[RELEASED] Decalicious – Deferred Decal System

Decalicious is here to satisfy all your longings for fancy Deferred Decals!​

► Asset store link

► Download the playable Demo

What is this?
Deferred Decals are a way to add detail to surfaces, using the full power of the Unity lighting pipeline. The decals are projected onto surfaces in a user-defined bounding box and can be applied on top of complex meshes and terrain. Common uses include (but are not limited to) bullet holes, blood, footprints, dirt, stains, graffiti, holes and cracks, painted labels and rust. Check out the demo (link above) to get a feel for what decals can do.

Example images

Spoiler: Example images

Feature overview

• Deferred Decals: Modify albedo, normals, specular and smoothness for a plethora of effects
• Full Lighting & Reflections: Thanks to Deferred Rendering, full lighting and reflections come cheap
• Dynamic Transform: Decals can be dynamically spawned, moved, rotated and scaled, and are culled and batched for maximum performance
• Limit Decal to Game Object: Choose whether a Decal should be drawn on every surface in its bounds, or be restricted to a specific GameObject's surfaces.
  
• Works with Terrain: Add detail to your terrain or use decals to get rid of those hard mesh-terrain edges
• Editor Placement Utility: The Decalicious Utility helps you place decals quickly in the Unity Editor
• Unlit Decals: In additional, Decalicious supports unlit decals for world markers, UI and effects

Requirements
Deferred Rendering is required for deferred decals to work, obviously. The package was submitted using Unity 5.5.0 because the example scene was built with it, but works fine from Unity 5.4.0. It could probably be adapted easily to work with earlier versions, so let us know if you'd need support for older Unity installations!

Roadmap
Decalicious is a brand-new system and is actively developed and tested in our own titles. The initial price of $15 will be increased as more features are added.

► Issue tracker

 

Looks pretty cool, but I can't access the asset store link. Maybe it's still being reviewed?

 

@christoph_r True, the package has only been submitted for review today, so it will be about 2 more weeks until it is available. Please stand by ;-)

 

Sexy, but does it work with POM in popular shader sets like UBER? Does it work in the absence of a primary light touching them?

 

@hippocoder Decals are drawn fine in ambient light / without primary light. The package hasn't been tested with UBER, and since I'm not familiar with the details of how the technique works, I'm not sure whether it works with POM. I'm gonna investigate and get back to you.

 

Sounds/looks cool, do the decals batch?

 

@punk Proper batching is pretty high on our ToDo list. We will implement batching for decals that only draw Albedo in the next weeks - first or second update I guess. Batching for decals that draw normals is more peculiar, because we need to make sure that they don't overlap. We're working on it

 

Cool sounds great

 

@hippocoder Here's an example of a decal partially in ambient light on an UBER POM shaded sphere. Works

 

Sexy innit.

 

For what price will this initially be released and do the decals batch dynamically? Will it be possible to have a "sheet" of multiple decals on one textureset? And will the source be available or will there be DLLs in the package?

 

I did (surprisingly) find performance issues in the demo if I sprayed enough...

 

I tried that too now and can confirm: on a gtx 1060 the fps drops super low (below 20fps) when I instance roughly the amount of decals I'd want to use (many).

Is that a technical limitation of the deferred decals that they don't get batched dynamically?

 

The initial price will be 15$.

Dynamic batching is our top priority now and is not yet in the demo. The main reason for the performance issues is that the bullet holes write to the normal buffer and, to ensure proper blending, a copy of the buffer needs to be created for each and every single bullet hole. Yep. Dynamic batching will improve on that heavily. You can expect it in a couple of weeks.

Decal sheets (multiple decals per texture) will be included after dynamic batching works, along with an option for animated decals.

Lastly, there are no DLLs in Decalicious, it's all open source. Just in case we are too slow for you, which I hope we won't be

 

Is it possible to add decals that only change the normals?

 

@StaffanEk Yes, that's possible. Check out the downloadable demo, the 2nd display panel features a decal that is decomposed into its Albedo and Normal components.

 

@Daerst

