Hi Aurelien,

On 3 June 2013 10:58, Aurelien Albert <[email protected]> wrote:
> At first sight, I think "Array::s/getNormalize()" and 
> "Array::s/getMaintainDataType()" are really good ideas.
>
> But sometimes (in very specific situation) one could want to use the same 
> osg::Array with different parameters for different geometries, so in this 
> case the "Array::s/getNormalize()" and "Array::s/getMaintainDataType()" 
> should become "Geometry::ArrayData::s/getNormalize()" and 
> "Geometry::ArrayData::s/getMaintainDataType()".

Personally such convoluted sharing of data for different purposes is
something we should dissuaded users from doing.  It might sound
"clever" and "efficient" but it would be crazy to maintain.  I can't
think of good reason why you'd want users to in one place normalize an
array, then in another not, then in one place treat the data as int's
and another have it converted to standard OpenGL floats.   If you can
find one really compelling and essential reason for doing this then
I'm inclined to put this in the bin ideas that just aren't good.

> And I think this also could lead to mixing different concepts : until now
>
> - I'm thinking about the osg::Array class as a "CPU data container" and 
> nothing more : there is no "hard link" betweeen osg::Array and openGL API.
>
> - I'm thinking about the osg::Geometry::ArrayData as a "CPU data container 
> OpengL  binding" : there is no management of CPU data here, only the binding 
> of these data to the openGL device.

Indeed, osg::Array has long been a data container, but it's has been
as a OpenGL vertex data container - it's DataType is expressed in
OpenGL terms, it's an BufferData so is associated to OpenGL buffer
objects.  If we are storing data from the array in a buffer object
then to have some of the details of how it's stored not completed
contained in the Array is a bit odd.

Robert.
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org

Reply via email to