Yes…
Actually, I realized what the issue is, and it’s partly that I’m thinking about it the wrong way and partly that your postprocess doesn’t really solve the problem fully.
The issue is: your global postprocess only works because it doesn’t do anything to the portal object itself. It uses Custom Stencil to filter the objects it modifies, meaning that when it sees the object the SceneCapture is rendered TO, it does nothing but pass it forward.
My cel shader and outline renderer, unlike yours, aren’t limited by the Custom Stencil flag. They process everything. This means that the portal captures the modified world, then gets modified AGAIN because the portal is also a mesh-with-a-material IN the world. So what I was doing was trying to mask out the portal so that it only passed PostProcess0 through, thinking it would then pass the captured scene, but that doesn’t work because of how the blendables are arranged relative to the tonemapper
I think, really, that the issue is I’m thinking about this backwards. Really, everything is working as it should, it’s just not what I want it to do. I think the proper solution is to forego projecting the SceneCapture ONTO a world object… instead, what I need is for the portal to somehow flag itself in a way that lets a PostProcess isolate it. Then, I can simply render the SceneCapture2D’s texture directly in the PostProcess, rather than into the world, bypassing the double-processing issue entirely.
Custom Stencil was made for this, but because my portal object itself is a translucent surface (so I can use depth fade to mask the seams when objects clip into it) I can’t render it with Custom Stencil/Depth.
So what I really need to do is find a clever way to configure the portal material so that a separate postprocess blendable can get “black, but white where the portal is visible”, then just use that mask to display the RenderTexture directly (which works since my portals already use ScreenSpace UVs)