[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 nat...@europe.altair.com 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
Re: [osg-users] R: R: about the front clipping plane
Hi Gianluca, On Tue, May 31, 2011 at 10:58 AM, Gianluca Natale nat...@europe.altair.com 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: 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 nat...@europe.altair.com 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] 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] 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] Version not changed from 15 to 16
Hi Torben, On Tue, May 31, 2011 at 2:38 PM, Torben Dannhauer tor...@dannhauer.info 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
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_ptrosg::Object ObjectList;
ref_ptrReferenced _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 templatetypename T ValueObject implementation that
has a T _value member.
templatetypename T
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:
templatetypename T
bool getUserValue(const std::string name, T value) const
{
typedef ValueObjectT UserValueObject;
UserValueObject* uvo =
dynamic_castUserValueObject*(getUserObject(name));
if (uvo)
{
value = uvo-getValue();
return true;
}
else
{
return false;
}
}
templatetypename T
void setUserValue(const std::string name, const T value)
{
typedef ValueObjectT UserValueObject;
unsigned int i = getUserObjectIndex(name);
if (igetNumUserObjects()) setUserObject(i, new
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_ptrosg::Group node = new osg::Group;
int i = 10;
node-setUserValue(Int value,i);
int j = 0;
if (node-getUserValue(Int value,j))
{
OSG_NOTICEInt value=jstd::endl;
}
else
{
OSG_NOTICEInt value not foundstd::endl;
}
std::string testString(All seems fine);
node-setUserValue(Status,testString);
std::string readString;
if (node-getUserValue(Status,readString))
{
OSG_NOTICEStatus=readStringstd::endl;
}
else
{
OSG_NOTICEStatus not foundstd::endl;
}
return 0;
}
So far I'm getting the correct values, and everything compiles OK
under g++ 4.5.2, hopefully
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] 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] 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_ptrosg::Object ObjectList;
ref_ptrReferenced _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 templatetypename T ValueObject implementation that
has a T _value member.
templatetypename T
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:
templatetypename T
bool getUserValue(const std::string name, T value) const
{
typedef ValueObjectT UserValueObject;
UserValueObject* uvo =
dynamic_castUserValueObject*(getUserObject(name));
if (uvo)
{
value = uvo-getValue();
return true;
}
else
{
return false;
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 robert.osfi...@gmail.comwrote:
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_ptrosg::Object ObjectList;
ref_ptrReferenced _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 templatetypename T ValueObject implementation that
has a T _value member.
templatetypename T
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:
templatetypename T
bool getUserValue(const std::string name, T value) const
{
typedef ValueObjectT UserValueObject;
UserValueObject* uvo =
dynamic_castUserValueObject*(getUserObject(name));
if (uvo)
{
value = uvo-getValue();
return true;
}
else
{
return false;
}
}
templatetypename T
void setUserValue(const std::string name, const T value)
{
typedef ValueObjectT UserValueObject;
unsigned int i = getUserObjectIndex(name);
if (igetNumUserObjects()) setUserObject(i, new
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_ptrosg::Group node = new osg::Group;
int i = 10;
node-setUserValue(Int value,i);
Re: [osg-users] Meta-data in core OSG - project started
Hi Chuck, On Tue, May 31, 2011 at 4:44 PM, Chuck Cole charles.e.c...@nasa.gov 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-setUserValuefloat(Height,1.4); Is able to get C++ to cast the 1.4 double into a float so that it creates a ValueObjectfloat 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 fla...@gmail.com 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 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 charles.e.c...@nasa.gov 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-setUserValuefloat(Height,1.4); Is able to get C++ to cast the 1.4 double into a float so that it creates a ValueObjectfloat 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 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_ptrReferenced _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] 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
[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] [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_ptrCamClearMaskCallback clearStencilCallback = new
CamClearMaskCallback(camera, GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT |
GL_STENCIL_BUFFER_BIT);
osg::ref_ptrCamClearMaskCallback dontClearStencilCallback = new
CamClearMaskCallback(camera, GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
osg::ref_ptrosgDB::ReaderWriter::Options fragmentOptions = new
osgDB::ReaderWriter::Options(fragment);
osg::ref_ptrosgDB::ReaderWriter::Options 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();
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] 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
[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] 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
