Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

[RELEASED] Decalicious – Deferred Decal System

Discussion in 'Assets and Asset Store' started by Daerst, Nov 21, 2016.

  1. Perlind-Arts

    Perlind-Arts

    Joined:
    Mar 5, 2017
    Posts:
    4
  2. Jussukka

    Jussukka

    Joined:
    Feb 17, 2016
    Posts:
    25
    We have been encountering this issue lately:

    (Filename: <715772e6e4b047d0a8ae0e7213d3a803> Line: 0)

    NullReferenceException
    at (wrapper managed-to-native) UnityEngine.Material:Internal_CreateWithShader (UnityEngine.Material,UnityEngine.Shader)
    at UnityEngine.Material..ctor (UnityEngine.Shader shader) [0x00007] in <715772e6e4b047d0a8ae0e7213d3a803>:0
    at ThreeEyedGames.DecaliciousRenderer.DrawLimitToGameObjects (UnityEngine.Camera cam) [0x0002d] in <3bd2dc91656e4932a8306bc30791d413>:0
    at ThreeEyedGames.DecaliciousRenderer.OnPreRender () [0x000d8] in <3bd2dc91656e4932a8306bc30791d413>:0

    At one point in game our decals just stop updating.
     
  3. Daerst

    Daerst

    Joined:
    Jun 16, 2016
    Posts:
    275
    As a quick fix, could you please try adding all Decalicious shaders to "Shader Preloading" under Edit -> Project Settings -> Graphics and see if that does any good?
     
  4. deliberative

    deliberative

    Joined:
    Dec 22, 2016
    Posts:
    12
    @Daerst

    Hi! Just bought Decalicious earlier today because I need to project decals on my terrain. I set up a decal and then set my (Unity) terrain in the LimitTo field, but it didn't work (no decal appeared). As soon as I removed the terrain from the LimitTo field, the decal appeared, but then other objects got affected by the decal, and I need to avoid that. In perusing this thread, I noticed some comments from back in April or such saying that Unity terrains in the LimitTo field aren't supported. Is that still the case? Was hoping it would work since the asset store states broadly that the tool works with terrains, but understand if it's still a work in progress.

    Thanks in advance for your help!
     
  5. Daerst

    Daerst

    Joined:
    Jun 16, 2016
    Posts:
    275
    Unfortunately, the LimitTo system still works using meshes, and thus doesn't support the Unity terrain system. This will be reworked, probably using the Unity layers, but I'm still trying to figure out how to do that without breaking backwards-compatibility for people using the old system.
     
  6. Freznosis

    Freznosis

    Joined:
    Jul 16, 2014
    Posts:
    298
    How does this decal system handle potentially 1000's of decals at once on the performance side?
     
  7. Daerst

    Daerst

    Joined:
    Jun 16, 2016
    Posts:
    275
    Decalicious supports instancing, so all Decals that share a material are drawn at once. Sprite sheets are currently not supported, but a basic implementation (that pretty much just allows you to overwrite the UV range per Decal, so you can manually use sprite sheets without breaking instancing) is in the works.

    Thousands of Decals with different materials / textures will undoubtedly be very heavy on performance.

    Note: Objects that use lightmaps, or are affected by different light or Reflection Probes, can’t be instanced. https://docs.unity3d.com/550/Documentation/Manual/GPUInstancing.html
     
  8. guildwriter

    guildwriter

    Joined:
    Mar 30, 2010
    Posts:
    10
    Is there an ETA on the next update? Could really use decals projecting on skinned meshes.
     
  9. Daerst

    Daerst

    Joined:
    Jun 16, 2016
    Posts:
    275
    I know that I've been delaying it for too long, so I will say 'soon', but unfortunately, I can't make any hard promises given my current schedule.

    That should already work with the current version. Or do you mean LimitTo skinned meshes?
     
  10. guildwriter

    guildwriter

    Joined:
    Mar 30, 2010
    Posts:
    10
    Having trouble with the decals not showing on skinned meshes. May ping you about that soon.
     
  11. Daerst

    Daerst

    Joined:
    Jun 16, 2016
    Posts:
    275
    Sure, please get in touch with the details. Make sure your skinned meshes are using deferred rendering, and not a special shader.
     
  12. Daerst

    Daerst

    Joined:
    Jun 16, 2016
    Posts:
    275
    For Decalicious 1.6, I would like to release the new LimitTo system based on Layers.

    I have been thinking back and forth about using a more 'flexible' system (custom Limit groups that allow you to add any MeshRenderers you want, and then be able to limit those), but I think simply limiting to Layers is flexible enough, more performant and way easier to use.

    That said, with this next update, the current LimitTo feature will be removed. This can slightly change the way you use Decalicious and require you to rework related code or scenes. Most importantly, it will no longer be (easily) possible to limit a Decal to one specific MeshRenderer, but it will be easily possible to limit it to a layer. Is this acceptable?

    “If anyone present, for any reason knows why these two should not be joined in Holy Matrimony, let him speak now or forever hold his peace.”
     
  13. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,436
    How would that be implemented exactly? What are the performance implications of it?

    I'm always much better at pointing out things that could go wrong than offering solutions, so here we go:

    - Would the new layer based system only render things on layers again that are used as limit-to masks? Or would it re-render the whole scene?
    - Would the new system be able to limit a decal to a flexible combination of multiple layers or only one layer?
    - How would people best solve usecases where they want to limit decals to only one object, but are unable to isolate the object onto a new layer? E.g. what if someone has 10 cars on a cars layer that all get damage decals? When they crash into each other decals could bleed over from one car to another.
    - How about usecases where people want to use a combination of per-item and per-layer decals for e.g. combining painted markings that cover a large area accross different objects of different materials, but require different damage decals (due to different materials of the objects being hit)?
    - What are the downsides to having more than one Decal.cs component that have different featuresets?
    - Can you implement the layer-based masking system with 0 byte GC allocations?
    - How do the performance cost implications of the different systems scale with numbers of decals and with numbers of total other objects in the scene?
    - How big would the performance and maintainance overhead for keeping both options of limiting be?

    As much as I was and still am in favor of layer based masking as an option, I think there must be quite a few people who have good usecases for the existing functionality and are currently relying on it being kept in (or are for other reasons unable to adjust their layer distribution to serve the decals). I assume many of them are not keeping an eye on this thread because the more productive devs seem to hang out less on the forum.

    Don't base your decision on my opinion, I'm possibly even abandoning the project I was planning to use all the decal stuff for, I'm just sharing my general thoughts on this. Unless there are strong reasons against it, I think having different decal components that server different needs is the way to go, prioritizing backwards compatibility for the existing decal script and putting new functionality into the new one(s).
     
    Daerst likes this.
  14. Daerst

    Daerst

    Joined:
    Jun 16, 2016
    Posts:
    275
    Thanks a lot for your feedback! This definitely helps.

    Decalicious fully relies on CommandBuffers to do the right stuff at the right time. The LimitGroups would work like this:
    You will get access to 32 lists of Renderers that you can fill as you want. For each of those lists, a tiny pixel shader is set that marks one of 32 bits in a target. Then all meshes in the list are drawn using CommandBuffer.DrawMesh. Later when the Decal is drawn, a mask gets handed to the shader, which will be compared per pixel to the previous 32-bit render target. Things get hairy when static batching kicked in before - there is a known bug with the LimitTo functionality that I want to fix along with this update. [NOTE: So far with the single LimitTo object this was handled in a similar way, but not using a bit mask but instead writing the explicit instance ID to a target]
    Layers would actually work very similar. With the SRP one might be able to create a second camera, just set the layers and have it render to a target with a replacement shader, which might make things easier and maybe faster. But for now, performance would be very comparable.

    Most of the stuff that I'm writing below applies equally to layers and limit groups. The main difference is just in 'who handles it' - Unity in itself, or Decalicious in a number of lists.

    Re-cull and -render everything on every [layer | limit group] that is referenced from any Decal. You can then mask as you know from e.g. Cameras.

    First case not at all, you need different [layers | limit groups] for this. Clear point for the more flexible groups. Second case, duplicate the decal and adjust it so that each variant is only displaced on the respective [layer | limit group].

    The Decal.cs components are pretty dumb. They mostly just insert themselves into a buffer and are then handled by the DecalRenderer.cs, so it's not easily possible to diverge too much there.

    I believe so.

    Very comparable with both systems I think.

    Bottomline: In the end, both approaches are similar and it's mainly a usability question. An alternative could be an option to auto-include layers in a group:
    upload_2018-3-15_13-28-46.png
    A Decal could then define a GroupMask (very similar to a LayerMask, but with groups) defining on which of the maximum 32 Limit Groups it would like to render, and the LimitGroups in turn would define which objects are included. In this case, it's the 4 primitives and all characters in the scene.

    Also, I'm just thinking of upgrading the maximum number of LimitGroups to 128, using an ARGB32 render target, or making this automatic or toggleable.
     
    Martin_H likes this.
  15. Daerst

    Daerst

    Joined:
    Jun 16, 2016
    Posts:
    275
    For now, I will only do the first part - Limit To Renderers. The reason is that it's not easily possible to find all Renderers on a specific layer in Unity. Usual rendering happens the other way around: Renderers register themselves for rendering and are put in their respective layer bin. This is not a suitable approach for the Limit system. I will think of a way around this. Until then, one needs to keep track of the Limit Groups manually.
     
    Martin_H likes this.
  16. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,436
    Thanks for the in depth replies! For the nitty gritty tech stuff I'm hoping someone more knowledgable about these things can chime in. Maybe @hippocoder is still interested in this asset?

    You've mentioned SRP, I'm hoping Decalicious will remain compatible to older Unity versions like 5.6 because many people seem not too eager to jump onto the 2017/2018 versions yet, myself included. Think I've recently read SRP isn't quite stable yet or something along those lines, but I'm not following it closely. Might have been in the SEGI thread.

    About the layers, sad to hear those renderers can't be accessed easily. But it is what it is. So how would that instance group thing work exactly? You set those up on some kind of manager object, add the mesh renderers to use as masks there, and give it an ID number, and on the decal you just set that number? Would it be possible to include a component like DecalMask.cs that you can attach to an object and it will automatically add the MeshRenderer of the object it is attached to (and optionally it's children too) to a set group ID? I think that could be a reasonable workflow that minimizes the amount of wasted rendering of objects and solves most usecases that layer based masking would solve.

    You could e.g. add 2 DecalMasks to your terrain, one for UI-like stuff projected from above and one for damage decals, and add 1 DecalMask to all your vehicles to receive just those UI-like projections but not the terrain damage Decals. And on the decals you just set those mask group IDs and the decals don't need to know about the masked objects. Would that work?
     
  17. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Well, HD has decals built in. What is happening with HD is, they're doing a fast depth prepass, so that they can optimise rendering, alpha test and decals. Any 3rd party decal systems would probably find use for it too.
     
    Martin_H likes this.
  18. Daerst

    Daerst

    Joined:
    Jun 16, 2016
    Posts:
    275
    Even if I include SRP, it will not be the only option. Legacy support is important, I agree.

    Pretty much. You get a manager object that allows you to create up to 32/128 LimitGroups. On each LimitGroup, you have a list of GameObjects that you can manage as you see fit. On each Decal, you can not only set one LimitGroup but actually a Mask of them, similar to the way you can set a Culling Mask on the Camera. So for example, if you have groups Terrain, Rocks, Houses and Characters, you could tell a Decal to render on Terrain/Rocks/Houses, but not on Characters. Another Decal might wanna render only on Terrain/Rocks, and another only on Terrain. Performance-wise, each LimitGroup has a cost (because the respective objects need to be rendered again), but the combinations come free.

    So in your example, all UI-like Decals would set Terrain/Cars, while the damage Decals would only set Cars or there could even be individual groups CarVettel, CarHamilton, CarRaeikkoenen etc. (up to a maximum of 128 total groups).

    Decalicious already does this. Still, it doesn't help you with a limiting feature without using further buffers that allow you to which objects occupy which pixels.
     
  19. Exis

    Exis

    Joined:
    Jan 27, 2014
    Posts:
    14
    Hi,

    Unfortunately, it's still Not working in unity 2017.31.f1, I Tried it with 2017.3b08 first, didn't work there either

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

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

    Shader error in 'Decalicious/Deferred Decal': unrecognized identifier 'UNITY_INSTANCING_CBUFFER_START' at Assets/Decalicious/Shader/DecaliciousCommon.cginc(60) (on d3d11)
     
    Last edited: Mar 26, 2018
  20. Daerst

    Daerst

    Joined:
    Jun 16, 2016
    Posts:
    275
    Works for me with 2017.3.1f1. Are you sure you're using the latest Decalicious version (1.5)?
    Specifically, please check line 63 of Decalicious/Shader/DecaliciousCommon.cginc. It should read:
    #if UNITY_VERSION >= 201730
     
  21. Exis

    Exis

    Joined:
    Jan 27, 2014
    Posts:
    14
    My line 63 reads: UNITY_INSTANCING_CBUFFER_END

    "2017" doesn't appear anywhere in the file.

    The issue is, I downloaded it from the Asset store into my project only yesterday, and it's grabbing the latest version, so I'm not sure what's wrong.
     
  22. Daerst

    Daerst

    Joined:
    Jun 16, 2016
    Posts:
    275
    I just did the same and got the latest package, version 1.5 with works just fine for example in 2018.1.0b11.
    Could you please try deleting the full Decalicious folder and re-downloading it from the store? If that doesn't help, please send me a PM so we can work this out.
     
  23. dgoyette

    dgoyette

    Joined:
    Jul 1, 2016
    Posts:
    4,193
    Just adding some feedback regarding the proposed changes to the way Limit will work, with my concern being that it will break the major functionality that sets this package apart from other decal systems.

    Here's an example of how I'm using Decalicious: When something explodes, I find all nearby objects, and put a decal on them. I parent the decal to that object, so that if the object moves later, the decal moves relative to the object. So, each object gets its own personal decal, since any object might move independently, and it needs to take its decal with it.

    A layer-based approach would mean that instead of an object having its own decal, a single decal would affect many objects around it, with no clear parent for the decal. This means that if objects move within the bounding box of the decal, they're look weird as the decal texture doesn't move with it.

    Am I getting this wrong? Or would the layer-based approach still support this use case? In short, will I still be able to put a decal on dynamic objects so that the dynamic object keeps its decal even as it moves?
     
  24. dgoyette

    dgoyette

    Joined:
    Jul 1, 2016
    Posts:
    4,193
    I didn't see anything about this in this thread, but I'm running into an issue using decals on game objects that have multiple materials. I'm curious if these are limitations of the package, or whether I'm just doing something wrong.

    When I set a decal to Limit To a specific object, it appears the decal will only be draw on faces that use the "first" material on the object. For example, I have a panel object with two materials, one on the front, and another on the back. If I put a decal near this object that doesn't use Limit To, the decal is painted on all faces regardless of material. But when I use Limit To, only faces with the first material have the decal.

    For example, in this screenshot, I have one material for the back and sides, and another material for the front. If I Limit a decal to this object, only one material is affected.

    upload_2018-4-6_16-49-50.png
     
  25. Daerst

    Daerst

    Joined:
    Jun 16, 2016
    Posts:
    275
    Thank you, this kind of feedback on your Decalicious use cases is exactly what I need! With the TargetGroup approach described above, you could do a similar thing: find all objects in the vicinity, create a Decal for each as a child so it moves with the parent. Then create a TargetGroup for each object that just contains the respective single object and limit the child-decal to it. You'd get the same result, it's just one more indirection (you're not limiting directly to a GameObject, but instead to a group containing just one GameObject), with one major limitation: you cannot have an inifite amount of limit groups, we're talking about 128 maximum. Could you provide me with some numbers of how many Decals with individual limit object you might have in your game?

    The problem is that your mesh has multiple submeshes, which currently is not respected by the Limit system. Could you please try replacing line 194 of DecaliciousRenderer.cs (it should currently read _bufferLimitTo.DrawMesh(...)) with the following lines and let me know if that fixes it:
    Code (CSharp):
    1. for (int subMesh = 0; subMesh < mf.sharedMesh.subMeshCount; ++subMesh)
    2. {
    3.     _bufferLimitTo.DrawMesh(mf.sharedMesh, mr.transform.localToWorldMatrix,
    4.         _materialLimitToGameObjects, subMesh);
    5. }
     
    Last edited: Apr 8, 2018
  26. dgoyette

    dgoyette

    Joined:
    Jul 1, 2016
    Posts:
    4,193
    128 feels potentially low, but not necessarily a problem. I'm current manually capping the number of objects I apply decals to to about 50, so your proposed cap is in line with what I'm doing now. The specific use-case is an explosion going off, and adding dirt decals to all nearby objects. Some of the objects might be small pieces of debris (rocks and such) that all have rigidbodies, so each need their own decal so it moves with them.

    Yup, that works exactly as I was hoping for. Thanks. :)
     
    Daerst likes this.
  27. dgoyette

    dgoyette

    Joined:
    Jul 1, 2016
    Posts:
    4,193
    Here's a potentially obscure issue. I tested this using an unmodified version of your package in a new project to pinpoint the issue I was having. I found that at runtime, decals weren't showing up from certain angles. I can PM you a test project that shows this happening if you want.

    The reason I say it's obscure is that it only happens under the following combination of conditions:
    • The Scripting Runtime is set to .NET 4.6, not .NET 3.5 in Player settings.
    • Static Batching is enabled in Player settings.
    • The Decal has its Limit To set to an object that is marked as Static.
    • There is at least one other mesh in the scene marked as Static.
    In my test scene, this causes the decal not to show up. If I change any of the above (use .NET 3.5, or disable static batching, or set Limit To to null, or make the object not static, or disable the second static object), the decal shows up properly.

    Note that things look fine in the editor, but as soon as I play the scene the decal disappears. In similar cases in my real scene, the behavior was more erratic, where the decal would only show up when viewed from certain angles. And even though it was set to Limit To, the decal would be drawn onto other Static meshes within its bounds. And in one case, it looked at though there was an invisible plane in front of the decal:

    upload_2018-4-9_15-5-45.png

    That decal you see (the red and black dirt) is set to Limit To the near cube. But it's getting drawn on the floor as well. And you can see the area where the decal is sharply cut off on both the cube and the floor.

    Anyway, I don't know if you support .NET 4.6, which is the only way I've been able to reproduce this issue so far.
     
  28. Daerst

    Daerst

    Joined:
    Jun 16, 2016
    Posts:
    275
    Thanks for the report @dgoyette! Limiting decals to statically batched geometry is a known issue, but as you pointed out it's kinda tricky to reproduce, so I'd appreciate if you could send me your test project. Cheers!
     
  29. dgoyette

    dgoyette

    Joined:
    Jul 1, 2016
    Posts:
    4,193
    I PM'd you the test project.

    On another topic:

    Hi Daerst,

    The above quote is your statement from June of 2017. What is the expected behavior when Limit To is used on a GameObject whose renderer is disabled? I'm finding that this seems to bypass Limit To, and the decal gets drawn on anything nearby.

    To reproduce, simply put two cubes (Cube1 and Cube2) close to each other. Create a decal, and Limit To Cube1. Now disable (but don't remove) Cube1's Mesh Renderer. You should observe that the decal is now drawn on Cube2. Note that this only happens when the Mesh Rendered is disabled. If you remove the mesh renderer entirely, the decal stops rendering.

    This seems like a simple fix:
    if (!mr.enabled) { continue; }


    Sorry to keep reporting things. I'll say that so far I'm very impressed with Decalicious, and it's making my game look a lot better. So, thanks for the great work :)
     
  30. Daerst

    Daerst

    Joined:
    Jun 16, 2016
    Posts:
    275
    Thanks a lot, I will have a look.

    I was able to reproduce the issue. You can see it best if the two cubes overlap. The error is in line 174 in DecaliciousRenderer.cs. Inserting your proposed fix in line 177 resolves this. I'll include it in the next update that I will push soon, thanks a lot!

    You're helping me a lot with this kind of feedback, so please don't apologize! I appreciate the reports and your good words.
     
    Martin_H likes this.
  31. holdingjason

    holdingjason

    Joined:
    Nov 14, 2012
    Posts:
    135
    Have a question that might be more about how the profiler displays information but it is a bit confusion to me that I am hoping someone might be able to clear up. Here is a SS of your demo scene where I shot a bunch of bullets into the wall. Instancing is working and running camera in deferred so all that is good. I see total batches still very high but also instancing showing that it reduced the bullet decals down to a single batch. So is total batches not really mean total batches? In the stat window I can see that is saved 191 batches which makes sense. But the profiler still shows 220 total. Just seems weird I am guessing that total batches is not the final number that is making it to the gpu so you have to use the batches - saved batches from the stat screen to get the real number.

    Thanks so far so good.

    opt.png
     
  32. Jussukka

    Jussukka

    Joined:
    Feb 17, 2016
    Posts:
    25
    Layer based limit to would be ideal! I would even love a layer based exclusion, as I would like to exclude player characters from decals in our environment grid like frost and oil that need to affect everything else (foliage, decals, structures, terrain)
     
  33. dgoyette

    dgoyette

    Joined:
    Jul 1, 2016
    Posts:
    4,193
    I'm creating some "dirt" decals for my scenes right now, where there's a lot of transparency in the material. I'm finding that I can't create a decal whose glossiness only influences the non-transparent areas of the decal. I added something to the shader to address this, but I'm curious if there's already a way to do what I want with built-in functionality.

    As an example, I have this "dirt" decal, which is mostly transparent, but you can see an outline around it:

    upload_2018-5-28_12-6-46.png

    The outline is due to the spec/gloss, and its much more apparent from a steep angle:

    upload_2018-5-28_12-7-32.png

    This is using the Modulate blend mode, though I don't think that matters.

    Anyway, this dirt decal is covering two different materials that have different roughnesses, so there's no way to adjust the gloss of the decal to get it to look right in all cases. What I really want is for the shader not to contribute any glossiness in places where the Albedo texture isn't contributing any color. It turns out that's pretty simple: Just add a float property to the shader that controls how much influence the Albedo alpha has on the gloss/spec contrinution. Then compute the following value:

    Code (CSharp):
    1. float4 albedoAlphaInfluence = (1 - _AlbedoAlphaInfluenceOnGloss) +  _AlbedoAlphaInfluenceOnGloss * tex2D(_MainTex, texUV).a;
    I'm multiplying specularVal and smoothnessVal by this amount. It only really looks right when _AlbedoAlphaInfluenceOnGloss is "1", so this should really be a toggle, but the result is what I'd hoped for. Here's the same decal with the new property set to "1":

    upload_2018-5-28_12-14-38.png

    upload_2018-5-28_12-15-3.png

    Anyway, I'm just curious if this was already something I could have accomplished without adding this property. If not, then consider it for a future feature?
     
    Martin_H likes this.
  34. Daerst

    Daerst

    Joined:
    Jun 16, 2016
    Posts:
    275
    Total batches is what really gets send. Without instancing, your number would be in the direction of 400. Try disabling the DecaliciousRenderer and see how much you're left with.

    I will try to make Decalicious support both the LimitTo GameObject and LayerMasks for limit and exclusion, but it's pretty hard to achieve technically. This functionality will come with a considerable overhead, since it requires rerendering the scene, and I need to see how bad it is.

    If you are using a mask texture, only the areas that are non-black in there should be affected by the decal's roughness. Would this be a way to approach your problem?
     
  35. dgoyette

    dgoyette

    Joined:
    Jul 1, 2016
    Posts:
    4,193
    Ugh, I don't know why I didn't notice that. Assigning a Smoothness map on the material does exactly what I was looking for. Thanks. :)
     
    Daerst likes this.
  36. Daerst

    Daerst

    Joined:
    Jun 16, 2016
    Posts:
    275
    I'm working on a preview of layer-based limiting:
    jjkFEMPwGw.gif

    By now, the feature works and only needs some polishing, but I'm not too sure about performance. It requires a re-render of the full scene (with a replacement shader) to get a depth texture early on, and then another repalcement shader re-render of each individual layer that is selected in any Decal. Due to the way Unity handles its Camera events (allowing you to hook in with CommandBuffers, but with nothing else), this is the best I can do without switching to the Scriptable Render Pipeline, which would require considerable rework of Decalicious.

    Still, I'm not too sure what this means for performance in practice. If you would like to test this experimental new feature and report how the impact on your real-world project is, that would be highly appreciated! Please get in touch via PN, with your invoice number if you have it at hand, and I will provide you with a package in the next couple of days.
     
    barker_s and DwinTeimlon like this.
  37. Thermos

    Thermos

    Joined:
    Feb 23, 2015
    Posts:
    148
    I personally suggest that DO NOT completely move to layer-based limiting. In some use-cases, the performance cost of pre-renderer full scene is acceptable, but in some cases, who only need some simple decals, the old way is better. Don't follow the footsteps of another great deferred decal system(which is deprecated not long ago) in the Asset Store.

    At least leave an option for user to choose which limiting system to use so everyone can use this decal system without worrying about performance. Thanks!
     
    Last edited: Jul 9, 2018
  38. StaggartCreations

    StaggartCreations

    Joined:
    Feb 18, 2015
    Posts:
    2,239
    Hi there,

    I've recently started using Decalicious, so far it's working as advertised! I came across several pain points which I think are grounds for improvement, namely:

    Culling seems to be based on a decal's position, rather than its bounds. This means decals will disappear when its center falls outside of the screen. For us, this unfortunately doesn't make it production ready. Changing the OnWillRenderObject function to an Update function is a dirty fix, but introduces flickering on far away decals. I cannot reproduce this in the demo scene but I also cannot find the differentiating factor between the setup and mine.

    I see atlases are on the roadmap, personally most looking forward to that, as it would make everything easier to manage and of course more performant :)
     
  39. snoops3d

    snoops3d

    Joined:
    Oct 10, 2013
    Posts:
    24
    Hello will this plugin work with unity 2018.2 non hdr pipe line
     
  40. DeadNinja

    DeadNinja

    Joined:
    Jun 3, 2013
    Posts:
    39
    Yes, its work in standart (legacy) pipepline up to 2018.2.2. With little moding it even works in single pass vr.
     
  41. StaggartCreations

    StaggartCreations

    Joined:
    Feb 18, 2015
    Posts:
    2,239
    I did some more testing for the decals disappearing when at the edge of the screen. Could not replicate it in an empty project. But it turns out this happens when the decals are not in the active scene. Though, if only one decal is active, this issue doesn't occur.

    If I press Play, and then active all decals, the issue also doesn't occur. Only when they are already active when playing the scene.

    As it turns out this is because of Static Batching, disabling the batching flag on the decals resolves these issues entirely.
     
  42. Deckard_89

    Deckard_89

    Joined:
    Feb 4, 2016
    Posts:
    315
    Hi, it seems decals don't seem to be showing in builds in 2017.1. In editor they work fine, but when built: nothing. Am I missing something?
     
  43. ChrisRaadjes

    ChrisRaadjes

    Joined:
    Feb 22, 2018
    Posts:
    1
    Hey there,

    Love the plugin! Just wondering if you know when Limiting objects will worked with SkinnedMesh renderers? We can bake our meshes for now, but it'd be really handy for our workflow to not worry about that.

    Thanks for a great plugin!
     
  44. Ruonan

    Ruonan

    Joined:
    Dec 6, 2012
    Posts:
    53
    Hey there,

    GPU Instancing is not working for me.
    The first picture is when I enable Use Light Probes on Decal.
    The second and third is when I disable Light Probes on Decal.

    My GPU support Instancing.
    Do you have any idea what is going wrong?

    upload_2018-8-18_15-7-6.png

    upload_2018-8-18_15-6-4.png

    upload_2018-8-18_15-6-38.png
     
  45. AlexanderElert

    AlexanderElert

    Joined:
    May 31, 2017
    Posts:
    37
    hello, can someone explain to me if it is possible to use this asset with UBER - Standard Shader Ultra , that is, use UBER materials in the model and then apply the decals over this base shader without modifying it.

    Tanks!
     
  46. Cobo3

    Cobo3

    Joined:
    Jun 16, 2013
    Posts:
    66
    Hello!

    Is it possible to modify the code/shader somehow so that we are able to specify the verteices of the decal?
    I mean, right now I can move, rotate and scale the decal, which allows for some cool effects such as skewing, as shown below.


    What I'd like to do, however, is be able to modify the shape completely and accomplish an effect similar to this:


    Is there anyway I can do that?
     
  47. Daerst

    Daerst

    Joined:
    Jun 16, 2016
    Posts:
    275
    Whoa, quite a lot happened here. Somehow the notifications for this thread have gone missing, sorry everyone! Time to follow up...

    Yep, Decalicious doesn't play well with Static Batching. This bug is known for some time, but so far I couldn't find a good fix for it. I'll keep working on it.

    You might want to include all Decalicious-related shaders in build - there were some troubles with this in the past (Edit -> Project Settings -> Graphics -> Always Included Shaders). Let me know if it helps.

    There is some commented-out lines in the DecaliciousRenderer.cs already (50, 163f, 204f). IIRC, it produces some artifacts (a one-frame delay in animation?) and baking the mesh is a heavy operation, so I wanted to go looking for different ways to handle it - but it might already be what you need.

    You can not use light probes and instancing together, Decals that use light probes will be drawn non-instanced. I assume you have no light sources near the decal (only GI through light probes) so the Decal will receive no light at all and end up black. If you can, please send a test scene over so I can have a closer look.

    Have you tried it out? :)

    No, this is currently not possible. Decalicious works the following way: Render a transformed unit cube, and for each covered pixel try to reproject this world position into the transformed unit cube. Given this reprojected position, you can interpolate the texture coordinates of the cube. Then again, it's not so easy to reprojected a point into any given mesh.
    Now you're not asking about any mesh, but just about a (slight) custom displacement of the corners.
    You can achieve some really weird effects if you give your Decal a parent object that has non-uniform scale. Maybe you could try experimenting with that and see if it helps in any way. In the meantime, I will try to think about ways how anything else than a cube could be handled - but I'm not too confident it will work.
     
  48. Daerst

    Daerst

    Joined:
    Jun 16, 2016
    Posts:
    275
    A word on Decalicious / Metal compatibility!

    Also, I have received a number of reports that Decalicious currently does not work on OS X / iPhone using Metal in Unity 2018!

    I would be most interested in knowing whether it ever did work in Metal and broke through some change in recent Unity versions. If you have Decalicious running on Metal, please let me know the Unity version!

    Thanks everyone for your continued interest in this Asset :)
     
  49. Cobo3

    Cobo3

    Joined:
    Jun 16, 2013
    Posts:
    66
    What I want to achieve is an affine transformation. It actually has nothing to do with the mesh being a cube, but more with modifying the resulting uvs.
     
  50. Deckard_89

    Deckard_89

    Joined:
    Feb 4, 2016
    Posts:
    315
    This works, thanks. Why does Unity not include the shaders by default I wonder?