[osg-users] SceneView and Multi-camera render to texture

1 view
Skip to first unread message

Argentieri, John-P63223

unread,
Mar 17, 2008, 1:46:04 PM3/17/08
to osg-...@openscenegraph.org

Robert and pals,

We are using osg 2.0. I am trying to duplicate the behavior of the osgdistortion example, but we are using osgUtil::SceneView and not osgViewer::Viewer.

I have been unable to mimic the behavior of the example. If I set my texture camera to PRE_RENDER, all I get is a blank quad set to the color of the osg::geometry. If I set it to NESTED_RENDER, which is wrong, I think it draws the texture to the back buffer, because I can see it on the screen.

Can anyone offer me some advice in this area?

Thanks for your help….

John Argentieri
Software Engineer
GENERAL DYNAMICS
C4 Systems
(407) 281-5568
John.Ar...@gdc4s.com

"This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message."

Robert Osfield

unread,
Mar 17, 2008, 3:28:00 PM3/17/08
to OpenSceneGraph Users
Hi John,

As you are rolling your own viewer its really open ended how you are
doing things, so its hard to know where to start. Are you using
pbuffers? frame buffer objects? How are you creating graphic
contexts?

Personally I'd recommend using osgViewer, it does mean that you know
it'll work and providing support at our end is much more sane as we
won't have to ask dozens of question trying to work out what setup you
have. Rolled you own viewer is really expensive for us to support.

Robert.

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

Argentieri, John-P63223

unread,
Mar 17, 2008, 4:53:03 PM3/17/08
to osg-...@openscenegraph.org
Robert,

I don't disagree with you, BUT we have certain requirements that we
would need from osgViewer in that case.

1) The window it runs in has already been created by us before calling
run().
2) Do we really have to extend GraphicsWindowEmbedded if we want to
support [1] for X11 and Win32?
3) Multiple views (windows) attached to one scene graph.
4) The ability to scrap all osg handlers for events, or to leave out
osgGA completely.
5) We need to dynamically modify the scene graph. If [3] is
multi-threaded that could be trouble.

Will osgViewer support these requirements? Is is possible to create a
single instance of osgViewer and add osg::Camera subtrees per each new
window during runtime?

P.S. Our network has problems with lists.openscenegraph.org, and I am
sending to osg-...@openscenegraph.org instead. Has this changed again?

Thanks,

John Argentieri
Software Engineer
GENERAL DYNAMICS
C4 Systems
(407) 281-5568
John.Ar...@gdc4s.com

"This email message is for the sole use of the intended recipient(s) and
may contain GDC4S confidential or privileged information. Any
unauthorized review, use, disclosure or distribution is prohibited. If
you are not an intended recipient, please contact the sender by reply
email and destroy all copies of the original message."

Hi John,

Robert.

> Thanks for your help....

Argentieri, John-P63223

unread,
Mar 17, 2008, 4:54:46 PM3/17/08
to osg-...@openscenegraph.org
Robert,

Oh and I forgot, we are creating graphics contexts via a class that I
wrote to manage context per window. I remember that I had to create a
fake context along with the first real context to successfully implement
sharing. Is there a nice way to use OSG to manage contexts?

John

-----Original Message-----
From: osg-user...@lists.openscenegraph.org
[mailto:osg-user...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Monday, March 17, 2008 3:28 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] SceneView and Multi-camera render to texture

Hi John,

Robert.

> Thanks for your help....

J.P. Delport

unread,
Mar 18, 2008, 3:16:47 AM3/18/08
to OpenSceneGraph Users
Hi,

I'm using PRE_RENDER cameras rendering to FrameBufferObjects with
SceneView, in some cases multi-pass as well. I've used a similar setup
as per the osgprerender example and did not find a difference between
using SceneView versus osgViewer. I'll splat some code into the bottom
of the email, maybe it helps. It's with svn osg, Linux, NVidia.

cheers
jp

