[RELEASED] Decalicious – Deferred Decal System

You mean that decals are only applied to specific layers? You can use the workaround from my reply #39 for now, if it's onlya couple of layers. Also I'm currently implementing a more flexible and handy system. Think it will still be finished this year.

 

The package was declined because I forgot some important stuff in the documentation. I just now submitted a new package (with instanced drawing this time!) for approval. I hope this will be a quick one so that you can check out Decalicious soon. Sorry about that!

 

does this work on Mobile platforms? (regardless of performance implications)

 

You need OpenGL ES 3.0 & MRT for deferred rendering to work, and I don't see a reason why Decalicious would not work with this but I didn't have a chance to test this so far, so I can't say for sure unfortunately.

 

► Hooray! Decalicious is released! Get it here

Thanks for your feedback so far, please keep it coming so we can work in what you need

 

Thanks for letting us know, I bought it already and made a little benchmark scene . Could you please do something about all those GC allocations? I briefly looked at the code and have seen that there seems to be potential to optimize . Imho all third party assets should have 0 byte per-frame GC allocations (if at all possible) because otherwise it all adds up and gets out of control in a big project.

You are using this in you own game too, right? What kind of genre and style are you working on?

 

bought it, it's looking great, except as Martin_H mentioned the GC allocations, I am right in saying that the mask does not affect the normal? doesn't seem to, be good if it did

 

I'm not a huge C# pro (coming from a C++ background), so I'll have my C# wizard take a look at it. Also, @punk sent me some helpful remarks about that, thanks! Update will come in very soon.

You can get a brief overview here

True and chosen by design. Quoting the manual: "Note that the decal mask is only applied to the normal map if using the Overwrite blend mode, not if using the Modulate blend mode – use upright normals (RGB 0.5, 0.5, 1.0) for this." The reason is that if you have a smooth fading mask, your normal map will most likely already include this, meaning you would apply the mask twice. For me, this is the intuitive way (info box in the inspector might be helpful), but I'd like to hear more opinions on that. Or maybe we need toggles for everything (apply mask to albedo, apply mask to normals etc.)?

 

@Daerst I've replaced my own deferred decal code with this - great work saved me a bit of time

couple of pics - first one is blood everywhere after a battle, performance cost is barley noticeable and there is 200 decals.

The second pic is the two different blend modes, top is overwrite bottom is modulate
notice how the snow in top screenshot is loosing its normals ie being made flat by the edge of the blood normal map

i'm not sure exactly what you mean by 'use upright normals (RGB 0.5, 0.5, 1.0) for this' (do you have any reference for that) also I'm assuming there is a performance benefit to doing it like that?

 

This sounds like a really cool idea, I wish you the best of luck!

Sounds good, looking forward to try the next version! Here is an interesting Unite talk that might give you some ideas:

I've spent some more time playing around with Decalicious, and so far I'm really liking it! Keep up the great work!

 

I've read through this thread and I'm still a bit unsure about what the actual pros are of a system like this as opposed to the more naive approach of just using meshes for decals?

When I think decals I think small bullet holes or blood splatters and ideally an unlimited amount of them. I realize that decals are used for a lot more than that, but that's my primary use case. I've never gotten so far as to release a complete game, but in all my shooter prototypes I just spawn a quad with a texture wherever I want a bullet hole or similar. And I've played around with different approaches of combining all existing decals into big combined meshes to hopefully make it possible to have unlimited bullet holes with little performance impact. But like I said I've never gotten far enough to actually see if that's true, nor have I really tested the performance of any of my projects.

Anyway, the key feature I want from a decal system is persistence. I want every decal to persist until it will never be seen again, i.e. the round ends in a multiplayer game or the player leaves an area which he'll never return to, to give players the feeling of actually affecting the game world. I hate bullet holes or blood splatter that fade away. I hate everything that fades away, lol. The difference between ending a session playing a zombie shooter or something and seeing shells, blood, bullet holes and corpses everywhere and just seeing a clean level is huge in my opinion, easily worth dropping the overall graphics of the game a few notches to support, although I understand the modern gamer generation doesn't share my views on that.