Cool stuff. Any plans on adding basic Unity parallax support. How do the decals work with lightmapping? Do they rely on lightprobes, or do they simply use the underlying lightmap?

 

I don't understand why a copy of the buffer is required?

 

I need emission on my decals, will that be inplemented?
Let's say I want to add custom shaders to the decal, will you provide a through guide for integration and add some macros to help?
I have amplify shader editor that support custom nodes, will that be integrated to create custom shader to work with your decal?
How does your decal position on a skinned mesh placed in runtime? Does it anchor to the world position? Local Position? Specific transform?
Will there be support for tessellation? Some example would be nice.

 

No plans for parallax support currently, hard to do technically and not worth the effort I'd say. Lightmaps are baked to static geometry, so decals won't receive them - only dynamic lighting. Decals will use lightprobes for reflections.

Decals are clipped based on normals, so we need access to the normal buffer. You cannot bind an output texture as input in a pixel shader. Furthermore, you cannot use default blending for normals, so a copy of the normal buffer is created and used as input for manual blending. While this is no problem if one copy is created, it's really performance-heavy when it's done per decal. As I said, this is gonna be fixed in one of the first updates.

There is a downloadable demo that you should check out, it will answer some of your questions.
You can set an HDR color for the Albedo to simulate emission. Decalicious uses the default Unity deferred pipeline, which you can replace with your own, but you cannot put a 'custom shader' for the decals. That's not how it works.
Decals are just Game Objects that can be moved freely or anchored to any parent, as you like. The decal will be applied to all geometry inside the decal's bounding box (when the normals are sufficiently aligned with the decal's orientation). There are decals on dynamic objects inside the downloadable demo, and you can also shoot bullet holes in moving objects. Also, you should check out this talk that provides a lot of infos on what exactly deferred decals are, what they can and cannot do.
The decals are applied after the GBuffer is done, so they should work with tessellation without problems.

 

Thanks for the answer. What I meant by tesselation support is whether the decal themselves can have tesselation.

 

@yc960 Currently not. Could you point out an example where this would be beneficial?

 

let's say the decal is spiky, if the shader does tesselation, it would appear somewhat spiky instead of flat. Like splinters for bullet hole.

 

Decals are applied to existing surfaces. No geometry is drawn, only existing geometries are modified in the GBuffer. You can use normals to fake spikes to some extent, but what you are asking is beyond what a Deferred Decal system can handle.

 

That is why I asked for tesselation as I thought that might bypass this limitation, and regarding HDR albedo as emission, it only worked if the surface is well lit.

 

True about the emission. I think this might be an option worth adding.

 

@Daerst: thank you for all the details. I'm starting to think I'm just not searching for a deffered decal system, but for one that generates meshes that conform to a surface. Something like this:

http://blog.wolfire.com/2009/06/how-to-project-decals/

Is that an approach that you plan on adding some time in the future? If the mesh generation is separate from the shader it should be a lot easier to integrate with custom shaders, right?

 

That doesn't seem right. Lightprobes and reflection-probes are completely different. I asked about the lightprobes. The ones that don't add reflections.

 

Decalicious doesn't generate meshes but works completely in Screen Space, so mesh generation won't be added in the foreseeable future, sorry.

You're completely right, seems I was still asleep when I answered. So, decals use reflection probes for reflections. About light probes, I'd think they work fine, but can't guarantee it right now. I'll test this and get back to you.

 

@StaffanEk Here is something for you:

Spoiler: Decal on dynamic Teapot with Light Probes

@hippocoder @Martin_H and all others concered about performance in the demo: We have, in the meantime, implemented dynamic batching of all decals. For normals and spec/gloss, this means that when two decals overlap, they cannot be properly blended. We included an option per decal to fall back to the old, performance-heavy way of making partial copies of the GBuffer. If this is only enabled very selectively on artist-placed decals, it's no problem performance-wise. So far, this seems to work really well for us, it just needs some bugfixing (error when batching more than 1023 decals at a time ) and then will be pushed to the store immediately once the package is accepted. Together with 'decal sheets' that allow you to have multiple different decals with the same material, this will make the system hugely more powerful.

