Hi. I am thinking a lot about my future scene graph design and I have an idea I'd like to share. Please tell me what you think about this. (note that the description below does not say about lighting - for simplicity) Let's say I have a material that need some dynamically created textures. Those textures could be planar reflections, cube map environment etc. The engine has a number of Recorders - every recorder is to generate one of those texture types, and have access to the whole scene graph and current camera. So I have Recorder for planar reflections, Recorder for cube maps etc.. The whole scene graph is rendered by Scene_Recorder. What it does is: 1. detect all visible objects 2. extract recorders from objects materials 3. process recorders (possible recursion - multi mirroring for example) 4. render objects Textures generated by recorders are taken from TexturesCache. Every texture in cache can be locked and unlocked. Textures in cache are locked when they are currently in use. They have also information about last recorder type that used it, generation time, camera state during generation, etc.. The key part is: Objects do not take ownership over textures (for caching) for longer than a single frame. Instead of that, Recorders search for textures in cache that would satisfy their needs (similar camera position etc.), and create new texture only if they don't find existing one - 'new textures' are also taken from the cache, but their image is generated all over. Why cache searching instead of permanent ownership? Imagine that you have multiple objects in distance, and each of them require the same dynamic texture type. You can easily group them by making only one recorder and set recorders's output texture to those objects material's. With this approach you don't have to deal with dynamic textures owned by those objects - I mean releasing them back to the cache. Another thing with grouping: imagine this situation A) you are at distance where objects do not get grouped B) you move away and objects get grouped C) you move back to position A In ownersip approach during B->C you would have to generate every dynamic texture all over. With my approach recorders just search cache and probably will find 'old' textures used by those objects. This approach can be easily extended for lighting and other effects. My main concern is about caching without taking ownership over textures (and insted of this searching for them in cache). This would involve some slight overhead, but I think would gratly simplify managing dynamic textures - grouping objects that are near of each other, adding new lights etc. ghostace

Thank for your reply.

I presented here only a small piece of the idea - just to make things simple. The main thing is that cache wouldn't be owned by any object between frames. Instead of this, textures in cache would have description of their content. When query'ing textures from cache, Recorders have two options:

1.
Just pick up a texture from cache and generate it's content.
2.
Pick texture and decide that it's content match the needs, so there is no need to generate it once again - just use it.


- Jason Z: -----------
Even so, if you can save some render passes by grouping objects together that would still be a good benefit. You'll have to let us know how it turns out!
----------------------

This is not just grouping passes, but grouping texture content generation. Like for reflections - the whole scene (culled and scissored) would be rendered to texture. When you need two reflections that are slightly diffrent you could group them, and have only one expensive generation instead of two.


- Jason Z: -----------
The only point that I would like to make is that if the textures are 'dynamic' then they will likely be generated quite often, if not every frame
----------------------

As far as I know caching is required (and often implemented) for systems to run fast. Limiting updated for let's say 0.1s interval would give you a huge fps boost. Other thing is that when objects that use dynamic textures are far away, the interval can be increased. With my approach optimizations like this seam easy to implement.




ghostace