Re: [osg-users] [osg-submissions] View Dependent Shadow maps (LispSM)

[Wojciech Lewandowski]

Thank You, Adrian

Lispsm classes derive all methods from StandardShadowMap & MinimalShadowMap.
StandardShadowMap has setLight method. I believe this is what you want.

Cheers,
Wojtek

 -Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Adrian Egli
OpenSceneGraph (3D)
Sent: Tuesday, September 23, 2008 10:46 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] [osg-submissions] View Dependent Shadow maps
(LispSM)


  Sorry, answered to  wrong list
  but here i am right :-)


  Hi all,

  great algorithm. i have just one question. my scene has a lof of lighs,
but only one should cast shadows. so would it be possible to add a method
like in parallel splitted shadow map to tell the algorithm witch light it
should be used for shadow casting.

  please have a short look at :
  _ParallelSplitShadowMap->
  setUserLight(m_sun.get());

  this method allow to tell the sun light. :-) for example

  adrian


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

Re: [osg-users] Extracting embedded Textures

[Paul Speed]

I almost hate to draw attention to this but just in case it ever matters...

For various reasons, I ended up writing some IVE readers in Java. 
Mostly because I had some .ive files that no version of OSG I had 
available would load correctly.  And partly because this is the sort of 
thing that feeds an odd manic part of my brain.


At any rate, the stuff is implemented to allow code configurable 
profiles because I was pretty sure I was going to have to hack a 
non-standard version.  The result of which is something that is almost 
like documentation... in code:

http://meta-jb.cvs.sourceforge.net/meta-jb/sandbox/src/java/org/progeeks/osg/io/StandardIveConfiguration.java?revision=1.11&view=markup

Each supported object type has an individual object profile with field 
types added (with an optional version designator).


I never finished it so there are some objects that aren't defined yet 
but I got it to the point that it could load all of my own IVE files and 
I was able to determine more about what was wrong with my bad ones. 
There have also been some changes in the IVE format that are harder to 
configure this way (byte ordering changes, etc.)... one day I may even 
get back to it.


Not sure it's at all useful, but it does centrally describe (in a way) 
the IVE format... with a little translation.  Other than that, it's 
probably only useful to me. :)


-Paul

Evans, Frank wrote:

Thanks once again for the incredibly fast response. Up to now I've been
using the OsgDotNet wrappers, so writing a Custom Visitor class means
maintaining and updating the wrappers as well. At least, if I understand
the solution correctly. I will of course make every effort to leverage
the native loader.



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Tuesday, September 23, 2008 12:53 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Extracting embedded Textures


On Tue, Sep 23, 2008 at 5:45 PM, Evans, Frank <[EMAIL PROTECTED]> wrote:

Thanks Robert, grinding through the learning curve now. Getting to the
vertices was easy (getVertexArray). Was looking for something similar
for image/textures.


It's straight forward, just look at the NodeVisitor examples I
mentioned.


Is there any documentation on the IVE format? A spec file?


No there is no spec file, it is not meant to be read in a non native
way like an interchanges format such Collada.

Given you have a perfectly serviceable loader it'd be madness to try
and read it by hand, please just use my suggestion.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

Re: [osg-users] osgviewerQT --QOSGWidget cannot create context?

[Jean-Sébastien Guay]

Hello Martin,


I will create a fuller QT sample, in line with the MFC sample, showing a 
toolbar and buttons etc.


That would be nice, though a case could be made from the point of view 
that an OSG example should not show how to program QT, just how to 
integrate the two... So if you do decide to pursue this, I would suggest 
you structure the code so that it's clear what code relates to the 
integration, and what code is strictly QT-related.


J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Fullscreen

[Tim Jaffe]

Greetings,

Thanks for the response. I got the borderless window method to work and 
finished updating the code to 2.4.  Is it possible to produce a true (exclusive 
mode) fullscreen view--perhaps by using an externally-created exclusive OpenGL 
context?

Thanks again,
/* blahpers */

> Hi Tim,
> 
> By default the osgViewer library will open up windows fullscreen, i.e.
> try runing osgviewer or almost all of the osg examples.  For examples
> of explictly setting up windows have a look at the osgcamera example
> and also the View::setUpView*() methods in src/osgViewer/View.cpp.
> 
> The fullscreen window It is done using a borderless window, in the
> same way the Producer did it.
> 
> Robert.
> 
> On Fri, Sep 5, 2008 at 7:47 PM, Tim Jaffe  wrote:
> > Greetings,
> >
> > I'm upgrading some old OSG 1.2 code to OSG 2.4 and need to implement the
> > option to run in fullscreen mode.  Sans Producer, how is this done?  Also,
> > is this true fullscreen (i.e., exclusive) mode or just a borderless topmost
> > window sized to fit the screen?
> >
> > Many thanks in advanced,
> > /* blahpers */
> >
> > ___
> > osg-users mailing list
> > osg-users at lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >



  

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

Re: [osg-users] osgviewerQT --QOSGWidget cannot create context?

[mgb]

>Does the osgviewerQT add any toolbars? 
No it doesn't - I assumed because the adaptor widget did!

I will create a fuller QT sample, in line with the MFC sample, showing a 
toolbar and buttons etc.

Martin
mgb mgbeckett com


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

Re: [osg-users] multi camera rendering and pick issues

[Emmanuel Roche]

Oh, and by the way, the results seem to be exactly the same when I use the
osgUtil::IntersectVisitor instead of the new version... so, someone has a
clue ?

regards,
Manu.


2008/9/23 Emmanuel Roche <[EMAIL PROTECTED]>

