I started R&D on next project with the intention of writing fewer custom shaders and sticking to the Unity standard ones as much as possible.

That didn’t last long. 😂 #hackhackhack

@sinbad Any specific reason? Btw there was a nice video by Schell Games where they said they basically extended the standard where needed, with some custom editors sprinkled on top to display as if it was intended to be that way.
@npatsiouras I needed to write alpha-rejected texture data to the gbuffer only in between 2 opaque object sets (a player highlight that must always be on top of the world but always behind player). Standard shader would either outsort to forward pass and/or include it in the depth-first pass, neither of which I wanted (either clips into world geometry or affects lighting). Custom shader with only the gbuffer pass and with everything stripped out except what I need is perfect.
@npatsiouras I did have a version with the standard shader but it required a zbias which was impossible to tune perfectly so that it never clipped the world or the player model. Decals were another way (not that Unity supports them OOTB except in HDRP which is out because no Switch support), but even then I didn’t want a “smeared” effects on uneven surroundings.
@npatsiouras for example (excuse terrible programmer art). See blue circle not clipping into wall but still being behind player. Also appears on top when player is behind wall even though player is invisible (will have silhouette rendering)
@sinbad Ok I understand the concept, though my knowledge on the actual details is lacking. If I understand correctly, it would be ok with the standard one so long as you got the clipping issue working right? Have you asked around(usual suspects) if its possible?
@sinbad Just for the sake of it really.
@npatsiouras No, it really wouldn't. The issue is that in order to appear on top of the world regardless of depth (ZTest Always) but behind the player (who is a standard shader), the ordering has to be *very specific* - world, ztest off circle, player. But if you enable alpha in the standard shader, it outsorts it to the forward pipeline, meaning it's always after the (deferred) player
@npatsiouras It does this regardless of whether you use alpha cutoff or not. So it's impossible to have a texture alpha cutoff version of the standard shader rendering at a specific point in the deferred pipeline, which is what I need.
@sinbad Ok, that's why you wanted the SRP thing from the other toot.
@npatsiouras Yeah, I will definitely want to use the SRP at some point. However the LWRP is missing features I want (e.g. projection) and the HDRP will probably never run fast enough on Switch, so I'm stuck in the middle for now (don't want to write my own SRP). Apparently the LWRP will mature in time and probably suffice but not until about a year's time I reckon
@sinbad Would it be too hard to hack up a mixture of the two? I think they do offer the C# code for them. But I have no idea if that's a tall order.
@npatsiouras they’re really quite different, HDRP is compute shader driven tile based lighting, LWRP is per-object single-pass up to 8 lights. And they’re both changing a lot. I don’t fancy that as a maintenance task
@sinbad Sure, it's never pretty. I was curious whether the tradeoff between waiting and doing it now until you can switch to a better SRP had merit.
@npatsiouras I’m tackling the awkward rendering bits now as R&D so I can be sure of my initial approach (also: silhouettes behind geometry needed a custom shader) but the rest of it should be ok with standard I think
@npatsiouras the deferred standard path is working for me anyway and I’ll look at LWRP again in time. I need a bunch of small lights so deferred makes sense in std pipeline, but 8 per object may well be good enough in the end, will see