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