17 replies to this topic

[Bender77]

Relief mapping : Seen on opengl.org In fact it's "simply" some raytracing into an heightmap using the pixel shader. You can even raytrace self-shadows (and local reflections I guess). It look awesome, but considering the high amount of pixel shader instructions needed ( Compared to parralax mapping in example ) I don't know if it's yet usable in some game engine ( Even on GeForce 6800 ). Maybe the solution is to use this technique near the camera, and to use parralax or standard bump-mapping instead farther. The problem will be to smoothly transition between these LODs (especially between relief mapping and others)

[mikeman]

Hmmm... after a quick read, it looks like a more advanced version of parallax mapping, but it requires many instructions and it's pretty slow even on hi-end cards. The beauty of parallax mapping is that you get a surprisingly good result with just 2-3 instructions.

I will definately check it out later, though.

[Bender77]

You got it ! It's like choosing between 3 added instructions and tenths/hundreds added instructions ( depending on the precision you want, you can have more or less iteration steps for the ray tracing linear and binary search ).

The only common point with parralax mapping tough is that both techniques perturbates in some way the UV coordinate used to sample the diffuse and normal maps ( and gloss etc maps ).

However I consider parralax mapping has being a hack ( while still being a cheap and good hack in some situations ) while relief mapping is more physicaly correct.

[Eelco]

yeah who couldnt see that coming...

still cool it works in realtime tho. it will really add some badass realism to games. all hail to raytracing i suppose.

on the other hand, a card built for rasterizing isnt likely to be better at raytracing than at rasterizing. if youd use that power to crunch some triangles instead of raytracing one quad, youd get the same with much less effort id wager.

[Eelco]

yeah who couldnt see that coming...

still cool it works in realtime tho. it will really add some badass realism to games. all hail to raytracing i suppose.

on the other hand, a card built for rasterizing isnt likely to be better at raytracing than at rasterizing. if youd use that power to crunch some triangles instead of raytracing one quad, youd get the same with much less effort id wager.

[_DarkWIng_]

I've followed the topic on opengl.org from the beginning and I'm very impressed with results it gives. But even with all the improvements posted so far, I doubt we'll see this in games any time soon. The cost, compated to bumpmapping and parallax mapping is just way to high for now, even if used in shader LOD chain. I'll try to implement it in my engine just to see how it performs on 100k tris scene. [grin]

[Dmytry]

