Current 2D Renderer's missing core features

I mention it because I get the feeling there's no longer a UGUI team, that they've all gone to the UIBuilder/UIToolkit world, and the only one left is Stephan and his fantastic SDF TMP...

And... because SDF/TMP rendering of 2D objects is AMAZING!!!

Have you done any experiments with SDF (2D) for 2D rendering of shapes with smoothness and expandability and effects etc?

In other words: I think SDF with shaders for 2D is a HUGE missing feature in the 2D armoury.

 

Hi @Chris_Chu ,

I've been working with 2D render pipeline for about 6 months now, and I think it's a really nice system. There is a unique lighting feature I've been working on in my current project, and it involved some fairly special shadow behavior...

Well, I was able to accomplish the unique effect using a Freeform Light2D, which was super exciting! So I did the same thing I've done for every unity class that I want to work with: Looked at the API hooks, and figuring out how to integrate. Hmm... updating the ShapePath isn't in the API. That's fine, I guess I'll extend the class and add the API hooks myself, except the class is sealed! Ok, ok, we're still not out of the game yet, I'll just add a package reference and add a partial class. After banging my head against this for a couple days, I remembered that the DLLs are compiled before connecting the reference, so that's no good either. These classes are so locked down, they're not even accessible using ReflectionUtils.
The way these are set up, I'd expect that there would be glitches or issues updating lighting during runtime, but modifying the lights in the editor while the engine is running doesn't appear to impact behavior. It appears that, in particular, the ShapePath is even intended to be updated, and runs a checksum to see if any of the points have changed.

After some looking in the source files, it looks like only some of the classes are locked down this way. Can you help me understand why this is? Would it be possible that these classes could be opened up enough for them to be extensible?

edit: I have also tried creating a copy of `Universal RP/Runtime` and referencing this instead, but for some reason when I do this, I can no longer assign the Light2D to objects. If anyone else has ideas for how to override this, I'd love to hear them.

edit: After a little more tinkering, I was able to accomplish a much better version of the effect using ShadowCaster2D, but since it uses the same ShapePath attributes, I still can't modify the path.

 

At this point of 2DRenderer development, I think most if not all of the class's properties should be opened up for API access. I have already mentioned this, but simple look at 2Dlight reveals that so many properties simply has no setter for no apparent reasons.

 

I appreciate your candidness here: I work on a 2 person engineering team for a product used by many (but not as many as 2D Renderer) and it would be devastating to lose a member just by the amount of "brain drain" and familiarity with the code base. Thanks for being open about release date changes, I now know how to temper my expectations.

This is the biggest issue I have, and I would appreciate this being made as easy as possible. Because I tried to do this and failed (without forking the repo)
Based on the idea that "Scriptable Render Pipeline" means "write your own render pipeline, and use existing pipelines as a base!", I assumed I could copy what I needed from the 2D Renderer and extend it.

I hit so many scope roadblocks with that approach that I gave up after an embarrassing number of hours, and realize now that I should have forked the renderer.

 

It has been another month since we talked about this.

Any chance of Emissive channel shader example? Any updates on this?

 

Thanks!

Which versions of Unity will this shader work?

 

I think I got it to work properly after changing the uv input for the light texture to screen position.

Next thing that we really need for the shader graph 2D, we need the following attribuites to be also able to change for all of the 2D shaders



I am assuming that Workflow mode is not relevant to 2D, but

Render Face, Depth Write (plus depth offset), Depth Test, Alpha Clipping, And all of the blend mode options (Blend mode, operation) should be available with 2DRenderer

 

This is just a grab of Amplify Shader Editor of 2DRenderer shader and it exposes most, if not all of the options that should be able to set for the shaders. Which is why I am not able to use shader graph for the 2DRenderer.

 

Having a look at the emissive shader, I am very curious on how "Normal map" affects the lighting? I mean the shader basically takes light texture and multiplies by it, which is fine, but then there is normal which is supposed to affect the lighting for the non emissive parts. My current guess for the emissive shader is that normal map is affecting both emissive and non emissive parts?

