PDA

View Full Version : Is this displacement mapping?



rapso
04-30-2002, 03:39 AM
http://www.nvidia.com/docs/IO/2358/ATT/tidepool.mpg

I didn't find any extensions to use this. http://www.opengl.org/discussion_boards/ubb/frown.gif did anybody ???

rapso->greets();

Nutty
04-30-2002, 03:59 AM
If it's the one they showcased for the GF4, it's Z correct bumpmapping. Theres some new pixel shader instructions that allow you to do this.

Nutty

rapso
04-30-2002, 04:40 AM
thx nutty..

and this just works on the gf4? right? http://www.opengl.org/discussion_boards/ubb/smile.gif

rapso->greets();

Robbo
04-30-2002, 05:03 AM
Looks like displacement mapping to me - although I have no idea how they are doing this (usually with displacement mapping the texels themselves supply the values by which the geometry fragments are altered).

Whatever it is, I am continually amazed at how quickly this field is advancing (graphics quality wise).

Devulon
04-30-2002, 05:20 AM
Originally posted by Nutty:
If it's the one they showcased for the GF4, it's Z correct bumpmapping. Theres some new pixel shader instructions that allow you to do this.

Nutty

Z Correct Bump Mapping ?

It looks like the waves are probably some form of a displacement map but I agree with Nutty that there is definately some form of bump mappping going on as well.

What the hell is Z Correct bump mapping. I am well aware of the way bump mapping works and how "FAKE" it really is. I haven't made the association with the Z value as it applies to bump maping, other than the fact that the bumps don't have any real Z values. Obviously bump mapping is a pixel trick and has now effect on geometry, only on the appearance of geometry. So I ask again what is Z correct bump mapping ?

Gonna take a look at google and good old developer.nvidia.com

Devulon

Robbo
04-30-2002, 05:56 AM
Well it all depends on your view really. Take a flat quad-grid (or something) and modulate the vertices by values from a texture map (alpha or intensity), then render it. You have displacement mapping. Apply bump mapping to it as well and you have a displaced mesh with bump mapping on. The resolution of the final mesh is of course dependant on the number of vertices it contains. If this is all being done in hardware of course, then you potentially have other problems with hit testing, because you can no longer rely on knowing the exact positions of all your geometry primitives.

Hmmmmm!! This has got me thinking somewhat.

davepermen
04-30-2002, 06:45 AM
Originally posted by Devulon:
Z Correct Bump Mapping ?

It looks like the waves are probably some form of a displacement map but I agree with Nutty that there is definately some form of bump mappping going on as well.

What the hell is Z Correct bump mapping. I am well aware of the way bump mapping works and how "FAKE" it really is. I haven't made the association with the Z value as it applies to bump maping, other than the fact that the bumps don't have any real Z values. Obviously bump mapping is a pixel trick and has now effect on geometry, only on the appearance of geometry. So I ask again what is Z correct bump mapping ?

Gonna take a look at google and good old developer.nvidia.com

Devulon

well, its a name nvidia announced for geforce4, that she can do this..
well, first: the gf4 can not do anything new the radeon8500 can't do.. second it can't do much more than a gf3 (and nothing new, only improvements)
so technically, there is NOTHING in wich does z-correct bumpmapping..
the only way is like creating fur for example: layering.. and i think thats the way they do it (called elevationmap), but could be some other way as well.. and combined with pixelshaders for bumpmapping and z-manipulation, you can get quite accurate sliced elevationmaps, and i think thats all they do.. slicing with the bumpmap, and possibly some z-adjustments with the textureshaders..

its just a name.. nvidia loves names http://www.opengl.org/discussion_boards/ubb/wink.gif
well, at least i think so.. i asked nvidia several times here in the forum what it is / how it is done, and got no real answer
as well there is no z-correct-bumpmapping-demo out yet.. looks like some name for a "new" feature simply implemented due very much fillrate, cause the gf4 does not have any other improvements over the gf3..

prove me to be wrong http://www.opengl.org/discussion_boards/ubb/wink.gif

