Ogre Forums

Hi,

I am trying to dig into compositors but still floating between "Aha, I think I've got this" and "Crap, I don't understand" depending on the situation...

Currently I have compositor setup similar to dynamic cubemap sample and it works (I define and create a cubemap texture in the code, pass it to the compositor as an input, some nodes write to it and then I pass it to next pass inside custom HLMS's fillBuffersFor as CbTexture() command which make it accessible to my shaders). So far so good.

So now I want to have depth buffer information in my shaders. From the examples and the doc I think I've got how to define depth texture in the compositor, but as I understand they are kinda special and represent a view to an actual depth buffer, so the same trick with defining such texture first in the code and passing it to the compositor wouldn't work. All the examples are using low level materials, but how can I pass the depth texture to HLMS? I've tried to define everything in the compositor and then call SceneManager::getCompositorTextures() in preparePassHash and it seems to give me something, but the texture content din't look like an actual depth buffer to me. So I just want to confirm if I am on the right track or doing something wrong? Did anybody pass a depth texture to HLMS successfully and want to share an example?

And speaking of examples. TutorialDistortion doesn't do distortion when I run it (tried it on Intel UHD first and thought maybe it's absence of a proper graphics but it's the same when I run it at on NVIDIA card). I've seen the video how it's supposed to look and it doesn't work the same for me. Is it me or some of the changes in Ogre which broke it? In other words - can someone confirm that TutorialDistortion works as intended in relatively recent Ogre 2.1?

Hrenli wrote: Fri Nov 16, 2018 10:49 am can someone confirm that TutorialDistortion works as intended in relatively recent Ogre 2.1?

I've using the version just after merging the hlms disk cache. I can run the sample tomorrow and tell you the result if no one did this before me

However, I strongly suggest you try Ogre 2.2 instead because it's much more flexible/capable when doing texture related things and is the future of Ogre 2.x. I still needs some polishing (mostly testing/fixing complex streaming/state transition scenarios) now, but I expect it to be production-ready before Xmas

In 2.1 DepthTextures are a particular thing because of the following:

1. Some depth textures are explicitly created for this purpose (i.e. shadow maps). You render depth only stuff, you sample depth from it.
2. Most depth textures are "views" of depth buffers that were used during/alongisde a regular colour render.
3. Internally speaking, the data does not actually live in the Texture class, but rather in the DepthBuffer class, which is associated to that texture (this is regardless of whether it's point 1 or 2).

So if you're creating a depth texture that fails into category #2, it is perfectly possible to create (whether by accident or on purpose) two depth textures that internally they point to the same depth buffer.

But when it comes to binding this depth buffer as a texture for shaders, they're just like any regular texture.

When it boils down to code, the first ones are created via the following: The "DepthBuffer::POOL_NON_SHAREABLE" is what tells Ogre that you want this depth buffer to never be shared with anyone. The depth buffer belongs to that texture, and that texture only. Useful for depth-only rendering (i.e. shadowmaps)

To create the second kind, the code is the following: In this snippet we instruct the colour RTT to use the same depth settings as the depth buffer we're "creating". I use quotes because we're not creating a depth buffer, we're just creating a view over a shared pool. If the settings don't match exactly, then we may end up looking at a different pool, and thus the depth texture view points to a different depth buffer, one that was not used by colourRt.

The default pool ID for all RTTs is '1'. Using that pool is possible but unless you have total awareness of what's going on in your pipeline, it's like putting your hand in a dirty lake and you don't know what you'll catch.
Using an arbitrary pool ID lets you ensure that a given colour RTT and a depth texture you create should be the same, and will not be reused by some other colour RTT you have laying around (which can be very disorienting if an unrelated render to a colour rtt accidentally overwrites what was in your depth texture).

The Compositor takes care of most of this so you don't have to worry about it. Samples such as ScreenSpaceReflectionsRenderingNode in ScreenSpaceReflections.compositor, StencilTestNode in StencilTest.compositor, Tutorial_ReconstructPosFromDepthNode in Tutorial_ReconstructPosFromDepth.compositor, SmaaNode in SMAA.compositor and SSAO_RenderNode in SSAO_HS.compositor show how to do it via compositor scripts.

When creating the COLOUR RTT from code, the key parts for depth textures to work are in the calls to setPreferDepthTexture, setDesiredDepthBufferFormat and setDepthBufferPool.

Hrenli wrote: Fri Nov 16, 2018 10:49 am can someone confirm that TutorialDistortion works as intended in relatively recent Ogre 2.1?

I can't see any Distortion too (using a VERY recent Ogre 2.1 last week). So I guess it's indeed broken now.

dark_sylinc wrote: Fri Nov 16, 2018 9:11 pmWhen creating the COLOUR RTT from code, the key parts for depth textures to work are in the calls to setPreferDepthTexture, setDesiredDepthBufferFormat and setDepthBufferPool.

Aha! That was probably the most missing bit of information for me, thanks (and for the snippets too)!