Ogre 2.0 -> no manual RTT?

Discussion area about developing with Ogre-Next (2.1, 2.2 and beyond)


Post Reply
User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1894
Joined: Sun Mar 08, 2009 5:25 am
x 114

Ogre 2.0 -> no manual RTT?

Post by mkultra333 »

Looking at the thread http://www.ogre3d.org/forums/viewtopic.php?f=4&t=79456, I went and had a look the porting notes for 2.0.

I see this in the notes.
3.5 Where is RenderTarget::update? Why do I get errors in Viewport?
Advanced users are probably used to low level manipulation of RenderTargets. As such they're used to
setting up their custom Viewports and calling RenderTarget::update.
That is too low level. Instead, users are now encouraged to setup Compositor nodes and multiple
workspaces to perform rendering to multiple RTs, even if it's for your own custom stuff . The new
Compositor is much more flexible than the old one (which has been removed). See section about
Compositors for more information.
Viewports are no longer associated with cameras as they're now stateless (they used to cache the camera
currently in use) and a lot of settings they used to hold (like background colour, clear settings, etc) have been
moved to nodes. See CompositorPassClearDef and CompositorPassClear.
RenderTarget::update has disappeared because the render scene update has been split in two stages, cull
and render.
If you still insist in going low level, see the code on CompositorPassScene::execute to understand how to
prepare a RenderTarget and render it manually. But again, we insist you should try the Compositor.
First up, I apologize if I misunderstand the general thrust of this. The impression I get is that I'm now being forced to use compositors, and that the old style RTT is now impossible or much more difficult than it used to be.

That looks... just... terrible.

I do tonnes of manual RTT, I hate compositors, and I do my own culling. My rendering setup is very complex, with complex customized deferred shadowing with various effects. Plus I'm aimed at NVidia 3DVision compatibility. Compositors always messed things up. I render many, many passes for each frame to achieve a whole bunch of different effects. Handling this in code was fine, trying to get anything like this done with compositors and Ogre controlled culling sounds like a total nightmare.

I use RenderTarget::Update everywhere, all the time.

The thing I really liked about Ogre is that if parts of it didn't suit me, like the compositors and inbuilt shadows, I could easily just ignore them and go low level, do it myself with RTT. But it looks as if I'm literally told "That is too low level" and forced to use Compositors. Ugh. I really hate that idea. It basically means porting to 2.0 requires a complete rewrite of my rendering engine, trying to shoehorn it into a system I really don't think suits my project at all. Why on earth not let me just keep using render targets?

The other thing I hate about being forced to use compositors is that it makes Ogre even more alien to other APIs like OpenGL or DirectX. While I know the nitty gritty of doing RTT on Ogre, raw OpenGL or raw DirectX might be very different, the higher level concept is the same. But Compositors force the abstraction to be far more different, making it harder if I want to transfer Ogre skills to other APIs.

Again, apologies if I've misunderstood. It seems insane to me that you'd lock people out of easily doing RTT like they used to, so there's a good chance I have misunderstood. But statements like "But again, we insist you should try the Compositor" are pretty ominous.
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
x 216

Re: Ogre 2.0 -> no manual RTT?

Post by scrawl »

I'll have to agree with your there.
Also, I fail to see how the compositor is very useful for something you're just rendering once (or very infrequently). Game minimap, etc.
User avatar
Xavyiy
OGRE Expert User
OGRE Expert User
Posts: 847
Joined: Tue Apr 12, 2005 2:35 pm
Location: Albacete - Spain
x 87

Re: Ogre 2.0 -> no manual RTT?

Post by Xavyiy »

+1 to this from here. I use some manual RTTs too. :roll:
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Ogre 2.0 -> no manual RTT?

Post by dark_sylinc »

mkultra333 wrote:First up, I apologize if I misunderstand the general thrust of this. The impression I get is that I'm now being forced to use compositors, and that the old style RTT is now impossible or much more difficult than it used to be.
The answer is yes and no.
Yes, the idea is that we strongly suggest to use the compositors from now on.
And no, you're not exactly forced to.

