Maximum Walkmesh Faces

[Legacy_Michael DarkAngel]

               

I'm sure this has been discussed before, somewhere, at some time...

 

Unfortunately, a search of this site and a google search has not turned up anything useful.

 

Does anyone know what the maximum number of faces a tile walkmesh can have?

 

I would like to have a target to reach so that 3DSMax doesn't crash when I apply the AuroraWalkmesh modifier.

 

TIA

 

MDA

               
               

               
            

[Legacy_OldTimeRadio]

               

The AuroraWalkmesh modifier in NWMax, while algorithmically "fine" for calculating the AABB tree for a given walkmesh, is not very robustly coded.  It appears to consume something like an exponential amount of memory the more faces you have above a certain point.  An editable mesh plane of more than 15-20 (IIRC) length/width segments is where things start to go haywire.  In the original Bioware export scripts, the AABB routine is one of the few things not handled by a script but by the plugin (Aura.dlm).  It has no such limitations.  

 

I have fixed this behavior in NWMax before but, lol, I don't know where I put it.  I can say that to break through the "haywire" barrier, you basically have to force super aggressive garbage cleanup (using the GC() MaxScript command with switches, if not one other command) in just about every bit of the AABB subroutine.  

 

In my limited tile work, I have never gone over 10 length/width segments (200 tris) for a walkmesh just because much more seems gratuitous and, possibly, detrimental to gameplay.  A 10x10 length/width also gives me generously sized 2-meter entry/exit points for the tile, something recommended on Page 2 of Bioware's TileSetConstruction guide.

 

If you really need to go over 10x10 for something, I can try to dig up the changed code.  But it might take a few days or more before I find it.

               
               

               
            

[Legacy_s e n]

               

optimizing walkmesh polycount by hand after a tile is done is most fun part of the job '>

               
               

               
            

[Legacy_MerricksDad]

               

Doesn't the aabb data only show face to face pathing, or more accurately edge to edge? I was never too in-the-know on exactly what those values mean, but I assumed that was the only method, other than storing data for straight line travel. So wouldn't aabb data then be an exponent pile based on the number of faces sharing a vert? If that is true, then wouldn't making sure you had lower faces per vert be beneficial? And again, if that is true, wouldn't an even number of faces be less time consuming to calculate, and use, than an odd one, given that any variety of odd faces immediately creates a star pattern instead of a 4-way stop, and so the tree would suddenly expand greatly at any 5 way or greater face node. Isn't it then easier on the engine to limit the number of faces to any given vert to 4 (correction 8 faces, or 4 square poly), creating a totally, or nearly so, squared-off mesh, even if that means dividing a face here and there, increasing the face count, but reducing the faces per vert count. The overall complexity of a WM would then be reduced, and larger gaps, such as index-7 cliff faces could feel free to be reduced in count, even if their number was somewhat odd at "land-locked" faces.

 

I could be totally wrong. I just don't know what the 7th number is about.

               
               

               
            

[Legacy_OldTimeRadio]

               

@MerricksDad - Much of that went right over my head, but from what I can understand, the AABB data is face to face and only used for intra-tile pathing.  Pathing within a tile.  While I mention not personally liking to go over 10x10 length/width segments, faces on walkmesh should be kept to the absolute minimum and preferably a minimum which yields the highest percentage of equilateral or close to equilateral triangles.  Time consumed to precalculate the AABB seems pretty speedy, already.

 

I could be totally wrong. I just don't know what the 7th number is about.

 

If you're talking about the 7th number in the AABB face data, you might find more information by searching the Omnibus for hlubocky and Banf.  That 7th number might not be used.  Dunno.

 

               
               

               
            

[Legacy_MerricksDad]

               

I understand it now. What a mess.

               
               

               
            

[Legacy_Michael DarkAngel]

               Okay, reduced the offending walkmesh faces by about 50% (1800 to 850). That allowed me to apply the AuroraWalkmesh modifier without crashing 3DSMax. Won't know how it reacts in game until later tonight.



MDA
               
               

               
            

[Legacy_Bannor Bloodfist]

               

Okay, reduced the offending walkmesh faces by about 50% (1800 to 850). That allowed me to apply the AuroraWalkmesh modifier without crashing 3DSMax. Won't know how it reacts in game until later tonight.



MDA

 

I have successfully worked with Woks of up to around 1200 faces, they will work in game.  However, they also slow the load of an area, appreciably when you have multiple tiles with such a large count of wok faces AND the resulting large count of object faces. 

 

However, I have found that just as using a shadow object with very low face count helps appreciably when casting shadows, reducing wok faces and resulting engine calculations increases speed of access to any area in a specific tile.  Besides, who needs such a high count of faces in a 10 meter area?  Of course, this is assuming that you have and are willing to spend, the amount of time necessary to reduce the face count.

 

For an example, take a set of stairs / steps.  One with a matching wok that uses faces for both the top of the step and the riser bit, the vertical separator between each step.   The engine will allow you to create such a wok, and it will load it.  Your NPC might have issues following you though, when you attempt to run up the stairs.  It will generally make it, but it tends to slow it down.  A simple, 2 face, angled ramp makes more sense. AND it will save all the wasted faces along the vertical sides of the steps that you can't walk on anyway... IE if the side of the steps are followed as the visual object with all the insets for each step, you must also create wok faces to match,  Whereas that simple 2 face ramp, would only require a single face on each side, thus resulting in a total of 4 faces for the entire set of steps.  While this might cause your characters feet to clip through the edge of the step a bit, typically, most humans would not even notice it.  The game engine itself will appreciate the reduced calc time though. 

 

