SceneManager changes

· by Steve · Read in about 2 min · (391 Words)

I’ve bitten the bullet, and have taken the opportunity raised by writing my version of zeroskills patch on enumerating SceneManagers to set right a few things in SceneManager in general. One of the goals is to make it safe to use more than one SceneManager at once, particularly for rendering subscenes using different techniques. In theory this has always been possible, but in practice some optimisations and assumptions put a few hurdles in the way. I’m resolving those things, as well as setting things up so that you can use more than one SceneManager of the same type, should you want to, to perform easy, coarse, manual scene partitioning. This has turned up as a feature request a number of times, and whilst you can manage this within an existing SceneManager, it’s kind of awkward, especially when it comes to plugging in specialised managers. By allowing top-level partitioning this way, it has far fewer combinational problems and the whole setup is cleaner.

I’ve also resolved the inconsistency that all MovableObject instances were created via SceneManager, except ParticleSystem which was held in ParticleManager. Now, particle systems are plugged in like every other factory and are thus owned by a single scene manager, making cleanup when using multiple subscenes much simpler. This is interface breaking, but not hard to adapt to since it’s more consistent.

Once I’ve done the manager enumeration, I’ll probably move back to finishing the compositor scripting. I have a few optimisation thoughts for that, especially when it comes to avoiding the scene parse when updating targets entirely used for post processing effects. I really, really want to find some time to put in a HDR sample - we’ve supported it for 18 months after all, it really should be shown off. No point doing that without the compositor script done though. Also, it would be useful to have implemented the ‘material scheme’ idea I have, which lets you switch wholesale between material techniques for different targets. This is handy for if you want to seamlessly have a HDR and non-HDR pipeline for example, since the HDR render requires unclamped shader output. Gah, why do I keep adding things on to this todo list of mine?

PS: apologies to friends who read this blog and don’t understand what the hell I’m wittering on about. 😀It makes sense to me, honest.