Spoiler: A thousand bullet holes with batching

We will update the downloadable demo shortly. Thanks for your feedback!

 

@Daerst Looks and sounds great.

 

Good to hear you are working on it! Thumbs up!

How bad does it look? I'm asking because that sounds like a pretty common scenario to me.

If they can't overlap each other it still might not be practical, depending on usecase.

It's good to see the performance having improved much, but I have a feeling that 14.6ms (your screenshot) for an almost empty room still is too much of an impact.

 

First of all, please note that blending of the Albedo part works fine with batching - just in case that wasn't 100% clear.

Upright normals are clipped, meaning that everywhere where your normal map has upright normals, everything's cool. Here is a worst-case scenario with a bad normal map that has a very broad 'fade-out'. The top decals are batched and don't get proper blending, meaning that the second decal to be drawn (right one) will overwrite the normals of the first (left one). The bottom decals use high-quality blending, meaning that normals of the first decal are taken into account when the second is drawn. With carefully crafted normal maps, I think you won't run into trouble with this, and for special cases, you can still use the high-quality blending. Still, we will try to improve on this.

Spoiler: Normal comparison

That's CPU time, mainly spent with waiting for the next V-blank, and has nothing to do with Decalicious itself. GPU time is way lower. The 1000 bullet holes take up something around 1.3ms on my machine (compared to the empty room). Here are my stats for a blank, new scene:

 

That doesn't look too bad, if the albedo is still blended correctly it's probably even less noticable.Thanks for the example!

Ah cool, that's good news! Maybe you should disable vsync for performance tests.

 

I totally should, good point

 

Great stuff, looking forward to having a play

 

I have another questions. Is there a way to limit what a decal projector is projecting on? Like for example I have terrain with vehicles and buildings on it, the buildings have concrete foundations and a big explosion hits the terrain near a building on a foundation. Theoretically the terrain would need a dirt-crater decal, the concrete foundation a dark burn residue decal, the remains of the collapsing building no decal, and then a vehicle drives over the blast area - through the decal projectors - but should also not be affecty by the decals at all. Is that possible?

 

Seems like this should use the Unity layer or tag system

 

The decals modify the G-Buffer. By the default, once you have this G-Buffer, you have no way of knowing which pixel stems from which object, and thus no chance to influence only individual objects. Here are some thoughts:

1. You could add multiple cameras (same position, orientation etc.) that render special layers. Put your objects and decals on the same layer and the decal will only affects those objects. When HDR is enabled, each camera renders its own individual G-Buffer and applies effects (such as Decalicious) before 'merging' into the master G-Buffer. For some reason, this does not work when HDR is not enabled - only the last camera is visible. Does anybody have an idea why this happens? Multiple cameras with render order through the depth parameter and different layers in deferred shading without HDR don't seem to work properly, also in a blank scene without Decalicious. Anyway, here is a small example image:
   
   
2. This setup from 1. might quickly get reaaaally clunky. An alternative could be to render the scene with a replacement shader that writes tag, layer and objectID (and we have room for some 4th thing, maybe some predefined categories like static / dynamic / skinned mesh or something) into a screen-sized texture. You could then restrict each decal easily, so that it is only applied to specific stuff you need. The downside is that you need to render one more pass of the scene (or the interesting objects at least). Depending on your scene, this may or may not be acceptable, so I'm thinking about trying it out and including this in Decalicious. I'm happy to talk about workflows you'd have in mind for the pretty complicated scenario above

 

I don't think #1 would be an ok solution. 2# sounds more interesting, but there still are edge cases that I can think of, where the solution would fall apart. E.g. a tank can consist of 3 meshes: body, turret, and barrel. It would look weird if the turret rotates and the decal is "stuck" to either one of the moving parts and slides over the other. I think I probably just need to stick with mesh decals that are precisely wrapped around the individual geometry that they should affect.

 

Create one decal per mesh, make each one a child of the respective mesh, set it to only render on the respective mesh Should work great I think.

 

