Re: [osg-users] Camera render order and Threading models

[Riccardo Corsi]

Hi Robert,

I've tried to reproduce the issue with a minimal example, without success
so far, even though the essential bits should be the same.
I'm also thinking it might have something to do with the data variance of
the affected geometries, I'll double check.
If I find something I'll report back here,
Thanks,
Riccardo



*Riccardo Corsi*  co-founder, software engineering
*Kairos3D srl*  Via Agostino da Montefeltro 2, 10134 Torino Italy
*T* +390113157111  *M* +393288522785

This e-mail is confidential and intended only for the use of the above
named addressee. If you have received this e-mail in error, please delete
it immediately and notify us by e-mail or telephone.


On Thu, Jan 7, 2021 at 6:45 PM Robert Osfield 
wrote:

> Hi Ricard,
>
> Both the RTT Camera and the main Camera should both be traversed in the
> cull traversal within the same frame and accumulated modelview matrices
> cached in the rendering backend to sent to the GPU as part of the draw
> traversal together.  Ordinarily this system should prevent problems like
> your describe as the rendering backend is double buffered so that the cull
> writes to the currently recording frames rendering backend, while the draw
> traverses the previous rendering backend structures.
>
> The behaviour you describe makes it seem like some state is being modified
> across the frames, I don't have your app or data so can't say what this
> might be.  The best I can suggest is to investigate what state seems to be
> changed inappropriately.  It might be that you need to double buffer the
> state that is being updated whilst it's being used for rendering.
>
> Robert
>
> --
> You received this message because you are subscribed to the Google Groups
> "OpenSceneGraph Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osg-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BWM4Cn4KooZoHxnv2nncmpHtrftT1aNEjGNnwows06OGA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAHhSftgzALxeG69w%2B1jJXuZQRxyt6NE4fBkAae%3DFtgVHdgMFgg%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Camera render order and Threading models

[Robert Osfield]

Hi Ricard,

Both the RTT Camera and the main Camera should both be traversed in the
cull traversal within the same frame and accumulated modelview matrices
cached in the rendering backend to sent to the GPU as part of the draw
traversal together.  Ordinarily this system should prevent problems like
your describe as the rendering backend is double buffered so that the cull
writes to the currently recording frames rendering backend, while the draw
traverses the previous rendering backend structures.

The behaviour you describe makes it seem like some state is being modified
across the frames, I don't have your app or data so can't say what this
might be.  The best I can suggest is to investigate what state seems to be
changed inappropriately.  It might be that you need to double buffer the
state that is being updated whilst it's being used for rendering.

Robert

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BWM4Cn4KooZoHxnv2nncmpHtrftT1aNEjGNnwows06OGA%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Camera::setLODScale not seams to work with PagedLOD

[OpenSceneGraph Users]

Hi Nick,
It's not known to be broken, and works for me on both windows and linux.
As a blind guess: you might be trying to set the LODScale on the viewer,
and we set it on the main Camera(s).
Laurens.

On Tue, Mar 31, 2020 at 11:20 PM OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> Hi Community,
>
> I have some PagedLOD database (small one, willing to share), and I can not
> make the LODScale to work, with osgviewer. Is this known to be broken? OSG
> 3.6.3 - I can update to latest, not an issue
>
>
>
> --
> trajce nikolov nick
> ___
> 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] camera functionality issue

[Robert Osfield]

On Wednesday, 22 January 2020 05:12:31 UTC, Ravi wrote:
>
> We have got the camera panning by calculating the resultant of two 
> vectors(previous vector before panning and changed vector after panning) 
> and compared its magnitude with a value to restrict its position in camera 
> view. But when we zoom in and zoom out the magnitude of the vector that 
> geometry can cover side by side changes and hence the hardcoded value is of 
> no help to us anymore.
>

I'm afraid this is pretty meaningless out of context, I can't work out what 
you are doing let alone what you might be doing wrong, or what 
understanding is missing for you.

Do you have code that you can post that illustrates what you are doing?


 

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/181ec22b-b21e-4dde-b405-92d13ca5db1d%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] camera functionality issue

[Ravi]

We have got the camera panning by calculating the resultant of two 
vectors(previous vector before panning and changed vector after panning) 
and compared its magnitude with a value to restrict its position in camera 
view. But when we zoom in and zoom out the magnitude of the vector that 
geometry can cover side by side changes and hence the hardcoded value is of 
no help to us anymore.


On Tuesday, January 21, 2020 at 7:57:53 PM UTC+5:30, Robert Osfield wrote:
>
> How far have you got?  What problems do you have?
>

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/e5468c08-d827-4226-a1d8-1b2d9eb7fc57%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] camera functionality issue

[Robert Osfield]

How far have you got?  What problems do you have?

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/fb9dad1a-856f-481d-a746-68aa16d6f6ce%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] camera functionality issue

[Robert Osfield]

Could you change you user name to a human name, it helps the community to 
converse respectively.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/701c7428-1142-4aa1-a3cc-c07838005a68%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Camera clear color

[cdp97531]

Hi OSG guys,
last setMode call is wrong.It works with/without the following 
stament:masterCamera->getOrCreateStateSet()->setMode(GL_SCISSOR_TEST, 
GL_TRUE);I am confused.Any way it works.
Best regards,Deping
- Original Message -
From: 
To: "osg-users" 
Subject: Camera clear color
Date: 2018-11-29 16:32

Hi OSG developers,
I am using OSG a lot now. OSG is great indeed.But I encountered a problem:There 
are one active master camera and one active slave camera which has its own 
scene graph.The 2 cameras shares the same GraphicsContext.Slave camera's 
viewport is contained in master camera's viewport.I want slave camera's 
viewport has a different background color, so I write:
masterCamera->setClearMask(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT);
masterCamera->setClearColor(osg::Vec4f(0.2f, 0.2f, 0.4f, 1.0f)); // blue
slaveCamera->setClearMask(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT);
slaveCamera->setClearColor(osg::Vec4f(0.4f, 0.2f, 0.2f, 1.0f)); // orange
But all view area is orange.I know glClear will clear whole color buffer.But  
GL spec says that scissor test affect the operation of glClear.After I add the 
following statement, it works:
slaveCamera->getOrCreateStateSet()->setMode(osg::StateAttribute::SCISSOR, 
osg::StateAttribute::ON);Is this a bug of OSG?
It seems that OSG has enable scissor test:void 
RenderStage::drawImplementation(osg::RenderInfo& renderInfo,RenderLeaf*& 
previous){...glScissor( static_cast(_viewport->x()),   
static_cast(_viewport->y()),   
static_cast(_viewport->width()),   
static_cast(_viewport->height()) );//cout << "clearing "y()<<","<< _viewport->width()<<","<< 
_viewport->height()<___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Camera serializer and culling

[Robert Osfield]

Hi Julien,

On 21 April 2018 at 13:16, Julien Valentin  wrote:
> Doing some RTT serialization I came into an issue:
> I just saw that only inheritedmask is the only CullSetting serialized. 
> Neither CullMode neither NearFarComputeMode
> I also set Node::ActiveCulling to false (does it even do anything) but 
> nothing do the trick: some of my Geometry are never drawn.
> If someone have an answer I would me very glad

I have the weekend off so I'm not going to dive into the OSG serialzer
implementation right now, it may well be that not all parameters are
serialized.  Some parameters are viewer centric rather than scene
graph centric so might be appropriate for serializing, I'll need to do
a full review.

Could you create a small example that illustrates the problem you are
seeing.  Thanks.

FYI, Node::setActiveCulling(bool) toggles on/off whether that node and
it ti's parents should have culling done on them during the cull
traversal.  With questions like this a quick search of osg and osgUtil
for instances of CullActive will show you how the rendering back-end
works using this bool.

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

Re: [osg-users] Camera resize vs setViewport

[Robert Osfield]

On 24 February 2017 at 15:18, Ravi Mathur  wrote:
> Thanks Robert. But still, why does resize() not accept x/y arguments? As it 
> is now, it cannot be used with CompositeViewer where Cameras are distributed 
> around the window with various Viewports. Is it just intended for use with 
> the regular osg::Viewer?

It's a resize of the window.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Camera resize vs setViewport

[Ravi Mathur]

Thanks Robert. But still, why does resize() not accept x/y arguments? As it is 
now, it cannot be used with CompositeViewer where Cameras are distributed 
around the window with various Viewports. Is it just intended for use with the 
regular osg::Viewer?


robertosfield wrote:
> Hi Ravi,
> 
> The resize is primarily for responding to window resize events where
> you need to adjust the viewport and projection matrix to provide
> sensible on screen behaviour.
> 
> The setViewport() method just sets the viewport, it doesn't try to do
> anything with any other paramters such as the projection matrix.
> 
> Robert.
> 


--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=70340#70340





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

Re: [osg-users] Camera resize vs setViewport

[Robert Osfield]

Hi Ravi,

The resize is primarily for responding to window resize events where
you need to adjust the viewport and projection matrix to provide
sensible on screen behaviour.

The setViewport() method just sets the viewport, it doesn't try to do
anything with any other paramters such as the projection matrix.

Robert.

On 24 February 2017 at 03:13, Ravi Mathur  wrote:
> Hi all,
>
> In osg::Camera, there exist two resize functions: Camera::resize(width, 
> height) and Camera::setViewport(x, y, width, height). I'm confused 
> conceptually as to when to use which one. Some examples use resize 
> (osgdistortion), whereas others use setViewport (osghud).
>
> Looking at the Camera.cpp code, it looks like resize() calls setViewport(), 
> but why does it not then accept x/y position arguments? For example, I have a 
> CompositeViewer with multiple Views. Each View has a master & slave (HUD) 
> camera, which are set up in a grid format on the GraphicsContext. I 
> initialize each master/slave combo using setViewport() but I can't use 
> Camera::resize() since I can't pass it the x/y coordinates.
>
> What am I missing here? When is it appropriate to call Camera::resize() 
> instead of Camera::setViewport()?
>
> Thanks,
> Ravi
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=70333#70333
>
>
>
>
>
> ___
> 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] Camera::resizeAttachments + texture rect

[Robert Osfield]

Hi James.

On 4 January 2017 at 17:20, James Turner  wrote:
> Hi,
>
> I have just been surprised to learn that Camera::resizeAttachments doesn’t 
> handle TextureRectangle. Would a patch to change this behaviour be accepted? 
> Or is it intentional for some reason?

I am a bit surprised as well, just looked at the code and it only all
the other main texture types... Yes a patch would be accepted :-)

> (Yes the texture coordinates have to be adjusted for a rectangular texture 
> but I still prefer that over using a 2D texture with considerable wasted 
> space)

There is no reason why there need be waster space with a Texture2D,
all modern cards will support non power of two textures, you just need
to set the Texture's ResizeNonPowerOfTwo to false to make it clear
that texture can be a non power of two.

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

Re: [osg-users] camera far plane culling issues

[Trajce Nikolov NICK]

Ah ok .. That makes sense then .. Thanks Robert

On Mon, Oct 17, 2016 at 9:46 AM, Robert Osfield 
wrote:

> HI Nick,
>
> Culling works on the bound volumes of objects so if the objects have
> any point of their bounding box/sphere the eye side of the far plan
> they won't be culled.
>
> Robert.
>
> On 16 October 2016 at 23:31, Trajce Nikolov NICK
>  wrote:
> > Hi Commuity,
> >
> > I have RTT camera and for some reason the culling is not working as
> > expected. Here is the code:
> >
> > camera->setProjectionMatrixAsPerspective(70, 1, 5, 10);
> > camera->setCullingMode(osg::CullSettings::FAR_PLANE_CULLING);
> > camera->setComputeNearFarMode(osg::CullSettings::DO_NOT_
> COMPUTE_NEAR_FAR);
> >
> > I am still seeing far behind these 10m
> >
> > Any hints?
> >
> > --
> > trajce nikolov nick
> >
> > ___
> > 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
>



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

Re: [osg-users] camera far plane culling issues

[Robert Osfield]

HI Nick,

Culling works on the bound volumes of objects so if the objects have
any point of their bounding box/sphere the eye side of the far plan
they won't be culled.

Robert.

On 16 October 2016 at 23:31, Trajce Nikolov NICK
 wrote:
> Hi Commuity,
>
> I have RTT camera and for some reason the culling is not working as
> expected. Here is the code:
>
> camera->setProjectionMatrixAsPerspective(70, 1, 5, 10);
> camera->setCullingMode(osg::CullSettings::FAR_PLANE_CULLING);
> camera->setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR);
>
> I am still seeing far behind these 10m
>
> Any hints?
>
> --
> trajce nikolov nick
>
> ___
> 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] camera pre-render and culling order

[Trajce Nikolov NICK]

Thanks for the clarification Robert!

Nick

On Sat, Sep 10, 2016 at 6:27 PM, Robert Osfield 
wrote:

> Hi Nick,
>
> On 10 September 2016 at 11:47, Trajce Nikolov NICK
>  wrote:
> > anyone knows what is the order of the camera pre-render and the cull
> > traversal in a frame?
>
> Cull and Draw are separate and for the same frame always done in the
> order Cull then Draw.  Draw contains all pre rendering, main rendering
> and post rendering stages.
>
> If there are multiple Camera's on a GraphicsContext/Window then the
> Cull and Draw for the different Camera's can be interleaved, depending
> on the threading model, but always for a single Camera the cull
> traversal of it's subgraph is always done before the rendering for
> that subgraph.
>
> This has to happen this way as it's the cull traversal that decides
> what goes into a draw traversal.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] camera pre-render and culling order

[Robert Osfield]

Hi Nick,

On 10 September 2016 at 11:47, Trajce Nikolov NICK
 wrote:
> anyone knows what is the order of the camera pre-render and the cull
> traversal in a frame?

Cull and Draw are separate and for the same frame always done in the
order Cull then Draw.  Draw contains all pre rendering, main rendering
and post rendering stages.

If there are multiple Camera's on a GraphicsContext/Window then the
Cull and Draw for the different Camera's can be interleaved, depending
on the threading model, but always for a single Camera the cull
traversal of it's subgraph is always done before the rendering for
that subgraph.

This has to happen this way as it's the cull traversal that decides
what goes into a draw traversal.

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

Re: [osg-users] Camera track one node with respect to another node

[Robert Osfield]

Hi Jay,

There isn't an osgGA::CameraManipulator for doing specifically what you
want so you'll need to write your own CameraManipulator to do this or
simply set the viewer's Camera's view matrix each frame within the frame
loop.  This shouldn't be difficult, the OSG has Matrix/Vec3 classes to help
with maths.  All you need to do is find the position of the two nodes you
want to track, computer their position in world coordinates using the
osg::computeLocalToWorldMatrix(nodePath) and their local center of interest
that you want to use, then do the maths you want to derive the view matrix
and apply this per frame.

Robert.

