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).]
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
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 (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)
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
hope to see more of this (thinkin at the stanford bunny with brick instead of fur )
>>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 )
ild be interested what ppl have ideas of what they could do with displacement maps?
(ie expand all the geometry + bevel the normals)
(thinkin at the stanford bunny with brick instead of fur 