> Okay...
>
>  I think I tried everything I could think about, unsuccessfully...
> unfortunately, I'm currently on WinXP with Visual Studio and for some
> obscure reason, I just cannot get/use the debug symbols from some of the OSG
> libraries (maybe beacuse I'm accessing those functions introspectively
> though a Lua release binary ? not sure about all that...) an as a result I
> cannot go deeper into those tests :-(
>
> But I've just discovered a new fact: this is at least partially linked to
> the scale of my object, I tried the following scene graph:
>
> - the main View camera
>   - my root group
> - a sub camera
>   - a PositionAttitudeTransform (with a scale set)
> - an object
>
> ---> then depending on the scale applied in the PositionAttitudeTransform I
> can pick parts of my object or not : the bigger the scale, the closer to the
> object I need to be to get some intersections (and I'm not even sure those
> intersections are correct...). So could there be a scale factor not applied
> somewhere ?? Or maybe, since my main camera renders no objects its near/far
> planes are set to minimal values and then those settings are not modified
> accordingly when going though a sub camera in an intersectionVisitor [this
> could explain why I cannot select objects if I'm not very very close to them
> (and depending on their scale)...] ?
>
> Is there an other way to render Univers scale + high precision scenes
> without using multiple cameras as children ??? I did a quick test using
> ClearNodes and setting the only camera left to "DO_NOT_COMPUTE_NEAR_FAR",
> but the results are not good (it seems to me that the ClearNodes clear the
> color buffer even when I only set the DEPTH_BUFFER_BIT mask... I really
> don't get it...).
>
> regards,
> Manu.
>
>
> 2008/9/23 Emmanuel Roche <[EMAIL PROTECTED]>
>
>> Hi Robert,
>>
>> unfortunately I don't think this an available option in my current
>> project: our software is already relying quite heavily on our current
>> CompositteViewer / View structure  (a view per window [using wxWidgets], a
>> camera manipulator, a single scene graph that should not be cut into pieces,
>> etc... and any way, I think there is a real problem here (expect if there is
>> still something I missed) so I think for me (in both cases) it's important
>> to solve this issue instead of just bypassing it.
>>
>> I hope you will find some time to give a deeper look to this thread later
>> ;-), meanwhile I'm not giving up: I checked the setSceneData(node) methods
>> and it's basically the same just a camera->addChild(node) call... so I may
>> have the finger on something [as I expected a noticable difference]. I'll
>> keep you informed.
>>
>> regards,
>> Manu.
>>
>> 2008/9/23 Robert Osfield <[EMAIL PROTECTED]>
>>
>> Hi Manu,
>>>
>>> I don't have the head for complex emails or logic right now, so I
>>> won't five into the details of thread.  What does jump out from speed
>>> reading this email is why you don't use osgViewer::CompositeViewer
>>> with multipler Views as this would totally clear up an ambiguity about
>>> what camera each intersection test is made against.
>>>
>>> Robert.
>>>
>>> On Tue, Sep 23, 2008 at 5:42 PM, Emmanuel Roche
>>> <[EMAIL PROTECTED]> wrote:
>>> > Hello again...
>>> >
>>> > I did other tests, my idea was:
>>> >
>>> > I have a single main camera displaying a root object [an osg::Group]
>>> and
>>> > this root object contains 5 or 6 osg::Camera object as direct children.
>>> And
>>> > those "sub cameras" contain pieces of the scene I want to display.
>>> Since (I
>>> > don't know why, but) using an IntersectVisitor gives completely
>>> incorrect
>>> > result on the main camera in that case, I decided to use my
>>> > intersectionvisitor with each sub camera one by one... in that case
>>> > everything should behave as if each of my sub camera was the root
>>> object
>>> > when it's traversed, no ?... but the answer is: NO... :-( this case
>>> doesn't
>>> > seem to be the same as using a single camera containing objects as the
>>> > intersection results are still completely false
>>> >
>>> > So my big question is now : what's the difference (from a "camera point
>>> of
>>> > view when it comes to intersections") between view->setSceneData(node)
>>> and
>>> > camera->addChild(node) ??? I keep investigating... :-) but any shortcut
>>> > would really be appreciated :-).
>>> >
>>> > regards,
>>> > Manu.
>>> >
>>> > PS: here is the main part of the code concerning the previous idea I
>>> > mentioned if someone wants to have a look...
>>> >
>>> > osg::Camera* cam = view->getCamera();
>>> > osg::Matrixd vm;
>>> > osg::Matrixd pm;
>>> > osg::ref_ptr vp;
>>> >
>>> > osgUtil::LineSegmentIntersector::Intersections hits;
>>> >
>>> > vDis

Re: [osg-users] multi camera rendering and pick issues

[Emmanuel Roche]

Okay...

 I think I tried everything I could think about, unsuccessfully...
unfortunately, I'm currently on WinXP with Visual Studio and for some
obscure reason, I just cannot get/use the debug symbols from some of the OSG
libraries (maybe beacuse I'm accessing those functions introspectively
though a Lua release binary ? not sure about all that...) an as a result I
cannot go deeper into those tests :-(

But I've just discovered a new fact: this is at least partially linked to
the scale of my object, I tried the following scene graph:

- the main View camera
  - my root group
- a sub camera
  - a PositionAttitudeTransform (with a scale set)
- an object

---> then depending on the scale applied in the PositionAttitudeTransform I
can pick parts of my object or not : the bigger the scale, the closer to the
object I need to be to get some intersections (and I'm not even sure those
intersections are correct...). So could there be a scale factor not applied
somewhere ?? Or maybe, since my main camera renders no objects its near/far
planes are set to minimal values and then those settings are not modified
accordingly when going though a sub camera in an intersectionVisitor [this
could explain why I cannot select objects if I'm not very very close to them
(and depending on their scale)...] ?

Is there an other way to render Univers scale + high precision scenes
without using multiple cameras as children ??? I did a quick test using
ClearNodes and setting the only camera left to "DO_NOT_COMPUTE_NEAR_FAR",
but the results are not good (it seems to me that the ClearNodes clear the
color buffer even when I only set the DEPTH_BUFFER_BIT mask... I really
don't get it...).

regards,
Manu.


2008/9/23 Emmanuel Roche <[EMAIL PROTECTED]>

> Hi Robert,
>
> unfortunately I don't think this an available option in my current project:
> our software is already relying quite heavily on our current
> CompositteViewer / View structure  (a view per window [using wxWidgets], a
> camera manipulator, a single scene graph that should not be cut into pieces,
> etc... and any way, I think there is a real problem here (expect if there is
> still something I missed) so I think for me (in both cases) it's important
> to solve this issue instead of just bypassing it.
>
> I hope you will find some time to give a deeper look to this thread later
> ;-), meanwhile I'm not giving up: I checked the setSceneData(node) methods
> and it's basically the same just a camera->addChild(node) call... so I may
> have the finger on something [as I expected a noticable difference]. I'll
> keep you informed.
>
> regards,
> Manu.
>
> 2008/9/23 Robert Osfield <[EMAIL PROTECTED]>
>
> Hi Manu,
>>
>> I don't have the head for complex emails or logic right now, so I
>> won't five into the details of thread.  What does jump out from speed
>> reading this email is why you don't use osgViewer::CompositeViewer
>> with multipler Views as this would totally clear up an ambiguity about
>> what camera each intersection test is made against.
>>
>> Robert.
>>
>> On Tue, Sep 23, 2008 at 5:42 PM, Emmanuel Roche
>> <[EMAIL PROTECTED]> wrote:
>> > Hello again...
>> >
>> > I did other tests, my idea was:
>> >
>> > I have a single main camera displaying a root object [an osg::Group] and
>> > this root object contains 5 or 6 osg::Camera object as direct children.
>> And
>> > those "sub cameras" contain pieces of the scene I want to display. Since
>> (I
>> > don't know why, but) using an IntersectVisitor gives completely
>> incorrect
>> > result on the main camera in that case, I decided to use my
>> > intersectionvisitor with each sub camera one by one... in that case
>> > everything should behave as if each of my sub camera was the root object
>> > when it's traversed, no ?... but the answer is: NO... :-( this case
>> doesn't
>> > seem to be the same as using a single camera containing objects as the
>> > intersection results are still completely false
>> >
>> > So my big question is now : what's the difference (from a "camera point
>> of
>> > view when it comes to intersections") between view->setSceneData(node)
>> and
>> > camera->addChild(node) ??? I keep investigating... :-) but any shortcut
>> > would really be appreciated :-).
>> >
>> > regards,
>> > Manu.
>> >
>> > PS: here is the main part of the code concerning the previous idea I
>> > mentioned if someone wants to have a look...
>> >
>> > osg::Camera* cam = view->getCamera();
>> > osg::Matrixd vm;
>> > osg::Matrixd pm;
>> > osg::ref_ptr vp;
>> >
>> > osgUtil::LineSegmentIntersector::Intersections hits;
>> >
>> > vDisplay::DisplayManager::CameraDeq& cams =
>> > vDisplay::DisplayManager::getRegisteredCameras(view);
>> > for(vDisplay::DisplayManager::CameraDeq::iterator it = cams.begin();
>> it
>> > != cams.end(); ++it) {
>> >
>> > osgUtil::LineSegmentIntersector::CoordinateFrame cf =
>> > osgUtil::Intersector::PROJECTION; //(*it)->getViewport() ?
>> > osgUtil::Intersector::

Re: [osg-users] setLODScale affecting near far planes?

[Joseanibal Colon Ramos]

Hi all,

Good, I am happy it is all clearer now, and I am sorry it wasn't enough at
first. So back to the original issue:
I observe my problem of auto-changing near/far planes when I modify the
LODScale via "camera->setLODScale(float)". This *always* happens whether
or not culling is enabled, but of course I am not affected by this problem
when culling is disabled because no matter what values my near/far planes
have, my objects do not get culled. I enable culling via:
camera->setCullingMode(getCurrent() | osg::CullSttings::near |
osg::cullS::far)  - I don't have the code in front of me but that is the
idea. The problem I encounter is that since I am culling the near/far
planes, some objects get culled from my scene if the near/far planes shift
positions automatically. Robert already explained that with my current
near/far computing settings I will get some slight changes to the near/far
planes when changing the LODScale. Although this is undesirable for my
application, it makes sense given Robert's earlier explanation. So Paul
asks, what if I just keep the original culling mode? Well, that would be
great, it looks great and I don't have the culling problem of the changing
near/far planes, but there is one *crucial* issue: frame-rate. My terrain
is too large and I need a decent level of detail, but it winds up drawing
way too many triangles. I am attempting to find the optimal LODScale for
my app, which can get me up from 10fps to about 25-30fps at a decent
LODScale, and I also want to cull all those extra triangles, which can
pump me up to 40-50 fps, at the cost of culling objects when not desired.
I think I'll be alright, I need to play some more with the near/far
compute settings. Thanks all for your interest in this topic,

-Jose

On Mon, September 22, 2008 10:52 am, Paul Martz wrote:
>> FYI, Roland is correct, the OSG just does culling on sides of
>> the frustum by default.
>>
>> OpenGL does no culling, is just does near and far *clipping*.   The
>> OSG of course doesn't change this so will do near/far
>> clipping and the only way to switch this off is to disable
>> GL_DEPTH_TEST.
>
> Even that won't work; DEPTH_TEST is a fragment op, and clipping against
> the
> clip planes is done before rasterization.
>
>> It would seem that Paul and Gordon have confused the clipping
>> and culling a little.
>
> Yes, I thought the original poster was talking about enabling OpenGL
> near/far clipping (probably because I have seen so many newbies ask how to
> disable this in the OpenGL forums and newsgroups). Clearly, the original
> poster said "culling"... My mistake, and thanks to all for the
> clarification.
>
> Back to the original issue:
>
> So, you see this problem when you enable OSG culling for near/far. What
> happens if you leave this disabled (as osgviewer does)?
>-Paul
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>


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

Re: [osg-users] [osg-submissions] View Dependent Shadow maps ( LispSM)

[Adrian Egli OpenSceneGraph (3D)]

Sorry, answered to  wrong list
but here i am right :-)


Hi all,

great algorithm. i have just one question. my scene has a lof of lighs, but
only one should cast shadows. so would it be possible to add a method like
in parallel splitted shadow map to tell the algorithm witch light it should
be used for shadow casting.

please have a short look at :
_ParallelSplitShadowMap->setUserLight(m_sun.get());

this method allow to tell the sun light. :-) for example

adrian





2008/9/23 Adrian Egli OpenSceneGraph (3D) <[EMAIL PROTECTED]>

> Hi all,
>
> great algorithm. i have just one question. my scene has a lof of lighs, but
> only one should cast shadows. so would it be possible to add a method like
> in parallel splitted shadow map to tell the algorithm witch light it should
> be used for shadow casting.
>
> please have a short look at :
> _ParallelSplitShadowMap->setUserLight(m_sun.get());
>
> this method allow to tell the sun light. :-) for example
>
> adrian
>
>
> 2008/9/23 Wojciech Lewandowski <[EMAIL PROTECTED]>
>
> Many Thanks Robert,
>>
>>  I've evaluated so far, it has an occasional glitch on the shadow with
>>> it disappearing for parts of the scene occasionally, hopefully many
>>> eye balls will be able to help resolve this.
>>>
>>
>> I saw this issue. I have not checked exactly what will solve it - but
>> expect that it may be related to coarse computation of scene bounds.
>> I would guess that switch from default --DrawBounds  to --CullBounds will
>> do this.
>>
>> Other hypothesis is that extending light casting margin around computed
>> scene bounds could help. --minLightMargin 20 option could be used for that.
>>
>> When I have more time I will work on some further additions. I have few
>> ideas in my sleeve: trapezoidal shadow map and lispsm using not predefined
>> formula but implementing numerical solution to shadow texel to pixel
>> equation.
>>
>> Cheers,
>> Wojtek
>>
>>
>>
>> ___
>> osg-submissions mailing list
>> [EMAIL PROTECTED]
>>
>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>>
>
>
>
> --
> 
> Adrian Egli
>



