> > On 10/25/06, Soheil Sotoodeh <[EMAIL PROTECTED]> wrote:
> > Hi Robert,
> >
> > Thanks, I've checked that, it is a quite extensive
> > documentation.
> >
> > I also have two question about the basic types.
> >
> > Consider that we have a point cloud (a set of points).
> > As far as I understood, in openGL when we add the
> > pointcloud by a sequence of glVertex calls, openGL
> > makes a copy of the coordinate values. Now when we
> > have OSG we add the points by a osg::Geometry object.
> >
> > [snip]
> >
> > Q2: Is there any approach that I can use a custom
> > point/vec3 (my own type) instead of osg::Vec3 in
> > osg::Geometry?
> > By that I mean having shared point objects for both
> > OSG and my application.
> >
> > [snip]
> >
> > Thanks for your suggestions,
> > Cheers,
> > Soheil
> >
> From: Robert Osfield <[EMAIL PROTECTED]>
> Subject: Re: shared points (between OSG and the application using OSG)
>
> Hi Shoeil,
>
> With real-time graphics go often end up with 3 copies of your imagery
> and vertex data, one on the CPU side, one on the OpenGL driver, and
> one on GPU.
>
> The OSG supports deallocating imagery automatically once its passed
> to OpenGL, so that only OpenGL retains it as a texture object.
>
> Potentially you can do this on the geometry side too, but there are
> more pitfalls as all your intersection code will fail.
>
> As for passing custom geometry to osg::Geometry, perhaps subclassing
> osg::Array will be sufficient. Not all OSG ops will work though, even
> if the graphics works fine.
>
Hi Robert. I'm currently trying exactly what you describe here.
Creating my own subclass of osg::Array and using it as the vertex
array for a osg::Geometry. I've run into a few rough spots.
Geometry.cpp contains things like this:
const Vec2Array* vec2Array = 0;
const Vec3Array* vec3Array = 0;
const Vec4Array* vec4Array = 0;
Array::Type type = _vertexData.array->getType();
switch(type)
{
case(Array::Vec2ArrayType):
vec2Array = static_cast<const
Vec2Array*>(_vertexData.array.get());
break;
case(Array::Vec3ArrayType):
vec3Array = static_cast<const
Vec3Array*>(_vertexData.array.get());
break;
case(Array::Vec4ArrayType):
vec4Array = static_cast<const
Vec4Array*>(_vertexData.array.get());
break;
default:
notify(WARN)<<"Warning: Geometry::accept(PrimtiveFunctor&) cannot
handle Vertex Array type"
<<_vertexData.array->getType()<<std::endl;
return;
}
which means that user-defined subclasses of Array are not supported.
I could have my subclass return one of the existing values for
getType, but then the static_cast is not correct. I worked around
that with something like this:
const Vec2* vec2Array = 0;
const Vec3* vec3Array = 0;
const Vec4* vec4Array = 0;
Array::Type type = _vertexData.array->getType();
switch(type)
{
case(Array::Vec2ArrayType):
vec2Array = static_cast<const
Vec2*>(_vertexData.array->getDataPointer());
break;
case(Array::Vec3ArrayType):
vec3Array = static_cast<const
Vec3*>(_vertexData.array->getDataPointer());
break;
case(Array::Vec4ArrayType):
vec4Array = static_cast<const
Vec4*>(_vertexData.array->getDataPointer());
break;
default:
notify(WARN)<<"Warning: Geometry::accept(PrimtiveFunctor&) cannot
handle Vertex Array type"
<<_vertexData.array->getType()<<std::endl;
return;
}
and that seems to work OK, but it's not clear to me whether this
is how you intend getType to be used. Do you think that getType is
telling an Array's user what type of data it is holding, or what
type of Array class it is? Currently the two are the same, but if
you add new subclasses of Array, then the difference becomes
important.
There are a few other, similar downcasts of Array in Geometry.cpp.
I haven't seen any in other files.
The application here is that we have geometric data that is
already stored in something other than a std::vector and I'd like
to wrap it up for OSG's use without making a copy. What do you
think would be the best approach here?
Thanks,
- Mike Garrity
- The MathWorks
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
