Hi Sean,
On Thu, Mar 25, 2010 at 7:34 PM, Sean Spicer sean.spi...@aqumin.com wrote:
I came across a nasty little bug today:
(a) Create an osg::Geometry and assign a vertex array that is an
osg::Vec4Array
(b) Try to pick with a LineSegmentIntersector
(c) CRASH
Ouch.
Digging a little bit,
I came across a nasty little bug today:
(a) Create an osg::Geometry and assign a vertex array that is an osg::Vec4Array
(b) Try to pick with a LineSegmentIntersector
(c) CRASH
Digging a little bit, it looks like LineSegmentIntersector assumes
that vertex arrays are always of type osg::Vec3Array.
Sean Spicer wrote:
I came across a nasty little bug today:
(a) Create an osg::Geometry and assign a vertex array that is an osg::Vec4Array
(b) Try to pick with a LineSegmentIntersector
(c) CRASH
Digging a little bit, it looks like LineSegmentIntersector assumes
that vertex arrays are always of
Without giving away too much IP, one of the reasons why one might want
to think about using Vec4Arrays is to take advantage of host-side SIMD
operations - which commonly use 128bit registers (4 floats).
I agree, this is a can of worms.
sean
Looking at osg::State::setVertexPointer(const Array *array), I see
that the stride parameter is always 0. If we relaxed this
constraint, and allowed an Array to have a stride, I might be able to
overcome the problem I am working on. Any comments on what impact
this might have ?
Also, in order
Sean Spicer wrote:
Without giving away too much IP, one of the reasons why one might want
to think about using Vec4Arrays is to take advantage of host-side SIMD
operations - which commonly use 128bit registers (4 floats).
I agree, this is a can of worms.
Mmmm, yes, I suppose that would be
6 matches
Mail list logo