[RELEASED] Decalicious – Deferred Decal System

Thanks for looking into the problem, but your fix doesn't work, it's actually a different problem.

It's fine to look for hidden shaders as you do it, but the problem is that the shader is stripped out in the build as it's not used in any material/prefab. At least that is my current guess.

I changed the DecaliciousRenderer.cs to have a reference of the GameObjectID shader and attached it to my camera. After that everything was fine besides, that your GameObjectID shader does have a compile error. You have probably never seen it, because it was never included into the builds and therefore not compiled for Windows (DirectX).

Shader error in 'Hidden/Decalicious GameObject ID': COLOR0 must be a four-component vector at line 29 (on d3d9)
Shader error in 'Hidden/Decalicious GameObject ID': SV_Target0 must be a four-component vector at line 29 (on d3d11_9x)

This can be fixed by changing the frag shader part to this:

Code (CSharp):

1.          
2.             float4 frag() : SV_Target
3.             {
4.                 return _ID;
5.             }
6.  

 

Funny - changing the 'Hidden' to something else fixed it for me, even without a direct reference to the shader.
Also, the DirectX error you are pointing out is specific to DX9. I've been using DX11 for all my tests, and there it works fine. I'll make sure to test DX9 too in the future

 

@Daerst, that is indeed strange, but I have researched a little, and the hidden path is definitely a viable solution. Maybe it worked because you have different stripping settings, not sure.

Yes DX11 is compiling fine, but DX9 not and it's really an easy fix to change the "float" to a "float4". I always compile my shader for all platforms, to see if they have any compatibility problems.

 

Any news on this front?

 

Is there a way to limit "Fade" to only Albedo Alpha (without changing other values)?
My mirrors losse the specular when low the "Fade" value.

I need to become transparent with the fade values, but keeping the specular high.

 

Looks good , maybe make a video to better show it off with out having to download the exe.

 

@Daerst is this asset still being worked on? I'm not in a hurry, but I'd like to have some information to plan with. Right now the asset isn't a super great fit for my usecase and I may or may not be able to change that by making some heavy modifications to the code, but I don't feel like exploring that road if there is still a chance that you add the things I need yourself. E.g. The implementation of object masking doesn't work well for me with the highres mesh terrain I'm using because it drives up the number of drawn triangles by a couple million per frame. Also the flickering issue persists in the unfortunate state of not being reproducible enough for a bugreport but happening often enough that it is an issue.
What are your future plans for the asset? I won't be mad if lack of sales doesn't justify continued development, I perfectly understand that the assetstore is financially unviable for the vast majority of developers. I just don't wanna waste a lot of time trying to implement something that for all I know you might have already 99% finished on your end. Cheers!

 

Hey everyone, sorry for being inactive the last couple of weeks. I've been grinding on a project with an April 1st deadline, and still have some rework to do tonight and tomorrow. Starting wednesday, I'll be back on the forums to adress your concerns and continue working on Decalicious. No plans to ditch this whatsoever

 

Glad to hear it . Good luck with your project and don't jump from one crunch into the next crunch. You've earned yourself a few days off, burnout is real. Cheers!

 

Hawing some problems with shadows and HDR camera

any way to get around?

 

If I get you correctly, you can just reduce the alpha value of the albedo color to achieve this effect.

Good idea, thanks!

Will look into it.

 

Yes, but albedo alpha changes ALL of my decals alphas (same material) and I need to change it per object (like Fade on your script).
Ideas?

 

Ah, get it. This is not currently possible out of the box. You can work around it though. The probably best way would be to split each Decal in two - one for the Albedo, and one for the specular part, at the same transform. You can then fade the Albedo only and keep the other one as is. Alternatively, you could create another Fade value (e.g. FadeAlbedo) and implement it in code and shaders just like Fade.

 

I just submitted Decalicious 1.4 to the Asset Store for review. It contains

• a fix for the flickering issues
• a new options for decals to respect light probes (quality) or not (performance)
• manual and slight compatibility updates

