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

[Michel S. <sa...@sc...>]

> From: "Mike C. Fletcher" <mcf...@ho...>
> 
> 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.
> 
Being the author of some of the functions discussed in this email 
(gl_TriangleNormals, gl_indexedGeomDSPL, glSphereSetDSPL) I would like to 
provide my point of vue :). I agree tyhat thse fucntion could be made more 
general (more flexible indexing scheme etc...). This being said, I would like to 
re-iterate here that in my opinion drawing a large set of spheres, lines, 
polygons or 3D labels is NOT specific to molecular visualization. I believe that 
such functions are basic to any kind of scientific visualization and in fact I 
have people using my applications to visualize meshes used in cardiac 
simulations and displaying neurons and neural networks (the real ones *wink*) 
and tree like structures representing amino acid mutations !. The bottom line 
is: they are all geometries (lines, triangles, spheres) and this is what DejaVu 
deals with.

> 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.
> 
I have about 3 and 1/2 programmers working with me and we want to contribute to 
the PyOpenGL project and maintain code. We have access to Windows, SGI, Solaris, 
Linux amd DeC Alpha machines here and we use PyOpenGL on all of them.
We have started trying to port PyOpenGL to Solaris and Dec Alpha (and are having 
some problems there). We are very impressed by the amount of work that has 
already be done in PyOpenGL2.0 and are very open to suggestions on how to 
evolve/re-implement/replace what we have done with with PyOpenGL. We are 
convinced that having people challenge what we did will be beneficial inthe long 
term. We hope that you feel the same about what has already be done on your side 
too.

> 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.
> 
This is a somewhat subjective statment in my view. I guess that "commonly 
needed" depends on what you are doing. For instance, we have never used 
multi-texturing (yet) ! 

> 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.
> 
I would not qualify state switches as funky. They are crucial to rendering 
performance.
 
> 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).
> 
:) are we back at square one ?

> 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).
> 
Again, we are willing to help here and we have some resources. One caveat though 
is that we (frederic Giacommeti and I) have looked at the PyOpenGL building 
process. We both have a fairly broad experience in programming Python, C and 
using SWIG but were unable to follow through the building process in order to 
fix it for the solaris and OSF. We have raised that point with Tarn and he has 
started to answer why and how it works. We need now to understand it all in 
order to be able contribute. 

> 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.
> 
Can you explain what you call the "core library". I see that the GLE source code 
is distributed with the PyOpenGL source. I believe that we should be able to add 
"helper functions" into something analog to GLE. Importing it from another .so 
than GL function is not a problem for us. Having to download another Python 
package and build it would be.

> 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.
> 
Again, none of the functions we have added so far are specific to molecular 
visualization. In fact, the very design of DejaVu is based on the idea that the 
visualization component DOES NOT need to know what the objects are represented 
using geometries in the viewer. Spheres can represent atoms, planets, balls on a 
Pool table or particles in a field. The point is that when you need to build a 
display list for lots of them you definitely do not want to do it in a Python 
loop.

> 
> 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.

We are willing to help here. We can generalize it based on suggestion and since 
we use it on more paltforms that PyOpenGL2.0 runs on I believe that there would 
be no support cost for you. I am looking to glDrawArray to replace it. but if 
this function sends a glColor or a glMaterial for every vertex when only a few 
are needed then it will definitly not be an alternative.

> 
> 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,

Same remark as for gl_indexedGeomDSPL

> 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?
> 
A first thing that must happen in my opinion is that the wrapping of the GL 
libray itself be discussed and understood by more people than just Tarn. I 
truely believe that this is crucial for the PyOpenGL project future. (And we are 
investing time and effort on this point.)

As I said before Iwe are trying to put some of our functions into a GL extension 
(I do not know yet how you call this in your terminology, but somewhat 
equivalent to GLE). This would enable us to transition to PyOpenGL2.0 smoothly.

> Who sometimes wonders how he wound up maintaining this project when he can't
> even code in the implementation language :) .
>
I appreciate very much what you guys have been doing and we are eager to help !

Cordially

-Michel 


-----------------------------------------------------------------------

Michel F. Sanner Ph.D.                   The Scripps Research Institute
Assistant Professor			Department of Molecular Biology
					  10550 North Torrey Pines Road
Tel. (858) 784-2341				     La Jolla, CA 92037
Fax. (858) 784-2860
sa...@sc...                        http://www.scripps.edu/sanner
-----------------------------------------------------------------------