Horde3D

Is there any way to create multiple scenes using Horde3D?

Basically I want to have one main world, and another which gets rendered to a texture and then is displayed in the main world. Doing this by separating them by some distance, but leaving them in one scene would be hacky, and would contain quite some caveats.

You can attatch several group nodes to the root that contain your scenes and can activate/deactivate them as required.

Doesn't this make any occlusion culling impossible?

In general, it shouldn't make any difference - each render target has to do occlusion culling seperately anyway. Not sure about Horde's implementation.

Occlusion culling is of rather dubious benefit on many types of scene, so you might not miss it anyway

_________________
Tristam MacDonald - [swiftcoding]

I think maybe he wants to render both scenes concurrently, so how would that work?

In your main render loop:

_________________
Tristam MacDonald - [swiftcoding]

I've used the suggested method with earlier version of horde3d and it worked perfectly.

But now I have a problem with hidden nodes(I'm using activate(false) to hide nodes). When I'm activating the root1 node it
activates every children, even the hidden nodes.

Any idea how to workaround this?

Thanks

The documentation says that h3dSetNodeActivation only affects the given node, not all the children as well, so I'd file that as a bug

The behavior that the children are affected as well is actually intended to keep a branch in a consistent state (if a parent is inactive, we don't have to visit the children). The documentation in the header was updated at some point but I guess the HTML file was not regenerated.

To solve your problem, I would suggest to introduce node flags. Something like h3dSetNodeFlags( node, H3DNodeFlags::NoDraw | H3DNodeFlags::NoCastShadow ). These flags would just affect a single node, although we could add an optional function parameter to apply the state recursively to all children.

I have some problem with this. The recursion of the whole subtree seems to be quite costly as I'm calling this per frame for each active camera. While I see that some kind of optimization is in the SetActivation function I think It can be quite confusing.

When I call SetActivation(false) for Root, Node1_1 isn't deactivated because Node1 is not active. I'm not sure if this is a problem as I dont know the visibility system works.


I like this alternative. Thanks. This could be extended with NoRayCast too.

Maybe I should write this into another thread, namely "Get rid of scenegraph"
I think that simple scenegraph (probably multiple ones for multiple scenes) that just simply contains a list of nodes would be much easier to use. With current hierarchy of nodes I have a problem that when I remove a node every children is removed also even if I still would like to use them. So In my wrapper I simply disallowed this deep hierarchy. The hieararchy is only Root->Scene->Object.
Marciano: Any info on the state of the work on "Get rid of scenegraph"? Thanks

I agree that an architecture that is less scene graph centric would avoid the mentioned performance overhead and complications. As removing the scene graph is quite a huge refactoring and will require changing the model format, I think we have to release a Beta5 first to keep compatibility with the current editor and to give people a chance to adopt the improved content pipeline.

I also like the idea of node flags, especially the example with the NoCastShadow flag, as for now you only can prevent shadow casting on a per-light or per-shader basis.

This flag system can also be used to enable/disable backface culling, because at the moment this can only be done on a per-context basis and as you cannot modify contexts by shader flags you have to write a speperate shader for two sided objects, despite the fact that two-sidedness is often model specific and can be handled in a shader quite easily by , possibly with a shader flag.

I'm sorry, if this is quite off-topic, but the mentioned flag-system is quite good for implementing this, in my opinion extremely missing, feature.

Hi Rauy, although "two-sided" is often most useful for special types of materials/shaders (e.g. vegetation), it can make sense to have it exposed in general as well. However, I would probably not begin mixing flags which are related to very different parts of the engine (culling/renderlists vs. render states). What could work though is if "two-sided" would be a special material flag which can overwrite the shader/FX culling mode.

That's also a good idea, as materials are model-specific anyway.