Re: [osg-users] osgEarth in OpenSceneGraph
Hi, osgViewer flawlessly worked with .osg files. But, it could view .earth models. It says there's a plugin named osg71-osg.dll. But I've osg55-osg.dll. I am using osg 2.8.4. I have checked for the missing dlls in the osg 2.9 version, but couldn't find one. It's very important as we're developing a good application. Thank you! .. Cheers, Sivaram. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39981#39981 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.5 RC2 and final call for testing
Hi all -- I've just committed the final feature, the backport of the trunk 3DS plugin. We're getting very close to a 2.8.5 final release! I've now created 2.8.5 RC2: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.5-rc2 Thanks to all for your testing so far. However, we need a final push for testing: Please go beyond simple build testing, and use your applications extensively with this RC. If there are no issues, I'll rename the tag as the final release. I'd like to do this no later than end of next week. Currently we're in a hard code freeze: no changes except for showstopper bug fixes. Thanks! Let me know how the testing goes! -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] glGenBuffers + OSG - returns 0 for all buffer IDs
Greetings all, I've been learning PBOs here lately, and I can't seem to find any tutorials about how to use OSG::PixelBufferObjects. If anyone can point me in the direction of one, that would be awesome, as I wouldn't have to mix OGL and OSG code quite as much as I'm doing now. Right now what I'm doing is trying to copy back the frame buffer to a PBO each frame, but I can't get glGenBuffers to return a valid buffer ID. I've tried passing in a single int or an array, but all I get back are 0's. (In a strict GLUT/GL project, I get 1,2,3..) I've made sure (as much as I can) that I have a context.. I've created a graphicscontext, a window exists, I've called viewer.realize(), even tried one viewer.frame() before glGenBuffers. All I can get back are 0's. So naturally when I try to bindbuffer / readpixels / mapbuffer, I just get back a null pointer because my bufferID is zero. Can anyone suggest a reason this might be happening? (Even if you can point me to a good OSG tutorial on using OSG::PixelBufferObjects, I'd still be curious to know.) Thanks in advance for any guidance anyone can offer.. Kris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39979#39979 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph hello
Wow what an amazing douche this person is Block him, before I'm tempted by his amazing offers. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph hello
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/31/2011 01:46 AM, dosto.wa...@gmail.com wrote: > OpenSceneGraph hello i wish someone had let me know about this sooner > http://g.msn... I suggest that someone deletes this from the forum, the link most likely distributes malware. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org/ iD8DBQFN5TdAn11XseNj94gRArUnAKDS8UzHwQS4/jpsRaY0q/t3mnGHSwCaAteW 1RnmnvbDmKhk2+cmo5kVsdE= =6IyS -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] [osgPPU] osgPPU and the stencil buffer
Hi David, > - Have you create an opengl context with a stencil buffer ? > - Have you try to use osg:ClearNode to clear the stencil buffer ? > - Have you check opengl call order in a debugger like gDEBugger ? - Yes I the context that osgViewer creates when realizing has a working stencil (I tested it). - No, I didn't know that one was allowed to put nodes such as osg::ClearNode inbetween osgPPU::Unit's - No, but I was planning to use GLintercept as a last resort > yes please, could be more simple to find the bug. Sure!, here it is: This function generates the whole pipeline and attaches its processor to an osg::Group which is returned Code: // This is a dirty workaround for not using an osg::ClearNode struct CamClearMaskCallback : public osgPPU::Unit::NotifyCallback { osg::Camera * m_cam; GLbitfield m_mask; CamClearMaskCallback(osg::Camera *cam, GLbitfield mask) : osgPPU::Unit::NotifyCallback(), m_cam(cam), m_mask(mask) {} virtual void operator()(osg::RenderInfo& ri, const osgPPU::Unit* u) const { m_cam->setClearMask(m_mask); if(m_mask & GL_STENCIL_BUFFER_BIT) { glClear(GL_STENCIL_BUFFER_BIT); //printf("CLEAR\n"); } else { //printf("\n"); } } }; osg::Group* MLAARendering::createMLAAPipeline(osg::Camera* camera) { osg::Group* finalGroup = new osg::Group; osg::ref_ptr clearStencilCallback = new CamClearMaskCallback(camera, GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT); osg::ref_ptr dontClearStencilCallback = new CamClearMaskCallback(camera, GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); osg::ref_ptr fragmentOptions = new osgDB::ReaderWriter::Options("fragment"); osg::ref_ptr vertexOptions = new osgDB::ReaderWriter::Options("vertex"); // Setup the clear mask and the stencil clear value camera->setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT); camera->setClearStencil(0); osg::Vec2f pixelSize(1.0/camera->getGraphicsContext()->getTraits()->width, 1.0/camera->getGraphicsContext()->getTraits()->height); // This stencil is intended to create the mask by writting a 1 to the stencil wherever a fragment is not discarded in the shader of the unit it's // attached to. However, the stencil test has to pass always and osgPPU disables the Z test, so I don't know if this is really working as I want! osg::Stencil * createMaskStencil = new osg::Stencil; { createMaskStencil->setFunctionRef(1); createMaskStencil->setFunction(osg::Stencil::ALWAYS); createMaskStencil->setWriteMask(1); createMaskStencil->setOperation(osg::Stencil::REPLACE, osg::Stencil::REPLACE, osg::Stencil::REPLACE); } // This one is intended to discard every fragment not masked by a 1 in the stencil osg::Stencil * useMaskStencil = new osg::Stencil; { useMaskStencil->setFunctionRef(1); useMaskStencil->setFunction(osg::Stencil::EQUAL);// TODO: TEMP!!, Should be osg::Stencil::EQUAL! useMaskStencil->setWriteMask(1); useMaskStencil->setOperation(osg::Stencil::KEEP, osg::Stencil::KEEP, osg::Stencil::KEEP); } // This is for testing purposes (it always passes and doesn't change the buffer) osg::Stencil * testStencil = new osg::Stencil; { testStencil->setFunction(osg::Stencil::ALWAYS,1,~0u); testStencil->setOperation(osg::Stencil::KEEP, osg::Stencil::KEEP, osg::Stencil::KEEP); } // Create a processor for this pipeline m_processor = new osgPPU::Processor(); m_processor->setName("Processor"); m_processor->setCamera(camera); osgPPU::UnitCameraAttachmentBypass* bypass = new osgPPU::UnitCameraAttachmentBypass(); { bypass->setBufferComponent(osg::Camera::COLOR_BUFFER0); bypass->setName("MLAA.mainCamOutputTex"); // I want the stencil to be cleared here, I don't really care if it's done before or after 'drawing' bypass->setBeginDrawCallback(clearStencilCallback.get()); } osgPPU::UnitCameraAttachmentBypass* bypassDepth = new osgPPU::UnitCameraAttachmentBypass(); { bypassDepth->setBufferComponent(osg::Camera::DEPTH_BUFFER); bypassDepth->setName("MLAA.mainCamOutputDepthTex"); } // First step: Edges detection and stencil mask creation edgeDetection = new osgPPU::UnitInOut(); edgeDetection->setName("MLAA.edgeDetectionUnit"); { edgeDepthShader = new osgPPU::ShaderAttribute(); edgeDepthShader->addShader(osgDB::readShaderFile("Shaders\\edge_depth_frag.frag", fragmentOptions.get()));
[osg-users] Interesting article on Qt scenegraph and its threading model
Perhaps now it is possible to render Qt Gui above OSG? http://labs.qt.nokia.com/2011/05/31/qml-scene-graph-in-master/ Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39975#39975 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Too long to generate the DEM with osgdem
Try using the --TERRAIN option in the osgdem command to see if that makes a difference in your build times... -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of ijustfu Sent: Friday, May 27, 2011 6:26 PM To: osg-users Subject: [osg-users] Too long to generate the DEM with osgdem Dear all, I am newer for using OSG. I compile gdal and VPB and rightly get all the files with VS2005. When I use osgdem to generate DEM, I find it generates .IVE and a folder of XXX-_root_L0_X0_Y0 . The problem is: It takes too long to generate the DEM. I check the time of file genration time and find the intervals between first several file is very short for level 0, level 1 and level 2. Coming to level 3 and after, the intervals are long, in my case 2 minutes or 3 minutes. So, after one and a half days, the DEM is only generated half. The input files are : Texture is: texture.tilf 70m 4019*4284 ; DEM is: height.tif 47m 4019*4284. The comand line to generate DEM is : osgdem -t texture.tif -d height.tif -l 8 -a mydem.osga Anybady can help me? Thanks a lot. 2011-05-28 ijustfu ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Robert, This looks pretty straightforward and I agree that less complexity is good. However a would modify it slightly to support two related features I have been lobbying for, which are the ability to share UserDataContainers between osg::Objects, and the ability to subclass a custom UserDataContainer implementation. The idea is that there is generally not a 1:1 correlation between the application entity model and the scene graph. Because of this, one often wants to be able to share or inherit metadata information, or look up metadata on the fly to avoid copying large amounts of application data into the scene graph. I think it feasible to add one level of indirection without adding too much complexity. For example: - Make osg::UserDataContainer a pure abstract class. class OSG_EXPORT UserDataContainer : public osg::Referenced { public: void addUserObject(Object* owner, Object* obj) = 0; void setUserObject(Object* owner, unsigned int i, Object* obj) = 0; void removeUserObject(Object* owner, unsigned int i); unsigned int getUserObjectIndex(Object* owner, const osg::Object* obj) const = 0; unsigned int getUserObjectIndex(Object* owner, const std::string& name) const = 0; Object* getUserObject(Object* owner, unsigned int i) = 0; const Object* getUserObject(Object* owner, unsigned int i) const = 0; Object* getUserObject(Object* owner, const std::string& name) = 0; const Object* getUserObject(Object* owner, const std::string& name) const = 0; unsigned int getNumUserObjects(Object* owner) const = 0; }; - Provide a default implementation which doesn't do anything with the "owner" field class OSG_EXPORT DefaultUserDataContainer : public UserDataContainer { ref_ptr _userData; b DescriptionList _descriptionList; ObjectList _objectList; public: void addUserObject(Object* owner, Object* obj) { _objectList.push_back(obj); } /* etc */ }; - The methods implementated in osg::Object just forward to the container along with the owner: void osg::Object::addUserObject(Object* obj) { if (!_container) { _container = new osg::DefaultUserDataContainer(); } _container->addUserObject(this, obj); } void osg::Object::setUserObject(Object* owner, unsigned int i, Object* obj) { if (!_container) { _container = new osg::DefaultUserDataContainer(); } _container->setUserObject(this, i, obj); } /* etc */ - osg::Object also gains a couple of new methods: osg::UserDataContainer* osg::Object::getUserDataContainer(); osg::Object::setUserDataContainer(osg::UserDataContainer*); Does this seem reasonable? - Peter -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Robert, That definitely sounds very sensible as it can get out of hand very quickly. In fact, what you present as an example is exactly what I ended up doing (i.e., implementing numerous methods such as getVariableAsFloat, getVariableAsInteger, etc.). But I wasn't sure which way you were heading on this, thus my previous comment. What you've done so far does look very promising though. Thanks. Chuck On Tue, 2011-05-31 at 11:01 -0500, Robert Osfield wrote: > Hi Chuck, > > On Tue, May 31, 2011 at 4:44 PM, Chuck Cole wrote: > > Just an observer of the thread ... I like what you've done so far, as I > > think it has far more reaching applications (even outside of OSG). I've > > put together something similar on a separate project that doesn't use > > OSG. The biggest issue that I found was how to handle getting/setting > > values when the variable types don't match. And as such, I just wanted > > to send along a heads-up on that issue. > > Right now there isn't any support getting a different type than has > been set, for now > I'm happy to just require users to either explict get the correct type > for a field or have > them get the basic Object and then use C++'s RTTI to detmine the > object type and then > let them deal with it. > > Automtically casting from one type to another on getting is an awkward > issue as it's so > open ended. Casting between int/float/double is relatively straight > forward, but your this > there isn't any obvious mapping. Perhaps one could specialize the > ValueObject template > into a NumbericObject which provides a range of getValueAsInt, > getValueAsFloat etc. > > In terms of setting it is straight forward to explictly assign the > type in the method so that > it's able to use C++'s automatically casting. For example: > > node->setUserValue("Height",1.4); > > Is able to get C++ to cast the 1.4 double into a float so that it > creates a ValueObject > object when assigning it to the Object::UserDataContainer::_objectList. > > Right now my main priority is working out how to provide the IO > support and keeping the whole > infrastructure simple and straightforward to use, rather than trying > to cover all types of usage. > > Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Farshid, On Tue, May 31, 2011 at 5:01 PM, Farshid Lashkari wrote: > Regarding serialization, will your changes break loading of older models > that contained node descriptions? This is a big concern for us because we > have hundreds of models that contain description strings. I haven't modified how the UserData and Description strings are supported so right now all existing files should just work as before. I am still considering how to add support for the more generic UserObject list, it might be that for .ive and .osg we'll just leave support out and just add support into the new serializer formats. With all these changes backwards compatibility is something we need to retain, so if something does break then we'll need to work out how to address this. So the testing out in the community will be really important even for those apps that don't use the new functionality. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Chuck, On Tue, May 31, 2011 at 4:44 PM, Chuck Cole wrote: > Just an observer of the thread ... I like what you've done so far, as I > think it has far more reaching applications (even outside of OSG). I've > put together something similar on a separate project that doesn't use > OSG. The biggest issue that I found was how to handle getting/setting > values when the variable types don't match. And as such, I just wanted > to send along a heads-up on that issue. Right now there isn't any support getting a different type than has been set, for now I'm happy to just require users to either explict get the correct type for a field or have them get the basic Object and then use C++'s RTTI to detmine the object type and then let them deal with it. Automtically casting from one type to another on getting is an awkward issue as it's so open ended. Casting between int/float/double is relatively straight forward, but your this there isn't any obvious mapping. Perhaps one could specialize the ValueObject template into a NumbericObject which provides a range of getValueAsInt, getValueAsFloat etc. In terms of setting it is straight forward to explictly assign the type in the method so that it's able to use C++'s automatically casting. For example: node->setUserValue("Height",1.4); Is able to get C++ to cast the 1.4 double into a float so that it creates a ValueObject object when assigning it to the Object::UserDataContainer::_objectList. Right now my main priority is working out how to provide the IO support and keeping the whole infrastructure simple and straightforward to use, rather than trying to cover all types of usage. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Robert, This is great! Being able to store meta-data in any osg::Object derived class has been something we've wanted for a while now. Regarding serialization, will your changes break loading of older models that contained node descriptions? This is a big concern for us because we have hundreds of models that contain description strings. Anyways, I'll begin playing around with these changes and report any issues I encounter. Cheers, Farshid On Tue, May 31, 2011 at 7:19 AM, Robert Osfield wrote: > Hi All, > > This morning I've been experimenting with extending the user data > support in the OSG, along the lines set out by Sukender. I've tried > to keep the class count down, and keep the user interface relatively > straight forward. Implementation wise I have gone for an > osg::Object::UserDataContainer that is used an internal implementation > structure in osg::Object, and this doesn't have any public interface. > This simple nested class is defined within the osg::Object protected > scope and looks like: > >class OSG_EXPORT UserDataContainer : public osg::Referenced >{ >public: >UserDataContainer(); >UserDataContainer(const UserDataContainer& udc, const > osg::CopyOp& copyop=CopyOp::SHALLOW_COPY); > >virtual void setThreadSafeRefUnref(bool threadSafe); > >typedef std::vector< osg::ref_ptr > ObjectList; > >ref_ptr _userData; >DescriptionList _descriptionList; >ObjectList _objectList; >}; > > Access methods for the old UserData and Descriptions list are > maintained, with the later moved in from osg::Node to allow all > osg::Object classes access to these convinience methods. These > methods automatically create the UserDataContainer when required and > can be used in an identical was as before. > > The new element is the ObjectList vector in UserDataContainer, this > can store any object subclasses from osg::Object which can be access > either via index into the vector or by the name of the osg::Object > (i.e. Object::setName()/getName()). I have put convience methods into > osg::Object public scope to access the UserDataContainer: > >void addUserObject(Object* obj); >void setUserObject(unsigned int i, Object* obj); >void removeUserObject(unsigned int i); > >unsigned int getUserObjectIndex(const osg::Object* obj) const; >unsigned int getUserObjectIndex(const std::string& name) const; > >Object* getUserObject(unsigned int i); >const Object* getUserObject(unsigned int i) const; > >Object* getUserObject(const std::string& name); >const Object* getUserObject(const std::string& name) const; > >unsigned int getNumUserObjects() const; > > This gets us so far, but... it forces us to provide our own subclasses > of osg::Object to be able to put in our own Data, to ease the burden I > have introduced a template ValueObject implementation that > "has a" T _value member. > > template > class ValueObject : public osg::Object > { >public: > >ValueObject(): >Object(true), >_value() >{ >} > >ValueObject(const std::string& name, T value): >Object(true), >_value(value) >{ >setName(name); >} > >ValueObject(const ValueObject& rhs, const osg::CopyOp > copyop=osg::CopyOp::SHALLOW_COPY): >Object(rhs,copyop), >_value(rhs._value) >{ >} > >META_Object(osg, ValueObject) > >void setValue(const T& value) { _value = value; } >const T& getValue() const { return _value; } > >protected: > >T _value; > }; > > And a couple of convinience methods in osg::Object to create/access these: > >template >bool getUserValue(const std::string& name, T& value) const >{ >typedef ValueObject UserValueObject; >UserValueObject* uvo = > dynamic_cast(getUserObject(name)); >if (uvo) >{ >value = uvo->getValue(); >return true; >} >else >{ >return false; >} >} > >template >void setUserValue(const std::string& name, const T& value) >{ >typedef ValueObject UserValueObject; > >unsigned int i = getUserObjectIndex(name); >if (i UserValueObject(name,value)); >else addUserObject(new UserValueObject(name,value)); >} > > > It's these methods that I'd expect the access to go through. As a > quick test I have created an osguserdata example than we can use as a > test bed for this new functionality. My current rev looks like: > > int main(int argc, char** argv) > { >osg::ref_ptr node = new osg::Group; > >int i = 10; >node->setUserValue("Int value",i); > >
Re: [osg-users] Meta-data in core OSG - project started
Hi Robert, Just an observer of the thread ... I like what you've done so far, as I think it has far more reaching applications (even outside of OSG). I've put together something similar on a separate project that doesn't use OSG. The biggest issue that I found was how to handle getting/setting values when the variable types don't match. And as such, I just wanted to send along a heads-up on that issue. For me, I wanted to still maintain the get/set functionality even if the variable type was different. For instance, if my base value was a double, but yet the calling routine wanted an integer return, I wanted to return a valid value as an integer (if possible). I was able to work around the issue by using the boost library and it's numeric_cast functionality (for me, the use of the boost library was not an issue). I realize that this is not really an option for OSG as it presents a significant additional dependency, and you've stayed away from such in the past. But, maybe a look into the boost library may help address the issue. Of course, that's if you wanted to handle type casting to begin with. Regards, Chuck On Tue, 2011-05-31 at 09:19 -0500, Robert Osfield wrote: > Hi All, > > This morning I've been experimenting with extending the user data > support in the OSG, along the lines set out by Sukender. I've tried > to keep the class count down, and keep the user interface relatively > straight forward. Implementation wise I have gone for an > osg::Object::UserDataContainer that is used an internal implementation > structure in osg::Object, and this doesn't have any public interface. > This simple nested class is defined within the osg::Object protected > scope and looks like: > > class OSG_EXPORT UserDataContainer : public osg::Referenced > { > public: > UserDataContainer(); > UserDataContainer(const UserDataContainer& udc, const > osg::CopyOp& copyop=CopyOp::SHALLOW_COPY); > > virtual void setThreadSafeRefUnref(bool threadSafe); > > typedef std::vector< osg::ref_ptr > ObjectList; > > ref_ptr _userData; > DescriptionList _descriptionList; > ObjectList _objectList; > }; > > Access methods for the old UserData and Descriptions list are > maintained, with the later moved in from osg::Node to allow all > osg::Object classes access to these convinience methods. These > methods automatically create the UserDataContainer when required and > can be used in an identical was as before. > > The new element is the ObjectList vector in UserDataContainer, this > can store any object subclasses from osg::Object which can be access > either via index into the vector or by the name of the osg::Object > (i.e. Object::setName()/getName()). I have put convience methods into > osg::Object public scope to access the UserDataContainer: > > void addUserObject(Object* obj); > void setUserObject(unsigned int i, Object* obj); > void removeUserObject(unsigned int i); > > unsigned int getUserObjectIndex(const osg::Object* obj) const; > unsigned int getUserObjectIndex(const std::string& name) const; > > Object* getUserObject(unsigned int i); > const Object* getUserObject(unsigned int i) const; > > Object* getUserObject(const std::string& name); > const Object* getUserObject(const std::string& name) const; > > unsigned int getNumUserObjects() const; > > This gets us so far, but... it forces us to provide our own subclasses > of osg::Object to be able to put in our own Data, to ease the burden I > have introduced a template ValueObject implementation that > "has a" T _value member. > > template > class ValueObject : public osg::Object > { > public: > > ValueObject(): > Object(true), > _value() > { > } > > ValueObject(const std::string& name, T value): > Object(true), > _value(value) > { > setName(name); > } > > ValueObject(const ValueObject& rhs, const osg::CopyOp > copyop=osg::CopyOp::SHALLOW_COPY): > Object(rhs,copyop), > _value(rhs._value) > { > } > > META_Object(osg, ValueObject) > > void setValue(const T& value) { _value = value; } > const T& getValue() const { return _value; } > > protected: > > T _value; > }; > > And a couple of convinience methods in osg::Object to create/access these: > > template > bool getUserValue(const std::string& name, T& value) const > { > typedef ValueObject UserValueObject; > UserValueObject* uvo = > dynamic_cast(getUserObject(name)); > if (uvo) > { > value = uvo->getValue(); > return true; > } > e
Re: [osg-users] Merging multiple textures
Hi, I am now trying to use the TextureAtlas builder. Can anyone point me to some tutorials, i cant seem to find much. I want to combine the textures(in 1024) into 2048 and then save them back out with the mesh. Any help would be fab! ... Thank you! Cheers, karl -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39967#39967 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Version not changed from 15 to 16
Hi Robert, thanks for the info! Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39966#39966 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi All, This morning I've been experimenting with extending the user data support in the OSG, along the lines set out by Sukender. I've tried to keep the class count down, and keep the user interface relatively straight forward. Implementation wise I have gone for an osg::Object::UserDataContainer that is used an internal implementation structure in osg::Object, and this doesn't have any public interface. This simple nested class is defined within the osg::Object protected scope and looks like: class OSG_EXPORT UserDataContainer : public osg::Referenced { public: UserDataContainer(); UserDataContainer(const UserDataContainer& udc, const osg::CopyOp& copyop=CopyOp::SHALLOW_COPY); virtual void setThreadSafeRefUnref(bool threadSafe); typedef std::vector< osg::ref_ptr > ObjectList; ref_ptr _userData; DescriptionList _descriptionList; ObjectList _objectList; }; Access methods for the old UserData and Descriptions list are maintained, with the later moved in from osg::Node to allow all osg::Object classes access to these convinience methods. These methods automatically create the UserDataContainer when required and can be used in an identical was as before. The new element is the ObjectList vector in UserDataContainer, this can store any object subclasses from osg::Object which can be access either via index into the vector or by the name of the osg::Object (i.e. Object::setName()/getName()). I have put convience methods into osg::Object public scope to access the UserDataContainer: void addUserObject(Object* obj); void setUserObject(unsigned int i, Object* obj); void removeUserObject(unsigned int i); unsigned int getUserObjectIndex(const osg::Object* obj) const; unsigned int getUserObjectIndex(const std::string& name) const; Object* getUserObject(unsigned int i); const Object* getUserObject(unsigned int i) const; Object* getUserObject(const std::string& name); const Object* getUserObject(const std::string& name) const; unsigned int getNumUserObjects() const; This gets us so far, but... it forces us to provide our own subclasses of osg::Object to be able to put in our own Data, to ease the burden I have introduced a template ValueObject implementation that "has a" T _value member. template class ValueObject : public osg::Object { public: ValueObject(): Object(true), _value() { } ValueObject(const std::string& name, T value): Object(true), _value(value) { setName(name); } ValueObject(const ValueObject& rhs, const osg::CopyOp copyop=osg::CopyOp::SHALLOW_COPY): Object(rhs,copyop), _value(rhs._value) { } META_Object(osg, ValueObject) void setValue(const T& value) { _value = value; } const T& getValue() const { return _value; } protected: T _value; }; And a couple of convinience methods in osg::Object to create/access these: template bool getUserValue(const std::string& name, T& value) const { typedef ValueObject UserValueObject; UserValueObject* uvo = dynamic_cast(getUserObject(name)); if (uvo) { value = uvo->getValue(); return true; } else { return false; } } template void setUserValue(const std::string& name, const T& value) { typedef ValueObject UserValueObject; unsigned int i = getUserObjectIndex(name); if (i node = new osg::Group; int i = 10; node->setUserValue("Int value",i); int j = 0; if (node->getUserValue("Int value",j)) { OSG_NOTICE<<"Int value="getUserValue("Status",readString)) { OSG_NOTICE<<"Status="<, ValueObject, ValueObject, ValueObject etc. will be sufficient. This will be my next experiment. I am a little nervous about the potential for build and runtime breakage so will post to the list a warning that I'm about to check these changes in. I have attached my versions of include/osg/Object and src/osg/Object.cpp for those keep to review the changes. Let me know what you think, Robert. Object Description: Binary data /* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield * * This library is open source and may be redistributed and/or modified under * the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or * (at your option) any later version. The full license is in LICENSE file * included with this distribution, and on the openscenegraph.
Re: [osg-users] Version not changed from 15 to 16
Hi Torben, On Tue, May 31, 2011 at 2:38 PM, Torben Dannhauer wrote: > was it intended not to raise the version number from 15 to 16 in version.h? I haven't bumped the svn/trunk version to 2.9.16 yet, but then I haven't checked anything in since 2.9.15. Once I do I'll bump the patch number and the so version number - the later as I'm about to break the ABI for the work on meta data. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Version not changed from 15 to 16
Hi Robert, was it intended not to raise the version number from 15 to 16 in version.h? Thank you! Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39963#39963 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph hello
Hi, I did not post the last message. I believe my account has been cracked. I am taking care of it. I am terribly sorry if the above link disturb someone in the forum. Thank you! Cheers, Sajjadul -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39962#39962 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] R: R: R: about the front clipping plane
Thanks Robert. -Messaggio originale- Da: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Robert Osfield Inviato: martedì 31 maggio 2011 12:04 A: OpenSceneGraph Users Oggetto: Re: [osg-users] R: R: about the front clipping plane Hi Gianluca, On Tue, May 31, 2011 at 10:58 AM, Gianluca Natale wrote: > The front and back clipping planes are updated by OSG during the cull > traversal, > based upon the bounding volumes of all the objects in the scene. > What happens if the farthest object (WRT the eye position) in the scene is > out of the viewing volume? > Is it still taken into count to determine the far clipping plane, or is it > excluded since out > of the frustum? > > Same question for the nearest object. If out the viewing volume, is it > ignored for computing the near clipping plane? If the a drawables bounding box intersections with the view frustum then it will be treated as though the whole object intersections and the computation of the near/far planes will use it whole extents. Drawables that a completely outside the view frustum will be culled and won't take any part in the computation of the near/far planes. 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] R: R: about the front clipping plane
Hi Gianluca, On Tue, May 31, 2011 at 10:58 AM, Gianluca Natale wrote: > The front and back clipping planes are updated by OSG during the cull > traversal, > based upon the bounding volumes of all the objects in the scene. > What happens if the farthest object (WRT the eye position) in the scene is > out of the viewing volume? > Is it still taken into count to determine the far clipping plane, or is it > excluded since out > of the frustum? > > Same question for the nearest object. If out the viewing volume, is it > ignored for computing the near clipping plane? If the a drawables bounding box intersections with the view frustum then it will be treated as though the whole object intersections and the computation of the near/far planes will use it whole extents. Drawables that a completely outside the view frustum will be culled and won't take any part in the computation of the near/far planes. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] R: R: about the front clipping plane
I still have another question about it. The front and back clipping planes are updated by OSG during the cull traversal, based upon the bounding volumes of all the objects in the scene. What happens if the farthest object (WRT the eye position) in the scene is out of the viewing volume? Is it still taken into count to determine the far clipping plane, or is it excluded since out of the frustum? Same question for the nearest object. If out the viewing volume, is it ignored for computing the near clipping plane? Thanks Gianluca -Messaggio originale- Da: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Gianluca Natale Inviato: lunedì 30 maggio 2011 16:53 A: OpenSceneGraph Users Oggetto: [osg-users] R: about the front clipping plane Thank you Robert, you are always clear and precise! That's the info I need. Gianluca -Messaggio originale- Da: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Robert Osfield Inviato: lunedì 30 maggio 2011 16:50 A: OpenSceneGraph Users Oggetto: Re: [osg-users] about the front clipping plane Hi Gianluca, The OSG by default will use COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES settings for osg::Camera which tells the cull traversal to compute the depth range of scene for each frame based on the extents of the bounding boxes of the drawables in the scene. Often the computed near position will be very close to the eye point or even behind it both of which are not usage values for settings up the projection matrix, so the cull travesal automatically clamps the near distances if it's too low. The minimum near distance the OSG uses as a cut off is computed from NearFarRatio * compute_zfar, you can reset this ratio to a lower value via osg::Camera::setNearFarRatio(double). Robert. On Mon, May 30, 2011 at 3:40 PM, Gianluca Natale wrote: > Hi, > > I have an issue with the distance of the front clipping plane of the viewing > frustum. > > I mean that my scene is made only of two isolated points, each with an > "empty" bounding box (i.e. the bb is defined as the 8 vertices coinciding > with the point). > > Also, I set: > > setComputeNearFarMode(COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES) for my > osg::camera, in order to have osg update automatically the front and back > clipping planes. > > But sometimes it happens that the nearest point (in my scene) to the camera > is not drawn on the screen, even if I'm sure that it is placed in front of > the camera and not behind. > > It looks like the front clipping plane cuts away that point since it is too > near the camera. Shouldn't OSG update the front clipping plane to include > such point in the viewing volume, > > since it has a valid bb and it is in front of the camera? > > I tried to print out the zNear when this happens, and obtained values <1e-5. > > Also, if later I try to move the camera even nearer to that point, I see an > error message of OSG (CullVisitor::apply(&Geode) detected NAN). > > > > So, where am I wrong? > > Is there any threshold to be taken into count when moving the camera near > the nearest point my scene? > > > > Thanks, > > Gianluca Natale > > ___ > 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