Parallax Occlusion Mapping

Caphalor · Post by **Caphalor** » Mon Jun 30, 2008 3:27 pm

I implemented Parallax Occlusion Mapping in Ogre.
Shader Features:
- Supports up to 3 Lights
- Parallax Occlusion Mapping (:D)

A screenshot taken from my editor:

.hlsl, .program and .material files (for Ogre 1.6):
See page 3

Samuelgames · Post by **Samuelgames** » Mon Jun 30, 2008 3:30 pm

Wow, awesome work you did there, this is the most 'volumetric' texture shader i've seen

Nauk · Post by **Nauk** » Mon Jun 30, 2008 3:58 pm

Wow this looks damn nice, totally have to agree with Samuelgames

Caphalor · Post by **Caphalor** » Mon Jun 30, 2008 9:30 pm

It's basically just an implementation of the POM shader you can find in the DirectX SDK with some minor changes, but I'm glad that you like it.

The really great thing here is Ogre with its flexible and powerful material system.

todderod · Post by **todderod** » Mon Jun 30, 2008 10:24 pm

Copy from DX SDK or not, it looks darn good!

Post by **sinbad** » Tue Jul 01, 2008 6:34 pm

Nice! I'll use that in the samples if you don't mind? Provided I can get around to writing a GLSL version of course.

Caphalor · Post by **Caphalor** » Tue Jul 01, 2008 7:29 pm

I'll use that in the samples if you don't mind?

It would be a honour.

Maybe the shader needs some additional testing and tweaking, feel free to do what you want with it. And you should consider using another parallax map, rockwall_NH.tga is really a bit small (I used a 256x256 parallax map).

nullsquared · Post by **nullsquared** » Tue Jul 01, 2008 7:37 pm

Very, very nice! This is excellent! I've been wanted to implement POM for a while now, but never found a decent source to observe (that also magically worked with Ogre)

Mind if I post a quick screenshot while playing around with it?

Code: Select all

float nMinSamples = 100;
float nMaxSamples = 200;

Depth scale of 1 needs ... quite a lot of samples

Anyways, note the FPS. On my 8800GTS, it runs a lot faster like this:
- ditch all of the LOD calculations, do complete POM regardless of distance/etc.
- ditch the derivatives, ray trace using the first mip level of the height texture:

Code: Select all

fCurrHeight = tex2Dlod( normalHeightMap, float4(vTexCurrentOffset, 0, 0)).a;

Chances are that the POM was being computed for some fragments regardless of the LOD'ing; and the derivatives usually only make things slower.

In my honest opinion, not only does this run faster, but it also looks a lot better when at a distance. Of course, using the first mip map of the height map has its own problems, but it looks good enough and runs fast enough for most scenes, so it's up to you.

