Horde3D

Because my characters are mostly boxes (deliberately), I get some pretty nasty banding with the object self shadowing (as you would expect). Is there a way to turn off self shadowing? I can live with banding from one objects shadow falling on another, but prefer not to self shadow the characters normally.

Ta.

Phil.

Hmm, thinking about this, its not really something you can easily turn off is it

I'm pretty sure Ogre has an option per node to cast/recieve shadows. But I wonder if that even applies to thier shadow map (I use stencil buffer shadows with ogre, so didnt really think about this).

I guess I'll have a look at the materials. Maybe I can disable shadow recieving on the characters and just have the shadow on the floor to fix them in place.

Ok, here's what I'm thinking:

I use a new shaderflag _F06_Noshadow

I create a new calcPhongSpotLightNoShadow in fragLighting.xml

I #ifdef the code to use the new spotlighting func in model.shader

That way I can set the shaderflag in my materials to ignore shadows being cast on my characters, but they still cast them themselves. It might look a bit weird when they are close together, but the default case should look nicer I think. Am I wrong?

Hmm, now there's an issue

It worked as expected with forward rendering. But of course it completely doesnt work on deferred rendering because there is no context for the dropping of the shadow map contribution to the lighting stage.

I guess I'll need to rethink things a tad here.

Just so its clear what I'm trying to do, I'm trying to create a scene with many hundreds of characters, all made of boxes. Each character is made of head, body, arms and legs as expected. Each of the head, arms, legs and body have seperate materials, because I want to swap out the textures used per character. So for instance you might have user-defined materials for the body, arms and legs, with a supplied head. Or you might have a user defined head on a supplied body/legs/arms. Its basically user created content in the form of textures.

feels like the wrong place for this thread now. Can we move it?

Disabling self-shadowing is tricky since it is not a special feature but happens implicitely due to the way our shadow maps work. Entirely disabling shadows for a character would be easier.

However, have you already tried to tweak the shadow bias? It is exposed as a light node parameter. For higher quality you should use the ddx/ddy based bias calculation. It is implemented in the shader context of model.shader but commented out since it requires SM3 hardware.

Tweaking the shadow bias fixed things. Looks a lot nicer now (none of the horrible banding across the faces).

still, the batch count is pretty damn high and rendering pretty damn slow for the number of poly's. So batching is making a huge impact (as one would expect).

I wonder how best to recreate the mesh to allow decent batching. I need to be able to swap the submesh textures. Its a bit surprising that submesh parts arent renderered in batches, but then I guess getting the transforms for them and them looking like skinned meshes doesnt help.

If you just want to disable shadowing for a given set of nodes, it should be a simple enough modification to change the shadow map rendering to use only a certain group of nodes (i.e. '~shadowcasters').

_________________
Tristam MacDonald - [swiftcoding]

Automatic batching is by far not a trivial thing. It can require reordering or merging of index buffers and the generation of texture atlases. Using skinned meshes complicates the matter even more. To draw several characters in a single batch, skeletons would need to be merged which would require updates of the joint index vertex data which is dangerous when done per frame since it could introduce pipeline stalls. And of course there is just a limited number of registers available for the joints.
I think batching should be addressed in a layer above Horde where more domain/application-specific information is available.

Drawcall performance is a D3D9 problem and does not exist to that degree in OpenGL (and D3D10). It is mainly due to the fact that parts of the D3D9 driver are running in kernel mode and other parts in user mode and switching between those is expensive. Of course, there's also some general API overhead in OpenGL and changing states can require a lot of internal reconfiguration in the driver. That's why we should enhance the render state sorting in Horde to help improving performance. On the other hand, if you just sort by state, you could get more overdraw and get fillrate limited since you have less benefit from the early-z rejection mechanisms which works best with geometry sorted by depth. And there is even more things to consider, so all in all it is not trivial

Can you give some more details about your scene (number of static and animated objects, light sources, etc.) and the current performance (FPS for which hardware spec)? Do you think you are rather GPU limited at the moment or is rather the animation, scene management and drawcall overhead the problem?

I'm using the chicago sample, with 100 chars.

I'm using the mulder box guy I sent you. Basically he's made up of 6 boxes, so 6x12 triangles per character. He's got 4 textures that are all 256 or 512 pot jpgs. Each character is "skinned" rigidly against a corresponding bone. A single animation clip is being played.

From what I can discern, he's basically creating around 12 batches.

I'm getting around 60fps in debug, with 100 chars in the chicago scene, which is at around 30k triangles and around 1600 batches using forward. Gets around 80fps with 1200 batches in deferred.

I'd expect a much higher framerate even in debug for 30k triangles on that card.

I know its really down to optimising the scene and all, but that then suggests that scenegraphs arent necassarily the way to go (as my old mucker Tom Forsythe pointed out on his blog a while ago). I really want to get around 300 or so box-chars on screen at a reasonable framerate (enough to give me time to run the physics and ai, the latter being the focus of the work).

If I'm going to have to hand-batch some of this stuff, I might as well just write a game specific renderer. Which might end up being my best option. But I was hopeful that the general case of a scenegraph might work. But its hard to tell where the time is being eaten.

Does that mean you are compiling in debug mode? Because bets are that you are solidly CPU bound at the moment, and optimisation can only help.

_________________
Tristam MacDonald - [swiftcoding]

Try running in release mode. This can make a huge difference.

I know but I have to debug the game too

My point is that even IN debug mode, those framerates are lower than I would expect.

I need enough headroom from a debug perspective to have the characters moving AND time to run the AI logic and physics while keeping a decent 30-60fps. If I'm getting close to that without any logic running I'm worried.

You can keep the debug symbols and still enable optimisation - I would suggest giving that a try.
if you are CPU-bound, your framerates in debug mode could be *a lot* lower than in release mode.

_________________
Tristam MacDonald - [swiftcoding]

Yeah I actually do this with all my game code - release is optimised but still has debug symbols in case I need to check something.

Also, I generally don't need to debug Horde, so my debug game code often links to a release version of horde.
If you're CPU bound, then you're going to get the same frame-rate with 10k or 100k triangles