Compiled vs Decompiled Models - Recent Findings (aka Round 2)

[Legacy_Pstemarie]

               

I have begun compiling the Project Q models which will significantly improve performance - load time - on lower end GPUs and systems. I also discovered something about compiled tile models that I'd thought I'd share:

 

It is not uncommon for tiles to have geometry that extends beyond the normal tile edges - for example tps01_stem01 from the revamped Sigil Tileset. However, such tiles, when compiled, WILL cause a "SQRT Domain" error within the toolset. The only way to get around this issue is to leave the tile as an uncompiled ascii format model.

 

Thus, for best practices, I recommend that, when building tilesets, tile geometry does not extend beyond the limits of the 1000x1000 tile. This is what TileSlicer was made for folks.

               
               

               
            

[Legacy_cervantes35]

               

I don't think you can compile animesh or it messes up the animesh. Does this include any overhang as the TNO set has a lot of this so I know it wasn't sliced with the tile slicer. I know I did this with some sigil tiles as it reduced the size considerably because when you slice it you can literally created houndreds of new verts at the slice points.

 

I have never compiled any of my tiles so I did not know it caused this problem.

               
               

               
            

[Legacy_Pstemarie]

               

I'm just compiling what I can that won't break the models. Its not really an issue as opposed to a performance boost when playing over a server. A lot of the lag people experience seems to be caused by the engine having to compile models on the fly. Is not as big an issue on today's high end machines.

 

I didn't know it was suspected of causing issues with animesh. I'll have to watch out for that.

 

So far I've only caught the overhang issue on a handful of tiles, but it does seem to be consistent.

               
               

               
            

[Legacy_MerricksDad]

               

And here I am making tiles that do specifically that because of the benefits of overhang.

               
               

               
            

