Re: [boost] [gsoc] Interest check for 3d geometry proposal

Subject: Re: [boost] [gsoc] Interest check for 3d geometry proposal
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-03-27 19:45:27

On Fri, Mar 27, 2009 at 2:37 PM, Kornel Kisielewicz
<kornel.kisielewicz_at_[hidden]> wrote:
> On Fri, Mar 27, 2009 at 9:33 PM, troy d. straszheim <troy_at_[hidden]> wrote:
>> Fernando Cacciola wrote:
>>>
>>> Hi Kornel,
>>>
>>> FWIW, after all this thread I still feel that it not sufficiently clear
>>> what you propose to work on, and how do you plan to manage to apparent or
>>> actual overlap between your proposal and related projects.
>>>
>>> So, can you TOP POST a message with summary of your proposal but with
>>> sufficient detail so potential metors can evaluate it?
>>>
>>> Make sure to contrast that very carefully with exiting libraries and
>>> proposals, inclusing Quaternions (which already exists), Boost.SIMD, Spatial
>>> Indexes from Federico Fernandez, GTl and GLL.
>>>
>>
>> One thing boost doesn't have is a fixed-size matrix class, which could be
>> used with boost::array as a building block for a lot of the more
>> game-specific tech involved.  Seems to me a boost::matrix class (essentially
>> a 2d boost::array) would be of reasonable scope/difficulty for a GSOC
>> project.  If there's time left over, one could investigate making optimized
>> rotations, dot projects, reflections and the like as freestanding
>> functions/operators in a special namespace somewhere.
>
> And this is definitively what I'd also like to do. As it seems an
> important topic, I'd make it the base of my proposal.

A 2D boost array is an overkill for a boost matrix class. In fact the
whole point of a game-developer-centric matrix/vector support is to
make the types simple and to the point.

For that purpose, all you need is the following types:

struct float2 { float x, y; };
struct float3 { float x, y, z; };
struct float4 { float x, y, z, w; };

struct float22 { float a11, a12, a21, a22; };
struct float33 { float a11, a12, a13, a21, a22, a23, a31, a32, a33; };
struct float44 { float a11, a12, a13, a14, a21, a22, a23, a24, a31,
a32, a33, a34, a41, a42, a43, a44; };

And a bunch of namespace-scope functions that work with them, for example:

float33 matrix( float a11, float a12, float a13, float a21, float a22,
float a23, float a31, float a32, float a33 );
float33 float33_zero();
float33 float33_identity();
float33 float33_row_major( float const m[3][3] );
float33 float33_col_major( float const m[3][3] );
float33 float33_row_major( float const m[9] );
float33 float33_col_major( float const m[9] );
float33 float33_rotx( float angle );
float33 float33_roty( float angle );
float33 float33_rotz( float angle );
float33 operator*( float33 const & l, float33 const & r );
.....etc.....

For any other application, you'd need a more generic and more abstract
interface, but such interface will just get in the way for game
development.

Also, if your goal is to get a wide spectrum of APIs (engines,
middleware, etc.) to talk through a common (boost) game development
math interface, it has to be as basic as this. Otherwise you'll run
into practical issues (ABI compatibility, etc.) as well as other
excuses not to support it.

Regardless, I'm skeptical. Chances are, the industry simply won't
adopt a common interface for this stuff, no matter what. :)

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode