[RELEASED] Decalicious – Deferred Decal System

Would it be possible to override the shaderqueue on per-material basis and through carefully managing the shaderqueues of all other shaders to do something like: draw terrain, draw terrain decals, draw buildings, draw building decals, draw everything else?
Or if that isn't possible, at least move the whole decal commandbuffer to just after the terrain and before everything else?
Neither would be ideal solutions, but it would at least allow me to go nuts on the terrain with decals, without worrying about them bleeding onto other things.

 

Try replacing COLOR0 and COLOR1 with SV_Target0 and SV_Target1, respectively. If that works, please let me know so I can include a change in the next Decalicious update.

Unity offers some very specific points at which you can insert a command buffer - I think it's not easily possible to insert it after the terrain has rendered, but before everything else. The only thing you could do is to use a multi-camera setup like I detailed earlier in this thread and have a special camera that only renders your terrain + terrain decals, and another camera that renders everything else on top. That might work pretty well in that special case. Apart from that, I will soon implement a simple frustum culling, so not all thousands of terrain patches get rendered in the Limit To function but only those that are actually visible.

 

I just tried that, but it doesn't work. Not even related to Decalicous I think, I can't get 2 deferred cameras to render this way without clearing the buffer inbetween even if I set it to "don't clear". I vaguely remember there was a bug with this feature. I'm still on 5.5.. I think I'll delay this for another while, and check again once I updated to Unity 5.6 or Unity 2017. Thanks for the recommendation.

Also, wouldn't it be rather expensive to do the deferred lighting step twice? I migt have a lot of dynamic lights.

 

So I might not be up to speed on the latest development of the asset, but is decalicious already batching draw calls? Like combining all the decals it can into a single draw call?

Then if there is one thing that would turn the usefulness of this asset up to 11 it would be if the decal could not only be limited to a mesh collider, but also a unity layer. Don't know if that information is still available at the time the decals a drawn (probably not), maybe there is a way (create a stencil buffer that will then be used to tell the decal renderer which parts of the screen should be rendered to for example)? If something like that could be done without tanking the performance, we could use decals on background meshes without them affecting for example NPCs, and still have the decal span multiple Background meshes to tie them together for example.


Last thing is maybe just as out there: is there a way to add some "fake-SSS" effect to the shader (Similar to the way UBER handles it, which gives a nice performance, and can easely be modified to support SSS color textures)? That would make things like moss decals look even more awesome. Without some special lighting faking a SSS like effect, moss currently looks a little bit ... off, for the lack of a better word. Not "Soft" enough.

Of course, the most amazing thing would be to be ablew to use ANY shader with decalicious, somehow. For example by providing a simple include that could be used to transform any old shader into a decalicious decal shader... so I could combine decalicious with UBER which I use for all other objects. No idea how big the difference would be, but might tie decals and scene objects together even more in case of some special shaders (for example toon shaders). This way the "fake-SSS" effect could just be created by combining UBER and decalicious shaders.


EDIT:

Oh, I totally forgot... is there a chance the decalicious shader could also be used for self illuminated materials with a future update? With an additional self illum texture being used?

 

How complicated would it be to add a list of gameobjects for limit to option instead just one? This would actually solve my problem I think.

Code (CSharp):

1. // Common header, mainly taken from UnityDeferredLibrary.cginc
2. #define DEFERRED_FRAG_HEADER UNITY_SETUP_INSTANCE_ID (i); \
3. i.ray = i.ray * (_ProjectionParams.z / i.ray.z); \
4. float2 uv = i.uv.xy / i.uv.w; \
5. float limitTo = UNITY_ACCESS_INSTANCED_PROP(_LimitTo); \
6. if (!isnan(limitTo)) \
7.     clip(abs(limitTo - tex2D(_DecaliciousLimitToGameObject, uv).r) > 0.1f ? -1 : 1); \
8. float depth = SAMPLE_DEPTH_TEXTURE(_CameraDepthTexture, uv); \
9. depth = Linear01Depth(depth); \
10. float4 vpos = float4(i.ray * depth,1); \
11. float3 wpos = mul(unity_CameraToWorld, vpos).xyz; \
12. float3 clipPos = mul(unity_WorldToObject, float4(wpos, 1)).xyz; \
13. clip(0.5f - abs(clipPos.xyz)); \
14. float2 texUV = TRANSFORM_TEX((clipPos.xz + 0.5), _MainTex); \
15. float mask = tex2D(_MaskTex, texUV).r * UNITY_ACCESS_INSTANCED_PROP(_MaskMultiplier); \
16. clip(mask - 0.0005f);
17.  

