Model Help: OC tileset model crashing the toolset

[Legacy_3RavensMore]

               

I've been tinkering with added this and that to the crypt tileset, and have encountered a strange problem.  The model tdc01_a14_01 crashes the toolset after it's exported with NWExplorer, loaded into gmax, and re-exported.  This has worked for all the crypt _a## models but this one.  FWIW the Sanity check reports problems thus:

 

Checking node Rectangle05

Bad Edge: 15 Vert pair: [-500,499.98,320.098],[-500,264.98,320.098]

Bad Edge: 18 Vert pair: [-265,499.98,320.098],[-500,499.98,320.098]

Bad Edge: 30 Vert pair: [500,499.98,320.098],[265,499.98,320.098]

Bad Edge: 33 Vert pair: [500,264.98,320.098],[500,499.98,320.098]

Bad Edge: 48 Vert pair: [-500,-20.0195,0.0980072],[-500,-500.02,0.0980072]

Bad Edge: 52 Vert pair: [-20.0001,-500.02,0.0980072],[39.9999,-500.02,20.098]

Bad Edge: 55 Vert pair: [-500,-500.02,0.0980072],[-20.0001,-500.02,0.0980072]

Bad Edge: 58 Vert pair: [39.9999,-500.02,20.098],[260,-500.02,20.098]

Bad Edge: 73 Vert pair: [-500,259.98,20.098],[-500,39.9805,20.098]

Bad Edge: 96 Vert pair: [99.9999,499.98,20.098],[-100,499.98,20.098]

Bad Edge: 105 Vert pair: [500,-100.02,20.098],[500,99.9805,20.098]

Bad Edge: 109 Vert pair: [101,499.98,320.098],[99.9999,499.98,20.098]

Bad Edge: 115 Vert pair: [-100,499.98,20.098],[-101,499.98,320.098]

Bad Edge: 131 Vert pair: [-500,264.98,320.098],[-500,259.98,20.098]

Bad Edge: 142 Vert pair: [500,99.9805,20.098],[500,99.9805,320.098]

Bad Edge: 163 Vert pair: [500,-100.02,320.098],[500,-100.02,20.098]

Bad Edge: 170 Vert pair: [265,-500.02,320.098],[500,-500.02,320.098]

Bad Edge: 173 Vert pair: [500,-500.02,320.098],[500,-265.02,320.098]

Bad Edge: 190 Vert pair: [500,99.9805,320.098],[500,264.98,320.098]

Bad Edge: 201 Vert pair: [500,-265.02,320.098],[500,-100.02,320.098]

Bad Edge: 202 Vert pair: [265,499.98,320.098],[101,499.98,320.098]

Bad Edge: 208 Vert pair: [-101,499.98,320.098],[-265,499.98,320.098]

Bad Edge: 219 Vert pair: [-500,39.9805,20.098],[-500,-20.0195,0.0980072]

Bad pivot location. Pivot must be 0,0,z.  Not -6.10352e-005,-0.0195312,z

ERROR: aabb split problem.

 

No other nodes generate a problem.  You can find the model in questions here: https://www.dropbox....dc01_a14_01.mdl  It's the unaltered from the crypt set model.

 

I'm really in the dark here...  Any help would be greatly appreciated.

               
               

               
            

[Legacy_Pstemarie]

               

The walkmesh has overlapping verts causing a tear in the walkmesh. It needs to be stitched up by hand. I can do it real quick and send it back to you. The walkmesh also needs to be centered at 0/0/0.

 

Edit - file is ready.... https://www.dropbox....tdc01_a14_01.7z

               
               

               
            

[Legacy_3RavensMore]

               

Thanks a bunch for that.  What would cause that to happen?  A assume it was how NWExplorer extracted it, but...is that a valid assumption?

 

Anyway, thanks again. 

               
               

               
            

[Legacy_Pstemarie]

               

No the model was messed up from the start. Many of the Bioware models have BAD walkmesh issues that don't get discovered until someone starts mucking around with the model and exports an updated version. Bioware modelers had a knack for cloning existing meshes to create the walkmesh then just attaching all the objects together and not welding verts. In this case, the walkmesh needed to be rebuilt, but, as I could not see any visible tears, I opted for eliminating unneccessary verts and then running the model through CM3. CM3 rebuilt the aabb data, allowing me to import the model, make a few manual tweaks and then export a final version. 

 

Walkmesh is very touchy and many things can cause issues. Some things to remember...

1. Minimize the complexity of the walkmesh by using as few verts and faces as possible

   
2. Do not allow faces to overlap

   
3. Make sure all verts are welded when you are done

   
4. Finalize the model in CM3

               
               

               
            

[Legacy_3RavensMore]

               

Ahh...  Well, just about every one the crypt tiles fail their sanity check.  That was the first one that crashed the toolset though.  I'll remember your tips for when I need start tinkering with walkmeshes.

               
               

               
            

[Legacy_3RavensMore]

               

Okay, there is still a problem with the tile.  When a PC moves near the doors, they jump up to well above the tileset and hover in the air.  They gain a retro funky moonwalk, but it rather problematic being a few tens of meters off the ground.  Any help?

               
               

               
            

[Legacy_Jedijax]

               

Regarding how you export the models from NWNExplorer, something Zwerk recommended and has worked wonders for me is extracting the model in it's ascii from the tab option, rather than clicking the export button. It will export as a text file, which you can then rename into a mdl. It significantly reduces the chances for model errors. Not saying this particular case will be solved in such a way, but it's a very good "defacto" protocol to follow.

               
               

               
            

