Decal System

In the example scene, you have an object named "Skinned Bullet Example". That one contains a "Skinned Bullet Example CS" component with a Decals Prefab field. This one has to be a prefab that is not in the scene. To me, it seems you make it different.

Just try to mimic 100% what happens in the demo scene and based on that you can move towards your own solution.

PS If you prefer it to write in german, just write me a mail.

 

Actually, I did exactly that... I assigned a .prefab file (which was not in the scene) to the Decals Prefab field. I just tested out the example scene and noticed that even there I can only produce 4 decals? I'm starting to wonder if it is really just my Unity going all crazy (?), if that's even possible.

 

That sounds weird indeed. It is the first time I hear of such an issue. You may try to create a new project, import the newest version of the Decal System and try the demo scene there. Does it work like that?

 

Hey,
Sorry If you have already answered this, but before I go ahead an purchase this, I want to project the decal onto a moving object with the decal as a child of this object (so the decal stays in the same place relative to the moving object). Obviously I only want the decal to update once (or if i tell it to) to save on performance - will this work?

 

Yes that works. You may check the dynamic object scene (Assets/Decal System Demos/Scenes/Bootcamp Simple With Dynamic Object).

 

I have a little problem with blood splatting.

How can i fix it?

 

There are several things you may try. First, this issue is present in every decal solution I am aware of. For runtime purposes it is not that simple to get rid of the issue. Possible solutions are:

• Lower the culling angle below 90. Try 80 or 85.
• Compute the rotation of the projector not only based on the impact position normal or the camera orientation, but based on the environment around it. A sphere cast instead of a raycast may be useful at runtime.

Hope this helps.

 

hi Dantus,

Thanks for sharing us your decal system.

Is it possible to change uv1RectangleIndex without update the mesh info(add projector, cut plane) again ?

 

Welcome to the forum!

No, this is not possible for a simple reason. The Decal System needs the internal representation for all those complex computations. But in the case that it is used as a design tool only to add some final touches to a level, there is no need to have that internal data always around. Indeed it would be a huge waste of system resources. For that reason, it is necessary to recreate it on your own at runtime.

 

Hello it's me again, I uploaded an online web build of my test project... just ignore the S***ty menu and the falling soldiers xD I was really just testing out stuff... just try and shoot at the character model that is standing there in the t-pose

https://dl.dropboxusercontent.com/u/17637038/Neuer%20Ordner.html

 

I have the same issue with your player. You need to send me the project, such that I can check what is going on to resolve the issue.

 

Hm.... Dantus I have to say: something really weird happened.
I created a new project and now it works, even though the decals are z-fighting.... the limit is gone... I wonder what I messed up in the past 3 test-projects... I am thinking if I maybe used a script or something that is not compatible with the decal system, given that that is even possible (?)... huh.... I just don't understand

Thanks for your help, I gotta say it again: your work is awesome and I really appreciate your support you are giving to us

 

Actually Dantus... I just found out what the problem was :O

I was intensively trying to understand what I had been doing wrong or different in the past three test-projects, and then it struck me: this one time I had forgotten to choose the DirectX 11 version....
So then I tried... and retried... and retried again; several times... and yup: in fact, everytime I use DX9 the decals place themselves nicely and as they should on the skinned mesh, but as soon as I use DX 11 the limit of 4 decals is back again °____°

Is this a bug in the decal system? Or maybe Unity? :O

 

I tend to say it is a Unity bug, because if it works with DX9, it should also work with DX11. But I certainly need to check first what happens exactly. Which shader did you use? That may also help me to find the cause.
Thanks for reporting!

 

At first I used the standard bootcamp demo shader (the one that you also used in the skinned bullet example scene if I remember correctly)... Then I tried the Transparent/Cutout/Diffuse... Both didn't work (they had the same limit problem in DX11 version)

 

For your information:
I found several issues with DX11 and custom meshes. I couldn't actually resolve the issue you encountered as it seems to be a Unity bug. I need some time in the coming weeks to isolate it.

 

It's no problem, the support you are giving for your decal system is already really really awesome! Take your time, I'll focus on modelling and programming other stuff meanwhile

 

Hi

I just found this promising unity package and would like to test it out in my prototype scene.

What I need is a decal system that is able to project bullet holes, created dynamically after being hit by a weapon unto my vehicles.

I see there are scripts that seem to be able to do that in the free package, but I do not see any example scene showing how to use this scripts. Did I miss it somehow? Or is there a video telling me what I need to know to start using it?


Thanks in advance for the information

Gian-Reto

EDIT: forget it, I just found it. Doh, who would have guessed that a right click fires an invisible weapon?

 

