| With that said, apparently Tarn is more open to this
| function, so he may
| just overrule me and create and/or allow a package for such geometry
| mechanisms. For now I will assume that is the case, and therefore assume
| that the functionality will be encoded somewhere.
It just occurred to me that my previous position was a bit dogmatic, so I
softened it but it ended sounding like a complete reversal. Anyways, this
is my current thinking.
glIndexedGeomDSPL and glSphereSetDSPL have a potential for general use, but
from my perspective there is no possiblity of including the functions as is
in the PyOpenGL core. First off both functions compile to straight to
display list. This goes directly against the OpenGL paradigm. Instead, any
drawing functions should produce output on the active buffer unless the user
surrounds the call with display list compilation. Secondly, I think that
both functions could be a bit more general. This would remove the debate as
to whether these are application specific functions.
For glIndexedGeomDSPL this probably means adding crease angle support.
There may be more capabilities that are worth adding that I don't know
about. Since Mike probably knows more about indexed geometry use , because
he has done some significant VRML work, I'll defer to him.
I've thought a bit about how I would implement glSphereSetDSPL given the
chance. My conclusion is that what one wants to do in a general sense is
have to ability to draw a whole collection of solids as if one was using a
function like a glMultiDrawArraysEXT (see
http://oss.sgi.com/projects/ogl-sample/registry/EXT/multi_draw_arrays.txt)
or glMultiModeDrawArraysIBM (see
http://oss.sgi.com/projects/ogl-sample/registry/IBM/multimode_draw_arrays.tx
t) but where the types of primitives (mode parameter) would be: SPHERE,
TORUS, TETRAHEDRON, etc.
In my mind this is the kind of development that needs to happen in order to
include these types of functions in the core. Unfortunatly I don't have the
time to pursue this because there are issues that are *much* more pressing.
This ends up meaning that if others don't step up to plate that it won't get
done. I'd also like to point out that in any solution "wrapping" an
existing library is preferable to creating our own code just from a
maintainance perspective. So if there an existing library out there
(haven't looked yet) than this is the way to go.
| Which brings up the question of whether the quaternion and
| trackball code
| should really be part of the library. I'm not sure whether these
| pieces of
| code should be included, as they don't really follow the OpenGL
| paradigms as
| I understand them. (I could very well be wrong on that, just my opinion).
I would tend to say that they don't fit into the core. Having a separate
"graphics math & utility" package would make more sense. As Mike probably
remembers, I was kicking and screaming a bit at the time of their
inclusion, although I couldn't seem to identify exactly why.
thanks all,
Tarn
p.s. What does froody mean?
|
