RenderTarget on a Layer and MeshInstances on multiple layers

[mvaligursky]

Hi guys,

Currently, the official way to render to the render target is to use Camera.renderTarget property. Additionally, it's recommended for each render or model component to be exactly on a single layer, instead of multiple.

For backwards compatibility though, this also works:

• specifying the renderTarget on the Layer (non public API)
• specifying multiple Layers for render / model components (this is officially supported)

The support of the old way of doing things adds a lot of complexity to the engine, but more importantly makes it very hard to move to where we want to go with FrameGraph and RenderPasses, which would give us new post-processing stack, new way to add self-contained rendering features to the engine (SSAO that runs before the scene, depth pre-pass, SSR and many others).

We're considering the removal of these. The question is - how will you be affected by this?

If you use either of those two "features", can you please give us details of why you need this. It could just be 'because we cannot be bothered to rewrite that code' as well as it works.

[LeXXik]

Personally, I am already using camera.renderTarget, when I need to write a texture. I support the change.

In a team, there are still some places that do require a switch from layer to camera in our codebase. The reason it wasn't changed so far, because we usually don't touch stuff that works :D The switch is trivial, though, and we can do it any time.

The only reason I personally fall back to layer, is when I try to revive some old projects that rely on it (even then its kind of hard, like After the Flood, for example).

[leonidaspir]

We haven't beeen using layer.renderTarget for quite sometime, we are quite OK with fully removing this.

About the 2nd point, do I understand correctly Martin you are talking about removing the ability to assign the same mesh instance to multiple layers?

I'd say although this adds complexity to the engine, we are using it in so many places (and many other users I gather):

• Specifying which models contribute to certain render features e.g. trees/bushes are rendered in both World and a Planar Reflections layer whereas grass to conserve performance only in World.
• Similarly select which models appear in a top down Map render target.
• We've also built an elaborate automatic HW instancing solution in our Solar Tools SDK that includes a custom frustum culling algorithm and LOD support. I remember it added a lot of complexity the fact a mesh instance can be found in more than one layers (we did manage to add support for that).

[mvaligursky]

@leonidaspir - thanks for this, I'm surprised you're not using the recommended set up for this: https://developer.playcanvas.com/en/user-manual/graphics/layers/#recommended-setup

It's not a problem supporting your solution, where you assign layers to the cameras the way a single mesh is not on multiple layers the camera renders - which would require to de-duplicate the list to avoid mesh getting rendered multiple times by a single camera. That's what I'm trying to avoid (and we currently do).

[leonidaspir]

I think when Layers where introduced in PlayCanvas there wasn't a strong case on why to use a single layer per mesh instance. And I think the PlayCanvas editor makes it super easy to assign more than one, so a lot of people do use this concept.

As you say in most cases it will be a separate camera rendering those extra layers e.g. a top down Map rendering camera or a separate camera for planar reflections.