pyopengl-users — Discussion of all PyOpenGL matters.

RE: [PyOpenGL-Users] Have exceptions terminate glutMainLoop

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

I'm not in agreement regarding the "right way" here.

For instance, if you force an exit on an uncaught exception, then any
callback raising an exception can cause data loss for the user (a
spurious/unimportant exception is raised, rather than being able to use some
other menu item (or whatever) to attempt to save their data, the user is
booted right out of the program (likely not even seeing the error if they've
launched the program directly instead of from a shell)).

Fail on any exception is nice for scripting/testing environments, but
kicking out of the whole application in larger projects seems too heavy to
me.  Would redirecting stderr to a log file work?  I haven't tried it
lately, but I think it should be able to catch the exception output.

Anyway, it's late, I'm going to sleep. Enjoy yourselves,
Mike


-----Original Message-----
From: pyo...@li...
[mailto:pyo...@li...]On Behalf Of Tarn
Weisner Burton
Sent: October 5, 2001 19:29
To: PyOpenGL Mailing List
Subject: RE: [PyOpenGL-Users] Have exceptions terminate glutMainLoop


| Would it be possible to have exceptions raised during
| glutMainLoop processing
| (ie. in the callbacks) actually terminate the loop? I find that
| if there is a
| problem, the exception ends up scrolling way off the screen when
| the matrix
| stack gets confused. I then have to quickly terminate my program
| before the
| initial exception disappears - which happens often when I'm working in
| fullscreen mode.

glutMainLoop never returns so it's not possible to pass an exception through
the loop.  Right now all exceptions are caught before reentering the loop.
I did this mostly to make sys.exit work as this was broken in PyGLUT.
Although after a bit more thought I think the right way to do this is to
exit the script completely on an exception.  But for right now if you want
to halt the loop this is what you will have to do:

----------------
import traceback

def on_display():
	try:
		# draw
	except:
		traceback.print_exc()
		sys.exit(1)

glutDisplayFunc(on_display)
glutMainLoop()
print "This print never gets executed"
----------------

Tarn


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

RE: [PyOpenGL-Users] Have exceptions terminate glutMainLoop

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

| Would it be possible to have exceptions raised during
| glutMainLoop processing
| (ie. in the callbacks) actually terminate the loop? I find that
| if there is a
| problem, the exception ends up scrolling way off the screen when
| the matrix
| stack gets confused. I then have to quickly terminate my program
| before the
| initial exception disappears - which happens often when I'm working in
| fullscreen mode.

glutMainLoop never returns so it's not possible to pass an exception through
the loop.  Right now all exceptions are caught before reentering the loop.
I did this mostly to make sys.exit work as this was broken in PyGLUT.
Although after a bit more thought I think the right way to do this is to
exit the script completely on an exception.  But for right now if you want
to halt the loop this is what you will have to do:

----------------
import traceback

def on_display():
	try:
		# draw
	except:
		traceback.print_exc()
		sys.exit(1)

glutDisplayFunc(on_display)
glutMainLoop()
print "This print never gets executed"
----------------

Tarn

[PyOpenGL-Users] Have exceptions terminate glutMainLoop

[Richard J. <ric...@op...>]

Would it be possible to have exceptions raised during glutMainLoop processing 
(ie. in the callbacks) actually terminate the loop? I find that if there is a 
problem, the exception ends up scrolling way off the screen when the matrix 
stack gets confused. I then have to quickly terminate my program before the 
initial exception disappears - which happens often when I'm working in 
fullscreen mode.

Having the exception propogate back up through glutMainLoop would make 
debugging much easier.


    Richard

[PyOpenGL-Users] [ pyopengl-Feature Requests-455686 ] Demonstration of py2exe with PyOpenGL

[<no...@so...>]

Feature Requests item #455686, was opened at 2001-08-27 00:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355988&aid=455686&group_id=5988

Category: Demo
Group: v2.0
Status: Open
Resolution: None
Priority: 3
Submitted By: Mike C. Fletcher (mcfletch)
Assigned to: Tarn Weisner Burton (twburton)
Summary: Demonstration of py2exe with PyOpenGL

Initial Comment:
A demonstration/document describing how to create 
PyOpenGL exe's with py2exe would be useful for some 
users (this request is based on a post to the pygame 
mailing list).

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

>Comment By: Tarn Weisner Burton (twburton)
Date: 2001-10-05 07:24

