In 2.1 DepthTextures are a particular thing because of the following:
- Some depth textures are explicitly created for this purpose (i.e. shadow maps). You render depth only stuff, you sample depth from it.
- Most depth textures are "views" of depth buffers that were used during/alongisde a regular colour render.
- 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:
Code: Select all
TexturePtr tex = TextureManager::getSingleton().createManual( texName,
ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME,
TEX_TYPE_2D, width, height, depth = 1,
numMips = 0, PF_D32_FLOAT, TU_RENDERTARGET, 0,
hwGamma = false, fsaa, fsaaHint, fsaaExplicitResolve,
DepthBuffer::POOL_NON_SHAREABLE );
rt->setDepthBufferPool( DepthBuffer::POOL_NON_SHAREABLE );
rt->setDesiredDepthBufferFormat( PF_D32_FLOAT );
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:
Code: Select all
poolId = 32; //Arbitrary value. Cannot be 0. See reserved values at DepthBuffer::PoolId
colourRt->setPreferDepthTexture( true ); //Signal Ogre we want the colour RTT to use a depth buffer that can be used as depth texture
colourRt->setDesiredDepthBufferFormat( PF_D32_FLOAT ); //Ensure the colourRt uses the same depth format we want to sample from
colourRt->setDepthBufferPool( poolId );
//Create the depth buffer
TexturePtr tex = TextureManager::getSingleton().createManual( texName,
ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME,
TEX_TYPE_2D, colourRt->getWidth(), colourRt->getHeight(), depth = 1,
numMips = 0, PF_D32_FLOAT, TU_RENDERTARGET, 0,
hwGamma = false, fsaa, fsaaHint, fsaaExplicitResolve,
poolId );
rt->setDepthBufferPool( poolId );
rt->setDesiredDepthBufferFormat( PF_D32_FLOAT );
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.