[Legacy_Shadooow]

               

Yes, there are lots of tiles failing sanity checks. Usually I try to run them via CM3, but it doesn't always help in that case I leave it a be, haven't found any which would crash, but if it happens only with recompiled model the solution could be to leave this tile model uncompiled...

 

Anyway, exporting via NWNExplorer should be fine, its how I proceeded myself - see here for all vanilla tileset files already decompiled.

               
               

               
            

[Legacy_OldMansBeard]

               

Okay, there is still a problem with the tile.  When a PC moves near the doors, they jump up to well above the tileset and hover in the air.  They gain a retro funky moonwalk, but it rather problematic being a few tens of meters off the ground.  Any help?

 

That's definitely caused by a hole in the walkmesh.

 

It occurs to me that the problem here, might be something to do with snapping, Importing into GMax and exporting again will result in the walkmesh verts being snapped to 1cm and this might turn a tile that just barely works in the original, into one that is firmly broken. I don't have GMax installed any more, but maybe someone else could follow that up.

 

Regarding how you export the models from NWNExplorer, something Zwerk recommended and has worked wonders for me is extracting the model in it's ascii from the tab option, rather than clicking the export button. It will export as a text file, which you can then rename into a mdl. It significantly reduces the chances for model errors. Not saying this particular case will be solved in such a way, but it's a very good "defacto" protocol to follow.

 

I've never known NWE to corrupt a model on export (apart from the emitter bugs and the selfillumcolor bug in the early version) but there's always a first time '> If you think it is a problem, you can try exporting the binary version and letting CM3 read it directly. But I don't think that's the problem with this model. I think it's a flaky walkmesh in the original.

 

edit - added

 

I tried running the vanilla, binary model through CM3 with and without snap. Either way, there are null faces and duplicate faces in the walkmesh and that's definitely a bad sign.

 

Suggestion: run the vanilla binary model through CM3 with snap set to decimal and 'Repair aabb overhangs' set to 'Interior only' but all other fixes turned off. That will give you an baseline ascii model that won't be corrupted by the snapping in NWmax and where at least some of the walkmesh glitches are fixed already.

               
               

               
            

[Legacy_Pstemarie]

               

I had completely remade the walkmesh - new verts and faces, however, so it shouldn't have any tears. I'll have to look at it again.

 

EDIT - Yup, no tears in the walkmesh. I've also run several passes with the PC moving through and around the doors of the tile I uploaded to dropbox and have been unable to duplicate the issue you are having now. You had mentioned modifying and adding stuff. OMB, is it possible this behavior could be caused by the adjacent tile - which may or may not have been modified by 3RavensMore - on the other side of the door?

               
               

               
            

[Legacy_3RavensMore]

               

Well in the light of a new morning, the repaired tile is working fine.     It truly was causing the above phenomenon last night though.  Since I'm going to be editing every crypt tile (I'm adding a roof) maybe I should learn to fix walkmeshes.      Seeing as I've never worked with them, it should be...ah...interesting, albeit in a probably painful sort of way. 

               
               

               
            

[Legacy_Zwerkules]

               

Yes, there are lots of tiles failing sanity checks. Usually I try to run them via CM3, but it doesn't always help in that case I leave it a be, haven't found any which would crash, but if it happens only with recompiled model the solution could be to leave this tile model uncompiled...

Any tile with an aabb split problem will cause a game crash because when the tile gets exported by (g)Max there's some text in the walkmesh and model file describing the aabb split problem and the game can't use the file properly any more.

There are quite a few Bioware tiles with walkmeshes so bad that they will crash the game after someone worked on the tiles with gmax and exported them. I remember the arena tiles in the city tileset have aabb split problems and there are some more I don't remember.

 

3RavensMore, it is very unlikely that you cause such aabb split problems yourself because there are very few ways to create this problem and all of them are easily avoided, which makes it strange that several Bioware tiles have them. They are much rarer than other problems though. For example, I don't like it if tiles don't pass the sanity check when I export them and there are many ways to make them fail the sanity check and still work in game and Bioware tiles are full of them:

 

A walkmesh should have a rotation of 0 degrees. Bioware tiles walkmeshes often have a rotation of 90 degrees.

 

Vertices aren't welded. This will cause problems in game when those unwelded vertices are on a walkable area of the tile or between a walkable and unwalkable area. When they are  on a completely unwalkable area they will not cause problems in game, but will cause the sanity check to fail.

 

Gaps in the walkmesh. Again, this won't cause any problems if they are in an unwalkable area and not right next to a walkable one, but will make the PC jump up in the air if the gaps are on a walkable area or next to it. There are many gaps in Bioware tiles walkmeshes that won't cause problem in game, but will make the sanity check fail.

 

Pivot point of the walkmesh is not at 0,0 or not an integer. You'll find this alot in the standard tilesets. They cause no problems in game, but will make the sanity check fail.

 

Edge vertices that are not an integer. If an edge vertex is at 500.06, 500.02, 0.0 it won't cause problems in game because the game probably rounds it down to 500, 500, 0. It will cause the sanity check to fail though. If a coordinate is greater than 500.499 it will also cause problems in game.

 

 

There is one problem the sanity check will not report that causes problems in game. If two vertices have the same x and y coordinates but a different z one, the PC can get stuck near them. If you make a wall or something like that, make sure that the vertices at the top of the wall are moved inward a little, one cm is enough.

 

 

I like to make sure that none of my walkmeshes have any of these problems, so I always have sanity checks turned on.

               
               

               
            

[Legacy_3RavensMore]

               

Thanks for the addition info Zwerk.