Robert Osfield | 1 Nov 10:13 2010
Picon

Re: License Questions

Hi Eric,

Independent modules having difference licenses doesn't conflict at all
with the OSGPL.  The OpenSceneGraph is a collection of various
libraries, plugins and examples.  The core libraries are all OSGPL,
and most of the plugins, but not all, and when the license differs it
is typically down to a 3rd party dependency or the license that the
code originally came from.

If you own usage of the OSG in your application is incompatible with
the GPL then you simply need to avoid relying upon those modules.

Robert.

On Fri, Oct 29, 2010 at 5:41 PM, Eric Buehler <osg@...> wrote:
> Hi,
>
> The following files seem to have a license (GPL v2) that conflicts with the OSGPL license.  Should these
be in the src base?
>
>
> examples/osganimationviewer/AnimtkViewerKeyHandler.cpp
> examples/osganimationviewer/AnimtkViewerKeyHandler
> src/osgPlugins/md2/anorms.h
> src/osgPlugins/net/sockstream.cpp
> src/osgPlugins/net/sockinet.cpp
> src/osgPlugins/net/sockstream.h
> src/osgPlugins/quicktime/QuicktimeImageStream.h
> src/osgPlugins/vnc/ReaderWriterVNC.cpp
> src/osgPlugins/xine/video_out_rgb.h
(Continue reading)

Robert Osfield | 1 Nov 10:14 2010
Picon

Re: [build] GL/glu.h "No such file" Error when Building

Hi Jimmy,

OSG-2.8.x all rely upon the GLU external dependency.

In the svn/trunk version of the OSG the parts of GLU that the OSG
usages have been directly integrated into the OSG code base so you no
longer require the external GLU library.

Robert.

On Thu, Oct 28, 2010 at 5:52 AM, Jimmy Carter <kg4sgp@...> wrote:
> Hello all,
>     I know is probably something simple I'm overlooking but when I try to make OSG I get this error (below).
I'm new to both OpenGL and OSG, any help would be greatly appreciated! I am building OSG 2.8.3
>
> [  5%] Building CXX object src/osg/CMakeFiles/osg.dir/Geometry.o
> [  5%] Building CXX object src/osg/CMakeFiles/osg.dir/GL2Extensions.o
> [  5%] Building CXX object src/osg/CMakeFiles/osg.dir/GLExtensions.o
> In file included from /OpenSceneGraph-2.8.3/src/osg/GLExtensions.cpp:15:0:
> /OpenSceneGraph-2.8.3/include/osg/GLU:23:24: fatal error: GL/glu.h: No such file or directory
> compilation terminated.
> make[2]: *** [src/osg/CMakeFiles/osg.dir/GLExtensions.o] Error 1
> make[1]: *** [src/osg/CMakeFiles/osg.dir/all] Error 2
> make: *** [all] Error 2
>
> Thanks,
> Jimmy Carter
>
> ------------------
> Read this topic online here:
(Continue reading)

Ted Morris | 1 Nov 22:34 2010
Picon

hiding objects from a cloned scenegraph hides the original...

Hi,

I am cloning a scenegraph for a 2nd viewer for osgCompositeView. Everytime I setNodeMask(0x0) to some
objects that is part of the cloned node the objects in the original disappears as well, unless it is a
CopyOp::DEEP_COPY_ALL.  The problem with using  DEEP_COPY_ALL is that it makes the UpdateCallback
process a mess-- since I then have to contrive other mechanisms to tie in the existing, callbacks for
objects in the original scene with the 'secondary' view's cloned scene graph.

Or, I have to end up walking the scenegraph tree, and doing appropriate clone level flags, one by one?? 

Thanks to all in advance!

Ted

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

Simon Kolciter | 1 Nov 23:45 2010
Picon

Re: Real-Time geometry editing - changing positions

Hi,

I have another problem with this.

In a vertices array assigned to a Geometry object, I want to assign different materials to vertices => use a
brush to give this texture to this vertex, that textrue to that vertex etc...just like you in the Crysis
Editor, for example.

