I based my decal rendering technique on the "Volume Decals" article by Emil Persson in GPU Pro 2, although I had to make some tweaks to get texture lookups for 2D decals to work correctly.
For each decal volume you render it comes down to retrieving the world position of your scene geometry at the fragment which is currently being shaded (you can use your depth buffer to reconstruct this position) and using this position to do a texture lookup in your decal texture(s).
If you're using deferred shading you can just overwrite (or even blend) the attributes stored in your g-buffer where your decal is rendered, which means your decals can have their own material properties, and that they can have normal maps and other cool effects.
If you don't own GPU Pro 2 I could give you a more detailed overview of the implementation if you'd like.
Thanks for the quick response... this is where we got stuck
I've read through the thread you posted, and our techniques differ quite a bit.
In my implementation I don't actually do any projective texturing by setting up a projection camera. What I am doing is setting up a 'decal volume' which in my case is a simple cube. I basically look for an intersection plane between my decal volume and the scene geometry. Afterwards I do an orthogonal projection of my decal texture onto this plane within the bounds of the decal volume. The projection direction is determined by the rotation of the decal volume.
The extents of your decal volume can be used to cut off your projected texture in all directions, that way your decal won't project onto surfaces it shouldn't be applied to.
To get your coordinates for sampling your decal texture you can use a reconstructed world position as I mentioned before. Of course you need to transform this position to be local to your decal before it's any useful for texture sampling.
For volume decals I just use the decal-local position for texture sampling. For 2D decals I just ignore the z-component of the sample position, which would be the same as sampling from a volume texture where each depth slice would be identical.
I hope this helps :)
Again thanks, Ill pass this on to telanor and see what he thinks. Your method may be better, i dont know! all that hoopla is beyond me!
You do indeed get a world position, but you need to transform this to a position local to your decal volume. I just use my decal volume's inverse world transformation to get this local position.
Ok that got me closer, I think I just need to scale/offset the resulting coordinates so they're proper texture space coordinates. The usual 0.5 * float2(pos.x, -pos.y) + 0.5 doesn't quite seem to be right. What's the correct way to do this?
Also, if you're using a deferred renderer, how are you handling the transparency in the decal? My GBuffer's alpha channel is used for the specular component, so writing the alpha ends up making the decal shiny. Figured it out, disabling alpha writes solves it.
The range conversion from [-1, 1] to [0, 1] works fine for me, it's just a standard (pos.xy + 1.0) * 0.5.
About disabling alpha writes, you might want to keep it enabled and let your decal write out its own material properties, like specular albedo, roughness, normals, etc. For decal alpha I just use an alpha map, but since I'm using deferred shading it is of course limited to either being completely opaque, or completely transparent (ie. I just discard the pixel). Maybe I should try experimenting with additive blending for some material properties, could give some interesting results.
With your system, have you noticed that when you get a certain distance away the decal offsets? We have this odd thing where if you move past a certain distance the decal changes and offsets by almost half. Thanks for the help with this and thank you for the updates! I owe you one!
Can't say I have this problem. Could you maybe provide some screenshots?
Could this be related to depth buffer precision? I had some nasty issues with this in the past, so I'm keeping a separate buffer with depth stored linearly from which I reconstruct my positions. It's not an optimal solution IMO, but it does solve a lot of headache inducing issues.
For anyone interested, here's another render of multiple decals with varying orientations (click to enlarge):
Wow, that is rather weird indeed. Since the sampling coordinates remain unchanged, could it be a problem with your decal texture's mipmaps?
How are you generating your mips right now? Are you letting your graphics library generate them for you, or do you generate them as a pre-processing step?
I've never used the D3DX library so I couldn't say whether you need to take any precautions with said function related to mipmap generation.
Are the texture's dimensions both powers of two? Normally seeing this shouldn't cause major problems anymore these days, but you never know.
For what it's worth, I can really recommend doing mipmap generation and other texture-processing jobs in a small custom off-line tool. You get a lot more control over the visual quality of your textures, and you reduce your game's loading time. If you'd be interested in developing something like this, a library like nvidia texture tools is a good start.
This is great work man! Love to see what you are doing and how you do it. Do you mind sharing where you found out how to get this to work? We attempted it but got stuck. Thanks again