(I can post the source if you want, but all I did was the above tex2Dlod change and I commented out the derivatives calculation and all of the if's for the LOD)

EDIT:
Here's with min 10 and max 50 samples, with LOTS of processing (filling up a lot of the screen):

EDIT2: Sorry, I just can't stop playing with it, this is BEAUTIFUL, man!

Caphalor · Post by **Caphalor** » Tue Jul 01, 2008 7:49 pm

I did not test the performance very much (my Editor has a fixed framerate at the moment), but thank you for the advice, I will try it soon.

Edit: You are right, the performance gain without LOD is really impressive! I updated the .rar file.
Edit2: Your screenshots are always welcome.

Post by **tuan kuranes** » Tue Jul 01, 2008 8:00 pm

Nice results !

'Parallax Occlusion Mapping' is nice and can be used/extended to brillant ideas too.

Check the implementation used in the paper labeled 'Instant Animated Grass'

http://www.cg.tuwien.ac.at/research/pub ... _2007_IAG/

They did use Ogre and hlsl, and did released the shader and texture, only missing the .material file.

captnoord · Post by **captnoord** » Tue Jul 01, 2008 9:15 pm

yup... I was waiting to get some time off so I could check that out... for our game....... atm we use PG for grass but it has some terrible disadvantages related to the grass......

xadhoom · Post by **xadhoom** » Thu Jul 03, 2008 10:49 am

Hi!

Very nice shader! IMHO these lines are a copy paste error in ParallaxOcclusionMapping.hlsl:

Code: Select all

   float Dist1 = length(lightPosition1 - position);
   float Dist2 = length(lightPosition1 - position);
   float Dist3 = length(lightPosition1 - position);

[Edit]
You can avoid one normalize() in the VS if you calculate the tangent space matrix like this:

Code: Select all

   float3 nNormal = normalize(normal); 
   float3 nTangent = normalize(tangent);
   float3 binormal = cross(nTangent, nNormal);

The length of a cross is 1 if both vectors have the length 1.

nullsquared · Post by **nullsquared** » Thu Jul 03, 2008 1:43 pm

Very nice, once again! And a very good example for Ogre, nice and clean without going on tangents (no pun intended).

Caphalor · Post by **Caphalor** » Thu Jul 03, 2008 4:56 pm

@xadhoom: Thank you for the fix! (it was really a copy and paste error)
I will update the shader once again.

Post by **sinbad** » Thu Jul 03, 2008 6:53 pm

Cool, I hadn't seen that grass paper, great to see that it was done using OGRE.

xadhoom · Post by **xadhoom** » Fri Jul 04, 2008 9:54 am

IÂ´m not sure if this is a shader bug, but if I put the shader on a capsule (or another cylindrical mesh) and
place one light at one side of it I see an inverse normalMap lighting on the left side of the capsule where the material becomes darker.

Can anybody confirm this?

[Edit]
Using Ogre 1.4.9

Caphalor · Post by **Caphalor** » Fri Jul 04, 2008 11:29 am

I had problems with some meshes, too, but I blamed it on wrong or not existing tangent vectors, maybe you should check this. The fact that it worked with the knot mesh made me optimistic.

Of course it is also possible that there's really a bug, I'm all in all a shader beginner.

Post by **Kojack** » Fri Jul 04, 2008 1:11 pm

The length of a cross is 1 if both vectors have the length 1.

No it isn't.
The length of a cross product is affected by the angle between the 2 vectors. The result is only length 1 if the 2 vectors are unit length and at 90 degrees to each other.

If the normal and tangent are always going to be at right angles, then it's fine. But that's a specific case.

iloseall · Post by **iloseall** » Fri Jul 04, 2008 2:04 pm

Cool~~~~~~

http://www.cg.tuwien.ac.at/research/pub ... _2007_IAG/

and Instant Animated Grass Cool too!

'Parallax Occlusion Mapping' is nice and can be used/extended to brillant ideas too.

Has another extented about POM?

Post by **Kencho** » Fri Jul 04, 2008 2:30 pm

Kojack wrote:
The length of a cross is 1 if both vectors have the length 1.
No it isn't.
The length of a cross product is affected by the angle between the 2 vectors. The result is only length 1 if the 2 vectors are unit length and at 90 degrees to each other.

If the normal and tangent are always going to be at right angles, then it's fine. But that's a specific case.

I think he wanted to say it's in the range [-1, 1]. When both vectors are normalised, their dot product returns the cosine of the angle they form as is, because it's multiplied by the length of both vectors (which in this particular case is exactly 1 for both)

Oogst · Post by **Oogst** » Sat Jul 05, 2008 8:25 pm

Looking good!

If you are having fun with this, then you could try to improve the performance with relaxed cone step mapping. Also, you could try to improve the visual quality by adding shadow to it as well.

Caphalor · Post by **Caphalor** » Sat Jul 05, 2008 9:38 pm

Thank you for the advice!
As far as I understand, the cone mapping algorithm would replace my while loop, and all in all it would be cone mapping with a dynamic step count, right? I think I will try to implement it, but don't expect a working shader soon, I also have to continue the programming of my editor.

And finally concerning the shadows, do you mean self-shadowing or shadows in general?

Oogst · Post by **Oogst** » Sat Jul 05, 2008 10:45 pm

I meant self shadowing, because you can do that really easy once you have the ray marching working.

As for the relaxed cone step mapping: it is a pretty difficult one to implement, because it also requires a tool to generate the cone step map in the first place. Requires a lot of time to make, I would expect. That's why I first asked whether you are having fun with this.

Relaxed cone step mapping is an awesome algorithm, though!

nullsquared · Post by **nullsquared** » Sun Jul 06, 2008 1:07 am

Oogst wrote:I meant self shadowing, because you can do that really easy once you have the ray marching working.

As for the relaxed cone step mapping: it is a pretty difficult one to implement, because it also requires a tool to generate the cone step map in the first place. Requires a lot of time to make, I would expect. That's why I first asked whether you are having fun with this. Relaxed cone step mapping is an awesome algorithm, though!

Wait, is there a difference between what you're describing and what one of those gamedev.net geniuses posted? Because the demo he provides runs with perfect quality (no aliasing or errors on the edges whatsoever) at least 10 times faster than POM or relief mapping with 200 steps (even at which you can still notice errors).

PolyVox · Post by **PolyVox** » Sun Jul 06, 2008 8:47 am

nullsquared wrote:Wait, is there a difference between what you're describing and what one of those gamedev.net geniuses posted? Because the demo he provides runs with perfect quality (no aliasing or errors on the edges whatsoever) at least 10 times faster than POM or relief mapping with 200 steps (even at which you can still notice errors).

I don't know, can you provide a link to the GameDev.net post? Cone Step Mapping and Relaxed Cone Mapping are described in GPU Gems 2 & 3 respectively, and the image in there are very good quality.