"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