Re: [osg-users] Maintaining a reference to an osg node outside of osg
Hi Preet, On 17/03/12 8:09 , Preet wrote: If I do this, then I need to maintain the underlying ref_ptr object no? This isn't particularly convenient. What was wrong with assigning the osg::Node's pointer to mysteryPtr instead? Basically with ... osg::ref_ptrosg::Node someNode; mysteryPtr = someNode.Get(); As long as the pointer returned by the Get() method is valid for the lifetime of the object I'm safe right? Then if I want to do anything with object: osg::ref_ptrosg::Node someNode = some_cast_callosg::Node*(mysteryPtr); someNode-partyAllDay(); That's not going to work terribly well, the Get() method simply cannot make guarantees that the pointer is valid. You *MUST* keep a osg::ref_ptr around to keep the object alive, otherwise you'll end up with a stale pointer to a deleted object at some point. So you might as well do that inside your struct. Without knowing your plans in detail I'd think about using a virtual base class as an interface (call it IMysteryStruct) that has a public method to return a void* if you need it (although I don't see a use for that). This is the class that you'd pass around internally. Then you can make derived classes, such as OsgMysteryStruct (which has an internal osg::ref_ptr to the object in question) or a SharedMysteryStruct (which has an internal shared_ptr to some object). Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Maintaining a reference to an osg node outside of osg
Hi Preet, On 16 March 2012 19:53, Preet prismatic.proj...@gmail.com wrote: Typically I use osg::ref_ptr to let osg handle reference counting. Right now I'm trying to create a 'rendering engine' for another library with osg. The idea for the other library is to maintain an API that allows different rendering engines -- osg, ogre, vtk, etc. Others have amply answered the ref counting question so I won't add anything further than this. I would like to question the idea of adding an rendering API abstraction layer. VTK is a very different beast to OSG or OGRE, and the later two while have more in common which each other than they do with the approach of VTK are still very different in design and implementation. This will mean the abstraction layer would have to do a lot of work just to try and fit them all into the same box. In doing this fitting you'll almost certainly make it harder to do any advance usage of the underlying API that you are actively using at any time. What you are gunning for is hard to design, hard to implement and hard to maintain. The next question I'd like to pose to what do you gain for this abstraction layer? The Pain is high with the approach you want to take, so the benefit will have to be huge Personally I can't think of a good reason to justify all the pain and hampering of final functionality. I would recommend not going to the lengths of trying to abstract away from the API's. Work out what you need to do with your application, work out what you need from your rendering API and match this up against the candidates in front of you. All of the candidates have been around for a good period and are mature SDK's each with their own strengths and weakness, but one thing for sure is that they have lived long enough and have big enough communities to know that they will be around for a good while longer and there all open source, so there isn't any reason to hedge your bets on which one will be around in 5 or 10 years time, there is a good chance they all will be. So work out which one fits best and pick it and discard the rest. This approach will be the most productive in the short term, mid term and long term. Software projects are typically hard enough as it is without putting extra roadblocks of complexity in your way. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Maintaining a reference to an osg node outside of osg
Hiya,
Typically I use osg::ref_ptr to let osg handle reference counting.
Right now I'm trying to create a 'rendering engine' for another
library with osg. The idea for the other library is to maintain an API
that allows different rendering engines -- osg, ogre, vtk, etc. The
other library has virtual methods that are called when objects need to
be added and removed from the scene, ie:
void RemoveObjectFromScene(SomeStruct myStruct)
The objects can be thought of as having a 1:1 relation with osg nodes.
I'd like to maintain a reference to the osg node corresponding to the
object so I don't have to traverse the scene graph to find a given
node (there are a lot of objects and this would get way too expensive
I think). I can modify SomeStruct as long as its library-agnostic --
so no osg specific stuff goes in there. Could I use a void * or
something similar to store a reference?
SomeStruct
{
void * mysteryPtr;
}
{
osg::ref_ptrosg::Node myNode = new osg::node; // 1 ref to myNode
m_persistant_root_node-addChild(myNode); // 2 refs to myNode
mysteryPtr = myNode.get(); // 2 refs to myNode (no change!)
}
// 1 refs to myNode since ref_ptr has gone out of scope as long as
m_persistent_root_node is alive
// mysteryPtr has NO bearing to any ref counting, except for the
fact that's its a valid pointer to osg::node as
// long as we have 0 refs to it
I'd be very grateful if someone could verify the above logic. If I'm
in the wrong here, I'd appreciate any advice pointing me in the right
direction.
Regards,
Preet
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Maintaining a reference to an osg node outside of osg
I'd be very grateful if someone could verify the above logic. If I'm in the wrong here, I'd appreciate any advice pointing me in the right direction. You should be able to do that (and you could probably use RTTI features to figure out what the OSG type/class mystery pointer was pointing to) as long as you realize that if an OSG node is disposed of, your mystery pointer is going to give you a mystery crash. You could also consider having it be a pointer to an entry in a table (stored/maintained outside of your struct/library code) of ref_ptrs or observer pointers. -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Training • Consulting • Contracting 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL Digital Imaging • GIS • GPS • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Maintaining a reference to an osg node outside of osg
What you're trying to do is the PIMPL design pattern. I'll leave the details to Google :) You may also want to brush up on the Factory design pattern for generating your opaque handles. In a direct answer to your question, no you can't use a void* to store a ref_ptr (without some trickery). You can, however, store a pointer to a ref_ptr as a void* . Then when you need to use it, convert it like this to avoid having to double dereference it every time you use it. Code: ref_ptr Node node = *reinterpret_cast ref_ptr Node *(mysteryPtr); And don't forget to delete the pointer to the ref_ptr when you're done. if you leak the ref_ptr the node will never get collected. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46372#46372 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Maintaining a reference to an osg node outside of osg
Hi, On Fri, Mar 16, 2012 at 4:43 PM, John Kaniarz john.kani...@us.army.mil wrote: What you're trying to do is the PIMPL design pattern. I'll leave the details to Google :) You may also want to brush up on the Factory design pattern for generating your opaque handles. In a direct answer to your question, no you can't use a void* to store a ref_ptr (without some trickery). You can, however, store a pointer to a ref_ptr as a void* . Then when you need to use it, convert it like this to avoid having to double dereference it every time you use it. If I do this, then I need to maintain the underlying ref_ptr object no? This isn't particularly convenient. What was wrong with assigning the osg::Node's pointer to mysteryPtr instead? Basically with ... osg::ref_ptrosg::Node someNode; mysteryPtr = someNode.Get(); As long as the pointer returned by the Get() method is valid for the lifetime of the object I'm safe right? Then if I want to do anything with object: osg::ref_ptrosg::Node someNode = some_cast_callosg::Node*(mysteryPtr); someNode-partyAllDay(); Code: ref_ptr Node node = *reinterpret_cast ref_ptr Node *(mysteryPtr); And don't forget to delete the pointer to the ref_ptr when you're done. if you leak the ref_ptr the node will never get collected. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46372#46372 ___ 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
