Cone Step Mapping and Parallax Occlusion Maping

segafan · 01-30-2009 10:56 PM

Hi,
At this moment i use C# resp. XNA but i also want to learn C++ and your engine looks very promising and ideal for learn. Only thing that i miss is possibility to use own shaders. Will that possible in near future? If not, i would like to ask you if it was possible to add these two shaders - Cone Step Mapping and Parallax Occlusion Mapping (Detailed Surface Viewer on <a class="postlink" href="http://www.brunoevangelista.com">www.brunoevangelista.com</a> shows both techniques). I use both of them and i am delighted.

**Esenthel** · 01-30-2009 11:23 PM

Hi,

have you checked the tutorial "rendering\bump mapping" ?

take a look here <a class="postlink" href="http://www.esenthel.com/en/engine/screens.html">http://www.esenthel.com/en/engine/screens.html</a>

on this screen [Image: 03.jpg]

it is already implemented

segafan · 01-31-2009 01:00 AM

Yes, i did. But "Parallax Mapping" and "Parallax Occlusion Mapping" are two absolutely diffrent techniques. Same it is with "Relief Mapping" and "Cone Step Mapping". I don't want to tease you for that, it's only i'm used to work with them and these two techniques are IMHO the best. It was only suggestion...

**Esenthel** · 01-31-2009 02:01 PM

Hello,

I've checked the tool you've provided link for.

Parallax Occlusion Mapping in the tool isn't any better than relief mapping (in fact it has worse quality and is slower)

Cone step mapping is in fact interesting, however it requires textures to have additional "cone ratio" information, which makes the technique impractical
(every bumpy material would require additional texture)

but thanks for the info smile

segafan · 02-16-2009 07:17 PM

Implementation of Parallax Occlusion Maping in that program i mentioned looks quite strange. I use it quite a long time and it's results are great - less artefacts with almost twice speed than Relief Mapping (simple scene vith 6 walls ~1500FPS vs 900FPS). Try look on this paper where are described adventages of this technique: <a class="postlink" href="http://ati.amd.com/developer/gdc/2006/GDC06-Tatarchuk-Parallax_Occlusion_Mapping.pdf">http://ati.amd.com/developer/gdc/2006/G ... apping.pdf</a>

Anyway, i would like to ask you, if is there any chance there will be possibility of using of own shaders in Esenthel?

**Esenthel** · 02-16-2009 07:41 PM

Yes, when I'll find the time, I'll add support for custom shaders.
Thanks for the link, I'll check it out.

**Esenthel** · 02-22-2009 08:33 PM

Hi,

I've found some implementation of parallax occlusion mapping, do you mean something like this?

Code:

float2 pt1 = 0;

    float2 pt2 = 0;        

    while ( nStepIndex < nNumSamples ) 

    {

        vTexCurrentOffset -= vTexOffsetPerStep;

        // Sample height map which in this case is stored in the alpha channel of the normal map: (Ati's comment)

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

        fCurrentBound -= fStepSize;

        if ( fCurrHeight > fCurrentBound ) 

        {   

           pt1 = float2( fCurrentBound, fCurrHeight );

           pt2 = float2( fCurrentBound + fStepSize, fPrevHeight );

           nStepIndex = nNumSamples + 1;    //Exit loop

           fPrevHeight = fCurrHeight;

        }

        else

        {

           nStepIndex++;

           fPrevHeight = fCurrHeight;

        }

    } 

    float fDelta2 = pt2.x - pt2.y;

    float fDelta1 = pt1.x - pt1.y;

    float fDenominator = fDelta2 - fDelta1;

    // SM 3.0 requires a check for divide by zero, since that operation will generate

    // an 'Inf' number instead of 0, as previous models (conveniently) did: (Ati's comment)

    if ( fDenominator == 0.0f )

    {

        fParallaxAmount = 0.0f;

    }

    else

    {

        fParallaxAmount = (pt1.x * fDelta2 - pt2.x * fDelta1 ) / fDenominator;

    }

    float2 vParallaxOffset = vParallaxOffsetTS * (1 - fParallaxAmount );

    newTexCoord = uv - vParallaxOffset;

If yes, then I can thel you that I've already tried that in the past, and I can say that my own implementation of relief mapping is much faster.

segafan · 02-23-2009 01:09 PM

Till now i worked in C# resp. XNA and i used this implementation: <a class="postlink" href="http://www.codeplex.com/XNACommunity/Wiki/View.aspx?title=Parallax%20Occlusion%20Mapping">http://www.codeplex.com/XNACommunity/Wi ... %20Mapping</a> . I'm not sure which one from C++ implementations is good or not. I suppose that in DXSDK (<a class="postlink" href="http://msdn.microsoft.com/en-us/library/bb147254(VS.85">http://msdn.microsoft.com/en-us/library/bb147254(VS.85</a>).aspx) should be that best(?).
Feature that i like on POM is self-shadowing which i haven't seen on your Relief Mapping.
I didn't make comparsion of these two techniques in c++, only in XNA.

edit: POM has one more adventage - is also possible use it on SM2.0 hardware

**Esenthel** · 02-23-2009 01:30 PM

this implementation <a class="postlink" href="http://www.codeplex.com/XNACommunity/Wiki/View.aspx?title=Parallax%20Occlusion%20Mapping">http://www.codeplex.com/XNACommunity/Wi ... %20Mapping</a> as well as DirectX sample all use the code which I posted above.

I've tested it in the past when developing my relief mapping, and it was slower than my current implementation.

Yes my implementation doesn't support self shadowing in the texture coming from the texture bumps itself, because I'm using deferred shading, which handles the lighting in a totally separate pass.

segafan · 02-23-2009 04:01 PM

Does it mean there is impossible to use self-shadowing on any bumpmapping method with deferred shading?

**Esenthel** · 02-23-2009 05:13 PM

Yes,

but don't misunderstand self-shadowing coming from the texture (bump map which is disabled), and self-shadowing from the model geometry (which is enabled)

Cone Step Mapping and Parallax Occlusion Maping
Author	Message