Message:
Logged In: YES 
user_id=21784

This looks like it works out of the box, but its a bit 
greedy about the modules that it includes due to the fact 
that OpenGL/__init__.py imports pygame, wxPython, etc. to 
support the info script.  I've fixed this in CVS.

Users will run into problems if their script uses both 
OpenGL.GL and OpenGL.GLU since py2exe just tosses all pyds 
into same directory and a name collision will then occur 
since their names are both __init___.pyd

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355988&aid=455686&group_id=5988

[PyOpenGL-Users] Re: Froody Was: (Utility module functions...)

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

It's classic HHGTTG slang...

Frood:
	Cool, amazingly together person.  The kind of person who knows where their
towel is.

Froody:
	As or like a Frood. Cool and amazingly together.  Having knowledge of towel
locations.


At least one issue safely put to rest :) ,
Mike

-----Original Message-----
From: pyo...@li...
[mailto:pyo...@li...]On Behalf Of Tarn
Weisner Burton
Sent: October 3, 2001 10:58
To: PyOpenGL Mailing List
Subject: RE: [PyOpenGL-Users] Re: Utility module functions, forward
directions,call for opinions/volunteers
...
p.s. What does froody mean?
...

[PyOpenGL-Users] documentation

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

I'd like to reiterate some points about documentation and participation in
the PyOpenGL project.

First off HTML and PDF documentation is included with PyOpenGL in the
"OpenGL/doc" directory and HTML docs are available online at
http://pyopengl.sf.net/documentation/  The online docs actually represent
the "in development" docs so may have expanded sections especially the
reference section.  For users trying to understand the package layout of
PyOpenGL and the general conventions of functions the User's Guide and the
Pydoc documentation is recommended.  If you have pydoc on your machine than
you can get access to this locally or you can use the online stuff at the
above link.

For people who are interested in the internals of PyOpenGL I recommend
reading the "internals" section of the manual and a willingness to spend
some time looking at the code.  I am more than willing to answer questions
about these topics especially in light of the fact that the current
documentation is obviously incomplete, but I'm likely to get frustrated if I
feel that someone hasn't spent the time to look at the docs themselves.
This is mostly because my own time is limited and there are PyOpenGL
enhancements that I want to work on myself, but will be unable to do so if I
am overwhelmed with queries from those unwilling to invest time themselves.

thanks,
Tarn

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

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

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

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

[Richard J. <ric...@op...>]

On Wed, 3 Oct 2001 14:28, Mike C. Fletcher wrote:
> Apologies on the slow response

I also want to contribute to this discussion, but won't have the time to even 
read and understand all the messages until the weekend. 


    Richard

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

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

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

[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 :) .

[PyOpenGL-Users] [ pyopengl-Support Requests-455914 ] IRIX installation

[<no...@so...>]

Support Requests item #455914, was opened at 2001-08-27 14:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=205988&aid=455914&group_id=5988

Category: install
Group: v2.0
Status: Closed
Priority: 5
Submitted By: Dr. Lothar Esser (lessertx)
Assigned to: Tarn Weisner Burton (twburton)
Summary: IRIX installation

Initial Comment:
Hi,
  
my sys.platform is sys.platform is irix646 and I am
having trouble to run 
python setup.py build.
The biggest problem seems to be that I could not figrue
out to change compiler options. It always uses cc which
is fine except that many scripts
contain c++ comments on which the c compiler chokes. I
can add a switch 
-Xcpuscomm but I don't know how to tell that to the
setup script. I tried the usual setenv CCFLAGS '-n32
-Xcpuscomm' but it seems to be ignored.
So what can I do to configure it ? Sorry if I
overlooked the obvious ... but I ran out of ideas. 

Thanks, 
    Lothar

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

>Comment By: Dr. Lothar Esser (lessertx)
Date: 2001-09-23 14:28

Message:
Logged In: YES 
user_id=215109

I have now updated to the latest version of pyOpenGL (.44)
and the installation 
worked without a problem. However I cannot run any of the
examples in
OpenGLContext 
I always get the message:
NameError: global name 'glutKeyboardUpFunc' is not defined

There is a bit more of course. It seems to me that there is
something wrong with 
Glut3.7. During build and installation I did not notice any
error associated with glut. 
Do you have an idea as to what I can check to track down the
error ? 
Thanks, 
    Lothar. 

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