On 19 February 2015 at 00:01, Jay Loid foboi1...@hotmail.com wrote:

 I'm just starting to play around with openscenegraph and I'd like to know
 if what I'm describing is possible. I have two nodes, which may both have
 paths. I'd like to attach a line of sight camera between the two nodes in
 such a way that the camera is aiming at node 1 from node 2 at all times.
 I'd then also like to be able to zoom in and out relative to this line of
 sight.

 I tried setting up a NodeTrackerManiulator, but that class seems to be
 able to freely track just one node. However, I need something that can
 track a node with camera movement constrained by another node. I tried
 something like the following:


 Code:

 osg::ref_ptrosgGA::NodeTrackerManipulator manip2 = new
 osgGA::NodeTrackerManipulator;
 manip2-setTrackNode(plane);
 manip2-setNode(sensor);
 manip2-setTrackerMode(osgGA::NodeTrackerManipulator::NODE_CENTER);
 addView(manip2.get());




 but it seems to still freely track just the plane node.

 Thanks in advance,

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=62724#62724





 ___
 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] Camera default stateset ???

[Robert Osfield]

Hi Nick,


osg::Camera is just an Node so to set the state that you want to get
inherited to everything below it you simple do:

  osg::StateSet* ss = camera-getOrCreateStateSet();
  ss-set*();

Robert.

On 11 January 2015 at 20:48, Trajce Nikolov NICK 
trajce.nikolov.n...@gmail.com wrote:

 Hi Community,

 I remember there was a change in the later OSG for calling explicitlly the
 setting of some defaults for the Camera (not sure though) stateset?? or
 something like that?

 If you know what I mean can you point me to the right thing? I tried to
 find it in the archive with no luck

 Thanks a bunch as always

 Nick

 --
 trajce nikolov nick

 ___
 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] Camera default stateset ???

[Robert Osfield]

Hi Nick,

On 12 January 2015 at 09:54, Trajce Nikolov NICK 
trajce.nikolov.n...@gmail.com wrote:

 yes, I know that, but thanks. I was looking for some setDefaults or
 something similar. I can not clearly recall the change you made in the
 later osg to explicitly set some defaults so I was shooting in the fog
 hoping someone will remember it better.


What is appropriate totally depends upon the context and needs.  In
osg::StateSet there is a setGlobalDefaults() method that gets set for the
master Camera or a View(er) so you don't need to set this.
setGlobalDefaults() sets some OpenGL state that is off by default such as
depth test.

A default constructed osg::Camera doesn't have an osg::StateSet assigned
though, so if you create our own osg::Camera and assign this to the
View(er) then you'll need to call StateSet::setGlobalDefaults().

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

Re: [osg-users] Camera default stateset ???

[Trajce Nikolov NICK]

yes That is what I was look for !! Thanks a bunch Robert!

Nick

On Mon, Jan 12, 2015 at 12:28 PM, Robert Osfield robert.osfi...@gmail.com
wrote:

 Hi Nick,

 On 12 January 2015 at 09:54, Trajce Nikolov NICK 
 trajce.nikolov.n...@gmail.com wrote:

 yes, I know that, but thanks. I was looking for some setDefaults or
 something similar. I can not clearly recall the change you made in the
 later osg to explicitly set some defaults so I was shooting in the fog
 hoping someone will remember it better.


 What is appropriate totally depends upon the context and needs.  In
 osg::StateSet there is a setGlobalDefaults() method that gets set for the
 master Camera or a View(er) so you don't need to set this.
 setGlobalDefaults() sets some OpenGL state that is off by default such as
 depth test.

 A default constructed osg::Camera doesn't have an osg::StateSet assigned
 though, so if you create our own osg::Camera and assign this to the
 View(er) then you'll need to call StateSet::setGlobalDefaults().

 Robert.

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




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

Re: [osg-users] Camera default stateset ???

[Trajce Nikolov NICK]

Hi Robert,

yes, I know that, but thanks. I was looking for some setDefaults or
something similar. I can not clearly recall the change you made in the
later osg to explicitly set some defaults so I was shooting in the fog
hoping someone will remember it better.

Thanks again

Nick

On Mon, Jan 12, 2015 at 10:04 AM, Robert Osfield robert.osfi...@gmail.com
wrote:

 Hi Nick,


 osg::Camera is just an Node so to set the state that you want to get
 inherited to everything below it you simple do:

   osg::StateSet* ss = camera-getOrCreateStateSet();
   ss-set*();

 Robert.

 On 11 January 2015 at 20:48, Trajce Nikolov NICK 
 trajce.nikolov.n...@gmail.com wrote:

 Hi Community,

 I remember there was a change in the later OSG for calling explicitlly
 the setting of some defaults for the Camera (not sure though) stateset?? or
 something like that?

 If you know what I mean can you point me to the right thing? I tried to
 find it in the archive with no luck

 Thanks a bunch as always

 Nick

 --
 trajce nikolov nick

 ___
 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




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

Re: [osg-users] Camera callbacks

[Robert Osfield]

HI John,

As the Camera has Initial/Pre/Post and FinalDrawCallbacks having
add/remove/getNum/get methods rather than just set/get will mean a lot
of extra new methods expanding an already large API.

To avoid a big expansion in the API it would probably be best to push
the list of callbacks onto DrawCallback, possibly as a linked list.
Or have a CallbackList object that we get for each for the
Intial/Pre/Post/Final draw callbacks.  For backwards compatibility
we'd need to main the old set/get methods, but for code that uses like
osgShadow we can easily update them to use the list method.

Robert.

On 9 April 2014 22:22, PCJohn pec...@fit.vutbr.cz wrote:
 Hi Robert,

 Providing similar support for Camera::DrawCallbacks would be possible,
 there isn't the same imperative for controlling traversal, but it'd
 keep the public Camera API simple - it's complicated enough as it is
 so am reluctant to add further API to it.

 Sorry, I am not native English. By the last sentence do you mean that the
 multiple Camera::DrawCallback support must be as simple as possible or that
 you would prefer to not put it into the API?

 I am not pushing the things, but it seems that shadow classes are already not
 compatible with OcclusionQueryNode as they both register pre and post draw
 callbacks. And a programmer might want to make his own callbacks for profiling
 reasons, start various OpenGL queries, resize his own custom RenderBuffers 
 used
 for HDR rendering whenever screen window resizes, etc.

 My idea was:

 struct OSG_EXPORT DrawCallback : virtual public Object
 {
 DrawCallback() {}
 DrawCallback(const DrawCallback,const CopyOp) {}
 META_Object(osg, DrawCallback);
 virtual void operator () (osg::RenderInfo renderInfo) const;
 virtual void operator () (const osg::Camera /*camera*/) const {}

 ref_ptrDrawCallback _nestedCallback;
 };

 inline void addPreDrawCallback(DrawCallback* dc)
 {
 if (dc != NULL) {
 dc-_nestedCallback = _preDrawCallback;
 _preDrawCallback = dc;
 }
 }

 inline void removePreDrawCallback(DrawCallback* dc)
 {
 if (dc != NULL) {
 if (dc == _preDrawCallback)
 _preDrawCallback = _preDrawCallback-_nestedCallback;
 else
 {
 DrawCallback *c = _preDrawCallback;
 while (c) {
 if (c-_nestedCallback==dc) {
 c-_nestedCallback = c-_nestedCallback-
_nestedCallback;
 dc-_nestedCallback = NULL;
 return;
 }
 }
 }
 }
 }

 Not sure if it is enough thread-safe. If you think that Initial-,Pre-,Post-,
 and Final-DrawCallback functionality has too many methods,
 we can make like see bellow, while possibly deprecating some of the current
 methods.

 enum DrawCallbackEnum { INITIALIZE_DRAW_CALLBACK = 0,
 PRE_DRAW_CALLBACK = 1,
 POST_DRAW_CALLBACK = 2,
 FINALIZE_DRAW_CALLBACK = 3 };

 inline void addPreDrawCallback(DrawCallbackEnum which, DrawCallback* dc)
 {
  if( which  4 ) {
  ref_ptrDrawCallback c = _drawCallbacks[which];
  
 }
 inline void removePreDrawCallback(DrawCallbackEnum which, DrawCallback*
 dc)
 {  }

 ref_ptrDrawCallback   _drawCallbacks[4]; // this replaces four variables


 John



 On Wednesday 09 of April 2014 16:16:31 Robert Osfield wrote:
 Hi John,

 Original Node callbacks didn't support multiple callbacks, but I
 worked out that I could add the functionality relatively
 non-intrusively by nesting callbacks. The key advantage with nesting
 is that it enables a callback retain data on the stack within the
 local scope of the callback - which makes things easy to implement and
 gives you thread safety for free, and enables the callback to take
 complete controlling traversal.

 Providing similar support for Camera::DrawCallbacks would be possible,
 there isn't the same imperative for controlling traversal, but it'd
 keep the public Camera API simple - it's complicated enough as it is
 so am reluctant to add further API to it.  The alternative would be to
 add a list of callbacks, but as you said this would break
 compatibility.

 Robert.

 On 9 April 2014 14:10, PCJohn pec...@fit.vutbr.cz wrote:
  Hi,
 
  I very like the capability of osg::Node to register any number of update,
  event and cull callbacks. This allows for a nice modular approach with
  each
  module registering callbacks for anything they wish without disturbing
  others.
 
  I came to a problem that Camera can register just one Initial-,Pre-,Post-,
  and Final-DrawCallback. Surely, I can register my own 

Re: [osg-users] Camera callbacks

[Robert Osfield]

Hi John,

Original Node callbacks didn't support multiple callbacks, but I
worked out that I could add the functionality relatively
non-intrusively by nesting callbacks. The key advantage with nesting
is that it enables a callback retain data on the stack within the
local scope of the callback - which makes things easy to implement and
gives you thread safety for free, and enables the callback to take
complete controlling traversal.

Providing similar support for Camera::DrawCallbacks would be possible,
there isn't the same imperative for controlling traversal, but it'd
keep the public Camera API simple - it's complicated enough as it is
so am reluctant to add further API to it.  The alternative would be to
add a list of callbacks, but as you said this would break
compatibility.

Robert.

On 9 April 2014 14:10, PCJohn pec...@fit.vutbr.cz wrote:
 Hi,

 I very like the capability of osg::Node to register any number of update,
 event and cull callbacks. This allows for a nice modular approach with each
 module registering callbacks for anything they wish without disturbing others.

 I came to a problem that Camera can register just one Initial-,Pre-,Post-, and
 Final-DrawCallback. Surely, I can register my own callback container that
 would call all my registered callback. But that is not compatible with OSG-
 registered Callbacks, for instance OcclusionQueryNode would overwrite my
 callback container. Could we possibly make the similar approach for the camera
 as for osg::Node? I can volunteer to make the first iteration for osg-
 submissions, if the community and Robert thinks that it is a good idea.


 My idea for implementation would be to append
 ref_ptrDrawCallback _nestedCallback into the Camera::DrawCallback structure,
 append Camera::add*Callback() and Camera::remove*Callback()
 and make Camera::callCallbacks(DrawCallback *cb) with a parameter giving
 pointer to the first DrawCallback of Initial-,Pre-,Post-, and Final-
 DrawCallback list.
 An alternative would be to let the user call nested callbacks from
 DrawCallback::operator(), but as we would always want (probably) to call all
 the callbacks and never stop in the middle of the work, I personally like the
 first approach more and it is more compatibility-friendly, as users will not
 need to modify their existing callbacks to get the new multi-callback
 capability. But I am ok with any approach.


 Do you think it is a good idea?
 John

 ___
 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] Camera callbacks

[PCJohn]

Hi Robert,

 Providing similar support for Camera::DrawCallbacks would be possible,
 there isn't the same imperative for controlling traversal, but it'd
 keep the public Camera API simple - it's complicated enough as it is
 so am reluctant to add further API to it.

Sorry, I am not native English. By the last sentence do you mean that the 
multiple Camera::DrawCallback support must be as simple as possible or that 
you would prefer to not put it into the API?

I am not pushing the things, but it seems that shadow classes are already not 
compatible with OcclusionQueryNode as they both register pre and post draw 
callbacks. And a programmer might want to make his own callbacks for profiling 
reasons, start various OpenGL queries, resize his own custom RenderBuffers used 
for HDR rendering whenever screen window resizes, etc.

My idea was:

struct OSG_EXPORT DrawCallback : virtual public Object
{
DrawCallback() {}
DrawCallback(const DrawCallback,const CopyOp) {}
META_Object(osg, DrawCallback);
virtual void operator () (osg::RenderInfo renderInfo) const;
virtual void operator () (const osg::Camera /*camera*/) const {}

ref_ptrDrawCallback _nestedCallback;
};

inline void addPreDrawCallback(DrawCallback* dc)
{
if (dc != NULL) {
dc-_nestedCallback = _preDrawCallback;
_preDrawCallback = dc;
}
}

inline void removePreDrawCallback(DrawCallback* dc)
{
if (dc != NULL) {
if (dc == _preDrawCallback)
_preDrawCallback = _preDrawCallback-_nestedCallback;
else
{
DrawCallback *c = _preDrawCallback;
while (c) {
if (c-_nestedCallback==dc) {
c-_nestedCallback = c-_nestedCallback-
_nestedCallback;
dc-_nestedCallback = NULL;
return;
}
}
}
}
}

Not sure if it is enough thread-safe. If you think that Initial-,Pre-,Post-,
and Final-DrawCallback functionality has too many methods,
we can make like see bellow, while possibly deprecating some of the current 
methods.

enum DrawCallbackEnum { INITIALIZE_DRAW_CALLBACK = 0,
PRE_DRAW_CALLBACK = 1,
POST_DRAW_CALLBACK = 2,
FINALIZE_DRAW_CALLBACK = 3 };