Basically, keep the wok as simple as possible, and run the scripts to reduce poly counts as much as possible on your wok object.  You will greatly appreciate it later.  Remember, the wok is not a visible in game object, so having detailed polys is just a complete waste of space (ram and/or disk) and processing (to compile it.)

 

As usual, I am speaking way to much about the subject, sorry.  YMMV

               
               

               
            

[Legacy_TheOneBlackRider]

               

Just because it fits here: When I was starting to work on the Witcher 1 Wyzima outskirts tavern, the walkmesh modifier crashed on me, when the face count was something around 882 faces (Gmax). With a bit more than 800 faces, it was still working. (I got around this by first slicing the walkmesh, then applying the modifier and assign the IDs and then attaching and welding the walkmesh again.)

 

Edit: Well, meanwhile, the whole model is tile slized and, of course, each walkmesh is much smaller regarding the face count.

               
               

               
            

[Legacy_OldTimeRadio]

               

I'm puzzled why anyone would need so many faces in a single tile's walkmesh, though.  Scaling down the game so a "player" is much smaller is about the only reason I can think of, but I think that has some unexpected drawbacks of its own.

 

Can someone shed insight on the matter? 

 

Very cool trick, BTW, TheOneBlackRider!  I took a look at that Inn you're describing, but that walkmesh face total had to have spanned several tiles, correct?

               
               

               
            

[Legacy_Michael DarkAngel]

               

@OTR

 

Detail. 

 

Stairs:  A flat ramp style walkmesh (2 faces) would most certainly suffice.  However, should the PC stop at some point in the middle you run the risk of having the PC floating above or sinking into the stairs.  Careful placement of the ramp may make it less noticeable.

 

If you detail the walkmesh to match the geometry, you don't have that issue.  Of course, the downside is an increase in face count.  Instead of having two faces for the simple ramp, each step would be a minimum of four faces.  And if your steps aren't perfect (crooked, broken, not level) your face count keeps going up.

 

I can't remember which tile I had this issue with now, but I finally had to reduce the face count on the walkmesh to less than 500 before it would export without crashing.  That's less than a third of the actual detail of the tile geometry.  I doubt anyone would notice as they walk/run through the tile, but standing still in certain spots may be noticeable.

 

MDA

               
               

               
            

[Legacy_rjshae]

               

I don't know about NWN, but in NWN2 the limit seems to be 127 or 128. I.e. an 8-bit signed integer. (The non-walkable faces don't count against that total.) If the total walkable faces goes over that count, it won't bake. Hence I try to keep a tile's walkable mesh faces at around 80 or less so I can add placeables (which can increase the number of faces).

               
               

               
            

[Legacy_rjshae]

               

@OTR

 

Detail. 

 

Stairs:  A flat ramp style walkmesh (2 faces) would most certainly suffice.  However, should the PC stop at some point in the middle you run the risk of having the PC floating above or sinking into the stairs.  Careful placement of the ramp may make it less noticeable.

 

If you detail the walkmesh to match the geometry, you don't have that issue.  Of course, the downside is an increase in face count.  Instead of having two faces for the simple ramp, each step would be a minimum of four faces.  And if your steps aren't perfect (crooked, broken, not level) your face count keeps going up.

 

I usually place a flat walkmesh ramp so that the outer end of every step is peeking through; that seems to produce reasonable results. I did try a walkmesh that follows a staircase more exactly, but it resulted in bumpy and unrealistic movement. I'd probably only try to do such a higher mesh count fitting if the steps are at least a character's stride-length deep.

               
               

               
            

[Legacy_TheOneBlackRider]

               

I'm puzzled why anyone would need so many faces in a single tile's walkmesh, though.  Scaling down the game so a "player" is much smaller is about the only reason I can think of, but I think that has some unexpected drawbacks of its own.

 

Can someone shed insight on the matter? 

 

Very cool trick, BTW, TheOneBlackRider!  I took a look at that Inn you're describing, but that walkmesh face total had to have spanned several tiles, correct?

 

Sorry for my slow reply - I've been away from home.

 

I imagine, one encounters these huge walkmeshes only when designing models (groups), which actually exceed the usual NWN1 size, because they are very specific structures. Examples for this are Mendeku's Dragonlance buildings "Dargaard Keep" (14x14), "Tower of Hight Sorcery" (10x11) or the "Dragon Mountain" (6x12).

 

Wouldn't one first design the whole model (eg. 14x14), then make a copy of the meshes needed to create a walkmesh, adjust the walkmesh in a workable way and then tile slice it? So before tile slicing, one would have one huge walkmesh. Or ist there a different (economical) approach for large models?

 

And thus: yes, the original walkmesh of the Witcher 1 tavern spanned severeal tiles before the tile slice. I have to cut out the models from a HUGE area plus CDP seem to have raised the general numbers of polys. That tavern is now "only" a 8x8 area, but the poly count for the walkmesh exceeded 882 faces at that time, because it was still one (8x8) mesh = not tile sliced.