Re: [boost] interest on a geometry library

From: Andy Little (andy_at_[hidden])
Date: 2006-03-26 06:26:13

"Nigel Stewart" wrote

>>> My elaborate explanations about anonymous union simply demonstrate that
>>> full opengl compatibility comes at huge price - it forces internal data
>>> structure. A huge no-no in good OO design.
>
>     Not necessarily, if what you're primarily interested in doing is
>     OpenGL.  I think there is a middle ground that is OpenGL-friendly
>     without being OpenGL-centric.

Pragmatically what I'm interested in is finding some basic Graphics capability,
which is cross-platform  and available, just because that is the natural output
format for geometry and would be very helpful for a geometry library. I have
heard that GLUT could provide this basic functionality. Is that the case?

>> vec2 a two component floating-point vector
>> vec3 a three component floating-point vector
> ...
>> ivec4 a four component integer vector
>>
>> With C++ templates one could represent all those in one class template
>
>     They could, but from an OpenGL point of view, it would also be
>     nice to have typedefs that have the type and dimension built into
>     the typename, OpenGL-style.  Such as vertex2i, vertex2f, vertex3d.
>     (The OpenGL API has variants such as glVertex2i, glVertex2f, etc)
>
>     Along with that, a boost::gl namespace could wrap the entire OpenGL API
>     glVertex2i(x,y)  -> boost::gl::vertex(v)
>     glVertex2f(x,y)  -> boost::gl::vertex(v)
>     glVertex3d(x,y)  -> boost::gl::vertex(v)
>
>> Secondly, the OpenGL?vec? family above is used IIRC as a standard container
>> for
>> different purposes, such as a vertex, or a color, but IMO it would be
>> more 'user friendly' to create a color type and a vertex type and only
>> convert
>> them to their low level OpenGL ?vec? equivalents for output,
>
>     More "user friendly" could be debated, but certainly more statically
>     type-safe to have color3f and vertex3f versus vector3f for both.
>
>     But, it is often useful to treat colors as vectors for interpolation,
>     so there needs to be conversions.
>
>     Here is an interesting question: Should there be a normal that behaves
>     differently to a vector? (or vertex?)  In the case of 4x4 matrix
>     transformation, the translation is applied to vertecies, but not normals.

If the functionality of two entities is different then why make them the same
type?  The practicality is that 1 type
is less work to implement. OTOH Using that argument as the sole criteria we
would make every type an array of bytes of course. In C++ I find the ability of
the compiler to act based on types very useful(e.g for overloaded functions)
However that asssumes its possible to get the correct behaviour.

As far as a normal is concemed it might be characterised best as a direction,
would it
That would differentiate it from a vector which also has magnitude.
Similarly a vertex is not a  vector, but rather a point in space.
In the abstract it seems to be a good idea to see these as separate types, in
order always to be as precise as possible, in practise try to keep with the
principle unless the problems of implementing it are too great.

>> The general thrust of the above is that I would prefer to end up with a User
>> Orientated design as opposed to a design which provides low level primitives
>> of
>> indeterminate meaning (eg using the same vector type to hold a vertex and a
>> color as raw Open GL does).
>
>     OpenGL accepts either arrays or named x,y,z parameters, but I would like
>     to clarify that OpenGL is a C API with no structures or types except for
>     GLfloat, GLdouble, etc.

Theres no dispute there (Well I thought I read That OpenGL API was close to but
not same as C e.g GL int is 32 bits whereas in C its system dependent size etc,
but could be wrong) However as this NG is C++ specific we can do better IMO.

>> The  downside of using  higher  level  Concepts is that One may end up with a
>> lot of structurally similar looking  entities. The upside may be that what we
>> are really discussing is Concepts which might correspond with the SoCalled
>> Generic Programming approach. A simple example of the difference.
>
>     In the OpenGL context I'm interested in doing certain things in a
>     concise efficient way.  Genericity does not necessarily serve that
>     purpose.  It seems to me that an OpenGL-centric layer based on
>     a templated generic library might serve both purposes, but I havn't
>     seen that actually put into practice. :-)

Point is that C++ compiler technology is  much improved recently, so a lot more
is now possible in practise than a few years ago where it was theoretically
possible but stymied by the compiler.

>     My intuition is that the genericity of templates isn't a good match
>     for the specifically crafted OpenGL API that is rooted in assumptions
>     about computer graphics hardware.  A wrapper namespace might be a
>     good way to harmonise between the general mathematical viewpoint and
>     the specificness of OpenGL.

Only one way to find out , which is to try building it I guess. :-)

regards
Andy little