Does a system like this offer any pros over a naive system like what I've been fiddling with for my use case or is a system like this better suited for letting artists hand place things like graffiti, rubble and what I'd consider "level features"? I'm not big on authored content so that's not a big selling point for me.

I guess I just don't understand what this feature list implies:

A naive system like my own automatically supports any shader, lighting, can be scaled, moved etc. so I guess this is a feature list comparing this system to other deferred decal systems?

The only thing I don't support with just simple quads is having decals on uneven surfaces, but that can be fixed by doing something similar to what's described in the blog post Martin_H linked to.

My naive approach doesn't support decals on skinned meshes, but neither does this system if I understand what I've read correctly? You would need a system that draws directly to the skinned mesh textures or something to support that, I guess?

Is it actually really expensive to just place quads everywhere? I guess that's something I should test and find out myself.

I'm just trying to wrap my head around all this new technology popping up everywhere.

 

It always depends. If you give them non-batchable multipass materials that use grabpass, it will be very expensive.

Ideally I want to achieve the same thing, but I'm not sure yet if it is possible. The whole issues is complex and has tons of "it depends" aspects to it. If you really care about it, you might have to adjust very fundamental gamedesign parameters like level size and available ammo to just make the performance-wise unfeasible scenarios impossible to reach.


I don't think the choice of decal system is "either or". It is "right tool for the job". I actually experimented a bit with constructing my own decal meshes and I pretty much thought "F*** this sh1t, I'll just buy the asset and see how far I get just using that".
Just quads will get you very far if you can know for sure, that the surface you attach it to is perfectly flat and it doesn't clip over an edge. In my usecase that's pretty hard because 95% of my geometry either is not flat, or is destructable. Also I don't have an answer to z-fighting issues with mesh based decals yet.


Please keep us updated on your progress, I'm interested in what solutions you'll choose.

 

I'm not really working on any projects that need decals at the moment, but I was thinking that the right tool for me was simply the most optimized one, as in the one that could handle the highest amount of decals. I obviously don't need to handle an unlimited amount of decals, but I probably would need to be able to have thousands, if not tens of thousands, of decals at once.

It's been a while since I was working on anything needing a decal system, but I want to complete some worthwhile shooter prototypes sooner or later.

Practically all my shooter projects are fully dynamic with procedural and destructible environments so I need to take that into account as well.

In one of my old quad decal systems I'm pretty sure the only thing I needed to take into account was the 65k vert limit for a single mesh, but with only simple quads that's well over 10 000 decals. But I remember that the mesh combine script (I think it was included with Unity at one point) caused some major performance spikes when it combined decal meshes and that there were many bugs and situations I didn't account for.

 

To clarify what the blend modes actually do, I made small sketch:


Modulate normals will reconstruct a tangent space and apply the (tangent space) normal map, which is great to add detail and keep the underlying normals or apply normals to curved surfaces. This also means that when you have an upright normal (RGB value of 0.5, 0.5, 1.0 - the default 'normal map blue') in your normal map, no change will happen whatsoever. So there is the inherent 'mask'.
On the other hand, Overwrite normals ignores the underlying normals and only uses the orientation (i.e. the tangent space) of the decal's game object to align the normal map, which is helpful is you wanna imitate mirroring puddles as done in the example scene. Any bumps below the puddle should be overwritten, the surface of the puddle needs to be perfectly upright. This blend mode allows for that.
Now, while developing Decalicious it seemed somehow intuitive to me that a blend mask should not be applied when modulating the normals, but should be applied when using the overwrite blend mode. This was purely a design choice and has no technical reasons. Right now, I must admit that it may be kind of an awkward thing and could cause more confusion than good, and think that I will remove this 'special case' in the next update. Further opinions on this are appreciated!

