OpenSceneGraph/include/osg/Shape

811 lines
26 KiB
Plaintext
Raw Normal View History

/* -*-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.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
#ifndef OSG_SHAPE
#define OSG_SHAPE 1
#include <osg/Object>
#include <osg/Vec3>
#include <osg/Quat>
#include <osg/Plane>
#include <osg/Array>
namespace osg {
// forward declare visitors.
class ShapeVisitor;
class ConstShapeVisitor;
/** META_StateAttribute macro define the standard clone, isSameKindAs,
* className and getType methods.
* Use when subclassing from Object to make it more convenient to define
* the standard pure virtual methods which are required for all Object
* subclasses.*/
#define META_Shape(library,name) \
virtual Object* cloneType() const { return new name(); } \
virtual Object* clone(const CopyOp& copyop) const { return new name (*this,copyop); } \
virtual bool isSameKindAs(const Object* obj) const { return dynamic_cast<const name *>(obj)!=NULL; } \
virtual const char* libraryName() const { return #library; } \
virtual const char* className() const { return #name; } \
virtual void accept(ShapeVisitor& sv) { sv.apply(*this); } \
virtual void accept(ConstShapeVisitor& csv) const { csv.apply(*this); }
2005-11-18 01:44:48 +08:00
/** Base class for all shape types.
* Shapes are used to either for culling and collision detection or
* to define the geometric shape of procedurally generate Geometry.
*/
class OSG_EXPORT Shape : public Object
{
public:
Shape() {}
Shape(const Shape& sa,const CopyOp& copyop=CopyOp::SHALLOW_COPY):
Object(sa,copyop) {}
/** Clone the type of an attribute, with Object* return type.
Must be defined by derived classes.*/
virtual Object* cloneType() const = 0;
/** Clone an attribute, with Object* return type.
Must be defined by derived classes.*/
virtual Object* clone(const CopyOp&) const = 0;
/** return true if this and obj are of the same kind of object.*/
virtual bool isSameKindAs(const Object* obj) const { return dynamic_cast<const Shape*>(obj)!=NULL; }
/** return the name of the attribute's library.*/
virtual const char* libraryName() const { return "osg"; }
/** return the name of the attribute's class type.*/
virtual const char* className() const { return "Shape"; }
2005-11-18 01:44:48 +08:00
/** accept a non const shape visitor which can be used on non const shape objects.
Must be defined by derived classes.*/
2005-11-18 01:44:48 +08:00
virtual void accept(ShapeVisitor&)=0;
/** accept a const shape visitor which can be used on const shape objects.
Must be defined by derived classes.*/
2005-11-18 01:44:48 +08:00
virtual void accept(ConstShapeVisitor&) const =0;
protected:
2005-11-18 01:44:48 +08:00
virtual ~Shape();
};
// forward declarations of Shape types.
class Sphere;
class Box;
class Cone;
class Cylinder;
class Capsule;
class InfinitePlane;
class TriangleMesh;
class ConvexHull;
class HeightField;
class CompositeShape;
From Patrick Hartling, "I encountered a bug related to RTTI for subclasses of osg::Shape. The circumstances under which this bug occur are rather specific, but the basic problem occurs when one translation unit other than libosg.so constructs an object that is a subclass of osg::Shape and another translation unit other than libosg.so tries to perform a dynamic_cast or other RTTI-based operation on that object. Under these circumstances, the RTTI operation will fail. In my case, the translation units involved were an application and osgdb_ive.so. The application constructed a scene graph that included instantiations of subclasses of osg::Shape. Depending on how the user ran the application, it would write the scene graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast operations in DataOutputStream::writeShape() would fail on the first subclass of osg::Shape that was encountered. This is because there were two different RTTI data objects for all osg::Shape subclasses being compared: one in the application and one in osgdb_ive.so. The fix for this is simple. We must ensure that at least one member function of each of the subclasses of the polymorphic type osg::Shape is compiled into libosg.so so that there is exactly one RTTI object for that type in libosg.so. Then, all code linking against libosg.so will use that single RTTI object. The following message from a list archive sort of explains the issue and the solution: http://aspn.activestate.com/ASPN/Mail/Message/1688156 While the posting has to do with Boost.Python, the problem applies to C++ libraries in general."
2009-01-28 17:21:46 +08:00
class OSG_EXPORT ShapeVisitor
{
public:
2005-11-18 01:44:48 +08:00
ShapeVisitor() {}
From Patrick Hartling, "I encountered a bug related to RTTI for subclasses of osg::Shape. The circumstances under which this bug occur are rather specific, but the basic problem occurs when one translation unit other than libosg.so constructs an object that is a subclass of osg::Shape and another translation unit other than libosg.so tries to perform a dynamic_cast or other RTTI-based operation on that object. Under these circumstances, the RTTI operation will fail. In my case, the translation units involved were an application and osgdb_ive.so. The application constructed a scene graph that included instantiations of subclasses of osg::Shape. Depending on how the user ran the application, it would write the scene graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast operations in DataOutputStream::writeShape() would fail on the first subclass of osg::Shape that was encountered. This is because there were two different RTTI data objects for all osg::Shape subclasses being compared: one in the application and one in osgdb_ive.so. The fix for this is simple. We must ensure that at least one member function of each of the subclasses of the polymorphic type osg::Shape is compiled into libosg.so so that there is exactly one RTTI object for that type in libosg.so. Then, all code linking against libosg.so will use that single RTTI object. The following message from a list archive sort of explains the issue and the solution: http://aspn.activestate.com/ASPN/Mail/Message/1688156 While the posting has to do with Boost.Python, the problem applies to C++ libraries in general."
2009-01-28 17:21:46 +08:00
virtual ~ShapeVisitor();
2005-11-18 01:44:48 +08:00
2008-06-05 21:46:19 +08:00
virtual void apply(Shape&) {}
2005-11-18 01:44:48 +08:00
virtual void apply(Sphere&) {}
virtual void apply(Box&) {}
virtual void apply(Cone&) {}
virtual void apply(Cylinder&) {}
virtual void apply(Capsule&) {}
virtual void apply(InfinitePlane&) {}
virtual void apply(TriangleMesh&) {}
virtual void apply(ConvexHull&) {}
virtual void apply(HeightField&) {}
virtual void apply(CompositeShape&) {}
};
From Patrick Hartling, "I encountered a bug related to RTTI for subclasses of osg::Shape. The circumstances under which this bug occur are rather specific, but the basic problem occurs when one translation unit other than libosg.so constructs an object that is a subclass of osg::Shape and another translation unit other than libosg.so tries to perform a dynamic_cast or other RTTI-based operation on that object. Under these circumstances, the RTTI operation will fail. In my case, the translation units involved were an application and osgdb_ive.so. The application constructed a scene graph that included instantiations of subclasses of osg::Shape. Depending on how the user ran the application, it would write the scene graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast operations in DataOutputStream::writeShape() would fail on the first subclass of osg::Shape that was encountered. This is because there were two different RTTI data objects for all osg::Shape subclasses being compared: one in the application and one in osgdb_ive.so. The fix for this is simple. We must ensure that at least one member function of each of the subclasses of the polymorphic type osg::Shape is compiled into libosg.so so that there is exactly one RTTI object for that type in libosg.so. Then, all code linking against libosg.so will use that single RTTI object. The following message from a list archive sort of explains the issue and the solution: http://aspn.activestate.com/ASPN/Mail/Message/1688156 While the posting has to do with Boost.Python, the problem applies to C++ libraries in general."
2009-01-28 17:21:46 +08:00
class OSG_EXPORT ConstShapeVisitor
{
public:
2005-11-18 01:44:48 +08:00
ConstShapeVisitor() {}
From Patrick Hartling, "I encountered a bug related to RTTI for subclasses of osg::Shape. The circumstances under which this bug occur are rather specific, but the basic problem occurs when one translation unit other than libosg.so constructs an object that is a subclass of osg::Shape and another translation unit other than libosg.so tries to perform a dynamic_cast or other RTTI-based operation on that object. Under these circumstances, the RTTI operation will fail. In my case, the translation units involved were an application and osgdb_ive.so. The application constructed a scene graph that included instantiations of subclasses of osg::Shape. Depending on how the user ran the application, it would write the scene graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast operations in DataOutputStream::writeShape() would fail on the first subclass of osg::Shape that was encountered. This is because there were two different RTTI data objects for all osg::Shape subclasses being compared: one in the application and one in osgdb_ive.so. The fix for this is simple. We must ensure that at least one member function of each of the subclasses of the polymorphic type osg::Shape is compiled into libosg.so so that there is exactly one RTTI object for that type in libosg.so. Then, all code linking against libosg.so will use that single RTTI object. The following message from a list archive sort of explains the issue and the solution: http://aspn.activestate.com/ASPN/Mail/Message/1688156 While the posting has to do with Boost.Python, the problem applies to C++ libraries in general."
2009-01-28 17:21:46 +08:00
virtual ~ConstShapeVisitor();
2008-06-05 21:46:19 +08:00
virtual void apply(const Shape&) {}
2005-11-18 01:44:48 +08:00
virtual void apply(const Sphere&) {}
virtual void apply(const Box&) {}
virtual void apply(const Cone&) {}
virtual void apply(const Cylinder&) {}
virtual void apply(const Capsule&) {}
virtual void apply(const InfinitePlane&) {}
2005-11-18 01:44:48 +08:00
virtual void apply(const TriangleMesh&) {}
virtual void apply(const ConvexHull&) {}
virtual void apply(const HeightField&) {}
2005-11-18 01:44:48 +08:00
virtual void apply(const CompositeShape&) {}
};
From Patrick Hartling, "I encountered a bug related to RTTI for subclasses of osg::Shape. The circumstances under which this bug occur are rather specific, but the basic problem occurs when one translation unit other than libosg.so constructs an object that is a subclass of osg::Shape and another translation unit other than libosg.so tries to perform a dynamic_cast or other RTTI-based operation on that object. Under these circumstances, the RTTI operation will fail. In my case, the translation units involved were an application and osgdb_ive.so. The application constructed a scene graph that included instantiations of subclasses of osg::Shape. Depending on how the user ran the application, it would write the scene graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast operations in DataOutputStream::writeShape() would fail on the first subclass of osg::Shape that was encountered. This is because there were two different RTTI data objects for all osg::Shape subclasses being compared: one in the application and one in osgdb_ive.so. The fix for this is simple. We must ensure that at least one member function of each of the subclasses of the polymorphic type osg::Shape is compiled into libosg.so so that there is exactly one RTTI object for that type in libosg.so. Then, all code linking against libosg.so will use that single RTTI object. The following message from a list archive sort of explains the issue and the solution: http://aspn.activestate.com/ASPN/Mail/Message/1688156 While the posting has to do with Boost.Python, the problem applies to C++ libraries in general."
2009-01-28 17:21:46 +08:00
class OSG_EXPORT Sphere : public Shape
{
public:
2005-11-18 01:44:48 +08:00
Sphere():
2005-11-18 01:44:48 +08:00
_center(0.0f,0.0f,0.0f),
_radius(1.0f) {}
Sphere(const Vec3& center,float radius):
2005-11-18 01:44:48 +08:00
_center(center),
_radius(radius) {}
Sphere(const Sphere& sphere,const CopyOp& copyop=CopyOp::SHALLOW_COPY):
Shape(sphere,copyop),
2005-11-18 01:44:48 +08:00
_center(sphere._center),
_radius(sphere._radius) {}
META_Shape(osg, Sphere);
inline bool valid() const { return _radius>=0.0f; }
inline void set(const Vec3& center,float radius)
{
_center = center;
_radius = radius;
}
inline void setCenter(const Vec3& center) { _center = center; }
inline const Vec3& getCenter() const { return _center; }
inline void setRadius(float radius) { _radius = radius; }
inline float getRadius() const { return _radius; }
protected:
2005-11-18 01:44:48 +08:00
From Patrick Hartling, "I encountered a bug related to RTTI for subclasses of osg::Shape. The circumstances under which this bug occur are rather specific, but the basic problem occurs when one translation unit other than libosg.so constructs an object that is a subclass of osg::Shape and another translation unit other than libosg.so tries to perform a dynamic_cast or other RTTI-based operation on that object. Under these circumstances, the RTTI operation will fail. In my case, the translation units involved were an application and osgdb_ive.so. The application constructed a scene graph that included instantiations of subclasses of osg::Shape. Depending on how the user ran the application, it would write the scene graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast operations in DataOutputStream::writeShape() would fail on the first subclass of osg::Shape that was encountered. This is because there were two different RTTI data objects for all osg::Shape subclasses being compared: one in the application and one in osgdb_ive.so. The fix for this is simple. We must ensure that at least one member function of each of the subclasses of the polymorphic type osg::Shape is compiled into libosg.so so that there is exactly one RTTI object for that type in libosg.so. Then, all code linking against libosg.so will use that single RTTI object. The following message from a list archive sort of explains the issue and the solution: http://aspn.activestate.com/ASPN/Mail/Message/1688156 While the posting has to do with Boost.Python, the problem applies to C++ libraries in general."
2009-01-28 17:21:46 +08:00
virtual ~Sphere();
2005-11-18 01:44:48 +08:00
Vec3 _center;
float _radius;
};
From Patrick Hartling, "I encountered a bug related to RTTI for subclasses of osg::Shape. The circumstances under which this bug occur are rather specific, but the basic problem occurs when one translation unit other than libosg.so constructs an object that is a subclass of osg::Shape and another translation unit other than libosg.so tries to perform a dynamic_cast or other RTTI-based operation on that object. Under these circumstances, the RTTI operation will fail. In my case, the translation units involved were an application and osgdb_ive.so. The application constructed a scene graph that included instantiations of subclasses of osg::Shape. Depending on how the user ran the application, it would write the scene graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast operations in DataOutputStream::writeShape() would fail on the first subclass of osg::Shape that was encountered. This is because there were two different RTTI data objects for all osg::Shape subclasses being compared: one in the application and one in osgdb_ive.so. The fix for this is simple. We must ensure that at least one member function of each of the subclasses of the polymorphic type osg::Shape is compiled into libosg.so so that there is exactly one RTTI object for that type in libosg.so. Then, all code linking against libosg.so will use that single RTTI object. The following message from a list archive sort of explains the issue and the solution: http://aspn.activestate.com/ASPN/Mail/Message/1688156 While the posting has to do with Boost.Python, the problem applies to C++ libraries in general."
2009-01-28 17:21:46 +08:00
class OSG_EXPORT Box : public Shape
{
public:
2005-11-18 01:44:48 +08:00
Box():
2005-11-18 01:44:48 +08:00
_center(0.0f,0.0f,0.0f),
_halfLengths(0.5f,0.5f,0.5f) {}
Box(const Vec3& center,float width):
2005-11-18 01:44:48 +08:00
_center(center),
_halfLengths(width*0.5f,width*0.5f,width*0.5f) {}
Box(const Vec3& center,float lengthX,float lengthY, float lengthZ):
2005-11-18 01:44:48 +08:00
_center(center),
_halfLengths(lengthX*0.5f,lengthY*0.5f,lengthZ*0.5f) {}
Box(const Box& box,const CopyOp& copyop=CopyOp::SHALLOW_COPY):
Shape(box,copyop),
2005-11-18 01:44:48 +08:00
_center(box._center),
_halfLengths(box._halfLengths),
_rotation(box._rotation) {}
META_Shape(osg, Box);
inline bool valid() const { return _halfLengths.x()>=0.0f; }
inline void set(const Vec3& center,const Vec3& halfLengths)
{
_center = center;
_halfLengths = halfLengths;
}
inline void setCenter(const Vec3& center) { _center = center; }
inline const Vec3& getCenter() const { return _center; }
inline void setHalfLengths(const Vec3& halfLengths) { _halfLengths = halfLengths; }
inline const Vec3& getHalfLengths() const { return _halfLengths; }
inline void setRotation(const Quat& quat) { _rotation = quat; }
inline const Quat& getRotation() const { return _rotation; }
inline Matrix computeRotationMatrix() const { return Matrix(_rotation); }
inline bool zeroRotation() const { return _rotation.zeroRotation(); }
protected:
From Patrick Hartling, "I encountered a bug related to RTTI for subclasses of osg::Shape. The circumstances under which this bug occur are rather specific, but the basic problem occurs when one translation unit other than libosg.so constructs an object that is a subclass of osg::Shape and another translation unit other than libosg.so tries to perform a dynamic_cast or other RTTI-based operation on that object. Under these circumstances, the RTTI operation will fail. In my case, the translation units involved were an application and osgdb_ive.so. The application constructed a scene graph that included instantiations of subclasses of osg::Shape. Depending on how the user ran the application, it would write the scene graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast operations in DataOutputStream::writeShape() would fail on the first subclass of osg::Shape that was encountered. This is because there were two different RTTI data objects for all osg::Shape subclasses being compared: one in the application and one in osgdb_ive.so. The fix for this is simple. We must ensure that at least one member function of each of the subclasses of the polymorphic type osg::Shape is compiled into libosg.so so that there is exactly one RTTI object for that type in libosg.so. Then, all code linking against libosg.so will use that single RTTI object. The following message from a list archive sort of explains the issue and the solution: http://aspn.activestate.com/ASPN/Mail/Message/1688156 While the posting has to do with Boost.Python, the problem applies to C++ libraries in general."
2009-01-28 17:21:46 +08:00
virtual ~Box();
2005-11-18 01:44:48 +08:00
Vec3 _center;
Vec3 _halfLengths;
Quat _rotation;
};
From Patrick Hartling, "I encountered a bug related to RTTI for subclasses of osg::Shape. The circumstances under which this bug occur are rather specific, but the basic problem occurs when one translation unit other than libosg.so constructs an object that is a subclass of osg::Shape and another translation unit other than libosg.so tries to perform a dynamic_cast or other RTTI-based operation on that object. Under these circumstances, the RTTI operation will fail. In my case, the translation units involved were an application and osgdb_ive.so. The application constructed a scene graph that included instantiations of subclasses of osg::Shape. Depending on how the user ran the application, it would write the scene graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast operations in DataOutputStream::writeShape() would fail on the first subclass of osg::Shape that was encountered. This is because there were two different RTTI data objects for all osg::Shape subclasses being compared: one in the application and one in osgdb_ive.so. The fix for this is simple. We must ensure that at least one member function of each of the subclasses of the polymorphic type osg::Shape is compiled into libosg.so so that there is exactly one RTTI object for that type in libosg.so. Then, all code linking against libosg.so will use that single RTTI object. The following message from a list archive sort of explains the issue and the solution: http://aspn.activestate.com/ASPN/Mail/Message/1688156 While the posting has to do with Boost.Python, the problem applies to C++ libraries in general."
2009-01-28 17:21:46 +08:00
class OSG_EXPORT Cone : public Shape
{
public:
2005-11-18 01:44:48 +08:00
Cone():
2005-11-18 01:44:48 +08:00
_center(0.0f,0.0f,0.0f),
_radius(1.0f),
_height(1.0f) {}
Cone(const Vec3& center,float radius,float height):
2005-11-18 01:44:48 +08:00
_center(center),
_radius(radius),
_height(height) {}
Cone(const Cone& cone,const CopyOp& copyop=CopyOp::SHALLOW_COPY):
Shape(cone,copyop),
2005-11-18 01:44:48 +08:00
_center(cone._center),
_radius(cone._radius),
_height(cone._height),
_rotation(cone._rotation) {}
META_Shape(osg, Cone);
inline bool valid() const { return _radius>=0.0f; }
inline void set(const Vec3& center,float radius, float height)
{
_center = center;
_radius = radius;
_height = height;
}
inline void setCenter(const Vec3& center) { _center = center; }
inline const Vec3& getCenter() const { return _center; }
inline void setRadius(float radius) { _radius = radius; }
inline float getRadius() const { return _radius; }
inline void setHeight(float height) { _height = height; }
inline float getHeight() const { return _height; }
inline void setRotation(const Quat& quat) { _rotation = quat; }
inline const Quat& getRotation() const { return _rotation; }
inline Matrix computeRotationMatrix() const { return Matrix(_rotation); }
inline bool zeroRotation() const { return _rotation.zeroRotation(); }
2005-11-18 01:44:48 +08:00
inline float getBaseOffsetFactor() const { return 0.25f; }
inline float getBaseOffset() const { return -getBaseOffsetFactor()*getHeight(); }
protected:
From Patrick Hartling, "I encountered a bug related to RTTI for subclasses of osg::Shape. The circumstances under which this bug occur are rather specific, but the basic problem occurs when one translation unit other than libosg.so constructs an object that is a subclass of osg::Shape and another translation unit other than libosg.so tries to perform a dynamic_cast or other RTTI-based operation on that object. Under these circumstances, the RTTI operation will fail. In my case, the translation units involved were an application and osgdb_ive.so. The application constructed a scene graph that included instantiations of subclasses of osg::Shape. Depending on how the user ran the application, it would write the scene graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast operations in DataOutputStream::writeShape() would fail on the first subclass of osg::Shape that was encountered. This is because there were two different RTTI data objects for all osg::Shape subclasses being compared: one in the application and one in osgdb_ive.so. The fix for this is simple. We must ensure that at least one member function of each of the subclasses of the polymorphic type osg::Shape is compiled into libosg.so so that there is exactly one RTTI object for that type in libosg.so. Then, all code linking against libosg.so will use that single RTTI object. The following message from a list archive sort of explains the issue and the solution: http://aspn.activestate.com/ASPN/Mail/Message/1688156 While the posting has to do with Boost.Python, the problem applies to C++ libraries in general."
2009-01-28 17:21:46 +08:00
virtual ~Cone();
2005-11-18 01:44:48 +08:00
Vec3 _center;
float _radius;
float _height;
Quat _rotation;
};
From Patrick Hartling, "I encountered a bug related to RTTI for subclasses of osg::Shape. The circumstances under which this bug occur are rather specific, but the basic problem occurs when one translation unit other than libosg.so constructs an object that is a subclass of osg::Shape and another translation unit other than libosg.so tries to perform a dynamic_cast or other RTTI-based operation on that object. Under these circumstances, the RTTI operation will fail. In my case, the translation units involved were an application and osgdb_ive.so. The application constructed a scene graph that included instantiations of subclasses of osg::Shape. Depending on how the user ran the application, it would write the scene graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast operations in DataOutputStream::writeShape() would fail on the first subclass of osg::Shape that was encountered. This is because there were two different RTTI data objects for all osg::Shape subclasses being compared: one in the application and one in osgdb_ive.so. The fix for this is simple. We must ensure that at least one member function of each of the subclasses of the polymorphic type osg::Shape is compiled into libosg.so so that there is exactly one RTTI object for that type in libosg.so. Then, all code linking against libosg.so will use that single RTTI object. The following message from a list archive sort of explains the issue and the solution: http://aspn.activestate.com/ASPN/Mail/Message/1688156 While the posting has to do with Boost.Python, the problem applies to C++ libraries in general."
2009-01-28 17:21:46 +08:00
class OSG_EXPORT Cylinder : public Shape
{
public:
2005-11-18 01:44:48 +08:00
Cylinder():
2005-11-18 01:44:48 +08:00
_center(0.0f,0.0f,0.0f),
_radius(1.0f),
_height(1.0f) {}
Cylinder(const Vec3& center,float radius,float height):
2005-11-18 01:44:48 +08:00
_center(center),
_radius(radius),
_height(height) {}
Cylinder(const Cylinder& cylinder,const CopyOp& copyop=CopyOp::SHALLOW_COPY):
Shape(cylinder,copyop),
2005-11-18 01:44:48 +08:00
_center(cylinder._center),
_radius(cylinder._radius),
_height(cylinder._height),
_rotation(cylinder._rotation) {}
META_Shape(osg, Cylinder);
inline bool valid() const { return _radius>=0.0f; }
inline void set(const Vec3& center,float radius, float height)
{
_center = center;
_radius = radius;
_height = height;
}
inline void setCenter(const Vec3& center) { _center = center; }
inline const Vec3& getCenter() const { return _center; }
inline void setRadius(float radius) { _radius = radius; }
inline float getRadius() const { return _radius; }
inline void setHeight(float height) { _height = height; }
inline float getHeight() const { return _height; }
inline void setRotation(const Quat& quat) { _rotation = quat; }
inline const Quat& getRotation() const { return _rotation; }
inline Matrix computeRotationMatrix() const { return Matrix(_rotation); }
bool zeroRotation() const { return _rotation.zeroRotation(); }
protected:
From Patrick Hartling, "I encountered a bug related to RTTI for subclasses of osg::Shape. The circumstances under which this bug occur are rather specific, but the basic problem occurs when one translation unit other than libosg.so constructs an object that is a subclass of osg::Shape and another translation unit other than libosg.so tries to perform a dynamic_cast or other RTTI-based operation on that object. Under these circumstances, the RTTI operation will fail. In my case, the translation units involved were an application and osgdb_ive.so. The application constructed a scene graph that included instantiations of subclasses of osg::Shape. Depending on how the user ran the application, it would write the scene graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast operations in DataOutputStream::writeShape() would fail on the first subclass of osg::Shape that was encountered. This is because there were two different RTTI data objects for all osg::Shape subclasses being compared: one in the application and one in osgdb_ive.so. The fix for this is simple. We must ensure that at least one member function of each of the subclasses of the polymorphic type osg::Shape is compiled into libosg.so so that there is exactly one RTTI object for that type in libosg.so. Then, all code linking against libosg.so will use that single RTTI object. The following message from a list archive sort of explains the issue and the solution: http://aspn.activestate.com/ASPN/Mail/Message/1688156 While the posting has to do with Boost.Python, the problem applies to C++ libraries in general."
2009-01-28 17:21:46 +08:00
virtual ~Cylinder();
2005-11-18 01:44:48 +08:00
Vec3 _center;
float _radius;
float _height;
Quat _rotation;
};
From Patrick Hartling, "I encountered a bug related to RTTI for subclasses of osg::Shape. The circumstances under which this bug occur are rather specific, but the basic problem occurs when one translation unit other than libosg.so constructs an object that is a subclass of osg::Shape and another translation unit other than libosg.so tries to perform a dynamic_cast or other RTTI-based operation on that object. Under these circumstances, the RTTI operation will fail. In my case, the translation units involved were an application and osgdb_ive.so. The application constructed a scene graph that included instantiations of subclasses of osg::Shape. Depending on how the user ran the application, it would write the scene graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast operations in DataOutputStream::writeShape() would fail on the first subclass of osg::Shape that was encountered. This is because there were two different RTTI data objects for all osg::Shape subclasses being compared: one in the application and one in osgdb_ive.so. The fix for this is simple. We must ensure that at least one member function of each of the subclasses of the polymorphic type osg::Shape is compiled into libosg.so so that there is exactly one RTTI object for that type in libosg.so. Then, all code linking against libosg.so will use that single RTTI object. The following message from a list archive sort of explains the issue and the solution: http://aspn.activestate.com/ASPN/Mail/Message/1688156 While the posting has to do with Boost.Python, the problem applies to C++ libraries in general."
2009-01-28 17:21:46 +08:00
class OSG_EXPORT Capsule : public Shape
{
public:
2005-11-18 01:44:48 +08:00
Capsule():
2005-11-18 01:44:48 +08:00
_center(0.0f,0.0f,0.0f),
_radius(1.0f),
_height(1.0f) {}
Capsule(const Vec3& center,float radius,float height):
2005-11-18 01:44:48 +08:00
_center(center),
_radius(radius),
_height(height) {}
Capsule(const Capsule& capsule,const CopyOp& copyop=CopyOp::SHALLOW_COPY):
Shape(capsule,copyop),
2005-11-18 01:44:48 +08:00
_center(capsule._center),
_radius(capsule._radius),
_height(capsule._height),
_rotation(capsule._rotation) {}
META_Shape(osg, Capsule);
inline bool valid() const { return _radius>=0.0f; }
inline void set(const Vec3& center,float radius, float height)
{
_center = center;
_radius = radius;
_height = height;
}
inline void setCenter(const Vec3& center) { _center = center; }
inline const Vec3& getCenter() const { return _center; }
inline void setRadius(float radius) { _radius = radius; }
inline float getRadius() const { return _radius; }
inline void setHeight(float height) { _height = height; }
inline float getHeight() const { return _height; }
inline void setRotation(const Quat& quat) { _rotation = quat; }
inline const Quat& getRotation() const { return _rotation; }
inline Matrix computeRotationMatrix() const { return Matrix(_rotation); }
bool zeroRotation() const { return _rotation.zeroRotation(); }
protected:
From Patrick Hartling, "I encountered a bug related to RTTI for subclasses of osg::Shape. The circumstances under which this bug occur are rather specific, but the basic problem occurs when one translation unit other than libosg.so constructs an object that is a subclass of osg::Shape and another translation unit other than libosg.so tries to perform a dynamic_cast or other RTTI-based operation on that object. Under these circumstances, the RTTI operation will fail. In my case, the translation units involved were an application and osgdb_ive.so. The application constructed a scene graph that included instantiations of subclasses of osg::Shape. Depending on how the user ran the application, it would write the scene graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast operations in DataOutputStream::writeShape() would fail on the first subclass of osg::Shape that was encountered. This is because there were two different RTTI data objects for all osg::Shape subclasses being compared: one in the application and one in osgdb_ive.so. The fix for this is simple. We must ensure that at least one member function of each of the subclasses of the polymorphic type osg::Shape is compiled into libosg.so so that there is exactly one RTTI object for that type in libosg.so. Then, all code linking against libosg.so will use that single RTTI object. The following message from a list archive sort of explains the issue and the solution: http://aspn.activestate.com/ASPN/Mail/Message/1688156 While the posting has to do with Boost.Python, the problem applies to C++ libraries in general."
2009-01-28 17:21:46 +08:00
virtual ~Capsule();
2005-11-18 01:44:48 +08:00
Vec3 _center;
float _radius;
float _height;
Quat _rotation;
};
/** Deprecated. */
From Patrick Hartling, "I encountered a bug related to RTTI for subclasses of osg::Shape. The circumstances under which this bug occur are rather specific, but the basic problem occurs when one translation unit other than libosg.so constructs an object that is a subclass of osg::Shape and another translation unit other than libosg.so tries to perform a dynamic_cast or other RTTI-based operation on that object. Under these circumstances, the RTTI operation will fail. In my case, the translation units involved were an application and osgdb_ive.so. The application constructed a scene graph that included instantiations of subclasses of osg::Shape. Depending on how the user ran the application, it would write the scene graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast operations in DataOutputStream::writeShape() would fail on the first subclass of osg::Shape that was encountered. This is because there were two different RTTI data objects for all osg::Shape subclasses being compared: one in the application and one in osgdb_ive.so. The fix for this is simple. We must ensure that at least one member function of each of the subclasses of the polymorphic type osg::Shape is compiled into libosg.so so that there is exactly one RTTI object for that type in libosg.so. Then, all code linking against libosg.so will use that single RTTI object. The following message from a list archive sort of explains the issue and the solution: http://aspn.activestate.com/ASPN/Mail/Message/1688156 While the posting has to do with Boost.Python, the problem applies to C++ libraries in general."
2009-01-28 17:21:46 +08:00
class OSG_EXPORT InfinitePlane : public Shape, public Plane
{
public:
2005-11-18 01:44:48 +08:00
InfinitePlane() {}
InfinitePlane(const InfinitePlane& plane,const CopyOp& copyop=CopyOp::SHALLOW_COPY):
Shape(plane,copyop),
Plane(plane) {}
2005-11-18 01:44:48 +08:00
META_Shape(osg, InfinitePlane);
protected:
From Patrick Hartling, "I encountered a bug related to RTTI for subclasses of osg::Shape. The circumstances under which this bug occur are rather specific, but the basic problem occurs when one translation unit other than libosg.so constructs an object that is a subclass of osg::Shape and another translation unit other than libosg.so tries to perform a dynamic_cast or other RTTI-based operation on that object. Under these circumstances, the RTTI operation will fail. In my case, the translation units involved were an application and osgdb_ive.so. The application constructed a scene graph that included instantiations of subclasses of osg::Shape. Depending on how the user ran the application, it would write the scene graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast operations in DataOutputStream::writeShape() would fail on the first subclass of osg::Shape that was encountered. This is because there were two different RTTI data objects for all osg::Shape subclasses being compared: one in the application and one in osgdb_ive.so. The fix for this is simple. We must ensure that at least one member function of each of the subclasses of the polymorphic type osg::Shape is compiled into libosg.so so that there is exactly one RTTI object for that type in libosg.so. Then, all code linking against libosg.so will use that single RTTI object. The following message from a list archive sort of explains the issue and the solution: http://aspn.activestate.com/ASPN/Mail/Message/1688156 While the posting has to do with Boost.Python, the problem applies to C++ libraries in general."
2009-01-28 17:21:46 +08:00
virtual ~InfinitePlane();
};
/** Deprecated. */
From Patrick Hartling, "I encountered a bug related to RTTI for subclasses of osg::Shape. The circumstances under which this bug occur are rather specific, but the basic problem occurs when one translation unit other than libosg.so constructs an object that is a subclass of osg::Shape and another translation unit other than libosg.so tries to perform a dynamic_cast or other RTTI-based operation on that object. Under these circumstances, the RTTI operation will fail. In my case, the translation units involved were an application and osgdb_ive.so. The application constructed a scene graph that included instantiations of subclasses of osg::Shape. Depending on how the user ran the application, it would write the scene graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast operations in DataOutputStream::writeShape() would fail on the first subclass of osg::Shape that was encountered. This is because there were two different RTTI data objects for all osg::Shape subclasses being compared: one in the application and one in osgdb_ive.so. The fix for this is simple. We must ensure that at least one member function of each of the subclasses of the polymorphic type osg::Shape is compiled into libosg.so so that there is exactly one RTTI object for that type in libosg.so. Then, all code linking against libosg.so will use that single RTTI object. The following message from a list archive sort of explains the issue and the solution: http://aspn.activestate.com/ASPN/Mail/Message/1688156 While the posting has to do with Boost.Python, the problem applies to C++ libraries in general."
2009-01-28 17:21:46 +08:00
class OSG_EXPORT TriangleMesh : public Shape
{
public:
2005-11-18 01:44:48 +08:00
TriangleMesh() {}
TriangleMesh(const TriangleMesh& mesh,const CopyOp& copyop=CopyOp::SHALLOW_COPY):
Shape(mesh,copyop),
2005-11-18 01:44:48 +08:00
_vertices(mesh._vertices),
_indices(mesh._indices) {}
META_Shape(osg, TriangleMesh);
void setVertices(Vec3Array* vertices) { _vertices = vertices; }
Vec3Array* getVertices() { return _vertices.get(); }
const Vec3Array* getVertices() const { return _vertices.get(); }
void setIndices(IndexArray* indices) { _indices = indices; }
IndexArray* getIndices() { return _indices.get(); }
const IndexArray* getIndices() const { return _indices.get(); }
protected:
From Patrick Hartling, "I encountered a bug related to RTTI for subclasses of osg::Shape. The circumstances under which this bug occur are rather specific, but the basic problem occurs when one translation unit other than libosg.so constructs an object that is a subclass of osg::Shape and another translation unit other than libosg.so tries to perform a dynamic_cast or other RTTI-based operation on that object. Under these circumstances, the RTTI operation will fail. In my case, the translation units involved were an application and osgdb_ive.so. The application constructed a scene graph that included instantiations of subclasses of osg::Shape. Depending on how the user ran the application, it would write the scene graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast operations in DataOutputStream::writeShape() would fail on the first subclass of osg::Shape that was encountered. This is because there were two different RTTI data objects for all osg::Shape subclasses being compared: one in the application and one in osgdb_ive.so. The fix for this is simple. We must ensure that at least one member function of each of the subclasses of the polymorphic type osg::Shape is compiled into libosg.so so that there is exactly one RTTI object for that type in libosg.so. Then, all code linking against libosg.so will use that single RTTI object. The following message from a list archive sort of explains the issue and the solution: http://aspn.activestate.com/ASPN/Mail/Message/1688156 While the posting has to do with Boost.Python, the problem applies to C++ libraries in general."
2009-01-28 17:21:46 +08:00
virtual ~TriangleMesh();
2005-11-18 01:44:48 +08:00
ref_ptr<Vec3Array> _vertices;
ref_ptr<IndexArray> _indices;
};
/** Deprecated. */
From Patrick Hartling, "I encountered a bug related to RTTI for subclasses of osg::Shape. The circumstances under which this bug occur are rather specific, but the basic problem occurs when one translation unit other than libosg.so constructs an object that is a subclass of osg::Shape and another translation unit other than libosg.so tries to perform a dynamic_cast or other RTTI-based operation on that object. Under these circumstances, the RTTI operation will fail. In my case, the translation units involved were an application and osgdb_ive.so. The application constructed a scene graph that included instantiations of subclasses of osg::Shape. Depending on how the user ran the application, it would write the scene graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast operations in DataOutputStream::writeShape() would fail on the first subclass of osg::Shape that was encountered. This is because there were two different RTTI data objects for all osg::Shape subclasses being compared: one in the application and one in osgdb_ive.so. The fix for this is simple. We must ensure that at least one member function of each of the subclasses of the polymorphic type osg::Shape is compiled into libosg.so so that there is exactly one RTTI object for that type in libosg.so. Then, all code linking against libosg.so will use that single RTTI object. The following message from a list archive sort of explains the issue and the solution: http://aspn.activestate.com/ASPN/Mail/Message/1688156 While the posting has to do with Boost.Python, the problem applies to C++ libraries in general."
2009-01-28 17:21:46 +08:00
class OSG_EXPORT ConvexHull : public TriangleMesh
{
public:
2005-11-18 01:44:48 +08:00
ConvexHull() {}
ConvexHull(const ConvexHull& hull,const CopyOp& copyop=CopyOp::SHALLOW_COPY):
TriangleMesh(hull,copyop) {}
2005-11-18 01:44:48 +08:00
2016-09-12 22:49:35 +08:00
META_Shape(osg, ConvexHull);
2005-11-18 01:44:48 +08:00
protected:
From Patrick Hartling, "I encountered a bug related to RTTI for subclasses of osg::Shape. The circumstances under which this bug occur are rather specific, but the basic problem occurs when one translation unit other than libosg.so constructs an object that is a subclass of osg::Shape and another translation unit other than libosg.so tries to perform a dynamic_cast or other RTTI-based operation on that object. Under these circumstances, the RTTI operation will fail. In my case, the translation units involved were an application and osgdb_ive.so. The application constructed a scene graph that included instantiations of subclasses of osg::Shape. Depending on how the user ran the application, it would write the scene graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast operations in DataOutputStream::writeShape() would fail on the first subclass of osg::Shape that was encountered. This is because there were two different RTTI data objects for all osg::Shape subclasses being compared: one in the application and one in osgdb_ive.so. The fix for this is simple. We must ensure that at least one member function of each of the subclasses of the polymorphic type osg::Shape is compiled into libosg.so so that there is exactly one RTTI object for that type in libosg.so. Then, all code linking against libosg.so will use that single RTTI object. The following message from a list archive sort of explains the issue and the solution: http://aspn.activestate.com/ASPN/Mail/Message/1688156 While the posting has to do with Boost.Python, the problem applies to C++ libraries in general."
2009-01-28 17:21:46 +08:00
virtual ~ConvexHull();
};
class OSG_EXPORT HeightField : public Shape
{
public:
HeightField();
HeightField(const HeightField& mesh,const CopyOp& copyop=CopyOp::SHALLOW_COPY);
2005-11-18 01:44:48 +08:00
META_Shape(osg, HeightField);
2003-10-28 00:07:21 +08:00
2005-11-18 01:44:48 +08:00
typedef std::vector<float> HeightList;
2005-11-18 01:44:48 +08:00
void allocate(unsigned int numColumns,unsigned int numRows);
2005-11-18 01:44:48 +08:00
inline unsigned int getNumColumns() const { return _columns; }
inline unsigned int getNumRows() const { return _rows; }
inline void setOrigin(const Vec3& origin) { _origin = origin; }
inline const Vec3& getOrigin() const { return _origin; }
2005-11-18 01:44:48 +08:00
inline void setXInterval(float dx) { _dx = dx; }
inline float getXInterval() const { return _dx; }
2005-11-18 01:44:48 +08:00
inline void setYInterval(float dy) { _dy = dy; }
inline float getYInterval() const { return _dy; }
/** Get the FloatArray height data.*/
FloatArray* getFloatArray() { return _heights.get(); }
/** Get the const FloatArray height data.*/
const FloatArray* getFloatArray() const { return _heights.get(); }
HeightList& getHeightList() { return _heights->asVector(); }
const HeightList& getHeightList() const { return _heights->asVector(); }
/** Set the height of the skirt to render around the edge of HeightField.
* The skirt is used as a means of disguising edge boundaries between adjacent HeightField,
* particularly of ones with different resolutions.*/
void setSkirtHeight(float skirtHeight) { _skirtHeight = skirtHeight; }
2005-11-18 01:44:48 +08:00
/** Get the height of the skirt to render around the edge of HeightField.*/
float getSkirtHeight() const { return _skirtHeight; }
2005-11-18 01:44:48 +08:00
/** Set the width in number of cells in from the edge that the height field should be rendered from.
* This exists to allow gradient and curvature continutity to be maintained between adjacent HeightField, where
* the border cells will overlap adjacent HeightField.*/
void setBorderWidth(unsigned int borderWidth) { _borderWidth = borderWidth; }
/** Get the width in number of cells in from the edge that the height field should be rendered from.*/
unsigned int getBorderWidth() const { return _borderWidth; }
2005-11-18 01:44:48 +08:00
inline void setRotation(const Quat& quat) { _rotation = quat; }
inline const Quat& getRotation() const { return _rotation; }
inline Matrix computeRotationMatrix() const { return Matrix(_rotation); }
inline bool zeroRotation() const { return _rotation.zeroRotation(); }
2005-11-18 01:44:48 +08:00
/* set a single height point in the height field */
inline void setHeight(unsigned int c,unsigned int r,float value)
{
(*_heights)[c+r*_columns] = value;
2005-11-18 01:44:48 +08:00
}
/* Get address of single height point in the height field, allows user to change. */
inline float& getHeight(unsigned int c,unsigned int r)
{
return (*_heights)[c+r*_columns];
2005-11-18 01:44:48 +08:00
}
/* Get value of single height point in the height field, not editable. */
inline float getHeight(unsigned int c,unsigned int r) const
{
return (*_heights)[c+r*_columns];
2005-11-18 01:44:48 +08:00
}
inline Vec3 getVertex(unsigned int c,unsigned int r) const
{
return Vec3(_origin.x()+getXInterval()*(float)c,
_origin.y()+getYInterval()*(float)r,
_origin.z()+(*_heights)[c+r*_columns]);
}
2005-11-18 01:44:48 +08:00
2003-10-28 00:07:21 +08:00
Vec3 getNormal(unsigned int c,unsigned int r) const;
Vec2 getHeightDelta(unsigned int c,unsigned int r) const;
protected:
2005-11-18 01:44:48 +08:00
virtual ~HeightField();
unsigned int _columns,_rows;
Vec3 _origin; // _origin is the min value of the X and Y coordinates.
float _dx;
float _dy;
float _skirtHeight;
unsigned int _borderWidth;
Quat _rotation;
ref_ptr<FloatArray> _heights;
2005-11-18 01:44:48 +08:00
};
typedef HeightField Grid;
2003-10-28 00:07:21 +08:00
/** Deprecated. */
From Patrick Hartling, "I encountered a bug related to RTTI for subclasses of osg::Shape. The circumstances under which this bug occur are rather specific, but the basic problem occurs when one translation unit other than libosg.so constructs an object that is a subclass of osg::Shape and another translation unit other than libosg.so tries to perform a dynamic_cast or other RTTI-based operation on that object. Under these circumstances, the RTTI operation will fail. In my case, the translation units involved were an application and osgdb_ive.so. The application constructed a scene graph that included instantiations of subclasses of osg::Shape. Depending on how the user ran the application, it would write the scene graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast operations in DataOutputStream::writeShape() would fail on the first subclass of osg::Shape that was encountered. This is because there were two different RTTI data objects for all osg::Shape subclasses being compared: one in the application and one in osgdb_ive.so. The fix for this is simple. We must ensure that at least one member function of each of the subclasses of the polymorphic type osg::Shape is compiled into libosg.so so that there is exactly one RTTI object for that type in libosg.so. Then, all code linking against libosg.so will use that single RTTI object. The following message from a list archive sort of explains the issue and the solution: http://aspn.activestate.com/ASPN/Mail/Message/1688156 While the posting has to do with Boost.Python, the problem applies to C++ libraries in general."
2009-01-28 17:21:46 +08:00
class OSG_EXPORT CompositeShape : public Shape
{
public:
2005-11-18 01:44:48 +08:00
typedef std::vector< ref_ptr<Shape> > ChildList;
CompositeShape() {}
CompositeShape(const CompositeShape& cs,const CopyOp& copyop=CopyOp::SHALLOW_COPY):
Shape(cs,copyop),
2005-11-18 01:44:48 +08:00
_children(cs._children) {}
META_Shape(osg, CompositeShape);
/** Set the shape that encloses all of the children.*/
void setShape(Shape* shape) { _shape = shape; }
/** Get the shape that encloses all of the children.*/
Shape* getShape() { return _shape.get(); }
/** Get the const shape that encloses all of the children.*/
const Shape* getShape() const { return _shape.get(); }
/** Get the number of children of this composite shape.*/
2009-01-30 18:55:28 +08:00
unsigned int getNumChildren() const { return static_cast<unsigned int>(_children.size()); }
2005-11-18 01:44:48 +08:00
/** Get a child.*/
Shape* getChild(unsigned int i) { return _children[i].get(); }
/** Get a const child.*/
const Shape* getChild(unsigned int i) const { return _children[i].get(); }
/** Add a child to the list.*/
void addChild(Shape* shape) { _children.push_back(shape); }
Introduced CMake option OSG_PROVIDE_READFILE option that defaults to ON, but when switched to OFF disables the building of the osgDB::read*File() methods, forcing users to use osgDB::readRef*File() methods. The later is preferable as it closes a potential threading bug when using paging databases in conjunction with the osgDB::Registry Object Cache. This threading bug occurs when one thread gets an object from the Cache via an osgDB::read*File() call where only a pointer to the object is passed back, so taking a reference to the object is delayed till it gets reassigned to a ref_ptr<>, but at the same time another thread calls a flush of the Object Cache deleting this object as it's referenceCount is now zero. Using osgDB::readREf*File() makes sure the a ref_ptr<> is passed back and the referenceCount never goes to zero. To ensure the OSG builds when OSG_PROVIDE_READFILE is to OFF the many cases of osgDB::read*File() usage had to be replaced with a ref_ptr<> osgDB::readRef*File() usage. The avoid this change causing lots of other client code to be rewritten to handle the use of ref_ptr<> in place of C pointer I introduced a serious of templte methods in various class to adapt ref_ptr<> to the underly C pointer to be passed to old OSG API's, example of this is found in include/osg/Group: bool addChild(Node* child); // old method which can only be used with a Node* tempalte<class T> bool addChild(const osg::ref_ptr<T>& child) { return addChild(child.get()); } // adapter template method These changes together cover 149 modified files, so it's a large submission. This extent of changes are warrent to make use of the Object Cache and multi-threaded loaded more robust. git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15164 16af8721-9629-0410-8352-f15c8da7e697
2015-10-22 21:42:19 +08:00
template<class T> void addChild( const ref_ptr<T>& child ) { addChild(child.get()); }
2005-11-18 01:44:48 +08:00
/** remove a child from the list.*/
void removeChild(unsigned int i) { _children.erase(_children.begin()+i); }
/** find the index number of child, if child is not found then it returns getNumChildren(),
* so should be used in similar style to STL's result!=end().*/
2005-11-18 01:44:48 +08:00
unsigned int findChildNo(Shape* shape) const
{
2002-11-11 16:04:40 +08:00
for (unsigned int childNo=0;childNo<_children.size();++childNo)
{
if (_children[childNo]==shape) return childNo;
}
2009-01-30 18:55:28 +08:00
return static_cast<unsigned int>(_children.size()); // node not found.
2002-11-11 16:04:40 +08:00
}
2005-11-18 01:44:48 +08:00
protected:
From Patrick Hartling, "I encountered a bug related to RTTI for subclasses of osg::Shape. The circumstances under which this bug occur are rather specific, but the basic problem occurs when one translation unit other than libosg.so constructs an object that is a subclass of osg::Shape and another translation unit other than libosg.so tries to perform a dynamic_cast or other RTTI-based operation on that object. Under these circumstances, the RTTI operation will fail. In my case, the translation units involved were an application and osgdb_ive.so. The application constructed a scene graph that included instantiations of subclasses of osg::Shape. Depending on how the user ran the application, it would write the scene graph to an IVE file using osgDB::writeNodeFile(). The dynamic_cast operations in DataOutputStream::writeShape() would fail on the first subclass of osg::Shape that was encountered. This is because there were two different RTTI data objects for all osg::Shape subclasses being compared: one in the application and one in osgdb_ive.so. The fix for this is simple. We must ensure that at least one member function of each of the subclasses of the polymorphic type osg::Shape is compiled into libosg.so so that there is exactly one RTTI object for that type in libosg.so. Then, all code linking against libosg.so will use that single RTTI object. The following message from a list archive sort of explains the issue and the solution: http://aspn.activestate.com/ASPN/Mail/Message/1688156 While the posting has to do with Boost.Python, the problem applies to C++ libraries in general."
2009-01-28 17:21:46 +08:00
virtual ~CompositeShape();
2005-11-18 01:44:48 +08:00
ref_ptr<Shape> _shape;
ChildList _children;
};
/** Describe several hints that can be passed to a Tessellator (like the one used
* by \c ShapeDrawable) as a mean to try to influence the way it works.
*/
class TessellationHints : public Object
{
public:
TessellationHints():
_TessellationMode(USE_SHAPE_DEFAULTS),
_detailRatio(1.0f),
_targetNumFaces(100),
_createFrontFace(true),
_createBackFace(false),
_createNormals(true),
_createTextureCoords(false),
_createTop(true),
_createBody(true),
_createBottom(true) {}
TessellationHints(const TessellationHints& tess, const CopyOp& copyop=CopyOp::SHALLOW_COPY):
Object(tess,copyop),
_TessellationMode(tess._TessellationMode),
_detailRatio(tess._detailRatio),
_targetNumFaces(tess._targetNumFaces),
_createFrontFace(tess._createFrontFace),
_createBackFace(tess._createBackFace),
_createNormals(tess._createNormals),
_createTextureCoords(tess._createTextureCoords),
_createTop(tess._createTop),
_createBody(tess._createBody),
_createBottom(tess._createBottom) {}
META_Object(osg,TessellationHints);
enum TessellationMode
{
USE_SHAPE_DEFAULTS,
USE_TARGET_NUM_FACES
};
inline void setTessellationMode(TessellationMode mode) { _TessellationMode=mode; }
inline TessellationMode getTessellationMode() const { return _TessellationMode; }
inline void setDetailRatio(float ratio) { _detailRatio = ratio; }
inline float getDetailRatio() const { return _detailRatio; }
inline void setTargetNumFaces(unsigned int target) { _targetNumFaces=target; }
inline unsigned int getTargetNumFaces() const { return _targetNumFaces; }
inline void setCreateFrontFace(bool on) { _createFrontFace=on; }
inline bool getCreateFrontFace() const { return _createFrontFace; }
inline void setCreateBackFace(bool on) { _createBackFace=on; }
inline bool getCreateBackFace() const { return _createBackFace; }
inline void setCreateNormals(bool on) { _createNormals=on; }
inline bool getCreateNormals() const { return _createNormals; }
inline void setCreateTextureCoords(bool on) { _createTextureCoords=on; }
inline bool getCreateTextureCoords() const { return _createTextureCoords; }
inline void setCreateTop(bool on) { _createTop=on; }
inline bool getCreateTop() const { return _createTop; }
inline void setCreateBody(bool on) { _createBody=on; }
inline bool getCreateBody() const { return _createBody; }
inline void setCreateBottom(bool on) { _createBottom=on; }
inline bool getCreateBottom() const { return _createBottom; }
protected:
~TessellationHints() {}
TessellationMode _TessellationMode;
float _detailRatio;
unsigned int _targetNumFaces;
bool _createFrontFace;
bool _createBackFace;
bool _createNormals;
bool _createTextureCoords;
bool _createTop;
bool _createBody;
bool _createBottom;
};
// forward declare;
class Geometry;
2018-04-21 00:18:22 +08:00
/** Convenience class for populating an Geometry with vertex, normals, texture coords and primitives that can render a Shape. */
class OSG_EXPORT BuildShapeGeometryVisitor : public ConstShapeVisitor
{
public:
BuildShapeGeometryVisitor(Geometry* geometry, const TessellationHints* hints);
virtual void apply(const Sphere&);
virtual void apply(const Box&);
virtual void apply(const Cone&);
virtual void apply(const Cylinder&);
virtual void apply(const Capsule&);
virtual void apply(const InfinitePlane&);
virtual void apply(const TriangleMesh&);
virtual void apply(const ConvexHull&);
virtual void apply(const HeightField&);
virtual void apply(const CompositeShape&);
void Normal(const Vec3f& v) { _normals->push_back(v); }
void Normal3f(float x, float y, float z) { _normals->push_back(Vec3(x,y,z)); }
void TexCoord2f(float x, float y) { _texcoords->push_back(Vec2(x,y)); }
void Vertex(const Vec3f& v) { _vertices->push_back(v); }
void Vertex3f(float x, float y, float z) { _vertices->push_back(Vec3(x,y,z)); }
void setMatrix(const Matrixd& m);
void Begin(GLenum mode);
void End();
protected:
BuildShapeGeometryVisitor& operator = (const BuildShapeGeometryVisitor&) { return *this; }
enum SphereHalf { SphereTopHalf, SphereBottomHalf };
// helpers for apply( Cylinder | Sphere | Capsule )
void drawCylinderBody(unsigned int numSegments, float radius, float height);
void drawHalfSphere(unsigned int numSegments, unsigned int numRows, float radius, SphereHalf which, float zOffset = 0.0f);
Geometry* _geometry;
const TessellationHints* _hints;
ref_ptr<Vec3Array> _vertices;
ref_ptr<Vec3Array> _normals;
ref_ptr<Vec2Array> _texcoords;
GLenum _mode;
unsigned int _start_index;
Matrixd _matrix;
Matrixd _inverse;
};
extern OSG_EXPORT Geometry* convertShapeToGeometry(const Shape& shape, const TessellationHints* hints);
extern OSG_EXPORT Geometry* convertShapeToGeometry(const Shape& shape, const TessellationHints* hints, const Vec4& color, Array::Binding colorBinding=Array::BIND_OVERALL);
}
#endif