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

[Legacy_OldMansBeard]

               

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!

Yes, what I'm doing now is to remake all the tiles with all the fences and splotches (conveniently, they all have transparencyhint 1) moved onto an 'a' node and left unconsolidated on their original tiles, just consolidating the truly static meshes across the chunks. So there will be less consolidation but what there is, will be good stuff.

 

Two more to do, then I can get some new data.

               
               

               
            

[Legacy_OldMansBeard]

               

Yes, what I'm doing now is to remake all the tiles with all the fences and splotches (conveniently, they all have transparencyhint 1) moved onto an 'a' node and left unconsolidated on their original tiles, just consolidating the truly static meshes across the chunks. So there will be less consolidation but what there is, will be good stuff.

 

Two more to do, then I can get some new data.

 

Well, that wasn't the answer. Sorry.

 1x1 101/155 fps
 2x2 101/155 fps
 4x4  96/155 fps
 8x8  67/149 fps
16x8  65/148 fps

Just chunking non-alpha meshes doesn't help. With fewer meshes consolidated, the effect of doing so is less marked but it's still adverse.

 

Interestingly, hanging the splotches and fences from an 'a' node seems to pull performance down somewhat, just in itself.

 

I'll upload the new files as Version 2

               
               

               
            

[Legacy_Lord Sullivan]

               

Well, that wasn't the answer. Sorry.

 1x1 101/155 fps
 2x2 101/155 fps
 4x4  96/155 fps
 8x8  67/149 fps
16x8  65/148 fps

 

Where do you guys get such numbers? NWN is caped at 60FPS... is there a setting to unlock it that I don't know about?

               
               

               
            

[Legacy_3RavensMore]

               

Capped at 60?  On a fresh install in a 16x16 area stuffed full of well...stuff, I get 50-120 fps. 

               
               

               
            

[Legacy_Lord Sullivan]

               

Capped at 60?  On a fresh install in a 16x16 area stuffed full of well...stuff, I get 50-120 fps. 

 

Really? See I have a decent desktop computer with a Nvidia GeForce 9800 GT, 4 GB Ram, Core2Duo E6600 2.4Ghz @3.0 Ghz.


I always have stellar performance in pretty much every game I play(Not most recent ones) up to 2009ish.


Example: Farcry at 1920x1200 native display resolution 96/152 FPS

vs

               Neverwinter nights at 1920x1200 native display resolution 19/24 FPS in extreme crazy filled areas(a rare case) 32/60 fluctuation in standard cases and 60 constant in an area with little in it such as the area in my lastest video on "Light & Flame Mod". It stays there... does not budge. Not even If I start moving the camera irraticaly.

Software: Gregion Gaming Capture and/or Fraps


So tell me, what am I missing?

               
               

               
            

[Legacy_Tiberius_Morguhn]

               

Really? See I have a decent desktop computer with a Nvidia GeForce 9800 GT, 4 GB Ram, Core2Duo E6600 2.4Ghz @3.0 Ghz.


I always have stellar performance in pretty much every game I play(Not most recent ones) up to 2009ish.


Example: Farcry at 1920x1200 native display resolution 96/152 FPS

vs

               Neverwinter nights at 1920x1200 native display resolution 19/24 FPS in extreme crazy filled areas(a rare case) 32/60 fluctuation in standard cases and 60 constant in an area with little in it such as the area in my lastest video on "Light & Flame Mod". It stays there... does not budge. Not even If I start moving the camera irraticaly.

Software: Gregion Gaming Capture and/or Fraps


So tell me, what am I missing?

 

Do you have VSync enabled in game?

               
               

               
            

[Legacy_Lord Sullivan]

               

Do you have VSync enabled in game?

 

ah AH! that's what I was missing! lol

 

Yeah I got up to 222 FPS in my small forest area. I had not set VSync in game but in the NVidia control panel in the per application settings for NWN to prevent screen tearing while capturing video. Having not checked FPS performance in quite a while, I thought NWN was capped at 60 FPS reguardless.

 

Thanks Tib.

               
               

               
            

[Legacy_OldMansBeard]

               

I've done one more test, setting the camera height to 200.0 and removing fog, looking straight down so that the whole area is visible in plan view. That way, all of the meshes in the areas are visible and the only difference between areas should be the way the faces are internally distributed between nodes and models.

 1x1 53 fps
 2x2 54 fps
 4x4 54 fps
 8x8 53 fps
16x8 51 fps

There's barely any difference, so chunking is not helping.

 

The conclusion has to be that, if only part of the area is visible (as in normal play), chunking forces more to be rendered and so pulls down performance whereas if the whole area is already being rendered (in artificial tests), it yields no improvement.

               
               

               
            

[Legacy_OldTimeRadio]

               

