I have been looking for a bullet decal package on the asset store. But I have not been able to find anything satisfactory.
The available packages include:
Frameshift Decal Framework: this one gets really bad reviews and besides, the publisher’s website seems to be down.
Decal System from Edelweiss Interactive: this one seems really good for adding decals to the environment but not really for bullet impacts at runtime. I have tested the free version and although it includes several examples of bullet impacts, the resulting decals are extremely stretched if the impacted surface is not close to perpendicular to the direction of the impact.
The projection calculations seem also rather expensive.
The other available packages only handle simple quad decals which simply don’t work on arbitrary geometry.
The only working example of bullet impact decals that I found is the bootcamp demo. But the system is not fully working as is visible on these screenshots.
It seems that the generated mesh is correct, but the uv totally wrong. The problem seems to be due to the orientation of the projection cube. It is indeed oriented along the normal of the impacted face.
I think that the projection cube should in fact be oriented along the average normal of the faces onto which the decal is projected.
I am going to throw in a few aspects about my Decal System. If you don’t like the stretching of the decals, you may have a look at the Bootcamp Simple Unstretched Bullet scene. This is likely what you are looking for.
The performance of the Bootcamp Decals and my Decal System are pretty close when the projection is calculated. That was at least the case when I developed it. Especially if you have several decals, the Bootcamp Decals will be slower due to a lack of built-in batching.
I have tested the unstretched example and I have observed the exact same uv projection problem as in the bootcamp demo. Would you be able to fix this? I’d be glad to use your system actually.
I have also quickly reviewed the code that is available in your examples (the main code is not accessible). And it seems to me that the projection is recalculated each frame, instead of being cached. Am I correct?
Finally, would there be a way to regroup all the bullet impact decals in one drawcall (since they all use the same material) with your system? A bit like NGUI rendering all the GUI in one single drawcall (one per atlas actually)
The uv issue you are encountering exists in every decal solution. What you are proposing could be achieved on your side, by not projecting the decal directly, but first by finding out, how the decal should be placed.
Even AAA games have those side effects.
No, the projection is only computed when it is needed.
That happens already when it is possible. There are situations when it is technically not achievable, but otherwise it is done like that. That’s why there is a difference between decals and projectors. You may think of decals as a container for many projectors in which the batching happens automatically. Just make sure not to use one decals instance per bullet, but use one decals instance which has then several projectors. That’s the way it already works in the examples.
I have to say that you are totally wrong in that matter. Having been a professional videogame developer since 1996. I must say that this problem has been solved a long time ago and does not exist in the vast majority of videogames. This is all the more true in FPS games and of course in AAA games. I have just checked Half Life 2, for example, which is already 10 years old, and the impact decals in this game are perfect. I’ll post some screenshots if you are interested.
The Frameshift Decal Framework has also fixed this problem (and also features some interesting functionalities like blood projections on walls when the player shoots an enemy). But as I explained in my first post, I am very reluctant to use this system because the code seems unclean and the publisher’s website is down (which most probably means no technical support at all).
I have indeed noticed that the projection vector is the key to solving this problem. If I pause the game and rotate the projector in the editor, I manage to fix the problem. Basically the projection vector should be roughly the average of the normals of the faces on which the decal is projected.
It’s my mistake then. =)
This is good news. I am developing a game for android and iOs and I am really cautious regarding the performances.
Your last two answers confirm that the Decal System is definitely worth evaluating further.
Would you be able to add to the Decal System the option of calculating the best projection vector (the average normal) for bullet impact decals?
The Decal System offers you many options. The bullet examples are called examples because that’s what they are. They illustrate you how you can integrate it. It was never meant to be a complete bullet decal solution. You can get rid of the stretching effect as you described it on your own. You know what you want, so you are free to integrate that. Just analyze the area around the impact position and compute the projection angle on your own. There is also the culling angle you can modify in order to fine tune the stretching effect.
You can also achieve blood effects if you want that. The Decal System was made to be flexible and all that should be achievable without even touching the source code.
Well I had played a webplayer demo that they had made available. This demo which was made with the latest version of their system clearly showed bullet decals without any kind of stretch effect, even when shooting at wall angles or at the angle between a wall and the floor.
Unfortunately I have been unable to find this webplayer online recently.
I think I know which effect you mean. In the example scenes, you find a game object named Bullet Example. It has a field named Culling Angle. Lower it to 80 and you should get rid of the most extreme stretching effects.
I already had try to modify this parameter. What it does,it seems, is merely culling out the decal if the impact angle is above this threshold. So in addition to the stretching problem, sometime the bullet hits a wall and the decal is simply not drawn.
As far as I know there is no difference compared to the Frameshift Decal Framework.
That should at least not happen in the example scenes. When you setup your own scene, you have to make everything identical to the example scenes or adjust the scripts, such that the relevant meshes can be found in a consistent way based on the hit collider.
Integrating bullet decals is not a no-brainer. The objects that can be hit, have to be setup in a consistent way, such that the meshes can be found based on the colliders. Further the bullet script needs to consider that object setup. Further the script needs to be adjusted for your needs. I have currently two variants for the impact angle. One just takes the camera rotation, the other one takes the surface angle. You may also think about taking a mix of them and modify the culling angle based on that decision. You may also want to extend it, such that more than one object can be hit. It is not easy and heavily depends on the project specifics.
I have just checked the Frameshift demo I was talking about. And you are right, in fact what they do is just not make the decal wrap around a corner but just clip it. So if you shoot at a corner, you get only half a decal.
I tried to capture some screenshots of Half Life 2 earlier to post them here but screenshot captor doesn’t work with HL2 it seems.
I have tested your system only with the supplied example scenes so far. Here is what I get with the scene “Bootcamp Simple Unstretched Bullet”. That’s with default settings (Culling Angle = 90).
I probably didn’t make my point clear. It is necessary to make your own solution. The examples that come with the Decal System are there to demonstrate what you can achieve technically. It is necessary to tweak the scripts and make them work as you wish. I already proposed you to mix the impact angle with the camera view angle. If you would do that, the stretching you are showing in your screenshot would most likely be eliminated. Further the wood is not affected, even if it would be hit as well. But that is also something I proposed in my previous post. Check if more than one object is hit and create the decal over them.
No matter which decal solution you pick, it is your task to make it working within your scenes. As of now, I am not aware of any complete bullet impact solution for Unity. Technically the decal solutions are all pretty close to each other. But none of them has a complete bullet solution.
Yes you did make your point clear. It is really a shame that your system does not offer a wider range of features and fails at proposing a fully working bullet and other impacts decals system. I am glad that not all Unity extensions developers have the same policy and are dedicated enough to improve and revise their system based on the user’s feedback.
Of course the actual solution would be for the developers at Unity Technologies to develop a built in decal system. Let’s hope that they will start working on this in the not so distant future.
Unfortunately, lots of Unity features are way behind the current standards of the videogame industry, either because they have never been included in Unity in the first place, like the decals, or because they have not been modified since the very early versions, like the lensflares (which are just ridiculous).
Regarding the camera view angle, I don’t think that it has anything to do with the decals. The player can shoot bullets in any direction so the bullets can impact the geometry at any angle, including very extreme ones. And we want the decal to be always projected along the normal of the impacted face and never along the camera view angle. Using the camera view angle as a projection vector is the reason for these extremely deformed decals which seem normal right after impact and as long as the camera remains at the same position, but are in fact extremely stretched.
If I were you I’d at least fix this problem right away.
Regarding the wrapping of the decals around the corners, as I put it in a previous post, is due to the decal being projected on several faces and on the projection vector being the normal of the main impacted face. The projection vector should be an average of the normals of the impacted faces. The camera view angle is not linked to this problem in any way. The problem would be exactly the same at any camera view angle and the correct projection vector (which would fix the problem) is the same at any camera view angle.
What I did was to offer you productive solutions for the current situation.
If you have a look at the Decal System thread, you will directly see that I am spending a lot of time to improve the Decal System based on user feedback. It was originally created to be a design tool and I am constantly extending it, to make it usable in a wider range of applications.
At first I misunderstood your proposal to compute the uvs based on the normals and the technique you were referring to didn’t come to my mind. But this one will also have artifacts at the edges. Sure, the stretching is removed, but the solution is still not perfect.
I find your attitude rather unreasonable, that’s why you can’t expect any answer in this thread from me anymore. The reason is likely a lack of dedication for my extensions.
OP you were rude and unreasonable throughout this post! The main solution was given to you…If you need the decals to do something you can make them do what you need yourself. How can the developer be expected to create every need for every user and not only that, but for free as you are clearly demanding. Also Unity is a game development framework, it doesn’t give you a finished game when you turn it on!! If you want better lensflare, make a better lenseflare! For someone that has been working in the gaming industry for 17 years, you really should be capable of building scripts to match your needs and understand the fact tools like this give the framework to develop not out of the box solutions to every problem. I hope people like Dantus are not put off helping people who need it after being spoken to like that, otherwise we are all going to lose out.
I am glad Dantus has decided to no longer offer support towards this post
1/ I have not been rude at all. Could you please point a word a sentence which in your opinion is rude?
2/ Although I fully understand that some work has to be done by the developer, an API like the decals system should be usable as a service by and remain as a “blackbox” with no need at all for the developer to dive into the code (which by the way is unavailable in the case of the Decal System). What would you say if each developer had to write his own code to make Unity’s built in lightmapping, or Shuriken, or Mecanim, work as expected?
The principle of an API is for the developer to call it by code and find innovative ways to use it. Not to add code within the API to make it work normally. Furthermore, adding code within the API should only be used to customize it and provide some unusual functionnality. Once again, it should not be required to make it work normally.
3/ I have indeed developed my own lensflare but that’s nothing more than a workaround. Any rendering functionnality which can have much impact on performances, like lensflare, should never be implemented by script but in C++ by the developers of the engine. In fact, as I explained in one of my earlier posts, it is also the case for decals which shoud obviously be directly built in Unity and implemented in C++. The Decal System itself is nothing more than a workaround for something that has to be built in a 3d game engine.
4/ I have indeed been working in the videogame industry for 17 years and I have conceived and directed a couple of AAA titles. That’s why I know pretty much what I am talking about.
I would like to add that I have contacted most of the developers of the various packages that I am using and none of them has reacted the way Dantus did. They all kindly replied to my inquiries and took the time to study my requests. Several of them have developed special versions of their package especially for me and have sent them to me privately.
I have pointed out a very obvious problem in the Decal System (look at the screenshot) and merely asked for it to be fixed.