inline void addPreDrawCallback(DrawCallbackEnum which, DrawCallback* dc)
{
 if( which  4 ) {
 ref_ptrDrawCallback c = _drawCallbacks[which];
 
}
inline void removePreDrawCallback(DrawCallbackEnum which, DrawCallback* 
dc)
{  }

ref_ptrDrawCallback   _drawCallbacks[4]; // this replaces four variables


John



On Wednesday 09 of April 2014 16:16:31 Robert Osfield wrote:
 Hi John,
 
 Original Node callbacks didn't support multiple callbacks, but I
 worked out that I could add the functionality relatively
 non-intrusively by nesting callbacks. The key advantage with nesting
 is that it enables a callback retain data on the stack within the
 local scope of the callback - which makes things easy to implement and
 gives you thread safety for free, and enables the callback to take
 complete controlling traversal.
 
 Providing similar support for Camera::DrawCallbacks would be possible,
 there isn't the same imperative for controlling traversal, but it'd
 keep the public Camera API simple - it's complicated enough as it is
 so am reluctant to add further API to it.  The alternative would be to
 add a list of callbacks, but as you said this would break
 compatibility.
 
 Robert.
 
 On 9 April 2014 14:10, PCJohn pec...@fit.vutbr.cz wrote:
  Hi,
  
  I very like the capability of osg::Node to register any number of update,
  event and cull callbacks. This allows for a nice modular approach with
  each
  module registering callbacks for anything they wish without disturbing
  others.
  
  I came to a problem that Camera can register just one Initial-,Pre-,Post-,
  and Final-DrawCallback. Surely, I can register my own callback
  container that would call all my registered callback. But that is not
  compatible with OSG- registered Callbacks, for instance
  OcclusionQueryNode would overwrite my callback container. Could we
  possibly make the similar approach for the camera as for osg::Node? I can
  volunteer to make the first iteration for osg- submissions, if the
  community and Robert thinks that it is a good idea.
  
  
  My idea for implementation would be to append
  ref_ptrDrawCallback _nestedCallback into the Camera::DrawCallback
  structure, append Camera::add*Callback() and Camera::remove*Callback()
  and make Camera::callCallbacks(DrawCallback *cb) with a parameter giving
  pointer to the first DrawCallback of 

Re: [osg-users] Camera rotation by Mouse

[Mattias Helsing]

Hi Drew
The TrackballManipulator is overriding your setting of viewmatrix! The
call to frame will (in the updatetraversal) update the ViewMatrix
local to the TrackbalManipulator, then your viewer goes and collects a
currect ViewMatrix from an attached CameraManipulator (which is the
TrackballManipulator) before rendering.
If you don't want a TrackballManipulator you should call
setCameraManipulator(0), probably after viewer.realize() since that
call installs a TrackballManipulator if none was found. Only then will
your setViewMatrix take effect.
Given your task description what you should probably do is code your
own CameraManipulator. There are some (more or less complex) examples
in the osgGA source, but basically a CameraManipulator is responsible
for responding to events of your choice (mouse, keyboard etc.) and
then produce a ViewMatrix (actually the view retreives the
InverseViewMatrix from a connected CameraManipulator)

Also - see the osgmanipulator example
cheers
/Mattias

On Sat, Sep 28, 2013 at 6:47 AM, Andrew Nelson drewnelson1...@gmail.com wrote:
 Hi Everyone,

 I'm new to using OSG so please forgive me if some of my terms or ideas are 
 incorrect. My overall goal currently is to simply rotate the camera(x-axis, 
 y-axis, and/or z-axis), based on the users mouse position(i.e. when the user 
 moves the mouse in any direction, camera rotates - rather than click and 
 drag). For now, I've just been trying to rotate(or even translate) the 
 camera(in any way) of the BasicGeometry.cpp program just so I can start to 
 get the idea. What I have so far:

 .
 .
 .
 //viewer defined as osgViewer::Viewer viewer;
 viewer.setCameraManipulator(new osgGA::TrackballManipulator());
 viewer.realize();
 while( !viewer.done() )
 {
  osg::Matrixd cameraRotation;
  osg::Matrixd cameraTrans;
  cameraRotation.makeRotate(osg::DegreesToRadians(-20.0),   
 osg::Vec3(0,1,0), // roll
  osg::DegreesToRadians(-15.0), osg::Vec3(1,0,0) , // pitch
  osg::DegreesToRadians( 10.0), osg::Vec3(0,0,1) ); // heading
  cameraTrans.makeTranslate( 10,-50,15 );
  viewer.getCamera()-setViewMatrix(cameraTrans * cameraRotation);
  viewer.frame();
 }


 My thinking is that by setting up a rotation matrix and a translation matrix, 
 the product of these matrices would provided by the desired position. Then, 
 with this we can set the viewer's camera to this desired matrix.

 The code compiles and runs, but this doesn't operate as planned. Could 
 someone explain why this process doesn't work and how I should approach this 
 issue?

 Any help is much appreciated.
 Thank you!

 Cheers,
 Drew

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=56531#56531





 ___
 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] Camera representing node

[Robert Osfield]

Hi Mots,

It sounds like inserting osg::CameraView nodes within the subgraphs you
wish to track, then using a osgGA::CameraViewSwitchManipulator would be the
easiest way forward.

Robert.


On 8 October 2013 03:29, Mots G maverickm...@gmail.com wrote:

 Hi,
 I'm trying to add cameras to the scene (dropping models across the scene)
 and the user could drag them or rotate them and change its parameters.
 All works good for the first time, however, I lose track if the user
 rotates the camera representing object. I'm banging my head with simple
 math but I'm unable to figure out how the camera's center/up vector change
 if the camera object rotates. I put the eye to where the node is translated
 to.

 I tried to figure out the rotation angle so that I could initialize the
 camera with the original parameters for the center and up and then apply
 rotation to the model view matrix but it doesn't seem to make the camera
 look at, in the correct direction. I'm using daggers for rotating and
 translating the node.

 Tried looking at source for some manipulators but could not understand
 much.

 Sorry for the noob question but would be glad if anyone could help.

 Thanks,
 mots




 ___
 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] Camera representing node

[Mots G]

Thank you so much Robert, will give it a try!

Cheers,
mots


On Tue, Oct 8, 2013 at 3:36 PM, Robert Osfield robert.osfi...@gmail.comwrote:

 Hi Mots,

 It sounds like inserting osg::CameraView nodes within the subgraphs you
 wish to track, then using a osgGA::CameraViewSwitchManipulator would be the
 easiest way forward.

 Robert.


 On 8 October 2013 03:29, Mots G maverickm...@gmail.com wrote:

 Hi,
 I'm trying to add cameras to the scene (dropping models across the scene)
 and the user could drag them or rotate them and change its parameters.
 All works good for the first time, however, I lose track if the user
 rotates the camera representing object. I'm banging my head with simple
 math but I'm unable to figure out how the camera's center/up vector change
 if the camera object rotates. I put the eye to where the node is translated
 to.

 I tried to figure out the rotation angle so that I could initialize the
 camera with the original parameters for the center and up and then apply
 rotation to the model view matrix but it doesn't seem to make the camera
 look at, in the correct direction. I'm using daggers for rotating and
 translating the node.

 Tried looking at source for some manipulators but could not understand
 much.

 Sorry for the noob question but would be glad if anyone could help.

 Thanks,
 mots



 ___
 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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Camera Manipulator needs to apply projection matrix extents in update traversal

[Nick McEvoy]

Yes I guess we could do via an EventHandler (which we have done for other 
things interested in events) except all our various extended 'camera 
manipulators' are added (i.e. set active) via the 
View::setCameraManipulator(osgGA::CameraManipulator*) ... so sticking to the 
pattern this particular specialised manipulator was implemented this way.


robertosfield wrote:
 Hi Nick,
 
 You still don't need a CameraManipulator to do this, a custom EventHandler as 
 some code setting the camera would be sufficient.
 
 


--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=55281#55281





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

Re: [osg-users] Camera Manipulator needs to apply projection matrix extents in update traversal

[Robert Osfield]

HI Nick,

The svn/trunk and recent dev releases of the OSG have a
CameraManipulator::updateCamera(osg::Camera) method that allows you to set
any properties you want on the View's Camera rather than pulling the view
matrix as was done previously.

The other bit of the jigsaw for you specific implementation requirements
might simply to not use a CameraManipulator at all and just set the view
and projection matrices on each new frame within your own frame loop.
CameraManipulators are only one way to control the view and while often
convinient to use in their default form aren't all required usage.

Robert.

On 17 July 2013 02:56, Nick McEvoy nmc...@gmail.com wrote:

 I'm writing a camera manipulator but have an issue where I need the
 manipulator to be visited during the update traversal ( after the scene
 graph has been updated). Without going into too much detail ... the basic
 reason I require this is ... that my manipulator needs to set the
 orthographic projection matrix extents based on the updated scene. I really
 need to set the orthographic projection matrix extents at about the point
 where the camera view matrix is applied (see point 2c below).

 So as we all know the viewer performs:
 1. event traversal
 2. update traversal
 3. rendering traversals

 And my area of concern is the viewers update traversal (point 2) which
 does the following:
 2a. visits the scene graph
 2b. visits the camera
 2c. sets the cameras view matrix (using the camera manipulators inverse
 matrix)

 BUT it does NOT visit the active manipulator or have any way for the
 active manipulator to apply a projection matrix if it so wishes
 (specifically at point 2c). :(

 I've considered and tested the following, but they all feel like hacks:
 - set the orthographic projection matrix extents in
 MyCameraManipulator::getInverseMatrix(), called at point 2c. But I think
 this is a bad idea because this method is really used for other purposes.
 - have my active camera manipulator add an update callback onto the
 current camera and so therefore set my projection matrix extents when I'm
 visited at point 2b. But then I must also have code to remove the update
 callback from the camera when my manipulator is no longer active or
 removed. My implementation on this works, but it feels dirty.

 Does anyone have a simpler/cleaner solution?

 The real question is why is there no mechanism in OSG to allow the camera
 manipulator to update the projection matrix at the appropriate time? Maybe
 something like the ideas below (++1) or (++2) could be considered?


 Code:

 void Viewer::updateTraversal()
 {
 if (_camera.valid()  _camera-getUpdateCallback())
 _camera-accept(*_updateVisitor);
 (++1) if (_cameraManipulator.valid() 
 _cameraManipulator-getUpdateCallback())
 _cameraManipulator-accept(*_updateVisitor);

 if (_cameraManipulator.valid())
 {
 _camera-setViewMatrix(_cameraManipulator-getInverseMatrix());
 (++2) _cameraManipulator-updateProjectionMatrix();
 }
 }




 Thoughts?

 Cheers,
 Nick[/code]

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=55232#55232





 ___
 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] Camera Manipulator needs to apply projection matrix extents in update traversal

[Nick McEvoy]

Excellent, the new updateCamera() method on the trunk sounds exactly what we 
need ! :)

We are on osg 3.0.1 so for now, so until we update to the latest, I've just put 
in our work around which connects our active manipulator to the camera's update 
callback and that seems to work ok.

Also just to clarify, we do need a manipulator for our implementation as it is 
an orthographic camera manipulator that takes user input to rotate, but has an 
additional feature to auto-fit all objects in the scene by setting the ortho 
projection extents.

Cheers,
Nick


robertosfield wrote:
 HI Nick,
 
 The svn/trunk and recent dev releases of the OSG have a 
 CameraManipulator::updateCamera(osg::Camera) method that allows you to set 
 any properties you want on the View's Camera rather than pulling the view 
 matrix as was done previously.
 
 The other bit of the jigsaw for you specific implementation requirements 
 might simply to not use a CameraManipulator at all and just set the view and 
 projection matrices on each new frame within your own frame loop.  
 CameraManipulators are only one way to control the view and while often 
 convinient to use in their default form aren't all required usage.
 
 Robert.
 
 


--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=55273#55273





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

Re: [osg-users] Camera Manipulator needs to apply projection matrix extents in update traversal

[Robert Osfield]

Hi Nick,

On 19 July 2013 00:08, Nick McEvoy nmc...@gmail.com wrote:

 Excellent, the new updateCamera() method on the trunk sounds exactly what
 we need ! :)

 We are on osg 3.0.1 so for now, so until we update to the latest, I've
 just put in our work around which connects our active manipulator to the
 camera's update callback and that seems to work ok.

 Also just to clarify, we do need a manipulator for our implementation as
 it is an orthographic camera manipulator that takes user input to rotate,
 but has an additional feature to auto-fit all objects in the scene by
 setting the ortho projection extents.


You still don't need a CameraManipulator to do this, a custom EventHandler
as some code setting the camera would be sufficient.

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

Re: [osg-users] Camera Manipulator needs to apply projection matrix extents in update traversal

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Nick,

On 07/17/2013 03:56 AM, Nick McEvoy wrote:
 I'm writing a camera manipulator but have an issue where I need the
 manipulator to be visited during the update traversal ( after the
 scene graph has been updated). Without going into too much detail
 ... the basic reason I require this is ... that my manipulator
 needs to set the orthographic projection matrix extents based on
 the updated scene. I really need to set the orthographic projection
 matrix extents at about the point where the camera view matrix is
 applied (see point 2c below).
 

You should intercept the cull visitor, not update one. Cull is what is
done right before rendering and after update.

Regards,

Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iD8DBQFR5oK9n11XseNj94gRAiM+AJ9OGJxBzijW2YXs550uL3KanKxUPACfYFUF
vumSooid17kMBLRpqvjkc/M=
=Di6d
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

[Robert Osfield]

Hi Judson,

On 29 May 2013 15:01, Judson Weissert jud...@mfrac.com wrote:
 My fault, I performed an invalid test. My osgviewer.cpp source was modified,
 and I did not realize it. It was still overriding checkNeedToDoFrame(). I
 retested, and it appears to be working as expected.

 Sorry about that.

 I will continue testing and report back my findings if I find anything.

Good to hear it's working.  With your own code with modified
checkNeedToDoFrame() you will be best to either call the base classes
checkNeedToDoFrame() or recreate similar code w.r.t calling the new
bool checkEvents() method rather than doing a full event traversal.

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

Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

[Robert Osfield]

Hi Judson,

On 28 May 2013 20:36, Judson Weissert jud...@mfrac.com wrote:
 I just got the 3.1.7 developer release built. Running the osgviewer
 application with arguments --run-on-demand --screen 1 dumptruck.osgt
 results in a regression where the viewer does not respond to mouse or
 keyboard input (does not render any new frames, does not allow me to exit
 via escape, does not respond to 's' for stats, etc). Similar behavior occurs
 in my application, but I have not had a chance to run the code in a debugger
 yet.

 Running the osgviewer application without the --run-on-demand flag appears
 to work as expected.

 Compiled with Visual C++ 2010, running on Windows 7 (Same machine and
 compiler settings as my previous tests).

I just tested:

osgviewer --run-on-demand --screen 0 dumptruck.osgt

And it worked fine.  I can't test --screen 1 I don't have a second
display attached right now.  I wouldn't expect this to make a
difference.  Could you try --screen 0?

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

Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

[Judson Weissert]

Robert,

My fault, I performed an invalid test. My osgviewer.cpp source was 
modified, and I did not realize it. It was still overriding 
checkNeedToDoFrame(). I retested, and it appears to be working as expected.


Sorry about that.

I will continue testing and report back my findings if I find anything.

Thanks again,

Judson

On 5/29/2013 4:19 AM, Robert Osfield wrote:

Hi Judson,

On 28 May 2013 20:36, Judson Weissert jud...@mfrac.com wrote:

I just got the 3.1.7 developer release built. Running the osgviewer
application with arguments --run-on-demand --screen 1 dumptruck.osgt
results in a regression where the viewer does not respond to mouse or
keyboard input (does not render any new frames, does not allow me to exit
via escape, does not respond to 's' for stats, etc). Similar behavior occurs
in my application, but I have not had a chance to run the code in a debugger
yet.

Running the osgviewer application without the --run-on-demand flag appears
to work as expected.

Compiled with Visual C++ 2010, running on Windows 7 (Same machine and
compiler settings as my previous tests).

I just tested:

osgviewer --run-on-demand --screen 0 dumptruck.osgt

And it worked fine.  I can't test --screen 1 I don't have a second
display attached right now.  I wouldn't expect this to make a
difference.  Could you try --screen 0?

Robert.
___
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] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

[Judson Weissert]

Robert,

This is great news! I will try out the new code as soon as possible and 
report back my findings.


Thanks,

Judson

On 5/24/2013 5:42 AM, Robert Osfield wrote:

Hi Judson.

I have refactored the Viewer/CompositeViewer::checkNeedToDo() method
so that it now calls a new Viewer/CompositeViewer::checkEvents()
method that checks for available events rather than rely upon the more
heavier weight eventTraversals() method.

The eventTraversals() method design is focused on being done as part
of a full frame and was hacked to work in the case of run or demand
but didn't handle me moving the frame() event generation into.  There
are good reasons to move frame() event, but not so good reasons to do
a full event traversal as a means for checking whether a full frame is
needed or not.