deshfrudu
04-30-2002, 09:34 AM
Nvidia's "z-correct bump" or whatever they call it, is just that. It's not displacement mapping. It's just altering the z value before it gets written to the depth buffer, depending on the bump.

dorbie
04-30-2002, 12:57 PM
Daveperman, you are wrong, this IS z correct bump mapping, you're taking what we know about GF4 architecture and mistakenly objecting to a an innovative and honest use of their hardware. Sure it uses existing 3D hardware but it's a new technique where z displace matches the normal map, it is not just a name but a new application of shading hardware and multitexture. There's a higher level concept and application of multitexture being demonstrated, there's also a z correct adjustment for viewing angle (V.N) which might be new.

It's already been said by others that it only displaces the Z value, what this means in terms of appearance is that it only looks different where the polygon intersects some other geometry, in this case the rocks intersecting the water surface. A true displacememt map would result in the position of the fragments changing in screen x y with the bump map, which may require additional polygons & subdivision depending on the implementation details. With z correct bump mapping the polygon will still look flat when viewed at an angle, with displacement mapping the surface would look correct.


[This message has been edited by dorbie (edited 04-30-2002).]

davepermen
04-30-2002, 01:32 PM
explain me the math with makes the z correct.. you would have to raycast over the bumpmap, wich is DEFINITELY not possible.. just by changing the z-value with textureshaders you will not get the correct z-value for the intersection..
explain me how

no one does, as long as no one shows me how and i don't see a way myself i dont believe in it..

nvidia profed enough to have fancy names..
true reflective bumpmapping
there are no true reflections, they never will without raytracing or perpixel-rastericing the geometry..

for me it looks like the same demo i've seen on dx8 showing some fluid in a box.. old thingy.. no one can PROVE its not..

high tesselated mesh
slicing
somefunkymathnoonecanexplain

i thought it would be the last, but specs tell me not to think so (no new features in, really! the z-value setting was in on gf3 as well, there is just a new one only using one texture-stage instead of 2 (without the division))

davepermen
04-30-2002, 01:46 PM
and please re-read my name..
its
DAVEPERMEN
with ONE A and THREE E

dorbie
04-30-2002, 03:15 PM
Dave, NVIDIA have drawn a clear disticntion between displacement mapping and z correct mapping. They have never said this was displacement mapping. Mathematically in it's simplest form you take eye Z and subtract bump height * V.N to give correct Z. This is not saying that a true displacement is done, nothing shifts in XY, but the fragment depth for the surface is corrected in Z to account for the bump height. The results are great for intersecting surfaces as the demo shows.

The technique used is very similar to the zbuffer texture displace used for single quads rendering spheres demo'd on earlier hardware, but I think the compensation for depth derivative is new (as I said earlier the V.N). In anycase the higher level method and application is certainly new. It's a genuinely interesting feature not just some marketing word.

As for your name, it was a typo, relax.

simongreen
04-30-2002, 06:55 PM
The depth replace feature demonstrated in the TidePool demo is exposed as the "DOT_PRODUCT_DEPTH_REPLACE" operation of the NV_texture_shader extension. It basically lets you replace the window-space depth of a fragment with a value derived from a texture map and a dot product calculation. This is supported on GeForce3 and 4. In addition, GeForce4 also supports "DOT_PRODUCT_AFFINE_DEPTH_REPLACE", which doesn't divide by W and requires one less texture stage.
http://www.nvidia.com/dev_content/nvopenglspecs/GL_NV_texture_shader.txt

Calling it "Z correct bump mapping" is perhaps a bit misleading since the Z values are only stricly correct if you're looking straight down at the plane, but it's a useful and real feature none the less.

-S.

zed
04-30-2002, 08:26 PM
on the subject of displacement mapping,
what are ppl using when 2 displaced textures join?
the only way around this problem is what im doing and using quasi 3dtextures, is there another way?
for the life of me i cant see it.

