foriero yazdı Anyway I think we need to "push" Unity to have DoF working with Depth.
Haha yeah that would be nice. There are quite a few features that the 2D Renderer is missing. The 2D Lights are really nice, but I personally feel like they announced the 2D Renderer too early. They only recently added the camera stacking, and you still can't use GrabPass in shaders (unless they added that recently, but I haven't read about it). The guys at unity working on it have been saying that they are focusing on optimization improvements, and have a big list of features that they're planning to add (I believe the Depth option was one of them). It's just unfortunate that there isn't an actual timeline for that, so who knows if it's going to be 6 months or 2 years :scared:
But on a lighter note, I believe I have a configuration that will work well with my setup to let me use DoF.
Quick video I made of a mockup "cliff" sort of thing - the DoF part is in the second half of the video: https://i.imgur.com/hypBxzd.mp4
Basically as Foriero was suggesting, to use camera stacking and have the Base camera render the 'background' layer with DoF, and then have another camera that renders the 'main' layer.
Since the 'background' area is using the sprites/spine on the AlphaTest render queue, they need to be manually 'sorted' by adjusting their Z-position. Meaning if there is some ground below with trees on it, the ground would need to be set to whatever Z distance (lets say 5), and then placing a tree on top would need to be slightly closer, like 4.9999. If I place another tree down that should overlap the first tree and be in front of it, I would set its Z-value to 4.9998. I made a little editor window helper that lets me nudge the Z-position value by +/- 0.0001. There might be a better way of doing this, so if anyone has a suggestion I'd be glad to hear it. I'm still working on the 'workflow' of using the perspective camera to set up the scene, but it's going pretty well!
Edit: A better solution to emulate the y-axis sorting for this setup would probably be something like this:
1) Create an empty gameobject container that will have all of the ground (dirt/grass/etc) sprites for a "area" in the background (like the ground below the cliff in my mockup video). Set its Z-value to whatever it should be (was 5 in my case). Add all of the dirt/grass/etc sprites to it. These are all fine to stay at Z = 5 position.
2) Now create another empty gameobject container that will have all of the stuff that would normally need y-axis sorting, like plants and trees. Set the Z-value for this empty gameobject container to slightly higher than the ground-sprites container (like 5.0500).
3) Add all of the sprites/spine for plants/trees/etc to the container and position them in 2D space (their local Z should be 0, so they should still be at world Z of 5.0500 at this point). Ignore Z-fighting for now.
4) Now if I create an editor window with a button such that I can select the container gameobject for the plants/trees, and press this button to have it create a temporary list of all child gameobjects, sort that list by their y-value, and then adjust their Z-value based on their position in the list. So the first object wouldn't adjust the Z-value at all, the second object would adjust it by -0.0001, third would adjust it by -0.0002, etc.
So essentially converting the y-axis sorting idea into tiny adjustments on the Z-axis, and doing it as a batch for each "area" that is in the background parallax/DoF.
