Debug shader output functionality

[mvaligursky]

Functionality, allowing a name of the shader pass to be set on camera, to be used for its rendering. There are multiple shader debug passes predefined, allowing debug rendering functionality.

Custom shader pass names can also be used. Possible use cases is where for example user wants to use cheaper shaders when rendering to reflection texture. They can use the shader define to skip some processing in some shader chunks. Alternatively, they can modify StandardMaterialOptions in a callback to disable shader features.

There are two new shader chunks:

• debug-output.js - inserted at the end of the generated shader, outputs data that are written to color render target based on the shader pass define
• debug-process-frontend - inserted before the front end data are passed to backend, allowing those to be modified. For example to render 'Lighting', the albedo is set to mid gray color here.

New API:

Example:

Multi-View example updated with dropdown (not all options are visible and scrolling is needing, which is not obvious)

debug-modes.mov

[willeastcott]

So cool. I was wondering. Maybe this feature warrants a new example. Maybe with 9 camera (3x3 grid) rendering an object with each viewport labelled with the pass being used.

[slimbuck]

I'm struggling to understand how the new shaderPassName relates to the existing FORWARD, DEPTH, ETC passes.

Is SHADERTYPE_DEBUG_AO assumed to be a FORWARD pass or...?

[mvaligursky]

I'm struggling to understand how the new shaderPassName relates to the existing FORWARD, DEPTH, ETC passes.

Is SHADERTYPE_DEBUG_AO assumed to be a FORWARD pass or...?

Shader pass name is converted to a number internally, and this is used as a pass that is used all over the place, for example in options.pass, or forward-renderer using pass to access shader from an array on material / mesh instance. FORWARD is 0, SHADOW is 1 .. and new passes that are created on camera are added after those. If the user wants to render shadow depth map, they could use existing DEPTH pass .. they are all the same. That is way I use the same SHADERTYPE_** constants. But I like @willeastcott 's suggestion of renaming them to SHADERPASS_**

[willeastcott]

If you do alias to SHADERPASS_, I would suggest changing CameraComponent#setShaderPassName to simply CameraComponent#setShaderPass.

[willeastcott]

This API naming looks much better to me so I'll go ahead and approve. What's your take @slimbuck?

[willeastcott]

Actually, can we consider this naming too please (since once chunk names are chosen, they can be used in app code). I'm not sure about debugOutput - the _DEBUG_ naming has gone from the constants. I can think of non-debug uses for this. And also debugProcessFrontend is a bit verbose. Not sure what could be better though. Ideas, @GSterbrant and @slimbuck?

[mvaligursky]

debugOutputPS could be: postEndPS
debugProcessFrontendPS could be: postFrontEndPS or processLitArgsPS

I'd probably vote for 1st on these lists.

[willeastcott]

Yeah, I think they're better. Would still love for @GSterbrant and @slimbuck to chip in too...

[slimbuck]

We chatted about this offline and decided this naming isn't great and we'd like to fix it, but not in the PR.