Horde3D

drawGeometry() calls drawRenderables() which will call any registered rendering function to draw renderable nodes. So if you have no emitters and drawParticles() is still being called then there might be an issue with the (*NodeRenderFunc)()'s.

I'd try turning:


into 0x0 in the place of Renderer::drawParticles, and then seeing if they go away. Which would indicate either a problem in the scenegraph containing bogus emitters or in the registration system.

The global renderableQueue is good for sorting purposes, but bad for rendering.

In the case of 70 models and 4 particles it's necessary to iterate through those 70 models when drawing those 4 particle emitters. Yes the loop just calls continue if the type is bogus, but it's still a bit unnecessary. Perhaps, when a node type is registered it also registers a queue for it's type. Then the render functions only need to access the queue of the renderable type, which would be cleared/rebuilt by updateQueues. The renderable queue update has the advantage that it could exploit temporal coherence, the rendering loop however can't.

I think one reason for the long loading time is that the scene/resource system is trying to find free handles by iterating over the whole scene/resource list. But this can very easily be optimized by adding a freelist where free slots are stored.

@abhinavgolas: Did you profile the loading process? If yes, where is most of the time spent?

@swiftcoder: Is there anything specific you have in mind? I don't think the resource system is overly slow (although there is room for optimization). Texture loading depends on the image type (dds will be even faster), geometry and animations should be quick as plain binary files. We have the few XML files but they should not slow down much since our parser is quite efficient (and the files are small). And if we need faster XML, we can write a non-extractive parser that should even be a lot faster by minimizing memory allocations. Shaders loading/compilation can be relatively slow of course, but that depends on the GL driver and there is nothing that can be done about in GL (D3D would have binary shaders).

Yeah, that can be improved, although different lists are more difficult with the scene node extensions. Also the dynamic shader context and material linking is not the most efficient solution. But sometimes (only sometimes ) that's the price for flexibility. Let's see what can be done there...

DOH!
That's why drawParticles comes up, the renderfunc iteration invokes every available render function, so there's an iteration for every single renderable type going across every single node. Didn't catch that until now.

Each species of renderable class could include a static vector< SceneNode* > and the SceneNode could define a "virtual void addToQueue()" and a virtual void "clearQueue()" that the renderable classes override to add themselves to their static queue. Could work for lights too, and avoids any registration funky-doo-wops.

Well, I whipped up a quickie.

SceneNode has acquired a virtual void addToQueue(SceneNode *tNode) {}; LightNode, ModelNode, TerrainNode, and EmitterNode all contain static vector<SceneNode*> renderQueue's and implement static void clearQueue(), void addToQueue(SceneNode *tNode) functions, and std::vector<SceneNode*>& getQueue() functions.

Node type registration expanded to take a queue clear function, and a vector fetch function (needed for sorting, lighting, and stuff).

I've made all the necessary modification to the renderer to properly shadow and handle light updates (** To my knowledge **), someone else will probably want to check through it though. There's some map iterations in regions such as sorting bbox.makeJoin() etc that may be able to be handled differently. Some of those may be able to generate a concatenated vector instead of iterating through each set.

Thanks for this patch. Without looking at the details of you modification, does it make a difference in performance? Doing a quick test on my notebook I couldn't figure out that well. The knight sample seems to be a bit faster (~5fps). The chicago sample with software skinning enabled may be about ~0.5fps faster. With hardware skinning it doesn't make any difference (most likely because this is limited by my GF7700). No difference for the terrain sample as well. But I guess I don't have the right setup for testing the possible improvements of this patch.

Ja, it slightly hampers testing when none of us even have the possibility of being CPU bound

_________________
Tristam MacDonald - [swiftcoding]

I've noticed it in my minimum frame rates. from 110 region to 121 at the lowest in Chicago, and the Knight never dropping below 600 where before it would be in the 500 range. Since it's basically an optimization for diversity inn scenes, that's where it's going to help.

@swiftcoder : Thanks for the tip, setting the function pointer to NULL added another bump to the performance


@marciano : The majority, in fact all of the time is being spent in AddNodes. Since I have optimizations turned on, it's not showing me the time spent in parseNodes, though I checked that even one interation of addNodes calls multiple recursive calls of parseNodes, which I assume is for each of the model joints. You mentioned that addNodes looks for the next available handle, would it not be straightforward to add a variable containing the next available free handle?

@AcidFaucet : I'm not able to use your patch, I get compilation errors in Renderer.cpp on undefined getRenderableQueue() . I tried fixing it myself, but couldn't, some help please

In which function(s) (or line #s) does it come up? I may be a chunk out of date with SVN.

Regardless of how many characters I put in the chicago demo, the init time isn't perceivably different. What I do notice is that the crowd simulation eats the framerate. Disabling it once the characters get into position brings framerates to an acceptable level during runtime. Sensible as with large numbers of characters, everything goes crazy. Are you sure that your crowd sim init code isn't a processor eating monster?

I get an error : class "SceneManager" has no member "getRenderableQueue"
on lines 696,698,805,807,1429,1431,1439,1660,1662,1664,1895,1897,1899
and the same for getLightQueue on lines 1095,1098,1200,1203,1441,1482,1484
all in egRenderer.cpp

I also get an error that MeshNode has no member "setVariable" in egMain.cpp

I'm using version 1.0.0Beta2, so dunno whether things have changed in the SVN checkout. Should I be using that?

Whoops my zip is bad, should have been egRenderer.cpp instead of egRendererBase.cpp that was stuck in it.

Meshnode problem is that I've got some other code that enables per object instance variables.
You can just comment out sections containing relevant errors about that ATM. I'll get a clean .patch file against the current version out shortly, in the mean time, here's egRenderer.cpp.

The patch is performing worse than swiftcoder's fix of commenting out particles. I agree that won't work in the general case, but in my case where I only have agents, I'm getting a performance of ~35-40fps using swiftcoder's method, versus ~25-30 fps with the patch, all for 1k agents.

Whatever you're profiling with, will it let you dump a text file, take a 'screenshot', or whatever with the information in it, including profiling of your application and its routines?

NOTE: Patch wasn't meant to solve your problem, while looking into your problem I noticed a hang-up for large scale projects, and spent an hour quickly prototyping a possible solution. It makes a difference in scenes with 10 emitters, 100 models, and a terrain; but can definitely be improved and may be the wrong approach.