Thanks, OldMansBeard.  On this last test (with the camera height set to 200), I assume those numbers are with the consolidation.  What were the baselines?  Because in situations where all the geometry is visible at once, I'd be gobsmacked if there is a decrease in FPS with consolidated models.  Then again, I might not understand the numbers but I can't argue with them.  With VSync turned off I know all those frames are not hitting the screen (that's determined by refresh rate on the monitor) but by the same token, I have no information that the work isn't being done so even with VSync turned off, the ratio in your observations should hold even with it turned on.  Or if not, that degredation in FPS would still be present with VSync turned on.

 

Interestingly, hanging the splotches and fences from an 'a' node seems to pull performance down somewhat, just in itself.

 

I assume you do not mean hanging all splotches for a group from a single tile's a-node, but leaving them connected to the tiles they were originally on.  Is that correct?

 

An aside: Totally separate topic, but related.  What do you ascribe to the FPS slowdown in a tileset like TNO, especially when things like the sea cliffs are in use and there's a lot of "depth" to the map?  With placeables like this, I've always gotten the impression that the performance of TNO, once obvious things like shadows were turned off, couldn't possibly be related to pure geometry because the placeable I link to is so much "heavier" than anything in that whole tileset or, possibly, all the tiles in that tileset, combined.  I don't know how to reconcile these two things.  I don't know if I mentioned it upthread, but the only other "differences" I could think of (in the case of TNO, for instance, were transparencies and TXI-deformed 32-bit textures (i.e. the water), which I know can get expensive- but I never would have assumed they'd be that expensive in typical use.   Edit: Or the animesh on the water.  Hrm....

 

And a bit of a ramble: In the last two years, I've only ever been able to find one reference to draw calls by someone who worked on NWN and that was by Trent Oster (during NWN development, back in the Interplay days) who indicated that the reason the weapon textures were consolidated into one texture was to reduce the draw calls.  Specifically.  But looking at official content (creatures, VFX, placeables) at some point those considerations were thrown out the window and I've always presumed it was because Bioware had locked down the camera and so only worried about keeping under-budget with things on the screen from that perspective.

 

Thank you so much for your data.  For the last few weeks, workmen and inspectors have been coming over and that's probably going to be happening off and on until June.  When I get more free time, I'm going to "Round Two" and "Round Three" this same idea with creatures and VFX and getting  a grip on how consolidation works (or doesn't) with tiles is the first big step.  I continue to look at this, not despite your data, but because there are differences in what the optimizations are.  The experience I had with static placeables seemed to carry over to tiles and maybe that was an erroneous assumption on my part...though why, I'm still not sure of.

               
               

               
            

[Legacy_OldMansBeard]

               

Thanks, OldMansBeard.  On this last test (with the camera height set to 200), I assume those numbers are with the consolidation.  What were the baselines?  Because in situations where all the geometry is visible at once, I'd be gobsmacked if there is a decrease in FPS with consolidated models.  Then again, I might not understand the numbers but I can't argue with them.  With VSync turned off I know all those frames are not hitting the screen (that's determined by refresh rate on the monitor) but by the same token, I have no information that the work isn't being done so even with VSync turned off, the ratio in your observations should hold even with it turned on.  Or if not, that degredation in FPS would still be present with VSync turned on.

 

 

I assume you do not mean hanging all splotches for a group from a single tile's a-node, but leaving them connected to the tiles they were originally on.  Is that correct?

 

An aside: Totally separate topic, but related.  What do you ascribe to the FPS slowdown in a tileset like TNO, especially when things like the sea cliffs are in use and there's a lot of "depth" to the map?  With placeables like this, I've always gotten the impression that the performance of TNO, once obvious things like shadows were turned off, couldn't possibly be related to pure geometry because the placeable I link to is so much "heavier" than anything in that whole tileset or, possibly, all the tiles in that tileset, combined.  I don't know how to reconcile these two things.  I don't know if I mentioned it upthread, but the only other "differences" I could think of (in the case of TNO, for instance, were transparencies and TXI-deformed 32-bit textures (i.e. the water), which I know can get expensive- but I never would have assumed they'd be that expensive in typical use.   Edit: Or the animesh on the water.  Hrm....

 

And a bit of a ramble: In the last two years, I've only ever been able to find one reference to draw calls by someone who worked on NWN and that was by Trent Oster (during NWN development, back in the Interplay days) who indicated that the reason the weapon textures were consolidated into one texture was to reduce the draw calls.  Specifically.  But looking at official content (creatures, VFX, placeables) at some point those considerations were thrown out the window and I've always presumed it was because Bioware had locked down the camera and so only worried about keeping under-budget with things on the screen from that perspective.

 

Thank you so much for your data.  For the last few weeks, workmen and inspectors have been coming over and that's probably going to be happening off and on until June.  When I get more free time, I'm going to "Round Two" and "Round Three" this same idea with creatures and VFX and getting  a grip on how consolidation works (or doesn't) with tiles is the first big step.  I continue to look at this, not despite your data, but because there are differences in what the optimizations are.  The experience I had with static placeables seemed to carry over to tiles and maybe that was an erroneous assumption on my part...though why, I'm still not sure of.

 

The numbers in that last test were when looking straight down from a great height at the middle of a 16x16 area; the different cases were for areas tiled with different-sized chunks (so the five areas look identical, they are just different inside the models). In a sense, the 1x1 number is the baseline because that uses the individual tiles with no consolidation across tiles at all. The 8x8 figure is for when all the static meshes for all the tiles in each 8x8 quadrant of the area are consolidated into their bottom-left-corner tile and the other 63 tiles in that quadrant have no static meshes left on them at all. So the draw calls for the static meshes are reduced by a factor of 64 (there are still draw calls for the fences and splotches, but those don't change). And the result is ... zilch. The frame rate is exactly the same. So, it looks like NWN tiles don't play nicely with the draw-calls theory. There must be something else going on, deep inside the engine.

 

In the V2 of the hak that I used for this last test, the splotches and fences were individually relinked to the 'a' node of the tile they belonged to (the vanilla tiles didn't have 'a' nodes, so new ones were created). They weren't consolidated within tiles nor across tiles and they weren't moved from the tiles they started on. They are just ignored by the whole chunking process. I think I might try deleting them completely, just out of interest. I'd expect the frame rates to shoot up.

 

With the fps being below 60, turning vSync on or off makes no difference to the fps (I've tried that). In the earlier tests, with the default camera height, it would have capped at 60 of course, so I had it turned off.

 

I've always believed that the performance hit in TNO was at least partly because it used heavier bitmaps, but I've never tried to do any systematic tests on that. It might be instructive to try. When you get time to look at things in more detail, maybe we can work together ?

               
               

               
            

[Legacy_OldMansBeard]

               

I've tried removing the fences and splotches entirely and, not surprisingly, the frame rates go up but the overall trend is the same. Then I tried switching to lo-res textures (tga compatibility mode) and, again not surprisingly, the frame rates went up but the overall trend is still the same.

 

Camera A: normal camera height, looking straight down, zoomed in on a small patch of cobbles

Camera B: as A but zoomed out (approx two buildings in view)

Camera C: camera height 200.0, whole area in plan view

 

Normal Textures

Chunk  Camera  Camera  Camera
Size     A       B       C
-----  ------  ------  ------
 1x1    180     121.5    66
 2x2    180     122      65
 4x4    180     115      66
 8x8    173      76      64
16x8    172      74      60.5

Lo-Res Textures

Chunk  Camera  Camera  Camera
Size     A       B       C
-----  ------  ------  ------
1x1     309     245      90
2x2     309     248.5    95
4x4     309     210      98
8x8     300     108      95
16x8    296     102      90

               
               

               
            

[Legacy__six]

               

A dubious theory on the a node: I'd suspect objects attached to the a node are rendered in a second pass over dynamic objects after all the static objects in the scene have been drawn. Which would probably equate to more CPU time in organising the objects, the more you had attached to it.

 

Actually, it's reasonable to suspect dynamic stuff in NWN just takes a totally different path. Ever noticed that placeable and door lighting looks rather different to tiles?

               
               

               
            

[Legacy_Zarathustra217]

               I recall a Bioware developer writing in a gamasutra article that most lighting for static geometry (including static placeables) is calculated on the client entering the area whereas dynamic geometry has it all calculated live, so that might explain why they sometime render differently.


Anyway, by now, do we have anything concrete saying that drawcalls are ever an issue in NWN? Before considering to consolidate meshes, we really need to answer that.


/Off-topic: What's an 'a' node? I've seen it mentioned a few times lately but haven't been able to find any documentation on it.
               
               

               
            

[Legacy_OldMansBeard]

               

I recall a Bioware developer writing in a gamasutra article that most lighting for static geometry (including static placeables) is calculated on the client entering the area whereas dynamic geometry has it all calculated live, so that might explain why they sometime render differently.


Anyway, by now, do we have anything concrete saying that drawcalls are ever an issue in NWN? Before considering to consolidate meshes, we really need to answer that.


/Off-topic: What's an 'a' node? I've seen it mentioned a few times lately but haven't been able to find any documentation on it.

 

What the measurements seem to be telling us, is that consolidating meshes to reduce draw calls, doesn't work for tiles. If anything, it's counter-productive.

 

About 'a' nodes

 

In tiles and placeables, a dummy node that has the name of the model with an 'a' on the end has a special meaning for the engine. Any nodes that are parented (linked) to that (or to other nodes that are in turn parented to it) are treated as dynamic, whereas nodes that are not, are treated as static. Static nodes are rendered more cheaply than dynamic ones because unless the camera is moving, they don't need to be recomputed for every frame.

 

Pieces of mesh that are animated (for example, a waterwheel that rotates slowly in a watermill tile) have to be attached to these 'a' nodes, otherwise the animations don't work because the engine treats them a static.

 

Shallow water (where the player can wade into it) needs to be attached to an 'a' node too, otherwise the player's feet disappear when viewed from above the water.

 

Meshes that are rendered with a bitmap that has transparent areas (fences, gratings, leaves on trees, for example) don't have to be attached to an 'a' node but it's better if they are because if they are not, some graphics cards and some drivers will leave a white margin around the opaque parts, which looks bad.

               
               

               
            

[Legacy_Zarathustra217]

               Ah, thanks for explaining that.


Anyway, concerning drawcalls, what I'm trying to say is that we haven't really tested yet how many you need to have before it starts actually affecting performance.