The reason for this change is because:
  • The new compositor smartly handles useful information to avoid unnecessary traversal of the hierarchy multiple times, and for shadows (like receiver aabb)
  • Rendering was split into multiple phases (and other changes that I can't remember; in other words, update was split into multiple calls); thus compositor easies this.
  • The old compositor messed up rendering because the compositor itself was really messed up; it hooked itself to the regular rendering process using hacks over hacks
  • In the future the Compositor may issue GPU commands from within multiple threads; it is in the perfect position to solve all data dependencies.
mkultra333 wrote: I do tonnes of manual RTT, I hate compositors, and I do my own culling. My rendering setup is very complex, with complex customized deferred shadowing with various effects. Plus I'm aimed at NVidia 3DVision compatibility. Compositors always messed things up. I render many, many passes for each frame to achieve a whole bunch of different effects. Handling this in code was fine, trying to get anything like this done with compositors and Ogre controlled culling sounds like a total nightmare.
The new compositor is made to solve exactly these problems with little setup. My biggest mistake here is not having written yet samples that show how to do these advanced rendering with compositors.
But to each its own. If you're so eager to not use compositors and even if you were to look at (yet unwritten) the samples and decided you don't want to use it, look at what CompositorPassScene::clear & CompositorPassScene::update are doing, which is basically the replacement of "RenderTarget::update".

Another solution is to create a Workspace (not to be confused with a WorkspaceDef) for each manually created RTT (set that RTT as output for the Workspace), disable it, and manually update that workspace; that should mimic the 1.9 style of doing things very closely (since you will be manually updating an RTT that you've manually created; you'll just will be calling workspace->update() instead of rtt->update() ).
mkultra333 wrote: Again, apologies if I've misunderstood. It seems insane to me that you'd lock people out of easily doing RTT like they used to, so there's a good chance I have misunderstood. But statements like "But again, we insist you should try the Compositor" are pretty ominous.
You understood correctly, we indeed insist on trying the compositor. But if you don't like it, we won't force you ;)
I'll update the doc to reflect this.

Edit: I've updated the manual. Check point 3.6
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Ogre 2.0 -> no manual RTT?

Post by dark_sylinc »

scrawl wrote:I'll have to agree with your there.
Also, I fail to see how the compositor is very useful for something you're just rendering once (or very infrequently). Game minimap, etc.
Stop thinking of the Compositor as the way to make shiny effects (i.e. Bloom), but rather the way of telling Ogre how you want to render the scene.

In fact, the Compositor may be much lower level than you think. The problem with 1.9 is that you could get multiple unwanted buffer clears between passes (or even consecutive clears) if you weren't carefull (or multiple wasteful Viewport instances) because automatic management could get in the way of manual updates or sometimes they were just Ogre bugs. This was with or without the compositor. And the way it used to discard skipped Render Queues was very inefficient too.

With the new compositor, you have to explicitly tell Ogre you want to do clears, or renders; and which RQs to include. And it is easy to issue the same commands to multiple viewports or even windows with only a few lines of code, thus making stereo effects and multimonitor setups much easier.
User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1894
Joined: Sun Mar 08, 2009 5:25 am
x 114

Re: Ogre 2.0 -> no manual RTT?

Post by mkultra333 »

Hehe, you're probably thinking "Jeez, just learn to do it the new way, it'll work!" but I'm thinking "Jeez, just let me do it the old way, it works!"