-- 

Adrian Egli
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgviewerQT --QOSGWidget cannot create context?

[Jean-Sébastien Guay]

Hi Martin,


But I get a window with no toolbars, not sure if this is related


Does the osgviewerQT add any toolbars? I didn't see anything either, but 
looking at the code I don't see it adding anything to the window other 
than the 3D display widget.


J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] osgviewerQT --QOSGWidget cannot create context?

[mgb]

I hit the same problem,
setting traits->setInheritedWindowPixelFormat to true to force it to call 
GraphicsWindowWin32::SetPixelformat()displays the file correctly

But I get a window with no toolbars, not sure if this is related

Martin

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

Re: [osg-users] Extracting embedded Textures

[Evans, Frank]

Thanks once again for the incredibly fast response. Up to now I've been
using the OsgDotNet wrappers, so writing a Custom Visitor class means
maintaining and updating the wrappers as well. At least, if I understand
the solution correctly. I will of course make every effort to leverage
the native loader.



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Tuesday, September 23, 2008 12:53 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Extracting embedded Textures


On Tue, Sep 23, 2008 at 5:45 PM, Evans, Frank <[EMAIL PROTECTED]> wrote:
> Thanks Robert, grinding through the learning curve now. Getting to the
> vertices was easy (getVertexArray). Was looking for something similar
> for image/textures.

It's straight forward, just look at the NodeVisitor examples I
mentioned.

> Is there any documentation on the IVE format? A spec file?

No there is no spec file, it is not meant to be read in a non native
way like an interchanges format such Collada.

Given you have a perfectly serviceable loader it'd be madness to try
and read it by hand, please just use my suggestion.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] multi camera rendering and pick issues

[Emmanuel Roche]

Hi Robert,

unfortunately I don't think this an available option in my current project:
our software is already relying quite heavily on our current
CompositteViewer / View structure  (a view per window [using wxWidgets], a
camera manipulator, a single scene graph that should not be cut into pieces,
etc... and any way, I think there is a real problem here (expect if there is
still something I missed) so I think for me (in both cases) it's important
to solve this issue instead of just bypassing it.

I hope you will find some time to give a deeper look to this thread later
;-), meanwhile I'm not giving up: I checked the setSceneData(node) methods
and it's basically the same just a camera->addChild(node) call... so I may
have the finger on something [as I expected a noticable difference]. I'll
keep you informed.

regards,
Manu.

2008/9/23 Robert Osfield <[EMAIL PROTECTED]>

> Hi Manu,
>
> I don't have the head for complex emails or logic right now, so I
> won't five into the details of thread.  What does jump out from speed
> reading this email is why you don't use osgViewer::CompositeViewer
> with multipler Views as this would totally clear up an ambiguity about
> what camera each intersection test is made against.
>
> Robert.
>
> On Tue, Sep 23, 2008 at 5:42 PM, Emmanuel Roche
> <[EMAIL PROTECTED]> wrote:
> > Hello again...
> >
> > I did other tests, my idea was:
> >
> > I have a single main camera displaying a root object [an osg::Group] and
> > this root object contains 5 or 6 osg::Camera object as direct children.
> And
> > those "sub cameras" contain pieces of the scene I want to display. Since
> (I
> > don't know why, but) using an IntersectVisitor gives completely incorrect
> > result on the main camera in that case, I decided to use my
> > intersectionvisitor with each sub camera one by one... in that case
> > everything should behave as if each of my sub camera was the root object
> > when it's traversed, no ?... but the answer is: NO... :-( this case
> doesn't
> > seem to be the same as using a single camera containing objects as the
> > intersection results are still completely false
> >
> > So my big question is now : what's the difference (from a "camera point
> of
> > view when it comes to intersections") between view->setSceneData(node)
> and
> > camera->addChild(node) ??? I keep investigating... :-) but any shortcut
> > would really be appreciated :-).
> >
> > regards,
> > Manu.
> >
> > PS: here is the main part of the code concerning the previous idea I
> > mentioned if someone wants to have a look...
> >
> > osg::Camera* cam = view->getCamera();
> > osg::Matrixd vm;
> > osg::Matrixd pm;
> > osg::ref_ptr vp;
> >
> > osgUtil::LineSegmentIntersector::Intersections hits;
> >
> > vDisplay::DisplayManager::CameraDeq& cams =
> > vDisplay::DisplayManager::getRegisteredCameras(view);
> > for(vDisplay::DisplayManager::CameraDeq::iterator it = cams.begin();
> it
> > != cams.end(); ++it) {
> >
> > osgUtil::LineSegmentIntersector::CoordinateFrame cf =
> > osgUtil::Intersector::PROJECTION; //(*it)->getViewport() ?
> > osgUtil::Intersector::WINDOW : osgUtil::Intersector::PROJECTION;
> > osg::ref_ptr< osgUtil::LineSegmentIntersector > picker = new
> > osgUtil::LineSegmentIntersector(cf, x, y);
> >
> > //osgUtil::IntersectionVisitor iv(picker.get());
> > vOGL::ExtendedIntersectionVisitor iv(picker.get());
> > iv.setTraversalMask(0x);
> >
> > // Reconfigure the camera:
> > vm = (*it)->getViewMatrix();  // these are actually identity
> > matrices as only the main camera is manipulated
> > pm = (*it)->getProjectionMatrix();
> > vp = (*it)->getViewport();
> >
> > (*it)->setViewMatrix(cam->getViewMatrix());
> > (*it)->setProjectionMatrix(cam->getProjectionMatrix());
> > (*it)->setViewport(cam->getViewport());
> >
> > if ((*it)->getViewport()) iv.pushWindowMatrix(
> (*it)->getViewport()
> > );
> > iv.pushProjectionMatrix( new
> > osg::RefMatrix((*it)->getProjectionMatrix()) );
> > iv.pushViewMatrix( new osg::RefMatrix((*it)->getViewMatrix()) );
> > iv.pushModelMatrix( new osg::RefMatrix() );
> >
> > (*it)->accept(iv);
> >
> > iv.popModelMatrix();
> > iv.popViewMatrix();
> > iv.popProjectionMatrix();
> > if ((*it)->getViewport()) iv.popWindowMatrix();
> >
> > (*it)->setViewMatrix(vm);
> > (*it)->setProjectionMatrix(pm);
> > (*it)->setViewport(vp.get());
> >
> > if (picker->containsIntersections())
> > {
> > hits = picker->getIntersections();
> > vLog::logInfo("Got %d intersections",hits.size());
> > return true;
> > }
> > }
> >
> >
> >
> >
> > 2008/9/23 Emmanuel Roche <[EMAIL PROTECTED]>
> >>
> >> Hi everyone,
> >>
> >> I have an interesting issue here:
> >>
> >> I'm building a scene this way (the following is a lua script 

Re: [osg-users] Build problems with osgviewerFLTK (OSG 2.6.0)

[Cliff Taylor]

Hey guys,
   I moved to a new development box with openSUSE 11.0 (x86_64), so I
had to rebuild OpenSceneGraph.  This time, I decided to use ccmake and
edit the configuration to build the documentation and support for some
more libraries.  I ran into some trouble when it tries to build
osgviewerFLTK.o.  I could have removed the library paths for FLTK in
my config, but I thought it might be a build issue you'd like to know
about.