Comment By: Rene Liebscher (rliebscher)
Date: 2001-09-11 23:16

Message:
Logged In: YES 
user_id=28463

If you had used CFLAGS (not CCFLAGS) it may have been 
worked.
(distutils adds the content of CFLAGS to the command line
of the compiler.)

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

Comment By: Tarn Weisner Burton (twburton)
Date: 2001-09-02 06:54

Message:
Logged In: YES 
user_id=21784

New version of PyOpenGL has C++ comments removed.  Have you 
tried it?  Please respond so I can determine the status of 
this support request.

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

Comment By: Tarn Weisner Burton (twburton)
Date: 2001-08-27 15:28

Message:
Logged In: YES 
user_id=21784

You can try alias cc=cc -Xcpluscomm.  The C++ comments have 
been removed in CVS.  The next release is on the 1st.  I 
would really like to make sure this works so if the alias 
method doesn't then I'll give a dist without C++ comments.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=205988&aid=455914&group_id=5988

[PyOpenGL-Users] Re: RE: PyOpenGL 2.0.0.44 build output

[Randall H. <aa...@ya...>]

--- Tarn Weisner Burton <twb...@ma...> wrote:
> Okay...look in the file setup/build_py for the "run" method.  
> ----------------------
> self._check_compiler()
> customize_compiler(self.compiler)   <------
> ----------------------

That did it.  Most of the examples run without a hitch now, with only
a handful failing for various odd reasons (GL extension naming differences, 
etc.).

Thanks for your help,

Randall

__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com

[PyOpenGL-Users] RE: PyOpenGL 2.0.0.44 build output

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

Okay...look in the file setup/build_py for the "run" method.  The first of
it should be:

----------------------
self._check_compiler()
----------------------

change this to:

----------------------
self._check_compiler()
customize_compiler(self.compiler)
----------------------

Tarn

[PyOpenGL-Users] RE: PyOpenGL 2.0.0.44 build output

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

After looking at the problem some more I don't think my previous suggestion
is going to fix the problem.    Hold on.

Tarn

[PyOpenGL-Users] RE: PyOpenGL 2.0.0.44 build output

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

First off, you don't need SWIG to build PyOpenGL.  If there is a SWIG
installation in the search path then PyOpenGL setup is going to try to use
it to rebuild the sources.  The current interface files only work with
1.3a5, not 1.3a1.  My suggestion is to unpack the PyOpenGL tarball again (to
get the original sources) and execute setup in a shell without SWIG in the
search path.

Tarn

RE: [PyOpenGL-Users] 2.0.0.44 fails to run

[Randall H. <aa...@ya...>]

> | Is this the problem?
> |
> | # ls -l /usr/local/lib/python2.1/site-packages/OpenGL/GL/__init*
> | -rwxr-xr-x    1 root     sys       571512 Sep 26 15:01
> | /usr/local/lib/python2.1/site-packages/OpenGL/GL/__init___.so
> 
> There should be /usr/local/lib/python2.1/site-packages/OpenGL/GL/__init__.py
> there also.  Kill the build dir in setup dir, and execute a rebuild.  Send
> me a copy of the output.

Will do.

Thanks,

Randall

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com

RE: [PyOpenGL-Users] 2.0.0.44 fails to run

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

| Is this the problem?
|
| # ls -l /usr/local/lib/python2.1/site-packages/OpenGL/GL/__init*
| -rwxr-xr-x    1 root     sys       571512 Sep 26 15:01
| /usr/local/lib/python2.1/site-packages/OpenGL/GL/__init___.so

There should be /usr/local/lib/python2.1/site-packages/OpenGL/GL/__init__.py
there also.  Kill the build dir in setup dir, and execute a rebuild.  Send
me a copy of the output.

Tarn

RE: [PyOpenGL-Users] 2.0.0.44 fails to run

[Randall H. <aa...@ya...>]

> | There is no GL.so module that I can find, though I notice that there is a
> | site-packages/OpenGL/GL subdirectory with a large __init__.so 
> | file in it 
> 
> check to make sure there isn't a /usr/lib/python2.1/site-packages/OpenGL

There isn't.  I also have no PYTHONPATH set.

> Are you running cone.py from OpenGL/Demo/GLE, i.e.
> 
> $ cd /usr/local/lib/python2.1/site-packages/OpenGL/Demo/GLE
> $ ./cone.py

