INFO: Draw calls not geometry as a bottleneck in NWN.

[Legacy__six]

               

Baking area-wide geometry into a single mesh means the engine has no way to cull any part of that mesh that is off camera. So sure you can render more in one go, but your overall going to be drawing more too. I'd be tempted to wildly speculate about memory allocation costs too (but after taking part in http://allrgb.com/ using a garbage collected language, I'm maybe a little fresh from the trenches there).

 

The takeaway from all this IMO should just be, minimize texture count and combine whatever seems appropriate within a single creature, placeable, tile or tilegroup. If there's any wizard software to be written, something that does the combining within a single tile (or tilegroup) would probably provide benefits overall, I reckon. I've seen tilegroups in various tilesets (CC City had plenty) that have been utterly minced by the tile slicer tool that'd definitely benefit from it.

               
               

               
            

[Legacy_Shadooow]

               

P.S.  If anyone has a game or even an engine that they think might surprise me or be something that I would enjoy working with, PLEASE let me know!

Not that I know of any other game with such possibilities, but friend of mine is working on a brand new NWN-style engine. His goal is to allow reuse of the NWN (non-bioware) models and prefabs with extending the engine in terms of technologies and supported hardware. Unfortunately he is still at very start, he send me a DEMO showcase of what he currently has. Not very impressive but there is a high potential there... (BTW in that demo, a movement keys works, W (weapon) and A (animate)) and mouse to mess with camera.

               
               

               
            

[Legacy_Bannor Bloodfist]

               

At least he has something working there.  Not sure where/how the model(s) were created, animated etc, but it sounds as if he is starting from the Bioware format so it should be something that could be learned by the cc folks that may be interested.

               
               

               
            

[Legacy_OldTimeRadio]

               

Thank you for the data, OldMansBeard!  Can you provide the testing materials (esp. ASCII versions of those models) you used so that I can attempt to reproduce this behavior? 

 

What I'd like to do is use that same testing material and attempt to reproduce the performance hit.  Then try to identify any other factors in the models (or their textures) which could be causing it.  Since this is solely based on consolidating geometry, I'm kind of at a loss as to what could possibly be causing that dramatic of a loss of frame rate when, for instance, the total geometry on four individual tiles and one of the consolidated 4x4 tiles should be exactly the same.

 

The performance hit you describe isn't just noticeable, it's huge.  I'd like to have the opportunity to examine what's going on in that scene with the debugger.  That kind of data could be incredibly useful.

               
               

               
            

[Legacy_OldMansBeard]

               

Thank you for the data, OldMansBeard!  Can you provide the testing materials (esp. ASCII versions of those models) you used so that I can attempt to reproduce this behavior? 

 

What I'd like to do is use that same testing material and attempt to reproduce the performance hit.  Then try to identify any other factors in the models (or their textures) which could be causing it.  Since this is solely based on consolidating geometry, I'm kind of at a loss as to what could possibly be causing that dramatic of a loss of frame rate when, for instance, the total geometry on four individual tiles and one of the consolidated 4x4 tiles should be exactly the same.

 

The performance hit you describe isn't just noticeable, it's huge.  I'd like to have the opportunity to examine what's going on in that scene with the debugger.  That kind of data could be incredibly useful.

 

Yes, I'll see what I can do. It will be tomorrow, though. I'll bundle up both the ascii and binary versions of the models. Your hardware is almost certainly different from mine, so it will be interesting to see what effect that has on the numbers.

 

I think _six hit the nail on the head when he posted "Baking area-wide geometry into a single mesh means the engine has no way to cull any part of that mesh that is off camera. So sure you can render more in one go, but your overall going to be drawing more too."

               
               

               
            

[Legacy_OldTimeRadio]

               

Thank you very much, OldMansBeard.  RL is very busy at the moment so no rush but I want to make sure I put the request in now so that when time does open up I can dive into this and see what's going on.  I also agree with _six.  Still, I feel like there's some kind of "x factor" that I'm missing in this.

               
               

               
            

[Legacy_Bannor Bloodfist]

               

