Jump to content

  • Log In with Google      Sign In   
  • Create Account

Parallax Occlusion Mapping Question


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 mikeshafer   Members   -  Reputation: 308

Like
0Likes
Like

Posted 01 June 2013 - 12:00 AM

Hi there,
 
So I'm trying to implement the ATI method of Parallax Occlusion Mapping.  It all makes sense except for one slick part which I cannot understand.  I've drawn a diagram to help myself understand what the variables are.  Here it is:
 
parallax.png
 
The ray coming in diagnally is the view ray.  So we basically do a linear search to find the point at which the boundary supertends the height.  The D3D10 sample has a variable called fParallaxAmount.  I've done some simplifying and canceling out and it turns out:

 

fParallaxAmount = (currBound * deltaHeight + currHeight * stepSize) / (stepSize + deltaHeight)

 

This is all dandy, but I can't just copy and paste it without understanding the theory behind it.  I am tempted to solve a parametric system of equations that assumes the slope of the height map stays the same, but the code above seems to be either similar triangles or Green's Theorem.  I can't figure out what it is.  Does anyone have any insight into what it does?  Note that (as far as I can tell) all values are along the vertical axis.  Let me know if you have any input.

 

Thanks,

Mike



Sponsor:

#2 Jason Z   Crossbones+   -  Reputation: 5062

Like
0Likes
Like

Posted 01 June 2013 - 07:34 AM

I remember solving a similar equation back when I was working on POM (check it out here for some background info).  Unfortunately the details escape me, but I seem to recall that the solution was possible with similar triangles.  The key to the diagram (and the derivation) was that I had to draw the two vertical segments (separated by the horizontal size of the step), then create triangles from the top of one segment to the bottom of the other segment.  That will create the intersection point in the middle, which is what you want to find.  It was slightly tricky to figure out (for me at least) but after I solved it I remember thinking that it should have been easier to solve...  I guess most math problems are like that :)

 

Also, I think your currHeight and prevHeight are swapped in the diagram - shouldn't the previous height be higher than the current one?



#3 mikeshafer   Members   -  Reputation: 308

Like
0Likes
Like

Posted 01 June 2013 - 02:32 PM

Yeah, I'm trying to make sense of it, but I think it's a rough estimate of where the intersection point should be.  The equation gives you a point between currBound and currHeight. I'm going to try it on my own using this shortcut and also by intersecting the ray with a psuedo-slope from the heightmap and see which gives better results.  Obviously, the D3D10 sample works and looks great so I'm hoping I end up with a result similar to it.

 

But yeah, currBound starts at 1.0 and moves toward 0.0.  At the same time, the height sampling moves to the right.  So it looks like if you're moving to the right, prevHeight will be lower than currHeight on a counter-relief extruded surface.  Am I wrong?  Maybe I'm looking at it wrong?

 

Mike



#4 Jason Z   Crossbones+   -  Reputation: 5062

Like
0Likes
Like

Posted 02 June 2013 - 12:44 PM

But yeah, currBound starts at 1.0 and moves toward 0.0. At the same time, the height sampling moves to the right. So it looks like if you're moving to the right, prevHeight will be lower than currHeight on a counter-relief extruded surface. Am I wrong? Maybe I'm looking at it wrong?

If the view ray direction is moving in the direction of the arrow, then each step should take you 'deeper' into the texture, where the height value is decreasing as you progress along the ray.  So in that case, I would expect currHeight to be smaller than prevHeight - which would make it appear lower in your diagram...  That is how I interpret it anyways - if it makes more sense to you to have it another way, then by all means use the way that works!



#5 mikeshafer   Members   -  Reputation: 308

Like
0Likes
Like

Posted 02 June 2013 - 09:07 PM

Haha, I hear you.  Right now I'm trying to write a custom Maya export for "boxy models" where the corner normals are not shared.  Wish me luck!






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS