[RELEASED] Dynamic Decals

@MadFox - If your using forward rendering, the shaders your projecting onto will need to be capable of rendering to the depthbuffer. If you add the line Fallback "VertexLit" to the bottom of your shaders, it can use the depth pass from that shader, a lot easier than writing your own. Also make sure they have a RenderType tag.

If you're unsure on how to do this, send me the problem shader via email & I'll set it up for you.

 

Thanks! tried that with no success (i've send you a more detailed email)

 

Grabbed the winter suite, checking your email now, give us a bit, while I figure it out.

 

The feedback from 1.4 has been overwhelmingly positive. It's fixed all the issues people where reporting using the system with VR, as well as the scene issues in forward etc. More than comfortable labeling the system "VR Ready". Thanks again for all the feedback.

 

Thanks! You were right about the shader i was using, awesome support!

 

Hey loving the asset and finding it really easy to use.

I have one issue however. I am using the CursorPositioner to position a target cursor around the level of my isometric game but when raycasting onto "thin geometry" (a sliding door) the raycast hit appears on the wrong side of the door, i.e. facing away from the player object. This doesn't happen with "normal geometry" (walls) where the decal is shown facing towards the player.

I know this is probably a Unity issue, but I wondered if anyone had a workaround for this issue? I have tried to detect if the "hit" and the player are facing the same direction in order to ignore the raycast, but it doesn't seem to detect the difference between a good hit and a bad one.

 

I'm not sure I fully understand the issue, perhaps a picture could better help explain it?

The cursor-positioner will project a ray from the camera, thus the decal should always be facing towards the camera. Currently I'm picturing something in the vein of Diablo, and you want the decal to face your character instead of the camera? Perhaps you could use a ray-positioner instead, that casts from your character to the targeted area?

 

The ray is projected from the player object at a particular eye level, and represents what the player is targetting (I will change the colour of the decal to represent friend/foe/neutral later). I basically took your CursorPositioner class and reimplemented it, inheriting from the Positioner base class.

Yes you have described the problem; when the player object is facing towards the camera and there is door directly "between" the player object and the camera, the cursor appears on the camera side of the door when it should appear on the player object's side. This seems to be an issue with the collider width as it does not happen for walls.

Let me see if I can get a project together than reproduces the issue and post it on github or whatever. That won't be until tonight though (GMT + 1).

 

Coolbeans, send me a link at support@LlockhamIndustries.com, sure we can figure this out, until I see your code I can only really speculate.

 

All fixed with the help of Dan. Long-story-short I was using a Pulse instead of a Decal for my target cursor.

Great support Dan, thanks again!

 

Great asset! Is it possible to make the decals project over angled surfaces in the same mesh? Do different printers behave differently in this regard? Whenever I "Ray Print" into a corner of a room, the decal only appears on one side of the wall.

Also, any plans to support material detection?

Thanks, loving the asset so far!

Edit: Also Custom Shaders/Parallax?

 

@flickitstudios - What do you mean by material detection? as in decal masking based on material?

Custom shaders might be possible, but it would be very, very, very.. very difficult. We would need a way to inject them into the system, a way to modify the decal/pulse component UI based on shader parameters, and every shader would have to be heavily modified to be a decal/pulse shader, so a lot documentation would need to be provided. None of the shaders would be able to support shader-model 2.0 either, as the requirements of the base decal shader already caps it out. Possible, but I think there are definitely more pressing items on my to do list.

A Parallax variant on the PBR decal shader is definitely achievable, though I should note the parallax effect would need to be based on a height provided to the decal itself, not based on the height map of the geometry it's projecting onto.

 

Yeah, a way to spawn a different decal depending on the material, or even layer.

Definitely, thanks for the explanation!

This would be an awesome eventual addition!


Thanks for taking the time to respond, bought the asset yesterday and got it working super fast. Very happy with the results!

 

@flickitstudios - Awesome idea! Went ahead and implemented it .


The idea being you could choose a different bullet-hole or blood decal etc. based on the surface you hit, correct? Doing it based on materials would have been more powerful/presented more fine grained control, but would have been very finicky and un-intuitive to setup and maintain. Layers was pretty easy to implement, covers more use-cases, presents a more intuitive UI and I think it's easier to manage in the long term as well as implement into a large project.

It works with all printers. Just drag the number of printable projections (the slider) to anything above 1, and the selection method drop down will appear. From there select layers, pick the decals you want to print and the layers you want them to print on and your good to go.

This will be in the next patch, but if you want an advanced copy @flickitstudios, send me an email at support@llockhamIndustries.com and ill send you a copy.

 

Amazing, immediately five-starred. I'll be sure to email if I get to that stage before the next patch comes out, thanks so much.

 

Still a no go to use your system on unity terrain shader? :'(

 

@Leoo - The decals themselves should project perfectly onto the terrain. You cannot use the in-built masking on the terrain or its billboarding trees etc., but the rest of the system works beautifully with it.

 

Perfect, blood splatter on terrain at runtime, no need for anything else, dont think ill ever need to mask out the terrain from the splatters lol .

Another silly question, does the decals work alike with the ones Unity has on their docs?, am trying to make those work with a custom terrain shader that dosnt write into deferred path.

Thanks.

 

@Leoo - As in here? The deferred path uses the same base technique, but is obviously extended and fixes a lot of issues that plagues there example. If your rendering in deferred, the system will only be able to project onto objects rendered in the deferred path, and I'm guessing your terrain renders in the forward loop after Deferred, so this will not fix the issue.

If your rendering in forward rendering though, it should work beautifully on anything that can cast a shadow, which I assume your terrain does. If you use forward rendering you should be good.

Edit - Might be able to force the system to render in forward rendering after the deferred loop, making it possible in deferred as well as setups that render in both forward and deferred! Will experiment and get back to you. Got me all excited.

 

Just submitted Dynamic Decals 1.5 to the asset store! 1.5 introduces layer based surface detection for printers, projection blockers and forced forward rendering. I've also renamed the "Pulse" component to the "Omni-Decal" component.

Layer based surface detection allows printers to print different decals, depending on which layer the printer hits when attempting a print. This allows us to, for example, have different bullet-hole decals print based on the surface we hit. More info a few posts back. Huge thanks to @flickitstudios for the idea!

Projection blockers are components that can be attached to cameras to prevent them from rendering decals. This is useful in situations in which you have multiple cameras, but you only want/need decals to show up in some of them. Had this on the to do list for a while now. Huge thanks to @Khavas for the idea!

Forced forward rendering allows the system to render in a forward render loop after the main deferred loop, while using deferred rendering. Thanks to @MadFox & @Leoo for the idea!
There are a few situations in which this is useful.

• If your rendering parts of your scene with custom shaders that only support forward rendering (The Winter Suite for example), the system cannot project decals onto the objects using the deferred technique, because those objects are drawn in a render-loop after the deferred loop has finished, and all the decals have been drawn. By forcing the system to render in the same forward loop, we can draw decals after those objects have rendered, allowing us to draw on them as well.
• If your running a setup with multiple cameras using different rendering paths (some forward some deferred) previously you had to choose which you wanted decals to render on. Now we can force deferred cameras to render as if forward and have all cameras render decals correctly.

As to why the pulse was renamed, "Pulse" came up too often as a naming conflict & I'm trying to avoid implementing a namespace. "Omni-Decal" is also a better representation of what the component actually is, an omni-directional decal.

Thanks for all the support and feedback. Dynamic Decals has come a long way already, wouldn't have been possible without all of you!

 

That's Awesome! Thanks for the wonderful support.

 

I updated from 1.2 to 1.4 today, and I'm happy to see that the decals look much better in forward rendering! Nice work.

However performance isn't better... I don't think it has changed from before, but I recently started testing my game's performance in a release build and realized how much the decals are going to be a problem.

In editor, I go from 45 to 22 with only 68 decals (see screenshots below). I expected it to be much better in release, but not really - I go from about 55 to 35 with 124 decals.

With 68 decals:

Without 68 decals:


Also... isn't it odd that 68 decals use 70k triangles? Aren't the decals quads?

 

@Nimred - Performance is next on the docket, up until now I've been chasing down all the corner cases I didn't predict when writing the system, and just trying to apply feedback in general. While there's still a lot I want to add, I think I'm in a pretty good position to tackle a minor system overhaul.

Your currently throttled on the CPU, running 11ms for 68 decals? What are your PC specs? Are you using custom printers or projectors? I can currently get close to 2000 decals, all moving, in editor, for the same CPU impact on my PC. Are you certain your not disabling something else as well? And the tri's are likely from the shader-replacement required to render the decals (Camera Depth Texture Modes), the decals themselves are just cubes.

Regardless, the system isn't anywhere close to where I want it to be in regards to performance. I'm working towards GPU instancing the entire system now, which will be a pretty major overhaul of the entire core of the system. This will reduce the GPU impact significantly as well as impose a far tighter structure in regards to how data is managed & submitted to be rendered, removing a lot of the redundant/repetitive submissions, which will reduce the CPU impact pretty significantly as well .

Right now all the projection types are hard-coded into the system as well, so adding new decal types is pretty labor intensive. The new structure should decouple them completely, making new types of decals far easier to implement.

It will still be at least a month out, likely more, but don't despair, it's definitely coming.

In the interim, I spent the afternoon going back and optimizing 1.5, so you have something to work with until then. Managed to nail down a few memory allocations and get the CPU impact down about 15-20%. Nothing close to what I expect from the overhaul, but it's a start, I'll submit it to the asset-store as a hot-fix once 1.5 hits. Hit me up at support@LlockhamIndustries.com, I'll send you an advanced copy .

 

Excellent! I'm glad performance improvements are coming. I can wait for the hotfix, 20% improvement is nice but from what you're saying I suspect there's a larger issue at play that is particular to my project.

Obviously I am not disabling anything else I use a keyboard shortcut to disable the game object that contains all the ship's decals - and only this ship's decals. I've enabled and disabled repeatedly with the same impact on frame rate every time.

My computer isn't especially recent but there's no reason decals would be slower on it than pretty much everything else. CPU: Core 2 Quad Q6600 - CG: GTX 960 (last year) - Ram: 8go DDR2

I made some more experiments... I tried disabling cameras, replacing the ship model by a much less complex one, but that made no difference (which is good ). In a situation with 52 decals this time, the profiler shows that Camera.FireOnPreCull increases from 0 to 3.6ms when the decals are active, and Camera.FireOnPreRender increases from 0 to 2.6ms. Unfortunately the editor crashes when I try to activate Deep Profiling, so I don't know what exactly in DynamicDecals.cs is being slow...

I'm gonna try and fix the deep profiling... In the mean time please let me know if you have ideas of things I could try to isolate the problem.

 

Ah, finally got the deep profiling to work. I'm going to assume it's because of all the material properties being set by strings Have you already fixed that in the upcoming 1.5?



Edit: Also is it normal to have 469 calls to UpdateProjection when there's 68 decals?

Edit 2: I forgot to look at OnPreRender... In comparison it does not blow up in Deep Profiling mode, and it looks like the cost is all in the custom camera render. I don't see anything obvious there, and if I'm not mistaken this will not increase with the number of decals, so I don't think it's a big deal.



Edit 3: Actually, why is it called 7 times? Is it because I have 7 cameras..? For the record my space game has different cameras for different scales - the distant stars and skybox are in a galactic camera, local star and planets are in a deep space cam, nearby planets and objects are in a scaled space camera, and finally the proximal camera renders the ships, missiles, and effects. So only this last one should be calling RenderProjections right?

 

All cameras will render decals unless otherwise specified, that's what the projectionBlocker component added in 1.5 was for, so you only have the system overhead on cameras that actually render projections . I've also found a bug in high precision forward rendering, thanks entirely to what you just posted. Turns out while Camera.RenderWithShader (Used to render high precision normals) won't run OnPreCull, OnPreRender etc. from attached scripts, but, it will still run them from assigned delegates. So the system was updating projections unnecessarily whenever the custom-normals camera rendered. Projections should only be updated once per frame, not once per camera.

This bug, coupled with 7 cameras, is likely the culprit for your performance issues, certainly explains it.
If you have the time, please send me an email, would really like you to test the fixed build.

Thanks for taking the time to help track down the issue, really clear & concise bug report, from a corner case I would never have predicted. Wouldn't have found it without you.

We're allowed to give out 12 vouchers (free copies) of our package per year, even if you don't have the time to help test the newest version, your welcome to at least 2 of them. The least I can do. (Send me a message with your email through Unity's "Conversations", so I know it's you )

1.5 is up now, I'll submit the optimized/fixed version as version 1.51 .

 

Ah thanks for the vouchers, but no need

Regarding this ProjectionBlocker, would it not be more efficient to have instead a ProjectionCamera component that you put on the cameras that need to render projections? I can see how you would want the projections to work right out of the box, but at the same time, people with multiple cameras get a large performance hit out of the box instead... There's many cases in Unity games that can require multiple cameras, including special UI cameras and just extending the view range without artifacts.

I'll contact you by email to get the optimized 1.51. You'll know it's me because of my signature

 

If you change your mind, hit me up anytime. Sent you the latest version.
It's been submitted to the asset-store, it should be up for everyone in a few days / next week.

I've also updated the getting started guide with some information on projection blockers, so new users who have multiple cameras should discover them, I'll update my website shortly as well. While ideally new users shouldn't have to worry about blocking cameras out of the box, I value out of the box usability far more than the occasional user experiencing a minor performance hit until they implement blockers. Keep in mind the performance hit your suffering is significantly more than they would experience, as your also experiencing a pretty severe bug that should be fixed in this new version.

Thanks again!

 

Hello, bought this asset. Was wondering how to achieve the effect of blood splatters on a skinned mesh ? I noticed somebody posted an image of a game using this asset for blood. Right now if I project blood on a skinned mesh the decals won't stay fixed and move with the animation if you know what I mean. Do you have an idea ?

 

@bcv - Firstly you need to determine how your printing your blood decals, so either a ray, particle or ray-collision printer will work here. Once you have that setup you need the printer to detect the surface of your skinned mesh. They all use ray-casts to detect collisions, so your skinned mesh needs to be broken down into collision objects. Unless your also using them for rag-dolls, I would recommend you use triggers, instead of actual colliers, as they will be much more performant.

Attach these to the various bones of your skinned mesh & remember to also add rigidbodies, as they will be dynamic and we don't want them to form a compound collider. If your skinned mesh has been "Optimized" by mecanim, you will need to expose these bones so colliders can be attached to them. So for a character, you would use box colliders, adjusted to fit the various portions of your character. Upper arm, lower arm, shoulder, upperchest, middlechest, hips, thigh, calf, neck, head, hands, feet, etc.

Now the part that ties it all together, in each printer's inspector there is a drop down menu titled "Parent", this has 2 options, default and surface. Default will parent the decal to the world, instead of moving with the surface of the object the ray hits. Surface will parent the decal to whatever it hits, ie. the colliders, you just set up. So we want Surface.

Now where the decals collide on joints, such as an elbow, they must pick either collider and move with it. So if a decal is moving with the lower arm and also projecting onto the upper arm, and they rotate independent of each other, it will look a little odd as the decal stretches and moves over the upper arm. To avoid this, I recommend you use lots of relatively small blood decals, about the size of an apple, instead of fewer larger detailed ones. This will have a bigger performance hit for now, but once instancing comes online, we should be able to negate a lot of that, and we can use pooling to keep our performance in check.

Thanks for the support .

 

Thanks for replying. Another question, I was wondering if there's an easy way to change the blend mode used by the Decal script. right now it seems that when I use transparency for the decals they become brighter and brighter, is there a way to change this default behavior ?

 

@bcv - I'm not sure I understand, currently transparency just blends as you would expect, ie. the alpha determines the blend between whats already on screen and what's being drawn. I'm planning on implementing additive and multiplicative blend-modes, But they're still a while out.

Could you post images of this brightening? and if your using PBR decals, it could be the gloss blend that's making your decals look brighter at certain angles, try setting the glossiness of your decal to 0.

 

Hi,

I'm currently using the plugin but having a little trouble with the 'Normal' type decals. I've plugged my normal map and opacity map into the correct areas, but I'm getting nothing showing up. It seems to work with the 'Full' type fine. Is there anything on my end that's going wrong?

Thanks,
Ben

 

@YoLaBengo - Normal and Roughness decals are only possible in deferred rendering. If your using forward rendering, you'll need to switch over to deferred if you want to use these decal types. If your already in deferred, make sure forced forward rendering is not enabled (Window > Dynamic Decals, un-tick Force Forward Rendering) .

 

Works perfectly now, it was the tick box!

Thanks a lot for the quick response

 

Hello there, I was able to pin point the issue, whenever one of the decals is nearby a light I can see a bit of overexposure on their color, I'm not sure how to describe it but looks very saturated and unnatural. Its worth mentioning that the decals have transparency and no emission.

I have played with every setting to try to lessen that saturation but haven't had any success so far, its probably something I'm overlooking though.

You can see in the image the center of each color splat looks quite saturated. cheers

http://imgur.com/a/orbQ3

 

@bcv - Nice find! What's happening is that all of the decals that share the same priority are rendering their base passes at once, then all of their additive light passes at once, so all of the additive light is being blended together. Only occurs in forward rendering with decals that share the same priority. Deferred lighting still appears correctly.

Discovered render.SortingOrder just now because of this, which is incredible! Currently priority is between 0 & 40 because I've been setting the render queue of materials to differentiate them, this will allow me to increase the range tenfold while still fixing this issue!

So as for your fix, we need to make each decal render all of it's passes together. For now (bit of a hack, I'll implement a more thorough solution into the next patch) open up projection.cs and find the line below, should be around line 534

Code (csharp):

1. meshRenderer.shadowCastingMode = UnityEngine.Rendering.ShadowCastingMode.Off;

add this line below it -

Code (csharp):

1. meshRenderer.sortingOrder = Random.Range(1, 32767);

Technically there's still a 1 in 4294705156 chance the issue occurs, but I think it's good enough for now .
You'll have to reset the systems renderers after you've compiled the change, so just switch your main camera to deferred then back to forward real quick, the system will create new renderers for all of your decals, with the random sorting order applied, and viola!

Thanks again for finding this! Happy to throw a free copy of the system your way if your interested. Send me pm .

 

Hey is it possible to use pbr materials with this decal system. I havent seen any realistic style usage of this plugin so i wonder if it is possible to make bullet holes, grunges and material wears with this.

 

@Sbuldan - It's definitely possible to pull off a realistic style with the system. The base decal component render's with a PBR decal shader that pulls from Unity's PBR cg includes, so it looks identical to Unity's standard shader. Both Specular and Metallic workflows are supported.

 

Hey that seems to work, it looks pretty good now thanks. The fix only works on forward rendering though as you mentioned, in deferred the decals look quite dark with that little fix.

Just to clarify, to switch to deferred rendering I only need to uncheck the "Force Forward Rendering" option in the DynamicDecals window correct?

Thanks for the quick fix. cheers

 

@bcv - To enable deferred rendering your camera or player preferences also have to be set to deferred rendering as well.
And no problem, that little hack will break projection priority, I'll have a more robust fix in the next patch, but that will require a fair bit of system redesign, so it'll have to do for now.

 

I just updated to 1.53 and I'm getting lots of NullReferenceExceptions in Unity 5.6.0p3 even using the demo scenes (Base, for example):

NullReferenceException: Object reference not set to an instance of an object
DynamicDecals.UpdateProjections () (at Assets/Dynamic Decals/Components/Core/DynamicDecals.cs:716)
DynamicDecals.LateUpdate () (at Assets/Dynamic Decals/Components/Core/DynamicDecals.cs:1010)

 

@trojanfoe123 - Thanks for the bug report! Known about that one for a few days. Send me an email (Support@LlockhamIndustries.com), uploading a build tonight with a few fixes and optimizations to the 1.5 branch, I'll send you an advanced copy . Up to 1.56 internally, that fix is included.

 

We're using an Ortographic Camera in our projects and no Decals are visible, is there any way to make it work?

 

@sed - Nice find! Never considered orthographic cameras, I'll see what I can do .

 

Hello there, what's the best way to ensure decals are parented to the surface they collide with ?

For example I have a sort of gun device gameobject which upon action, shoots (Instantiates) a prefab projectile, this projectile gameobject is composed of a sphere collider and a Collision Printer, the collision printer has the right Collision Decal selected in its properties and has the Parent dropdown set to surface. Pretty simple and its something you can see working in the demos provided.