There is no video for the runtime scripts, but there are several scenes. They are located in Assets/Decal System Demos/Scenes. There is a bunch of bullet example scripts that are use in those scenes which have lots of explanation within the code. If you have trouble to understand something, don't hesitate to ask.

 

Thanks, but your example script works like a charm after some minor tweaking and integration into my damage system.
And being able to put numbers on the vehicles is also pretty cool.
Even the FPS remained stable.

Expect a five-star recommendation from me in the future


Cheers

Gian-Reto

 

Thanks

 

Hello,

I have a question for the Decal System. I want to get the UV of the projected area corners on the original mesh. I saw a property called PreservedProjectedUVArrays available in the pro version, is it exactly meant to provide this information?

Thank you!

Simon

 

Welcome to the forum!

I am not sure if I understood you correctly, so just ask again if I got it wrong.
I assume that you want to get to uvs of the mesh onto which you perform the projection. In that case, change the Projection to Advanced, then change the UV mode to TargetUV.

 

Hello, Thank you for your quick reply.

I changed the projection to advanced, and changed the UV2 to TargetUV2. I think I can access these values by individual vertex using .LinkedDecalsMesh.UV2s[vertexIndex]. Is there a way to access only the 4 corners of the decals like CurrentUvRectangles ?

Thank you!

Simon

 

No, that information is not directly available. But you may calculate that on your own. Bring the vertex to projector space and in there you need to check whether it is the one at the corner. Like that you are getting the vertex index with which you also find the uv2 coordinate.
Sure that's not straight forward, but it works.

 

Thanks a lot !

 

Another quick question.

As it is a mobile game, I am trying to avoid any calculations that aren't necessary. Instead of bringing the vertex to projector space, do you think I could use :

Edelweiss.DecalSystem.DecalsMesh tMesh = ...

int tLowerIdx = tMesh.ActiveDecalProjector.DecalsMeshLowerVertexIndex;
int tUpperIdx = tMesh.ActiveDecalProjector.DecalsMeshUpperVertexIndex;

Vector2 tLowerUV = tMesh.UV2s[tLowerIdx];
Vector2 tUpperUV = tMesh.UV2s[tUpperIdx];

On my side, it seems that Decals Mesh Lower and Upper Vertex Index are always in the decal mesh but not always the lower and upper vertex, maybe it's because of something in my code. But I wanted to know if you think it could work using this code ?

Thank you!

Simon

 

You can't make this kind of assumptions because the order of the vertices is arbitrary. The Decal System takes an existing mesh along with the order in which the vertices are provided. Usually the cut operations are performed which means that vertices may be removed and new ones are added at the end. That's why you can't make any assumption about some specific vertices. They are in the range given by lower and upper as you pointed out, but within that it you can't expect any kind of structure.

 

Hi,

Are there any known stability issues with Decal System and 4.3.1f1? I've added some decals in four times and each time it crashes and takes Unity down with it. Sometimes it was editing the mesh offset, sometimes just moving the decals around.

Looks a great system, exactly what we want. Very keen to get it into our production pipeline, so just a little worried on the stability.

Also could I just ask about the pro features. Nothing on that list really stands out as something we'd need, except maybe vertex colouring. Are there plans for any more features? Is the source code the main differential?

Thanks

Richard
@Total Monkery

 

Welcome to the forum!

There is indeed a know stability issue for DX11. It is due to a Unity bug. I was able to reproduce it just a few days ago. There are a few more contexts that need to be tested, but you can expect a bug fix release within one or two weeks. Let me know if you would like to get it earlier.
The Pro version indeed contains the source code. Besides that you find the relevant differences in this post:
http://forum.unity3d.com/threads/141792-Decal-System/page33?p=1335738&viewfull=1#post1335738

As most developers, I tend not to talk about unfinished work. At the moment I have two new features in the pipeline. One of them is new projection mode, the other is a mesh minimizer for flat areas. The current implementation produces meshes with more vertices than actually needed. The minimizer will be an extra step to remove them. This will especially be useful in the Unity editor. Those two features will be in the Pro version only.

There are certainly more ideas, but nothing to announce yet.

Hope this helps

 

Hi,

Thanks for the really quick reply. Yes, we are indeed DX11 based as we plan on console and PC release. Happy that this is already known about and not some new bug that's just popped up. We can wait on a fix as we can work on something else while we wait. As I said, I think we're happy to use this as our decal system and we'll probably get the pro licence when the fix is in.

I would be interested in knowing how the optimization works for real-time decals as this is something we are considering as well. However, once we get the pro version I can delve in.

