RE: [PyOpenGL-Users] Utility module functions, forward directions, call for opinions/volunteers

[Tarn W. B. <twb...@ma...>]

Just thought I put in my two cents.

| With that said, I would like to keep the core library "The Python OpenGL
| Wrapper", that is, a wrapper around the OpenGL library, with external
| projects (such as OpenGLContext) dealing with application-class specific
| enhancements.

If we stick to this idea in a strict sense what about modules like GLE?
Instead I believe that additional modules should stick to the "spirit" of
OpenGL in that they are either simple window toolkits (read GLUT) or drawing
modules (GLE, gl2ps, etc.) excluding modules that implement scene graphs or
generalize window toolkits (OpenGLContext)

| 	Concern has been raised regarding the need to compile
| "other libraries" in
| order to use PyOpenGL within application-class specific projects (i.e.
| needing to compile both PyOpenGL and "PyOpenGL-Molecular" in order to
| develop a Python protein visualization application).  I would like to know
| how big an issue this really is.  My gut reaction is that compiling a
| distutils-enabled project is fairly trivial, and once the PyOpenGL setup
| script runs, you basically can compile any other PyOpenGL-based code as
| easily as if it were included in the PyOpenGL project.

My current plan is create a setup framework which uses the backbone of the
PyOpenGL setup which would allow third parties to easily create modules to
use the SWIG typemaps, error handling and interact with PyOpenGL as if it
was part of the core.

| gl_TriangleNormals -- this function provides functionality not readily
| accomplishable using Python code when dealing with extremely large models.
| The function is fairly general, and could be made more so. It solves a
| general problem, namely that code to do normal generation is too slow when
| written in Python to handle extremely large geometries.  It (or something
| similar) might be included in a utility module of the core system.

Pure calculation routine.  I don't really see a place for this in PyOpenGL.

| gl_indexedGeomDSPL -- the primary "loop" function, basically, with the
| exception of modifying material properties during the loop, and the format
| of the arrays, is a call to glDrawElements.  There are some optimizations
| for avoiding state switches, and the function always generates a display
| list.  I'm of the opinion that using glDrawElements would be a cleaner
| approach even with the potential for a greater memory and set up penalty.
| There are benefits here, but I'm not sure they outweigh the maintenance
| overhead of the approach.

Although I am not sure that the existing implementation should be used I see
an honest general use for this.

| gl_Tetrahedra -- another application-specific function, should
| really be in
| an external module as far as I can see.

Yes, but what about glutSphere, glutCube?  If there were enough other solids
one could have a "geometry" module.  Or maybe this should be a feature
request to GLUT.

| glSphereSetDSPL -- basically a loop for calling glutSolidSphere to draw
| large numbers of spheres with various material parameters being set.  This
| is one of those "really important for a particular application class"
| functions that seem to belong in an external module.

Drawing large numbers of small spheres is almost a particle problem.  What
about using GL_ARB_point_parameters?

| gl_TrianglesWithNormals, gl_Triangles, gl_Lines, gl_Points,
| gl_ColorVertex2d, gl_Vertex -- the equivalent of enabling various arrays
| using OpenGL 1.1 and drawing.  These have little or no chance of
| being added
| to the core library.

Agree!

thanks,
Tarn