OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

OSG in Gtk3 GLArea

Goto page Previous  1, 2
 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General
View previous topic :: View next topic  
Author Message
mean_taipan
Newbie


Joined: 01 Jun 2018
Posts: 10

PostPosted: Tue Jun 05, 2018 4:34 pm    Post subject:
Reply with quote

Hi kornerr,

Thanks for the heads up. I'll give it a try when I get back to core profile work, which I will feel better about once I have a kludge that works well enough to keep the boss happy.

We basically use only geodes, switches and model transforms, along with some state settings like blending. So I'm hoping that there's not too many more implementation details to worry about.

Cheers,
Steve
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11924

PostPosted: Tue Jun 05, 2018 6:46 pm    Post subject:
OSG in Gtk3 GLArea
Reply with quote

Hi Steve,

On 5 June 2018 at 17:34, Steve Hardy <> wrote:
Quote:
We basically use only geodes, switches and model transforms, along with some state settings like blending. So I'm hoping that there's not too many more implementation details to worry about.

What type of geometry and state are you using?

FYI, if you using text, in OSG-3.4.x and before there was no fallback
for GLES2 or GL Core Profile so you'd have to provide your own
shaders, in OSG-3.6.x and master there are shaders provided for you.
This doesn't solve all the issues with moving to GLES2 or GL Core
Profile but does help a little. For the rest of the scene graph
you'll need to provide your own shaders.

Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
mean_taipan
Newbie


Joined: 01 Jun 2018
Posts: 10

PostPosted: Tue Jun 05, 2018 7:21 pm    Post subject:
Reply with quote

Hi Robert,

The full application uses the following:

- read .wrl files using osgDB::readNodeFile()
- create geometry nodes dynamically with quads, lines, line strip.
- billboards with text
- osgSim::DOFTransform, osg::MatrixTransform
- osg::Camera (additional cameras for HUD or inset display)
- osg::TextureRectangle (we live video feed to textured quad(s))
- in the osg::StateSet we set modes for GL_NORMALIZE (sine we need to scale the VRML models), GL_BLEND (translucent quads), 2-sided lighting,

Hope that's the info you were asking for. For the current test case, however, I have stripped it down to just quad-based geometry and a few transforms, single-sided, single world lighting.

To make things just a bit more complicated, I'm actually calling from Python code, so the OSG API is selectively wrapped using boost::python. I don't think that's an issue at present.

I know practically nothing about shaders, so I'll take any recommendations for reading material.


Cheers,
Steve
Back to top
View user's profile Send private message
mean_taipan
Newbie


Joined: 01 Jun 2018
Posts: 10

PostPosted: Wed Jun 06, 2018 2:42 am    Post subject:
Reply with quote

So far, the kludge solution is almost working. I needed to add

glPixelStorei(GL_PACK_ALIGNMENT, 1);

before glReadPixels() otherwise it broke if the window width wasn't a multiple of 8.

Problems remaining:

1. the aspect ratio does not adjust properly on window size changes, so that the scene just stretches like rubber.

2. there is a truly horrendous amount of copying data.

For (1), I was assuming that

camera->setViewport(new osg::Viewport(0,0,width,height));
camera->setProjectionMatrixAsPerspective(30.0f, 1.*width/height, 1.0f, 10000.0f);

on the slave and main (?) cameras would fix that up, but no. Maybe there's something cached somewhere, even though I am completely reconstructing the slave camera on each resize.

Any suggestions where to look?

For (2), after the hardware renders the scene, and the PBO is mapped back into userspace RAM, the following copies occur:

- memcpy to the osg::Image data
- image->flipVertical() since 2D library has Y inverted w.r.t GL.
- copy to a new Python string object
- copy to a new GdkPixbuf object
- copy to the cairo context (that's the Gtk 2D graphics engine).

I think a lot of this could be eliminated by creating the GdkPixbuf directly from the PBO map, flipping the row order in this copy. Although it performs OK, we have to run on low-end systems.

Cheers,
Steve
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11924

PostPosted: Wed Jun 06, 2018 7:52 am    Post subject:
OSG in Gtk3 GLArea
Reply with quote

Hi Steve,

On 6 June 2018 at 03:42, Steve Hardy <> wrote:
Quote:
Problems remaining:

1. the aspect ratio does not adjust properly on window size changes, so that the scene just stretches like rubber.
....
For (1), I was assuming that

camera->setViewport(new osg::Viewport(0,0,width,height));
camera->setProjectionMatrixAsPerspective(30.0f, 1.*width/height, 1.0f, 10000.0f);

on the slave and main (?) cameras would fix that up, but no. Maybe there's something cached somewhere, even though I am completely reconstructing the slave camera on each resize.

Any suggestions where to look?


In osg::Camera there is support for adjusting the projection matrix to
track changes in he viewport:

enum ProjectionResizePolicy
{
FIXED, /**< Keep the projection matrix fixed, despite
window resizes.*/
HORIZONTAL, /**< Adjust the HORIZONTAL field of view on
window resizes.*/
VERTICAL /**< Adjust the VERTICAL field of view on window resizes.*/
};

/** Set the policy used to determine if and how the projection
matrix should be adjusted on window resizes. */
inline void setProjectionResizePolicy(ProjectionResizePolicy
policy) { _projectionResizePolicy = policy; }

/** Get the policy used to determine if and how the projection
matrix should be adjusted on window resizes. */
inline ProjectionResizePolicy getProjectionResizePolicy()
const { return _projectionResizePolicy; }


Quote:
2. there is a truly horrendous amount of copying data.
....
For (2), after the hardware renders the scene, and the PBO is mapped back into userspace RAM, the following copies occur:

- memcpy to the osg::Image data
- image->flipVertical() since 2D library has Y inverted w.r.t GL.
- copy to a new Python string object
- copy to a new GdkPixbuf object
- copy to the cairo context (that's the Gtk 2D graphics engine).

To avoid the flip you could flip the projection matrices y axis so
that the it renders upside down,

Quote:
I think a lot of this could be eliminated by creating the GdkPixbuf directly from the PBO map, flipping the row order in this copy. Although it performs OK, we have to run on low-end systems.

Another approach might be to look at trying to use a GL context for
the actual window and see if you can keep the data resident in
graphics memory and copy it across without doing the round trip to the
CPU.

Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
mean_taipan
Newbie


Joined: 01 Jun 2018
Posts: 10

PostPosted: Wed Jun 06, 2018 2:32 pm    Post subject:
Reply with quote

Hi Robert,

OK I will check out the resize policy settings.

Excellent point about inverting the projection matrix. Since the last post, I managed to eliminate most of the copying, with the single remaining copy reversing the pixel row order on-the-fly. Since that copy is unavoidable, in the end it probably wouldn't save much time to invert the rendering.

One question I do have: in the screencapture sample that I based this off, there are 4 options: read pixels, and 1- 2- or 3 pixel buffer objects. I assumed that single PBO is appropriate for this use (since our application doesn't demand super smooth high frame rates or anything, 15Hz is adequate). But to minimize CPU involvement, is this the best choice?

It's getting close enough to be a workable backup plan, so next step would be to try your suggestion of copying between GL contexts.

Cheers,
Steve
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General All times are GMT
Goto page Previous  1, 2
Page 2 of 2

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



Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP