Tileset Dynamic Grass Question

[Legacy_s e n]

               OTR: two separate wok meshes or a wok mesh that has double faces when required?
               
               

               
            

[Legacy_OldTimeRadio]

               

s e n wrote...
OTR: two separate wok meshes or a wok mesh that has double faces when required?

Two (normal) seperate WOK meshes in the same tile model, exported as one WOK file.  The WOK file will contain information about two separate aabb nodes, in this case with the grass mesh coming first.

Nothing fancy or odd about the meshes themselves.

Edit:  Sample file for download here, may not import properly into NWMax:

Replaces Rural tile TTR01_G02_01.  Should be pretty easy to get just placing the beginning of a stream someplace and tileset shows tile name at the bottom of the screen when mouse is hovering over tile.

Edit: Causes some kind of bizarre crashing problem with the toolset.  Removed link to file.
               
               

               

                     Modifié par OldTimeRadio, 19 août 2012 - 02:55 .
                     
                  

            

[Legacy_Pstemarie]

               Cool concept OTR, but it crashes the toolset whenever I try to save. I would suspect its because on some of the tiles the geometry coverage with the second wok is 100%
               
               

               
            

[Legacy_OldTimeRadio]

               

Pstemarie wrote...
Cool concept OTR, but it crashes the toolset whenever I try to save. I would suspect its because on some of the tiles the geometry coverage with the second wok is 100%

You're right, I'm seeing that too.  I wasn't having the problem earlier so let me see if I can reconstruct where it's going wobbly.
               
               

               
            

[Legacy_s e n]

               can you try make a single mesh instead of two and see if that works too? maybe detach the grass wok faces and "hide" them under the water faces, just a 1 cm!
               
               

               
            

[Legacy_OldTimeRadio]

               Stuff I tried(skippable and probably boring): Thank you for the ideas, SEN!  I tried the first one but not the second one and I also tried a bunch of other tests.  You guys could probably imagine all the ways to try to sneak that extra AABB in there.  None of them worked, though some of them caused more problems than others.  I have no idea what I was doing before or maybe if I was mistaken, but I ran through it a few times and just couldn't come up with something that didn't crash the toolset on exit.  Not the first time I've seen this particular problem with the toolset.  Game launches OK, module saves OK, but crash on exit.  I hit the Omnibus and looks like Lucifer Church ran into this problem along with Danmar and probably a couple of others, accidentally.  And from their comments it all seemed to point back to the AABB.  After quite a bit of trying to get that square peg into the round hole, I switched tacks and turned to the model itself.  The grass isn't a function of the AABB, it's a function of the material on each face.  Tried a bunch of cutting up my AABB node to get that to work and still nothing that seemed to work that didn't cause  a problem somewhere along the line.

However, I do think I might have nailed it: I hope, anyway.  Again, since it's "all about the faces", I went into the ASCII model, into the aabb node and found the water faces (which end in 6), copied them, pasted them at the end of the list of faces, changed the 6 at the end to 3 and then counted how many new lines I'd added.  Then I went back up to the "faces" count and incremented it by that many.  In this case, I added 14 new lines (these are copies of the water faces), and so my "faces 90" became "faces 104".  No AABB weirdness involved.  No duplicating AABB with this method.  This only affects the faces, which is the cue NWN is using to determine what needs to be drawn.  If anything, this is just doping the model with extra face data.  I tried compiling it externally and the external compiler doesn't seem to have a problem with it.

Download it here and give it a spin.
               
               

               

                     Modifié par OldTimeRadio, 19 août 2012 - 02:54 .
                     
                  

            

[Legacy_s e n]

               Otr: I know for sure that woks dont like verts that share XY position. To create those camera blocking tiles, just like Baba's Spidercaves to give you example, basically you use reversed obscuring faces, but you need to be sure that no vert of the obscuring roof shares XY value with the verts of the floor wok. but, the wok is always one! so maybe try that, just slightly offset XY values with the cloned and detached and reattached faces of the grass wok
               
               

               
            

[Legacy_s e n]

               img43.imageshack.us/img43/2236/swamp1.jpg

I got it: it is easy enough: you clone the faces you want with both grass and water, you slightly offset ( I say 5 cm) the shared XY verts of the cloned faces,  you flip the grass faces, and then you add the wok modifier and apply water where needed, and grass to the flipped ones. this way you get the grass to render (even with flipped faces, that doesnt interfere with the movement so you dont get movement weirdness, the grass will always render in vertical position with growing bottom->top) and you get splotches and water sound as you move.
               
               

               
            

[Legacy_NWN_baba yaga]

               Very cool stuff guys:) I´ll add this way for grass at the river edges for any tileset in the future.
               
               

               
            

[Legacy_OldTimeRadio]

               Hey, man- NICE!  And thanks for the information about the blocking tiles in Baba's spider caves, too.

How does that look when you have renderaabb on?  Will it compile with an external compiler?

Unless someone comes up with a problem with the method, I'm still sweet on just changing the faces.

Here's why:
-Modeling the grass through walkmesh affects the verts, faces, tverts and aabb.
-Simply adding extra faces to the face list only affects the faces and nothing more, but achieves the same effect.  Seems pretty benign in comparison.

Still, it's cool to see how many different ways we can approach the same problem!

Now, it doesn't look like anyone's downloaded the sample file I posted in the previous message so I'm not sure how much interest there is in a solution to this particular problem anyway.  But I think beyond attempting to address Pstemarie's question, these approaches also probably have applications outside of that narrow spectrum- and it'll be interesting to see what those wind up being.
               
               

               

                     Modifié par OldTimeRadio, 19 août 2012 - 03:34 .
                     
                  

            

[Legacy_s e n]

               OTR: I dunno how does it look in renderaabb, and I cant test cuz I already trashed the model ahah!

From what I understand the engine uses only up facing polys to create the path, and absolutely discards down facing ones, that can be used for "special rendering" effects like the grass one, or for cam blocking using obscuring terrain. as I said, just be careful of the XY coordinates, and you'll get no issues. I am sure your method is as good as this, I just hate notepad and ascii edits and prefer shortcuts '>
               
               

               
            

[Legacy_henesua]

               OTR - do all of the grass meshes you produce using your method reder using renderaabb
               
               

               
            

[Legacy_OldTimeRadio]

               

henesua wrote...
OTR - do all of the grass meshes you produce using your method reder using renderaabb

They do.  The real heart of my question wasn't so much about whether they render in renderaabb or the color it chooses to display the faces...but what the actual positions of the triangles in the walkmesh were, according to it.  If you add something and it messes with what the triangulation should be on the walkmesh, I'd consider that as something which was likely going to be problematic down the road.

That's not to say it certainly would, though.  1.69 is a lot more forgiving about that kind of stuff.  Not necessarily the toolset, though.
               
               

               
            

[Legacy__six]

               With regard to the downward facing triangles thing, you should be careful with placing them as if it's possible to get the camera underneath them (for instance if they're atop a raise/lower or cliff) it's likely to get trapped. Placing them slightly underneath the main walk mesh rather than on top is a good idea.
               
               

               
            

[Legacy_s e n]

               Six:downward grass doesnt block camera, i think only cam blocking is done by obscuring type, and if you create them, you already should have them carefully modelled for that blocking effect you are after