Should be up in ~2 weeks.

 

Hello,

I've seen some questions asked about light probes, but just so it's clear to me, does the decals can be seen when there're only baked light and light probes in the scene (no realtime light)?

I've tried the deferred decals demo from unity and when there's no realtime light the decal just vanishes :/

Thanks!

 

I guess you're talking about the deferred decals from here? That's a very basic implementation with lots of errors that Decalicious solves. Decalicious decals will work fine with ambient light, light probes, real-time lights... Feel free to upload a test scene with your desired light setup and I will drop in some decals to show you how the results will look

 

Thinking about purchasing this asset since it appears to be the best performing.

Is it possible to use your material on a custom mesh. For instance having a long custom UV'd mesh go along a model as a decal. I realize it's probably as simple as just using the material, but are there any "gotchas" that I need to keep in mind? Is the shader "assuming" that the decal has projector uv's generated via a separate gameobject?

 

I'm not sure I understand your questions correctly. Decalcious works by projecting a decal (which is a cube, always, in Decalicious) on some other surface(s) (your custom meshes, UVs and complexity don't matter here). You can currently not replace this cube by a "custom UV unwrapped" mesh, if that's what your asking. For what would you need this functionality?

 

For instance having a long continuous un-breaking decal. A rail track would be one obvious use case. Or any continuous seam. Hell, even a EasyRoads trail in a forest. Is this idea so bizarre?

 

One use I could think of would be using a particlesystem to spawn decals for avoiding the overhead of having them be individual gameobjects. Or making a sheet of multiple decal textures and using procedurally generated geometry to create a system of permanent decals where you can draw like 5k decals of varying types and sizes from 1 material, with 1 drawcall. I'm not very well informed about how exactly deferred decals in general are implemented (so maybe this isn't possible), but I'd imagine there'd be lots of potential for performance optimization and getting the numbers up.

 

Ok, got it. This is currently not easily possible with Decalicious. The system works by rendering the decal's bounding box and then, for every pixel in this box, querying the GBuffer and checking if the GBuffer position is actually inside the decal. A "point in bounding box" test is fairly simple, a "point in custom mesh" not so much. Also, given a 3D point that is inside your mesh but not on its surface, it's not trivial to determine the UVs. Anyway, I'll think about it.

I will start working on decal sprite sheets (and probably then also animated decals) soon. There will be no need for custom meshes / UVs

 

But what about the seams. There are already assets that create meshes that conform to an underlying mesh. No need to guess where the pixel is. Raw UV's and just offset the vertices a bit in the shader.

 

The sentence you quoted referred to @Martin_H's sprite sheet suggestion, I'm not saying there's no need for your suggested feature in general. Then again, if you want to create "a mesh that conforms to an underlying mesh" Decalicious as a screen-space effect is not for you.

 

I still get flickering with the 1.4 update at certain camera distances, while using the post processing stack with temporal AA. When I disable the TAA it's fine again.

 

When use a normalmap texture, some decals (instances) invert the normal value (like if you put a negative number) so the texture appear embossed or carved randomly.

 

I am having an issue with "limit to" an object. I want to limit the decals to my terrain only, but when I check the box, the decals disappear. Any help is greatly appreciated.

 

Did you also set the transform that you want the decal to be limited to?

 

I'm not exactly sure what you mean.

 

See the screenshot here (expand the quote and click the link to view the attachement):