The introduction of the checkEvents() method required quite a few
changes in other classes to support it, fingers crossed I haven't
broken the build in the process of making these changes, unfortunately
I can't test out OSX, iOS, Windows builds so will have rely upon the
community to test of these changes that I had to make to the platform
specific GraphicsWindow implementations.

I have now checked in my changes to svn/trunk, could you test them out
and let me know if things are working OK now.

Cheers,
Robert.
___
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] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

[Judson Weissert]

Hi Robert,

I just got the 3.1.7 developer release built. Running the osgviewer 
application with arguments --run-on-demand --screen 1 dumptruck.osgt 
results in a regression where the viewer does not respond to mouse or 
keyboard input (does not render any new frames, does not allow me to 
exit via escape, does not respond to 's' for stats, etc). Similar 
behavior occurs in my application, but I have not had a chance to run 
the code in a debugger yet.


Running the osgviewer application without the --run-on-demand flag 
appears to work as expected.


Compiled with Visual C++ 2010, running on Windows 7 (Same machine and 
compiler settings as my previous tests).


Regards,

Judson

On 5/28/2013 9:39 AM, Judson Weissert wrote:

Robert,

This is great news! I will try out the new code as soon as possible 
and report back my findings.


Thanks,

Judson

On 5/24/2013 5:42 AM, Robert Osfield wrote:

Hi Judson.

I have refactored the Viewer/CompositeViewer::checkNeedToDo() method
so that it now calls a new Viewer/CompositeViewer::checkEvents()
method that checks for available events rather than rely upon the more
heavier weight eventTraversals() method.

The eventTraversals() method design is focused on being done as part
of a full frame and was hacked to work in the case of run or demand
but didn't handle me moving the frame() event generation into. There
are good reasons to move frame() event, but not so good reasons to do
a full event traversal as a means for checking whether a full frame is
needed or not.

The introduction of the checkEvents() method required quite a few
changes in other classes to support it, fingers crossed I haven't
broken the build in the process of making these changes, unfortunately
I can't test out OSX, iOS, Windows builds so will have rely upon the
community to test of these changes that I had to make to the platform
specific GraphicsWindow implementations.

I have now checked in my changes to svn/trunk, could you test them out
and let me know if things are working OK now.

Cheers,
Robert.
___
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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

[Robert Osfield]

Hi Judson,

On 23 May 2013 21:57, Judson Weissert jud...@mfrac.com wrote:
 I just realized that the modification to osgViewer::Viewer is not actually
 required to reproduce the problem in the osgviewer application since there
 are no update callbacks installed anyway. Originally, I could not get the
 behavior to happen in the unmodified osgviewer application, but I just tried
 again and the unmodified osgviewer application (when run with
 --run-on-demand dumptruck.osgt) did exhibit the problem after I played with
 it for a while.

 Toggling the stats viewer while manipulating the model via right click and
 drag may increase the probability of triggering the behavior.

This is great news, I've just tried running osgviewer --run-on-demand
as suggested and see the problem with the pan causing the view to jump
off toward infinity.  I can reproduce the bug consistently so there is
a good chance I'll be able to home in on the issue.

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

Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

[Robert Osfield]

Hi Judson.

I have refactored the Viewer/CompositeViewer::checkNeedToDo() method
so that it now calls a new Viewer/CompositeViewer::checkEvents()
method that checks for available events rather than rely upon the more
heavier weight eventTraversals() method.

The eventTraversals() method design is focused on being done as part
of a full frame and was hacked to work in the case of run or demand
but didn't handle me moving the frame() event generation into.  There
are good reasons to move frame() event, but not so good reasons to do
a full event traversal as a means for checking whether a full frame is
needed or not.

The introduction of the checkEvents() method required quite a few
changes in other classes to support it, fingers crossed I haven't
broken the build in the process of making these changes, unfortunately
I can't test out OSX, iOS, Windows builds so will have rely upon the
community to test of these changes that I had to make to the platform
specific GraphicsWindow implementations.

I have now checked in my changes to svn/trunk, could you test them out
and let me know if things are working OK now.

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

Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

[Robert Osfield]

Hi Judson,

Great detective work. The change to the frame() was done to avoid
issues with events being given times that aren't in sequence -
previously we'd get time delta's that could be negative.

Do you have an idea of how to reproduce the problem now?  Once I can
reproduce it I'll be able to work out the best west to resolve the
problem.


Robert.

On 22 May 2013 22:50, Judson Weissert jud...@mfrac.com wrote:
 Robert,

 I found the revision that caused the regression. Ironically, it occurred way
 before the 3.1.6 release...

 See r13092 associated with
 http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk/src/osgViewer/Viewer.cpp

 The 3.1.2 behavior returned when I reverted that revision. A notable
 behavior change that I noticed is that before I reverted r13092, the
 OSG_INFOReset event time from ... line in EventQueue::takeEvents() would
 trigger extremely often (e.g., while hovering over the viewer window). It
 does not trigger at all after I reverted r13092.

 See also the cutOffTime variable in Viewer::eventTraversal() which explains
 the link to ON_DEMAND frame scheduling.

 Do you happen to know the original intention of r13092? The log message is
 Moved the frame() event into the event traversal after then events and
 their state have been accumulated.

 Thanks for the help,

 Judson



 On 5/22/2013 3:02 PM, Judson Weissert wrote:

 Robert,

 I have made some progress. The problem appears to be caused by an
 eventTimeDelta of zero which is calculated within
 StandardManipulator::performMovement(). It eventually results in a divide by
 zero and the propagation of non-finite value(s) through the remainder of the
 call chain. Specifically, dy in OrbitManipulator::zoomModel() and
 OrbitManipulator::panModel() ends up being a non-finite value.

 Thus, I have found an explanation for the symptoms, but I have not tracked
 down the underlying cause of eventTimeDelta being calculated as zero.
 Therefore, I have not been able to create a small example case yet.

 Regards,

 Judson

 On 5/22/2013 2:37 PM, Robert Osfield wrote:

 Hi Judson,

 It's a curious set of circumstances but as yet I can't think of a
 specific cause.

 Is there any chance you can create a small example that illustrates
 the problem so that I can try it out and see if I can spot the
 problems.

 Cheers,
 Robert.


 ___
 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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

[Judson Weissert]

Robert,

I figured out why my case diverges from the osgviewer application. I 
override osgViewer::Viewer::checkNeedToDoFrame(), member function, and 
call eventTraversal() on a code path where it would otherwise not be 
called. Specifically, I don't want the default behavior where a new 
frame is scheduled if the camera has an update callback, or the scene 
has update callbacks associated with it.


The attached patch contains a modification to 
osg/applications/osgviewer/osgviewer.cpp that exposes the problem I ran 
into. Notice that the checkNeedToDoFrame() implementation is exactly the 
same as it exists in osgViewer::Viewer except for the 3 lines that were 
removed via the #if 0 macro.


After applying the patch, I recompiled and ran:

osgviewer --run-on-demand --SingleThreaded --screen 1 spaceship.osgt

Throwing the model with the middle or right mouse button will 
occasionally cause the model to disappear. Granted, it does not 
reproduce every time. Right clicking and dragging horizontally seems to 
be the best way to reproduce the behavior (sometimes right clicking over 
and over while dragging).


I guess I need to figure out a different way to prevent frames from 
being scheduled when update callbacks are present?


Thanks again,

Judson


On 5/23/2013 3:30 AM, Robert Osfield wrote:

Hi Judson,

Great detective work. The change to the frame() was done to avoid
issues with events being given times that aren't in sequence -
previously we'd get time delta's that could be negative.

Do you have an idea of how to reproduce the problem now?  Once I can
reproduce it I'll be able to work out the best west to resolve the
problem.


Robert.

On 22 May 2013 22:50, Judson Weissert jud...@mfrac.com wrote:

Robert,

I found the revision that caused the regression. Ironically, it occurred way
before the 3.1.6 release...

See r13092 associated with
http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk/src/osgViewer/Viewer.cpp

The 3.1.2 behavior returned when I reverted that revision. A notable
behavior change that I noticed is that before I reverted r13092, the
OSG_INFOReset event time from ... line in EventQueue::takeEvents() would
trigger extremely often (e.g., while hovering over the viewer window). It
does not trigger at all after I reverted r13092.

See also the cutOffTime variable in Viewer::eventTraversal() which explains
the link to ON_DEMAND frame scheduling.

Do you happen to know the original intention of r13092? The log message is
Moved the frame() event into the event traversal after then events and
their state have been accumulated.

Thanks for the help,

Judson



On 5/22/2013 3:02 PM, Judson Weissert wrote:

Robert,

I have made some progress. The problem appears to be caused by an
eventTimeDelta of zero which is calculated within
StandardManipulator::performMovement(). It eventually results in a divide by
zero and the propagation of non-finite value(s) through the remainder of the
call chain. Specifically, dy in OrbitManipulator::zoomModel() and
OrbitManipulator::panModel() ends up being a non-finite value.

Thus, I have found an explanation for the symptoms, but I have not tracked
down the underlying cause of eventTimeDelta being calculated as zero.
Therefore, I have not been able to create a small example case yet.

Regards,

Judson

On 5/22/2013 2:37 PM, Robert Osfield wrote:

Hi Judson,

It's a curious set of circumstances but as yet I can't think of a
specific cause.

Is there any chance you can create a small example that illustrates
the problem so that I can try it out and see if I can spot the
problems.

Cheers,
Robert.


___
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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Index: osgviewer.cpp
===
--- osgviewer.cpp   (revision 45025)
+++ osgviewer.cpp   (working copy)
@@ -52,6 +52,68 @@
 #define GL_TIMEOUT_IGNORED0xull
 #endif
 
+namespace
+{
+
+/// Modified Viewer implementation to expose the problem I encountered.
+class osg_viewer_t : public osgViewer::Viewer
+{
+public:
+osg_viewer_t ();
+
+osg_viewer_t (osg::ArgumentParser arguments);
+
+/// Copy constructor (not implemented).
+osg_viewer_t (
+  const osgViewer::Viewer viewer, const osg::CopyOp copyop
+);
+
+/* osgViewer::ViewerBase */
+
+virtual bool
+checkNeedToDoFrame ();
+};
+
+} // anonymous namespace
+
+osg_viewer_t::osg_viewer_t ()
+: osgViewer::Viewer ()
+{
+}
+
+osg_viewer_t::osg_viewer_t 

Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

[Robert Osfield]

Thanks for the code reproducing the problem, I'm just turning in for
the day so will have a look at trying to reproduce the issue tomorrow.

On 23 May 2013 18:32, Judson Weissert jud...@mfrac.com wrote:
 Robert,

 I figured out why my case diverges from the osgviewer application. I
 override osgViewer::Viewer::checkNeedToDoFrame(), member function, and call
 eventTraversal() on a code path where it would otherwise not be called.
 Specifically, I don't want the default behavior where a new frame is
 scheduled if the camera has an update callback, or the scene has update
 callbacks associated with it.

 The attached patch contains a modification to
 osg/applications/osgviewer/osgviewer.cpp that exposes the problem I ran
 into. Notice that the checkNeedToDoFrame() implementation is exactly the
 same as it exists in osgViewer::Viewer except for the 3 lines that were
 removed via the #if 0 macro.

 After applying the patch, I recompiled and ran:

 osgviewer --run-on-demand --SingleThreaded --screen 1 spaceship.osgt

 Throwing the model with the middle or right mouse button will occasionally
 cause the model to disappear. Granted, it does not reproduce every time.
 Right clicking and dragging horizontally seems to be the best way to
 reproduce the behavior (sometimes right clicking over and over while
 dragging).

 I guess I need to figure out a different way to prevent frames from being
 scheduled when update callbacks are present?

 Thanks again,

 Judson



 On 5/23/2013 3:30 AM, Robert Osfield wrote:

 Hi Judson,

 Great detective work. The change to the frame() was done to avoid
 issues with events being given times that aren't in sequence -
 previously we'd get time delta's that could be negative.

 Do you have an idea of how to reproduce the problem now?  Once I can
 reproduce it I'll be able to work out the best west to resolve the
 problem.


 Robert.

 On 22 May 2013 22:50, Judson Weissert jud...@mfrac.com wrote:

 Robert,

 I found the revision that caused the regression. Ironically, it occurred
 way
 before the 3.1.6 release...

 See r13092 associated with

 http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk/src/osgViewer/Viewer.cpp

 The 3.1.2 behavior returned when I reverted that revision. A notable
 behavior change that I noticed is that before I reverted r13092, the
 OSG_INFOReset event time from ... line in EventQueue::takeEvents()
 would
 trigger extremely often (e.g., while hovering over the viewer window). It
 does not trigger at all after I reverted r13092.

 See also the cutOffTime variable in Viewer::eventTraversal() which
 explains
 the link to ON_DEMAND frame scheduling.

 Do you happen to know the original intention of r13092? The log message
 is
 Moved the frame() event into the event traversal after then events and
 their state have been accumulated.

 Thanks for the help,

 Judson



 On 5/22/2013 3:02 PM, Judson Weissert wrote:

 Robert,

 I have made some progress. The problem appears to be caused by an
 eventTimeDelta of zero which is calculated within
 StandardManipulator::performMovement(). It eventually results in a
 divide by
 zero and the propagation of non-finite value(s) through the remainder of
 the
 call chain. Specifically, dy in OrbitManipulator::zoomModel() and
 OrbitManipulator::panModel() ends up being a non-finite value.

 Thus, I have found an explanation for the symptoms, but I have not
 tracked
 down the underlying cause of eventTimeDelta being calculated as zero.
 Therefore, I have not been able to create a small example case yet.

 Regards,

 Judson

 On 5/22/2013 2:37 PM, Robert Osfield wrote:

 Hi Judson,

 It's a curious set of circumstances but as yet I can't think of a
 specific cause.

 Is there any chance you can create a small example that illustrates
 the problem so that I can try it out and see if I can spot the
 problems.

 Cheers,
 Robert.

 ___
 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 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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

[Judson Weissert]

Thanks Robert.

I just realized that the modification to osgViewer::Viewer is not 
actually required to reproduce the problem in the osgviewer application 
since there are no update callbacks installed anyway. Originally, I 
could not get the behavior to happen in the unmodified osgviewer 
application, but I just tried again and the unmodified osgviewer 
application (when run with --run-on-demand dumptruck.osgt) did exhibit 
the problem after I played with it for a while.


Toggling the stats viewer while manipulating the model via right click 
and drag may increase the probability of triggering the behavior.


Sorry for my confusion,

Judson

On 5/23/2013 2:34 PM, Robert Osfield wrote:

Thanks for the code reproducing the problem, I'm just turning in for
the day so will have a look at trying to reproduce the issue tomorrow.

On 23 May 2013 18:32, Judson Weissert jud...@mfrac.com wrote:

Robert,

I figured out why my case diverges from the osgviewer application. I
override osgViewer::Viewer::checkNeedToDoFrame(), member function, and call
eventTraversal() on a code path where it would otherwise not be called.
Specifically, I don't want the default behavior where a new frame is
scheduled if the camera has an update callback, or the scene has update
callbacks associated with it.

