Offset Mapping

At last I got home so I could play around with it a bit. It doesn't "morph" as much as I thought it would. (At least not with the height maps they used.) So there's little need for the extra iterations I spoke about. And in fact, when it's hard to make the iterations converge (at the edges), it looks better with just one iteration.

So just scrap my idea. :(
 
The image looks really nice.
At first I thought it was some real form of Displacement Mapping like the good old Relief Texture Mapping; cause the wall looks very similiar to the wall in the RTM.pdf, but then I saw that here the edge of the texture is not displaced (as someone pointed out above).

I'm still wondering a little bit why Relief Texture Mapping is not used in games?
 
Basic said:
At last I got home so I could play around with it a bit. It doesn't "morph" as much as I thought it would. (At least not with the height maps they used.) So there's little need for the extra iterations I spoke about. And in fact, when it's hard to make the iterations converge (at the edges), it looks better with just one iteration.

So just scrap my idea. :(

Yeah, I didn't think it would help much. The problem is that at the edges, not only is the height (and subsequently the displacement) small, but you can never go "backwards", i.e. find out which texel displaces to that point, rather than assume the displacement of the current texel will find you this texel.

That's why I think PTM's to determine the displacement amount should work nicely, but it'll be a fair amount of work to implement this.

BTW, the author asks if anyone has done this already, and I think I've seen it before:
http://shaderstudio.com/images/Displace.jpg
"This is my attempt to push the Radeon 8500 to it's limit. I show a picture of the Displacement of an image by an amount in the alpha channel to a polygon shown here overlayed. This shows that it is in fact just one polygon, and this is in Real-Time >450FPS for just this one polygon. I haven't completed the algorithm so i'm not putting it's shader online yet, if anyone wishes to discuss it further, start up a thread on the forum, email or chat with me."

It looks like a similar technique to me, but the author uses a pretty crappy texture and no lighting.
 
Well, I've tried this out myself now, and the results are surpricingly good, given that you use a smooth bumpmap as adviced. I'm thinking of doing a demo of this combined with self shading bumpmapping. Should improve things quite a bit.
 
mboeller said:
The image looks really nice.
At first I thought it was some real form of Displacement Mapping like the good old Relief Texture Mapping; cause the wall looks very similiar to the wall in the RTM.pdf, but then I saw that here the edge of the texture is not displaced (as someone pointed out above).

I'm still wondering a little bit why Relief Texture Mapping is not used in games?
A site that has a couple cool RTM examples is http://www.paralelo.com.br/en/portfolio/realtime3d/cg/index.php
 
Basic, I just realized what wasn't working with your code that you suggested. Instead of:

Code:
TEX height, fragment.texcoord[0], texture[2], 2D;
MAD height, height, 0.04, -0.02; # scale and bias
MAD newtexcoord, height, eyevects, fragment.texcoord[0];

TEX height, newtexcoord, texture[2], 2D;
MAD height, height, 0.04, -0.02; # scale and bias
MAD newtexcoord, height, eyevects, fragment.texcoord[0];

TEX height, newtexcoord, texture[2], 2D;
MAD height, height, 0.04, -0.02; # scale and bias
MAD newtexcoord, height, eyevects, fragment.texcoord[0];

do this:

Code:
MAD newtexcoord, 0.02, eyevects, fragment.texcoord[0];

TEX height, newtexcoord, texture[2], 2D;
MAD height, height, 0.04, -0.02; # scale and bias
MAD newtexcoord, height, eyevects, fragment.texcoord[0];

TEX height, newtexcoord, texture[2], 2D;
MAD height, height, 0.04, -0.02; # scale and bias
MAD newtexcoord, height, eyevects, fragment.texcoord[0];

Basically, this just changes the starting point of the iteration.

This fixes some problems, most notably the clipping that occurs on sharp features, but creates other problems. You get some doubling up of features if the view angle is extreme enough and the feature is thin enough, as you essentially hop right over the feature during iteration. If you output the final height value to the screen before it's scaled, you'll see it clearly.
 
Humus said:
Well, I've tried this out myself now, and the results are surpricingly good, given that you use a smooth bumpmap as adviced. I'm thinking of doing a demo of this combined with self shading bumpmapping. Should improve things quite a bit.

Humus, you should use a horizon map lookup value (using the eye position) to determine the displacement. The visibility information will help you determine the real location of the occluding texel. This should get rid of most of the artifacts, or at least the major ones.

Ideally, though, you should create a new horizon map that tells you how much to displace, and if you want, you can use this to test for shadows. I'd love to see the results.

EDIT: I think I just described view dependent displacement mapping. So much for originality :)
 
Like Dio said, this is fascinating.

I asked Tim Sweeney about this and he had this to say :

Tim Sweeney said:
Anthony,

I saw this kind of technique in action a couple months ago when visiting a
developer that was prototyping something similar. It looks *incredibly*
impressive in situations where you don't expect to see gratuitous silhoette
edges, and even in the worst cases didn't look worse than an ordinary bump
mapped surface. It's a really great use of shader programs, and illustrates
the kind of thing that's possible when you think beyond shaders as just
doing traditional texturing and lighting.

PS. I had to remove part of his email that referenced some stuff in UnrealEngine3.

I'm experimenting with this as I type.
 
PS. I had to remove part of his email that referenced some stuff in UnrealEngine3.

Yet you had to mention it after all; now where have I misplace that old rotten trout again? :devilish:
 
Mintmaster:
I changed the bias instead (not in the shader I posted here, but when I started to experiment practically). Meaning that the height map only contain grooves. It's not the exact same thing, but "stays on top of the edge" in the same way as yours.

I havent tried everything I want with lod bias yet though (TXB instead of TEX). The shader became too long so I could only add one iteration. It probably won't help for sharp edges though. It would mostly be there to make small bumps overlayed on large bumps right.
 
Oh no, I don't mean to behave like Dave ( 8) )... just thought it's best to say I edited Tim's email, in case my post is brought to his attention.
 
Mintmaster said:
Humus, you should use a horizon map lookup value (using the eye position) to determine the displacement. The visibility information will help you determine the real location of the occluding texel. This should get rid of most of the artifacts, or at least the major ones.

Ideally, though, you should create a new horizon map that tells you how much to displace, and if you want, you can use this to test for shadows. I'd love to see the results.

EDIT: I think I just described view dependent displacement mapping. So much for originality :)

For this to work though I would need to have 4D horizon maps though. The displacement is not just a function of texcoord and angle, but also height above surface.
 
Well, I wrote the self shadow demo in DX before GLSL became official, and now I just updated the demo. I still prefer GL over DX.
 
Humus said:
Mintmaster said:
Humus, you should use a horizon map lookup value (using the eye position) to determine the displacement. The visibility information will help you determine the real location of the occluding texel. This should get rid of most of the artifacts, or at least the major ones.

Ideally, though, you should create a new horizon map that tells you how much to displace, and if you want, you can use this to test for shadows. I'd love to see the results.

EDIT: I think I just described view dependent displacement mapping. So much for originality :)

For this to work though I would need to have 4D horizon maps though. The displacement is not just a function of texcoord and angle, but also height above surface.

You're right, which is why my first suggestion said "help". You could assume a height based on the angle, just to help you get a better guess than just using the current pixel's height.

However, my second paragraph offered the solution (and I think this is what the View Dependent Displacement Mapping paper suggests, but I didn't look closely). While you could have a second 3D map, using one for the displacement and the other for the horizon map, the proper solution uses only the former. I'll send you an email describing how you can use this displacement function to determine shadowing.

I have to say, though, that your demo looks extremely good. What I'm describing is only useful for fixing sharp bumps, which your demo doesn't have anyway. Do you use a 3D texture for the horizon map, or do you use a couple of textures like the old DX8 way?

BTW, no-one commented on that 8500 demo I mentioned. Is it the same thing? It looks like it to me. If this technique is getting so much praise right now in the DX9 9700 era, imagine what people would have said back then. Heck, you could even use DX7 EMBM to implement this technique (although it would be slightly incorrect due to a fixed offset direction), but I'm not sure if the original Radeon could do DP3 lighting after the EMBM lookup. I still think EMBM is the most underrated, underused feature ever introduced in a GPU :( .
 
Those comparison images really show the difference. Great work.

Reckon this is going to become a standard feature even faster than I thought it would!
 
Back
Top