I can recommend Pope Kim's SIGGRAPH 2012 Presentation on that matter. It explains really well what a Deferred Decal system can (and can't) do.
For simple bullet holes, a series of quads with proper batching may be feasible. Altering a single mesh, as you suggested, requires the whole mesh data to be uploaded to the GPU everytime you change it, which will work nice at first and break down later. Also, culling (frustum / occlusion) will not work well with a single mesh. When it comes to more complicated, curved or detailed surfaces that you want to place decals on, you run in to more problems. Then there is the Z-fighting. Also, mesh based decals can not easily do what Decalicious does, that is altering the G-Buffer in a sophisticated way. This is beyond bullet holes of course, but drawing albedo while keeping the underlying normals, multiplying the albedo color with some value, altering just the normals to add scratches (or holes?) to any surface while keeping the rest of the properties... You can do some fancy stuff with it In any case, even if you just need bullet holes, Decalicious will save you the trouble of optimization, has proper culling and batching, and may come in handy for more randomly-placed details to enrich a procedural world.

 

Maybe you could write a custom inspector for the shader material and add a note what is masked by the mask slot, depending on what is chosen in the dropdown for modulate/overwrite?

 

I think you meant the other way around, currently you can't mask in overwrite mode. To me the mask implies that if you want to 'overwrite' a puddle, you'd just mask it in the shape of a puddle, so the it doesn't overwrite the edges. Also a mask implies that white would use the normal map(overwrite), black would ignore it (modulate) and .5 would be a blend between the two and similarly the other maps, but i'm not sure whats technically possible and if that adds any limitations

 

Does it? I would expect a similar behaviour to a photoshop layer with a layermask: layer blend mode would be the equivalent of overwrite/modulate (normal/overlay in photoshop), and the layermask would interpolate between 0 and 100% visibility of the blendresult.

Can you think of usecases where you would actually want a mix of blend/overwrite? Of the top of my head I can't think of any, but I'm sure there are. There always are .

 

Do you mean the opposite of what I said, Black is overwrite, white is modulate, Grey is a blend? I can think of blend uses, snow perhaps, you could better control the coverage then, frost, there's probably more and probably other ways of doing it. My game is cold I guess it would just allow more flexibility, I've gotta do a bit more testing, but currently I think it's great

 

No, maybe we are talking about different things or there is some other kind of misunderstanding? As far as I understand it: black/white is off/on and has nothing to do with modulate or overwrite. You choose between modulate and overwrite with the dropdown menu for normal blend mode, in the decal material. The mask is just limiting the effect to a certain area, except for the modulate blend mode where it does not mask out the normal map, because in this mode a neutral normal in the normal map is supposed to be used to limit the effect to the desired area.
For snow and frost - depending on what you are trying to do - you might want to use a material shader that supports global weather settings like Lux. Or a custom shader that supports vertex painting to let you manually choose where frost shows and where not. I doubt it makes much sense to cover a whole level in snow using deferred decals. What might work well though is using the decals as footprints in snow. For blood splatter in snow I kind of would expect them to not affect the normal map (much), because the snow should "soak up" blood.
Do you have screenshots of cases where you think a mixed blend mode would work better than either of the two available right now?

 

Exactly, well put! I'll be happy to write more details later, if things are still unclear.

 

isn't it black is off anything else is on? that's what confused me I kinda assumed a greyscale mask would be blended not cutout, I get it now . I'm only using deferred decals for decals added at runtime, blood, impacts, etc I have characters that can freeze the floor etc, all working good

 

If I recall correctly some things are alpha blended (albedo for example) and some are "cutout", maybe? I certainly saw differences tweaking my greyscale mask with level-adjustments in photoshop.

 

@Daerst @Martin_H - (in pic left is no mask/right is using a mask) best I can figure out in overwrite mode when using a mask all the maps are blended you can see this in effect below on the right. black will also cutout the decal ie no overwrite and anything above black will fully overwrite the normals as shown below. The cutout creates a hard edge which leads to a flat normal surrounding the decal when its faded out as below. If it was blended you wouldn't get that, I think it at least needs a theshold so you can control the cutoff otherwise it limits what you can use mask for. Am I making sense?

 

