Confused about addNodeAlias

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


Post Reply
jwwalker
Goblin
Posts: 224
Joined: Thu Aug 12, 2021 10:06 pm
Location: San Diego, CA, USA
x 17
Contact:

Confused about addNodeAlias

Post by jwwalker »

I'm confused about the use of CompositorWorkspaceDef::addNodeAlias. The docs say it creates an independent instance of the same node, which sounds like something I might want, but what can I do with it? It apparently doesn't create a new CompositorNodeDef, in fact if I pass the alias ID to CompositorManager2::getNodeDefinition, it throws an exception.

Maybe I should explain why I'm thinking I might need this, which might be on the wrong track. I wanted to try CompositorNodeDef::addRenderTextureView to associate a depth buffer and a color buffer as my rendering target, but if that's modifying the CompositorNodeDef, maybe I shouldn't do it to a node definition that I may want to re-use in another workspace instance.

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Confused about addNodeAlias

Post by dark_sylinc »

Hi.

It doesn't clone an existing CompositorNodeDef.

It means that when creating a CompositorWorkspace (not CompositorWorkspaceDef) then two CompositorNode will be created sharing the same CompositorNodeDef.

This is particularly useful if the CompositorNodeDef has locally defined textures and you want to preserve their contents between frames (or you're rendering entirely different stuff into each, toggling stuff via compositor listeners)

I wanted to try CompositorNodeDef::addRenderTextureView to associate a depth buffer and a color buffer as my rendering target, but if that's modifying the CompositorNodeDef, maybe I shouldn't do it to a node definition that I may want to re-use in another workspace instance.

Could you explain at a higher level what you're trying to achieve?

jwwalker
Goblin
Posts: 224
Joined: Thu Aug 12, 2021 10:06 pm
Location: San Diego, CA, USA
x 17
Contact:

Re: Confused about addNodeAlias

Post by jwwalker »

dark_sylinc wrote: Sun Jul 03, 2022 12:01 am

Could you explain at a higher level what you're trying to achieve?

I'll try. I have various rendering targets, some of which come and go, each with their own compositing workspace instance. Some end up at a Window, and some end up at an offscreen texture. I often need access to the depth buffer. In the window case, I can use Window::getDepthBuffer, no problem. In the offscreen case, I have been using RenderSystem::getDepthBufferFor, which works, but you told me in another thread that it's not the recommended way of doing things, so I was trying to figure out the alternative.

Now, in the immediate problem that led to this, I'm trying to do a two-phase process. In the first phase, I render a scene off-screen. In the second phase, which may be targeted on-screen or off-screen, I render a full-screen Rectangle2D that uses a Material. Both the color texture and the depth texture produced in the first phase are passed as inputs to the Material. If the second phase targets a Window, then it all seems to work as planned. But if the second phase renders off screen, it behaves as if the depth texture input of the Material was all black. (The color texture input is definitely getting through to the Material's fragment shader. I've tried dumping the depth texture to a file, and it's definitely not really all black.) I don't have much idea why things go wrong in the off-screen case, but I thought it might have something to do with the nonstandard way I set up the depth buffer in the first phase.

jwwalker
Goblin
Posts: 224
Joined: Thu Aug 12, 2021 10:06 pm
Location: San Diego, CA, USA
x 17
Contact:

Re: Confused about addNodeAlias

Post by jwwalker »

While I was waiting for more help or inspiration on the questions here, I decided to try a less programmatic approach, writing my first compositor script. Much to my surprise, it worked, pretty much right away. So my question about node aliases has become moot. Here's the script, please let me know if anything looks wrong or inefficient. I can't find any discussion of that rtv block in the Ogre manual, I'm just imitating other scripts.

Code: Select all

compositor_node JWDoF_Node
{
    in 0 renderwindow
    texture firstPass target_width target_height target_format
    texture firstDepth target_width target_height PFG_D32_FLOAT
    
    rtv firstPass
    {
        depth firstDepth
    }
 
    target firstPass
    {
        pass clear
        {
            colour_value 0.6 0 0.6 1
        }
        pass render_scene
        {
            rq_first    0
            rq_last     max
        }
    }
    
    target renderwindow
    {
        pass clear {}
        pass render_quad
        {
            material JWDepthOfField
            input 0 firstDepth
            input 1 firstPass
        }
    }
}
 
workspace JWDoF_Workspace
{
    connect_output JWDoF_Node 0
}
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Confused about addNodeAlias

Post by dark_sylinc »

jwwalker wrote: Tue Jul 05, 2022 1:10 am

While I was waiting for more help or inspiration on the questions here, I decided to try a less programmatic approach, writing my first compositor script. Much to my surprise, it worked, pretty much right away. So my question about node aliases has become moot.

Great!

In my experience even highly configurable (from C++) compositor setups are often arranged by having "baked" nodes and then modifying them from C++ mix and matching to achieve what you need.

jwwalker wrote: Tue Jul 05, 2022 1:10 am

Here's the script, please let me know if anything looks wrong or inefficient. I can't find any discussion of that rtv block in the Ogre manual, I'm just imitating other scripts.

The script is alright. I have two suggestions:

1- Merge your clear passes for better tiler friendliness (I'm skipping irrelevant parts):

Code: Select all

    target firstPass
    {
        pass render_scene
        {
            load
            {
		all				clear
		clear_colour	0.2 0.4 0.6 1
            }
            rq_first    0
            rq_last     max
        }
    }
    
target renderwindow { pass render_quad { load { all clear clear_colour 0.2 0.4 0.6 1 } material JWDepthOfField input 0 firstDepth input 1 firstPass } }

That is, the clear pass was removed and moved into the "load" section. This is more tiler friendly (e.g. TBDRs like mobile and Apple M1, and hybrid tilers like NVIDIA post-Maxwell and AMD post-Vega GPUs)

2- Consider using dont_care if it applies to you.
For example if I can assume:

  1. firstPass will render to the whole screen (no pixel is left untouched by the triangles) with fully opaque triangles (i.e. alpha blending over the clear colour breaks this assumption).

  2. renderwindow will render to the whole screen (same as assumption #1)

  3. renderwindow doesn't need the depth buffer contents (i.e. the render_quad doesn't read renderwindow's depth buffer at all)

  4. Even if assumption #3 isn't true, the depth buffer values written by renderwindow don't matter after this pass

Then we can convert your script to the following:

Code: Select all

    target firstPass
    {
        pass render_scene
        {
            load
            {
		all		clear         // We still the depth (& possibly stencil) buffer to be cleared
		colour	dont_care // See assumption #1. We are now overriding the colour section (since it was just set to clear in previous line)
            }
            rq_first    0
            rq_last     max
        }
    }
    
target renderwindow { pass render_quad { load { all dont_care // See assumption #2 & #3 } store { depth_stencil dont_care // See assumption #4 } material JWDepthOfField input 0 firstDepth input 1 firstPass } }

If you are using them wrong, RenderDoc is also great for debugging incorrect usage of dont_care:
Image

In this example, the depth value was set to store -> depth dont_care; and later we read from it; which means there's a bug (it should've been set to store -> depth = store_or_resolve).

jwwalker
Goblin
Posts: 224
Joined: Thu Aug 12, 2021 10:06 pm
Location: San Diego, CA, USA
x 17
Contact:

Re: Confused about addNodeAlias

Post by jwwalker »

Thanks, that's very helpful. I think you made one minor mistake: When I tried using depth_stencil in a store clause, I got an error message about an unexpected token. And if I search the sample compositor scripts, I see depth_stencil in rtv clauses but not in store clauses.

I'm guessing that the Manual is out of date in the Simple bootstrap for beginners section, when it says that createBasicWorkspaceDef is equivalent to a script:

Code: Select all

compositor_node MyOwnWorkspace_Node
{
    in 0 renderwindow
 
    target renderwindow
    {
        pass clear
        {
            colour_value 0.6 0 0.6 1
        }
        pass render_scene
        {
            rq_first    0
            rq_last     max
        }
    }
}
 
workspace MyOwnWorkspace
{
    connect_output MyOwnWorkspace_Node 0
}

Presumably that should be more like:

Code: Select all

compositor_node MyOwnWorkspace_Node
{
    in 0 renderwindow
 
    target renderwindow
    {
        pass render_scene
        {
            load
            {
                all clear
                clear_colour 0.6 0 0.6 1
            }
            rq_first    0
            rq_last     max
        }
    }
}
 
workspace MyOwnWorkspace
{
    connect_output MyOwnWorkspace_Node 0
}
Post Reply