Argentieri, John-P63223 wrote:
> Robert and pals,
>
> We are using osg 2.0. I am trying to duplicate the behavior of the
> osgdistortion example, but we are using osgUtil::SceneView and not
> osgViewer::Viewer.
>
> I have been unable to mimic the behavior of the example. If I set my
> texture camera to PRE_RENDER, all I get is a blank quad set to the color
> of the osg::geometry. If I set it to NESTED_RENDER, which is wrong, I
> think it draws the texture to the back buffer, because I can see it on
> the screen.
>
> Can anyone offer me some advice in this area?
>
> Thanks for your help….
>

> *John Argentieri*
> *Software Engineer*
> *GENERAL DYNAMICS*
> *C4 Systems *
> *(407) 281-5568*
> *John.Ar...@gdc4s.com*

SceneView setup
---8<---
_SceneView = new osgUtil::SceneView();
_SceneView->setDefaults();
osg::StateSet *gstate = _SceneView->getGlobalStateSet();
gstate->setGlobalDefaults();
gstate->setMode(GL_BLEND, osg::StateAttribute::OFF);
gstate->setMode(GL_CULL_FACE, osg::StateAttribute::OFF);
gstate->setMode(GL_DEPTH_TEST, osg::StateAttribute::OFF);

_RootNode = new osg::Group();
_SceneView->setSceneData(_RootNode.get());
_SceneView->setClearColor(osg::Vec4(1.0f, 0.0f, 0.0f, 1.0f));
gstate->setMode( GL_LIGHTING, osg::StateAttribute::OFF);
_SceneView->setLightingMode(osgUtil::SceneView::NO_SCENEVIEW_LIGHT);
---8<---

Camera setup
---8<---
// clearing
_Camera->setClearColor(osg::Vec4(1.0f,0.0f,0.0f,1.0f));
_Camera->setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

// projection and view
_Camera->setProjectionMatrix(osg::Matrix::ortho2D(0,1,0,1));
_Camera->setReferenceFrame(osg::Transform::ABSOLUTE_RF);
_Camera->setViewMatrix(osg::Matrix::identity());

// viewport
_Camera->setViewport(0, 0, _TextureWidth, _TextureHeight);

_Camera->setRenderOrder(osg::Camera::PRE_RENDER);

_Camera->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);

// attach the texture and use it as the color buffer.
_Camera->attach(osg::Camera::COLOR_BUFFER, _OutTexture.get());
---8<---

Quad setup
---8<---
osg::ref_ptr<osg::Group> top_group = new osg::Group;

osg::ref_ptr<osg::Geode> quad_geode = new osg::Geode;

osg::ref_ptr<osg::Vec3Array> quad_coords = new osg::Vec3Array; //
vertex coords
// counter-clockwise
quad_coords->push_back(osg::Vec3d(0, 0, -1));
quad_coords->push_back(osg::Vec3d(1, 0, -1));
quad_coords->push_back(osg::Vec3d(1, 1, -1));
quad_coords->push_back(osg::Vec3d(0, 1, -1));

osg::ref_ptr<osg::Vec2Array> quad_tcoords = new osg::Vec2Array; //
texture coords
quad_tcoords->push_back(osg::Vec2(0, 0));
quad_tcoords->push_back(osg::Vec2(_TextureWidth, 0));
quad_tcoords->push_back(osg::Vec2(_TextureWidth, _TextureHeight));
quad_tcoords->push_back(osg::Vec2(0, _TextureHeight));

osg::ref_ptr<osg::Geometry> quad_geom = new osg::Geometry;
osg::ref_ptr<osg::DrawArrays> quad_da = new
osg::DrawArrays(osg::PrimitiveSet::QUADS,0,4);

quad_geom->setVertexArray(quad_coords.get());
quad_geom->setTexCoordArray(0, quad_tcoords.get());
quad_geom->addPrimitiveSet(quad_da.get());