The problem seems to stem from the include/osg/Math file.  Adding
#include  makes it build correctly on my system, but that's
probably not completely portable.  I am building from the stable
release 2.6.0 (zip) from the osg project page with g++-4.3 as my CXX.

I also had the same problem as this posting on osg-submission, which
manually adding Robert's changes fixed:
http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph.org/2008-September/002216.html

I assume this issue stems from the same strictness in gcc/g++.

Info for debugging follows if you need it

-- Cliff T.
--

Here's my gcc config:
#
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--program-suffix=-4.3 --enable-version-specific-runtime-libs
--enable-linux-futex --without-system-libunwind --with-cpu=generic
--build=x86_64-suse-linux
Thread model: posix
gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision
135036] (SUSE Linux)
##

I know it's prerelease, but I don't think it's an error in gcc.

Here's the compiler output for the failed build (sorry it's so long,
but I want to be thorough):
##
[ 98%] Building CXX object
examples/osgviewerFLTK/CMakeFiles/example_osgviewerFLTK.dir/osgviewerFLTK.o
In file included from /home/ctaylor/lib/osg/include/osg/Vec2f:17,
 from /home/ctaylor/lib/osg/include/osg/Vec2:17,
 from /home/ctaylor/lib/osg/include/osg/Array:19,
 from /home/ctaylor/lib/osg/include/osg/Uniform:22,
 from /home/ctaylor/lib/osg/include/osg/StateSet:21,
 from /home/ctaylor/lib/osg/include/osg/Node:19,
 from /home/ctaylor/lib/osg/include/osg/NodeVisitor:17,
 from /home/ctaylor/lib/osg/include/osgGA/EventVisitor:17,
 from /home/ctaylor/lib/osg/include/osgViewer/Viewer:18,
 from
/home/ctaylor/lib/osg/examples/osgviewerFLTK/osgviewerFLTK.cpp:23:
/home/ctaylor/lib/osg/include/osg/Math: In function 'float osg::round(float)':
/home/ctaylor/lib/osg/include/osg/Math:194: error: 'floorf' was not
declared in this scope
/home/ctaylor/lib/osg/include/osg/Math:194: error: 'ceilf' was not
declared in this scope
/home/ctaylor/lib/osg/include/osg/Math: In function 'double osg::round(double)':
/home/ctaylor/lib/osg/include/osg/Math:195: error: 'floor' was not
declared in this scope
/home/ctaylor/lib/osg/include/osg/Math:195: error: 'ceil' was not
declared in this scope
/home/ctaylor/lib/osg/include/osg/Math: In function 'bool osg::isNaN(float)':
/home/ctaylor/lib/osg/include/osg/Math:206: error: 'isnan' was not
declared in this scope
/home/ctaylor/lib/osg/include/osg/Math: In function 'bool osg::isNaN(double)':
/home/ctaylor/lib/osg/include/osg/Math:207: error: 'isnan' was not
declared in this scope
In file included from /home/ctaylor/lib/osg/include/osg/Vec2:17,
 from /home/ctaylor/lib/osg/include/osg/Array:19,
 from /home/ctaylor/lib/osg/include/osg/Uniform:22,
 from /home/ctaylor/lib/osg/include/osg/StateSet:21,
 from /home/ctaylor/lib/osg/include/osg/Node:19,
 from /home/ctaylor/lib/osg/include/osg/NodeVisitor:17,
 from /home/ctaylor/lib/osg/include/osgGA/EventVisitor:17,
 from /home/ctaylor/lib/osg/include/osgViewer/Viewer:18,
 from
/home/ctaylor/lib/osg/examples/osgviewerFLTK/osgviewerFLTK.cpp:23:
/home/ctaylor/lib/osg/include/osg/Vec2f: In member function 'float
osg::Vec2f::length() const':
/home/ctaylor/lib/osg/include/osg/Vec2f:147: error: 'sqrtf' was not
declared in this scope
In file included from /home/ctaylor/lib/osg/include/osg/Vec3:17,
 from /home/ctaylor/lib/osg/include/osg/Array:20,
 from /home/ctaylor/lib/osg/include/osg/Uniform:22,
 from /home/ctaylo

Re: [osg-users] Best method for screencapture in OSG?

[Jean-Sébastien Guay]

Hello Stephen,


Can any give insight into the benefits of the different means of getting a
screen capture that can be transferred back to CPU/main memory?
The app uses OSG to model a camera on the network and streams jpeg images
at a target of 30Hz to client nodes.


I don't know the details, but as I understand the osgscreencapture 
example (which you should have in your OSG 2.6+ source tree) is designed 
to be a testbed for doing something similar to what you describe.


The osgViewer::ScreenCaptureHandler which I submitted (also in 2.6) was 
based on that example, but extended to give access to a user-overridable 
ScreenCaptureOperation which could do anything with the captured image - 
the default is to save the image to the disk but it could be to send it 
to a remote machine... So at a high level, you could use this handler.


The only problem I can see with using the ScreenCaptureHandler in your 
case is that it will remove itself after having captured a frame. It was 
designed to take screenshots based on a key press, for example, so that 
seemed a sensible thing to do. In your case, you would need to capture 
all frames, so the callback shouldn't remove itself. It would be simple 
to extend the handler to have a "remove after capture" Boolean flag.


I think it could also be extended to specify which buffer to capture 
(color, depth, ...) but I'm not sure.


This doesn't address your lower-level questions, and I'm not the best 
placed to answer them since I just took what Robert had done in the 
osgscreencapture handler and refactored it to be an event handler. 
Perhaps others will have better answers.


Hope this helps,

J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Extracting embedded Textures

[Robert Osfield]

On Tue, Sep 23, 2008 at 5:45 PM, Evans, Frank <[EMAIL PROTECTED]> wrote:
> Thanks Robert, grinding through the learning curve now. Getting to the
> vertices was easy (getVertexArray). Was looking for something similar
> for image/textures.

It's straight forward, just look at the NodeVisitor examples I mentioned.

> Is there any documentation on the IVE format? A spec file?

No there is no spec file, it is not meant to be read in a non native
way like an interchanges format such Collada.

Given you have a perfectly serviceable loader it'd be madness to try
and read it by hand, please just use my suggestion.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Best method for screencapture in OSG?

[Robert Osfield]

Hi Stephen,

Have a look at the osgscreencapture example for efficient streaming of
rendered images to the CPU.

Robert.

On Tue, Sep 23, 2008 at 5:44 PM,  <[EMAIL PROTECTED]> wrote:
>
> I need to update an OSG based app that performs screen capture.  The
> existing app used OSG 1.x and readPixels.  It worked but I would like to
> move to 2.6+ and improve efficiency.  I am looking into the alternatives,
> but don't currently have the target hardware.
>
> Can any give insight into the benefits of the different means of getting a
> screen capture that can be transferred back to CPU/main memory?
> The app uses OSG to model a camera on the network and streams jpeg images
> at a target of 30Hz to client nodes.
>
> I have looked at the old and new prerender example (the existing app is
> largely based on the 1.x version of prerender).
> I have researched Frame Buffers, FBOs, PBOs, and the traditional
> readPixels.  Which of these is likely to be best for the described use?
> Is this complicated at all if this is done using MPV which uses OSG with
> SDL?
>
> I have searched Google and the mailing list archives, read the FAQ, and
> read "How-to-ask Questions the Smart Way", but have yet to find an answer I
> understand.
>
> We also have a somewhat different usecase which grabs the depth buffer
> (again with readPixels) from an orthographic projection above the current
> location on the terrain.  We use the depth buffer image and the linear
> scale of the ortho projection to convert to distance/height values.  This
> provides image width*height number of samples quite quickly, which we then
> have any system memory.  We currently process this on the CPU and send
> terrain elevation information to a separate dynamics app (potentially on a
> different machine).  I am starting to investigate what could be done on the
> GPU to improve this process.
>
> Thanks for any tips.
>
> Stephen Haithcock
> General Dynamics Land Systems
> 38500 Mound Rd.
> Sterling Heights, MI 48310
> MZ 436-40-15
> (586) 825-8573
>
>
>
>
> This is an e-mail from General Dynamics Land Systems. It is for the intended 
> recipient only and may contain confidential and privileged information.  No 
> one else may read, print, store, copy, forward or act in reliance on it or 
> its attachments.  If you are not the intended recipient, please return this 
> message to the sender and delete the message and any attachments from your 
> computer. Your cooperation is appreciated.
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] multi camera rendering and pick issues

[Robert Osfield]

Hi Manu,

I don't have the head for complex emails or logic right now, so I
won't five into the details of thread.  What does jump out from speed
reading this email is why you don't use osgViewer::CompositeViewer
with multipler Views as this would totally clear up an ambiguity about
what camera each intersection test is made against.

Robert.

