[RELEASED] Decalicious – Deferred Decal System

I feel like I should mention the decal was not in that hierarchy with the -1 scale. Under the root it looked like this:

Code (csharp):

1.  
2. decal
3. player
4.         object
5.         object scaled -1/1/1
6.  

the decal was scalled something like 1000/1000/1000 and not under any other object in the hierarchy

edit: sorry for the weird code tags, I don't know how to properly indent otherwise.

 

So a totally unrelated object with negatives scaling makes the instanced decals flicker? Wow, that's quite something...

 

Yup. And even a change so minor as selecting all the objects left in the scene, dragging them in the hierarchy as a child of a newly created but not centered empty game object, and dragging them back out again, made the flicker go away. So even floating point accuracy might be at play.

 

I finally updated Unity to 5.6, my older version seemed to still have a bug with multicam setups. I experimented with the multicam idea a bit, but I think there's a showstopper there: when I only render the Terrain on one cam, all the shadowcasting is broken since I need all objects to cast shadows onto the terrain. I'll chalk that approach off as impractical.

My terrain system is still going through iterations, and at the moment I have the mesh-size of it down pretty low, so it's just one mesh with ~63k verts. That means it's now no big deal (neither in polycount nor drawcalls) to draw that once again for masking stuff to the terrain. If I can avoid adding too many other meshes to the terrain that need to be rendered for masking, I believe I can now just use the limit-to feature for my terrain as intended, without major downsides (at least I don't see any at the moment).

What's the current status of general development of this asset, and how is the status of a feature for a "sorting order" of decals so that I e.g. could force damage decals to be always drawn over paint marking decals?


I've recently stumbled over this:
http://aras-p.info/blog/2010/01/07/screenspace-vs-mip-mapping/
I can't quite remember where we were with my bugreport about "weird edge artifacts", but that looks exactly like what I was seeing, so I believe it could be useful to you.

 

Please excuse my neophyte attitude but it seems I'm meeting a problem that may be due to my lack of experience with Unity but in doubt, I'd rather share it there for other neophytes.

So, I've follow the documentation pre-requisite in order to use the decals properly. Despite doing that, the moment I turn one of my material on this shader, it turn invisible. I'm actually looking to use this deferred decals just as they used them in Star citizen. So far i've been spending a good full 24h and even after waking up I still can't figure out where is my problem... .

I added some screenshot to show my problem... . Again sorry for my lack of knowledge.

 

You are trying to apply your decal material to your own mesh, right? This kind of deferred decal solution is designed to be applied to boxes that project the decal onto uneven surfaces, one decal per projection box. For the type of decal-use that Star Citizen has, there is an open source solution aimed more specifically at that usecase:
https://bitbucket.org/bac9/shading
I would suggest to try to use the open source solution to do detailling decals like in your screenshot, and use Decalicious for damage decals like bulletholes and burn marks. These are situations where you will want to project details onto uneven surfaces and that's where screenspace deferred decal solutions really shine.

 

Oh now I get it! Thanks a lot for the link, it did exactly what I was looking for and I played with some Decalicious to spice up my landscape! Work just fine! Must have! Thanks!

 

Great to hear that, thanks for reporting!

First of all, I'd like to say thank you for your continued interest in this asset. Development is still dragging, unfortunately, due to various things that eat up a lot of time (most of all moving into a new apartment and preparing for recording studio next week with my band #shamelessadvertising). Both of those things should be more or less settled by the end of the month, which will massively free up my calendar. Anyway, the sort order thing is not a huge task, so I will try to edge it in as soon as possible. I'll get back to you.

I applaud your excellent choice of words. Glad you sorted it out with @Martin_H's help, I'll make it more clear in the docs that the Cube is required for Decalicious to work properly.

 

Thanks for the link, I'll look into it. I'm not so sure this has to do with Decalicious though, but maybe even with Unity's default shadows. Look at this example (basic scene with just a plane and a cube, glitch happens only at specific resolutions):

 

Moving is a real pain, I hope it all goes smoothly and good luck with your recording sessions too! \m/

Cool, PM me if you want me to beta test the new feature.

Since you have a repro case, maybe you should submit it as a bug report? This doesn't look quite right to me.

 

Hi, I'm researching whether deferred decals will be a good fit for our project.
I've played around with the basic deferred decal system from the Unity documentation and noticed that if the camera near plane goes inside a decal bounding-box then the decal disappears. Is this something you have fixed in your implementation or is it something inherent to deferred decals in general?
Our project demands that the camera can get very close to decals on very organic objects(read non flat).

 

This issue is not present in Decalicious

 

@Daerst I just noticed in the latest version of unity reflection probes have stopped working in VR single pass on the decals, they're off set

 

I'm having trouble with the decals not appearing in playmode when the object they are limited to or the decal itself is set to static. Is this a bug?

 

Thanks for the report, I will see if I can find the error.

I tested it and can reproduce the error. It doesn't matter whether Decals are set to static (there's really not benefit to it, so they shouldn't be), but as soon as there is more than one static mesh visible that is a target of LimitTo decals, decals are vanishing. If you turn off Static Batching, decals are drawn as they are supposed to. I will look into this asap, thanks for reporting!

 

Just FYI:

In Unity 2017.3b08 I get the following compile errors:

Shader error in 'Decalicious/Unlit Decal': not enough actual parameters for macro 'UNITY_ACCESS_INSTANCED_PROP' at line 49 (on d3d11)

Shader error in 'Decalicious/Deferred Decal': not enough actual parameters for macro 'UNITY_ACCESS_INSTANCED_PROP' at line 65 (on d3d11)

Shader error in 'Decalicious/Deferred Decal': unrecognized identifier 'UNITY_INSTANCING_CBUFFER_START' at Assets/Plugins/Decalicious/Shader/DecaliciousCommon.cginc(60) (on d3d11)

You can find the relevant changes here:
https://unity3d.com/de/unity/beta

 

Thanks for reporting, and also for the link! I'll make a patch asap.
Have you already fixed this for yourself?

 

Yes I have fixed it already, thanks for the fast reply.
Any chance for an update with all the fixes from the above threads?

In case you don't know yet. The UNITY_VERSION for the current beta (2017.3b8) is 201730

 

I've added user-defined decal render order, added emission for deferred decals, added a fix for the 2017.3 changes you mentioned and fixed an error occuring when creating Decals from scratch in Play mode. Just need to update the documentation now and assemble the package, hope to get this done tomorrow

Next up on my list are a fix for the 'limit to multiple static meshes with static batching' error, and a new implementation of the Limit To features using the mentioned Limit groups (up to 32) that will make things a good deal more flexible while also not clashing with layers that are probably already in use for various other things.

Anything I've missed?

 

Sounds good so far! What about the idea of decal sheets that has been discussed before? Is this something that could get setpass calls down? Could it give a performance boost in addition to instancing?

 

Decal sheets could reduce setpass calls, but I think the performance gain will not be super huge, unless you use 1000s of different decals. As a coold side effect, we could get animated decals, which I'm really looking forward to. Technically, the shader changes required to do this would not be huge (just add offset / tiling to the per-renderer data), but to make it really fun to use, we'd need a sprite sheet editor, options for driving animations etc. I wouldn't want to push a half-baked solution, so it won't be included in this next update. But it's on the roadmap

 

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

• Added Decal Render Order. Instead of using an enum (that might not exactly fit your needs, and then you change it, and with the next update your changes get overwritten again...), the RenderOrder field is a simple int. Low numbers are early, high numbers are late. This feature is pretty cheap, but breaks instancing – only Decals with the same render order and with the same material are drawn together. I will further work on batching with different RenderOrder values.
  
• Emission for Deferred Decals. Like all dynamic objects, Decals cannot cast light into the scene with Enlighten, but they can be used for great effect in combination with an HDR cam and Post-Processing Bloom.
• Fixes for the creation of Decals in play mode and compatibility with the latest 2017.3 beta.

 

I think it's up already, I got an assetstore notification mail.

Thanks a lot for implementing those! Int for the order should work fine. As long as instancing works with items that still have the same render order I don't expect any issues, as I was only planning to use the order for rough grouping of decals into things like ground details, things painted onto the ground, bullet holes, craters, etc.. Emission could come in handy to have some tiny glowing spots in smoking craters.
I don't know when I'll have time to check it out, but I'll let you know in case I find any issues.
Cheers

 

@Martin_H Wow, the asset store team is moving fast! Let me know if you find anything, cheers

 

I was using other decal system but recently when profiling found out that the decal system was doubling Camera.Render calls (for each camera's onPreRender event , it copies camera setting from the camera and renders the camera with replacement shader).

Does Decalicious work the similar way( like drawing the scene with replacement shader to get depth buffer, etc) ?

 

Decalicious by default does no such thing. The system just renders a cube for each decal and, for all surfaces inside this cube, modifies your G-Buffer accordingly. This requires you to use Deferred Rendering.
The only thing where geometry is rendered extra is when you use the `LimitTo` feature. This allows you to restrict rendering of decals to specific surface. This information is by default not present in the G-Buffer, so the geometry that you are limiting decals to needs to be rendered a second time with a custom replacement shader. However, we're rendering specific meshes and not doing a blind Camera.Render.

 

I've heard Scriptable Render Pipeline makes it a bit more optimised, is that the case for your asset as well? Would like to test if you're doing that

 

Thanks for the detailed information. The way decalicious renders makes more sense to me. I'll give it a try shortly.

 

The Scriptable Render Pipeline is not yet utilized in Decalicious as it's still in experimental state. Nevertheless, I hope to find the time to take a look at it and weigh the potential benefits shortly.

 

Hey there!
I'm looking for a solid solution to rendering few thousand or so decals on gpu tessellated terrain (craters, water, etc.). I'm currently balancing between Decalicious and 2 other decal solutions. One of them does not support this and the other one works in theory but its in beta state at the moment.

Should there be any issues with this use case? I'm assuming you're rendering the decals last so it would work but I want to make sure.

 

BTW, Regarding terrain masking from other renderers:
Perhaps you could take advantage of terrain's height data and clamp out pixels based on that?
You could generate a shared heightmap texture for decals that want to render on particular terrain. Then only render decal pixels that are below or very close to terrain height value -> objects above terrain are not affected by decals. Concept would be very similar to z-depth testing but using terrain height and testing in against fragment's world y position.

I used something similar to smoothly blend mesh renderers to terrain and it worked pretty well there. Downside would be keeping a float height texture on gpu even if only one decal used terrain masking.

 

No problem with GPU tessellation. Decalicious batches Decals, so a few thousand of them should also be no problem (unless they are all unique, then Decal Sheets would come in handy to reduce batches, but they are still WIP).

Good idea for terrains. I'll put it on the roadmap and think about whether incorporating this technique with the other changes I'm making to the Limit system will be beneficial. Thanks!

 

Hey bud, did you know that decals with limits (limiting decal projection to a gameobject) on tesellation heavy mesh doesn't work very well? Once I remove the object limit, it works fine, but as soon as limits are set, decals sort of stay below the mesh and stay not so visible. I can see the decal when I reduce the depth of tessellation to the point of it being flat...

 

Good point. For the Limit function, meshes are rendered a second time with a replacement shader. This shader doesn't use tesselletation so that's where the problem comes in. Could you tell me what kind of shader you are using - a custom one, or some shader from the store?

 

I was using UBER shaders.

Also, I was just wondering if you would add the following options:

1. Layer specific limit (Based on layermask)
2. Allow limited to the gameobject and its children. (If one object is split into two, then this would be nice)

 

Thanks, will try the Limit feature with UBER.

Probably not, because (and this is a personal reasons that you may feel different about, so I'd like to hear your opinion!), the layer is already overused. It's used for physics, for full camera culling, and you may already have to combine and do ugly things like a TransparentClickableOutlined layer (something that ignores visibility raycasts, but receives player click raycasts, and is rendered by a special camera with post effects to have an outline when selected). I wouldn't want to throw Decals into this mix. Additionally, for n layers, layer-based culling requires you to have n additional calls to Camera.Render, which might or might not be excessive. Maybe I'll quickly prototype it and see how it behaves. The system that I have in mind (not implemented yet) gives you full flexibility by giving you up to 32 Limit Groups, i.e. lists of GameObjects that you want to limit to (including child objects). You can then use this however it fits your need then. What do you think?

This is already done, by default. Only supporting MeshRenderers for now the, other types like SkinnedMeshRenderer are on the roadmap.

 

I see why you say that and for most part, I feel your solutions works best for static mesh, but consider the following scenario.

1. Decal is used to show burns from a grenade explosion on a terrain that has multiple objects (separate mesh)
Under the current implementation, the objects need to be either a child of the terrain (and have limit set to the terrain) or have no limits. But without the limits the burn decals will show up on player's foot as well (when the playter moves on top of it)

2. A list of gameobjects for limits is implemented (I want this feature but it also has downsides...)
For every instance of decal, we have to compute what needs to be included in a list, if a machine gun makes bullet hole decal for each bullet hit at a realistic rate of 15 rounds per second (A good average of modern assault rifles) and let's assume that there are multiple shooters, the amount of raycast computation for determining which objects to be added to the list could get out of hand real quick.

I've shipped a game with Decalicious and is in making of another one with it. These things that I am mentioning, were real concerns I had during development. If it is possible, maybe you could provide multiple ways for limiting decals.

I personally consider Decalicious "Production-Ready" so I really appreciate that you are adding more features.

 

Quick suggestion. What if layers were used to determine what needs to be entered to the list of gameobject limits?

So for example, upon spawning of any decal, we would have to compute what needs to be added to the limit correct? What if we added all objects to the list (I am assuming collision/trigger detection) and filter it with layermask instead of doing n layer computation on the camera.

Wouldn't this resolve the performance issue?

 

Good suggestions, thanks @jjejj87! I'll try to work this is when implementing the new system.

Great to hear that you have released a game with Decalicious! Would you mind sharing the title?

 

I do mind publicly, I can pm you.

 

Hi I bought this plugin and I'm trying to use it in a VR project. Currently I have an issue, decals only show up in one eye while playing with an Oculus headset (haven't tried a different headset).

Any suggestion? Thanks

 

Decalicious has not been tested with VIVE or Oculus, as such VR support is still on the roadmap. You could try using single-pass stereo rendering, maybe that helps. Also, I think there are others successfully using Decalicious in VR. Can somebody provide some insights, maybe?

 

They do work in single pass just reflection probes are wrong

 

Hi! After upgrading to 2017.3, Decalicious decals stopped working. Is there a quick fix on the way?

Cheers!

 

It works fine for me in 2017.3.0b8, haven't tried the release version yet.
Which version are you using exactly?
Are you getting any warnings / error messages from Decalicious?
Are you spawning Decals at runtime?
Could you post a screenshot of a Decal in the inspector (please fold out all components and Materials on the MeshRenderer)?

 

Hello! After reimporting Decalicious in 2017.3, it works just fine.

 

Any plans on allowing the shader to work on pre modelled decal planes? It would be greatly appreciated

 

@Perlind-Arts Could you explain in more detail what you mean, and maybe make a quick screenshot / mockup? Thanks in advance

 

So rather than projecting the decals onto the world, we want some of the decals to be already modelled in, uv unwrapped etc. Then rewrite whatevers underneath in the gbuffer like with deferred decals.


Take this scenario, left is the mesh with the decals on top, on the right is the decals themselves.
Games like star citizen use this technique extensively to save on needing large textures to get small rivets and bolts on their models.
Cheers.

 

Ok, got it. Thanks for the explanation. This will require some refactoring, but all in all shouldn't be too hard. I'll add it to the roadmap