Irrlicht Engine

rogerborg wrote:Is it usable? It looks like it'll happily hang out in space, so it'll look vile when applied near edges.

Yeah, but that's a pretty hard problem that I haven't got time to solve! (either use projective textures or clip the decal mesh to a triangle selector, spanning multiple triangles where required, making sure it doesn't span too many, and scaling along the normals at runtime to avoid z-fighting)
Better to have a 1990s solution than none at all!

to avoid z-fighting

Thats it, thanks for the inspiration.

To make sure it doesnt exceed the surface what you do is make a tradtional decal, then push it back a bit into the surface (using the surface normal).

Then when drawing the decal set its depth function to GREATER, since the decal is deeper than the wall it will be drawn there but the parts that are floating in the air wont be drawn since they are still nearer than background (not GREATER depth).

Since transparent materials are drawn based on order and dont zwrite this wont interfere with them!.

Does irrlicht have a z function setting in the materials section? if not lets add it and try this technqiue.

That's either insanity or genius. I'm leaning towards the latter.

I used a similar technique for decals on the walls, except I just brought them slightly closer in clipspace after transformations in the vertex shader. Since Z is always facing the camera in clipspace, it is impossible to tell if they are up against the wall or not.

SMaterial::ZBuffer supports Off, Less Equal, and Equal, so you may have to alter your technique a bit to work with this set of options.

I setup what you have described but it doesnt handle the sticking infront of the background case, since the background is always behind the decal and hence at a greater depth.

Fantastic idea!
It shouldn't be too hard to add a greater option to SMaterial and the hardware drivers, not sure about the software ones though.
The z-buffer options should be replaced with an enum to make it nice and clean, maybe also add another render pass for objects that need to be rendered after everything but shadows - otherwise there's no guarantee that the greater flag will work on transparent materials.
Any thoughts on this? ESNRP_INSIDE perhaps?

Well we shouldnt be writing the depth values of these decals because anything testing against the zbuffer is probably assuming everything before it was using LESSTHANEQUAL (eg:another transparent object testing if it is occluded by a solid). so they wont affect anything before / after them,and since they are transparent they should get rendered after the solids. But the enum way would work well if we just add it under materialFlags.

I was thinking of say, adding all the decals to a single mesh buffer.
This wouldn't sort properly with transparent materials in the scene, so would really need to be in a special effects pass that comes after the transparent pass. There's one pretty big problem with this technique though:



You'd see the red decal through the blue wall here. Perhaps using GL_GEQUAL / D3DCMP_EQUAL would be better? Or perhaps some stencil buffer trickery?

Surely, in this example, the black wall has an opposite normal to the blue and will be culled (with the decal) at that eye position?

nope, both facing the same way.. Imagine the blue and black walls are double sided and for the sake of awkwardness they both belong to the same surface. Like you're stood in a room looking at the blue wall, and there's a corridor behind it with a bullet hole in the black wall (the hole is behind the wall)

Or perhaps some stencil buffer trickery?

Bitplane if you're gonna take this to the extreme why not have a go at this method?

wow, amazing
I'll leave that one to you BlindSide

well that one looks like a lot of texture memory is needed if really every surface has its own texturemap. might work in a simple demo but seams pretty hard to combine with different shaders.

doh, nice spot bitplane. It needs 2 z tests and i guess thats why people used stencil for them. We can always clip them since the triselectors return the tri.
Clipping should be fast enough since its done realtime per frame for the software rendering so doing it once per decal wouldnt be bad.

I found some code and theorey explaing the clipping then triangulation of the result. the both work in 2d so i guess we have to flatten our triangles onto the x and y plane (using the normal) do the stuff then rotate back again.

http://en.wikipedia.org/wiki/Sutherland-Hodgeman <-clipping
http://www.flipcode.com/archives/Effici ... tion.shtml <-tri

I am trying to do something like that,

instead that it is a wall being shot with paintball guns, so I just have to leave the paint mark.

In my case will I need to change the texture? or there is another technique?