1. Is there a way to configure the StateSet object or the Geometry object to somehow "tell" each vertex what
texture it should use (given I don't want to change the order of the vertices - which I fear I will have to)?

2. Won't this be a bit of a problem for the performance?

3. The edited model has a spherical shape, so I would like the textures to be displayed as in a spherical
environment. Is there a way to compute the TexCoord Vec2's in a similar way as UVW Map modifier for max, but
in real time?

I know that doing this stuff would be easier in an existing editor and just exporting, but I am making an
editor that is supposed to this real time.

Btw thanks Skylark for the answer earlier
Thank you!

Cheers,
Simon

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

(Continue reading)

David Glenn | 2 Nov 01:53 2010
Picon

Re: OSG greensceen


deltaaruna wrote:
> Hi,
> 
> Can we make a green screen with openscenegraph
> 
> Thank you!
> 
> Cheers,
> Aruna

if your talking about changing the background to a Chroma Key a view for say taking an image and editing it on 
another background. And Yes, I have Done this in OSG as part of a Genlock device!
You can change the background color of your view by setting the clearcolor for the camera your using. 

Ex: mycamera->setClearColor(osg::vec4d(0.0f,0.0f,1.0f,1.0f));

Hope thats what you want! If I'm totaly off, well! Sorry!

D Glenn

------------------------
D Glenn (a.k.a David Glenn) - Join the Navy and See the World ... from your Desk!

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

Lv Qing | 2 Nov 07:40 2010
Picon

How to delete a NodeCallback*?

Hi,

//simply define a node and a NodeCallback

osg::Node* node          = new  osg::Node;
osg::NodeCallback* nc = new  osg::NodeCallback;

//setup the nodecallback,no problem

node -> setUpdateCallBack(nc );

//remove the nodecallback,no problem

node -> setUpdateCallBack(NULL);
or 
node -> removeUpdateCallBack(nc );

//want to release the osg::NodeCallback* memory ,crash every time!
if (nc ) delete nc; 

Don't know why,need help!
... 

Thank you!

Cheers,
Lv

------------------
Read this topic online here:
(Continue reading)

Ulrich Hertlein | 2 Nov 07:52 2010
Picon

Re: How to delete a NodeCallback*?

On 2/11/10 17:40 , Lv Qing wrote:
> //setup the nodecallback,no problem
> 
> node -> setUpdateCallBack(nc );
> 
> //remove the nodecallback,no problem
> 
> node -> setUpdateCallBack(NULL);
> or 
> node -> removeUpdateCallBack(nc );
> 
> //want to release the osg::NodeCallback* memory ,crash every time!
> if (nc ) delete nc; 

Yeah, don't do that.

> Don't know why,need help!

You're holding a raw pointer to a reference counted object.  The reference count drops to
zero when you call 'setUpdateCallback(NULL)' or 'removeUpdateCallback()' which deletes the
object.  When you then call 'delete nc' you try to delete an already deleted object.

Use osg::ref_ptr.

/ulrich
Wang Rui | 2 Nov 07:54 2010
Picon

Re: How to delete a NodeCallback*?

Hi Lv,

You will never need to manually delete your node callback object,
because it is manged by ref_ptr when added with setUpdateCallback().
It will be automatically released when no nodes referencing it (that
is why your application crashes when you explicitly deleted it again,
which is already a dangling pointer).

Cheers,

Wang Rui

2010/11/2 Lv Qing <donlvqing@...>:
> Hi,
>
>
> //simply define a node and a NodeCallback
>
> osg::Node* node          = new  osg::Node;
> osg::NodeCallback* nc = new  osg::NodeCallback;
>
> //setup the nodecallback,no problem
>
> node -> setUpdateCallBack(nc );
>
> //remove the nodecallback,no problem
>
> node -> setUpdateCallBack(NULL);
> or
> node -> removeUpdateCallBack(nc );
(Continue reading)

Anders Backman | 2 Nov 08:00 2010
Picon
Picon

Re: OT: VS2010 LNK2005 problem related to ostringstream

I don't think MS considers this to be a problem. It is by design. Not being able to derive from ANY stl classes is quite serious if you ask me. Fiddling around with allowing multiple symbols and other hacks does not really present it self as a stable and viable solution.


I managed to get around deriving from std::string by making it a pure template implementation, not using any dllimport/dllexport directives. That worked (of course). But as soon as you derive the interface, export it in a dll-file, it does not work. Unless you instantiate all symbols inside the dll. Then it get the correct linkage. Its really the mix between template and non-template code that causes the problem.

I don't think we can expect a solution for this any time soon. Unless someone has a brother working as a manager at the vs2010 team? :-)
Also, Incredibuild is heavily delayed for vs2010 (~4 months still encounting), seems that they have problems of the port over to vs2010 too.

/Anders

<div>
<p>I don't think MS considers this to be a problem. It is by design. Not being able to derive from ANY stl classes is quite serious if you ask me. Fiddling around with allowing multiple symbols and other hacks does not really present it self as a stable and viable solution.</p>
<div>

<br>
</div>
<div>I managed to get around deriving from std::string by making it a pure template implementation, not using any dllimport/dllexport directives. That worked (of course). But as soon as you derive the interface, export it in a dll-file, it does not work. Unless you instantiate all symbols inside the dll. Then it get the correct linkage. Its really the mix between template and non-template code that causes the problem.</div>

<div><br></div>
<div>I don't think we can expect a solution for this any time soon. Unless someone has a brother working as a manager at the vs2010 team? :-)</div>
<div>Also, Incredibuild is heavily delayed for vs2010 (~4 months still encounting), seems that they have problems of the port over to vs2010 too.</div>

<div><br></div>
<div>/Anders<br><br>
</div>
</div>
Filip Holm | 2 Nov 09:01 2010
Picon

Re: setUpdateCallback fails under slave-camera

Hi Timm,
 
I ran into a similar problem to what you have and solved it without having to modify the OSG Core source code. The problem is that osgViewer does not do eventTraversal and updateTraversal on the slave's subgraph regardless if they are using the mastersSceneData or not. I'm submitting a fix to this on osg-submission today, so hopefully it will be a part of the next OSG release.
 
To get around the problem you can add an eventCallback and a updateCallback to the slave camera that is not using the mastersSceneData and modify the traversal mode of the visitor within the callback to traverse the camera's subgraph.
 
 
class SlaveCameraUpdateCallback : public osg::NodeCallback
{
public:
 virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
 {
  if(nv->getVisitorType() == osg::NodeVisitor::UPDATE_VISITOR)
  {
   osg::NodeVisitor::TraversalMode tm = nv->getTraversalMode();
   nv->setTraversalMode(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN);
   traverse(node,nv);
   nv->setTraversalMode(tm);
  }
  else
  {
   traverse(node,nv);
  }
 }
};
{
 //Rigging up slave camera with it's own subgraph
 viewer.addSlave(camera,false);
 //Set updateCallback for camera to ensure subgraph updateTraversal
 camera->setUpdateCallback(new SlaveCameraUpdateCallback);
}
Filip

 
On Mon, Jul 20, 2009 at 5:25 PM, Timm Linder <timmlinder <at> yahoo.de> wrote:
Hi Robert,

I'm picking up this somewhat outdated topic since we are having a similar problem. We need to render some of our geometry with a separate depth buffer because of precision issues: In the first pass, we are rendering a very large landscape that was created using VirtualPlanetBuilder. This puts the far clipping plane very far away from the viewer.

Then, however, we need to draw some objects that are flying very close to the camera and need a lot of precision here. This is what makes us require a second rendering pass with a separate depth buffer and projection matrix (where the far plane is very close to the eye point). It is guaranteed that this geometry is always above the landscape, so we need no further sorting here.

In both passes, we require our update callbacks to work. As should have become clear from my description, the master and slave camera do not share their geometry.

Do you think there is a way of making the update callbacks work in the slave camera *without* tampering with the original OSG Core source code?

Any hint would be greatly appreciated.

Thanks a lot for your help,

Timm

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





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

<div>
<div>Hi Timm,</div>
<div>&nbsp;</div>
<div>I&nbsp;ran into a similar problem&nbsp;to what you have and solved it&nbsp;without having to modify the&nbsp;OSG Core source code. The problem is that osgViewer does not do eventTraversal and updateTraversal&nbsp;on the slave's subgraph regardless if they are using the mastersSceneData or not. I'm submitting a fix to this on osg-submission today, so hopefully it will be a part of the next OSG release.</div>

<div>&nbsp;</div>
<div>To get around the problem you can add an eventCallback and a&nbsp;updateCallback to the slave camera that is not using the mastersSceneData and modify the traversal mode of the visitor within the callback to traverse the camera's subgraph.</div>

<div>&nbsp;</div>
<div>&nbsp;</div>
<div>class SlaveCameraUpdateCallback : public osg::NodeCallback<br>{<br>public:<br>&nbsp;virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)<br>&nbsp;{ <br>&nbsp;&nbsp;if(nv-&gt;getVisitorType() == osg::NodeVisitor::UPDATE_VISITOR)<br>
&nbsp;&nbsp;{<br>&nbsp;&nbsp;&nbsp;osg::NodeVisitor::TraversalMode tm = nv-&gt;getTraversalMode();<br>&nbsp;&nbsp;&nbsp;nv-&gt;setTraversalMode(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN);<br>&nbsp;&nbsp;&nbsp;traverse(node,nv);<br>&nbsp;&nbsp;&nbsp;nv-&gt;setTraversalMode(tm);<br>&nbsp;&nbsp;}<br>&nbsp;&nbsp;else<br>
&nbsp;&nbsp;{<br>&nbsp;&nbsp;&nbsp;traverse(node,nv);<br>&nbsp;&nbsp;}<br>&nbsp;}<br>};</div>
<div>{<br>&nbsp;//Rigging up slave camera with it's own subgraph<br>&nbsp;viewer.addSlave(camera,false);<br>&nbsp;//Set updateCallback for camera to ensure subgraph updateTraversal<br>&nbsp;camera-&gt;setUpdateCallback(new SlaveCameraUpdateCallback);<br>
}<br>
</div>
<div>Filip</div>
<div>
<br>&nbsp;</div>
<div class="gmail_quote">On Mon, Jul 20, 2009 at 5:25 PM, Timm Linder <span dir="ltr">&lt;<a href="mailto:timmlinder@...">timmlinder <at> yahoo.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">Hi Robert,<br><br>I'm picking up this somewhat outdated topic since we are having a similar problem. We need to render some of our geometry with a separate depth buffer because of precision issues: In the first pass, we are rendering a very large landscape that was created using VirtualPlanetBuilder. This puts the far clipping plane very far away from the viewer.<br><br>Then, however, we need to draw some objects that are flying very close to the camera and need a lot of precision here. This is what makes us require a second rendering pass with a separate depth buffer and projection matrix (where the far plane is very close to the eye point). It is guaranteed that this geometry is always above the landscape, so we need no further sorting here.<br><br>In both passes, we require our update callbacks to work. As should have become clear from my description, the master and slave camera do not share their geometry.<br><br>Do you think there is a way of making the update callbacks work in the slave camera *without* tampering with the original OSG Core source code?<br><br>Any hint would be greatly appreciated.<br><br>Thanks a lot for your help,<br><br>Timm<br><br>------------------<br>Read this topic online here:<br><a href="http://forum.openscenegraph.org/viewtopic.php?p=15145#15145" target="_blank">http://forum.openscenegraph.org/viewtopic.php?p=15145#15145</a><br><br><br><br><br><br>_______________________________________________<br>osg-users mailing list<br><a href="mailto:osg-users@...">osg-users@...</a><br><a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
</blockquote>
</div>
<br>
</div>

Gmane