> > 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
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to