[RELEASED] Dynamic Decals

Introduction:
Dynamic Decals is the decal solution built from the ground up to be fast, easy to use and flexible. Perfect for bullet holes, blood effects, projected UI elements and just about anything else you can think of!

No more fiddling with quads to avoid z-fighting, or re-projecting / recalculating decal meshes every time you want to move a decal. Just drop a projection renderer onto an empty gameObject and setup your projection. You can save it as a prefab and spawn it like any other gameObject, as well as move, rotate and scale it at run-time without issue. It's that easy.

On top of this, I've built a fast fully featured and flexible pooling system, a layered masking system and some "Printers" & "Positioners" to help users with no programming experience use the system.






Demo

New Version 2.0 Features
- GPU instancing with per-instance properties and atlassing.
- Animated projections.
- Additive & Multiplicative projections.
- Masking via Unity layers.

Key Features
- Print and manipulate decals at run-time.
- Project decals onto skinned meshes.
- Overlap and order decals.
- Clean, simple editor integration.
- Run-time Printers & Positioners.
- Omni-directional Projections.
- Mobile & VR support
- Support for Deferred & Forward rendering paths & all shader models.
- Full source code included.
- Zero setup required.

Links
Website
Script Reference
Asset Store

Change Log
1.1
- Removed close to all memory allocations within the core system.
- Various optimizations, focused on main CPU thread
- Added Normal and Roughness Decal types

1.2
- Inverted decal support
- Default DepthTextureMode
- Various Shader optimizations
- Pooling optimizations & fixes
- Normal map fixes

1.3
- Multiple pools
- Pool Quality Settings
- Overlap prevention
- Automated redundant settings
- Renamed components to prevent naming conflicts
- Improved warnings
- Fixes for 5.5 & beta 5.6

1.4
- Particle printer
- Automated DepthTextureMode
- High precision forward projections
- Fixes for 5.6 final release
- VR support

1.5
- Projection blockers
- Forced forward rendering
- Layer based surface detection for printers
- Renamed "Pulse" to "Omni-Decal"

1.6
- Tag based surface detection for printers
- Various optimizations
- Various bug fixes

2.0
- GPU instancing
- Per-instance properties
- Texture atlases
- Animated projections
- Additive projections
- Multiplicative projections
- Masking by Unity layers
- Nine-sprite projections
- Print projections with behaviors attached
- Omni-Directional decals now support all projection types
- Brand new demo scenes
- Extensive optimizations

 

Very happy someone finally published a commercial deferred decal solution.

Can it project roughness and normal maps as well?

 

It can, It writes to all 4 deferred buffers (Albedo, Spec/Smooth, Normal and Ambient/Emission) and, in the PBR lighting mode (Default) will work just like the standard shader. It supports both metallic and specular workflows as well.

As of now it cannot project exclusively to just normal or just roughness, but it would be easy to add if theirs demand for it. Though such features could only work in Deferred shading, not Forward.

Edit - As of 1.1 It can project exclusively to normal or roughness. (Deferred Only)

 

I've been working on a custom deferred decal solution to explicitly paint spec/smooth onto our trees to simulate wetness. This package seems to be further ahead and I'd like to use it as my new baseline.
Does this support texture atlasses? I prefer baking all our decals onto large atlasses for grouping and performance reasons.

 

Currently no, but it would be pretty trivial to modify the shaders and the decal component to support them, as well as a custom pass to output exclusively to spec/smooth. If you need a hand I'd be happy to help. It seems I'll likely be adding support for roughness maps anyway.

 

