Volume Decals demo

Humus

Crazy coder
Veteran
I haven't published a demo since February, man it's been way too long, but now it's time again! Woot! :)
This one is a little more interactive too since you paint the decals yourself. It's hours of fun! :p

VolumeDecals.jpg


The demo illustrates a technique for decals seamlessly wrapping around arbitrary geometry by rendering decals as convex volumes. The technique will be featured in the upcoming book GPU Pro - Advanced Rendering Techniques.

The demo is available for download here:
http://www.humus.name/
 
Pretty cool demo.
I was wondering if it works on translucent geometry, because you probably normally would not render a Z buffer in that case.
Also for fully transparent mapped patterns like fences or leaves I wonder what would be the result, probably it could work I guess if no Z is written for the transparent regions.
 
It'll work fine for alpha tested stuff, as well as alpha-to-coverage. For alpha blended stuff it's a bit trickier. You wouldn't get any decals on the transparent stuff. The technique is best suited for deferred renderers anyway, and they have a problem with alpha blending anyway. But if you'd use a "deep deferred renderer" though it would integrate just fine.
 
Camera movement is glitched on my machine.
Seems like the movement vector is inverted every n steps causing a back and forward movement (slightly skewed forward).
Happens in all directions and regardless of framerate or if I tap or hold the key. Might be due to a too large collision detection object, but I can't confirm.
 
Another 'issue' with the technique is that it paints on the backside of objects that are thinner than the paint volume. Like splatting on the corner of walls when only one wall is visible there is also paint on the other side. The same happens when painting on bottom of the hanging lights, also the top side is painted. It seems an artifact inherent to the technique that may not be easy to solve, maybe by clipping the paint volume.
 
Camera movement is glitched on my machine.
Seems like the movement vector is inverted every n steps causing a back and forward movement (slightly skewed forward).
Happens in all directions and regardless of framerate or if I tap or hold the key. Might be due to a too large collision detection object, but I can't confirm.

What CPU & GPU?
If you start the demo, open task manager, right click the process and set affinity to CPU0 only, does the problem go away?

Could you whip up a couple of cool DX11 demos for me real quick Humus?

Kthnxby.

I'll get to that once I have a DX11 card.

Another 'issue' with the technique is that it paints on the backside of objects that are thinner than the paint volume. Like splatting on the corner of walls when only one wall is visible there is also paint on the other side. The same happens when painting on bottom of the hanging lights, also the top side is painted. It seems an artifact inherent to the technique that may not be easy to solve, maybe by clipping the paint volume.

Depending on what you're using the decals for it may indeed not be desirable to paint back faces, for instance paint/blood splashes. Burn marks from fires on the other hand looks best if it burns everything within the volume. I elaborate on solutions to this problem in the article. I haven't implemented any techniques for it in the sample though, but it's not too hard to solve. A quick and dirty solution is to look up the normal and simply not apply it to backfaces, which is not 100% perfect in all cases though but solves simple cases like over corners. For a complete visibility check from the point of the blast you can use a "blast shadow map".
 
What CPU & GPU?
If you start the demo, open task manager, right click the process and set affinity to CPU0 only, does the problem go away?
Q6600 and 8800GTS640. Windows 7 final RC, so might be a beta software issue.
Setting affinity didn't help.
Video
 
I used to see similar jumpiness in my older demos when I first got a dual-core CPU. It was a simple effect of timers not being in sync across the CPUs, so every time the process was scheduled on the other core the delta time could be negative, and then shoot forward again. I sorted that issue out in the framework a long time ago though so it really shouldn't happen anymore. Your issue looks slightly different though, the movement back and forth looks smoother than it used to look for me, as if time is progressing by sin(time) or something. Weird.
 
I'll get to that once I have a DX11 card.

Excuses, excuses. Did Einstein ever say "..but I don't have a time machine"? :p

I guess I'll have to wait for the paper, but is the process anywhere along the lines:

1. Trace obstacle
2. Generate omnidirectional light g unit between view point and impact point
3. Render 5 face cubemap as shadowmap
4. Colour shadow map onto world geom

?
 
Q6600 and 8800GTS640. Windows 7 final RC, so might be a beta software issue.
Setting affinity didn't help.
Video

I got the exact same effect in the Deferred shading 2 demo. My HW is different, Phenom 3x and Radeon 4850, but I run Windows 7 final RC too, so I think you're right it might be a beta issue.
 
Excuses, excuses. Did Einstein ever say "..but I don't have a time machine"? :p

I guess I'll have to wait for the paper, but is the process anywhere along the lines:

1. Trace obstacle
2. Generate omnidirectional light g unit between view point and impact point
3. Render 5 face cubemap as shadowmap
4. Colour shadow map onto world geom

?

Not sure I understand what you mean in (2), or why 5 of the cubemap faces would be sufficient. I'd replace 2 & 3 with "render shadow map from impact point", and express 4 somewhat differently perhaps, but yeah, sort of like that.
 
Great, we were thinking of doing something like that.

One minor problem is that you should render these before rendering the "dynamic" objects, to avoid e.g. the foot of a character being affected by the decal.
 
Thanks Humus. Yep, I was going to ask about that (whether you somehow stored into a lightmap or kept it real-time but avoided moving objects).

Btw, I was saying only 5 faces in case you rendered the shadow cubemap orthogonal to the traceline since the 6th surface facing towards the eyeview wouldn't ever be needed. Speaking of which, aren't 3 faces all that are needed? If you render the cubemap at a 45º angle on all axis so that the common vertex of the three faces of the cube is exactly on the trace line? Maybe there's some corner cases I'm neglecting though.
 
Back
Top