The attached patch contains a modification to
osg/applications/osgviewer/osgviewer.cpp that exposes the problem I ran
into. Notice that the checkNeedToDoFrame() implementation is exactly the
same as it exists in osgViewer::Viewer except for the 3 lines that were
removed via the #if 0 macro.

After applying the patch, I recompiled and ran:

osgviewer --run-on-demand --SingleThreaded --screen 1 spaceship.osgt

Throwing the model with the middle or right mouse button will occasionally
cause the model to disappear. Granted, it does not reproduce every time.
Right clicking and dragging horizontally seems to be the best way to
reproduce the behavior (sometimes right clicking over and over while
dragging).

I guess I need to figure out a different way to prevent frames from being
scheduled when update callbacks are present?

Thanks again,

Judson



On 5/23/2013 3:30 AM, Robert Osfield wrote:

Hi Judson,

Great detective work. The change to the frame() was done to avoid
issues with events being given times that aren't in sequence -
previously we'd get time delta's that could be negative.

Do you have an idea of how to reproduce the problem now?  Once I can
reproduce it I'll be able to work out the best west to resolve the
problem.


Robert.

On 22 May 2013 22:50, Judson Weissert jud...@mfrac.com wrote:

Robert,

I found the revision that caused the regression. Ironically, it occurred
way
before the 3.1.6 release...

See r13092 associated with

http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk/src/osgViewer/Viewer.cpp

The 3.1.2 behavior returned when I reverted that revision. A notable
behavior change that I noticed is that before I reverted r13092, the
OSG_INFOReset event time from ... line in EventQueue::takeEvents()
would
trigger extremely often (e.g., while hovering over the viewer window). It
does not trigger at all after I reverted r13092.

See also the cutOffTime variable in Viewer::eventTraversal() which
explains
the link to ON_DEMAND frame scheduling.

Do you happen to know the original intention of r13092? The log message
is
Moved the frame() event into the event traversal after then events and
their state have been accumulated.

Thanks for the help,

Judson



On 5/22/2013 3:02 PM, Judson Weissert wrote:

Robert,

I have made some progress. The problem appears to be caused by an
eventTimeDelta of zero which is calculated within
StandardManipulator::performMovement(). It eventually results in a
divide by
zero and the propagation of non-finite value(s) through the remainder of
the
call chain. Specifically, dy in OrbitManipulator::zoomModel() and
OrbitManipulator::panModel() ends up being a non-finite value.

Thus, I have found an explanation for the symptoms, but I have not
tracked
down the underlying cause of eventTimeDelta being calculated as zero.
Therefore, I have not been able to create a small example case yet.

Regards,

Judson

On 5/22/2013 2:37 PM, Robert Osfield wrote:

Hi Judson,

It's a curious set of circumstances but as yet I can't think of a
specific cause.

Is there any chance you can create a small example that illustrates
the problem so that I can try it out and see if I can spot the
problems.

Cheers,
Robert.


___
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 mailing list
osg-users@lists.openscenegraph.org

Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

[Robert Osfield]

HI Judson,

I have done a refactor of osgViewer's internally handling of mouse
events to allow for seamless handling of distortion correction set
ups, there is chance that this might have broken something that I
haven't yet observed in my own testing.  Other than this there hasn't
been any changes that effect culling.

Do you see problems with using osgviewer?

Robert.

On 22 May 2013 14:59, Judson Weissert jud...@mfrac.com wrote:
 Hello,

 I have recently upgraded to the 3.1.6 development release of the OSG library
 (from 3.1.2) and encountered some behavior changes when manipulating a model
 using the Trackball Manipulator (I did derive from it though and modify some
 non-mouse related
 features).

 Compiled by VS2010, running on Windows 7 64-bit.

 Basically, when I throw (release mouse while dragging) the view using
 either the middle mouse button (pan), or the right mouse button (move
 towards/away), the model disappears from view entirely, and the statistics
 view shows the triangle count as zero. Statically placed HUD geometry (not
 usually affected by the manipulator at all) is also culled.

 I looked through the Changelog and source code changes a bit, but I feel
 like I am searching for a needle in a haystack.

 Does anyone know of any changes in the culling logic or Trackball
 manipulator that might explain this behavior?

 Thanks,

 Judson
 ___
 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] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

[Judson Weissert]

Robert,

On 5/22/2013 10:23 AM, Robert Osfield wrote:

HI Judson,

I have done a refactor of osgViewer's internally handling of mouse
events to allow for seamless handling of distortion correction set
ups, there is chance that this might have broken something that I
haven't yet observed in my own testing.  Other than this there hasn't
been any changes that effect culling.

Do you see problems with using osgviewer?


The osgviewer application does not seem to exhibit the problem. Also, it 
does not happen when emulating a throw manipulation on a touch screen 
(via a rightclick emulation and drag).


I switched back to using the standard osgGA::TrackballManipulator, but 
it did not solve my problem.


I will continue searching.

Thanks,

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

Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

[Judson Weissert]

Robert,

The viewer I am running has ON_DEMAND frame updates. When I remove the line

viewer-setRunFrameScheme (osgViewer::ViewerBase::ON_DEMAND);

the disappearing geometry behavior goes away. However, I was not able to 
replicate the problem by applying ON_DEMAND frame updating to the 
osgviewer application.


Thus, there is still a piece of the puzzle that I am missing.

Regards,

Judson

On 5/22/2013 12:10 PM, Judson Weissert wrote:

Robert,

On 5/22/2013 10:23 AM, Robert Osfield wrote:

HI Judson,

I have done a refactor of osgViewer's internally handling of mouse
events to allow for seamless handling of distortion correction set
ups, there is chance that this might have broken something that I
haven't yet observed in my own testing.  Other than this there hasn't
been any changes that effect culling.

Do you see problems with using osgviewer?


The osgviewer application does not seem to exhibit the problem. Also, 
it does not happen when emulating a throw manipulation on a touch 
screen (via a rightclick emulation and drag).


I switched back to using the standard osgGA::TrackballManipulator, but 
it did not solve my problem.


I will continue searching.

Thanks,

Judson
___
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] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

[Robert Osfield]

Hi Judson,

It's a curious set of circumstances but as yet I can't think of a
specific cause.

Is there any chance you can create a small example that illustrates
the problem so that I can try it out and see if I can spot the
problems.

Cheers,
Robert.

On 22 May 2013 18:31, Judson Weissert jud...@mfrac.com wrote:
 Robert,

 The viewer I am running has ON_DEMAND frame updates. When I remove the line

 viewer-setRunFrameScheme (osgViewer::ViewerBase::ON_DEMAND);

 the disappearing geometry behavior goes away. However, I was not able to
 replicate the problem by applying ON_DEMAND frame updating to the osgviewer
 application.

 Thus, there is still a piece of the puzzle that I am missing.

 Regards,

 Judson


 On 5/22/2013 12:10 PM, Judson Weissert wrote:

 Robert,

 On 5/22/2013 10:23 AM, Robert Osfield wrote:

 HI Judson,

 I have done a refactor of osgViewer's internally handling of mouse
 events to allow for seamless handling of distortion correction set
 ups, there is chance that this might have broken something that I
 haven't yet observed in my own testing.  Other than this there hasn't
 been any changes that effect culling.

 Do you see problems with using osgviewer?


 The osgviewer application does not seem to exhibit the problem. Also, it
 does not happen when emulating a throw manipulation on a touch screen (via a
 rightclick emulation and drag).

 I switched back to using the standard osgGA::TrackballManipulator, but it
 did not solve my problem.

 I will continue searching.

 Thanks,

 Judson
 ___
 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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

[Judson Weissert]

Robert,

I have made some progress. The problem appears to be caused by an 
eventTimeDelta of zero which is calculated within 
StandardManipulator::performMovement(). It eventually results in a 
divide by zero and the propagation of non-finite value(s) through the 
remainder of the call chain. Specifically, dy in 
OrbitManipulator::zoomModel() and OrbitManipulator::panModel() ends up 
being a non-finite value.


Thus, I have found an explanation for the symptoms, but I have not 
tracked down the underlying cause of eventTimeDelta being calculated as 
zero. Therefore, I have not been able to create a small example case yet.


Regards,

Judson

On 5/22/2013 2:37 PM, Robert Osfield wrote:

Hi Judson,

It's a curious set of circumstances but as yet I can't think of a
specific cause.

Is there any chance you can create a small example that illustrates
the problem so that I can try it out and see if I can spot the
problems.

Cheers,
Robert.



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

Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6

[Judson Weissert]

Robert,

I found the revision that caused the regression. Ironically, it occurred 
way before the 3.1.6 release...


See r13092 associated with 
http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk/src/osgViewer/Viewer.cpp


The 3.1.2 behavior returned when I reverted that revision. A notable 
behavior change that I noticed is that before I reverted r13092, the 
OSG_INFOReset event time from ... line in EventQueue::takeEvents() 
would trigger extremely often (e.g., while hovering over the viewer 
window). It does not trigger at all after I reverted r13092.


See also the cutOffTime variable in Viewer::eventTraversal() which 
explains the link to ON_DEMAND frame scheduling.


Do you happen to know the original intention of r13092? The log message 
is Moved the frame() event into the event traversal after then events 
and their state have been accumulated.


Thanks for the help,

Judson


On 5/22/2013 3:02 PM, Judson Weissert wrote:

Robert,

I have made some progress. The problem appears to be caused by an 
eventTimeDelta of zero which is calculated within 
StandardManipulator::performMovement(). It eventually results in a 
divide by zero and the propagation of non-finite value(s) through the 
remainder of the call chain. Specifically, dy in 
OrbitManipulator::zoomModel() and OrbitManipulator::panModel() ends up 
being a non-finite value.


Thus, I have found an explanation for the symptoms, but I have not 
tracked down the underlying cause of eventTimeDelta being calculated 
as zero. Therefore, I have not been able to create a small example 
case yet.


Regards,

Judson

On 5/22/2013 2:37 PM, Robert Osfield wrote:

Hi Judson,

It's a curious set of circumstances but as yet I can't think of a
specific cause.

Is there any chance you can create a small example that illustrates
the problem so that I can try it out and see if I can spot the
problems.

Cheers,
Robert.



___
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] Camera navigation confusion

[Robert Osfield]

Hi Jamie,

To use a wii remote with the OSG I'd either write a custom
CameraManipulator to do this integration and provide the appropriate
view matrix (via the getInverseMatrix() method) or just directly set
the viewer's Camera's ViewMatrix directly and not use a
CameraManipulator at all.  Either of these route would avoid the
potential pitfall of your code modifying the CameraManipulator's
matrix only for this to be over written by CameraManpulator's own
update methods.

For the direction issue, this is likely an issue with either ordering
of the transform you are setting up or the coordinate frame.  I know
nothing of the specific wii coordinate frame so can't comment
specifically on this.

Robert.

On 20 March 2013 11:17, Jamie Spence js...@hw.ac.uk wrote:
 Hello!

 I am trying to navigate around my scene using the following code which works 
 for pitch and roll (read from a wiimote using the wiiuse library) but when 
 forward motion is applied, the camera only travels along one axis, not along 
 the vector of it's facing direction. Is there a way of making the camera 
 travel in the direction it is looking by a set value?


 Code:

 osg::Matrixd m = viewer.getCameraManipulator()-getMatrix(), m2;
 m2.makeRotate(osg::DegreesToRadians(pitch/100), -1, 0, 0);
 m *= m2;
 m2.makeRotate(osg::DegreesToRadians(roll/100), 0 , 1, 0);
 m *= m2;
 osg::Vec3f vec = m2.getRotate().asVec3();
 vec.normalize();
 m2.makeTranslate(vec);
 m *= m2;
 viewer.getCameraManipulator()-setByMatrix(m);




 Thanks,

 illumi

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=53170#53170





 ___
 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] Camera manipulator zoomFactor

[Peter Bako]

I am sorry about the useless topic.
I was searching the property on a wrong object

manipulator-setWheelZoomFactor()

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=53189#53189





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

Re: [osg-users] Camera Manipulator problem

[Robert Osfield]

Hi Peterakos,

There isn't any way a third party will be able to diagnose the problem
with your code with such a tiny extract of code.  The best I can
suggest is develop your own skills of hunting down and fixing bugs.
Using a debug to see the flow of control, or add debug message that
output results to the console so you can learn about what is
happening.  With looking things more closely the problem in your code
should jump out.

Robert.

On 19 February 2013 01:32, Peterakos hay...@gmail.com wrote:
 Hello.

 I try to make my own camera manipulator in which the push events with
 X lower than the half of the window will be ignored.

 I created a class, which derives trackball manipulator.
 Here is the handle method

 virtual bool handle( const osgGA::GUIEventAdapter ea,
 osgGA::GUIActionAdapter us )   {
 if (ea.getEventType() == osgGA::GUIEventAdapter::PUSH 
 isInBounds(ea.getX(), ea.getY())) {
 return true;
 }
 return osgGA::TrackballManipulator::handle(ea, us);
 }

 Even though I return true (which means i dont want further handle), it
 keeps taking into account the event.

 Is there anything wrong with the code above ?

 thnx.
 ___
 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] Camera manipulator velocity and home() calculation affected after scaling nodes

[Regina Howard]

You can find it from the settings.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49674#49674





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

Re: [osg-users] Camera Default Light

[Robert Osfield]

Hi Laith,

On 12 September 2012 11:03, Laith Dhawahir laithbasildot...@gmail.com wrote:
 How can I change or set the camera default light ?

You don't set a Camera's default light, rather you can set a View's
default light, see include/osg/View or provide the appropriate Light
via an osg::LightSource placed into the scene graph.  Note, that
osgViewer::Viewer subclasses from osg::View (via osgViewer::View).

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

Re: [osg-users] Camera Default Light

[Laith Dhawahir]

Hi Robert,

Thanks alot, yes what you said is 100% correct :) thanks for your time 

Thank you!

Cheers,
Laith

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49989#49989





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

Re: [osg-users] Camera manipulator velocity and home() calculation affected after scaling nodes (partially resolved)

[Judson Weissert]

On 8/27/2012 3:14 PM, Jeremy Moles wrote:
 A Drawable can have a special ComputeBoundsCallback() (something like
 that, I'm on my phone right now and can't look it up), so you could use
 that as well...
Here is the code I came up with after your suggestion that does resolve
my problem (I attach the callback directly to the PAT in question):

[code]

/// This callback is used to prevent the bounding sphere associated with a
/// osg::PositionAttitudeTransform from modifying the bounding sphere due to
/// its scaling factor.
class keep_bounding_sphere_t : public
osg::Node::ComputeBoundingSphereCallback
{
public:
  keep_bounding_sphere_t ();

  keep_bounding_sphere_t (const osg::Vec3 axes);

  keep_bounding_sphere_t (
const keep_bounding_sphere_t other, const osg::CopyOp copyop
  );

  META_Object (anonymous, keep_bounding_sphere_t);

  /* * * osg::Node * * */

  virtual osg::BoundingSphere
  computeBound (const osg::Node node) const;

private:
  /// The axes that might be scaled and should be checked.
  /// e.g. osg::Z_AXIS to check only the z-axis.
  osg::Vec3 axes_;
};