AFAIK this code does the limiting but I am not good enough in shader programming to make this work for multiple game objects. Any ideas?

 

Yep.

I'm still looking for a satisfactory, general solution to the "Limit To" problem. Many people suggested layers, others suggested that they are also tied to physics and thus might not be the best options. Anyway, all approaches I could think of so far require a second draw pass with a special replacement shader of the geometry you want to limit to. I'm not overly happy with this, but for now it's the best I could come up with given the limited time I can spare to work on Decalicious. I hope to improve on this aspect in particular.

Not sure how that's done in UBER and if it's possible with

Emissive decals will be a thing soon. I hope that they will integrate seamlessly in the Unity lighting pipeline. I wouldn't expect Decals to be able to cast precomputed lighting though (so you probably couldn't light your scene with Emissive decals).

For a handful of objects, doable but not super-pretty. Dynamic lists in shaders always suck. On the other hand, we could introduce 'Limit To' groups as GameObjects, that allow you to add any number of GameObjects to them. Each LimitTo group then has an ID that is, at it is currently the case for MeshRenderers, written to the _DecaliciousLimitToGameObject texture. Problem is if multiple groups are 'valid' for a single pixel. Could use a bitmask for that, which would cap the number of those groups to 32. What do you think, are 32 groups enough to handle everything?

 

Great idea, 32 would be totally fine I think.

 

Great, thanks for the quick reply... not trying to light my scene with self illum textures here, not trusting the GI System enough to rely on that to be honest. So just self illum alone is enough for me.

Just so I understand it correctly... the solution you proposed to DwinTeimlons question would mean I could throw different environment meshes into a single gameobject, and as long as every of those environment meshes would have a collider, I could limit the decals to all the meshes contained in this one gameobject?
That would basically make the layer thing obsolete, really... Besides the fact this would probably still rely on colliders.

 

Not exactly, Colliders aren't used anywhere in Decalicious - we need MeshRenderers. When you limit to a GameObject (lets call it "Environment"), Decalicious searches for MeshRenderers in Environment and any of its children (or their children, recursively). The Decal will then be drawn on those MeshRenderers only.
I'm not sure that this makes the Layer thing obsolete, since it may not always be convenient to actually have a common parent for a set of MeshRenderers that you want to limit to, but it may help in your case. Please keep in mind that no culling (especially frustum cullung) is implemented yet, meaning that if you limit to Environment and it has 1000 child meshes, all of those need to be rendered in the internal Decalicious LimitTo pass, regardless of whether they are actually visible on the screen or not. This can make your #Batches explode. Frustum culling for the LimitTo objects should be fairly easy to implement and is high up on the ToDo list.

 

Hey Daerst. Would it be possible to utilise Decalicious shader techniques to draw custom meshes as decals? For instance, given a triangle strip that represents a road, blending albedo/normal data with the terrain underneath from that road?

 

Not possible out of the box, but also not entirely unthinkable. Currently, it's always a box that is 'implicitly' UV unwrapped in the shader. It shouldn't be too hard to replace this with a custom mesh that has explicit UV unwrapping.

 

Hey Daerst, is there any solution blend decals with realtime tiremarks, i try to add decal component but there is nothing....

 

It's not possible to help you with the sparse information you provide. How are your tiremarks drawn? What are you trying to add a decal component to? Have you used other decals successfully? What exactly are you trying to achieve by "blending", what is the expected result and what does actually happen?

 

I just submitted Decalicious 1.4.2 to the store for review. Should be up in ~2 weeks.

• Added frustum culling for LimitTo objects. This should alleviate the LimitTo problems a little. Still, the LimitTo system is work in progress and will be totally overhauled, probably with the 32-groups-max solution detailed above and some other tweaks so that only LimitTo objects that are actually colliding with a decal will actually be drawn. This should then make the "Limit Decals to tiled mesh terrain" case practical.
• Fixed LimitTo functionality in build (Unity 5.6+). And...
• Fixed DirectX 9 compatibility. Hope those two points work as intended now, I've tried both Unity 5.5 and 5.6 with DX9 and DX11 in various settings in build, and everything worked fine for me. If you still have problems there, please let me know!

 