Yes, exactly that.

Is this the problem?

# ls -l /usr/local/lib/python2.1/site-packages/OpenGL/GL/__init*
-rwxr-xr-x    1 root     sys       571512 Sep 26 15:01
/usr/local/lib/python2.1/site-packages/OpenGL/GL/__init___.so


Thanks,

Randall

Randall

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com

RE: [PyOpenGL-Users] 2.0.0.44 fails to run

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

| I neglected to remove the old OpenGL package.  With that done, I 
| rebuilt and
| reinstalled, only to get the following error.  Any idea what is wrong?  
| 
| There is no GL.so module that I can find, though I notice that there is a
| site-packages/OpenGL/GL subdirectory with a large __init__.so 
| file in it (a
| shared object).  I guess Python doesn't see this as a reasonable 
| proxy for a
| "GL" module.  Should it?
| 
| Traceback (most recent call last):
|   File "cone.py", line 8, in ?
|     from OpenGL.GL import *
|   File 
| "/usr/local/lib/python2.1/site-packages/OpenGL/__init__.py", line 16, in
| ?
|     from GL import __numeric_present__, __numeric_support__
| ImportError: No module named GL
| 

check to make sure there isn't a /usr/lib/python2.1/site-packages/OpenGL

Are you running cone.py from OpenGL/Demo/GLE, i.e.

$ cd /usr/local/lib/python2.1/site-packages/OpenGL/Demo/GLE
$ ./cone.py


Tarn

RE: [PyOpenGL-Users] 2.0.0.44 fails to run

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

| It builds, but fails to run the demos.  Is OpenGL._numeric deprecated?

2.0.0.44 doesn't use OpenGL._numeric, but 1.5.x does.  You probably have an
old version about.  Previous versions must be removed before install
2.0.0.44 since it's source is incompatible with 1.5.x.  Just delete
site-packages/OpenGL then reinstall.  Also make sure there isn't another
OpenGL in the python path.

Tarn

Re: [PyOpenGL-Users] 2.0.0.44 fails to run

[Randall H. <aa...@ya...>]

> It builds, but fails to run the demos.  Is OpenGL._numeric deprecated?
> 
> FWIW I do have Numeric installed.  Also, I notice that the build did compile
> with -DNUMERIC, so PyOpenGL knows it's there.

I neglected to remove the old OpenGL package.  With that done, I rebuilt and
reinstalled, only to get the following error.  Any idea what is wrong?  

There is no GL.so module that I can find, though I notice that there is a
site-packages/OpenGL/GL subdirectory with a large __init__.so file in it (a
shared object).  I guess Python doesn't see this as a reasonable proxy for a
"GL" module.  Should it?

Traceback (most recent call last):
  File "cone.py", line 8, in ?
    from OpenGL.GL import *
  File "/usr/local/lib/python2.1/site-packages/OpenGL/__init__.py", line 16, in
?
    from GL import __numeric_present__, __numeric_support__
ImportError: No module named GL


__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com

[PyOpenGL-Users] 2.0.0.44 fails to run

[Randall H. <aa...@ya...>]

It builds, but fails to run the demos.  Is OpenGL._numeric deprecated?

FWIW I do have Numeric installed.  Also, I notice that the build did compile
with -DNUMERIC, so PyOpenGL knows it's there.

Randall

> cd OpenGL/Demo/GLE
> python cone.py
Traceback (most recent call last):
  File "cone.py", line 8, in ?
    from OpenGL.GL import *
  File "/usr/local/lib/python2.1/site-packages/OpenGL/__init__.py", line 16, in
?
    from GL import __numeric_present__, __numeric_support__
  File "/usr/local/lib/python2.1/site-packages/OpenGL/GL/__init__.py", line 15,
in ?
    if OpenGL._numeric:
AttributeError: 'OpenGL' module has no attribute '_numeric'

> python
Python 2.1 (#2, Jun  1 2001, 14:16:06) [C] on irix646-n32
Type "copyright", "credits" or "license" for more information.
>>> import Numeric
>>>

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com

RE: [PyOpenGL-Users] installation (?) problem on irix646

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

|  I replaced library_dirs=/usr/lib with
|
|             library_dirs=/usr/lib32
|
|  as on the newer systems the default compilation is with a -n32 flag. This
| may be slightly machine dependent but maybe one could add this as the
| first path to be searched ...

done.

thanks,
Tarn