keep_bounding_sphere_t::keep_bounding_sphere_t ()
: ComputeBoundingSphereCallback (),
  axes_ (1.0f, 1.0f, 1.0f)
{
}

keep_bounding_sphere_t::keep_bounding_sphere_t (const osg::Vec3 axes)
: ComputeBoundingSphereCallback (),
  axes_ (axes)
{
}

keep_bounding_sphere_t::keep_bounding_sphere_t (
  const keep_bounding_sphere_t other, const osg::CopyOp copyop )
: ComputeBoundingSphereCallback (other, copyop),
  axes_ (other.axes_)
{
}

osg::BoundingSphere
keep_bounding_sphere_t::computeBound (const osg::Node node) const
{
  osg::BoundingSphere out = node.computeBound ();

  const osg::PositionAttitudeTransform *pat =
dynamic_cast const osg::PositionAttitudeTransform * (node);
  if (!pat)
return out;

  osg::Vec3d scale = pat-getScale ();

  double sscale = 1.0;
  if (axes_.x ())
sscale = scale.x ();
  if (axes_.y ()  scale.y ()  sscale)
sscale = scale.y ();
  if (axes_.z ()  scale.z ()  sscale)
sscale = scale.z ();

  if (sscale)
out.set (out.center () , out.radius () / sscale);

  return out;
}

[/code]

My understanding of Transform::computeBound() could be better, but in my
case, it was effectively multiplying the bounding sphere radius by the
scaling factor even though the scaling factor only applied to a single
axis and should not have been a factor when calculating the boundary sphere.

Thus, the code above works provided the extent of the geometry along the
axis being scaled will never be larger than the extent of the geometry
along the other axes. I can think of a few improvements to this code
(like compute the bounds of the child node(s) directly then determine
what to do with the scale values). However, does this seem like a
proper/common approach to solving this problem? Another approach might
be to override the PositionAttitudeTransform node directly?

Regards,

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

Re: [osg-users] Camera manipulator velocity and home() calculation affected after scaling nodes

[Jeremy Moles]

On Mon, 2012-08-27 at 13:54 -0400, Judson Weissert wrote:
 Hello,
 
 I was hoping someone could help me with a camera manipulator/scaling
 problem that I have been having.
 
 I have a scene graph that contains geometry representing a hydraulic
 fracture. The fracture length is of the order 1000ft, the height is of
 the order 100ft, and the width is of the order .01ft. I am trying to
 appy a width exaggeration factor to the model in order to artificially
 inflate the geometry along the width axis (in my case it is along the
 z-axis). To accomplish this, I call
 osg::PositionAttitudeTransform::setScale(osg::Vec3d(1.0, 1.0, 100.0)) on
 the PAT node that I use to orient the fracture in the model. This works
 as expected, and the fracture width is exaggerated. However, the camera
 manipulator (osgGA::TrackballManipulator) does not return to the same
 home position. The larger the scale value, the further the home position
 seems to be from the model. Also, the velocity of the camera (model
 distance / screen pixel distance) when manipulated via the mouse
 increases with the scale value. That is, dragging the mouse an inch on
 the screen results in a larger camera manipulation when the scale value
 is increased.
 
 Perhaps I am making some false assumptions regarding how the camera
 manipulators and scaling operations interact? Is the scaling operation
 messing up a bounding box calculation somewhere? I tried computing then
 drawing the bounding box of the root node, but it did not seem to change
 for either case. That is, the exaggerated fracture width does not make
 the overall volume of the scene any larger (as far as I can tell).

I've been working on a custom OrthographicCameraManipulator (and have
done FirstPersonShooter and other kinds of CameraManipulators in the
past) and I've never seen this behave OTHER than how you're describing.

Scaling the PAT will definitely affect the home position of the
osgGA::StandardManipulator, so you may end up having to do something
like:

osgGA::CameraManipulator* cm = viewer.getCameraManipulator();

cm-setHomePosition(...);

That should also set autoComputeHomePosition to false, so it'll stick.

I could, of course, be misunderstanding the question. :)

 Additional information:
 
 Lib Version: OpenSceneGraph 3.1.2 (Compiled with VS2010 on Windows 7 64-bit)
 Manipulator: osgGA::TrackballManipulator
 
 Any hints/tips would be greatly appreciated.
 
 Thank you,
 
 Judson Weissert
 ___
 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] Camera manipulator velocity and home() calculation affected after scaling nodes

[Jeremy Moles]

On Mon, 2012-08-27 at 15:12 -0400, Judson Weissert wrote:
 On 8/27/2012 2:22 PM, Jeremy Moles wrote:
  On Mon, 2012-08-27 at 13:54 -0400, Judson Weissert wrote:
  Hello,
 
  I was hoping someone could help me with a camera manipulator/scaling
  problem that I have been having.
 
  I have a scene graph that contains geometry representing a hydraulic
  fracture. The fracture length is of the order 1000ft, the height is of
  the order 100ft, and the width is of the order .01ft. I am trying to
  appy a width exaggeration factor to the model in order to artificially
  inflate the geometry along the width axis (in my case it is along the
  z-axis). To accomplish this, I call
  osg::PositionAttitudeTransform::setScale(osg::Vec3d(1.0, 1.0, 100.0)) on
  the PAT node that I use to orient the fracture in the model. This works
  as expected, and the fracture width is exaggerated. However, the camera
  manipulator (osgGA::TrackballManipulator) does not return to the same
  home position. The larger the scale value, the further the home position
  seems to be from the model. Also, the velocity of the camera (model
  distance / screen pixel distance) when manipulated via the mouse
  increases with the scale value. That is, dragging the mouse an inch on
  the screen results in a larger camera manipulation when the scale value
  is increased.
 
  Perhaps I am making some false assumptions regarding how the camera
  manipulators and scaling operations interact? Is the scaling operation
  messing up a bounding box calculation somewhere? I tried computing then
  drawing the bounding box of the root node, but it did not seem to change
  for either case. That is, the exaggerated fracture width does not make
  the overall volume of the scene any larger (as far as I can tell).
  I've been working on a custom OrthographicCameraManipulator (and have
  done FirstPersonShooter and other kinds of CameraManipulators in the
  past) and I've never seen this behave OTHER than how you're describing.
 
  Scaling the PAT will definitely affect the home position of the
  osgGA::StandardManipulator, so you may end up having to do something
  like:
 
  osgGA::CameraManipulator* cm = viewer.getCameraManipulator();
 
  cm-setHomePosition(...);
 
  That should also set autoComputeHomePosition to false, so it'll stick.
 
  I could, of course, be misunderstanding the question. :)
 
 Thank you.
 
 After thinking about what you said, I figured I would revisit my bounding box 
 code. I must have made a mistake the first time around because this time I do 
 get a completely different bounding box for the scene when the scale changes. 
 Therefore, the code that is computing the home position thinks that it needs 
 to view a huge volume, even though most of that volume does not actually 
 contain any drawables.
 
 Therefore, I think I need to fix the bounds calculation and then I will still 
 be able to rely on the default ComputeHomePosition algorithm. So far I have 
 just relied on the default bounds() calculations.
 
 Thanks,

A Drawable can have a special ComputeBoundsCallback() (something like
that, I'm on my phone right now and can't look it up), so you could use
that as well...

 Judson
 


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

Re: [osg-users] Camera manipulator velocity and home() calculation affected after scaling nodes

[Judson Weissert]

On 8/27/2012 2:22 PM, Jeremy Moles wrote:
 On Mon, 2012-08-27 at 13:54 -0400, Judson Weissert wrote:
 Hello,

 I was hoping someone could help me with a camera manipulator/scaling
 problem that I have been having.

 I have a scene graph that contains geometry representing a hydraulic
 fracture. The fracture length is of the order 1000ft, the height is of
 the order 100ft, and the width is of the order .01ft. I am trying to
 appy a width exaggeration factor to the model in order to artificially
 inflate the geometry along the width axis (in my case it is along the
 z-axis). To accomplish this, I call
 osg::PositionAttitudeTransform::setScale(osg::Vec3d(1.0, 1.0, 100.0)) on
 the PAT node that I use to orient the fracture in the model. This works
 as expected, and the fracture width is exaggerated. However, the camera
 manipulator (osgGA::TrackballManipulator) does not return to the same
 home position. The larger the scale value, the further the home position
 seems to be from the model. Also, the velocity of the camera (model
 distance / screen pixel distance) when manipulated via the mouse
 increases with the scale value. That is, dragging the mouse an inch on
 the screen results in a larger camera manipulation when the scale value
 is increased.

 Perhaps I am making some false assumptions regarding how the camera
 manipulators and scaling operations interact? Is the scaling operation
 messing up a bounding box calculation somewhere? I tried computing then
 drawing the bounding box of the root node, but it did not seem to change
 for either case. That is, the exaggerated fracture width does not make
 the overall volume of the scene any larger (as far as I can tell).
 I've been working on a custom OrthographicCameraManipulator (and have
 done FirstPersonShooter and other kinds of CameraManipulators in the
 past) and I've never seen this behave OTHER than how you're describing.

 Scaling the PAT will definitely affect the home position of the
 osgGA::StandardManipulator, so you may end up having to do something
 like:

   osgGA::CameraManipulator* cm = viewer.getCameraManipulator();

   cm-setHomePosition(...);

 That should also set autoComputeHomePosition to false, so it'll stick.

 I could, of course, be misunderstanding the question. :)

Thank you.

After thinking about what you said, I figured I would revisit my bounding box 
code. I must have made a mistake the first time around because this time I do 
get a completely different bounding box for the scene when the scale changes. 
Therefore, the code that is computing the home position thinks that it needs to 
view a huge volume, even though most of that volume does not actually contain 
any drawables.

Therefore, I think I need to fix the bounds calculation and then I will still 
be able to rely on the default ComputeHomePosition algorithm. So far I have 
just relied on the default bounds() calculations.

Thanks,

Judson

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

Re: [osg-users] Camera manipulation with trackball manipulator

[Robert Osfield]

Hi Zak,

I would recommend writing your own CameraManipulator to do exactly
what you want, or simply set the Viewer's Camera's ViewMatrix directly
yourself on each new frame.

Robert.

On 3 August 2012 16:42, Zak Stromquist strom...@umn.edu wrote:
 Hi,

 I'm trying to create a camera at a fixed location that can be rotated using a 
 manipulator.

 From what I've read, it looks like a trackball manipulator might be the way 
 to do this.  The only problem is that when I set it up, in order to keep the 
 camera at the fixed location, the eye and center of the trackball need to be 
 the same.  This leads to a bad starting view.

 Is there any way to get around this while still using a trackball 
 manipulator, or would something else work better?

 ...

 Thank you!

 Cheers,
 Zak

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=49161#49161





 ___
 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] camera manipulator proposal

[Riccardo Corsi]

Hi Robert,

I agree that the Camera as an argument makes more sense.
Thanks for merging the submission.

Cheers,
Ricky



On Mon, Jul 9, 2012 at 7:38 PM, Robert Osfield robert.osfi...@gmail.comwrote:

 Hi Riccardo,

 On review of the submission I've decided that passing in a Camera
 rather than a pointer would make it clear that a valid Camera object
 should be passed in rather than a pointer which could be NULL or
 pointing to a valid Camera object.  This brings the method more into
 line with how this type of method is invoked elsewhere in the OSG.

 Cheers,
 Robert.
 ___
 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] camera manipulator proposal

[Robert Osfield]

Hi Riccardo,

Sorry for the very long delay in getting to review your suggested
changes, I've now done the review and the changes look good, the only
amendment I made to rename the parameter name Camera* pCamera to
Camera* camera as from the context it's obvious that camera is a
Camera* one doesn't need to add extra short hand in the name to make
this clear, rather the extra p just makes the code less human
readable.

Changes now merged and submitted to svn/trunk.

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

Re: [osg-users] camera manipulator proposal

[Robert Osfield]

Hi Riccardo,

On review of the submission I've decided that passing in a Camera
rather than a pointer would make it clear that a valid Camera object
should be passed in rather than a pointer which could be NULL or
pointing to a valid Camera object.  This brings the method more into
line with how this type of method is invoked elsewhere in the OSG.

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

Re: [osg-users] Camera help

[Braden Edmunds]

Never mind. I'm an idiot. Spherical Manipulator.

Cheers,
Braden

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=47538#47538





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

Re: [osg-users] camera manipulator proposal

[Riccardo Corsi]

Hi Robert and All,

I just wanted to know if the proposal I made some weeks ago doesn't seem to
fit some requirements,
or simply passed unnoticed.

Thank you,
Ricky


On Wed, Mar 14, 2012 at 15:42, Riccardo Corsi riccardo.co...@kairos3d.itwrote:

 Hi all,

 sorry that it took long to setup the proposal...
 Eventually the code change was minimal:

 1. added a method void updateCamera(osg::Camera*) on CameraManip base
 class. I propose a default implementation that sets the camera view matrix
 by using the existing getInverseMatrix method, so that standard
 manipulators don't need any change.

 2. viewer classes call the new method instead of setting explicitly the
 camera view matrix, for instance:

 //old call -_camera-setViewMatrix(_cameraManipulator-getInverseMatrix());
 _cameraManipulator-updateCamera(_camera);

 This brings enough flexibility for the cases that I have in mind at the
 moment.

 The changed files are in the attached zip, based on osg 3.1.0.
 If it's better not to provide a default implementation for the new method,
 I can remove it and re-implement it in all derived manipulators.

 If the approach looks reasonable I will make a submission out of it.

 Ricky



 On Tue, Mar 6, 2012 at 17:06, Robert Osfield robert.osfi...@gmail.comwrote:

 HI Ricky,

 On 6 March 2012 14:36, Riccardo Corsi riccardo.co...@kairos3d.it wrote:
  I totally agree on the general approach.
  Still, if you want to go for the change on the  osgGA::CameraManipulator
  base class as a first step,
  I'd be glad to help with that.

 Why not have a bash at modifying osgGA::CameraManipulator to work for
 the purpose you have in mind then post this as proposal, we can then
 tweak this if required.

 Robert.
 ___
 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] camera manipulator proposal

[Robert Osfield]

Hi Riccardo,

On 5 April 2012 11:37, Riccardo Corsi riccardo.co...@kairos3d.it wrote:
 I just wanted to know if the proposal I made some weeks ago doesn't seem to
 fit some requirements,
 or simply passed unnoticed.

I'm afraid I haven't had a chance to review it yet.

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

Re: [osg-users] Camera attached to object

[Sergey Bocharov]

Hi, Sergey 

I cannot get the right result. 
Please help me if you can.
79250103663

... 

Thank you!

Cheers,
Sergey

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=46581#46581





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

Re: [osg-users] Camera attached to object

[Sergey Bocharov]

Anyone knows how to do this?

Thank you!

Cheers,
Sergey

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=46424#46424





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

Re: [osg-users] Camera attached to object

[Sergey Bocharov]

Hi, Sergey

Я уже голову сломал с этими матрицами.

;-)

Cheers,
Sergey

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=46433#46433





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

Re: [osg-users] Camera attached to object

[Sergey Bocharov]

