Decal QoL Issues

[wookieejedi]

Now that decals are stable and likely to be used more here are 3 QoL issues I and others have noticed:

1. If the player flies within the radius of the decal the decal will disappear (really only noticeable with large decals).

2. If Ship A is next to a decal that hits Ship B and within the decal radius, Ship A will get the decal as well (really only noticeable with large decals). https://cdn.discordapp.com/attachments/223511363807346691/1047961391706947634/image.png

3. Animated sub-models can move outside the range of a decal and have it appeared to slide off of them. https://cdn.discordapp.com/attachments/223511363807346691/1047962145750532106/Blast_It_-_Trim_Wiggle.mp4

[MoerasGrizzly]

I found a fourth issue I'd like to add to this: When a ship breaks up, a decal stays 'in place', snaking across the hull.

[asarium]

@wookieejedi All of these issues are due to how rendering decals is done. A decal is basically just a box we draw in the world and then read the deferred rendering data from where the pixels/fragments ended up on the screen. This allows to determine the location of the object at the decal location which then allows to determine if this pixel is within the volume of the decal. Since nowhere in that pipeline we even know what "object" a decal is attached to, if a second object happens to be within the decal volume, the decal will also be applied to that. Regarding the specific issues:

1. This should be relatively easy since the described effect happens due to backface culling. If you disable that, flying into the decal will work but you would need to somehow figure out how to avoid shading the geometry twice. Maybe an "inside-out" box could be created?
2. As noted, this is due to the system not knowing which object a decal is attached to during rendering. I am not sure if we have that information somewhere but we could add an additional g-buffer that caries the object id or something and then check against that when rendering the decal. That would involve storing additional data through and would decrease rendering performance since more data would need to be stored from the main render pass.
3. This is a similar problem to 2. but more complicated since the decal should still show up on both subobjects. This could use a similar technique to 2. but additionally we match against the submodel id and discard non matching pixels. This would lead to decals only affecting one submodel which would not be the desired effect so instead when creating a decal, it would need to be split into multiple instances, one for each submodel. These separate decals would then be attached to their own submodels which should then look correctly but figuring out which submodels are involved would already require some effort and rendering multiple decals would also decrease render performance.

@MoerasGrizzly If a ship breaks up the rendering gets a bit weird so it would not surprise me if the decal code does not handle that properly.

[wookieejedi]

Ah yeah that all makes sense, thank you for the detailed reply and explanations. Given it would be more expensive to track sub-objects to prevent overlap and track sub-model animation, I reckon it would overall not be super worthwhile then. Overall, the current decal system is really most useful for temporary decals that are somewhat smallish (so those problems mentioned do not really get noticed), and in this regard it's great to even have any decal system at all working, since it adds so much immersion IMO :)