_StateSet = quad_geom->getOrCreateStateSet();
_StateSet->setMode(GL_LIGHTING,osg::StateAttribute::OFF);
_StateSet->setTextureAttributeAndModes(0, _InTexture.get(),
osg::StateAttribute::ON);


quad_geode->addDrawable(quad_geom.get());

top_group->addChild(quad_geode.get());

return top_group;
---8<---

--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.

Robert Osfield

unread,
Mar 18, 2008, 4:49:15 AM3/18/08
to OpenSceneGraph Users
Hi John,

On Mon, Mar 17, 2008 at 8:53 PM, Argentieri, John-P63223
<John.Ar...@gdc4s.com> wrote:
> I don't disagree with you, BUT we have certain requirements that we
> would need from osgViewer in that case.
>
> 1) The window it runs in has already been created by us before calling
> run().

The osgViewer library creates the windows at realize, unless they have
already been created.

FYI, run() is just the frame loop wrapped up in a single convinience
call(), you can break it out and manage realize(), and the frame loop
all yourself. There are examples of this in the OSG example set.

> 2) Do we really have to extend GraphicsWindowEmbedded if we want to
> support [1] for X11 and Win32?

GraphicsWindowX11, GraphicsWindowWin32 and GraphicsWindowCarbon all
support window inheritance i.e. they all can inherit their window from
an externally created window, adding the OpenGL support to this
window.

The osgviewerMFC and osgviewerQT both had code paths that illustrate
this window inheritance route.

> 3) Multiple views (windows) attached to one scene graph.

This is one of the main points of the development of osgViewer, it now
elegantly handles multiple views attached to one scene graph. The
class for doing this is osgViewer::CompositeViewer, this manages a
list of osgViewer::View(s). A few key points about it:

Each View has one scene graph, and can share its scene graph between
other instances of View.

The View can also share the same GraphicsWindow, or have its own
GraphicsWindow.

The View also has a master Camera, and an optional list of slave
Camera so you can scale from simple
views up to complete distortion correction or multiple display
output setups.

Each View has its own event handlers and cameras handlers.

Its extremely flexible and configurable.

> 4) The ability to scrap all osg handlers for events, or to leave out
> osgGA completely.

Yep, osgViewer supports this too. By default osgViewer doesn't
register any camera manipualators or event handles, you add the ones
you need. See applications/osgviewer/osgviewer.cpp.

he only except is that a TrackballManipulator is added by default by
Viewer::run() if no other camera manipulator has been added, but run()
is just a conveince method, you are free to roll you own frame loop
and control each View's master Camera view within the main loop
according to your own needs. I'd recommend this approach, run() is
only used in the examples to keep the examples simple and just focused
on the examples main task and not demonstrating viewer code n times
over.

> 5) We need to dynamically modify the scene graph. If [3] is
> multi-threaded that could be trouble.

osgViewer supports a range of threading options, all controllable by
you. You can set single threaded if you wish, but there is also
support for managing modification of the scene graph whilst
multi-threading.

viewer.setThreadingModel(osgViewer::Viewer::SingleThreaded);

Also see other threads about the various threading models.

> Will osgViewer support these requirements? Is is possible to create a
> single instance of osgViewer and add osg::Camera subtrees per each new
> window during runtime?

Yes and yes. You can even stop and start threading for when you do
these reorganizations of the viewer.

osgViewer is meant to be flexible in almost all ways, its intended to
solve the full range users viewer needs, and in doing so consolidate
the usage in a way that makes it easier to document, learn, usage and
for us at the other end to support.

osgViewer is just viewer nirvana yet though, if there are things that
can't be done then we can discuss these and look to resolve then to
make it closer to the ideal of a perfect viewer library. I suspect
for your own needs osgViewer is already along way along this route and
can do everything you need right out of the bag.

> P.S. Our network has problems with lists.openscenegraph.org, and I am
> sending to osg-...@openscenegraph.org instead. Has this changed again?

list.openscenegraph.org is the correct address.

Robert.

Reply all
Reply to author
Forward
0 new messages