zonk wrote:
 Hi Sergey,
 
 why don't you use OSGs standard nodetrackermanipulator?
 You can track a node and configure which DOF are controllable via the 
 manipulator.
 
 
 Cheers,
 Torben


Hi Torben nodetrackermanipulator allow to sen node as point of view and camera 
flying around this node. I need the same thing but camera must be at the node 
and point of view flying around camera. Is in possible with 
nodetrackermanipulator?

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=46405#46405





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

Re: [osg-users] Camera attached to object

[Torben Dannhauer]

Hi Sergey,

why don't you use OSGs standard nodetrackermanipulator?
You can track a node and configure which DOF are controllable via the 
manipulator.


Cheers,
Torben

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=46175#46175





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

Re: [osg-users] Camera attached to object

[Sergey Bocharov]

Hi, Sergey

if I have a Viewer  , scene and node in this scene how can a attach smart 
camera to this Viever

something like this?


Code:
#include UserTrackballManip

  osg::ref_ptrosgGA::KeySwitchMatrixManipulator keyswitchManipulator = new 
osgGA::KeySwitchMatrixManipulator;

keyswitchManipulator-addMatrixManipulator( '1', Trackball, new 
UserTrackballManip() );
viewer.setCameraManipulator( keyswitchManipulator.get() );




Cheers,
Sergey

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=46156#46156





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

Re: [osg-users] camera manipulator proposal

[Robert Osfield]

Hi Riccardo,

The current osgGA::CameraManipulator's are a bit of mess, the way they
just control the view matrix is one of their flaws.  I merged a set of
sweeping changes from Jan Perciva back in May 2010 that added a new
inheritance hierarchy and more features, but in hindsight I feels
these have just made them more convoluted in design and
implementation.

Rather than tweak the current CameraManilulator API I feel that a
wholesale review of osgGA and the CameraManipulator is long overdue.
We have new devices such as multi-touch and MS's Kinect, as well as
old ones like joysticks that are really not served properly by osgGA.
We really should try and tie these all together.  Perhaps this should
be an objective for 3.4.

In terms of osgGA::CameraManipulator base class I'd like to distil it
down to it's core functionality - allowing a manipulator to control a
Camera.  Potentially we could introduce this change prior to the
wholesale revamp.

Robert.

On 5 March 2012 17:35, Riccardo Corsi riccardo.co...@kairos3d.it wrote:
 Hi Robert and All,

 in more than one occasion I've noticed that having access to the camera
 manipulator in use is not enough to have full control over the camera
 motion handling.

 An example is if you want to temporary disable the manip to set the camera
 position explicitly (in this case you need to remove the manipulator from
 the viewer, not to get the position overwritten),
 or if you want to write a manip for an ortho camera, in which case you need
 access to the camera's projection matrix as well.

 At the same time we need to preserve the loose coupling between the camera
 and its manipulator.

 I think that a possible approach would be a virtual method in the base
 camera manip like:
 virtual void osgGA::CameraManipulator::UpdateCamera(osg::Camera* pCam)
 to be invoked by the viewer classes.
 Instead of asking the ViewMatrix to the manipulators, they would call this
 method passing the reference camera and leaving the matrix assignments to
 the implementation.

 Do you think it's a reasonable approach?
 The porting of the existing manipulators to the new interface would be an
 easy task.

 Please give me some feedback,
 if you like the approach I can submit a patch.

 Thanks,
 Ricky

 ___
 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] camera manipulator proposal

[Riccardo Corsi]

Hi Robert,

I totally agree on the general approach.
Still, if you want to go for the change on the  osgGA::CameraManipulator
base class as a first step,
I'd be glad to help with that.

Ricky

On Tue, Mar 6, 2012 at 11:44, Robert Osfield robert.osfi...@gmail.comwrote:

 Hi Riccardo,

 The current osgGA::CameraManipulator's are a bit of mess, the way they
 just control the view matrix is one of their flaws.  I merged a set of
 sweeping changes from Jan Perciva back in May 2010 that added a new
 inheritance hierarchy and more features, but in hindsight I feels
 these have just made them more convoluted in design and
 implementation.

 Rather than tweak the current CameraManilulator API I feel that a
 wholesale review of osgGA and the CameraManipulator is long overdue.
 We have new devices such as multi-touch and MS's Kinect, as well as
 old ones like joysticks that are really not served properly by osgGA.
 We really should try and tie these all together.  Perhaps this should
 be an objective for 3.4.

 In terms of osgGA::CameraManipulator base class I'd like to distil it
 down to it's core functionality - allowing a manipulator to control a
 Camera.  Potentially we could introduce this change prior to the
 wholesale revamp.

 Robert.

 On 5 March 2012 17:35, Riccardo Corsi riccardo.co...@kairos3d.it wrote:
  Hi Robert and All,
 
  in more than one occasion I've noticed that having access to the camera
  manipulator in use is not enough to have full control over the camera
  motion handling.
 
  An example is if you want to temporary disable the manip to set the
 camera
  position explicitly (in this case you need to remove the manipulator from
  the viewer, not to get the position overwritten),
  or if you want to write a manip for an ortho camera, in which case you
 need
  access to the camera's projection matrix as well.
 
  At the same time we need to preserve the loose coupling between the
 camera
  and its manipulator.
 
  I think that a possible approach would be a virtual method in the base
  camera manip like:
  virtual void osgGA::CameraManipulator::UpdateCamera(osg::Camera* pCam)
  to be invoked by the viewer classes.
  Instead of asking the ViewMatrix to the manipulators, they would call
 this
  method passing the reference camera and leaving the matrix assignments to
  the implementation.
 
  Do you think it's a reasonable approach?
  The porting of the existing manipulators to the new interface would be an
  easy task.
 
  Please give me some feedback,
  if you like the approach I can submit a patch.
 
  Thanks,
  Ricky
 
  ___
  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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] camera manipulator proposal

[Robert Osfield]

HI Ricky,

On 6 March 2012 14:36, Riccardo Corsi riccardo.co...@kairos3d.it wrote:
 I totally agree on the general approach.
 Still, if you want to go for the change on the  osgGA::CameraManipulator
 base class as a first step,
 I'd be glad to help with that.

Why not have a bash at modifying osgGA::CameraManipulator to work for
the purpose you have in mind then post this as proposal, we can then
tweak this if required.

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

Re: [osg-users] Camera and Animation Path

[Robert Osfield]

Hi Paul,

osgGA::AnimationPathManipulator is pretty simply to use and it's setup
is illustrated in applications/osgviewer/osgviewer.cpp, just search
for AnimationPathManipualtor.

Robert.

On 21 November 2011 15:15, Paul Leopard paul.leop...@gmail.com wrote:
 Hi,

 Has anyone found any good example code for attaching the camera to an 
 animation path? Unfortunately all of the example code I have found is very 
 dated and due to a deadline I am unable to go back and learn Producer and 
 then how to port it to osgGA. I'm trying to find some example code so I can 
 quickly achieve the animation ... any example code would be greatly 
 appreciated.

 I have a trajectory of a missile that I have animated with an animation path 
 and all works well. Now I need to put the camera on the head of the missile 
 and orient it according to the direction the missile seeker is pointing.

 Thank you!

 Cheers,
 Paul

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=43979#43979





 ___
 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] Camera control in osgvisual

[Roy Arents]

Thanks for the update Torben. I'll keep you posted on our descision and 
hopefully progress after that

Cheers,
Roy

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=42790#42790





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

Re: [osg-users] Camera control in osgvisual

[Torben Dannhauer]

Hi Rooi,

Viijesh told me he will send me his working stage. I'm still waiting, havn't 
recieved any files yet.

I personally haven't started with the implementation, still a lot of other 
things on my to-do stack.

One of the osgvisual users i'm currently working with has implemented a X-Plane 
connection and uses it experimentally. I'm also waiting for that connection if 
it helps you.

I would like to stay in contact if you decide to start the implementation of an 
OSG/CIGI implementation.

Cheers,
Torben

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=42712#42712





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

Re: [osg-users] Camera control in osgvisual

[Roy Arents]

Hi Vijeesh and Torben,

Interesting discussion. I'm looking into possibilities to connect osg using the 
cigi interface myself. Could you please indicate what the status of this 
develpoment is and if I could contribute to this if we descide to use osgVisual 
for our application?

Thank you!

Cheers,
Roy

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=42621#42621





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

Re: [osg-users] Camera returns NULL viewport on Windows but not Linux

[Robert Osfield]

HI Paul,

On Wed, Aug 10, 2011 at 2:38 PM, Sebastian Messerschmidt
sebastian.messerschm...@gmx.de wrote:
 Hi Paul,

 This is expected behaviour as far as I know.
 The viewer camera won't return you a viewport if more than one device
 context is used (i.e. more than monitor)

Sebastien is correct, the osgViewer by default will automatically
create multiple windows, one per screen, and use a slave Camera
attached to the Viewer for each of the windows.  Since the slave
Cameras are now taking on the task of managing the windows the
viewer's master Camera doesn't have a window assigned to it, and as
consequence it won't have or need a viewport.

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

Re: [osg-users] Camera returns NULL viewport on Windows but not Linux

[Paul Leopard]

Understood, Thanks for the help

Regards,
Paul

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=42029#42029





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

Re: [osg-users] Camera returns NULL viewport on Windows but not Linux

[Paul Leopard]

I successfully built v3.0.1 last night and tried it this morning. Same issue 
... Still a NULL pointer

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=41976#41976





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

Re: [osg-users] Camera returns NULL viewport on Windows but not Linux

[Paul Leopard]

Ok now I am making some progress. If I set the environment variable OSG_SCREEN 
to 1 then the problem goes away and the pointer returns valid. Evidently this 
is related to another problem that I've been having ... I have dual monitors 
and OSG apps open up spanning both monitors with the left monitor functioning 
properly and the right monitor remaining a static frame.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=41977#41977





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

Re: [osg-users] Camera returns NULL viewport on Windows but not Linux

[Sebastian Messerschmidt]

Hi Paul,

This is expected behaviour as far as I know.
The viewer camera won't return you a viewport if more than one device 
context is used (i.e. more than monitor)



Ok now I am making some progress. If I set the environment variable OSG_SCREEN 
to 1 then the problem goes away and the pointer returns valid. Evidently this 
is related to another problem that I've been having ... I have dual monitors 
and OSG apps open up spanning both monitors with the left monitor functioning 
properly and the right monitor remaining a static frame.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=41977#41977





___
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] Camera returns NULL viewport on Windows but not Linux

[Jeremy Moles]

On Tue, 2011-08-09 at 22:05 +0200, Paul Leopard wrote:
 I have some code I have inherited that was developed on Linux. I am trying to 
 get a Windows version of it to run but there is an inconsistency that I am 
 unable to explain. Perhaps someone here has seen this issue before ...
 
 Anyway, the problem is that on Windows (OSG v2.9.9 and v3.0.0) I get a NULL 
 viewport pointer with the following (pseudocode) call to getViewport() :
 
 Code:
 osg::ArgumentParser arguments(argc,argv);
 osgViewer::Viewer viewer(arguments);
 viewer.addEventHandler(...);
 osg::Group* root = new osg::Group;
 root-addChild( ... );
 viewer.frame();

Try viewer.realize() here instead; not sure it'll change anything, but
it's worth a shot.

 osg::Camera* camera = viewer.getCamera();
 assert(camera!=NULL); // Ok
 osg::Viewport* pViewPort = camera-getViewport();
 assert(pViewPort !=NULL); // FAILS! NULL POINTER
 
 
 
 
 On Linux the pointer is valid, on Windows it is always NULL. Am I missing 
 something here or has anyone else had this issue?
 
 
 Thanks!
 Paul
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=41955#41955
 
 
 
 
 
 ___
 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] Camera returns NULL viewport on Windows but not Linux

[Paul Leopard]

Thanks for the reply but it didn't fix anything ...

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=41958#41958





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

Re: [osg-users] Camera set to RTT, texture never changes

[Wojciech Lewandowski]

Hi Kris,

Unfortunatelly I cannot offer you a working code example. But I have few 
observations that could help I believe. For sure you have an error in 
glBindTexture call. It should be called with GL texture object id. You can 
obtain it from your RTT texture with 
getTextureObject(state-getContextID() );
Next I suppose that FBO_RENDER_TEXTURE_UNIT is a texture stage unit. 
glActiveTexture is the GL function which sets texture stage. Even if you 
call it there is another catch need to know, call it as
glActiveTexture( GL_TEXTURE0 + FBO_RENDER_TEXTURE_UNIT )  because GL enum 
fror texture stages does not start from 0 like OSG stages do.


However, instead of using gl functions i suggest you use OSG equivalents 
that would do all neccessary GL work for you and you would not risk 
desyncing OSG state with GL state . Code may look like this :


void FBOFinalRenderCallback::operator () (osg::RenderInfo renderInfo) const
{
   osg::State * state = renderInfo.getState();

   state-applyMode( GL_TEXTURE_RECTANGLE, true );
   state-setActiveTextureUnit(FBO_RENDER_TEXTURE_UNIT);
   renderTexture-apply(*state);

   glGetTexImage(renderTexture-getTextureTarget(),
 0,
 renderTexture-getInternalFormat(),
 renderTexture-getSourceType(),
 data);
}

However, the best solution for you in my opinion would be using osg::Image 
instead of osg::Texture as a RTT camera attachment. If osg::Image is 
attached OSG automatically reads the image contents after draw. So you just 
have the updated data in the image available all the time. See osgprerender 
for example code. If you insist on using your own callback you may debug 
this example and see how image contents are refreshed and use the original 
OSG source as guidance for your code.


HTH  Cheers,
Wojtek



-Oryginalna wiadomość- 
From: Kris Dale

Sent: Saturday, June 04, 2011 12:48 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Camera set to RTT, texture never changes

Happy Friday everyone.

Forgive me if this turns out to be a terribly trivial problem.  I'm still a 
rookie with GL/OSG/graphics in general.


I'm attempting to get a two camera system set up, one RTT.  I'm attempting 
to read the texture back into an unsigned char array during a callback each 
frame.  My scene graph is set up such that I have:



Code:

viewer
|_ setSceneData()
  |_topNode(osg::Group)
 |_FBOCamera(set to prerender)
|_SceneRoot(osg::Group)




I don't have any nodes added under the viewer's main camera currently.

The setup for my FBOCamera is:


Code:

   primaryCamera-setFinalDrawCallback(new 
FBOFinalRenderCallback(renderTexture));


   FBOCamera-setClearColor(Vec4f(1., 1., 1., 1.));
   FBOCamera-setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
   FBOCamera-setViewport(0, 0, WIDTH, HEIGHT);
   //FBOCamera-setViewMatrixAsLookAt(Vec3d(0., 0., 0.), Vec3d(0., 1., 0.), 
Vec3d(0., 0., 1.));

   FBOCamera-setViewMatrix(Matrixd::identity());
   //FBOCamera-setProjectionMatrixAsPerspective(60., 
(double)WIDTH/(double)HEIGHT, NEAR, FAR);

   FBOCamera-setProjectionMatrix(Matrixd::identity());

   FBOCamera-setRenderOrder(Camera::PRE_RENDER);
   FBOCamera-setRenderTargetImplementation(Camera::FRAME_BUFFER_OBJECT);
   FBOCamera-attach(Camera::BufferComponent(Camera::COLOR_BUFFER), 
renderTexture);