The thing I always hated about compositors (apart from the fact that they often didn't work) was that it added an extra level of complexity. If I do all my updating manually with a bunch of RTT, its just "C++ -> Material", but if I use compositors it's "C++ -> Compositor script -> Material". That's an extra layer of padding that I can mess up, and an extra layer that I have to use a different logical/coding style in.

The main rendering function in my project, "UpdateRenderTargets", goes through a long list of procedures as it builds up to the final image. Lots and lots of if/else. Are they only rendering a wireframe? Does this update include ambient light or not? Are they using edge-dejagging, motion blur, or both? Does this update have glass in the scene, is the glass going to distort the things behind it, is the glass being hit by a spotlight? That's on top of just doing the MRT, deferred point light and deferred spotlights.

Lots and lots of rendertargets, some being reused over and over (lo-res blur surfaces for example), some occasionally being reused (a "behind glass colour tint and glass depth" render might be useful for half the render, but reused at the end for something else), and some being pretty static the entire frame (the depth from the MRT tends to be useful the entire life of the frame render, for instance.)

Controlling this in code was ideal from both a logical perspective (easier to keep track and see what is going on, because all the logic is in just two places, the UpdateRenderTarget function and the materials) and from a render target memory and speed perspective (I know exactly when I should and shouldn't re-use or clear a render target, exactly when I should flip the buffer or leave it for more passes to come.) Sometimes the final scene might end up on different surfaces before final output, depending on the path taken. Under different circumstances, different render targets feed into each other differently to save on unnecessary passes.

So this gets pretty complicated and is all controlled at a fine level, which is why doing it in code and avoiding any unnecessary levels of complexity are paramount. It also makes it easier to experiment. I'd hate to have to do all that with Compositor scripts in the middle.

I had a look at your new Point 3.6. Hopefully it will indeed be possible to use this as a simple new way of doing the old style RTT.

BUT...

I just hope you really do take seriously that sometimes, some of us would MUCH prefer to directly control render surface drawing without compositors. That the new system is, for the manual RTT renderer, at least as powerful, versatile and easy to use as it used to be. RTT is possibly the single most powerful technique a real-time graphics programmer can use, it's the basis of almost every effect and visual out there, so the road blocks and jump-hoops you need to wrangle with in order to use it should be minimal. For me, compositors were always just an extra, unnecessary hoop.

EDIT: Had another look at point 3.6, and it says this:
Create one Workspace for each RTT: Manually create the RTT and create a Workspace instance
that uses this RTT as output. Now disable the workspace so that it's not automatically updated for
you. Call Workspace::update as if you were using RenderTarget::update
Just to check, can I change the RTT input to a workspace on the fly? That's the kind of thing I do all the time in my current setup, changing which RTT gets rendered onto another RTT.
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Ogre 2.0 -> no manual RTT?

Post by dark_sylinc »

In retrospective, I shouldn't have used the word compositor, and perhaps "Rendering Commander" or the likes.
The main rendering function in my project, "UpdateRenderTargets", goes through a long list of procedures as it builds up to the final image. Lots and lots of if/else. Are they only rendering a wireframe? Does this update include ambient light or not? Are they using edge-dejagging, motion blur, or both?
Does this update have glass in the scene, is the glass going to distort the things behind it, is the glass being hit by a spotlight? That's on top of just doing the MRT, deferred point light and deferred spotlights.
Sounds like when done the "Ogre 2.0 way"; this code would create/modify the Definitions on the fly (instead of using scripts). CompositorWorkspaceDef, CompositorNodeDef, CompositorPassSceneDef, etc and then instantiate.

Then on the instances (i.e. Workspace and/or CompositorNode) change the channel connections on the fly. That would totally (and elegantly) achieve what you describe while allowing the Compositor do it's optimization jobs, including future proof for multithreading (due to the immaturity of the code, right now live editing of a Workspace and Compositor Nodes at run time is not entirely possible due to many members not being exposed plus some possible stability issues, but not because it's not planned; it's just your case is possibly too complex to be handled in the first alpha release).

It's like playing with a TV, a projector, and 3 DVD players: You'll select if a single DVD player outputs to both the TV and the projector, or if each DVD player outputs to the TV and the other to the projector (and you choose which player is left out), or if the DVD is plugged to the other DVD; or if the TV output is plugged to the projector's input. On top of that, all DVD players can read from the same disk to avoid having to buy three disks (in case you want to play the same movie).
Lots and lots of rendertargets, some being reused over and over (lo-res blur surfaces for example), some occasionally being reused (a "behind glass colour tint and glass depth" render might be useful for half the render, but reused at the end for something else), and some being pretty static the entire frame (the depth from the MRT tends to be useful the entire life of the frame render, for instance.)
The new compositor allows exactly this (use of global RTTs and/or put the input RTT as output as well so that they can be reused). The old compositor had a messy way of reusing RTTs, or just resign yourself to waste a lot of vram.
Just to check, can I change the RTT input to a workspace on the fly? That's the kind of thing I do all the time in my current setup, changing which RTT gets rendered onto another RTT.
I would like to know a bit more context about that; because I'm not sure what you mean by that.
User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1894
Joined: Sun Mar 08, 2009 5:25 am
x 114

Re: Ogre 2.0 -> no manual RTT?

Post by mkultra333 »

I would like to know a bit more context about that; because I'm not sure what you mean by that.
As an example, a point is reached in my rendering process where either dejagging and motion blur is applied, or it isn't. Depending on this, the render ends up on one of two surfaces, DfShMix or DfShTemp. From my comments:

Code: Select all

// now DfShMix has the final surface if there is no dejagging or motionblur,
// and DfShTemp has the final surface if there is some dejagging or motionblur.
The reason for this is simple. If there's no need for further processing, then DfShMix is ready to go as it is. Otherwise DfShMix is used as the input to the defag/motionblur process and output to DfShTemp. I could make thing simple by re-rendering DfShTemp back on DfShMix, but why waste the batches and fill time if I don't need to?

But now there's further processing down the line, and still the final output screen to be rendered. If I haven't done any motion blur, then those processes will use DfShMix as their input, but if I have done motion blur then DfShTemp will be the input. So there's code like this:

Code: Select all

		if(m_nDejag==0)
			miniScreen_DfShMaster->setMaterial("HDR_MixToBlurA") ; 
		else
			miniScreen_DfShMaster->setMaterial("HDR_TempToBlurA") ; 

		// put up a fullscreen quad so BlurA has some UV coordinates.
		m_pSceneMgr->getRootSceneNode()->addChild(miniScreenNode_DfShMaster) ;

		// render DfShMix (or DfShTemp) to BlurA
		renderTexture_BlurA->update(true) ;
I'm alternately rendering either DfShMix or DfShTemp onto BlurA, depending on whether I'm using the original DfShMix or the dejagged, motionblurred DfShTemp.

That's what I mean by " change the RTT input to a workspace on the fly." In the current system (1.8.1), what I'm doing is putting up a full screen quad, setting it to a material that either uses the DfShMix texture or DfShTemp texture, and then rendering that onto BlurA.

How does this work with the "Manually create the RTT and create a Workspace instance that uses this RTT as output" system mentioned in point 3.6?

(Actually I may have mis-understood, I read that as "uses this RTT as input" which is wrong. So I'm guessing it's still fine to alter what gets rendered, models or quads with variable materials, onto any RTT, at any time.)
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Ogre 2.0 -> no manual RTT?

Post by dark_sylinc »

First, the more you describe, the more I think "this is EXACTLY why the new compositor was written".
All this management, it was a lot of C++ code or face frustration in 1.9; plus rendering using m_pSceneMgr->getRootSceneNode()->addChild for the quads was very, very inefficient.

Second,
mkultra333 wrote:How does this work with the "Manually create the RTT and create a Workspace instance that uses this RTT as output" system mentioned in point 3.6?

(Actually I may have mis-understood, I read that as "uses this RTT as input" which is wrong. So I'm guessing it's still fine to alter what gets rendered, models or quads with variable materials, onto any RTT, at any time.)
Yup, that's what puzzled me. I said output, not input. By "RTT as output" it means the workspace will render to that final RTT.
As for inputs, there can be any source (created by the compositor, or manually set to the material)

I see many of your questions are caused by the lack of examples to toy with. There are many valid ways to use the Compositor and the only one being shown currently is the crappiest of all (createBasicCompositorDef), that doesn't really tell anything; and without something to test, you miss the details leading you to a bit of anxiety.
I'll suggest to wait a bit until some samples are written or try experimenting with it.
User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1894
Joined: Sun Mar 08, 2009 5:25 am
x 114

Re: Ogre 2.0 -> no manual RTT?

Post by mkultra333 »

I see many of your questions are caused by the lack of examples to toy with. There are many valid ways to use the Compositor and the only one being shown currently is the crappiest of all (createBasicCompositorDef), that doesn't really tell anything; and without something to test, you miss the details leading you to a bit of anxiety.
Ok, I'll take your word for it. :)

Just the way you currently have the document worded, it seems to be really discouraging the manual usage of RTT, even if you do it via the new compositors. Perhaps you don't need to be so discouraging if it's actually no big deal to just do the old style RTT in a new way.
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1894
Joined: Sun Mar 08, 2009 5:25 am
x 114

Re: Ogre 2.0 -> no manual RTT?

Post by mkultra333 »

First, the more you describe, the more I think "this is EXACTLY why the new compositor was written".
All this management, it was a lot of C++ code or face frustration in 1.9
Just to clarify on that point, I personally much prefer C++ code to using a compositor script. As I said, for me and a complex rendering formula, "C++ -> Material" is way easier to work with than "C++ -> Compositor Script -> Material"

BTW, I do appreciate the work you're putting into the new engine. Obviously it had to change to keep up with progress in the field, so I don't want to seem like I'm terrified of all change. Just terrified of losing control of RTT.
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
User avatar
Zonder
Ogre Magi
Posts: 1168
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 73

Re: Ogre 2.0 -> no manual RTT?

Post by Zonder »

mkultra333 wrote:
First, the more you describe, the more I think "this is EXACTLY why the new compositor was written".
All this management, it was a lot of C++ code or face frustration in 1.9
Just to clarify on that point, I personally much prefer C++ code to using a compositor script. As I said, for me and a complex rendering formula, "C++ -> Material" is way easier to work with than "C++ -> Compositor Script -> Material"

BTW, I do appreciate the work you're putting into the new engine. Obviously it had to change to keep up with progress in the field, so I don't want to seem like I'm terrified of all change. Just terrified of losing control of RTT.
It is probably worth an investigation though as when the compositors are threaded and more optimized your pipeline will be a lot faster.
There are 10 types of people in the world: Those who understand binary, and those who don't...
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Ogre 2.0 -> no manual RTT?

Post by dark_sylinc »

It's done.

Many Compositor samples are ready, showing how to use it (samples that need the compositor but haven't been ported yet are DeferredShading, SSAO & Depth Shadow mapping)

Read the samples' description (in SampleBrowser) as well as the demos' code comments, they both contain A LOT of useful information:
  • "Compositor" demo shows how to setup a postprocessing system using either scripts or pure raw C++. It also shows a clever way on how to enable and disable nodes selectively without any performance impact (I say "clever way" because there is no "right" way to do it, there are many ways to do it, depending on your pipeline and needs).
  • "Fresnel" demo shows how to drive the Compositor to create 2 RTTs and render refraction and reflection passes, all within compositors (no manual thing). For renderings like this, this is the recommended way.
  • "Cubemap" demo shows how to manually create an RTT and manually update the workspace. For things like IBL probes, this is the recommended way.
As the sample's description says, in Cubemap we use a few scripts "as templates" to create Nodes and Passes (because they're waaaay easier to write and maintain than C++ code) but then in C++ we put them together into a workspace.

This is probably the best approach for those seeking to drive the Compositor from C++: Write a few lines of code in scripts, then use them as building blocks (just as you can create a Material in a script, and later clone it and heavily modify it).
You can of course, go masochist way and use no scripts at all.
User avatar
madmarx
OGRE Expert User
OGRE Expert User
Posts: 1671
Joined: Mon Jan 21, 2008 10:26 pm
x 50

Re: Ogre 2.0 -> no manual RTT?

Post by madmarx »

You can of course, go masochist way and use no scripts at all.
No masochism here, I might prefer my compiled-checked-c++ over scripts (and the resources management it needs) :) . DSEL can be funny to use too.
Anyway, I am just passing by, saying thanks. I use manual RTT a lot, and even manual render call too, I will probably check this next year (only sadly). Providing examples is really great.
Tutorials + Ogre searchable API + more for Ogre1.7 : http://sourceforge.net/projects/so3dtools/
Corresponding thread : http://www.ogre3d.org/forums/viewtopic. ... 93&start=0
Post Reply