Wouldn't that break batching though?

 

With the approach no. 2, all three decals could be rendered in one batch I think. I will just implement it and see how it goes in practice

 

► We just updated the playable demo of Decalicious - grab it here!

Contains all the dynamic batching updates. Please let us know if this solves the performance issues you had Thanks!

 

I'm happy to report that in the new demo I can't get it below 60 fps. So with the current despawn rate of decals and rate of fire of the gun, whatever the max amount of decals is that I can spawn that way it handles nicely at 60fps, great improvement!

One issue I still noticed is that the despawning of decals does something to the render order of the remaining decals. So if you lay down a long row of them that all are overlapping each other, once decals start despawning something happens like the one that gets drawn last (on top of the others) switches 1 step backwards with each decal that despawns. Or something like that, I can't quite tell for sure by just looking at it.

Did you already do something to limit projection onto other meshes? I tested near some corners, edges and the moving pendulum and was positively surprised by how little overlap artifacts I was seeing.

 

Thanks for pointing that out, I will look into that!

Nope, that's just the basic mechanics. Projection is currently clamped at 60 degree (fixed, but will be configurable soon), meaning that if the angle between decal orientation and normal of the surface is more than 60 degree, the decal won't be drawn on it. Also, the bounding boxes of most decals are pretty flat, so they don't affect too much geometry.

 

Will there be some way to influence the order in which certain groups of particles are drawn? E.g. if I have dirtroad decals, tire tracks and explosion craters, all as deferred decals, can I set it so that they will always draw in that order?

Any news on when your asset will go live on the store? You've convinced me to give it a shot. Also I noticed the shader I'm currently using doesn't batch and that's not gonna work out in the long run.

 

The thing I'm most concerned about is limiting the overlay to specific objects/groups of objects. There's a way to mask out specific materials using a custom shader as seen here, but while this solves the issue in cases where you don't want materials affected by any decals at all and would work as a quick-and-dirty fix, it's an all-or-nothing kind of thing (and not very elegant). I think a real solution to aim for with this should allow (as an example) one decal for a cracked line in the ground to ignore a character stepping on it, while a second decal for a dirt-speckled texture, placed on the character's shoes, in turn ignores the ground. Ideally, a third decal might be able to affect neither, or both, as appropriate.

I like the idea for the slider on the material, as per the linked example (this per-material decal opacity setting would be useful in the final solution, perhaps), but think the logic for "which decals affect this material" needs to be extended to some form of ID groups rather than global like this. The multiple-camera idea works for the decals themselves, but layers (which are the premise there) aren't really the best indicator of how you want decals to affect things, because "what affects what" in terms of drawing decals is completely different from "what affects what" in PhysX, and you can't really have it both ways. Also, and correct me if I'm wrong, but adding a new camera for every decal grouping is going to get quite heavy, really fast, especially if each character on the screen need their own group for dirt/blood spatter and such.

Since deferred decals are essentially post-processing effects (to my limited understand), I get that this is a tricky situation, but as it stands any decals that have a bounding box large enough to account for curved surfaces (which is the primary point of using them over standard flat decals) will have adverse interactions with the world/characters around them, especially in a third-person scenario.

Anyways, looks great so far, and I'll likely be buying the asset immediately when it goes live, but I really hope that this aspect is given a decent priority because I don't think the system would really be usable in most real-world production scenarios as it stands, sadly.

 

Since you pointed out that despawning bullet holes mess things up, draw order is something that I need to look into anyway. A 'priority' will probably be included then I think.

Pending Review since Nov 21, 2016. That's about 12 workdays, they 'usually' get it done in 10, so I hope it will be accepted very soon

Decalicious is used in development of our upcoming game SWARMED, so we too have a strong interest in creating a real-world usable system. I already have plans on how to solve this and will start working on it soon. I will try to go for a 'minimally invasive' solution that does not require you to change your shaders or use custom shaders for the deferred pipeline. Expect some results soon

 

has the layed decal exclusion system been inplemented for this release? This is extreme important for my project.