On Tue, Sep 23, 2008 at 5:42 PM, Emmanuel Roche
<[EMAIL PROTECTED]> wrote:
> Hello again...
>
> I did other tests, my idea was:
>
> I have a single main camera displaying a root object [an osg::Group] and
> this root object contains 5 or 6 osg::Camera object as direct children. And
> those "sub cameras" contain pieces of the scene I want to display. Since (I
> don't know why, but) using an IntersectVisitor gives completely incorrect
> result on the main camera in that case, I decided to use my
> intersectionvisitor with each sub camera one by one... in that case
> everything should behave as if each of my sub camera was the root object
> when it's traversed, no ?... but the answer is: NO... :-( this case doesn't
> seem to be the same as using a single camera containing objects as the
> intersection results are still completely false
>
> So my big question is now : what's the difference (from a "camera point of
> view when it comes to intersections") between view->setSceneData(node) and
> camera->addChild(node) ??? I keep investigating... :-) but any shortcut
> would really be appreciated :-).
>
> regards,
> Manu.
>
> PS: here is the main part of the code concerning the previous idea I
> mentioned if someone wants to have a look...
>
> osg::Camera* cam = view->getCamera();
> osg::Matrixd vm;
> osg::Matrixd pm;
> osg::ref_ptr vp;
>
> osgUtil::LineSegmentIntersector::Intersections hits;
>
> vDisplay::DisplayManager::CameraDeq& cams =
> vDisplay::DisplayManager::getRegisteredCameras(view);
> for(vDisplay::DisplayManager::CameraDeq::iterator it = cams.begin(); it
> != cams.end(); ++it) {
>
> osgUtil::LineSegmentIntersector::CoordinateFrame cf =
> osgUtil::Intersector::PROJECTION; //(*it)->getViewport() ?
> osgUtil::Intersector::WINDOW : osgUtil::Intersector::PROJECTION;
> osg::ref_ptr< osgUtil::LineSegmentIntersector > picker = new
> osgUtil::LineSegmentIntersector(cf, x, y);
>
> //osgUtil::IntersectionVisitor iv(picker.get());
> vOGL::ExtendedIntersectionVisitor iv(picker.get());
> iv.setTraversalMask(0x);
>
> // Reconfigure the camera:
> vm = (*it)->getViewMatrix();  // these are actually identity
> matrices as only the main camera is manipulated
> pm = (*it)->getProjectionMatrix();
> vp = (*it)->getViewport();
>
> (*it)->setViewMatrix(cam->getViewMatrix());
> (*it)->setProjectionMatrix(cam->getProjectionMatrix());
> (*it)->setViewport(cam->getViewport());
>
> if ((*it)->getViewport()) iv.pushWindowMatrix( (*it)->getViewport()
> );
> iv.pushProjectionMatrix( new
> osg::RefMatrix((*it)->getProjectionMatrix()) );
> iv.pushViewMatrix( new osg::RefMatrix((*it)->getViewMatrix()) );
> iv.pushModelMatrix( new osg::RefMatrix() );
>
> (*it)->accept(iv);
>
> iv.popModelMatrix();
> iv.popViewMatrix();
> iv.popProjectionMatrix();
> if ((*it)->getViewport()) iv.popWindowMatrix();
>
> (*it)->setViewMatrix(vm);
> (*it)->setProjectionMatrix(pm);
> (*it)->setViewport(vp.get());
>
> if (picker->containsIntersections())
> {
> hits = picker->getIntersections();
> vLog::logInfo("Got %d intersections",hits.size());
> return true;
> }
> }
>
>
>
>
> 2008/9/23 Emmanuel Roche <[EMAIL PROTECTED]>
>>
>> Hi everyone,
>>
>> I have an interesting issue here:
>>
>> I'm building a scene this way (the following is a lua script using
>> osgIntrospection to manipulate OSG stuff) :
>>
>> local root = osg.Group()
>> root:setName("Universe")
>>
>> -- we want to add this root object as a scene in the current project
>> (otherwise it will never be found)
>> -- this root object will be assigned as the scenedata for the master
>> camera.
>> local proj = vProj.ProjectManager.instance():getCurrent()
>> proj:add_Scene(root)
>>
>> local view = vDisplay.DisplayManager.getViewer():getView(0)  -- here,
>> getViewer() returns our osgViewer::CompositeViewer object
>> local manip =
>> reflection.cast(view:getCameraManipulator(),"vGA::ArcBallManipulator")
>>
>> -- now create the LTS project:
>> require('LTS')
>>
>> local cam = view:getCamera()  -- this is the "main" camera, the scene data
>> for this camera is the previously declared "root" object
>> local subcam = osg.Camera()  -- we create a sub camera than we will add to
>> the main scene (so an inderect child for the main camera...)
>> subcam:setGraphicsContext(cam:getGraphicsContext())
>> subcam:setViewport(cam:getViewport())
>> subcam:setRenderOrder(osg.Camera.RenderOrder.POST

Re: [osg-users] 2.6.1 release

[Paul Martz]

Hi all --
 
I've now made all changes to the 2.6.1 branch that I intend to make. I'd
like to open this up for testing to anyone willing to help out. Check out
2.6.1 from here:
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph
-2.6
 
See the ChangeLog for the list of post-2.6 bug fixes that I merged onto this
branch.
 
I hope to release this in the very near future, say 1 October.
 
Thanks,
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com  
+1 303 859 9466
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Extracting embedded Textures

[Evans, Frank]

Thanks Robert, grinding through the learning curve now. Getting to the
vertices was easy (getVertexArray). Was looking for something similar
for image/textures.

Is there any documentation on the IVE format? A spec file?

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Tuesday, September 23, 2008 10:28 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Extracting embedded Textures


HI Frank,

Just load the .ive file then use a custom NodeVisitor to traverse the
scene and on encoutering StateSet on the Node and Drawables check from
Texture, then the Image's attached to the Textures.   There a examples
of NodeVisitor all over the OSG, and even some that do searches for
textures.  The osgUtil::GLObjectVisitor wouldn't be a bad guide for
you.

Robert.

On Tue, Sep 23, 2008 at 3:23 PM, Evans, Frank <[EMAIL PROTECTED]> wrote:
> I need to extract the embedded textures in IVE files for use in
another
> application.
> osgconv is not an option. Need to do it programmatically via the API.
>
> 1. Is there any mechanism, direct or circuitous, for getting a handle
on an
> embedded texture in an IVE file?
> 2. Is there any spec document for the IVE format?
>
> Thanks in advance
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Best method for screencapture in OSG?

[haithcoc]

I need to update an OSG based app that performs screen capture.  The
existing app used OSG 1.x and readPixels.  It worked but I would like to
move to 2.6+ and improve efficiency.  I am looking into the alternatives,
but don't currently have the target hardware.

Can any give insight into the benefits of the different means of getting a
screen capture that can be transferred back to CPU/main memory?
The app uses OSG to model a camera on the network and streams jpeg images
at a target of 30Hz to client nodes.

I have looked at the old and new prerender example (the existing app is
largely based on the 1.x version of prerender).
I have researched Frame Buffers, FBOs, PBOs, and the traditional
readPixels.  Which of these is likely to be best for the described use?
Is this complicated at all if this is done using MPV which uses OSG with
SDL?

I have searched Google and the mailing list archives, read the FAQ, and
read "How-to-ask Questions the Smart Way", but have yet to find an answer I
understand.

We also have a somewhat different usecase which grabs the depth buffer
(again with readPixels) from an orthographic projection above the current
location on the terrain.  We use the depth buffer image and the linear
scale of the ortho projection to convert to distance/height values.  This
provides image width*height number of samples quite quickly, which we then
have any system memory.  We currently process this on the CPU and send
terrain elevation information to a separate dynamics app (potentially on a
different machine).  I am starting to investigate what could be done on the
GPU to improve this process.

Thanks for any tips.

Stephen Haithcock
General Dynamics Land Systems
38500 Mound Rd.
Sterling Heights, MI 48310
MZ 436-40-15
(586) 825-8573




This is an e-mail from General Dynamics Land Systems. It is for the intended 
recipient only and may contain confidential and privileged information.  No one 
else may read, print, store, copy, forward or act in reliance on it or its 
attachments.  If you are not the intended recipient, please return this message 
to the sender and delete the message and any attachments from your computer. 
Your cooperation is appreciated.

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

Re: [osg-users] multi camera rendering and pick issues

[Emmanuel Roche]

Hello again...

I did other tests, my idea was:

I have a single main camera displaying a root object [an osg::Group] and
this root object contains 5 or 6 osg::Camera object as direct children. And
those "sub cameras" contain pieces of the scene I want to display. Since (I
don't know why, but) using an IntersectVisitor gives completely incorrect
result on the main camera in that case, I decided to use my
intersectionvisitor with each sub camera one by one... in that case
everything should behave as if each of my sub camera was the root object
when it's traversed, no ?... but the answer is: NO... :-( this case doesn't
seem to be the same as using a single camera containing objects as the
intersection results are still completely false

So my big question is now : what's the difference (from a "camera point of
view when it comes to intersections") between view->setSceneData(node) and
camera->addChild(node) ??? I keep investigating... :-) but any shortcut
would really be appreciated :-).

regards,
Manu.

PS: here is the main part of the code concerning the previous idea I
mentioned if someone wants to have a look...

