Ogre Forums

In our application we have (aside from the main scene) a RTT that should only be updated once in a while, and it has its own SceneManager, with objects different from the main scene, and a compositor chain with some specialized post effects.

In Ogre 1.x we created a manual texture of type TU_RENDERTARGET, added a viewport to it, set setAutoUpdated(false), and called clear() and update() whenever we wanted to update it. During the application's "Edit Mode" this could happen every frame, but in "Normal Mode" this should typically only happen once by a change in setup/initialization.

How do we do this the best way in Ogre 2.1?

I am right now about to create a workspace for the TU_RENDERTARGET manual texture (which I still create using TextureManager::createManual), with a compositor node chain, and camera from the dedicated SceneManager. Are those steps ok?

But then I'm a bit stuck on how to update it on request, and not have it auto updated? Should I just invoke workspace->setEnabled(true) temporarily for one frame and then disable it? If so, is there are any performance cost of then afterwards having the idle disabled workspace?

(The texture is afterwards used as input to a compositor node post effect on the main scene for a "warping and blending" effect)

I looked at the Terra sample project. Maybe something similar to the implementation of Terra::createNormalTexture is what I should do.

Call setEnabled( false ); or create it with enabled=false when calling addWorkspace, and then proceed to _update it yourself manually: Usually this is all what's needed.

In case you're wondering about corner cases:
1. When it comes to RenderWindows it gets more tricky because they have to be swapped. And in the case of iOS, there may be some semaphores tied to it. It should be fine if you call update once per frame. If there's a missing function call you should mimic what CompositorManager::_update and _swapAllFinalTargets do

2. If you call A LOT of workspace updates, you will probably start getting out of memory problems because too many GPU operations get queued up. ParallaxCorrectedCubemap::updateExpensiveCollectedDirtyProbes runs into this problem, and thus the update procedure is slightly different to flush the driver out (and our internals as well).
Note that ParallaxCorrectedCubemap runs into this problem because it can easily accumulate 100s of passes: 6 faces per cubemap x num cubemap probes x (aroung 3 shadowmapping passes + 1 regular renderin pass) x num iterations.
But it's rare for a regular application to run into this problem.

Ok. Thanks for the feedback. I'll give it a try.

We won't need a lot of workspace updates, there should just be a few off-scene RTT at the same time.