Huh! That's not intended behaviour and most probably a bug. The faded mask should also lead to a smooth transition of normals, as you expected. I will look into it, thanks!

 

Ah cool

 

Yep, can confirm - silly bug on my part. Will be fixed in the next version. Also, @floAr managed to cut the Garbage Collection stuff in half, and has more ideas on how to improve it. I will push an update soon that incorporates these first fixes and optimizations.

 

We managed to get the GC Allocations down to 0B Thanks for the hint guys! I'll fix the bug with the normal blend mask and push an update ASAP.

 

legends

 

Waiting for the inclusion/exclusion system to buy it (no rush, and no disrespect, I've just been burned a lot by the UAS lately). I did have a question about dynamic transforms and object pooling though.

The features list says that dynamic transforms are possible, like rotating, scaling, etc. Does this mean that you can slide the decal around on a surface in real time, like with a shadow blob (traditionally the job of projectors) and have the blending work properly with the normals on the changing surface? In other words, is there some sort of special action that needs to be taken to update the blending, like a refresh of some sort, or are the normals blended each frame in the shader? I'm obviously not a shader expert, so I'm not quite sure what to expect there.

While I'm at it, will there be easy support for animating aspects of the material (not just the transform), like the color, albedo, etc, from within scripts? I can imagine this being useful when updating transparency levels of deferred decals in some cases- shadow blob opacity based on character distance from the ground, for instance, or making liquid-style decals more transparent the closer you are to them, etc.

Lastly, are there any special considerations to account for in object pooling systems that might be used for traditional decals, when constantly disabling/enable/moving the objects about as the game progresses? This is really tied to the dynamic transform question- if the shader handles everything and moving it about works fine, I can't imagine the object pooling has many annoyances either.

 

Haha, update is pushed - also added a 'Mask Normals?' toggle on the shader. If checked, the mask will be applied to normals, for both Modulate mode (left) and overwrite mode (right). If not, the mask is ignored for normals.

Might be harder than I initially thought, but it's my top priority right now. Thanks for waiting!

Nothing special needs to be done here. Move the decal's GameObject, and everything will just work. Under the hood, the Decal is just a bounding box that is drawn with a magic shader, and this box can be moved freely and the underlying normals will be taken into consideration just fine. The decals don't require any pre- / reprocessing at all when moved / rotated / scaled.

A Decalicious decal consists of a tiny MonoBehaviour component and a complex material. The component has a Fade value that allows you to control the Decal's influence, which can be controlled from script:

Code (CSharp):

1. GetComponent<Decal>().Fade = _myAnimationCurve.Evaluate(Time.time); // example

Note that this value can be controlled individually per Decal. Other properties like Color etc. are stored in the Material that may be shared among multiple Decals, so changing values there will affect all Decals that use this Material. Easy sprite sheet animations using the UV channels are on our roadmap. We didn't think about animation of other properties so far. Anyway, if your material is not shared among decals or if you indeed wanna animate all decals in the same way you can do this:

Code (CSharp):

1. Material decalMat = GetComponent<Decal>().Material;
2. decalMat.color = _myAnimatedAlbedo;
3. decalMat.SetFloat("_SmoothnessMultiplier") = _myAnimatedSmoothness;

I think a decal pool, e.g. for bullet holes, won't pose problems. Right now we have a bug though, the draw order of decals may not be consistent when any decal is removed, which can lead to artifacts with overlapping decals. I'm looking into ways to fix this. When it comes to high performance drawing, keep it mind that only objects with the same material can be instanced, i.e. drawn in a single batch. We plan to include better support for sprite sheets, so that you can compress multiple decals into the same Material using different UV coordinates.

 

Here is a status report on two issues we've been dealing with in-between turkey and Glühwein:


Render Order of Decals
Especially, the example scene has the issue that the render order of existing bullet holes is shuffled when bullet holes are despawned (60 seconds after being created, in our case). Also, there have been ideas on setting the render order individually using a Priority parameter. We have fiddled around and for now will keep relying on Unity's internal render order and will not change this behaviour. Having a special, user-defined render order requies you to have a sorted list which comes with a certain overhead, both in terms of CPU time and GC allocations, and we feel it's not worth it.

Workarounds
Generally, decals that are added to the scene later will be drawn on top of previous ones. To have a decal rendered on top of others, deactivate and re-activate its GameObject. Please note that this order is not consistent (e.g. when entering play mode), so do it from script during gameplay if required.
For the vanishing bullet holes, you could either just leave them there - the overhead is really not that big in most cases - or set their Fade value to 0. Decalicious 1.3 (will be pushed in a few days) will include a slight performance tweak that will minimize overhead of decals with Fade == 0.


Limiting Decals to specific surfaces
Decals are drawn on each and every surface (normal clamping: 60° - we will make this a parameter with the next update) within the decal's bounding box. It is often necessary to draw a decal only on specific surfaces though, and omit others. We have implemented a first iteration of solving this issue. For each Decal, we added a field GameObject LimitTo that, when set, will only render the Decal on the set GameObject or any of its children. This works by rendering the MeshRenderer of the GameObject itself and any of its children into a special buffer that is then used for clipping the Decals. When you want a Decal to be rendered on multiple GameObjects (which don't share a parent that you could select), you can copy the Decal and draw it once for every target object.

