I am pretty new to OSG but have been working on it for the past few weeks. I have an application that is rendering a 2D terrain with a constant width. When I rotate my display the line sometime appears broken.

There are no other layers present. I have attached an example. This terrain should be solid and sometimes is depending upon the viewing angle.

Does anyone have any suggestions as to what is happening or what I might be able to do to fix it?

From the info given it's not possible to know exactly what is wrong as

there are several possibilities depending upon what the rest of your
application is doing, and the data itself, none of which we have
knowledge of. The best I can do is back some general statements about
handling this type of data.

First up, OpenGL graphics hardware works mostly with floats so that
when working with large vertex values precision can be a big issue,
causing jitter. The way to avoid precision issues when rendering with
the OSG is to create your geometry with a local origin and decorate
this with a Transform node that places this subgraph in it's final
location. The OSG uses doubles to accumulate the Camera View matrix
and all the internal Transform nodes to maintain precision as long as
possible before passing to OpenGL where it'll be cast down to floats.
This technique has been discussed many times in the osg-users mailing
list/forum so have a look through the archives. The osgEarth and
osgTerrain NodeKit's use these technique to handle whole earth
databases with precision problems,

The next possibility is z fighting. You mix discussion of line and
mesh in your post and the picture kinda looks like you might have a
line and mesh together, if you do and the line is
appearing/disappearing if could be due to z fighting. This another
topic discussed many times in the OSG community and out on the web so
have a search.

Robert.

On 19 January 2018 at 01:57, Adrian Jelffs <> wrote:

Quote:

Hi,

I am pretty new to OSG but have been working on it for the past few weeks. I have an application that is rendering a 2D terrain with a constant width. When I rotate my display the line sometime appears broken.

There are no other layers present. I have attached an example. This terrain should be solid and sometimes is depending upon the viewing angle.

Does anyone have any suggestions as to what is happening or what I might be able to do to fix it?

Would it be possible for you to explain what these are doing or send me a link where I can read about it? I find that the online information is not descriptive enough.

If I add a 3D terrain underneath the 2D terrain then the problem comes back again and the problem looks like the attached image. Even when I add a significant offset to the 2D terrain from the 3D terrain I still get the same results.

I put an offset on the line to check if it was a precision issue and the problem still happens to the line. So I am thinking it must be a Z fighting issue. However, the problem doesn't go away when I zoom in so I thought Z fighting would only be an issue when I zoom out.

Would it be possible for you to explain what these are doing or send me a link where I can read about it? I find that the online information is not descriptive enough.

If I add a 3D terrain underneath the 2D terrain then the problem comes back again and the problem looks like the attached image. Even when I add a significant offset to the 2D terrain from the 3D terrain I still get the same results.

I put an offset on the line to check if it was a precision issue and the problem still happens to the line. So I am thinking it must be a Z fighting issue. However, the problem doesn't go away when I zoom in so I thought Z fighting would only be an issue when I zoom out.

You tests confirm it's a z fighting issue. There will be lots of
discussions about zfighting in the osg-users/forum archives as well as
on general internet, go do a google search.

The ComputeNearFarMode setting the OSG provide control how the OSG
computes the near and far distances used when setting up the
projection matrix. For best precision of the depth buffer you want to
maximum the near/far ratio, this means pulling in the far distances as
much as possible, and pushing out the near distances are much as
possible - the ComputeNearFar modes control the way that OSG attempts
to optimize this ratio, it's not fall proof though.

If you know exactly what near/far distances are appropriate for your
scene you can just disable the CompureNearFar and set the projection
matrix yourself.

Another approach can be to depth partition your scene, or to use a non
linear depth buffer. This are both topics that have been discussed
here on osg-users/forum and on the internet so go search these topics.

Robert.

On 27 January 2018 at 03:32, Adrian Jelffs <> wrote:

Quote:

Hi Robert,

Many thanks for your reply. I found that when I add the following lines it fixes the 2D terrain problem.

Would it be possible for you to explain what these are doing or send me a link where I can read about it? I find that the online information is not descriptive enough.

If I add a 3D terrain underneath the 2D terrain then the problem comes back again and the problem looks like the attached image. Even when I add a significant offset to the 2D terrain from the 3D terrain I still get the same results.

I put an offset on the line to check if it was a precision issue and the problem still happens to the line. So I am thinking it must be a Z fighting issue. However, the problem doesn't go away when I zoom in so I thought Z fighting would only be an issue when I zoom out.

Many thanks for your help. The big problem is that whenever you Google an issue as Z Fighting, a trillion results appear about somebodies similar issue in a forum which usually ends up in the answer being "it is probably z fighting, there are many answers on the internet if you Google it"

After several days of Googling I have gathered very little information. There is a distinct lack of examples available on the internet and I am yet to find a single site which can explain to me what each of the settings such as DO_NOT_COMPUTE_NEAR_FAR, COMPUTE_NEAR_FAR_USING_PRIMITIVES etc actually does.

For my own particular problem I found that the following link was the most helpful so far:

This explained to me some of the issues associated with Z fighting and that I can't make my fustrum as big as I want it to be. I then found, mainly by trial and error, that the setting COMPUTE_NEAR_FAR_USING_PRIMITIVES works the best in my situation. I am yet to find any documentation that tells me how to set the "primitives". Is there actually a location on the internet that has documentation about OSG as opposed to API definitions or forum questions?

Z fighting is a basic topic for real-time computer graphics, we can't
be responsible for teaching you everything about computer graphics

As for primitives well again it's basic topic for real-time computer
graphics, just like OpenGL the OSG uses the primitives, we've adopted
the same language for the same features when wrapping up OpenGL
features in the OSG.

To understand primitives have a look online, or at OSG examples like
osggeometry, in particular where it sets of the PrimitiveSet's for the
geometry. Also have a look at the
OpenSceneGraph/include/osg/PrimitiveSet header class.

Robert.

On 27 January 2018 at 22:28, Adrian Jelffs <> wrote:

Quote:

Hi Robert,

Many thanks for your help. The big problem is that whenever you Google an issue as Z Fighting, a trillion results appear about somebodies similar issue in a forum which usually ends up in the answer being "it is probably z fighting, there are many answers on the internet if you Google it" :)

After several days of Googling I have gathered very little information. There is a distinct lack of examples available on the internet and I am yet to find a single site which can explain to me what each of the settings such as DO_NOT_COMPUTE_NEAR_FAR, COMPUTE_NEAR_FAR_USING_PRIMITIVES etc actually does.

For my own particular problem I found that the following link was the most helpful so far:

This explained to me some of the issues associated with Z fighting and that I can't make my fustrum as big as I want it to be. I then found, mainly by trial and error, that the setting COMPUTE_NEAR_FAR_USING_PRIMITIVES works the best in my situation. I am yet to find any documentation that tells me how to set the "primitives". Is there actually a location on the internet that has documentation about OSG as opposed to API definitions or forum questions?

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou cannot download files in this forum