Hello!
I’ve recently started work on a deferred decal system, it’s base is similar to what Aras kindly gave an example of, however due to how unity’s deferred works, his example system is to limited.
What I want to achive is a much more complete deferred decal system, where I also write to AO, Roughness, Spec color (metalness), and emissive.
It not getting any ambient light is also not acceptable, so that will also be “fixed”.
Note all of this is very early in development, but even so, ideas and feedback on the ideas I have written and have on the trello board are very welcome! (Comments are open on the trello board.)
The ability to have “Layers” for decals, so that materials can have one or multiple layers, and decals can effect only or exclude one or multiple layers.
The downsides:
No lightmaps on things affected by decals.
Reflection probes are unlikely to work unless they update a global cubemap.
Lightprobes will most likely not work, considering getting past this and using per pixel interpolated lightprobes. (This can also make them less “good” in some cases, and it’d be low on the priority list.)
I can use the global cubemap, (can be set runtime), but reflection probes placed around in the enviorment that unity blends between per object would be alot tricker, I have some ideas for it, but even so limits would exist. Sometimes it’d be enough to simply blend between 2-3 light probes, and all visible objects share those, that I can easily do.
Per object solutions would require storing what lightprobes affect each object, and have all relevant lightprobes acessible in the lighting pass.
Good work so far. Having them only affect some layers is fairly vital, otherwise in a lot of situations where you need a bigger projection area, you would end up overlapping objects you didn’t want just to have a valid projection, ie dynamic characters.
Best of all, it won’t “steal” layers from your physics as I won’t be using unity’s layers, downside is that the layer count will be even more limited. (Stencil buffer)
Unity is doing per pixel probe lookup for SSRR in 5.2 or .3 - check roadmap, which may or may not contain functionality that could be expanded for your use cases - best ask them.
The curvature of the lines is not known in advance because the tarmac shape itself is procedurally generated. I can’t integrate the lines in the tarmac texture because there would be way too many combinations and the tarmac itself is 4k, so that would likely overflow the GPU memory.
I could create a bunch of curves and then match the closest one. Would it be possible to pack those curves nicely in a texture like this, or will the UVs be a problem?
One advantage of that is that mesh tessellation is not visible.
Could you potentially give the shader enough information to mathematically construct a very similar curve?
(I can probably help with the math if needed)
Yes and no, it’d be pretty hard to know what line is what when packed so tightly (y-overlap), but if you don’t need colors in the texture we could use the 4 channels for alternating lines, so the y-overlap would never happen within a y-range.
One other possible solution/idea I’m thinking of is to remap the UV from xz Object space to something else.
This could probably be done with textures, and they could then be blended!
The blending should get you near perfect variations without having to create to many textures for it. (2 channels needed per remap, so you could pack 2 remaps per render texture if that’s what your using).
Yes, the taxiways can be slightly modified to follow the curve of of available lines, but not too much. Alternatively, I could construct the taxiways out of pre-set curvatures. I suppose that should work as well.
The lines do need colors, but the color can be added globally in the shader, because most lines have the same color i.e. yellow and white. So the base texture can be monochrome, that should be no problem.
By the way, there is no specific need to pack the textures so tightly, if that poses problems, it is ok to pack them in a non-overlapping way.
Nice!
I was testing the unity example at the weekend and I’ve discovered one big issue with the “normal only” decal shader.
It overwrites the normals under the decal instead of multiplying/combining it somehow.
Is combining even possible? In this state it’s unusable for me.
I hope you’ve got something like that in the pipeline.
Its on the todo list, however my time spent on this project has been reduced drastically, but that one feature I’ll see if I can’t get done today, after that if people want it, pm me and I can send you a copy. I don’t want to put it on the asset store, as its to far from finished, but if people want it in it’s current state and/or want to help develop it please ask! If others help out it will be uploaded for free on asset store, with a license that allows free development and sharing, (and github or such). If it ends with me doing everything somewhere in the future it will have a cost to it.
I still have the major issue of ambient light and lightmaps, thankfully unity have a plan for that, but its not out yet…
I am more than interested no matter what the current status is. Though i wouldn’t be any good what it comes to ambient light and lightmaps, as either one of those are not used in the project i am hoping to use some dd’s. PM sent anyway
Well, sadly I have put this project on hold as mentioned, at least until I can get either enough interest to make it open source, or I get time to spend on it again.
Once (if) unity decides to make the GI be applied in the deferred pass instead of the initial pass, well, that would allow me to make them “complete”.
But there are a LOT of things that would need to be done to have all the functionality that is needed also. Alot of that revolves around normals and normal blending.
Ah I see - well I think they’d be open to that if you contact them. The new Unity (NU for short!) listens to users and implements great things.
For example 5.2 extends the plugin api, allowing middleware to inject rendering into a precise stage. It’s really great so gives me hope that robust deferred decals are possible.
Well, what I need from them is something they have in their todo plan. However there is a lot more that could and probably needs to be done for it to be releasable as a genericly usable defererred decal solution. Such as the matrix for the normals not necessarily being the same as the one for the game object!
My version might work better, however it really depends on how what the bug with the SSAO pro is. My guess would be stencil buffers, in what case no. If it’s depth related it’d be really odd. It could also be something else completely. My suggestion to your graphics programmer is to download and learn RenderDoc. Note that it can be run with the unity Editor! So no need to make builds to get a LOT of information!
The main problem with my decals would be that they are to a degree built upon the UT version, more complete, and they get past an issue or two, but still the same base. As I said in the beginning, it’s all dependent on what the bug is, as they bug is VERY weird!
I currently use 2 passes as I chose not to modify unity’s deferred g-buffer layout. However I have done this before, but for a specific game. And in that case I changed around the layout a bit of the g-buffer, leaving the AO in the alpha channel, making it so I didn’t need dual passes.