Notice how the decal is only drawn on the Wall and Floor (both children of Room), but not on the Platform:



We will push these changes in the next days. As always, we appreciate your feedback very much, especially whether this system actually fits the real-world needs from the projects you are working on!

 

Decalicious 1.3 has just been submitted for review.
The update will include the changes mentioned above (ability to Limit Decal to GameObject, Angle Limit parameter and a performance tweak for Fade == 0). Also, this update comes with a slight price increase from 15 to 18$.

 

Would it be a viable solution to keep the unsorted list, but give every decal an enum value for the priority and then iterate over the whole list priority_max times, only drawing the i == current_priority decals? I'd imagine iterating 10x over the list in a for loop shouldn't be that big of an overhead and should not cause additional GC. And 10 would probably be more than I actually need. I haven't thought much about this yet but for example "landscape decals, roads/trails, craters, debris" could already solve the bulk of possible issues I can think of right now.

What kind of performance profiling did you do on this? It sounds very expensive. Do I understand this right - 10 decals on a group of 10 objects would in a worst case cause 100 additional meshes to be rendered (unlit and untextured I assume)? Does it do this for every decal again? Like, when I want to limit 100 "dirt crater decals" to the terrain object group, does it draw all the non-culled tiles of my ~8 million triangles terrain again for each of the decals?

I haven't tried the updated version yet and at the moment have no time to work on my game, but to be honest it doesn't really sound like the first iterations of these new systems would solve my realworld usecases very well. I do realize though that this is a very tough nut to crack, and maybe there just is no solution that is both easy on performance and flexible at the same time :-/.

Did you research the option to render an "id-mask" split up by layers? I think you mentioned something like that a while ago.

Thanks for your continued support and "Guten Rutsch ins neue Jahr!"

 

Not a bad idea at all, I will think about it!

I didn't profile this solution too much yet, and only did basic optimization. A GameObject referenced by multiple decals will only be drawn once though, not 100 times if you have 100 decals Unlit and untextured like you said. The meshes are also drawn after the GBuffer and use the existing Z values (ZTest Equal) so no overdraw is happening, but there is no culling currently (except that Decals are culled, and that only the GameObjects for the actually visible Decals are drawn). For static GameObjects, we could imitate Unity's Static Batching (i.e. merge meshes, transform vertices only once).
So far the system only works with objects that have MeshRenderer + MeshFilter, so not on Terrains, not on Skinned Meshes. I realize this is a problem and I'm working on a solution for that.

Should be fairly simple - for each layer, set the appropriate mask and render with replacement shader. I'm not sure though whether this would be hugely helpful - as @Lysander put it, "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". Do you think this would still be useful?

You are welcome, valued customer! Thanks for your input, and Guten Rutsch

 