hi, Dearest, here is what i do ,left is the tiremark using unity standard shader with Albedo color and normal map with it, and right is Decalicious shader apply to it, with only normal texture, as you can see, the tiremark disappear. And i am sure your system work with simple plane, so my question is can i make the tiremark like MarioKart8 do with Decalicious, and how?

 

Haven't played MarioKart8, so I still don't know for sure what you're going for, but the problem is that you're setting up the decal incorrectly. Please read the PDF manual that is included with Decalicious. You can't use the system with your own mesh, but need to use the automatic setup - just add the Decal component to an empty game object and everything will be fine. Then make sure that the resulting cube is pointing y-up (green arrow points upwards) and is position so that it contains the ground. You can scale the cube as you like, so as long as your tire marks are simple and straight, this should be it.

 

@Daerst any tips on where to start hunting for issues in shaders? Been using Decalicious for a while, and it's worked fine up to now when I try to use it with beffio's Car Paint 3.0. With this shader, the decal just doesn't appear on the surface. Out of curiosity I tried the shader along with Unity's deferred decal tutorial project - same result. Like there is something in the shader that just makes it incompatible.

Any tips on why a shader would cause the decal to fail?

 

Hey Matt, I guess the shader doesn't use the 'usual' deferred rendering pipeline, but implements its own Vertex / Fragment shader, causing it be rendered after the whole deferred stuff in an extra pass. Some shader packages like Uber work around this by extending the whole deferred pipeline with their own shader, so they work fine with Decalicious. Other custom shaders will be rendered in a forward pass and don't put the required information for Decalicious to work in the G-Buffer. This is just a guess, but if this is the problem, there's no real solution to that I'm afraid.

 

Any way make decals work on mesh with opacity?

 

So I'm having a little trouble with the Limit To functionality in Unity 2017.1. I have a simple ramp model imported from Blender, UV mapped and everything, and a special holder object for my terrain that contains it and a Unity cube primitive. The scene looks like this:



I use the Limit To selector to select the terrain object and the decals all show up fine on the Unity cube, but not the model imported from Blender. However, they all show up find in the inspector, as you can see here. I've gone over the docs a few times trying to figure out if I'm doing something wrong, but I can't seem to find the problem there. If I don't limit the decals to anything, they all show up just fine on the ramp object.

edit: further testing reveals further weirdness. If I replace the ramp with a standard unity cube but keep the Limit To field to the Terrain object, it works perfectly. It just seems that it's affecting my imported models.

edit 2: Stranger still is that they show up fine in the editor window when I limit to terrain, but not in the game view.

 

If you mean objects with transparency, then no. Unity (and pretty much any other deferred renderer) draws transparent objects in a forward pass after the deferred pass, so Decalicious does not have a chance to influence them unfortunately.

I didn't get around to testing Decalicious with 2017.1 yet. If you have a 5.6 installation at hand, could you try with this? Also, I'd be happy to take a look at a test scene that exhibits this error, if you can provide it.

 

After a lot more testing, it seems to be something weird going on with the scene itself. If I make a new scene and import everything the same way, everything works just fine. It's... odd, but I think I can work around it. The demo scene working perfectly no matter what I did to it tipped me off.

 

Decals disappears. How to fix this?

 

By providing more information.

 

Understood with the problem. The problem was due to the parent. Now works well

 

Glad to hear you solved it, thanks for reporting back

 

I havent updated to the newest version yet. Was this submitted with the newest build?

 

No, we're still on the old LimitTo system. Unfortunately I can't make any promises as to when the new system will be finished. If this is blocking your project, please drop me a PM and let's chat.

 

Here's a quick status report on the Target Groups (as I call it by now) feature:

There's a new component called DecalTargetGroups, which keeps track of all the groups of game objects that you want to limit your decals to (recursively, meaning you can put parent objects). Think of this as a Singleton that is easily accessible from everywhere to add or remove objects. Up to 32 groups are supported.


