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

[Mike C. F. <mcf...@ho...>]

Michel, Tarn and I have been discussing this stuff off-list, I figured it
was time to involve a wider group, since these are decisions which involve
the entire library.  The following is my own opinion, I don't claim to speak
for Tarn or Michel, or really, anyone.


I have been looking at the PyOpenGL 1.5.7 utilities library and attempting
to figure out what parts of this functionality (if any) good and/or should
be added to the PyOpenGL 2.x code base.  I am faced with the problem that
some of the code as written is application-specific (targeted at
visualization of molecules), and largely duplicates functionality available
in OpenGL 1.1.

I am of the opinion that the code as written does not really belong in a
general package such as PyOpenGL, and am very hesitant to take on the
responsibility of maintaining code which does not appear to belong.

There are, however, some things done by the code which are not readily
accomplished using python.  For example, the code provides a mechanism for
drawing huge numbers (~100,000) of GLUT spheres with certain material
parameters.  This is not something which is (in my experience) commonly
needed, but I am told that in situations where it is needed, it is
critically needed.

In response to the situation, I worked on creating a pseudocode
specification of a generalized version of the code.  In effect, each of
these loops is a binding such that some arrays of data are looped over.
Some number of functions operate on each iteration of the loop, most taking
a reference to the current value of a given array (though this is not
necessarily true).  For those familiar with the OpenGL 1.1 specification,
this sounds eerily similar to the functionality of the array drawing code.

My pseudocode solution would provide a few minor enhancements beyond that
provided by OpenGL 1.1's array drawing mechanisms:

	Each array could be specified according to its natural data format (i.e.
you could mix indexed and non-indexed arrays in a single loop).  This would
allow you (theoretically) to save memory and upfront processing effort (as
opposed to the array drawing functionality, where the indexing scheme of all
parallel arrays must be identical).

	You would be able to plug-in new functions to the loop (defined either in C
or python)

	For given C helper functions, you'd be able to avoid the overhead of a
Python loop -- basically this is the primary argument for such a system.

	Theoretically, you could code some funky mechanisms into the loop allowing
for funky effects such as avoiding state switches, performing multiple
rendering passes with a single call, etc.

Obviously, however, these loops will not be anything like as fast as the
hardware-implemented loops of the standard array drawing functionality, even
if the functions are all C-coded.  The practicality of using a Python
function is likely minimal save for very early prototyping (you wouldn't
want to draw 100,000 items using a Python call).  So, most real-world
functionality would require a C module to be written and maintained by the
end-user of the functionality (which suggests they could just as easily
write the code directly in C and wrap it with SWIG).

The benefits of the rather involved process of building the system (in C)
appear rather limited, and the overhead of maintaining the code seems
considerable.  I don't see this as a useful path forward for the project.
Which leaves me still needing to make a decision regarding these functions.

Options:

1) Leave the functions out of the core PyOpenGL library (as is currently
done).  Allow/assist those interested in such functions to easily build a
project to generate a shared library for their platforms containing whatever
code is appropriate to their applications.  At present this appears to me to
be the most appropriate approach given the rather limited resources of the
PyOpenGL project (the most precious of those being Tarn's time).

Basically, I would like to make the process of creating such application
and/or application-class specific packages as simple as possible, so that
those who have a vested interest in maintaining such code can maintain the
code themselves and share it among those who are interested in the
functions.  If there is significant interest in a package, and it is fairly
general and widely used, but without a group having vested interest in
maintaining it, then we might consider devoting PyOpenGL resources to it.

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.

2) Include the legacy code in PyOpenGL 2.0 verbatim, or with modifications
to take advantage of the significance simplifications and automations in the
2.0 code base.  To me this is not a good solution, as it again pushes
maintenance work for application-specific code into the generalized code
base.  I'm interested in seeing if people have significant enough interest
in the functions that this approach should be taken.

I mention here that someone stepping up to say "I would like the work to be
done" will have considerably less influence than someone stepping up to say
"I would like the work to be done, and will do the work to make this
generalized, to make interact nicely with the rest of the system, and to
deal with any errors that arise."


Some other notes:
	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.


For your reference, here are the functions referenced above and my current
thoughts on them:

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.

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.

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

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.

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.

So, basically I'm wondering how much real interest there is in these
particular functions, how much effort is willing to rise and apply itself to
the work involved, and whether there are other options that you can see.

If, as I expect, we travel down the first option path, what do we need to do
for you?  Has anyone produced C extension modules using PyOpenGL 2.0?  Is
there anything we can do to make that easier for you?

Enjoy yourselves,
Mike Fletcher
Who sometimes wonders how he wound up maintaining this project when he can't
even code in the implementation language :) .