osg::Camera* cam = view->getCamera();
osg::Matrixd vm;
osg::Matrixd pm;
osg::ref_ptr vp;

osgUtil::LineSegmentIntersector::Intersections hits;

vDisplay::DisplayManager::CameraDeq& cams =
vDisplay::DisplayManager::getRegisteredCameras(view);
for(vDisplay::DisplayManager::CameraDeq::iterator it = cams.begin(); it
!= cams.end(); ++it) {

osgUtil::LineSegmentIntersector::CoordinateFrame cf =
osgUtil::Intersector::PROJECTION; //(*it)->getViewport() ?
osgUtil::Intersector::WINDOW : osgUtil::Intersector::PROJECTION;
osg::ref_ptr< osgUtil::LineSegmentIntersector > picker = new
osgUtil::LineSegmentIntersector(cf, x, y);

//osgUtil::IntersectionVisitor iv(picker.get());
vOGL::ExtendedIntersectionVisitor iv(picker.get());
iv.setTraversalMask(0x);

// Reconfigure the camera:
vm = (*it)->getViewMatrix();  // these are actually identity
matrices as only the main camera is manipulated
pm = (*it)->getProjectionMatrix();
vp = (*it)->getViewport();

(*it)->setViewMatrix(cam->getViewMatrix());
(*it)->setProjectionMatrix(cam->getProjectionMatrix());
(*it)->setViewport(cam->getViewport());

if ((*it)->getViewport()) iv.pushWindowMatrix( (*it)->getViewport()
);
iv.pushProjectionMatrix( new
osg::RefMatrix((*it)->getProjectionMatrix()) );
iv.pushViewMatrix( new osg::RefMatrix((*it)->getViewMatrix()) );
iv.pushModelMatrix( new osg::RefMatrix() );

(*it)->accept(iv);

iv.popModelMatrix();
iv.popViewMatrix();
iv.popProjectionMatrix();
if ((*it)->getViewport()) iv.popWindowMatrix();

(*it)->setViewMatrix(vm);
(*it)->setProjectionMatrix(pm);
(*it)->setViewport(vp.get());

if (picker->containsIntersections())
{
hits = picker->getIntersections();
vLog::logInfo("Got %d intersections",hits.size());
return true;
}
}




2008/9/23 Emmanuel Roche <[EMAIL PROTECTED]>

> Hi everyone,
>
> I have an interesting issue here:
>
> I'm building a scene this way (the following is a lua script using
> osgIntrospection to manipulate OSG stuff) :
>
> local root = osg.Group()
> root:setName("Universe")
>
> -- we want to add this root object as a scene in the current project
> (otherwise it will never be found)
> -- this root object will be assigned as the scenedata for the master
> camera.
> local proj = vProj.ProjectManager.instance():getCurrent()
> proj:add_Scene(root)
>
> local view = vDisplay.DisplayManager.getViewer():getView(0)  -- here,
> getViewer() returns our osgViewer::CompositeViewer object
> local manip =
> reflection.cast(view:getCameraManipulator(),"vGA::ArcBallManipulator")
>
> -- now create the LTS project:
> require('LTS')
>
> local cam = view:getCamera()  -- this is the "main" camera, the scene data
> for this camera is the previously declared "root" object
> local subcam = osg.Camera()  -- we create a sub camera than we will add to
> the main scene (so an inderect child for the main camera...)
> subcam:setGraphicsContext(cam:getGraphicsContext())
> subcam:setViewport(cam:getViewport())
> subcam:setRenderOrder(osg.Camera.RenderOrder.POST_RENDER,3) -- We post
> render this subcamera with an arbitrary order.
> subcam:setClearMask(GL.Mode.GL_DEPTH_BUFFER_BIT) -- We want to render
> Universe scale scenes that's why we introduced this multi pass system.
> root:addChild(subcam)
>
> local st = vOGL.SceneTools;
> local pat = osg.PositionAttitudeTransform()
> pat:addChild(LTS.createDoubleCraft("K1")) -- Here we create a satellit
> object
> subcam:addChild(pat) -- And we add the object to the sub camera...
>
>
> ... this scene is rendered perfectly... but now I'm trying to "pick" items
> in the scene using the implementation found in
> osgViewer

Re: [osg-users] Extracting embedded Textures

[Robert Osfield]

HI Frank,

Just load the .ive file then use a custom NodeVisitor to traverse the
scene and on encoutering StateSet on the Node and Drawables check from
Texture, then the Image's attached to the Textures.   There a examples
of NodeVisitor all over the OSG, and even some that do searches for
textures.  The osgUtil::GLObjectVisitor wouldn't be a bad guide for
you.

Robert.

On Tue, Sep 23, 2008 at 3:23 PM, Evans, Frank <[EMAIL PROTECTED]> wrote:
> I need to extract the embedded textures in IVE files for use in another
> application.
> osgconv is not an option. Need to do it programmatically via the API.
>
> 1. Is there any mechanism, direct or circuitous, for getting a handle on an
> embedded texture in an IVE file?
> 2. Is there any spec document for the IVE format?
>
> Thanks in advance….
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Extracting embedded Textures

[Evans, Frank]

I need to extract the embedded textures in IVE files for use in another
application. 
osgconv is not an option. Need to do it programmatically via the API. 

1. Is there any mechanism, direct or circuitous, for getting a handle on
an embedded texture in an IVE file?
2. Is there any spec document for the IVE format?

Thanks in advance


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

Re: [osg-users] multi camera rendering and pick issues

[Emmanuel Roche]

Okay, more information on this issue I mentioned:

I tested a scene where I have only two satellites (not too far away, the
same size) in two different sub camera (still under the main camera): in
that case, using the "Test 2" implementation [treating the camera as a
simple Group] gives correct picking results.

So now, I think the second part of the problem I have in my "normal" scene
is due to the scale difference between the objects: in the main camera, I
have a subcamera containing an "Earth" model (radius ~= 6371 units, since I
use km as unit) and in an other subcamera I have my satellite (typical size
~= 0.001 units as the satellite has a small size in meters...)

