Re: [boost] interest on a geometry library

From: Nigel Stewart (ns_at_[hidden])
Date: 2006-03-24 17:47:37

>> 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.

> 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.

> 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.

> 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. :-)

     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.

>> Fast disply in yade is much less important than geometrical computations
>> themselves - related to physics of the system, not to the graphics.

     That depends what your job is.  Mine happens to be feeding OpenGL
     with information.

Cheers,

Nigel Stewart