But correct me if I am wrong, previous experiences tells me that for all other rendering pipeline emissive channel should ignore the lighting result coming from normal map? If that is true, then current implementation can not work as expected?

For example, if you have very dark pixel that is supposed to be in result after normal map lighting calculation, having emissive pixel at the same place is not going to look correct as it is also going to be darken because of the normal map?

 

Or do something like this?



But then even if we do above, I failed to see how normal could affect non emissive pixels... if input to "normal" doesn't really do anything. (because it is custom lighting..)

If we have to manually calculate pixel lighting with normal then :

1. Not sure how internally 2Drenderer actually calculates that.
2. Even if we do it manually, then what is the "normal" input to fragment node supposed to do ?

 

Or is it that the result of Light buffer map already been rendered using normal map?

 

@Chris_Chu

Also, it would be helpful to have an example of custom lit mode in a very basic Shader in forms of just text instead of shader graph, just like the Sprite-Defualt-Lit shader.

Looking at the compiled shader from shader graph is just feels way more complicated and in a mess, than just looking at the provided Sprite-Default-Lit shader in text form.

If Shader graph will take so much more time in developing to provide all the necessary shader options, then it will be super helpful to have a skeleton text form of the Custom lit shader just like Sprite-Default-Lit shader.

 

@Chris_Chu, any respond to above?

 

Thanks. I understand it better now. Text version of emissive shader I was talking about is exactly what it said. It would be useful to have non shader graph version of the emissive shader just like default lit shader.

Compiled text version from shader graph is just so messy and not good to be based on for customizing it. Simple text version of emissive shader is going to be useful because we have no telling when shader graph will be updated fully to support all the options that shader can have so having text based version can solve the issue in a meanwhile.

 

@Chris_Chu,

Also, I am currently in need of developing my own custom 2dlight and been researching on what would be the best way to approach this.

Basically, I have 2 idea.

1. Somehow come up with custom 2Dlight component which can write to the light buffer.
2. Use custom lighting model and do full screen custom lightmap and then use that texture inside shader.

Now, approach 2 would be easier, but I am not sure how light buffer is being written and at what value and how the lighting was actually calculated. So it would be very helpful if you can explain how does light buffer gets rendered, especially with normal maps in mind. The part that I am very much wondering is the "Distance" of the 2dlight for normal map. I am thinking when light gets rendered into the buffer, it takes normal map from the normal buffer and then "distance" value from the light (z value?) and the actual color of the light pixel to calculate lighting and writes to the buffer? If so, is there any 2dlight internal shader that actually takes those parameters and process it? ( if so , where can we find it? or can you provide us one?)

Any help in regarding to this would be very nice.

Thanks.

 

I see. So Sprite light type possibility. So I am assuming that sprite you are talking about is this ? :

light2D.lightCookieSprite ? I am using 2021.2 and it is currently only has getter.. So I am assuming that 2DRenderer for URP 13 (Unity 2022.1) has setter for this? And is there any reason why URP 12 version can't get sprite cookie update backported?

 

Yes, if you can also give us setters for other light2d properties while doing so, would be super! Thanks!

 

I also would like to be able to use this in 2020.3.22f1 (LTS). More recent versions have some build hanging problems for me.

 

Since I found a thread that had several other people reporting the same issue and was a "me too," I personally have not.

Related thread:
https://forum.unity.com/threads/con...-assemblies-program-crashing-hanging.1057568/

 

@Chris_Chu

Sampling of 2D Light texture becomes black for prefab editing scene. (Editor mode). Resulting everything becoming black when trying to edit any prefab that is using 2Dlight texture and custom lit mode in its shader.

This has to be a bug? The same prefab looks fine in the scene.

-- Edit --
I can create some dummy scene with some global 2d light and use that as prefab editing scene and it sort of works, but asset preview below the inspector still show a pitch black prefab. I am guessing the 2dlight texture is not properly sampled for that space.

Bug report case : 1407980

 

Are soft shadows planned for implementation at all?

 

If it's not on the roadmap then we have to assume it isn't planned.

