simdis triton ocean problem

[devcxx]

I use simdissdk-1.8 and osgearth-simdis-sdk-1.8 version, when I run osgearth_triton example the triton ocean is normal display on the earth, but run simdissdk example Ocean, the triron ocean display abnormally, can't see the ocean surface on the earth: but can see the ocean water wave when I look up from under the water: I don't know why, maybe it's simdissdk bug? Hope for your help thanks. My system is Windows 10 and Nvidia graphics card.

[emminizer]

Hi Sam,

I'm not able to reproduce your problem with the current master. Can you try the current master osgEarth and current master SIMDIS SDK?

Here's what I'm seeing, with Windows 10 and NVidia graphics card:

Note that the Triton integration into the SDK does attempt to auto-detect Triton for those who have SIMDIS installed by searching for the SIMDIS_DIR environment variable. Perhaps the Triton Resources path is different from osgEarth to the SIMDIS SDK because of a SIMDIS install? Take a look at simExamples::getTritonResourcesPath() (here) to see what I mean.

Thanks,

• Dan

[devcxx]

I installed the Triton SDK, it's exist the TRITON_PATH variable in my system, so simExamples::getTritonResourcesPath() can get the correct triton resources path. Is there any other reason for this problem?

[emminizer]

Not that I know of. I can't reproduce the issue here and I have never seen the problem where the bottom draws fine but the top does not.

[devcxx]

Hi Dan, What's your Triton SDK's version? I guss maybe we use a different Triton version so cause this problem. I've tried to build the latest SIMDIS and osgEarth version in master branch, but the run result is same with before, I don't know why.

[devcxx]

I find when i press 'w' key to view in grid mode, there is water wave moving, but in normal mode you can see no nothing

[emminizer]

We are using Triton 3.91. I recently tried upgrading Triton but we encountered some kind of issue that prevented us from doing so...

Are you using Logarithmic Depth Buffer (LDB)? You might see behavior like what you're describing, if LDB is turned on. At one point the osgEarth project was hosting the modified version of the Triton shaders that included LDB support, but I don't see it in the repository currently. To test if it's an LDB problem, in Ocean.cpp you can call something like viewer->setLogarithmicDepthBufferEnabled(false).

The vertex shader modifications we use, in user-vert-functions.glsl:

/**
 * osgEarth logarithmic depth buffer algorithm (vertex)
 * Note: the output varying is only used for the "precise" variant
 */
uniform float oe_logDepth_FC;
#if __VERSION__ > 140
out float oe_logDepth_clipz;
#else
varying float oe_logDepth_clipz;
#endif
uniform mat4 osg_ProjectionMatrix;

vec4 applyOsgEarthLogDepthBuffer(in vec4 clip)
{
    if (oe_logDepth_FC > 0.0 && osg_ProjectionMatrix[3][3] == 0.0) // perspective
    {
        clip.z = (log2(max(1e-6, clip.w+1.0))*oe_logDepth_FC - 1.0) * clip.w;
        oe_logDepth_clipz = 1.0 + clip.w;
    }
    else
    {
        oe_logDepth_clipz = 2.0;
    }
    return clip;
}

// Provides a point to override the final value of gl_Position.
// Useful for implementing logarithmic depth buffers etc.
vec4 overridePosition(in vec4 position)
{
    return applyOsgEarthLogDepthBuffer(position);
}

Our modifications to user-functions.glsl:

uniform float oe_ocean_alpha;

/**
 * Fragment component of osgEarth logarithmic depth buffer precise variation
 * (Not used if not using the fragdepth option)
 */
uniform float oe_logDepth_FC;
#if __VERSION__ > 140
in float oe_logDepth_clipz;
#else
varying float oe_logDepth_clipz;
#endif
uniform mat4 osg_ProjectionMatrix;

void emitOsgEarthLogDepthBufferDepth()
{
    if (oe_logDepth_FC > 0.0 && osg_ProjectionMatrix[3][3] == 0.0) // perspective
    {
        gl_FragDepth = log2(oe_logDepth_clipz) * 0.5*oe_logDepth_FC;
    }
    else
    {
        // must set gl_FragDepth in all branches even if it doesn't change
        gl_FragDepth = gl_FragCoord.z;
    }
}

void writeFragmentData(in vec4 finalColor, in vec4 Cdiffuse, in vec3 lightColor, in vec3 nNorm )
{
    // Modify the final alpha with the value of the oe_ocean_alpha uniform.
    finalColor.a = finalColor.a * oe_ocean_alpha;
#ifdef OPENGL32
    fragColor = finalColor;
#else
    gl_FragColor = finalColor;
#endif
    // Uncomment if you are using LDB::setUseFragDepth(true)
    emitOsgEarthLogDepthBufferDepth();
}

• Dan

[devcxx]

Thanks Dan, I called viewer->setLogarithmicDepthBufferEnabled(false) in the Ocean.cpp, it's work! The code you paste below about user-vert-functions.glsl is necessary?

[emminizer]

LDB helps with depth Z-fighting near the surface, particularly when your eye is far from the surface, but close to another object in space. LDB works by reassigning the pixel depth to a logarithmic depth scaling. https://github.com/gwaldron/osgearth/blob/master/src/osgEarthUtil/LogarithmicDepthBuffer has more details.

We use this in SIMDIS because it's common to be tethered to an entity at aircraft or space altitudes, but still want to see good Z sorting near the earth surface.

Triton does not have native support for LDB. Because Triton does its own drawing outside of OSG framework, and installs its own shaders, it needs modifications to support LDB. That is what the code snippets above are: integration of LDB into Triton user-defined modules.

Thanks for letting me know that was the problem, I will close this issue out.