GeLeTo
04-30-2002, 11:26 PM
Originally posted by zed:
on the subject of displacement mapping,
what are ppl using when 2 displaced textures join?
the only way around this problem is what im doing and using quasi 3dtextures, is there another way?
for the life of me i cant see it.

Use the vertex alpha to blend the two textures. At the edges where the two textures meet the alpha should be 0.5

davepermen
05-01-2002, 02:05 AM
Originally posted by dorbie:
Dave, NVIDIA have drawn a clear disticntion between displacement mapping and z correct mapping. They have never said this was displacement mapping. Mathematically in it's simplest form you take eye Z and subtract bump height * V.N to give correct Z. This is not saying that a true displacement is done, nothing shifts in XY, but the fragment depth for the surface is corrected in Z to account for the bump height. The results are great for intersecting surfaces as the demo shows.

The technique used is very similar to the zbuffer texture displace used for single quads rendering spheres demo'd on earlier hardware, but I think the compensation for depth derivative is new (as I said earlier the V.N). In anycase the higher level method and application is certainly new. It's a genuinely interesting feature not just some marketing word.

As for your name, it was a typo, relax.

i see this typo more than my real name.. thats sort of stupid, isn't it? http://www.opengl.org/discussion_boards/ubb/wink.gif

well.. its in no way new (as stated above, every gf3 can do this as well, you just loose there one texture-stage)
and its in _NO_ way z-correct bumpmapping (except possibly from top-down, okay..)
so its just some hack to show what you can do with the depthreplace except the z-correct billboards (wich are really z-correct)