It would be great if everybody would submit the idea (in addition to submitting any other feature requests they have)! I honestly do not know if Unity actually listens to these submissions. But it is the 'official' way for us developers to communicate what we need, so it's worth a try.

At the end of the day, 2D URP is just sooo understaffed.
I'm not sure if asking for more development resources dedicated to 2D URP is an 'idea'... but when in Rome...

 

I too, ... have already done submitting idea, feature requests multiple times... but you know how it goes. Just can't emphasis enough on understaffed issue for 2DRenderer..

 

And done. Hopefully that helps.

 

It really is sad how 2D users and 2D development has been more or less demoted to 'second class' by Unity. Especially when the 2D URP community is so eager to help in any way that we can.

 

Big money is in 3D I guess. Including all the industries where Unity is expanding besides gaming. Since they focus less on gaming in general now, 2D isn't a priority for them anymore. Sad indeed.

 

When you think about the Unity's business model, it makes sense for Unity to keep expanding its user base beyond gaming. Which I do get it. But you are right, it is "don't give baits to already caught fish mentality" ... unfortunately. For me, Unity has become or becoming more like adobe now, less innovation internally, but seeks to expand by user base addon and merging external tech. It is sad really... what we need is some serious competition within the Unity users region. I think Unreal is not a competition anymore when it comes to heavy 3d field. Unity should not try and fight in that field. That area is already lost in my honest opinion.

 

@MelvMay , I am sure everyone who is working on 2D at Unity is doing their best, and I don't think anyone posting here is trying to undermine that effort. But despite what you have said above, it is also true that a lot of users including myself can't help but feels that Unity should spend more budget to 2D than at least now because we simple have no idea on exactly how Unity internally spends its resources, but we occasionally hear news about mergers and expansions while we wait for very critical features to be either fixed or implemented for years. And all of that are not helped by not really knowing when and if what will be fixed/implemented in the future makes the whole waiting process even more edgy. So most of our nagging here is just a expression for result of years of frustration.

I am not saying that 2D team is not working harder or passionate than the other teams at Unity. But the end of the day, progress does seem to be slower (well for us users) than some of the other parts of the Unity, which is why we probably feels like Unity should invest more resources. If any of our simple minded thinking has discouraged you, we do apologize for that.

When I hear question like "Are soft shadows planned for implementation at all?" It just reminds me of how long that request was made before, years of wait and still have no idea on when that will ever happen makes me feel frustrated all over again and puts shadow of doubt on my mind whether I should consider using 2DRenderer again or not.

I consider myself to be one of edge type person who usually eagerly follow the technology development around the tech that I need to use to develop the product. But after years of trying, I am actually little tired of trying to follow the Unity 2DRenderer development, because of its pace and not enough sources to get the development information from.

After saying all of above, I do feel like it is not even fair to comment such thing on all of the 2D team. For me, it is probably just the 2DRenderer side only which is the only part of the 2D development that I feel like it isn't there yet. I personally think 2DPhysics is awesome and it is complete and beyond what is mostly required to build a 2D game.

For us users what we mostly need is some lists of stuff being/will be worked on with at least some month accurate dates to go with them, so we can plan better and the wait is not so painful as is now.

 

@MelvMay we hear what you are saying and I apologize for my statement (it was imprecise and frankly not true. I was frustrated by other non-2D-Unity things when I wrote it).

But I would like to direct your attention to the 2D Roadmap. At the time of me writing this, the roadmap contains no roadmap. Everything on the roadmap has been completed. This isn't bad per se, but it might be sending the wrong messages. If someone were to try to determine the future of 2D in Unity just using the roadmap... it almost looks as if Unity has no future plans for 2D development!

That's not a great roadmap.

And when you think about it — an empty roadmap is rather odd.
Over the past few years there has been MANY feature requests (mostly 2D URP related). So there really shouldn't be a shortage of ideas/features in the roadmap, even if they are just listed in the "Under Consideration" section.
Why is this?

Many 2D URP users have provided feedback.
Even some users such as @ThundThund have implemented long-awaited features themselves.