Thank you very much, OldMansBeard.  RL is very busy at the moment so no rush but I want to make sure I put the request in now so that when time does open up I can dive into this and see what's going on.  I also agree with _six.  Still, I feel like there's some kind of "x factor" that I'm missing in this.

 

Aren't you just re-enforcing the issue that has already been proven:  Aurora does NOT like high poly objects.  We ALL know that, it has been proven soo many times over the past 10 years that it is not even worth considering as a non-issue. The more poly's  single object has, the more the engine chokes.  Looking over the numbers OMB quoted a page or so back, about how many faces/polys you end up with, regardless of how simple a set of models you use the original idea of saving draw calls becomes moot.  The engine can't handle the actual poly count on anything large enough for an area to be useable to gain any advantage of merging everything into a single object.  Add to that the issues of lighting, shadows, and what EVERYONE wants in the way of variability, a tileset of pre-set 8x8 or 16x16 tiles would get so boring so fast that few, if any, would use it more than once anyway.

 

It was a neat idea, but seriously, do you expect to find anything truly different enough to make a difference? 

 

This sort of research would have helped Bioware long before the engine was finalized, but back then, 32 bits was new, and 64 bits was a dream.  Bioware even investigated what it would take to update the Aurora engine, and decided they were better off dropping it completely and moving on to a completely new engine, which they have also dropped in favor of licensing software from some other developers.

 

Anyway, the missing 'x' factor you appear to keep missing is just the simple poly count issues we have always had  to deal with.  No gain in speed from a single object vs split up objects, and in fact, reduced functionality with no real gain at all in speed - thus, no advantage.

 

With newer game engines, the draw call limit might be an issue, but likely it has already been designed around in various other ways.  That, and the fact that newer game engines are all written in 64bit languages even if the various programmers are NOT using the true advantages of the larger address bandwidth.

               
               

               
            

[Legacy_MerricksDad]

               

I'd personally like to know the exact limits of the engine. I didn't before, and now I know one more part of it. Whether or not it actually gets us something more useful to work with is still just speculation, but I'd like to know, and have documented for others, the exact limitations, and the why of each limitation. This kind of information can save people headaches in the future, especially users who are new to the toolset and modding in general. Without that info, people may simply run into the wall a full speed and their projects would then die from frustration.

               
               

               
            

[Legacy_henesua]

               

Bannor, it is not worth while to caution someone from more research - especially not when there are still questions unanswered.

 

One question we still need to answer here is what are the critical thresh holds for draw calls. How many drawcalls can we have per frame before performance takes a hit.

 

OMB's test didn't address draw calls at all. It addressed a problem you will run in to by endlessly combining meshes, and found a critical threshold that we can not cross. What his test actual was about was to anwer the question: is there a negative sideaffect to combing meshes.

               
               

               
            

[Legacy_OldMansBeard]

               

I've posted my test files on neverwintervault http://neverwinterva...-together-areas

               
               

               
            

[Legacy_OldTimeRadio]

               

Thank you sharing that, OldMansBeard!  I have made a little video in the debugger to show what I think the issue is:

 

               
               

               
            

[Legacy_MerricksDad]

               

I am not even going to ask why the Loch Ness Monster is sounding off in the background...

               
               

               
            

[Legacy_OldTimeRadio]

               

Ha!  I have the window open (it's a fine day over here) and apparently that's how my laptop's microphone records the sound of a car passing on the street out front.  I was like "What...What is that sound?" and then I realized.

               
               

               
            

[Legacy_OldMansBeard]

               

Interesting. Thanks, OTR. I'll try some quick tests with suppressing those fence meshes somehow and see what happens. They aren't on an 'a' node in the vanilla tiles, though they perhaps should have been, so I didn't force them.

               
               

               
            

[Legacy_OldTimeRadio]

               

Thanks, OldMansBeard.  To clarify something I said in the video, I'd suggest leaving all 32-bit textured things where they are (so, no consolidation of any sort) and then just consolidate the regular 24-bit stuff.   Listening to what I said, I realized it could have sounded like I could be suggesting consolidating the 32-bit stuff in some way and that wasn't my intention.  Thanks again!