Just to avoid misunderstandings: my "terrain" doesn't use the unity terrain, it's just regular tiled meshes exported from worldmachine with standard meshfilter and meshrenderer components. I don't think I have any skinned mesh renderers in the project, although there are good usecases for them to do a kind of "manual batching" by for example attaching the "bones" to different rigidbodies that can and should be drawn in one drawcall. I don't do that at the moment but I could see why people might want to.

Good point! Layers certainly aren't the perfect solution and are very much dependant on other requirements that vary from project to project. No (decal) system should ever rely on layers being available to do such sorting tasks. In my case I have layers like "ground, structures, player, enemies, debris", so I could cover quite a few cases with using layer masking. Like for example a big crater decal could be limited to the ground layer and a vehicle could drive through and be unaffected.

Awesome! Let us know if it's actually a promising approach or if there are some issues I haven't thought of.

 

Watching the thread for now, if you can get skinned meshes working I'll give it a shot.

 

Working on limiting decals to skinned meshes, basics are down

 

Of course you can also set a bone as parent (in this case, the head bone) to animate decals with (mostly rigid in itself) parts of your skinned mesh - could be useful for tattoos, scars, brandings etc.

 

But that wouldn't work in areas that are affected by 2 or more bones (joint areas), right?

 

Does this work in runtime and in mobile

 

Right, you will get distortions if the areas are affected by two or more bones. This is just beyond what screen-space decals can do, so you would need to look to an altogether different approach for that.

Everything works in runtime, and I guess it should be no problem on mobile (as long as deferred shading works!), but I'm not a mobile developer, have no experience with it and not really an ability to test it. Any reports are appreciated

 

Would it distort with the mesh or would it stay fixed to one bone while the underlying mesh distorts along 2 bones?

 

The latter, e.g. a tattoo on skin would not "stretch" with the skin but stay fixed to the bone you children'd it to and probably look weird.

 

Is premodelling the decals possible? Like would I be able to have UV mapped 'decal' planes overlaying my geometry with normals and albedo?

 

A decal is a box by default, and you cannot simply replace this with your own geometry.

 

Mate I'm currently having a problem which prevent the decals be renderer, I post it in unity reviews but i've forget to add more info.
Unity version: 5.5.0f3
GPU: AMD HD 8750m

Error i get:
InvalidOperationException: DrawMeshInstanced is not supported.
UnityEngine.Rendering.CommandBuffer.DrawMeshInstanced (UnityEngine.Mesh mesh, Int32 submeshIndex, UnityEngine.Material material, Int32 shaderPass, UnityEngine.Matrix4x4[] matrices, Int32 count, UnityEngine.MaterialPropertyBlock properties) (at C:/buildslave/unity/build/artifacts/generated/common/runtime/RenderingCommandBufferBindings.gen.cs:240)
ThreeEyedGames.DecaliciousRenderer.DrawDeferredDecals_Albedo (UnityEngine.Camera cam) (at Assets/Decalicious/Scripts/DecaliciousRenderer.cs:209)
ThreeEyedGames.DecaliciousRenderer.OnPreRender () (at Assets/Decalicious/Scripts/DecaliciousRenderer.cs:99)
UnityEditor.DockArea:OnGUI()

 

Ouch, seems like your GPU does not support instanced drawing, which is currently required by Decalicious. Could you check whether SystemInfo.supportsInstancing is indeed false? I'll see if I can come up with a fix.

EDIT: Please get in touch with info@three-eyed-games.com - I have a fix that I would like you try out

 

Yes you have the reason, i think it's a problem from my drivers because the first time i tried Decalicious it works but currently isn't working anymore.
Should be drivers problem of my GPU.

Debug.Log("Support instance? " + SystemInfo.supportsInstancing);
Support instance? False

 

Instancing was added in version 1.1, so if you tried it before that, it will have run fine. Please send me an e-mail so I can send you a fixed DecaliciousRenderer.cs to try out

 

Hi Daerst - we're building off of 5.4.3p1. Would it be possible to get this working on that version?