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_castconst
Vec2Array*(_vertexData.array.get());
break;
case(Array::Vec3ArrayType):
vec3Array = static_castconst
Vec3Array*(_vertexData.array.get());
break;
case(Array::Vec4ArrayType):
vec4Array = static_castconst
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_castconst
Vec2*(_vertexData.array-getDataPointer());
break;
case(Array::Vec3ArrayType):
vec3Array = static_castconst
Vec3*(_vertexData.array-getDataPointer());
break;
case(Array::Vec4ArrayType):
vec4Array = static_castconst
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
___