Again, thanks for the reply and looking forward to the fix. Really nice system you've got going.

Richard
@Total Monkery

 

In the case that you want some information already now, you can tell me which optimization exactly you mean and I would explain you some details about it.

 

Hey Dantus, thanks for a great asset!
I am attempting to do some blood splatter by instantiating it in realtime.
I have used the example script that you provided(the bullet hole one), but when my decals spawn, they only lay onto the mesh they collide with and are not projected over several meshes, as it would when i place decal by hand. Is this intentional and/or is it possible to make it project onto several meshes?

Best Regards.

 

It is possible to affect more than one mesh. The tricky part is to find all of them. One solution is to replace the raycast by a spherecast(all) in the code and adjust everything else accordingly.

 

Hi

I have two questions that might be difficultto answer, and I might be asking the Wrong Person, but here goes anyway:

1) I am trying to integrate a system for skid marks into my racing game prototype... now I've seen that most people build these with trail renderers. I gave this solution a spin and have to say it does not work for me. I would like to have more control over the skid marks , and after getting awesome results with using your decal system for bullet holes, I would love to store and project them unto the terrain with a decal system.

Now what I want to try is creating a decal at runtime just as with the bullet holes, only this time instead of creating a mesh of a fixed size with a simple UV projection, I want d polygon strip of fixed width with variable length and a tiling UV projection ( just what the trail renderer does), and then assign this procedurally created decal to a projector, replacing it every frame or two as long as this decal is still growing in length.

would something like this work somehow?

2) l use the global fog image effect, and as this image effect is drawn on top of transparent particles and other transparent geometry, I had to make Use of the @draw Opaque attribute ... side effect is that the transparent shaders are now drawn always on top and they are conflicting with each other ... the decals from your system are also affected.

I would suspect the problem is that they don't write to the Z-Buffer... any ideas how I can change that behaviour so that the decals are drawn at the right time?


EDIT:

Problem 3: "Shader wants tangents, but the mesh Bullet Decals Mesh Instance doesn't have them"

I use a bumped version of the decal shader, and I get this message.... any idea how to resolve it so that the generated meshes are generated with tangents?


Thanks for any input in advance

Gian-Reto

 

Hi Dantus,

I'd like to second problem number 2 that gian-reto described - all the decals are drawing on top of the global fog. Our shader programmer has solved it for our own transparency shaders, but the decals are still a problem.

Furthermore, I'm having a lighting issue. We're using exclusively real-time lighting, and yet the decals aren't being lit correctly - some of them will sort of flicker in and out of proper lighting, sometimes very dark and sometimes very bright, even when you're moving right past them up close. Others are just always incorrectly lit (typically too dark, as if the light doesn't affect them and they're only lit by the ambient light), and very few of them will always be correctly lit. I'm wondering if this is because the decals are spread out across a rather large area with different lights hitting different parts of the mesh?

Thanks!

Jonas
Logic Artists

 

We would probably want to drop decals as footprints so simple top down projections, so I was wondering if the overheard for the mesh calculations could be simpler? Also (sorry for not having looked if this is the case) can the decals be removed efficiently and the mesh recalculated when we want to remove certain elements (like an old footstep if we have a max count)?

 

I am not sure if using decals for skid marks makes sense from a performance point of view. Though it may work. But as only rectangles can be projected at the moment, it would need to be generalized a little. I'll look into it and come back to you within a few days.

You need to change the shader to achieve the correct behaviour. Maybe it helps to enable z write, but I am not really sure about that or change the queue, such that the decals are drawn earlier. But I am not sure if that helps. If you do funky stuff that affects transparent shaders, it will have an impact on the decals as well.

Change the projection type in the decals instance to the bumped diffuse.

 

Welcome to the forum!
Ask the shader programmer to do the same for the decal shaders. It would be awesome if you could ask what needs to be done and hopefully post the solution or the idea here. It is very likely not something that can or should be done in general, but at least knowing the solution may help!

Which graphics setup are you using? Are you using forward or deferred lighting? Have you DX11 enabled?
If too many lights affect a mesh, more than defined in the Pixel Light Count in the quality settings, it will be light too extremely. You may try that with any mesh. If you span the projectors of a decals instance over a huge area with lots of lights, it is very likely that you end up with too many lights.
If it doesn't help, I would need to have a closer look at the project or I would need to get a reproduction to investigate the issue more closely.

 

No, because the way decals are computed will still stay as is. That means the complexity mostly depends on the number of vertices/triangles of the mesh onto which you are performing the decal projection.

