GLU3 FTW!

I just finished pitching my fledgling GLU3 library to the ARB, and everybody loved it. Quite a few people said that they've hacked up something similar, but much less complete, to get simple demo apps running. A few of the people had functionality not in the library, and it sounds like I may get a few code contributions. It also sounds like it may be included in the OpenGL SDK. Yay me!

For those interested, the doxygen documentation is at:

http://people.freedesktop.org/~idr/glu3

The GIT tree for the code is available at:

git://anongit.freedesktop.org/~idr/glu3

At some point the tree will probably move somewhere that can allow direct commits by people other than me. I'll cross that bridge when I come to it.

RSS Atom

git URL

You probably want to advertise the "anongit" URL instead: git://anongit.freedesktop.org/~idr/glu3

Comment by Scott Tsai — Fri 22 Jan 2010 08:55:31 AM PST

Yay

Congrats!

Comment by Greg — Fri 22 Jan 2010 09:57:48 AM PST

SIMD support

I'm not sure if it's a target goal of yours at all, but in the interest of possibly (finally!) including a decently high-performance math library with OpenGL, perhaps you should take a look at the API changes necessary to ensure that GLU3 can be used with common compilers' SIMD support.

In particular, check out this article on some of the limitations and changes you have to make to a math library's API to work around many common compiler limitations: http://www.gamasutra.com/view/feature/4248/designing_fast_crossplatform_simd_.php

Comment by Sean — Fri 22 Jan 2010 03:23:22 PM PST

RE: SIMD support

I read that article when it was printed in Game Developer. Yeah, that is part of the plan. That is one of the main motivations behind putting the inlined functions in a separate header file. My expectation is that most of the GLUvec4 operations will end up just being wrappers around the compiler SIMD intrinsics.

Some of the inspiration for GLU3 came from the vectormath library in Bullet. I had been using that for a long time, but quite a few aspects of its design (effectively no C interfaces, the Vector3 vs. Vector4 vs. Point3 bonghits, etc.) and massive amounts of bugs in the SSE implementations (Matrix4::lookAt is completely borked) caused me to abandon it. I do not intend to replicate the SOA vs. AOS organizations from vectormath. I think that was a design mistake. My preference is to provide some fundamental tools and instruct people how to use those tools to implement SOA or AOS.

I haven't implemented any of the SIMD versions because I haven't needed them. There's a lot of basic functionality that I want to implement first.