[osg-users] Updating app to latest OSG

36 views
Skip to first unread message

OpenSceneGraph Users

unread,
Sep 6, 2020, 12:47:32 PM9/6/20
to osg-...@lists.openscenegraph.org
Hi,

I'm currently in the process of updating an application that originally used OSG version 2.8.2, I didn't write the application and I'm not very familiar with OSG or OpenGL.

I didn't have to change too much to get it working with OSG 3.6.5, just the addition of a vertex shader to compute coordinates as the original version just used gl_TexCoord[0] from inside the fragment shader.

The application displays seismic data as 2D planes comprising square tiles of 2D textures, the fragment shader is just assigning a colour from a colour scale to each sample value. The planes can be oriented along any of the x,y and z axes and intersect at right angles and it's at the intersection of the planes where I'm seeing something odd in my new version.

At the point where orthogonal planes intersect, a rotated view shows that the foreground plane isn't properly occluding the planes behind and I can see this has something to do with the texture2D tile size as the smaller the size the less pronounced the effect.

There's also a wire frame to show the bounds of the display and even that doesn't appear to be drawn correctly with respect to which bits should be visible.

I'm going to attach a couple of pictures - is that allowed on this list? The first will be the original application and the second my updated version.

I haven't changed any of the code that positions the planes and they do look to be in the right place but rotating the scene creates the very odd effect I hope you can see in the second screen shot.

Any hints as to where to look for the problem would be much appreciated.

Cheers,
Franco









OpenSceneGraph Users

unread,
Sep 7, 2020, 4:13:01 AM9/7/20
to OpenSceneGraph Users
Hi Franco,

Posting screenshots is fine, and exactly the thing to do with these types of problems.

It's not possible to diagnose the exact problem you are seeing with rendering under OSG-3.6.5.  Broadly it looks like a depth test issue.

I don't know if this is relevant, but will mention it as some others have been caught out by it. One of the bug fixes in the OSG-3.x series was to fix an override of the osg::Camera settings that was causing applications settings to be lost.  The fix had the side effect of revealing missing settings, in essence it was a bug A that hide a bug B that only occurred with certain usage models.

So bug A has been fixed and bug B usage case is an application creates a viewer osg::Camera, sets up a graphics context, then just directly assigns it to the viewer without setting any global state that is required for top level osg::Camera.  The state not set includes GL_DEPTH_TEST - which is where there "might" be an overlap with the problem you see with your application.

Normal OSG usage where you use the Viewer Camera's that are assigned by default also call StateSet::setGlobalDefaults() on this StateSet, so you never see a problem.  All the OSG examples provided in the OpenSceneGraph distribution do this.

However, the problem usage cause was something that was done in early osgQt based examples - they created a local osg::Camera assigned to the viewer and never called StateSet::setGlobalDefaults() on the osg::Camera's StateSet.   These examples used to work fine, even with this ill defined state because of Bug A.  If you copied one of these examples then you'll inherit this bug B usage case.

If this is the case then can either:
 
    1) Just use the viewer(views) Camera via Viewer/View::getCamera() to get the Camera to assign the GraphicsContext to, so utilize the default settings.
    2) Call:  camera->getOrCreateStateSet()->setGlobalDefaults() on the locally created Camera before it's assigned to the View(er).

There was a lot of discussion about this problem usage case and the solution when bug A was fixed and bug B revealed, but that's quite a few years ago now - had your software been updated more regularly it's likely you'll have seen discussions.

Cheers,
Robert.

OpenSceneGraph Users

unread,
Sep 7, 2020, 6:53:31 AM9/7/20
to osg-...@lists.openscenegraph.org
Hi Robert,

Thanks for the comprehensive reply, I think I've done what you suggested but it doesn't appear to have changed anything.

This application uses osggtkdrawingarea which I've modified to work with GtkGLArea.

The viewer is added like so:

class OSGGTKDrawingArea : public osgViewer::Viewer {
osg::ref_ptr<osgViewer::GraphicsWindowEmbedded> _gw;

...
}

_gw = setUpViewerAsEmbeddedInWindow(0, 0, width, height);

and in the realise callback I've added this:

getCamera()->setGraphicsContext(_gw);
    getCamera()->getOrCreateStateSet()->setGlobalDefaults();

I even tried explicitly setting depth test

getCamera()->getOrCreateStateSet()->setMode( GL_DEPTH_TEST, osg::StateAttribute::ON );

Still no joy.

I turned on GL_CULL_FACE just to check and it did what I expected so setting the camera attributes appears to be working.

Anything else you can think of tat I can try?

Cheers,
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

OpenSceneGraph Users

unread,
Sep 7, 2020, 3:34:20 PM9/7/20
to OpenSceneGraph Users
Hi Franco,

I can't help with GTK related stuff as I've neer worked with it.

If you can try your scene graph with the standard osgViewer rather than embedding into a GTK graphics context.

Robert.

OpenSceneGraph Users

unread,
Sep 8, 2020, 8:59:45 PM9/8/20
to osg-...@lists.openscenegraph.org

Aha! Thanks for the tip.

I needed to add this call to osggtkdrawingarea.cpp realise callback

gtk_gl_area_set_has_depth_buffer(area, TRUE);

Working as before now.

Cheers,
_______________________________________________
Reply all
Reply to author
Forward
0 new messages