Hi Mike,
I'm really cold on this topic right now, and can't really add much
without sitting down and spending time reviewing all the related code,
alas I have very little time for such activities right now.
What might help is to create an OSG example that demonstates what you
are trying to do and highlights the problem points. This example
could then be reviewed by others and checked into the OSG distribution
for testing purposes and for helping out others who walk this path in
the future.
Cheers.
Robert.
On Nov 19, 2007 7:34 PM, Mike Garrity <[EMAIL PROTECTED]> wrote:
> > > 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
>
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