Where it says "limit to" you need to put the transform of the object that has the meshrenderer(s) you want limit the decal to. It even works accross multiple meshes if you set their parent transform (at least for me it worked on an older version, didn't test on the newest yet). I'm not sure if terrains are supported yet (the answer is probably somewhere in this thread), my terrain were tiled meshes.

 

I noticed some issues with the normals too, I will look into it.

The LimitTo option currently only works with Mesh Colliders. Here's why: Decals are drawn in screen space after the GBuffer has been rendered. At this point, you can no longer know which object occupied which pixel, e.g. which pixel is terrain. My solution is to render objects that are used as LimitTo targets once more with a special shader, reusing the depth buffer from the screen to write their IDs into pixels they actually occupy on the screen. This is fairly simple for MeshRenderers, will take some more effort for SkinnedRenderers and probably takes some deep-dive into the Unity terrain system to account for LODding, chunking etc. A workaround could be to use mesh terrains. I know this is not ideal, but I doubt that the LimitTo feature will be easy to implement for Terrains.

I will spend the upcoming week in Berlin at Quo Vadis game developer conference - come say hi if you happen to be there The week after that, I will try to sort all the feature requests and bugs into some kind of tracker to get a better overview and make transparent what's being worked on.

 

Interested in Decalicious development, soon-to-be fixed bugs and upcoming features? Check out the ISSUE TRACKER.

I tried to gather everything that is still a topic from this thread. If anything is missing, please give me a hint

To be clear, your decals randomly disappear for a short amount of time, right? The fix that I mentioned fixed color changes from light probees when moving the camera, so your issue is probably not related.

 

Yes.

 

Okay, thanks. Haven't observed this bug so far, but when I come across it I'll kill it with fire.

 

Retrieving array element that was out of bounds
UnityEditor.SerializedProperty:GetArrayElementAtIndex(Int32)
TMPro.EditorUtilities.TMP_MeshRendererEditor:OnInspectorGUI() (at Assets/3rdParty/TextMesh Pro/Editor/TMP_MeshRendererEditor.cs:30)
UnityEditor.DockArea:OnGUI()


NullReferenceException: Object reference not set to an instance of an object
TMPro.EditorUtilities.TMP_MeshRendererEditor.OnInspectorGUI () (at Assets/3rdParty/TextMesh Pro/Editor/TMP_MeshRendererEditor.cs:31)
UnityEditor.InspectorWindow.DrawEditor (UnityEditor.Editor editor, Int32 editorIndex, Boolean rebuildOptimizedGUIBlock, System.Boolean& showImportedObjectBarNext, UnityEngine.Rect& importedObjectBarRect) (at C:/buildslave/unity/build/Editor/Mono/Inspector/InspectorWindow.cs:1229)
UnityEditor.DockArea:OnGUI()

unity 5.6.0f3 and p4

 

I updated to 1.4 today with unity 5.6.0p3 and as soon as I use use an unlit/deferred decal I get this error:
CommandBuffer: material 'BloodDecal' cannot be used with DrawMeshInstanced because it doesn't enable instancing.

Switching off instancing in the DecaliciousRenderer does prevent the error from occuring but my drawcalls jump from 100 to 10k with only one decal.

I guess your shaders have not been updated to new Unity instancing yet, as they do not have an instancing flag.

Looking forward to the new version, as the current one is not useable for me atm.

 

The error clearly points to TextMeshP Pro/Editor/TMP_MeshRendererEditor.cs (lines 30 and 31). Why do you suspect an error in Decalicious?

Unit 5.6.0p3 fixed this issue that prevents a material from being rendered with instancing (which, in my book, should raise a warning instead of throwing an exception and not rendering stuff, but anyway...). Try setting enableInstancing to true on your materials, this should fix it for now. I'll fix this in the next update. Thanks for reporting.

 

I would have done this for sure, but there is no option to set it, as your shaders are probably outdated now.

 

I meant in code, e.g. Scripts/Decal.cs in Line 97 (before renderer.Add) add this line:

Code (CSharp):

1. Material.enableInstancing = true;

As I said, this will be fixed in the next version of Decalicious to also be compatible with current Unity Patch releases.

 

oh sorry, misread that obviously, cheers for the followup.

The error is gone now, but I still have 10k drawcalls with only one decal (90 dcs without the decal) .

 

Hmmm, can't reproduce that (tested with Unity 5.6.0p4). You mean the "Batches" value in the Game view's stats window, I suppose? Behaves as expected for me. Would it be possible for you to provide a test scene?

 

Hey, we're having an issue where if just 1 decal has a 'limit to' gameobject set, it all works within the editor as expected. However within the build, all decals disappear regardless of if they have a 'limit to' object set. When making a build with all the 'limit to' decals disabled, all other decals show up correctly.

 

Thanks for reporting, there currently are known issues in the build, but it's good to know that they are related to the LimitTo option. I will look into this asap (hopefully this weekend) and try to fix it, seems the be the most severe bug in Decalicious right now.

 

Seems instanciated decals are broken on the last Unity update.
I get this error after update Unity to latest Version 5.6.1f1

CommandBuffer: material 'myMaterial' cannot be used with DrawMeshInstanced because it doesn't enable instancing.

 

See here: https://forum.unity3d.com/threads/r...erred-decal-system.442135/page-4#post-3066057
A fix for this is submitted to the asset store and should be up next week.

 

Ah! Ok, I missed this post.
Now works again.
Thanx

 

I can't get this to work in 5.5.3. Nothing shows up at all - even in the demo scene the decals don't show. I am definitely set to Deferred rendering (with Linear Colour Space).

EDIT: False alarm. Unity had set itself to DX9 for some reason.

 

Sorry have been on vacation for a few days. I know what is actually happening.

I am talking about the batches value in the stats window which I call drawcalls (dc's).

I have a 3d tile map with a 100x100 grid, each grid has currently it's own 3d tile which are 10k tiles. The tiles are parented to a terrain object and the decal has the terrain object set as the "limit to" object.

The tiles use all the same material which also uses instancing so my dc's for the terrain is below 50, even when I zoom out quite a bit (which is only necessary inside the editor of the game).

As soon as a decal is visible, each tile seems to have i'ts own dc, even though there are not even visible with the current camera. I have thought setting the "limit to" object of the decal to the tile respective tile, but decals might obviously be visible on more than one tile so I cannot set a limit to object without creating new gameobject which parent those tiles.

 

@DwinTeimlon Good point. You are probably using static batching for your terrain tiles, right? The LimitTo feature currently does not utilize this, so each mesh is drawn individually with its own draw call. The material and its parameters are not changed though, so it's just draw calls and no extensive state changes, so it might not be as bad as you expect it to be. Still, it's not nice behaviour on Decalicious' part and I'll see if I can find a way to knock the nonsense out of it.

 

I don't use static batching, only instancing, it has far less draw calls compared to static batching.

The render time increase is significant. From 1ms to 7ms as soon as a decal is visible. As I have hundreds of moving units on my game, I cannot waste 6ms per frame just for the decals .

I probably have to look for another solution then.

 

Hi, My target platform is PS4 and when I build my project for it I get the following errors;

Shader error in 'Decalicious/Deferred Decal': Program 'frag', 'COLOR' is not a valid semantic for pixel shader output 'outAlbedo' at line 62 (on ps4)

Shader error in 'Decalicious/Deferred Decal': Program 'frag', 'COLOR' is not a valid semantic for pixel shader output 'outEmission' at line 62 (on ps4)

Shader error in 'Decalicious/Deferred Decal': Program 'frag', 'COLOR' is not a valid semantic for pixel shader output 'outNormal' at line 104 (on ps4)

Shader error in 'Decalicious/Deferred Decal': Program 'frag', 'COLOR' is not a valid semantic for pixel shader output 'outSpecSmoothness' at line 104 (on ps4)


Compiling Fragment program
Platform defines: UNITY_ENABLE_REFLECTION_BUFFERS UNITY_USE_DITHER_MASK_FOR_ALPHABLENDED_SHADOWS UNITY_PBS_USE_BRDF1 UNITY_SPECCUBE_BOX_PROJECTION UNITY_SPECCUBE_BLENDING UNITY_ENABLE_DETAIL_NORMALMAP
​

And the decals show up purple in the build
Any ideas if/how this is fixable?