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.
I've come to this conclusion that they are an issue in NWN, partly through the process of elimination and partly through deductive reasoning.
I invite alternative opinions but the way I see it, there are going to be three possible things which would limit the GFX engine: Geometry, Texture Memory and Draw calls. There's one other factor, the overhead of the sound system, that I'm leaving out intentionally because, for what I'm getting at, it didn't appear to be a factor. In your mind imagine a laggy, overstuffed scene, filled with placeables and creatures and spell effects and just freeze it, that whole scene, in your mind's eye. The scene could be almost anything where your FPS drops, though, like a busy scene in TNO. So what's causing the FPS to drop?
Is it the geometry? Conventional wisdom would always say "Yes, there's just too many polys in the scene". I used to subscribe to this, too, but when I actually tried to find what the limits for polys were, I found (except for the polys per node limit OldMansBeard mentioned) that there weren't any. The context in which this is taking place is one where shadows are turned off, BTW. I once did a proof of concept conversion of this insane mesh (~1,2 million tris) as a static placeable and it worked- until I whipped out my torch and the vertex lighting destroyed itself, giving me a bluescreen. But I could back off to things like Megaton from Fallout 3 or the Spelljammer Merchant and they worked. By all conventional wisdom, neither of those things should be possible at all much less run well for how heavy they are. But more than that, they represent a functioning, workable paradigm that blows that laggy scene I asked you to imagine right out of the water, poly-wise. So I removed pure geometry from consideration.
Is it the textures? I looked at this, too, a few different ways. TGAs max out at 2048x2048 and DDS files at 4096x4096. Even with the compression, DDS files that size are around 11 megs apiece. The filesize on a 2048x2048 TGA is something insane, like 16mb a pop. Since it would seem to be the less-optimized of the two, and since static placeables are still subject to TXI functions, I loaded no less than 8 cycling animations (watermarked so I could be sure they were using different textures) using 2048x2048 textures (which were also partly transparent) and those played nicely too. That's almost 200mb of unique texture memory being consumed which is also, in my guess anyway, far more than even that laggy scene we're trying to get to the bottom of would be using. So I removed texture memory from consideration.
Is it the draw calls? Draw calls were the last remaining thing I could possibly describe that unexpected FPS hit with but just that, itself, wasn't enough. But using a debugger, I could see the huge number of draw calls the game was making and that tipped the balance more than anything else. Except for emitters, some of which are definitely optimized to reduce draw calls internally, most official content and most community-made things aren't efficiently created, using separate textures and meshes which increase the draw calls. A lot. I can't easily get a count of the draw calls on whole scenes because NWN does not apparently make its draw calls to a specific OpenGL "context". It just shoots them out. I can step through them and count them manually but I can't (yet) get an automated draw call count because those performance meters are specific to measure the draw calls directed at a specific context, either Context 1 or Context 2. Also, how many draw calls is too many? Totally depends on your graphics card and CPU. I tend to make things that are playable on my P4 (circa 2005) with a GeForce2 Ti (circa 2001) in it, just sort of because. Not all draw calls carry the same weight (because some draw operations, for instance, might involve transparency) but I hear numbers like 500, under 2000, that kind of thing. Across the board (this is the deductive part) draw calls are to be avoided because too many will slow down FPS. And so I haven't been able to eliminate draw calls from the candidates, nor do I have something else I can point to.
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.
Because there are a few variables involved, one thing I've seen bandied about online is a test that goes something like this: Get VSync on so you have a clear handle on the number of full frames that are hitting the monitor. So, 60, 75, whatever your refresh rate is. Find/make a scene which reduces your framerate some considerable amount, say to 30 FPS with VSynched maximum of 60. Then lower your resolution. If the FPS do not go up, then the FPS is being limited because of too many draw calls. I don't have much time, but I'm hoping to take known or generally agreed-on laggy non-shadowed areas and try to analyze them.
Do you or anyone else have what they think are good candidates for testing this? Official content would be preferable to community-made stuff.