Yes, you may have a look at the bullet decal examples. When a certain amount of projectors is reached, the oldest one is automatically removed. You are open to implement your own solution to remove the footprints after a certain time or whatever criterion makes sense for you. With the Decal System Pro you could even fade them out before removing them.

 

Hi Dantus

Thanks for checking my questions.... I know they might be a little out there. I'm not sure about the skid marks myself, but after trying the trail renderer and finding it unsuitable, I have run out of options basically.

About the draw order: I will test around a little. The "Funky stuff" was sadly just what is necessary to make the global fog work with particles and transparent shaders, which is not only looking better than the normal fog, but the only option if you are using lots of SSAO (which is drawn on top of the normal fog!)...


Ah, the "BumpedDiffuse" option did the trick... I somehow missed this.


Thanks for the help

Gian-Reto

 

Hello once i want to thank you for your unremitting support,
i have a simple question, in your bullet hole example, how can i make parent the decal projector to hit object? so i mean decal can stick to dynamic objects?( decalsPrefab.parent=l_RaycastHit.transform ?? )
thank you.

There is a video about decal system of my project;

 

Did that some time ago, its actually pretty simple:

- Add the bullet example script as component to your moving object. Make sure the Decals Prefab you want to use is setup correctly and drag it to the respective parameter field in the script. Then, make sure you are calling the Bullet example script from your own scripts every time you want to add a decal. Bam, you are done (leaving out all the small customization steps I had to do because they might not be needed for you)


One thing to keep in mind: If you have a complex object consisting of multiple meshes that move in relation to each other, each mesh gameobject needs its own Bullet example script, and you need to trigger that to create the decals to be projected unto this second mesh (as the decal projector will be static relativ to whatever object the script is added to, so if you have a tank with a turret that is a seperate mesh and turnable, you need 2 Instances of the script)...

I don't know about skinned meshes, but will find out soon (moving away from multiple meshes, combining all the meshes to a single skinned one for draw call optimization).

Hope this helps

Gian-Reto

 

Are you on Skype? If you can show me your project, we may have a look at it. This would heavily simplify the communication.
My Skype name is: edelweissinteractive

 

Thank you very much Dantus, that was exactly the problem. I spent the day splitting up our giant decals into a whole bunch of smaller groups so no single decal mesh would be affected by more than 3 lights at a time, and now everything is lit the way it's supposed to be.

I'll ask our shader guy to take a look at the decal shader, and I'll report back here to let you know how he manages to fix it.

 

Thanks a lot!

 

Hi,

I'm currently evaluating the decal system and need to use it on skinned meshes. And good surprise, it works great

The only problem, which unfortunately is a hard requirement for us, is that we also need blend shapes, and apparently this is not supported. For what I can see, it projects on the original mesh (as if it had no blend shape), and the resulting decal mesh has no blend shape either.

I don't see a way to make it work, but maybe I'm missing something ? It should be sufficient for our needs if the projection was made on the displaced mesh, even if the resulting decal mesh has no blend shape (we could re-project each time the blend shape weights are changed on the original mesh).

Thanks.

 

Yes I am on Skype.... I will contact you as soon as I need more input.

I checked the whole thing again and it seems that I indeed also suffer from the same problem that was described before... to many lights leading to an incorrect shading of the decal. It works fine with the single searchlight on my vehicle, but the front row of lights (about 6 or 10.... yes, maybe a little heavy, I try to test the deferred shading )does seem to lead to issues with the lighting.

There also still seems to be a problem with the Z-Buffer with some transparent meshes (lightshafts to be precise), but I am not sure if the problem is with the Decal or the Lightshaft. It seems that as soon as the Decal is "in" the middle of the lightshaft, the lightshaft gets ignored and the decal is drawn before it.

I'll test some more and let you know

 

That topic is on my todo list. I don't know yet how difficult it is to achieve that functionality. I can't make any promises right now.

 

Played around with the ZWrite setting in both the decal shader and the transparent lightbeam shader. Did not help at all to set it on, seems to be a different problem.

To illustrate the problem, I made two pictures of it:


This is how it should look, and how it looks as long as the lightbeam is more than ~5 meters away from the decal. The Lightbeam is drawn on top of the decal as it should be.


This is how it look when the vehicle gets closer to the decal. The Lightbeam is NOT Intersecting the Decal at all, maybe touching it, maybe just parts of the lightbeam being farther away than the decal (lightbeam is pretty long).

Is there something going wrong with Z-Testing? Is it the blend mode? Any Idea what I could still try?


The Decal shader is the transparent vertexlit one, as I did not get good results with the others.

Also, the lightbeam shader is set to ignore projectors.