render pass TOP

Thanks so much for implementing the render pass path parameter RFE :exclamation:

Now before I change my setup I’d like to know if the amount of renderpass TOPs will have any impact on performance.
The setup’s gonna be like this

In “/render” there is 1 render TOP
In “/shots/*” there are up to ~500 Containers, and in each container I have a renderpass TOP targeting the main render TOP
In “/render” I also have 2 select TOPs which will select from 2 of the 500 renderpasses and blend them to produce the final image (which will be displayed)

During the show I will switch from which 2 of the 500 containers I will select. Will this setup be a problem?

Also, can a renderpass have a different resolution than the render TOP it targets?

And finally, what’s does the render parameter of the renderpass TOP do. Setting it to 0 does not seem to stop the render pass TOP from rendering.

Thanks
Achim

The main performance impact of a renderpass TOP is what it’s rendering. If it isn’t rendering anything or has its Render parameter to 0, it’s about as expensive as a Null TOP.

Currently, your idea won’t work as you described it. The problem is that Render TOP/RenderPass TOPs still need to be a linear chain with no forks to other RenderPass TOPs. You can’t connect 2 RenderPass TOPs to 1 Render TOP. It needs to be Render TOP->RenderPass TOP->RenderPass TOP. Here’s why, Render/RenderPass TOPs essentially pass a ‘canvas’ between each other and take turns painting on it.
Lets say in the Render TOP you are rendering the background to your scene. In your first RenderPass TOP you are rendering some object infront of it.
Now you have a 2nd RenderPass TOP also connected to the Render TOP. It’s also rendering some objects infront of the background. The problem is that when the first RenderPass TOP cooks, it destroys the clean background image that the Render TOP had created. The 2nd RenderPass TOP doesn’t have the correct starting point (a clean background rendered by the Render TOP) to draw over, so it won’t be able to create the correct result.

To get what you want there are a few options. One is to have Render TOP->RenderPass TOP, the first one rendering the first scene and the 2nd one rendering the 2nd scene. You can blend the outputs of the two TOPs together (you can fork off other TOPs from a Render TOP, just not RenderPass TOPs). You can use DATs to choose which geos the TOPs should render.

You currently can not have a RenderPass that renders at a different resolution than the Render TOP.

It’s very possible things will change for the Render/RenderPass TOPs in the future, but this is the way it currently works.

Finally, the Render Parameter will cause the RenderPass TOP to not draw any of it’s geos. The node will still cook, but it will be a very cheap cook (like a Null TOP).

And If I do not use (display) the image from a render pass TOPs this behaves like any other op and will not cook at all, right?

I can’t test it as touch errors when connecting two passes to the same render TOP, but as I’m clearing Camera Color and Depth buffer anyway, I don’t think I would run into problems here. would I?

Yep, this is what I’m doing, but as I have some TOP chains in each of the 500 containers, I then need to use a couple of scripted select TOPs to control the data flow. [render][in the 500 containers select from render][pipe through some TOPs][select back into render Container][blend]…

So currently I use render TOP → renderPass TOP in /render
In each of the 500 containers I select TOP from one of these render ops and pipe it through ome more TOPs
Again in the render container, I select TOP from the two active container and blend them
This way I can also select from a 2x2 constant TOP in the 498 other containers and keep their mem usage to a minimum.

I was hoping to use the new renderpass option to avoid this double selection (by having the renderpasses in each of the 500 containers), as my current select/selectBack approach needs to be scripted and may cause flickering due to scripts being executed at an “unpredictable” point in time. (you probably remember those flickering problems I had a couple of month ago)

Anyway, I’ll sick with my current setup for some time.

Thanks for the extensive explanation
Achim

Right, unless something downstream of it is cooking.

In your particular case because you know what your doing, no, you wouldn’t run into issues. The problem here though is that it’s very easy for a new user to get tripped up on this, which is why I make that error occur.

Hmm, maybe what I can do is make it so the render TOP merely puts out a warning saying ‘You can’t render anything in this node because you have 2 RenderPass TOPs connected to it’… Let me think about it.

and/or just force the two clear parameters to be 1 (and disable them) ?

But as I need to keep the memory usage in the 498 (non-active) containers to a minimum, I believe I need to stay with the select/select back approach, as I can then select form a 2x2 constant TOP in non-actives containers. I can’t see a way to accomplish something similar when using the renderpasses. hmm, maybe setting the render pass TOPs in the non used containers to target a 2x2 render TOP could work? Gotta try, but it’s probably not gonna make it (much) easier than the current setup.

Ya yes, the memory usage is another big issue with the multiple RenderPass TOP idea. I think the way you have it right now is the best solution, it just suffers from that flickering of course. Don’t worry, we haven’t forgotten about that its just a really tricky thing to fix.