thats what i wanted to say..
AND that there is no way to do displacementmapping without slicing, or tesselating, or raycasting over the triangle (while this will result in errors anyways.. i'll go for slicing)

dorbie
05-01-2002, 11:57 AM
Nobody has said this is displacement mapping, but I was wrong about the V.N modulation of the bump being done, sorry.

This would give true z correct bump mapping and looks to me like it's possible today using another stage, two at most, it shouldn't take additional textures since you can feed those vectors in as color components.

I still think using existing hardware capabilities in a new way creates something new, in this case correlating a z offset with a bump map.

davepermen
05-01-2002, 12:03 PM
Originally posted by dorbie:
I still think using existing hardware capabilities in a new way creates something new, in this case correlating a z offset with a bump map.

but this does not make it a gf4-feature http://www.opengl.org/discussion_boards/ubb/wink.gif

and the z-offset is by no way true for me.. http://www.opengl.org/discussion_boards/ubb/smile.gif (need some big .ppt and .pdf with a lot of pictures profing me wrong http://www.opengl.org/discussion_boards/ubb/smile.gif)

dorbie
05-01-2002, 12:49 PM
Well I'm convinced the V.N modulation would make it correct, and at least one of those vectors is already being sent. I could accurately say that bump mapping is in no way correct but it's a useful improvement over Phong shading.

davepermen
05-01-2002, 12:58 PM
well bumpmapping is part of the phongshading/lighting and it is quite correct (bether use bumpmapping for brdfs or such stuff as phong lighting is piece of crap http://www.opengl.org/discussion_boards/ubb/smile.gif)

bumpmapping is perfect for lighting bumped surfaces, not for displacing them..

and this z-correct feature is stupid as the bump is not at the correct place, so saying the z is correct does not help at all.. (and i don't think even now the z _IS_ correct http://www.opengl.org/discussion_boards/ubb/wink.gif)

well.. for doing z-correct bumpmapping, you need the correct pixels at the correct place, means you need to do displacement mapping..

this can be done nice with slicing (for more-or-less topdown view) and i think this combined with the z-correct fake and some horicontal slices this can be done with a very low amount of slices and correctly to view from the side..
but well..
its all just hacking around..

i'll go for slice expanding along the normals and alphatest..

correct z-values
correct bumpmaps
correct displacement

what else do you want?

well.. more fillrate http://www.opengl.org/discussion_boards/ubb/wink.gif

dorbie
05-01-2002, 02:43 PM
It was Blinn who invented bump mapping, it is not part of Phong shading.

Blinn, James F. Simulation of Wrinkled Surfaces. Computer Graphics (SIGGRAPH 78 Proceedings) 12(3) August 1978, p. 286-292.

Bui-Tuong, Phong. Illumination for Computer Generated Pictures. Communications of the ACM 18(6) June 1975, p. 311-317.

There's no question that displacement mapping is better visually. My point is that there are degrees of accuracy and all efforts so far are an approximation. Taking your reasoning to it's logical conclusion, what's the point of calculating the correct fragment color using a bump map if the fragment is in the wrong place (which it is). The point is it looks better and is more correct, not totally and absolutely correct.

Z correct bump mapping is clearly more correct than just bump mapping in situations where surfaces interpenetrate. This is the problem it attempts to solve and it succeeds in that with more accurate visual results than when you don't use the technique.

BTW there is another way of doing displacement mapping at the fragment level without the methods you mention, but it needs hardware.


[This message has been edited by dorbie (edited 05-01-2002).]

zed
05-01-2002, 05:32 PM
Originally posted by GeLeTo:
Use the vertex alpha to blend the two textures. At the edges where the two textures meet the alpha should be 0.5

i cant see how thats gonna help, (perhaps i didnt explain it well)
both polygons are in different 'spaces' eg a cube has 6 spaces (sides) this displacing vertices on one side will mean they wont match up with the displaced vertices on the adjacent side (not explained well but if youve ever done it u will know what im talking about)
the only way i see around this problem is to use '3d' textures

davepermen
05-01-2002, 10:36 PM
smooth the normals and displace along the normals..

zed
05-02-2002, 12:02 AM
yeah i used to do that for collision detection when i used to treat moving objects as points the good old days when quake style collision detection was good enuf http://www.opengl.org/discussion_boards/ubb/smile.gif (ie expand all the geometry + bevel the normals)
i wonder how it'll go for this displacement mapping (well only one way to find out)

zed
05-02-2002, 01:22 PM
got it late last night http://www.opengl.org/discussion_boards/ubb/smile.gif http://uk.geocities.com/sloppyturds/displace.png (flat shaing)

the issues of mipmapping levels still havent been 100% resolved yet though but itll come.
now ive just gotta find some uses for it http://www.opengl.org/discussion_boards/ubb/smile.gif

davepermen
05-03-2002, 05:30 AM
cool looking. chance to get some mail or link to test that demo? would _LOVE_ to see this..

zed
05-03-2002, 01:04 PM
Davepermen just in case youre like me and never check the online email acciunt often, heres a note to say ive emailed u at hotmail

davepermen
05-03-2002, 02:02 PM
hm.. i see the mails coming in realtime.. thats fast enough isn't it?

thank you very much for thte demo.. one tex you forgot (the one with the guy on..) but anyways, the resting 3 sides of the cube look coool (the one with the brick)

slow but awesome cool http://www.opengl.org/discussion_boards/ubb/smile.gif

hope to see more of this http://www.opengl.org/discussion_boards/ubb/wink.gif (thinkin at the stanford bunny with brick instead of fur http://www.opengl.org/discussion_boards/ubb/wink.gif)

zed
05-03-2002, 05:12 PM
>>thank you very much for thte demo.. one tex you forgot (the one with the guy on..)<<

always a neat party trick

>>slow but awesome cool<<

theres heaps of ways to speed it up (eg not using glBegin()..glEnd() for a start, also LOD + precalculations)

>>hope to see more of this (thinkin at the stanford bunny with brick instead of fur )<<

personally i find displacementmapping to be not that large a jump from bumpmapping (ie compared to nobumpmaps->bumpmaps)
then again itll be awesome to now realise a billion polygon scene, displacement maps up close fading to bumpmaps at a distance (of course with an angle bumpmaps wont cut it, perhaps just displace one side of the polygon? nah to difficult http://www.opengl.org/discussion_boards/ubb/wink.gif)

ild be interested what ppl have ideas of what they could do with displacement maps?