I’ve been working with implementing some custom 2D lighting, and I’ve found that there’s only so much I can do by implementing custom lit shaders for my objects.
What I’d really like is to change the behaviour of how the light textures are generated.
I noticed that the Renderer2DData does have serialized fields for all of the lighting shaders, as well the FallOffLookup texture. Exposing these would add a huge amount of customisation options for stylised lighting effects.
I’ve found that by changing the Inspector to debug mode, I am able to change the shaders used for the lights themselves, which is a huge opportunity, however the FallOffLookup is marked as [HideInInspector], so this remains hidden.
I’ve worked around this for now by creating a custom editor to expose this property for use.
However, I am concerned that the [Reload] Attribute could cause these values to reset back to their defaults (I haven’t looked too closely at how it works).
Here are some examples of effects that could be achieved by changing these values:
Change FallOffLookup texture to add solid banding to the light falloff
Exposing these fields would open a huge range of opportunities to developers looking for a more unique lighting style, without needing to reimplement the entire 2D renderer!
I have similar things going on in a custom renderer based on the universal renderer the one thing that really made my life is easier is using an assembly definition reference which points to the urp assembly definition to basically get a foot into the internal part of the package. Maybe that can help you as well.
I still need a custom editor and renderer and I use the fact that the URP asset class is a partial class to get all of this working but still that one “hack” made a lot of the customizations a lot easier.
That’s a good shout, I’ve mostly relied on dubious reflection code when I need to utilise some internal methods.
It’s a real shame that extending Unity so often requires assembly references or reflection to gain access to the very extension hooks that the Unity developers use for themselves. I understand the heavy use of internal is encouraged to prevent reliance on APIs that may change in the future, but I’ve seen so many other Unity devs who are still using those APIs, but just with more pointless hoop jumping.
I’d really like to see more transparent extension points and less hidden properties and internal utilities.
Could not agree more!
I am literally loosing my mind over per-object-properties without breaking srp batching for months now. Every angle, every workaround I try is 98% possible but then one single thing blocks it from actually fully working. No matter how much energy I throw at it :-/
Exactly this - if the API won’t let you, and the only way forward is to ignore the API bounds, most devs are going to do that.
As said above, embed the URP package and add your assembly to the ‘InternalsVisibleTo’ in the URP AssemblyInfo.cs to gain access to all the ‘internal’ methods.
That aside, perhaps you can do your ideas (adding a screen space noise to the falloff texture) by adding a render feature and blitting to/from the already created falloff texture to band or noise it. I’ve not looked at 2DURP so I’m not sure which event to use, but presumably this is just a global texture you can access like others?
It’d be great if you could, be unfortunately the 2D Renderer is far more restrictive than the standard URP.
The entire 2D Lit Pass happens in one pass; Rendering the lights, and then rendering the sprites. This means there’s no way to inject a pass in between rendering lights and renderering the sprites. And all the lighting data is cleaned up afterwards. It’s a really annoying solution, as it also prevents using the lighting data on custom render passes, and makes any custom use cases difficult. This makes a lot of use cases with the RenderObjects feature non-starters too.
Luckily my current workaround of dangerously editing the hidden properties on the 2DRenderer does work for this specific problem.
the asmdef hack does not even require you to embed the package. I am using the read-only package and it simply works.
This trick is actually like having super power since you can drill into rather rarely seen classes by attaching to other assemblies too (UnityEngine.UI puts you into the main UnityEngine assembly)
Back at topic, I am pretty sure a world space tileable noise could go a long was in adding structure to the 2d lights as well and the banding might be similarly achieveable just in the shader with a global gradient texture to lookup with the falloff.