Next, the Decal component, which previously had the GameObject LimitTo, now has a mask TargetGroups. Here you can select all the target groups that you want to render your decal on. The mask value 'Everything' has a special meaning: it will not limit your Decals to all the groups you have created, but it will not limit the Decal at all, meaning that it will also be drawn on surfaces that are in no target group.


This is working and just needs some polishing before it can be pushed to the store (make sure it works with SkinnedMeshRenderers, handle the case where no DecalTargetGroups component has been created, make a nicer inspector to handle the groups, performance considerations, and some other minor things).

Still, I can think of some cases where this system might not be suitable. As a practical example: Let's say we have a character and a decal that is drawn on the floor when the character is selected (like in many strategy games, for example). We now may want to just exclude characters and prevent the decal from being drawn on their feet, but allow all other surfaces. I'm thinking about making two masks to handle this case (IncludeTargetGroupMask and ExcludeTargetGroupMask).
» Is it useful to have these two masks instead of one?

Also, this change removes the possibility to limit a decal to one specific game object (unless you give it its own group, but you're still limited by the 32-groups maximum).
» Is this a bad thing, or is everything you need covered by the 32 groups?

 

That could depend on how easy it is to create/mange groups from code at runtime. Off the top of my head I think I would get a lot more use out of the proposed group masking and can't think of a good usecase that can only be solved with "limit to" in my game.
For people who make an FPS or something like that it might be different. They probably don't want to make a group with just all characters because rendering them all sounds expensive, and they'll easily hit the 32 group limit if they have many characters that can get blood/damage decals.

Depends on what it "costs" us to have that functionality in terms of performance and ease of use.

My main goal for using decals is still terrain, and I'll have a lot more buildings and vehicles than terrain meshes, so this kind of masking (from your example with unit selections or similar stuff) probably would be more expensive then just limiting the decals to the terrain group I'd imagine.


Have you played Deserts of Kharak? I've looked very closely at their terrain and I think they must be using tons of decals or some other kind of magic. In any case it looks really nice.

 

It's basically a list of class TargetGroup, each of which consists of a string for the name and a list of GameObjects. Will make it all publicly accessible via DecalTargetGroups.Instance.

We already have frustum culling, which alleviates this a bit. Furthermore, I would like to render only those objects that are touched by a decal (simple AABB vs AABB check could do wonders for performance, but I need to stress-test this).

Here's a mockup of what I have in mind:

If you disable the checkboxes, the respective mask will be greyed out / hidden and the decal will not be limited to / excluded from any groups. Peformance-wise, you will always have an overhead the more groups you use and the more objects they contain, but once they are drawn, the overhead for the include / exlude logic is negligible.

Will look into it, thanks for the suggestion.

 

Please have a close look at the GDC talk slides for Deserts of Kharak:
http://www.gdcvault.com/play/1024571/The-Great-Divide-Unique-Visuals

 

It is not yet blocking, project will still be in development for quite a while. Planning a pre-alpha version in the next weeks, but if some decals are drawn on units/etc its not such a big deal.

 

Are the strings involved in any runtime lookups or just for editor convenience? I'm worried about performance, which after the masking is my second highest concern.

Can you elaborate on what the AABB checks should do? That sounds like something that could easily backfire in complex scenes where all decals are placed in sensible places (so that the box intersects something). But maybe I just have the wrong idea of what you plan to do?

Thank you so much! This is pure gold! So sad the talk is in the members only section of the vault.
1000+ decals for one map, wow.
Skimming through the slides I see they have a "sorting order" feature for decals. I think I need something like that too. Actually probably everyone who wants to combine environmental- and damage-decals will...

 

Haven't seen that one yet, thank you!

There will probably be a function to find a TargetGroup by name (similar to Unity's LayerMask.NameToLayer etc.), which you shouldn't overuse, but apart from this convenience function, the name is purely for ease of use. The whole system would work perfectly fine without names

Let's say a decal has a mask so that it is only drawn on the Terrain group, which contains 100 individual terrain meshes. The naive approach would be to render all 100 meshes to the TargetGroup buffer (to know which pixels on the screen are covered by them). We can already throw away a lot of those 100 meshes by using frustum culling, but still many of them may be in the view but not be touched by a decal. Therefore, we could draw only those terrain meshes whose AABBs are intersecting any decal AABB being drawn in the same frame. I don't know whether this will be good or bad for performance (and it depends a lot on your game, and where your bottleneck is, as this obviously stresses the CPU but takes load off the GPU), so I will test it and maybe make this an optional feature.

It's on the ToDo list. Shouldn't be too much work, but I don't know when it'll be done.

 

I've pulled the latest version from the store and gave it another try after not having used it in quite a while.

I was trying out to use it for a projected hud element:





The messed up looking one happens when I enable mip maps on the decal texture. Without mip maps it looks better at this angle, but worse at others.

The frustrum seems to be culling the object based on the position of the center of the projection box instead of AABB intersections between frustrum and decal. So I can still see half of the circle on screen just before the decal gets culled. That'll be super noticable in every game that uses big decals. Think of a stain on the floor and it just vanishes when still half of it is on the screen.

 

Thanks, will look into this.

Are you using the 'Limit To' feature? This is the only place where I do custom frustum culling. Everywhere else I rely on Unity's builtin culling, so if you're not using Limit To, the problem has to be something else.

 

No.

My scene is very large scale (that decal spanning hundreds of meters), so if the AABB of your custom mesh for the projection box doesn't get affected properly by the transform's scale, then the AABB would be tiny compared to the visual size of the decal. Just a guess.

 

I can't reproduce this. In a fresh scene with a huge plane (10km) and a huge decal (from the example scene, scaled to 1000m) the Decal is culled only when it's way outside the frustum. Half the decal, with the center outside the frustum, is shown just fine.
Could you try stripping down your scene and maybe simplify the Decal (e.g. just color without texture) and send it to me?

 

Think I found the bug. When I add a decal component to an empty game object in edit mode it looks like this:



but when I add it in play mode it looks like this:





Without the decal cube in the mesh filter the AABB is wrong and the culling messes up.

I do a lot of setting up stuff in play mode because my whole terrain is generated at runtime so I can't do most of the things I want to in edit mode, and all the stuff I want to keep from my play mode experiments I save to prefabs.

Thanks for looking into it.

 

@Daerst having an issue in build for PC. Got loads of decals setup, some use limit to, some don't, there's around 100 in total. In editor and play mode everything works as expected. But in a build, once the camera view moves out of the view of decals, then goes back, the decals that were there originally disappear. Not all of them disappear, just a select amount in a certain area but I'm not sure why.

Checked the output log of the build and this is getting spammed:

NullReferenceException
at (wrapper managed-to-native) UnityEngine.Material:Internal_CreateWithShader (UnityEngine.Material,UnityEngine.Shader)
at UnityEngine.Material..ctor (UnityEngine.Shader shader) [0x00000] in <filename unkown>:0
at ThreeEyedGames.DecaliciousRenderer.DrawLimitToGameObjects (UnityEngine.Camera cam) [0x00000] in <filename unkown>:0
at ThreeEyedGames.DecaliciousRenderer.OnPreRender() [0x00000] in <filename unkown>:0

I've been through each decal and don't see any issues with setup, i.e. no decals that used to limit to an object that no longer exists.

Any ideas?

 

Makes sense, because the Mesh is set in the Reset() function. Try putting everything from Reset() into OnEnable() right above in Decal.cs. This should fix your issue. Thanks for pointing it out, slipped so far because I only instantiate Decals from Prefabs and not really create them in Script (which could also be a good idea for your scenario). Anyway, I will make sure this ends up in the next release.

Could you try making a Debug build? That might make it clearer where the error comes from.
It looks like the error is a null reference exception (i.e. shader not found) here:

Code (CSharp):

1. _materialLimitToGameObjects = new Material(Shader.Find("Hidden/Decalicious Game Object ID"));

but this should actually only be called once per camera, and either work for everything or nothing. Do you have multiple cameras in your scene?

 

Does seem strange that it could find the shaders at first, but they then have gone walkabout and it can't find them. In a debug build none of the decals will work and the above error is spammed again.

I've added the shaders to always included list and it seems to have fixed it. Thanks.

 

Seems to work, thanks for the quick fix!

Regarding the messed up filtering with mip maps which I mentioned in post #236: it seems to be fixable by forcing higher anisotropic filtering levels for the texture of the decal. I had anisotropic filtering globally disabled because I usually don't think it's worth it. Is this a bug or expected behaviour?

Remember the flickering of unlit decals I mentioned in the past? I encountered that again. I still have no repro, but I can tell you it happens only with instancing enabled in the decalicious renderer component, while also having motion blur in the post processing stack enabled, and apparently it only happens when you look at the decal from specific angles. But when all conditions are met the flickering is very noticable, like a broken neon light. And with 100 duplicates of the same decall they all flicker in sync, so either all are visible or none.
Since I can't reproduce it in a clean project with only decalicious and the post stack, chances are something else could also be required to trigger it.

 

Weird, this problem randomly happened before but I thought it was gone Will make it a hard reference in the next release. Thanks for pointing it out and glad that you fixed it.

Great, cheers!

You're looking at a pretty flat angle, so mip-mapping is expected to look not-so-great without anisotropic filtering. You could try putting a plane with the same texture right next to the Decal and see if that looks better. If it does, it's a bug

Instancing. Post-processing stack motion blur. Specific angle. Will try to reproduce too.
Does it only happen for unlit decals or also for deferred ones?

 

I believe in the past I've seen it for both, but the latest occurance was for unlit decals only, the deferred decal next to it was fine. The angle was a more or less normal isometric perspective angle (with a regular pespective camera though - not ortho), so about 30 to 45 degrees down from the horizon I think. I tried to reproduce it in a stripped down project but wasn't able to. It might be hard to find without a mouselook script to move the camera, so maybe drop one in from the standard assets or use the one from your demo scene.
Do you have a hunch what it could be or what I could try to narrow it down further?
I wouldn't rule out that it's not even an error on your end, might be the Post processing stack itself, because I've also seen the entire AO flicker under specific circumstances. Maybe there's something non-deterministic about the order in which certain buffers are written to or read from? I think I noticed that the degree of AO flickering changed when I had a scene view open or not. I'd hate to send you on a ghost chase and waste your time for something that might not be your fault at all. So if you have any idea what I could try first, let me know. I'll check later if there maybe is a better version of the post stack than I'm using. I know the stack itself still has some issues for sure.

 

Like you mentioned, non-deterministic draw order would also be my first guess. Even if it's not my fault, I'd still like to find out what happens. We're using the post-processing stack with TAA (no motion blur though) in our own game and so far didn't have problems with it, despite using the same camera setup that you described. We don't yet have many instanced Decals though. I'll keep an eye open.

 

I just checked the release notes on the asset store and the recent august release (pretty sure I don't have that yet) mentions this fix.
"- Fixed flickering Ambient Occlusion with recent Nvidia drivers."

I'll give it a try and let you know whether it solves it.

 

Ok, so after spending another nerve wrecking hour trying to build a repro case I give up for now. I have it 100% reproducible in my multi gigabyte main project, but when I copy just the relevant parts over to another folder, including project settings, it doesn't occur.

Plus I've narrowed it down so far, that I can add a bunch more items to the already ridiculous list of specifics that need to align for it to occur. It happens under these conditions:
-specific camera angle
-decalicious set to instancing
-post processing stack with options that force generation of motion vectors texture, so... temporal antialiasing or motion blur (you can remove the stack afterwards, so it doesn't seem to be the command buffers)
-part of my player object structure, with Kejiro's brownian motion component on the root (which needs to be set to specific values)
-child object to the player object that has a scale of -1/1/1

Every one of these things seems to have the power to make the flicker go away if I change or remove it...
This is just insane!

My new best guess is that the negative scaling somehow messes with matrices that get passed as a block to instanced shaders and somewhere along the way something goes wrong and the decal shader gets fed the wrong matrix.

For now I'll just not do the -1 scaling thing. It's bad practice anyway and might very well have been responsible for another bug with motion vectors that I thought was unrelated.

 

Good choice. I spent quite some time figuring out why a Decal wasn't visible, bounding box looked fine and everything, until I noticed that it was scaled to -1, 1, 1 because I accidently made it a child of something that had weird scale and dragged it out again. I'll put it on the list anyway, this case should be handled more gracefully. Thanks for all the details!