Advertisement Jump to content
Sign in to follow this  

How to make Parallax Occlusion Mapping usable in practice?

This topic is 4502 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi people! Much is said about Parallax Occlusion Mapping and similar techniques (such as Per-Pixel displacement mapping with distance functions or Relief Mapping). But almost all demos we see present a flat surface with a relief texture. I was considering a possibility of using POM or a similar technique on objects more complicated than a surface, and I've faced a few problems that inhere in all of the techniques. The major problem is handling the ray outside of the prism. As you know, the surface represented by the heightmap is enclosed within a triangular prism with the actual face being its cap. The tracing of the eye-ray starts from a point on the face (e.g. on the cap of the prism) and continues through the volume bounded by the prism. If the ray intersects the surface represented by the heightmap, the algrithm terminates. If the ray intersects the bottom of the prism, it also terminates, because no pits are deeper than the zero level of the heightmap, which is the bottom of the prism. But what if the ray leaves the prism through a side of the prism? In most demos I've seen this issue is not handled at all. Usually,the behavoir depends on the texture sampling mode, and in case texture replication is active, we observe the opposite edge of the texture through a side face of the prism (this is true if the whole texture is attatched to the face; otherwise we would see some parts of the texture that are not attatched to the face but located close to its mapping in the texture). For example, in Tatrchuk's demo this terrible problem is broken into two seperate cases. First, she has noted a disturbing stripe along the edge that breaks a quad into two(like everybody else she tested her technique on a quad). The reason why this stripe appeared is that some other portions of the texture were observed through the side of the triangle's prism, other than the portion of texture attatched to the neighboring triangle. The solution to this problem was copying a reasonably wide (approx. 10-20 pixels) stripe of pixels from the portion of the texture attatched to the neighboring triangle in order to make a king of frame at the sides of the portion of the texture attatched to the current triangle. In fact, if the portions of the texture attatched to the triangles sharing a common edge are located in such a way they are adjacent on the texture, no problem occurs at all. I hope you understand me. The second sub-problem was the border of the quad: rays that leave the outer border of the square prism must be termonated in some way, otherwise some odd portions of the texture will be observed "under" the border of the quad. This problem was not handled: other geometry was placed ontop of the quads at thier border regions instead, so that there was no chance to look "under" the border of the quad in the demo. Still, there's a theoretical approach that such rays may be killed with the help of the texkill command, and that would make an illusion of a complex silhouette. But this is only good when a quad is considered. Everything gets worse if you consider any geometry other than a plane. A ray that leaves a face's prism through its side may intersect the surface represented by trhe heightfield below the adjacent face. But it is easy to understand that it remains completely BELOW the adjacent face, and doesn't intersect it. It means that for the purpose of the correct representation the calculations considering the intersection of the ray with the heightfield below the adjacemt face must be done in the pixel shader called for a pixel of the CURRENT face! As I understand the problem, there are two possible solutions. Either the ray must be somehow transformed into tangent space of the adjacent face and the current point on the ray must be moved to the portion of the texture attatched to the adjacent face, OR the mapping of the face on the texture must be surrounded with a frame representing the shape of the mesh around the face by means of a heightfield (relative to the face's plane). In the first case, we have some portions of the original surface omitted, because the extruded faces leave out some space that falls into the Voronoi regions of the edge they share (the same is true for Voronoi regions of the vertices). So even if we develop a robust method of transforming the eye ray from the tangent space of the current frame to the tangent space of the adjacent face, we have no information about the shape of the object on the section of the ray after it leaves the prism of the current face and before it enters the prism of the adjacent face. That means we need to store this information somehow, and it will make the shader completely crazy. The second option, e.g. the frames on the heightfield, is not robust because we don't know their width (in fact we can compute it, but it will be different for each edge, and for me it's not clear, whether to use the maximum one or not), and we'll have to re-arange the whole texture, because we'll need all triangles to be far enough from each other on the texture to compose the frame around each of them. Besides that, this will fix the shape of the object, making it unusable for such modifications as non-uniform scaling, morphing or sceletal animation. There's another problem with the POM. The curvature of a face represented by different normals in its vertices is not incorporated in the technique, since it rcognizes only the heightmap. Even if you combine the normal form the normal map with the interpolated normal in some way for a given pixel, the curvature effect will be hindered by the much more obvious POM displacement effect. The curvature must be incorporated in the heightfield! It's not the issue if we generate heightmaps from the high-poly models (we may simply assume that the low-poly model has flat faces and generate the normal map and the height map accordingly, and that'll be OK), neither it is a problem if we add the heightfield onto the objects that are intended to be flat. But sceletal animation and morphing work through affecting normals, and these changes must be reflected somehow, what seems to me impossible when using POM or a similar technique. I'd like you to tell me, 1) if there are some solutions to the problem of a ray that goes through a side of the face's prism, 2) if there are any successful examples of using POM or something of the kind on non-flat geometry 3) what do people do with the damned rays that go outside the prism 4) and what do people say about POM + sceletal animation (skinning) ? Thank you very much for your patience and for your help

Share this post

Link to post
Share on other sites
I've looked the article through.

It seems to me that I don't understand much of it.

AFAIK, they are doing the following:
1) they are computing a kind of a functional representation of tthe object's surface, based exclusively on it's vertices
2) trace the ray not through a prism, but through a curved slice, with the heightmap assumed relative to the functional surface not the plain face
3)assume that the ray doesn't intersect the emulated surface if it doesn't intersect the functional surface. [EDIT: if it intersects the funcional surface twice without intersecting the heightmap, e.g. leaves it]

I belive it must not work for most cases. If you have a look at Figure 6 in the mentioned paper, you can mentaly change the eye position in a way that the eye-tay would still leave the curved slice through its side face. So no problem is solved, I believe. I'll look throgh the sorce codes if I find them, but I believe I won't find a solution there.

Besides that, these quadric coefficients that are precomputed also fix the shape of the body and make no skinning or morphing possible

[Edited by - fragdemon on September 19, 2006 4:18:07 PM]

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!