Problem is that if somehow this gun device is parented to another object's joint the decals don't seem to stay on the surface they collided with, and instead move with the gun device, do you know what might be going on ?

 

@bcv - Is there any chance I could get you to assemble a quick demo scene for me illustrating the issue? Once I have the problem reproducible I can usually figure out whats happening pretty quickly.

If I was to hazard a guess, could the bullets that are being shot be colliding with the jointed object? In the circumstance that a collision printer collides with multiple objects at once, it uses the first collision object (Chosen Arbitrarily by Unity) which could easily be the joint your gun is attached too. It will still do a ray cast afterwards to get a more accurate position/normal, so it may appear to be printing to another surface, while still attaching to your joint.
You can prevent this by setting the jointed object to a physics layer of your choice, then telling the printer not to print on collisions with that layer via it's "Layers" property.

If you've done that and it's still occurring, try adding the following line to CollisionPrinter.cs at line 107:

Code (csharp):

1.  surface = hit.collider.transform;

 

@sed - Got it working in orthographic! Check you inbox, sent you a build. Completely changes how we sample depth from the depth texture (linear scale not logarithmic) as well as how we reconstruct our world space position in shader.



It'll automatically adjust technique based on the camera being used. I still want to optimize the shader, set it up to compile different versions, but it's enough to hit the ground running for now. Really nice corner case, thanks again!

 

Hello, I put the jointed character in a separate layer and it works fine now thanks a lot.

Still wondering why it collides with itself when the gun thingy is parented to the character, the instantiation of the projectile is happening quite far from the character so nothing should be colliding with it, could be something in my scene though.

Whenever I have more time, I'll try to recreate this in a simple scene to see what was going on. Cheers

 

Hello again, I'm having some performance issues when using a Projection Mask script on a character with a SkinnedMeshRenderer. I profiled the app and noticed that the majority of the time is spent in

ProjectionMask.get_Mesh()
SkinnedMeshRenderer.BakeMesh()
MeshSkinning.skin

As soon as I disable the Projection Mask script on the character, the performance goes back to normal. Is there anything I should be aware of when using this script ?

Regards