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

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

Apologies on the slow response, I tend to bog down when I have to respond to
large numbers of issues in a single e-mail, as I like to do these things all
at once, and getting enough time to respond sometimes takes a while...
suppose I should write shorter e-mails so the responses are shorter :o) .


Regarding "application-specific code"
	I should have been more precise.  There is one function (two if we count
the tetrahedron-drawing function) that appears to be specific to certain
classes of visualisation (that being the glSphereSetDSPL function).  To me
this seems application specific.  Just my opination :) .  Drawing lines and
polygons seems very general to me, I just worry about the generality of the
functions, and can't see myself producing truly general versions of them, as
I'd wind up having to create a loop "protocol" that would basically
constitute a re-architecting of OpenGL 1.1.  On the other hand, I'm quite
willing to let someone else do it ;) .
	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.


Regarding challenging design decisions
	Challenge away :) .  Basically I like the current design, not so much
because of the particular layout, as for the rather rigorous (to my
perception) abstraction applied to the problem of wrapping the libraries.
That abstraction has meant that the effort required to wrap a huge set of
code, while huge, was within the reach of a single programmer.
	Basically I would like to follow the old maxim of consultation that once
tabled, all ideas, designs, and approaches cease to "belong" to their
originators.  Critiques of the particular approaches are critiques of the
particular approaches, not of their originators.  The goal here is to make a
"better" library (and come to some consensus regarding what is better), not
to create a politicized forum and offend everyone and their brother
(brothers are so sensitive sometimes) :o) .  Sorry if any of my comments
were seen as prejudicial, they were not intended as such.


Regarding contributors and contributions
	I obviously misunderstood.  I was under the impression that your group was
uninterested in maintaining code in PyOpenGL.  Your clarification and offer
is greatly appreciated.


Regarding "common functionality"
	One of the things I was hoping to gather from the (still hypothetical)
larger group of people involved in the conversation (anyone out there?) was
the level of need for particular types of functionality.  If there is a huge
need for drawing spheres, then we will need to provide a mechanism for
drawing spheres.  Since that looks to be a considerable effort depending on
the level of generalization, I'm hoping to get some "market research"
stating that the effort will be broadly accepted if completed.  More
importantly, I'm hoping that people with such a need will speak up regarding
the level of functionality/generality they need.  If the current function is
general enough, then we don't need to do much work.  If, as would seem to
me, other applications needing to draw large numbers of spheres would need
significant customizations of the loop, then we really do need to work on
the generality, and should plan for the associated cost (in terms of
manpower).


Regarding state switch optimizations
	My use of the word "funky" was to imply "cool and not immediately obvious
that it is easily accomplished", rather than "weird and undesirable".  I'm
of the impression that most OpenGL 1.1 array drawing implementations
actually do the state change optimizations as well, it's just that the state
being checked is simpler in those systems.


Regarding the build process
	Obviously Tarn is the person best suited to respond here.  Producing
documentation regarding the creation of C extensions under PyOpenGL 2.0 is,
if I'm understanding correctly, one of his priority projects.
	I understand the difficulty you face. The use of SWIG adds an extra step
compared to simple C sources.  The poor documentation for the distutils
project (which is a rather complex system of heavily interacting objects)
makes it difficult to easily understand the effects of the setup scripts.
The rigorous systemization of the project that allows for rapid inclusion of
new modules/packages (such as the 100+ OpenGL extensions) means that another
level of abstraction is introduced.
	Tarn's documentation project in this area is, I think we agree, critical to
the success of the PyOpenGL 2.0 source tree in the future.  As you begin to
understand the system, it might be beneficial for you to mirror back to Tarn
your understanding of the system to clarify for him how the system looks to
an outside observer.  Others could contribute by attempting to create a C
module in concert with Tarn, and using the resulting communication to
develop a tutorial document.


Regarding my "core library" postulate
	I was wrong here.  Tarn was closer to what seems correct to me in his
reply.  That is (if I've understood correctly), that PyOpenGL should only
include code which follows the OpenGL programming paradigms, which match the
mode of operation of the OpenGL libraries.  For instance, in those
libraries, you alter state values of an engine through method calls, then
cause something to happen through another method call.  Individual method
calls generally specify only single pieces of information, allowing for "mix
and match" approaches to enabling/disabling various features.
	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).


Regarding gl_indexedGeomDSPL
	The array drawing functionality of OpenGL 1.1 is highly optimized, so
basically, I don't expect that the color array being enabled will cause a
noticeable slowdown.  To accomplish the material rendering (the only
nonstandard feature if I understand the function correctly) with minimized
state changes, consider the following pseudocode:

for (materialParameters, startIndex, stopIndex) in materialSets:
	changeMaterials (materialParameters)
	glDrawElements( indexArray[startIndex: stopIndex])

With a function setMaterialArray (materialParameterArray) that compiled the
materialParameterArray into an array processable by the loop above.  If the
materialParameterArray were set to None, you simply pass the entire array to
glDrawElements.  This gives you the material state optimizations, the
display list compatibility, and the use of the extremely fast array
functionality if materials are not changing within the object.

	The same materialSets array could be used for your sphere drawing
functions, with the loop looking something like this:

for (materialParameters, startIndex, stopIndex) in materialSets:
	changeMaterials (materialParameters)
	for (transform, radius, slice1, slice2) in sphereDataArray:
		glTranslate( transform)
		glutSolidSphere( radius, slice1, slice2 )
		glTranslate( -transform)

What I would like to see discussed is how general the system needs to be to
support all of the users likely to use the functionality.  Discussions of
appropriate APIs and/or approaches would also be beneficial. Discussions of
constraints on use (numbers of objects, operational environments, data
format requirements) would also be useful.


Regarding Square 1
	Not quite, square one was where I really didn't understand what the code
was doing.  I now understand it and am scared by the "obviously right" (in
my warped little universe) approach to solving the problem :) .  As a
result, I am hoping to get more information to change what I see as the
"obviously right" approach to something simpler and less scary.  (I hate
scary :o) .)


Enjoy yourselves, stay cool, speak up, remain froody, remember Wichita, love
your neighbour, howl at the moon, take time to sit on the beach and reflect
on the wonder of life, take the road less traveled, forget what you know and
seek what someone else knows, remain true to your convictions, become one
with the universe, become one with yourself, become one with at least one
another person, breathe deeply in the morning air, and smile at someone for
no reason save that they are human, and as such, are wonderful.
Mike



-----Original Message-----
From: pyo...@li...
[mailto:pyo...@li...]On Behalf Of Michel
Sanner
Sent: October 1, 2001 19:05
To: pyo...@li...; mcf...@ho...
Cc: fr...@sc...
Subject: [PyOpenGL-Users] Re: Utility module functions, forward
directions, call for opinions/volunteers



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



_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net
_______________________________________________
PyOpenGL-Users mailing list
PyO...@li...
https://lists.sourceforge.net/lists/listinfo/pyopengl-users