cool, of course... i had similar(if not same) idea about implementing terrain from voxel world on GPU, but i have GeForce FX 5200 only... :(

[mattnewport]

It's a neat technique but I think we're likely to see mainstream hardware that can do true displacement mapping with adaptive tesselation before it becomes really practical for real time use. With hardware support that's likely to be a more efficient way to do things. The nice thing about parallax mapping is that it looks significantly better than normal mapping without costing too much more. This looks significantly better again but is significantly more expensive as well.

[superpig]

Quote:

Original post by mattnewport It's a neat technique but I think we're likely to see mainstream hardware that can do true displacement mapping with adaptive tesselation before it becomes really practical for real time use.

Aye. To be honest, I'm having trouble getting really excited about all these texture-space effects because they don't solve the biggest problem - the silhouette.

Once someone shows me a method which does virtual displacement, with silhouette correction, on a single quad, then I'll be excited. [grin]

[sBibi]

superpig> this one does produce correct silhouettes, not like parallax mapping, it's just that these screenshots don't show it.

the bumps don't stick out of the surface, but dig inside it.
if the pixels that connect the quad edges to the rest are rendered transparently, you get proper silhouettes. (your meshes faces need to be pushed along their normals so they enclose the highest possible bump).

[superpig]

Quote:

Original post by sBibi superpig> this one does produce correct silhouettes, not like parallax mapping, it's just that these screenshots don't show it. the bumps don't stick out of the surface, but dig inside it. if the pixels that connect the quad edges to the rest are rendered transparently, you get proper silhouettes. (your meshes faces need to be pushed along their normals so they enclose the highest possible bump).

Ah. Does it work if bumps touch the edges of the quad?

[sBibi]

what do you mean?
the only problem there is with silhouettes (but you can't do anything about this with a flat quad anyway, is that the closest edges of the quad will seem to "cut" the bumps that go inside the quad, and will make the quad appear as more or less a window that lets see what's underneath.

but for polygons connected into a complete mesh that represents a closed volume, you won't get this problem (I'm not 100% sure, I didn't test any of it, but I really don't see why it wouldn't work, there's no reason at all... and you can get the silhouette of the object to look bumpy like it should be if you use alpha test and set the alpha value of all boundary pixels that don't touch the virtually displaced mesh to 0.

however, there might be (and probably are) some artifacts with sharp surfaces, where bumps stick out the opposing surface, and at the edge between two faces that have a high angle relative to each other. hmm, did that sentence sound english? :D. sorry, I'm having trouble saying what I'd like to say :/
anyway... there aren't any flattening of the bumps anywhere on the surface, they stay consistent, and you can get proper silhouettes :)
but a demo showing this would be cool...

[Anonymous Poster_Anonymous Poster_*]

Quote:

Original post by sBibi but for polygons connected into a complete mesh that represents a closed volume, you won't get this problem (I'm not 100% sure, I didn't test any of it, but I really don't see why it wouldn't work, there's no reason at all... and you can get the silhouette of the object to look bumpy like it should be if you use alpha test and set the alpha value of all boundary pixels that don't touch the virtually displaced mesh to 0.

For polygons in a complete mesh, there is no problem if a bump from one triangle comes into the area corresponding to another triangle. The above screenshot with the quad is proof of it as the quad is actually two triangles. The problem is at triangle edges but only those edges which are at the object's silhouette. For the rest of triangles the neighbouring triangles will handle the "spilled" bumps.

I don't think setting alpha to 0 and then using alpha test will solve it because if it works at the silhouette, it will break when both the tris sharing the edge in the silhouette are visible. More info needs to be stored.

[sBibi]

Quote:

For polygons in a complete mesh, there is no problem if a bump from one triangle comes into the area corresponding to another triangle. The above screenshot with the quad is proof of it as the quad is actually two triangles. The problem is at triangle edges but only those edges which are at the object's silhouette. For the rest of triangles the neighbouring triangles will handle the "spilled" bumps.

mh yes, you're right, it should work if the face normals are interpolated for each fragment (and that'd be the case). then it works well for any mesh, except on the mesh screenspace boundaries as you said, but that's without alpha test.

Quote:

I don't think setting alpha to 0 and then using alpha test will solve it because if it works at the silhouette, it will break when both the tris sharing the edge in the silhouette are visible. More info needs to be stored.

I think it would work pretty nicely, if you set to 0, as I said two posts above, only the pixels that don't fall into the virtually displaced mesh, and these pixels exist _only_ on the mesh silhouette, not when the two tris are visible, I mean, you won't have transparent pixels right in the middle of a surface between two connected faces, only on the silhouette.

[Alura]

It's a nice new technique, but I wouldn't say better than parallax mapping, simply due to it's speed-looks relation, which is quite lower than parallax mapping (ok, it's prettier, but also a lot slower).

[sBibi]

superpig> OK, forget what I said about silhouettes, I understood the algorithm the wrong way, and when you think about it, it seems obvious... a pixel shader can't know how the surface it belongs to will evolve, and the shader assumes the surface follows the surface tangent at the pixel location, and this introduces some deformations on the silhouettes (although much much better than parallax mapping), I should have read the shader code... sorry about that :/

[EvilDecl81]

Quote:

Original post by Bender77 Relief mapping : Seen on opengl.org In fact it's "simply" some raytracing into an heightmap using the pixel shader. You can even raytrace self-shadows (and local reflections I guess). It look awesome, but considering the high amount of pixel shader instructions needed ( Compared to parralax mapping in example ) I don't know if it's yet usable in some game engine ( Even on GeForce 6800 ). Maybe the solution is to use this technique near the camera, and to use parralax or standard bump-mapping instead farther. The problem will be to smoothly transition between these LODs (especially between relief mapping and others)

The best paper I've seen on these kinds of techniques is this one (published in GI 2004). The key reasoning in this paper was to break the interesction prisms into 4 tetrahedrins, which makes doing intersections mathmatically cheap. This paper was implemented on a Radeon 9700, IIRC.

http://www.gris.uni-tuebingen.de/publics/paper/Hirche-2004-Hardware.pdf

[EvilDecl81]

Quote:

Original post by EvilDecl81 Quote: Original post by Bender77 Relief mapping : Seen on opengl.org In fact it's "simply" some raytracing into an heightmap using the pixel shader. You can even raytrace self-shadows (and local reflections I guess). It look awesome, but considering the high amount of pixel shader instructions needed ( Compared to parralax mapping in example ) I don't know if it's yet usable in some game engine ( Even on GeForce 6800 ). Maybe the solution is to use this technique near the camera, and to use parralax or standard bump-mapping instead farther. The problem will be to smoothly transition between these LODs (especially between relief mapping and others) The best paper I've seen on these kinds of techniques is this one (published in GI 2004). The key reasoning in this paper was to break the interesction prisms into 4 tetrahedrins, which makes doing intersections mathmatically cheap. This paper was implemented on a Radeon 9700, IIRC. It is quite feasable on next-gen hardware. http://www.gris.uni-tuebingen.de/publics/paper/Hirche-2004-Hardware.pdf