Hi Wojtek,
On 10 October 2013 15:36, Wojciech Lewandowski <[email protected]>wrote: > Don't want to take part in optimization disussions. But I do see few > arguments for float quaternions: > > - completness: we have float/double matrices, float/double vertices and > that makes a valid context for float quaternions. When one use float verts > and float matrices he may not need double quaternions. > I still follow the "minimal and complete" guide to the OSG, it's already a very large API so new classes really have to have a strong justification for inclusion. > - mobile devices and OpenGL ES: many cell phone CPUs emulate floating > point. I am not sure how many of them is still in wide use but I am sure > you would see the speed difference between emulated float and emulated > double. Btw Łukasz mentioned he may want to use it in embeded environment. > It may mean such CPUs as well. > This will only be a problem for very specific platforms and very specific applications - most applications will only use osg::Quat very sparingly and shouldn't be calling it many thousands of times per frame, so a small CPU overhead shouldn't be a big issue. If it's proven to be a performance issue then the issue changes, but still there needs to be strong justification. > - size: it may matter if one has a need for large number of quaternions. > Geometry instancing ? I see a benefit when storing thousands of quaternions > to texture and there is no need to go through CPU floating point unit to > convert them to floats. Hardware bone animations could probably benefit too. > We don't currently pass Quaternions to OpenGL, they are just used on the CPU side. If the user is passing quaternions to OpenGL currently they'd do it use an osg::Vec4fArray, while it's not as conceptually convinient as a QuatfArrray it would probably work just fine for most users. We have to be careful about coming up with imaginary problems to solve and then coming up with a solution. We need concrete problems and any solution has to have a measurable use without easy alternatives. Robert.
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