Now we understand that the 2D team might be painstakingly reading every thread and logging the feedback internally. But if you don't communicate with us or show us that our feedback has power, it will come off as negligence no matter the diligence of your unseen efforts!

Look at the Unity Future .NET Development Status thread.
The Scripting Team has opened up a meaningful two-way communication with every single Unity user about the future of Scripting in Unity and they have made good on promises they have made in that thread. That is pure gold to us users!

Spoiler: P.S.

We appreciate the 2D Team for everything that you guys do and we are not ignoring the big features you have given us in 2021.2. Thank you all for working hard for us and doing your best to deliver us what we need to make great games!

Spoiler: P.S.S

I fully acknowledge one yet-to-be-completed 2D URP card can be found in the VFX graph section.

 

Melvyn would this be the time to mention the little play around with improved 2D shadows.
If I remember isn't there a new 2D shadow coming if it is approved by by certain QA teams. Pretty sure I saw some videos, but not sure if it is near ready to be mentioned. If I remember it has improved shape support of the sprite renderer and collider shape support as well.

Wasn't sure if people would see that and be more happy and calm about waiting for new 2D renderer features.

Also, honestly with some of the new stuff that is coming in Unity 2022.2 I can say the 2D team has 100% made a huge amount of stuff and improvements. So understandable with how much they made if they didn't get to other features.

Also note let's not bother the dev teams for when stuff is going to be ready. Usually there is a reason
for them not making comments on the forums yet, or they have a huge gift waiting to be shown to bring people a smile.

Either way I think with what I seen so far this year has a lot of major improvements to 2D systems and when they come they come.

 

Hey, @MelvMay?
I don't want to be that guy... but did the 2D Product Manager ever get back to you?

 

The 2d Renderer's performance is terrible! When will it get better？ Waited 2 years.

 

2022 roadmap recaps what was done last year:

No mentions of any new features or tools.

 

They did us dirty.

The only good news is there are a few announced features that may arrive in the coming years:

1. Experimental 2D Contact Modification API
   
   
2. Lit 2D Visual Effects Graph Particles

Unfortunately that's not a whole lot...


And on another note, exactly which source of truth are we supposed to believe anymore? Should we believe:

1. Unity's Official GDC Roadmap
   
   
2. Unity's Official Roadmaps On Their Website
   
   
3. Or random posts made by Unity's 2D Team that I have found by scrounging around the forums?

Now I understand that the 2D Team is working as hard as possible... but please, the 2D Team needs to take a moment to rally their troops and march over to the 2D Marketing / Product Department and tell them to stop playing minesweeper.

 

Actually Unity 2022.2 has a lot of new 2D features that was not mentioned at GDC and isn't on the roadmap.

This includes a new WIP 2D specific Profiler window with a lot of details for performance on GPU, CPU, and memory usage. It shows a lot of information for rigid bodies, joints, and a lot of other stuff. Due note I don't think it has landed in the Unity 2022.2 public alpha yet.

We have a much better function set for addForce in 2D API.

Rigidbody components have some new fields that help relieve a lot of headaches in complex systems where you want certain objects of physics layers to interact with other layers on a per object basis.

I think there is a new physics shaped based lighting coming out, but I doubt it will be in 2022.2 release.
It uses collider and rigidbodies for the light shapes.
So instead of adding shadow casters it actually reads the colliders and generate the shadows.
Basically better real time lighting and shadows for 2D. I can confirm the lights and shadows look real nice in as well.

Also have to think that Navmesh once updated with DOT backend will be working to making 2D continuous
nav grids for easy a* path finding with 2D colliders. This one depends on DOT stack readiness though if Unity still plans to make some nav mesh stuff run with c# job system as a backend system. This one is up in the air of how they are planning it and I don't have too much concrete information because nav mesh haven't been up kept very well information wise or package manger wise.

So I would say we have a lot to look forward to this year and early next year for 2D features.

 

Something has appeared on the roadmap as of yesterday: https://unity.com/roadmap/unity-platform/2d