Is this displacement mapping?

http://www.nvidia.com/docs/IO/2358/ATT/tidepool.mpg

I didn’t find any extensions to use this. did anybody ???

rapso->greets();

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

thx nutty…

and this just works on the gf4? right?

rapso->greets();

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).

Originally posted by Nutty:
[b]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[/b]

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 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.

Originally posted by Devulon:
[b] 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[/b]

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
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

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.

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).]

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))

and please re-read my name…
its
DAVEPERMEN
with ONE A and THREE E

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.

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.

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.

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

Originally posted by dorbie:
[b]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.[/b]

i see this typo more than my real name… thats sort of stupid, isn’t it?

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)

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.

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

and the z-offset is by no way true for me… (need some big .ppt and .pdf with a lot of pictures profing me wrong )

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.

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 )

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 )

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