[Legacy_Frush O'Suggill]

               

Dumb question, but did Bioware use a different compiler for their models? I know there are a few official tiles that have geometry extending beyond the 1000x1000 limit. The cellar group from HotU comes to mind, for example.

               
               

               
            

[Legacy_cervantes35]

               I think that is why TNO was left uncompiled  because compiling the animesh caused problems.


I did this so I could test, which I never got around to trying to decrease the number of draws on a texture and see if helped with the frame per second  and hopefly improve shadow rendering by not  having bits of a mesh spread across several tiles.
               
               

               
            

[Legacy_OldMansBeard]

               

Animesh doesn't necessarily break when compiled. I compiled the CTP Babylon tiles with animesh "wavy water" like TNO and they worked fine. But it might depend on how the model is constructed and how the animations are defined.

 

Bioware had their own model compiler, different from nwnmdlcomp. It was available for download at one time and I still have a copy of it. It was basically the same code as the engine uses to load ascii models, but pulled out into an executable, The compiled models it generates are slightly different from the ones nwnmdlcomp generates but the differences are not usually important unless you are doing tricky stuff with emitters.. (edit - added: it was never updated to corespond to patch 1.69, which may be why the tno models were left uncompiled)

 

Some Bioware tile groups have meshes that project across tile boundaries, they are compiled and they don't cause SQRT Domain errors in the toolset. Maybe there's more to it, than just that?

 

Come to think of it, as an extreme case, for the tests I was doing in the "draw calls" thread, I made some tiles that were 16 times bigger than normal, compiled them and they didn't break the toolset. So compiling tiles with overhangs as big as 155.00 metres definitely isn't a problem.

 

What does CM3 say about your test models? If it passes them and they break when compiled, then CM3 needs fixing because it shouldn't.

               
               

               
            

[Legacy_Shadooow]

               

Some Bioware tile groups have meshes that project across tile boundaries, they are compiled and they don't cause SQRT Domain errors in the toolset. Maybe there's more to it, than just that?

Ive stumbled across this error too when I was fixing little errors in models, not sure how Ive created this problem, but running the models via CM3 always helped.

               
               

               
            

[Legacy_OldMansBeard]

               

Ive stumbled across this error too when I was fixing little errors in models, not sure how Ive created this problem, but running the models via CM3 always helped.

The SQRT Domain thing happens when the engine tries to compute the distance between two points (or between a point and a face) that are very close together and, because of rounding errors, gets a negative number for the "square on the hypotenuse", which it can't then take the square root of.

 

I'm speculating, but it could be caused by null or degenerate faces (where two or three verts are nearly coincident). These are almost impossible to spot visually, however hard you look at the model because basically you would need a microscope to see them. That's why we trained CM3 to sniff them out.

               
               

               
            

[Legacy_Zwerkules]

               

The SQRT Domain thing happens when the engine tries to compute the distance between two points (or between a point and a face) that are very close together and, because of rounding errors, gets a negative number for the "square on the hypotenuse", which it can't then take the square root of.

 

I'm speculating, but it could be caused by null or degenerate faces (where two or three verts are nearly coincident). These are almost impossible to spot visually, however hard you look at the model because basically you would need a microscope to see them. That's why we trained CM3 to sniff them out.

I've seen this in Bioware tiles, but don't remember in which tileset (probably interior). There are things like cylinders with several segments of which the vertices of the lowest segment were moved up so they ended up in the same place as the lower vertices of the segment above them. This is impossible to spot and I have no idea why they didn't remove the faces before they did this. I only noticed it when I had much more faces selected than should have been there.

Letting CM3 fix those tiles might be a good idea, but don't let it repair walkmesh overhangs because there are alot of those in Bioware tilesets at the edge of tiles and if it only gets fixed for some of them the walkmeshes won't align properly with those of tiles which weren't fixed.

               
               

               
            

[Legacy_OldMansBeard]

               

I've seen this in Bioware tiles, but don't remember in which tileset (probably interior). There are things like cylinders with several segments of which the vertices of the lowest segment were moved up so they ended up in the same place as the lower vertices of the segment above them. This is impossible to spot and I have no idea why they didn't remove the faces before they did this. I only noticed it when I had much more faces selected than should have been there.

Letting CM3 fix those tiles might be a good idea, but don't let it repair walkmesh overhangs because there are alot of those in Bioware tilesets at the edge of tiles and if it only gets fixed for some of them the walkmeshes won't align properly with those of tiles which weren't fixed.

Yes, that would make sense. And yes, if you are fixing walkmesh overhangs with CM3, you basically have to  do the whole tileset or none.

               
               

               
            

[Legacy_MerricksDad]

               

Wait....you can do walkmesh overhangs!!!!???

               
               

               
            

[Legacy_Zwerkules]

               

Walkmesh overhangs will cause problems if the material type of one or both of them is walkable. If it's not walkable they don't cause problems but shouldn't really be there. In Bioware tiles you get those overlapping walkmesh faces a lot in cliffs for example.

               
               

               
            

[Legacy_Lord Sullivan]

               

Wait....you can do walkmesh overhangs!!!!???

 

Walkmesh overhangs should not be a problem as long as it does not overlap another one in the group. Naturaly, walkmesh overhangs/overlap from a single tile is not good.

 

[Edit]: Gawd dam, I thought the discussion was about walkmeshes that expend on to other tiles in a tile group to join with the remaining balance of it... like not cut/split straight exactly at the normal edge limit of a tile.

               
               

               
            

[Legacy_OldMansBeard]

               

Wait....you can do walkmesh overhangs!!!!???

No, that's the point. If you try, it breaks things. But there are some iffy tilesets around where parts of the walkmesh do overhang other parts so CM3 has a feature for fixing this (it works by relaxing vertices so as to rotate the downward-pointing faces until they don't point downwards) but it has to be used carefully. If you relax the verts along one edge of a tile but not along the edge of any possible adjoining tile, you will get a tear in the whole walkmesh and that can be worse than if you left things alone. If you let CM3 fix the whole tileset, though, it will adjust the edges of all the tiles in identical ways, so they all line up again afterwards and there are no overhangs and no tears.

 

This is a bit off-topic, though. This thread is about compiling ...