The setup for my texture is:

Code:

   StateSet *stateSet = topNode-getOrCreateStateSet();
   stateSet-setTextureAttributeAndModes(FBO_RENDER_TEXTURE_UNIT, 
renderTexture, StateAttribute::ON);


   renderTexture-setTextureSize(WIDTH, HEIGHT);
   renderTexture-setSourceFormat(GL_RGBA);
   renderTexture-setInternalFormat(GL_RGBA8UI);
   renderTexture-setSourceType(GL_UNSIGNED_BYTE);
   renderTexture-setFilter(Texture2D::MIN_FILTER, Texture2D::NEAREST);
   renderTexture-setFilter(Texture2D::MAG_FILTER, Texture2D::NEAREST);
   renderTexture-setWrap(Texture::WRAP_S, Texture::CLAMP_TO_EDGE);
   renderTexture-setWrap(Texture::WRAP_T, Texture::CLAMP_TO_EDGE);
   renderTexture-setWrap(Texture::WRAP_R, Texture::CLAMP_TO_EDGE);





My callback gets a ref_ptr to the texture.  Then each frame it:

Code:


   glBindTexture(GL_TEXTURE_RECTANGLE, FBO_RENDER_TEXTURE_UNIT);

   glGetTexImage(renderTexture-getTextureTarget(),
 0,
 renderTexture-getInternalFormat(),
 renderTexture-getSourceType(),
 data);

   glBindTexture(GL_TEXTURE_RECTANGLE, 0);

   PostCallbackValidateData(); // prints all the values in data to the 
console







When I print data to the screen, all I get are the values I initially 
populated data with.  I never even get the clear color for the camera.  What 
I've written looks right when compared to other things I've seen done.  What 
am I missing here?


(As an aside:  am I right in calling FBOCamera that?  I presume that by 
setting the camera to RTT, it's got to be using an FBO's GL_COLOR_BUFFER 
behind the scenes, even if I don't 

Re: [osg-users] Camera backgroundtransparency and viewport border

[Paul Martz]

On 4/24/2011 2:15 PM, Zuzana Číková wrote:

I have one main and one slave camera, I would like to make the background of 
the slave camera semi transparent so I can see the main camera rendering. How 
is this possible? I have spheres visualized in both cameras and these dont have 
to be semitransparent, just the background.


Hm. Did you try disabling clear on the slave camera? Set the clear mask to 0, or 
set it to clear just the depth buffer.



Other thing, I wish I could border the viewport of the slave camera, so it 
would be directly visible that bordered part is the one of slave camera.


Use the same technique as you would for a fullscreen quad or triangle pair, but 
use a GL_LINE_STRIP primitive instead.

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

Re: [osg-users] Camera intrinsics

[benedikt naessens]

Keith Parkins wrote:
 After looking at this again, I am unclear as to whether you have built
 the projection matrix from the intrinsic parameters. I was assuming that
 you had made it by hand. To do that you would do something like this:
 
 //-//
  
 // The _intrinsic variable holds the five values for the intrinsic
 // matrix. The intrinsic * our pixel transform to get the projections
 // matrix. The intrinsic values (itr[]) are given as five doubles
 // such that: 
 //
 //| itr[0] itr[1] itr[2]  |
 //|   0itr[3] itr[4]  |
 //|   0  0  0 |
 //
 //| alpha_u gamma u_0  |
 //|   0alpha_v v_0 |
 //|   0  0  0  |
 //
 //-//
 
 void 
 -Camera::calcProjection() {
 double alpha_u, alpha_v;
 
 // calc alphas
 alpha_u = _intrinsic[0];
 double cot_theta = - _intrinsic[1]/_intrinsic[0];
 double sin_theta = sqrt(1/(1+cot_theta*cot_theta));
 alpha_v = _intrinsic[3] * sin_theta;
 
 double skew = _intrinsic[1];
 
 double u0, v0;
 u0 = _intrinsic[2]; v0 = _intrinsic[4];
 
 double left = -u0 / alpha_u * _near;
 double bottom = (_screen_height-v0) / alpha_v * _near;
 double right = (_screen_width - u0) / alpha_u * _near;
 double top = -v0 / alpha_v * _near;
 
 _projection[0] = 2 * _near / (right - left);
 _projection[4] = 2 * _near * skew / ((right - left) * alpha_u);
 _projection[5] = 2 * _near / (top - bottom);
 _projection[8] = -(right + left)/(right - left);
 _projection[9] = -(top + bottom)/(top - bottom);
 _projection[10] = (_far + _near) / (_far - _near);
 _projection[11] = 1;
 _projection[14] = -2 * _far * _near/(_far-_near);
 
 |}
 
 
 /lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 

___
osg-users mailing list

http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

 --
Post generated by Mail2Forum[/quote]

There seems to be a mismatch between the projection matrix generated by e.g. 
makePerspective and the projection matrix elements you suggest here.

When I do the comparison between the two, it seems that: 
_projection[5], _projection[8], _projection[9] and _projection[11] have 
opposite signs. 

I'm also a bit surprised that the projection matrix generated by OSG 
(makePerspective) has -1 instead of 1 for _projection[11]. Maybe that has 
something to do with the inversion of the Y axis (0,0 in the bottom left 
instead of the top left) ?

Can you give me a suggestion why these differences exist ?

Thanks !
Benedikt.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=38253#38253





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

Re: [osg-users] Camera intrinsics

[Keith Parkins]

Hi Benedikt,

I don't have time to look at this right now, but off the top of my head
the sign difference that you noticed may be because I grabbed this from
a reverse projection that I did (the projection was bounced off some
mirrors to a back projection which in turn was viewed by looking into
another mirror). So if everything was flipped when you tried this, that
was probably the reason why.

-K

On Wed, 6 Apr 2011, benedikt naessens wrote:



Keith Parkins wrote:

After looking at this again, I am unclear as to whether you have built
the projection matrix from the intrinsic parameters. I was assuming that
you had made it by hand. To do that you would do something like this:

//-//
// The _intrinsic variable holds the five values for the intrinsic
// matrix. The intrinsic * our pixel transform to get the projections
// matrix. The intrinsic values (itr[]) are given as five doubles
// such that:
//
//| itr[0] itr[1] itr[2]  |
//|   0itr[3] itr[4]  |
//|   0  0  0 |
//
//| alpha_u gamma u_0  |
//|   0alpha_v v_0 |
//|   0  0  0  |
//
//-//

void
-Camera::calcProjection() {
double alpha_u, alpha_v;

// calc alphas
alpha_u = _intrinsic[0];
double cot_theta = - _intrinsic[1]/_intrinsic[0];
double sin_theta = sqrt(1/(1+cot_theta*cot_theta));
alpha_v = _intrinsic[3] * sin_theta;

double skew = _intrinsic[1];

double u0, v0;
u0 = _intrinsic[2]; v0 = _intrinsic[4];

double left = -u0 / alpha_u * _near;
double bottom = (_screen_height-v0) / alpha_v * _near;
double right = (_screen_width - u0) / alpha_u * _near;
double top = -v0 / alpha_v * _near;

_projection[0] = 2 * _near / (right - left);
_projection[4] = 2 * _near * skew / ((right - left) * alpha_u);
_projection[5] = 2 * _near / (top - bottom);
_projection[8] = -(right + left)/(right - left);
_projection[9] = -(top + bottom)/(top - bottom);
_projection[10] = (_far + _near) / (_far - _near);
_projection[11] = 1;
_projection[14] = -2 * _far * _near/(_far-_near);

|}


/lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




___
osg-users mailing list

http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

--
Post generated by Mail2Forum[/quote]

There seems to be a mismatch between the projection matrix generated by e.g. 
makePerspective and the projection matrix elements you suggest here.

When I do the comparison between the two, it seems that:
_projection[5], _projection[8], _projection[9] and _projection[11] have 
opposite signs.

I'm also a bit surprised that the projection matrix generated by OSG 
(makePerspective) has -1 instead of 1 for _projection[11]. Maybe that has 
something to do with the inversion of the Y axis (0,0 in the bottom left 
instead of the top left) ?

Can you give me a suggestion why these differences exist ?

Thanks !
Benedikt.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=38253#38253





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



Keith ParkinsU of R Center for Visual Science
kpark...@cvs.rochester.edu   Meliora Hall, Room 253
office: (585) 275-2460   lab: (585) 275-2230
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Camera control in osgvisual

[Torben Dannhauer]

Hi Vijeesh,

not the slot mechanism itself push the values into the visual_objects (I think 
the cigi name is entity), but every visual_object has an attached updater 
class. This updater class is executed during the OSG update traversal, and it 
pulls the values it requires from the slot mechanism.

I chose that pulling design to make it more flexible. In that case every 
object with it's updater has to manage it's data aquisition on its own (by 
subclassing of the updater class), the only common part every object has is 
that they retrieve there data from the central data management module  - from 
the slots.

In a pushing design, the central data management module would have to be 
aware of all used object types to be able to update it. This makes it more 
difficult to add additional object types.

Any thoughts/ideas related to the data design?

For deeper understanding of the current object design and data flow, please 
read this wiki pages:

http://www.osgvisual.org/projects/osgvisual/wiki/visual_dataIO
http://www.osgvisual.org/projects/osgvisual/wiki/visual_object


Cheers,
Torben

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=38059#38059





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

Re: [osg-users] Camera control in osgvisual

[Vijeesh Theningaledathil]

Hi Torben

I'm sorry. I couldn't get your question. According to my knowledge, the cigi 
event processsors(classes) are event queues. so we just have to process and 
discard the data. 
I incorpaorated the example code from DumyIG  example which is bundled with 
CIGI.

Thank you!

Cheers,
Vijeesh

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=37991#37991





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

Re: [osg-users] Camera control in osgvisual

[Torben Dannhauer]

Hi Vijeesh,

Your guess was right, I asked if the cigi event processor can be discarded 
after procession or if we have to store them.

So what would be the next stept I have to do to help you?

Best regards,

Torben

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=37992#37992





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

Re: [osg-users] Camera control in osgvisual

[Vijeesh Theningaledathil]

Hi Torban

I implemented dataIO_extLinkCIGI::readTO_OBJvalues() with the code to receive 
cigi packet and decode it. So on each dataIO_eventCallback, The viewcontrol 
data is available  as a structure. Now I need to map it to the particular slots 
as you did for VCL from where the camera is controlled, I guess. So I need to 
know how to map the structure to slots. 

... 

Thank you!

Cheers,
Vijeesh

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=38003#38003





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

Re: [osg-users] Camera control in osgvisual

[Torben Dannhauer]

Hi Vijeesh,

here is some explanation how the SLOT mechanism works currently:

it is a list of SLOT classes.

A slot class contains the following members:
* string name
* double value
* string sValue  (string value)
* enum direction: TO_OBJ | FROM_OBJ
* enum type: STRING | DOUBLE

If a software module wants to store some values which are directed TO the 
visual Objects ( e.g. object3_LAT), it searches in this list for the slot with 
the corresponding name,  type and direction and stores the value in it.

The object updater for example reads on every update in this slot list for a 
slot with the appropriate name and read the value to apply it to its own object.


This has the the following implications:
* Supposed to be very slow if lot's of variables are used: if someone searches 
in the list, he has to perform many string comparisons.
* Only strings and doubles can be stored but no complex data structures ( e.g. 
cigi containers)


My approach with the slots was only a first shot.

I would be very glad if we could discuss this, maybe also with other users in 
the forum. It would be great to construct a more sophisticated and usefull 
architecture to manage the data of the IG.

After that I would implement this solution asap, but currently I have no idea 
in which direction we should proceed.


Thank you!

Cheers,
Torben

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=38007#38007





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

Re: [osg-users] Camera control in osgvisual

[Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC]

Most of the IG industry uses CIGI to pass data from the host to the IG
(and back for end of frame and mission functions stuff). I'm sure the
architecture is well defined on this. 

For starters, you can take a look at Boeing's Multi Purpose Viewer
software which is an IG test bed for the CIGI protocol. They interface
it to a generic host. The Multi Purpose Viewer uses OSG on the backend
for rendering.

This might give you some ideas on what you can do to add CIGI into your
IG stuff...

-Shayne


-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Torben
Dannhauer
Sent: Tuesday, March 29, 2011 6:45 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Camera control in osgvisual

Hi Vijeesh,

here is some explanation how the SLOT mechanism works currently:

it is a list of SLOT classes.

A slot class contains the following members:
* string name
* double value
* string sValue  (string value)
* enum direction: TO_OBJ | FROM_OBJ
* enum type: STRING | DOUBLE

If a software module wants to store some values which are directed TO
the visual Objects ( e.g. object3_LAT), it searches in this list for the
slot with the corresponding name,  type and direction and stores the
value in it.

The object updater for example reads on every update in this slot list
for a slot with the appropriate name and read the value to apply it to
its own object.


This has the the following implications:
* Supposed to be very slow if lot's of variables are used: if someone
searches in the list, he has to perform many string comparisons.
* Only strings and doubles can be stored but no complex data structures
( e.g. cigi containers)


My approach with the slots was only a first shot.

I would be very glad if we could discuss this, maybe also with other
users in the forum. It would be great to construct a more sophisticated
and usefull architecture to manage the data of the IG.

After that I would implement this solution asap, but currently I have no
idea in which direction we should proceed.


Thank you!

Cheers,
Torben

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=38007#38007





___
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] Camera control in osgvisual

[Vijeesh Theningaledathil]

Hi Torben

Thanks for your explanation on slots mechanism. Still I couldn't make out where 
the slot values are assigned to observer position and attitude. I'll look in to 
MPV implementation and see any better implementation. 

... 

Thank you!

Cheers,
Vijeesh

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=38058#38058





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

Re: [osg-users] Camera control in osgvisual

[Torben Dannhauer]

Hi Vijeesh,

sorry for my late reply, I was on a trip the last days. You explanation helped 
me to understand Cigi better.

I have some additional questions:
do we need to store the transfered SIGI contains in the IG to store the 
transfered value, or are the cigi classes only a incoming event queue?

If the latter is true, it should be sufficient to process and discard the 
incoming cigi transport classes, shouldn't it?
 
Regarding terrain modification: This modification currently works only for 
databases which use osgTerrain Framework. I use a VPB generated database. The 
modification is done at runtime. But I planned to implement a caching feature 
which allows to cache modified tiles. Currently I do not know if the cache will 
be persistent or only per run.



Thank you!

Cheers,
Torben

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=37933#37933





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

Re: [osg-users] Camera control in osgvisual

[Vijeesh Theningaledathil]

Hi Torben

I was trying to integrate CIGI to osgvisual. I could subclass extlink for cigi 
and data is receiving from host. Now I don't know how to connect the values to 
camera. I looked into VCL implementation but it just writes the data to a 
dataslot. But in CIGI case packet is received as a structure. So how to convert 
the structure to the slot. Please tell me. Once this is finished, I'll send you 
the full source for your review. Thanks


Thank you!

Cheers,
Vijeesh

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=37830#37830





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