using the subcam:setClearMask(GL.Mode.GL_DEPTH_BUFFER_BIT) statement is
enough to display everything correctly even with those geant scale
differences [actually I also have a "Sun" object in an other subcamera with
real size (695 500 units :-( ), and real distance from the earth (150 000
000 units !!! ) :-S ]... maybe this can lead to an overflow of the precision
when performing the intersection tests ??? do those tests use floats or
doubles ?

regards,

Manu.



2008/9/23 Emmanuel Roche <[EMAIL PROTECTED]>

> Hi everyone,
>
> I have an interesting issue here:
>
> I'm building a scene this way (the following is a lua script using
> osgIntrospection to manipulate OSG stuff) :
>
> local root = osg.Group()
> root:setName("Universe")
>
> -- we want to add this root object as a scene in the current project
> (otherwise it will never be found)
> -- this root object will be assigned as the scenedata for the master
> camera.
> local proj = vProj.ProjectManager.instance():getCurrent()
> proj:add_Scene(root)
>
> local view = vDisplay.DisplayManager.getViewer():getView(0)  -- here,
> getViewer() returns our osgViewer::CompositeViewer object
> local manip =
> reflection.cast(view:getCameraManipulator(),"vGA::ArcBallManipulator")
>
> -- now create the LTS project:
> require('LTS')
>
> local cam = view:getCamera()  -- this is the "main" camera, the scene data
> for this camera is the previously declared "root" object
> local subcam = osg.Camera()  -- we create a sub camera than we will add to
> the main scene (so an inderect child for the main camera...)
> subcam:setGraphicsContext(cam:getGraphicsContext())
> subcam:setViewport(cam:getViewport())
> subcam:setRenderOrder(osg.Camera.RenderOrder.POST_RENDER,3) -- We post
> render this subcamera with an arbitrary order.
> subcam:setClearMask(GL.Mode.GL_DEPTH_BUFFER_BIT) -- We want to render
> Universe scale scenes that's why we introduced this multi pass system.
> root:addChild(subcam)
>
> local st = vOGL.SceneTools;
> local pat = osg.PositionAttitudeTransform()
> pat:addChild(LTS.createDoubleCraft("K1")) -- Here we create a satellit
> object
> subcam:addChild(pat) -- And we add the object to the sub camera...
>
>
> ... this scene is rendered perfectly... but now I'm trying to "pick" items
> in the scene using the implementation found in
> osgViewer::View::computeIntersections(...) : If I put my "K1" object
> directly "in" the "main" camera everything is perfect, and I can pick
> intersections correctly. But when using this "subcam"  as parent then I get
> incorrect results :-( (intersections found when clicking on nothing, or no
> intersections found when cliking on sub parts of the object...)
>
> I gave a look at the osgUtil::IntersectionVisitor implementation... and I
> think everything is happening in this function:
>
> void IntersectionVisitor::apply(osg::Camera& camera)
> {
> // osg::notify(osg::NOTICE)<<"apply(Camera&)"<
> // note, commenting out right now because default Camera setup is with
> the culling active.  Should this be changed?
> // if (!enter(camera)) return;
>
> // osg::notify(osg::NOTICE)<<"inside apply(Camera&)"<
> if (camera.getViewport()) pushWindowMatrix( camera.getViewport() );
> pushProjectionMatrix( new osg::RefMatrix(camera.getProjectionMatrix())
> );
> pushViewMatrix( new osg::RefMatrix(camera.getViewMatrix()) );
> pushModelMatrix( new osg::RefMatrix() );
>
> // now push an new intersector clone transform to the new local
> coordinates
> push_clone();
>
> traverse(camera);
>
> // pop the clone.
> pop_clone();
>
> popModelMatrix();
> popViewMatrix();
> popProjectionMatrix();
> if (camera.getViewport()) popWindowMatrix();
>
> // leave();
> }
>
> I created my own "ExtendedIntersectorVisitor" (derived from this class) to
> override this function and I made multiple tests to handle the "main" camera
> and the "sub" cameras differently:
>
> void ExtendedIntersectionVisitor::apply(osg::Camera & camera) {
> if(!cameraInitialized) {
> cameraInitialized = true;
> // The first time we get a camera object we use it to setup the
> camera details normaly:
>
> if (camera.getViewport()) pushWindowMatrix( camera.getViewport() );
> pushProjectionMatrix( new
> osg::RefMatrix(camera.getProjec

[osg-users] multi camera rendering and pick issues

[Emmanuel Roche]

Hi everyone,

I have an interesting issue here:

I'm building a scene this way (the following is a lua script using
osgIntrospection to manipulate OSG stuff) :

local root = osg.Group()
root:setName("Universe")

-- we want to add this root object as a scene in the current project
(otherwise it will never be found)
-- this root object will be assigned as the scenedata for the master camera.
local proj = vProj.ProjectManager.instance():getCurrent()
proj:add_Scene(root)

local view = vDisplay.DisplayManager.getViewer():getView(0)  -- here,
getViewer() returns our osgViewer::CompositeViewer object
local manip =
reflection.cast(view:getCameraManipulator(),"vGA::ArcBallManipulator")

-- now create the LTS project:
require('LTS')

local cam = view:getCamera()  -- this is the "main" camera, the scene data
for this camera is the previously declared "root" object
local subcam = osg.Camera()  -- we create a sub camera than we will add to
the main scene (so an inderect child for the main camera...)
subcam:setGraphicsContext(cam:getGraphicsContext())
subcam:setViewport(cam:getViewport())
subcam:setRenderOrder(osg.Camera.RenderOrder.POST_RENDER,3) -- We post
render this subcamera with an arbitrary order.
subcam:setClearMask(GL.Mode.GL_DEPTH_BUFFER_BIT) -- We want to render
Universe scale scenes that's why we introduced this multi pass system.
root:addChild(subcam)

local st = vOGL.SceneTools;
local pat = osg.PositionAttitudeTransform()
pat:addChild(LTS.createDoubleCraft("K1")) -- Here we create a satellit
object
subcam:addChild(pat) -- And we add the object to the sub camera...


... this scene is rendered perfectly... but now I'm trying to "pick" items
in the scene using the implementation found in
osgViewer::View::computeIntersections(...) : If I put my "K1" object
directly "in" the "main" camera everything is perfect, and I can pick
intersections correctly. But when using this "subcam"  as parent then I get
incorrect results :-( (intersections found when clicking on nothing, or no
intersections found when cliking on sub parts of the object...)

I gave a look at the osgUtil::IntersectionVisitor implementation... and I
think everything is happening in this function:

void IntersectionVisitor::apply(osg::Camera& camera)
{
// osg::notify(osg::NOTICE)<<"apply(Camera&)"< matrix = _modelStack.empty() ? new
osg::RefMatrix() : new osg::RefMatrix(*_modelStack.back());
camera.computeLocalToWorldMatrix(*matrix,this);

pushModelMatrix(matrix.get());

// now push an new intersector clone transform to the new local
coordinates
push_clone();

traverse(camera);

// pop the clone.
pop_clone();

popModelMatrix();

// tidy up an cached cull variables in the current intersector.
leave();
   // End of Test 1

   // Test 2: treat the camera as a osg::Group only!
if (!enter(*(camera.asGroup( return;

traverse(*(camera.asGroup()));

leave();
   // End of test 2

   // Test 3: just try not to push the model matrix, view matrix,
projection or viewport, one by one:

if (camera.getViewport()) pushWindowMatrix( camera.getViewport() );
pushProjectionMatrix( new
osg::RefMatrix(camera.getProjectionMatrix()) );
pushViewMatrix( new osg::RefMatrix(camera.getViewMatrix()) );
//pushModelMatrix( new osg::RefMatrix() );

// now push an new intersector clone transform to the new local
coordinates
push_clone();

traverse(camera);

// pop the clone.
pop_clone();

//popModelMatrix();
popViewMatrix();
popProjectionMatrix();
if (camera.getViewport()) popWindowMatrix();
// End of Test 3
}
}


.. But none of this tests gave interesting result :-(... I really don't know
where this problem may comes from then, and I really need to be able to pick
objects in a Camera containing other sub cameras :-S. Do you have any clue
about all that ? What am I doing wrong ?

regards,
Manu.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Widget and Exception

[Julen García]

Hello,

I have downloaded the 2.6 version and I'm trying to add widget components to my 
project. All is ok but when I pass the mouse on a 3D object of my scene, an 
exception occurs

I use this function to start my project

return osgWidget::createExample(viewer, wm, myScene->getScene());

That is ok? If I use return osgWidget::createExample(viewer, wm); my scene 
doesn't appears. I've tried to call first 
viewer.setSceneData(myScene->getScene()); but it doesn't work.

Thanks in advance



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

Re: [osg-users] Spatial View SVI autosteroscopic display

[Chris Denham]

Hi Steffen,
Thanks very much for the info. It did seem to me as though finding the right 
place to call the API from was the key issue, so your suggestion for using 
Postrender-CameraCallback is very useful. I was beginning to think along the 
lines of implementing a Drawable::drawImplementation() function, which is 
interesting because I notice the osgteapot example does that.
However, looking at osgteapot example from OSG2.6, it doesn't seem to do 
anything with camera callbacks, so I am a bit puzzled as to exactly what you 
mean here. I found a couple of other examples that use 
Camera::setPostDrawCallback, so I will have a look at them too.Which version 
of OSG did you use for this? Have names & examples changed since you did 
your integration?

Regards.
Chris.



Date: Mon, 22 Sep 2008 22:01:20 +0200
From: Steffen Kim <[EMAIL PROTECTED]>
Subject: Re: [osg-users] Spatial View SVI autosteroscopic display
support.
To: osg-users@lists.openscenegraph.org
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=iso-8859-15

Hi Chris.

I spent quite some time on doing just what you are planning to do - 
getting an OpenSceneGraph-application to work with a Spatial View display. 
In the end I was successful.
I don't know at the moment if I can provide you with any code but of 
course I can tell you how I am doing it. I have no idea if this is the 
best way but it works quite well.


I use 5 RTT-cameras to save the five views in textures that later become 
input for the interlacer. You can position these 5 cameras using the SVI 
camera API or calculate the view and projection matrixes yourself. You 
then let the SVI interlacer render the result from the 5 textures. 
Everytime the master camera (the main osg camera) changes you also have to 
recalculate the matrixes of your slave cameras. The important part is that 
you take care on when you do call the API functions. You have to do this 
in a part of your program where the OpenGL context was set accordingly by 
OSG. You can use a PostRender-CameraCallback for this. See the 
osgteapot-example for some code on how to do this.


Good luck.

Schon geh?rt? Bei WEB.DE gibt' s viele kostenlose Spiele:
http://games.entertainment.web.de/de/entertainment/games/free/index.html



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

Re: [osg-users] ImageStream current frame

[Robert Osfield]

Hi Richard,

Chasing after PixelBufferObject usage will just waste your time on
something that really won't lead to much benefit.  What you are after
is a value that the OSG doesn't at present provide, but the OSG is
open source, so you can take the source extended it to do what you
need to do and then get these changes make into the main trunk.   The
changes will need to be to base class and the ImageStream
implementations.

Robert.

On Tue, Sep 23, 2008 at 1:28 AM, Richard Baron Penman
<[EMAIL PROTECTED]> wrote:
> thanks for the clarification about ImageStream Robert.
>
> If I understand right ImageStream buffers the frames in a PixelBufferObject
> and switches the frames in the compileBuffer() function. So if I could get
> feedback from this function then I could determine the frame count. Possibly
> the _compiledList[contextID] variable might help with this.
> Am I on the right track? Can you offer any advice?
>
> Richard
>
>
>> Hi Richard,
>>
>> These methods are virtual methods, and ImageStream is a base class...
>> that implementations subclass from, so the fact a header doesn't
>> implement something doesn't say anything about the actual
>> implementations that are meant to implement it.
>>
>> Secondly the getReferenceTime() and TimeMultiplier are an time offset
>> and multiple, that is used by the ImageStream implementations to
>> compute the current time, and not the current time of the movie.
>>
>> The actual time of the movie is something that would have to added to
>> ImageStream and its implementations, it should be possible to do this,
>> something like a getMovieTime().
>>
>> Robert.
>>
>> On Fri, Sep 19, 2008 at 6:52 AM, Richard Baron Penman
>>
>> <[EMAIL PROTECTED]> wrote:
>> > hello,
>>
>> > I would like to display what percentage of a video has been played. I'm
>> > using the ImageStream class and I thought getReferenceTime() or
>> > getTimeMultiplier() might help me, but they always return 0.
>>
>> > Examining the header file I found this:
>> > 72 virtual double getLength() const { return 0.0; }
>> > 73
>> > 74 virtual void setReferenceTime(double) {}
>> > 75 virtual double getReferenceTime() const { return 0.0; }
>> > 76
>> > 77 virtual void setTimeMultiplier(double) {}
>> > 78 virtual double getTimeMultiplier() const { return 0.0; }
>>
>> > So it seems this functionality is not ready yet. Does anyone have an
>> > alternative way to determine the current playing video frame?
>>
>> > regards,
>> > Richard
>>
>> > ___
>> > osg-users mailing list
>> > [EMAIL PROTECTED]
>> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph...
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] shared VertexBufferObject question

[Robert Osfield]

Hi Alex,

Adding back in the lazy updating of the glVertexPointer would get you
a small amount of performance, but it must have been commented out for
a reason, what I don't recall as this will have been a number of years
back.  Commenting it back in might work, but then it might come across
crashes due to the vertex pointer being reset elsewhere with
osg::State being updated to know that it was dirty.   At a guess it
might an issue with mixing display lists and vertex pointer usage.

Robert.

On Mon, Sep 22, 2008 at 7:53 PM, Pecoraro, Alexander N
<[EMAIL PROTECTED]> wrote:
> I did some reading about VBOs on the NVidia developer site and it turns
> out that the glBindBuffer() call is not the one that I should worry
> about. The white paper I read said that limiting the number of calls to
> glVertexPointer() was the proper way to optimize the use of VBOs.
>
> So I noticed that there was some commented out code in include/State
> that appeared to be for the purpose of preventing redundant calls to
> glVertexPointer() - see below:
>
> inline void setVertexPointer( GLint size, GLenum type,
>  GLsizei stride, const GLvoid *ptr
> )
> {
>   (only showing relevant parts of code)
>  //if (_vertexArray._pointer!=ptr || _vertexArray._dirty)
>  {
>_vertexArray._pointer=ptr;
>glVertexPointer( size, type, stride, ptr );
>  }
>  _vertexArray._dirty = false;
> }
>
> Seems like if the commented out IF statement was not commented out then
> I could have multiple Geometry nodes share a vertex buffer object and a
> vertex array and only require one call to glVertexPointer(). Wouldn't
> that be more efficient?
>
> Alex
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Robert
> Osfield
> Sent: Saturday, September 20, 2008 1:56 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] shared VertexBufferObject question
>
> Hi Alex,
>
> The unbind is done to prevent state leakage.  One could potentially
> using lazy state updating on VBO state by placing more controls into
> osg::State, but this would require all Drawables to be careful about
> what they assume is current state.  It's possible but it's quite a bit
> of work.
>
> Robert.
>
> On Sat, Sep 20, 2008 at 12:42 AM, Pecoraro, Alexander N
> <[EMAIL PROTECTED]> wrote:
>> I want to create a VertexBufferObject that is shared by several
> Geometry
>> nodes so that the number of calls to glBindBuffer() are decreased, but
> I
>> noticed that on lines 1561 - 1567 of Geometry.cpp there is some code
> that
>> automatically unbinds the vertex buffer object effectively forcing
> each
>> Geometry node to rebind the VBO each time. Why does it do this? Isn't
> this
>> preventing a shared VBO from being used in the most efficient way
> possible?
>>
>>
>>
>> Thanks.
>>
>>
>>
>> Alex
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>>
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
> g
>>
>>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
> g
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Ref_ptr question : argument and return

[Vincent Bourdier]

Hi Thibault

Thanks a lot, this will help me.
I understand that the ref_ptr is not needed everywhere, but sometimes it
becomes very difficult to undestand if a ref_ptr is needed or if a pointer
will be sufficient or safety.

Thanks for your help.

Regards,
   Vincent.

2008/9/23 Thibault Genessay <[EMAIL PROTECTED]>

> Hi Vincent
>
> On Mon, Sep 22, 2008 at 5:23 PM, Vincent Bourdier
> <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > I read that all the objects that inherit from Referenced need to be in a
> > ref_ptr.
>
> They don't _need_ to. You can perfectly use a raw pointer to an
> osg::Referenced instance, e.g. create a new node:
> MyNode* node = new MyNode();
> myscene->addChild(node);
> You have to be aware that if an exception is thrown (or any event that
> could cause the addChild() call to be skipped) before the node is
> added to the parent the memory will not be freed - group nodes keep
> ref_ptr<>s to their children, and once the node is added to 'myscene'
> it will be managed by the ref_ptr mechanism.
>
> The general rule is to use raw pointers only when you do trivial
> things (e.g. creating an instance provided that the constructor cannot
> throw) or when you know that your object is already referenced from
> somewhere else (e.g. like in osg::Node* node = myscene->getChild(0)).
> Use ref_ptrs as class members (*) (e.g. have a look at osg::Group) and
> when things are more complicated, especially w.r.t exceptions that
> could be thrown in the meantime.
>
> > Ok that sounds good , but :
> >
> > In this case I don't know if I need to put the ref_prt in argument or if
> > only the ptr is needed.
>
> It's not a good idea to use ref_ptr<> in arguments. If your function looks
> like
> void setFooState(ref_ptr arg) { // add the foo state to the
> node's stateset  }
> And you call it this way:
> osg::Node* node = new MyNode();
> setFooState(node);
> then a ref_ptr will be implicitly created. It will ref() the node, do
> whatever it needs to do with it and unref() it before it returns to
> the caller. Since the node was not referenced from somewhere else, it
> will be deleted and your 'node' pointer will be a dangling pointer -
> which is certainly not what you want.
>
> OTOH, if your function is defined as
> void setFooState(osg::Node* arg) {...}
> you can safely call either
> setFooState(node); if you have a raw pointer to your node
> or
> setFooState(node.get()); if you have a ref_ptr to your node
>
> Hope this helps
>
> Thibault
>
> (*) Keep in mind that your (scene) graph must be acyclic w.r.t to
> ref_ptr<>s: if A holds a ref_ptr to B then neither B nor its children
> must hold a ref_ptr to A. This is why Groups have an
> std::vector > to their children, and Nodes have an
> std::vector to their parents.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Ref_ptr question : argument and return

[Thibault Genessay]

Hi Vincent

On Mon, Sep 22, 2008 at 5:23 PM, Vincent Bourdier
<[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I read that all the objects that inherit from Referenced need to be in a
> ref_ptr.

They don't _need_ to. You can perfectly use a raw pointer to an
osg::Referenced instance, e.g. create a new node:
MyNode* node = new MyNode();
myscene->addChild(node);
You have to be aware that if an exception is thrown (or any event that
could cause the addChild() call to be skipped) before the node is
added to the parent the memory will not be freed - group nodes keep
ref_ptr<>s to their children, and once the node is added to 'myscene'
it will be managed by the ref_ptr mechanism.

The general rule is to use raw pointers only when you do trivial
things (e.g. creating an instance provided that the constructor cannot
throw) or when you know that your object is already referenced from
somewhere else (e.g. like in osg::Node* node = myscene->getChild(0)).
Use ref_ptrs as class members (*) (e.g. have a look at osg::Group) and
when things are more complicated, especially w.r.t exceptions that
could be thrown in the meantime.

> Ok that sounds good , but :
>
> In this case I don't know if I need to put the ref_prt in argument or if
> only the ptr is needed.

It's not a good idea to use ref_ptr<> in arguments. If your function looks like
void setFooState(ref_ptr arg) { // add the foo state to the
node's stateset  }
And you call it this way:
osg::Node* node = new MyNode();
setFooState(node);
then a ref_ptr will be implicitly created. It will ref() the node, do
whatever it needs to do with it and unref() it before it returns to
the caller. Since the node was not referenced from somewhere else, it
will be deleted and your 'node' pointer will be a dangling pointer -
which is certainly not what you want.

OTOH, if your function is defined as
void setFooState(osg::Node* arg) {...}
you can safely call either
setFooState(node); if you have a raw pointer to your node
or
setFooState(node.get()); if you have a ref_ptr to your node

Hope this helps

Thibault

(*) Keep in mind that your (scene) graph must be acyclic w.r.t to
ref_ptr<>s: if A holds a ref_ptr to B then neither B nor its children
must hold a ref_ptr to A. This is why Groups have an
std::vector > to their children, and Nodes have an
std::vector to their parents.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org