First of all, why has that poor llama a razorblade stuck in his throat? =(




I've already bought another solution, so I'll not buy another one super soon (although it looks like your solution has a lot more features currently). But I would be interested to see how your solution holds up with massive numbers of decals. Like let's say 5000 decal instaces of at least 10 different decal textures on screen. Demo videos of different usecases or an .exe for download would be very interesting for potential buyers too I'm sure.

 

Hell yes!!! I'm so happy right now I could kiss you on the mouth

Thank you for developing this. I'll definitely be buying today!

 

I second that. A video that shows how to set things up would be appreciated too, as well as some performance tests / numbers.

I personally would be interested how I would set up "footprint decals" and "blood decals" on arbitrary geometry, not just flat surfaces and what type of geometry might cause the decal system to give a hard time. I've also animated objects (doors) where decals need to move with the door when it gets opened (think of blood spray on door). Is it as simple as moving the decal into the door hierarchy?

The description mentions it features a pooling system. Is this referring to pooling of decal GameObject's? If that's the case, can I also choose not to use it, but use my existing GameObject pooling solution instead?

Can I use custom shaders / non-pbr materials for decal rendering?

I was reading the script documentation a bit, but most/some classes have rather generic descriptions only. It would be really useful to have an actual description for them, that describe what a particular class is doing, what problems it tries to solve and for what things it could be used.

 

+Martin H - The razor blade is an ode to how the name came to be. LLockham = Llama + Occam's razor. Honestly surprised you noticed it.

A demo seems like a great idea. I'll try get one up today.

+HakJak - Thanks for the support, means more than you could know.

+Peter77 - There is no setup required. If you want a decal, all you need to do is create an empty gameObject and add a decal component to it. The system will detect which rendering path your using and do everything behind the scenes for you.

It's also perfect for footprint and blood decals. The performance of a decal is independent of surface complexity, you could project onto a surface with 1M verts of complexity and get the same performance as a flat plane.

Your more than welcome to use your own pooling system, though the in-built printers use the in-built pooling system. But you could easily build your own printers.

Think of decals as any other kind of GameObject. If you want to move rotate or scale them, simply do so, there are no tricks to it. If you want decals to move with a surface, parent them to that surface. If you want to create or duplicate them, instantiate them from a prefab like any other GameObject.

For Blood, an approach you could take, use the collision printer attached to "blood droplets" that spawn whenever a character is hit. Those droplets would then print blood decals wherever they land.

For Footprints, you have a few options. You could use the ray-collision printer on each foot to check when the foot comes close to the ground and print, or you could use a ray printer timed with animation events. The later would probably be more reliable.

Again though, you could easily custom build your own way of placing decals, the printers and pooling system included are more a convenience items so artists can use the system.

 

Alright, Uploaded a demo video (See start of thread) and have done some final bench-marking on my machine.


The system can run 5000 decals on screen with 10 materials as requested, but unfortunately not at an acceptable rate. It held around 30 - 40 fps on my PC (4 years old, mid range, which is what you would expect most gamers to have). With a game piled on that 5000 decals won't be ship-able. As a hard limit I wouldn't go over 1500 decals on a PC release and for mobiles, to be safe, I'd keep it around 250 - 500. Keep in mind though, this is on-screen at any one time. The system has full culling support, as well as ways to fade and remove temporary decals.

I'll continue to optimize as I continue development, but as it currently stands, I still think the system is well worth the asking price.

I'd also really like to experiment with GPU instancing and atlassing. All projections already share the same mesh, and roughly 6 different shaders. So in theory we could draw tens of thousands of decals in a single draw call, and the entire system in a few. If this is possible it will still be a few months away though, so please don't purchase the product if your not happy with it in it's current state.

and thanks for the feedback guys, really constructive.

 

That doesn't sound too bad, what GPU model do you have? Thanks a lot for testing and making that video! For the kind of visuals I want there isn't too much I can do to avoid the crazy numbers of decals. Also many of them will be on screen at the same time and there's no occlusion culling because it's an RTS style perspective.

 

I believe I'm running a Radeon R9 270x.. But it's of little consequence, the system is currently bound by the main CPU thread, not the render thread/s (Submits Draw-calls) or the GPU. Right now the onus is simply on me to find creative ways to optimize updating command buffers & such, then I can think about optimizing for the GPU.

Out of curiosity, what is your use-case? What exactly are you trying to achieve that requires 5000 decals on screen at once?

 

I'll send you a PM.

 

Just bought this and totally worth the price! Already production ready from the tests I've done so far. Super high quality and superb results. I've been waiting for a deferred decal solution for a long time and will be putting this baby to good use ASAP!

I'll leave a review once I get my hands dirtier with it and implement it in my project. Great job man!!

 

Glad you like it! Keep me updated. if theirs ever a situation where you think to yourself, "Man, I wish it could do ___" or "Damn, I wish it did ____ like this.". Let me know. chances are I can make it happen. The more use-cases the better!

 

As I didn't see it on the asset store page: No link to a forum thread is usually a red flag for me, especially with technical and more complex assets. It's a good indicator of what level of support to expect, a way to ask questions before buying and finding out about potential caveats.
I assume for skinned meshes you'd have to position decals based on bone transforms and not have to get them close to joints?

 

I'll get a forum link on the asset store page asap, thanks for the tip!

And your correct, painting decals onto skinned meshes does so in world space volumes, so decals would not deform with the mesh as they are not baked to the mesh itself. Depending on the decal and how you approach applying them, this could cause some unfitting results. If your working with rigid characters like robots you would be fine, and if your working with normal characters you could probably still get away with small bloodstains or other details, if your clever about it. But placing a detailed tattoo across joints (Shoulder, Elbow, Knee) is definitely not recommended, and beyond the scope of a screen-space solution.

 

Version 1.1 has just been submitted for approval. Most of the changes are behind the scenes, removing sources of memory allocation and optimizing, though I did add Roughness and Normal decal types.
The system now allocates zero memory on a frame by basis and very little anywhere else. You can't avoid allocating memory when your creating or instantiating new projection instances, so printers will always allocate a little when they print new decals. But the core of the system shouldn't ever allocate any after initialization.

I've also managed to reduce the impact on the main thread pretty significantly. where it used to take 25+ms to manage 5000 decals it now takes 17-18 ms. The render threads are still sitting down at about 10 ms as well.

The roughness and normal decal types are decals that project to only a single buffer/buffer channel. This does limit there use to Deferred Rendering. In Forward rendering they will simply be ignored.

The Roughness decal allows you to project only to the alpha of the spec-smooth buffer (Roughness/Smoothness). The most common use-case for this type of decal would be "Wetness" decals, where the decal would make the surface appear shinny-er and smoother as water hits it.

The Normal decal allows you to project only to the normal buffer, ignoring the albedo, gloss and ambient buffers. The most common use-case for these would be adding cracks, rivet holes etc. to a surface. This is useful when the base mesh is far too large to have fine details baked into its normal map, or if it uses tiling materials as it's base and you need to break up the tiling with details to make it less obvious.



To those of you have bought it so far, thanks for the support! Enjoy!

 

Thanks for adding the normal and roughness decals. That is a great feature!

 

Hey Dan,

Is there a reason why the DeferredDepthTextureMode is set to None?

I was having issues using this asset with SSAO Pro, and I tracked it down to the UpdateDeferred method setting it to DepthTextureMode.None.

Changing it to DepthTextureMode.DepthNormals fixed it, but a wise philosopher said not to change anything unless you understood what the old code did

 

- gamers2000, glad you found a soloution. I've not looked into SSAO Pro but in deferred rendering this is no reason to use any DepthTextureMode. The Deferred rendering pipeline already provides both depth and normals in seperate buffers, at high precision.

DepthTextureMode.DepthNormals uses shader replacement to render every visible object again, which is a performance hit, and provides a single texture with 16bit depth and 16bit normals packed in one. But the deferred rendering pipeline provides a 24-32bit depth texture (subject to platform) and a 20bit normal texture by default.

DepthTextureMode.DepthNormals is great for forward rendering, this package relies on it, but in deferred it makes no sense, which is why it's turned off when switching from forward rendering to deferred.

That said, I've not looked into AO, maybe there's something I'm missing, and it's definitely not my place to enforce it on anybody. I'll add a "Default DepthTextureMode" option in the settings, so it can switch to that when using deferred, instead of DepthTextureMode.None. Should be in by version 1.2.

And in the interim, if anybody else has the same problem, the solution above is easy enough to implement. Open DynamicDecals.cs and change line 737 from
Camera.depthTextureMode = DeferredDepthTextureMode;
to
Camera.depthTextureMode = DepthTextureMode.DepthNormals;

Thanks for the feedback!

Edit - Depth Texture Mode cached and handled automatically as of 1.4

 

Does it work with terrains?

 

It does!

 

Loving this asset so far!

However, the pooling system messes up when I reload a scene; it tries to refer to deleted GameObjects because the pool lists are not cleared out when a scene is reloaded.

Although I'm sure you'll fix that in a future udpate, is there an quick way for me to fix this myself for now? I would love to put it to good use right away, but worried I'll mess up something tinkering around in there.

 

Also, 1 other question: is there a way to check if 2 or more decal projection "boxes" are intersecting? I'm using this for blood splatter, instantiated from particles, so it would be very useful for optimization to be able to do a quick check to see if a decal is already nearby before placing another one on top of it.

 

Sorry for the delay, just got back from work.
Honestly don't think I would have encountered this in my own testing for months, so thanks for finding it! Fix will be in the next update.

Edit - Fixed as of 1.2

As per your second post, this is tricky. The simplest solution would be to check distance against every other decal in the scene, but if you have thousands of decals, this becomes a little expensive. If you wanted to accurately check for bounds intersecting, it would become even more expensive. And maintaining a temporary decal is relatively cheap, it may actually be cheaper to simply print the decal.

Nevertheless, I would approach it like this:

Add this method to DynamicDecals.cs

Code (csharp):

1.  
2. public static bool CheckIntersecting(Vector3 Point)
3.     {
4.         for (int i = 0; i < System.projections.Count; i++)
5.         {
6.             Vector3 localPoint = System.projections.transform.InverseTransformPoint(Point);
7.             if (Mathf.Abs(localPoint.x) < 1 && Mathf.Abs(localPoint.y) < 1 && Mathf.Abs(localPoint.z) < 1)
8.             {
9.                 return true;
10.             }
11.         }
12.         return false;
13.     }
14.  

you can then use it anywhere by calling

Code (csharp):

1.  
2. DynamicDecals.CheckIntersecting(PointToCheck);
3.  

It checks if a point is intersecting any projections within the scene. You can then check this when printing to see if the point your printing at already has a projection there. Keep in mind this will check against all projections though, not just blood decals.

You could optimize this further by grouping decals, and only checking against projections of the type your after (ie. only checking against nearby blood decals), but this is about as much as I can give you without getting in to see your project myself.

Test it, see if it helps performance. If it does, awesome!

And thanks for the feedback!

 

Thank you for the amazing support and for sending an updated script!

Another feature suggestion: multiple pools. It would be really handy if there were, say, 4 different pools to use for decals. This way the user could have more control over which decal groups disappear first. For example, I'm using this for blood splatter and it would be amazing to be able to have the splatter on main characters and vehicles completely separate from environmental splatter. This way I could ensure that blood stays much longer on characters, while still taking advantage of pooling.

 

Okay, I modified the overlapping decal check a bit and got it to work! It improves performance when placing lots of decals in the scene at runtime, by preventing unnecessary additional decals from being placed. Also allows older decals to stay in place longer before being pulled back into the pooling system.

Here's the modified code:

"checkRatio" is 0-1. The smaller the number, the smaller the check area and thus the more likely to spawn a new decal. 0.1-0.3 seems to be a good range for a little overlap.

Code (CSharp):

1.     // Check for intersecting decals at the given Vector3 point
2.     public static bool CheckIntersecting(Vector3 Point, float checkRatio)
3.     {
4.         foreach (Projection projection in System.projections)
5.         {
6.             Vector3 localPoint = projection.transform.InverseTransformPoint(Point);
7.             if (Mathf.Abs(localPoint.x) < checkRatio && Mathf.Abs(localPoint.y) < checkRatio && Mathf.Abs(localPoint.z) < checkRatio)
8.             {
9.                 return true;
10.             }
11.         }
12.         return false;
13.     }

Could be a good feature for the full asset?

 

What is the proper way to change the Pool size limit during runtime?
I need to allow players to change this according to quality settings, but not sure if I'm doing right. Can it be changed any time? Only during Start()?

Is it just this, from any script?

DynamicDecals.Settings.poolLimit = newPoolLimitHere;

 

You've been busy! I think we are in opposite time-zones, just got up.
First post - Great idea! I'll see what I can do, might be tricky to get something intuitive but I'll figure something out. I just uploaded 1.2 last night, so it will have to wait until 1.3.
Second post - I still think it's inefficient when you have thousands of decals, however, if we combine this with multiple pools. and only check against the pool your printing into, it could be very viable. I'll play with it once I get multiple pools up and running.
Third post - The only "proper way" to change it is via editor. The variable is stored in an asset file and can't be directly saved at run-time. However, the method you suggested will work, as long as it's done at the start of every play session. ie. it can be written to, but the value written won't persist between level changes or play sessions.
That said, variable pool sizes according to quality settings sounds like a feature I should be adding to the system. expect it in 1.3.

Edit - All suggestions added as of 1.3

Thanks for the suggestions and the feedback, great ideas here!

 

Sounds great!

Turns out that code I posted above doesn't quite work. As soon as I made it into a prefab, I got the following error. Same thing happened when I tried your code. Any idea on how to fix this? I had it working, but can't figure out what went wrong. So close....

Code (CSharp):

1. NullReferenceException: Object reference not set to an instance of an object
2. DynamicDecals.CheckIntersecting (Vector3 Point) (at Assets/Dynamic Decals/Components/Core/DynamicDecals.cs:603)
3. SplatterManager.OnParticleCollision (UnityEngine.GameObject other) (at Assets/_GutsAndGlory_/Scripts/SplatterManager.cs:118)

 

Nevermind, I figured it out! Had to add a check to see if there were even any decals in the scene first.

Here's the updated code in case anyone else needs it:

Code (CSharp):

1.     // Check for intersecting decals at the given Vector3 point
2.     public static bool CheckIntersecting(Vector3 Point, float checkRatio)
3.     {
4.         // No decals created yet
5.         if (System.projections == null)
6.         {
7.             return false;
8.         }
9.  
10.         for (int i = 0; i < System.projections.Count; i++)
11.         {
12.             Vector3 localPoint = System.projections[i].transform.InverseTransformPoint(Point);
13.             if (Mathf.Abs(localPoint.x) < checkRatio && Mathf.Abs(localPoint.y) < checkRatio && Mathf.Abs(localPoint.z) < checkRatio)
14.             {
15.                 return true;
16.             }
17.         }
18.         return false;
19.     }

 

Version 1.2 has been submitted for approval. Most of the changes are fixes, some listed here, some simply things I've discovered in obscure use-cases. I've also optimized the core decal shaders, as well as the inbuilt pooling. The default DepthTextureMode has been introduced, and while playing around with footprints and animal tracks I also introduced negative scaling.

Decals can now be scaled negatively to invert the texture on a chosen axis without breaking the normals. This is useful for footprints and tracks as it allows us to have a single left footprint decal, and simply flip it for the right, instead of requiring another texture and decal. You can also use it to make often used decals appear less repetitive.

As of the release of 1.2 the price will be dropping from $39 USD to $29 USD.
I've gotten unanimous feedback from friends and enthusiasts alike. The price point is set too high for most people to give it a chance. I appreciate the honest feedback, it's not an easy thing to tell someone. I want this system in as many hand as possible, and if the price point is the only thing preventing people from giving it a chance, then it's something that needs adjusting.

For those of you thinking about buying the system, wait for 1.2 to release, save yourself some money.
For those of you early adopters, I don't know what will happen. I hope Unity refunds the difference, but If they don't, I encourage you to ask for a refund and purchase it at the new price. Thanks for the support and the feedback.

I can't give an exact date on when these changes will be approved, but It should be sometime within the week.

 

I'm looking for a solution to do really detailed blood splattering, is this possible with your decal system?

With blood being such a common decal, I do recommend an example in your preview video.

 

Detailed in what way? The system is built on top of Unity's Physically based rendering pipeline, so you can achieve high detailed blood splattering with normals and specular reflections. And you can have hundreds to thousands on screen at once, depending on your platform. You would have to provide your own blood decal textures, but they shouldn't be too hard to get a hold of / produce. Otherwise, yea, this system is perfect for blood splattering. I believe HakJak is already using it for exactly that, printing blood decals based on particle collision.

 

Say like how in CSGO when you shoot someone and blood shows up on the wall behind them.

And I see the balls that you make paint on stuff they touch? Could that be replicated on blown-up pieces of a model like in Doom?

Reference:

(skip to about 0:22s)

Like how when doomguy kills an enemy and a piece of the enemy hits a wall, it leaves a blood spot there on the wall.

 

Oh yeah, easily.
If your firing actual projectiles, You could have a projectile with a ray-collision printer attached that only prints when it collides with the environment, then every update you could check if it passes through an enemy, if it doesn't it would print a bullet-hole when it eventually collides with the environment. If it does, change the decal in the printer to a blood-splatter and it will print that when it collides with the environment.

If your firing raycasts (ie. hitscan) You could use a ray printer to print to the environment behind the enemy, whenever your hitscan ray "hits" an enemy.

As for the corpse chunks smearing the environment, just use a collision printer (what those balls where using). They're essentially just a printer that prints onto whatever surface they collide with. You can set them to print constantly, like a blood smear, or only once, or only once every x seconds, or only once every x meters etc. And you can choose what collision layers cause prints. Theres a lot of control there.

If you want to program your own custom printers you can do that too. The worlds your oyster!

 

I notice on yours they start to fade, can I changed the time until they start to fade or just not have them fade at all? They processing heavy? (Sorry for all the questions, I think you're becoming my favorite decal system ever lol)

 

Questions are good, If you have them, chances are other people will have them too.

They take a draw-call to render, so you'll start to see a performance impact after your first thousand or so decals on screen at once. In my examples I'm showing them printing 500 or so decals every second, so I'm also fading them out quite quickly. If your smart about how you print them though (ie. don't smear too aggressively, limit printing reasonably) you could have them persist for a lot longer / for ever and then just have them destroy them-self when you leave the level.

And all printers allow you to specify how long it takes to fade out the decals they print.

 

If you want an amazing system for blood splatter, Dynamic Decals is the best. I own a few others, but none come close.

The aesthetic for my game is somewhere between realistic and toony, so the blood is purposefully stylized as such. This doesn't even have normal maps applied yet. However, you can see from the screenshot below that amazing blood fx are very achievable with this asset, and the decals can cover anything, no matter how complex.

Oh, and it's insanely fast too!

 

Well done

Oh Thanks.

 

@HakJak Looks very "Happy Wheels"-esque XD And that image really speaks wonders for the asset. Seeing the blood on the spokes of the bike wheel is pretty awesome!

 

This look nice, I think I will give it a try when 1.2 is released. I have no idea how this works - are the decals being projected based on collision meshes, or rendered meshes? And you mention different techniques are used in deferred vs forward rendering - but are the visual results and the features identical?

 

Decals are projected in screen-space, so the position of a projection at any given pixel is calculated based on the depth-buffer. Anything that can be rendered to it can be projected onto, normal geometry, skinned meshes, terrain etc.

The original technique was designed for Deferred rendering, and is insanely cheap as a result. Unity already calculates depth & normal buffers for deferred so essentially your just injecting data into the deferred buffers mid-render cycle & all your lighting etc. is free.
Forward is an adaption to the original technique but has to render its own depth + normal buffers using (DepthTextureMode.DepthNormal). It also has to calculate lighting as per normal, so is roughly the same as rendering a normal object.

Visually they're close to identical, both use the same PBR model as the standard shader and appear identical. Deferred has higher precision depth and normal buffers so you get a lot crisper reflections, but unless your in a first-person game looking up-close at a decal at 1080p you won't notice the difference. Deferred also supports the "roughness" and "normal-only" decals types introduced in 1.1 where forward does not.

Follow the thread, I'll let you know when 1.2 is live.

 

1.2 is live! Price has now officially dropped from 39 USD to 29 USD. If you already own the system 1.2 introduces support for inverted decals, as well as a few fixes and optimizations under the hood. Grab it while it's hot.

 

Would you be able to use this system to simulate patterns projected on surfaces through colored glass? Like stained glass?

I've tried with projectors and they project on every outward-facing surface in the frustrum of the projector. Hopefully your system would cull all the faces facing away from the decal projector?

Thanks for your thoughts.

 

This looks useful. Has something changed so decals can now work with ambient light only?

How is the masking implemented? Does it use the normal buffer alpha channel?

 

+amasinton - every decal has what I've labelled "projection clipping". This allows you to specify at what angle between the normal of the surface and the inverse of the projection direction to stop projecting onto the surface. In layman's terms, you can choose whether you want to project on backward or side-ward facing surfaces, on a per-decal bases.
(I believe my system is also a lot cheaper to run than unity's projector)

And I don't see why you couldn't use a decal, with blended transparency, to imitate light coming through a stained glass window. If you grab the system please use it for more than that though, it can do so, so much more.

+Khavas - masking uses an entirely new buffer built solely for the purpose. This allows us to have 4 masking layers instead of the 1 that would be possible with the 2 bit normal buffer alpha channel. You can specify which objects you want to be in each masking layer by giving them a mask component, and a single object can be apart of multiple layers. Decals can then specify if they want to render to all surfaces except specified masking layers OR only render to surfaces apart of the specified masking layers. Theres a lot of flexibility there.

What do you mean by ambient light only? as of 5.3 you can render to the ambient light buffer, but I can't image a use case in which you would want to render to the ambient light buffer exclusively.
In deferred mode the systems writes to all 4 buffers. Unless your using Roughness (Spec-Smooth buffer alpha channel only) or Normal (Normal buffer only) decal types.
If you have a use-case for rendering exclusively to the ambient light buffer I'd be happy to add a variant that does exactly that.

Also welcome to the forums Khavas!

 

Cool, thanks. I probably don't need more than to just mask any moving objects, but I need those 2 bits for modified BRDFs.

I mean decals being visible while no lights are affecting them. The consensus some time ago seemed to be that this isn't possible. I guess they didn't make a big deal about that change.

Just picked this up. I'll be back with feedback.

 

Wow, this looks so cool, great job! I haven't had a chance to try it out but I watched the video and I've been following this thread and I'm just so impressed and amazed at the quality of product and support you're providing! Keep up the great work!

I can't wait to use this - I'm intending to make a cartoony arcade shooter with splatter everywhere and this looks like a perfect tool for it. Thanks for such a cool product. The price drop made me pull the trigger early, so it was the right move!