pyopengl-devel — Discussion of PyOpenGL development.

[PyOpenGL-Devel] [ pyopengl-Patches-643038 ] Tk Rawopengl resize / matrix mode fix

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

Patches item #643038, was opened at 2002-11-24 13:10
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305988&aid=643038&group_id=5988

Category: Tk
Group: v2.0
Status: Open
Resolution: None
Priority: 5
Submitted By: Tom Whittock (tomwhittock)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tk Rawopengl resize / matrix mode fix

Initial Comment:
Apologies for this not being in a proper patch format.
I can't find the file in your CVS respository, so I
don't know if this is even relevant anymore.

If you attempt to resize a Rawopengl Widget, you can
get into a situation where it recieves a tkRedraw-using
message during the update_idletasks call inside
tkRedraw. This is only a problem inside the
gl{Push|Pop}Matrix pair, since you can cause a stack
overflow.

Also, I wouldn't rely on self.redraw  to keep the
matrix mode as projection, so I put another matrix mode
set in there.

Here's the "fixed" function. Perhaps it'd be a good
idea to know why update_idletasks is being called in
redraw.

distribution file: OpenGL/tk/__init__.py
class Rawopengl:
	def tkRedraw(self, *dummy):
		# This must be outside of a pushmatrix, since a
resize event
		# will call redraw recursively.
		self.update_idletasks()
		self.tk.call(self._w, 'makecurrent')
		_mode = glGetDoublev(GL_MATRIX_MODE)

		glMatrixMode(GL_PROJECTION)
		glPushMatrix()

		self.redraw()
		glFlush()

		glMatrixMode(GL_PROJECTION)
		glPopMatrix()

		glMatrixMode(_mode)
		self.tk.call(self._w, 'swapbuffers')


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305988&aid=643038&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-642239 ] glGetFloatv( GL_PROJECTION_MATRIX )

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

Bugs item #642239, was opened at 2002-11-22 11:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=642239&group_id=5988

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Calle Lejdfors (clejdfors)
Assigned to: Nobody/Anonymous (nobody)
Summary: glGetFloatv( GL_PROJECTION_MATRIX )

Initial Comment:
glGetFloatv( GL_PROJECTION_MATRIX ) returns an 
improperly casted array. It is 'u' but should be 'Float' .

This is on a WinXP using PyOpenGL-2.0.0.44 and 
Numeric-22.0




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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=642239&group_id=5988

Re: [PyOpenGL-Devel] New PyOpenGL-2.0.0.44.win32-py2.2.exe based on Numeric 22.0?

[<il...@ya...>]

Anyone know how to make the installer from that code? 


I was planning on using inno setup for the
pre-release.  Perhaps you could use that? 
http://www.jrsoftware.org/isinfo.php

I'm going to be making a new pre-release soon from the
current cvs.  It will be against Numeric 22.  So maybe
you could wait for that instead?

However I can't figure out how to build togl in
windows?  Can you shed some light on this?

I got some extentions compiled with mingw tonight, so
I don't think I'll need msvc to make a release.



 --- "David C. Morrill" <dmo...@au...>
wrote: > Would it be possible to update the current
Win32
> PyOpenGL-2.0.0.44.win32-py2.2.exe installer to a
> version of PyOpenGL built
> against Numeric 22.0 (i.e. the latest version of
> Numeric)?
> 
> I just spent a day tracking down a problem caused by
> upgrading my Numeric to
> 22.0 and then having my PyOpenGL/Togl based
> application suddenly start
> trapping. After a lot of work rebuilding PyOpenGL
> against Numeric 22.0, my
> application is working again. It would be nice if
> the Win32 installer files
> were built against the latest Numeric.
> 
> Thanks,
> Dave Morrill
> 
>  

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

[PyOpenGL-Devel] New PyOpenGL-2.0.0.44.win32-py2.2.exe based on Numeric 22.0?

[David C. M. <dmo...@au...>]

Would it be possible to update the current Win32
PyOpenGL-2.0.0.44.win32-py2.2.exe installer to a version of PyOpenGL built
against Numeric 22.0 (i.e. the latest version of Numeric)?

I just spent a day tracking down a problem caused by upgrading my Numeric to
22.0 and then having my PyOpenGL/Togl based application suddenly start
trapping. After a lot of work rebuilding PyOpenGL against Numeric 22.0, my
application is working again. It would be nice if the Win32 installer files
were built against the latest Numeric.

Thanks,
Dave Morrill

Re: [PyOpenGL-Devel] new semi-release soon.

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

Should be, but it'll be dog slow without serious optimisations (which is 
part of why I need to re-tool the traversals).  Even in C the author of 
the algo suggests it requires lots of optimisations.  (It does 1+Nx2 
full rendering passes (opaque+transparent) for N lights in the scene + 
2xM shadow-volume-rendering passes).  Will require ways to auto-cull 
shapes according to light cones/spheres, and ways to test for 
shadow-volume intersections with the frustum (among othe requirements). 
 That all requires mechanisms for manipulating/calculating relative 
scenegraph path matrices and the like.  Should have those tools anyway, 
but I haven't needed them until now in OpenGLContext.

Oh well, such is life,
Mike

Rene Dudfield wrote:

> --- "Mike C. Fletcher" <mcf...@ro...> wrote: 
>  
>
>>Sounds fine to me.  
>>
>>BTW: I've been working on OpenGLContext this weekend
>>(one of my 
>>long-standing todos was to create a robust
>>stencil-buffer-based shadow 
>>renderer).  It's going darn slowly (in the middle I
>>realised I needed to 
>>re-tool the entire scenegraph engine).  I've got the
>>shadow-volume 
>>calculation done, it's just a matter of integrating
>>it into the 
>>traversal mechanisms.
>>
>>Have fun,
>>Mike
>>    
>>
>
>
>ooh!  that sounds nice :)
>
>
>
>__________________________________________________
>Do You Yahoo!?
>Everything you'll ever need on one web page
>from News and Sport to Email and Music Charts
>http://uk.my.yahoo.com
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: To learn the basics of securing 
>your web site with SSL, click here to get a FREE TRIAL of a Thawte 
>Server Certificate: http://www.gothawte.com/rd524.html
>_______________________________________________
>PyOpenGL Homepage
>http://pyopengl.sourceforge.net
>_______________________________________________
>PyOpenGL-Devel mailing list
>PyO...@li...
>https://lists.sourceforge.net/lists/listinfo/pyopengl-devel
>
>  
>

-- 
_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

Re: [PyOpenGL-Devel] new semi-release soon.

[<il...@ya...>]

 --- "Mike C. Fletcher" <mcf...@ro...> wrote: 
> Sounds fine to me.  
> 
> BTW: I've been working on OpenGLContext this weekend
> (one of my 
> long-standing todos was to create a robust
> stencil-buffer-based shadow 
> renderer).  It's going darn slowly (in the middle I
> realised I needed to 
> re-tool the entire scenegraph engine).  I've got the
> shadow-volume 
> calculation done, it's just a matter of integrating
> it into the 
> traversal mechanisms.
> 
> Have fun,
> Mike


ooh!  that sounds nice :)



__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Re: [PyOpenGL-Devel] new semi-release soon.

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

Sounds fine to me.  

BTW: I've been working on OpenGLContext this weekend (one of my 
long-standing todos was to create a robust stencil-buffer-based shadow 
renderer).  It's going darn slowly (in the middle I realised I needed to 
re-tool the entire scenegraph engine).  I've got the shadow-volume 
calculation done, it's just a matter of integrating it into the 
traversal mechanisms.

Have fun,
Mike

Rene Dudfield wrote:

>Hi,
>
>thought I'd mention that I plan on making a small
>release soon.  It will be labeled as experimental,
>beta etc, as some important(for some people) things
>don't work.
>
>In cvs some bugs are fixed for some fairly useful
>functions.  However togl doesn't compile easily on
>windows, and glut is broken.  Those are the major two
>problems with it.
>
>Keeping up with the latest swig is a waste of time I
>think.  As it changes so often, and almost every
>distribution has a different version.  So requiring
>swig 1.3.13 for now seems like an ok thing to do.
>
>There are a couple of reasons I think doing this is a
>good idea.  
> 1) Allow pygame users to use a new wrapper spritegl
>wrapper, which requires some fixes from cvs.
> 2) Allow people who don't use glut/togl to take
>advantage of the bug fixes for the core opengl stuff.
> 3) maybe spur along some helpers/developers.
>
>I've found a windows developer who will make a zip of
>the pyopengl installation.  We could make an installer
>I guess, but since this is a dodgy release, I'd want
>people to make sure they know what they are doing.
>
>Repeating that this will be marked
>experimental-dodgy-alpha.
>
>
>Any thoughts?
>
>
>__________________________________________________
>Do You Yahoo!?
>Everything you'll ever need on one web page
>from News and Sport to Email and Music Charts
>http://uk.my.yahoo.com
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: To learn the basics of securing 
>your web site with SSL, click here to get a FREE TRIAL of a Thawte 
>Server Certificate: http://www.gothawte.com/rd524.html
>_______________________________________________
>PyOpenGL Homepage
>http://pyopengl.sourceforge.net
>_______________________________________________
>PyOpenGL-Devel mailing list
>PyO...@li...
>https://lists.sourceforge.net/lists/listinfo/pyopengl-devel
>
>  
>

-- 
_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

[PyOpenGL-Devel] new semi-release soon.

[<il...@ya...>]

Hi,

thought I'd mention that I plan on making a small
release soon.  It will be labeled as experimental,
beta etc, as some important(for some people) things
don't work.

In cvs some bugs are fixed for some fairly useful
functions.  However togl doesn't compile easily on
windows, and glut is broken.  Those are the major two
problems with it.

Keeping up with the latest swig is a waste of time I
think.  As it changes so often, and almost every
distribution has a different version.  So requiring
swig 1.3.13 for now seems like an ok thing to do.

There are a couple of reasons I think doing this is a
good idea.  
 1) Allow pygame users to use a new wrapper spritegl
wrapper, which requires some fixes from cvs.
 2) Allow people who don't use glut/togl to take
advantage of the bug fixes for the core opengl stuff.
 3) maybe spur along some helpers/developers.

I've found a windows developer who will make a zip of
the pyopengl installation.  We could make an installer
I guess, but since this is a dodgy release, I'd want
people to make sure they know what they are doing.

Repeating that this will be marked
experimental-dodgy-alpha.


Any thoughts?


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

[PyOpenGL-Devel] [ pyopengl-Bugs-639285 ] glutGetWindow doc missing

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

Bugs item #639285, was opened at 2002-11-16 04:29
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=639285&group_id=5988

Category: doc
Group: v2.0
Status: Open
Resolution: None
Priority: 3
Submitted By: Mike C. Fletcher (mcfletch)
Assigned to: Nobody/Anonymous (nobody)
Summary: glutGetWindow doc missing

Initial Comment:
There's no documentation for glutGetWindow.  (Not even
C documentation).  Probably just skipped during the
conversion to XML.  Should figure out how everything
was converted and convert this too.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=639285&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-621504 ] Error/Typo in glTexImage2D documentation

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

Bugs item #621504, was opened at 2002-10-10 14:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=621504&group_id=5988

Category: doc
Group: None
>Status: Pending
>Resolution: Postponed
Priority: 5
Submitted By: Thomas Boggs (tboggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error/Typo in glTexImage2D documentation

Initial Comment:
In the documentation for glTexImage2D located at
http://pyopengl.sourceforge.net/documentation/manual/glTexImage2D.3G.html,
the documenation specifies that the width and height of
the image must be
    2 n + 2 (border),
where n is an integer. I attempted to call the function
with a bitmap matching that criterion and it raised an
exception with
    "[Errno 1281] invalid value".

I found another OpenGL document somewhere on the web
which stated that the image dimensions must each be
    2^n + 2 (border),
where n is an integer.  That eliminated the problem.

I'm not sure if it's a typo or a formatting problem in
the html.

-thomas


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

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2002-11-16 04:24

Message:
Logged In: YES 
user_id=34901

Hmm, not sure how to go about fixing this.  Basically, the
Math-ML is set up to show as (the equivalent of)
2<super>n</super>, but your browser isn't rendering it as
such.  I can't actually reproduce the problem on my machine
because both IE and Mozilla render it as 2 with n as a
superscript.  Given that is auto-generated from the standard
OpenGL docs, it's not really something I feel like going
through to fix manually.

Suggestions welcome.  (Would it be possible to include a
MathML stylesheet that takes over if MathML support isn't
available?)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=621504&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-637090 ] Typo in glGenLists documentation

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

Bugs item #637090, was opened at 2002-11-12 07:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=637090&group_id=5988

Category: doc
Group: v2.0
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Bram Senders (bags43)
>Assigned to: Mike C. Fletcher (mcfletch)
Summary: Typo in glGenLists documentation

Initial Comment:
Hi there,

in the glGenLists documentation there is an
inconsistency between the C spec and the Python spec.
The C spec says glGenLists returns a GLuint, while the
Python spec says it returns None, while actually this
also returns some kind of integer.
The document I am referring to is at
http://pyopengl.sourceforge.net/documentation/manual/glGenLists.3G.html

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

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2002-11-16 04:12

Message:
Logged In: YES 
user_id=34901

I've fixed this in CVS, should appear the next time we
rebuild the documentation (i.e. when I get around to setting
up the XML-processing tools on my system).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=637090&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-636052 ] rotations around center

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

Bugs item #636052, was opened at 2002-11-09 18:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=636052&group_id=5988

Category: Context
Group: OpenGLContext v1.0
>Status: Pending
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: rotations around center

Initial Comment:
transform.py
Transform class
transform method

rotation needs to come above center and transform for rotations around center to work as intended.

	def transform( self ):
		''' Perform the actual alteration of the current matrix '''
		if self.rotation:
			apply(glRotatef, self.rotation )

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

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2002-11-16 03:53

Message:
Logged In: YES 
user_id=34901

I've examined the code, and it really does appear to do what
I intended (which is to mimic the VRML97 model).  Rotation
is done about the centre (as is scaling).  To do that AFAIK,
you need to have the centre-translate active before you do
the rotation and scaling.  

I'm pretty sure it's right as-is (I've done a _lot_ of work
on VRML Transform coding over the years). An explanation of
_why_ you think it should work some other way would be helpful.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=636052&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-637090 ] Typo in glGenLists documentation

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

Bugs item #637090, was opened at 2002-11-12 13:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=637090&group_id=5988

Category: doc
Group: v2.0
Status: Open
Resolution: None
Priority: 5
Submitted By: Bram Senders (bags43)
Assigned to: Nobody/Anonymous (nobody)
Summary: Typo in glGenLists documentation

Initial Comment:
Hi there,

in the glGenLists documentation there is an
inconsistency between the C spec and the Python spec.
The C spec says glGenLists returns a GLuint, while the
Python spec says it returns None, while actually this
also returns some kind of integer.
The document I am referring to is at
http://pyopengl.sourceforge.net/documentation/manual/glGenLists.3G.html

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=637090&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-636052 ] rotations around center

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

Bugs item #636052, was opened at 2002-11-09 15:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=636052&group_id=5988

Category: Context
Group: OpenGLContext v1.0
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: rotations around center

Initial Comment:
transform.py
Transform class
transform method

rotation needs to come above center and transform for rotations around center to work as intended.

	def transform( self ):
		''' Perform the actual alteration of the current matrix '''
		if self.rotation:
			apply(glRotatef, self.rotation )

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=636052&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-629236 ] source install failed on RH8.0

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

Bugs item #629236, was opened at 2002-10-26 16:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=629236&group_id=5988

Category: install
Group: v2.0
Status: Open
Resolution: None
>Priority: 7
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: source install failed on RH8.0

Initial Comment:
Tried to install PyOpenGL-2.0.0.44-1.src.rpm on Redhat
8.0 with:

rpm --install /gslice/rpms/PyOpenGL-2.0.0.44-1.src.rpm

I get the following error:

error: cannot create %sourcedir /usr/src/redhat/SOURCES

There's no directory /usr/src/redhat on my Redhat 8.0
machine...



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

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2002-10-26 19:44

Message:
Logged In: YES 
user_id=34901

I'm a little out of my depth here (never used RPM for
packaging).  I'd guess this would be easily fixed merely by
re-building the RPM under redhat 8.0, but as I say, I'm not
sure.  I've bumped the priority up a notch as RH 8.0 is
likely to be a fairly significant target for users.

(user (if you happen to read this), you might find it
easiest to unpack the source tarball and try running
"setup.py install" I'd guess the linux .config file will
still work for RH 8.0, so it should be able to install from
that).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=629236&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-629239 ] source rpm tries expects user twburton

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

Bugs item #629239, was opened at 2002-10-26 13:53
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=629239&group_id=5988

Category: install
Group: v2.0
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: source rpm tries expects user twburton

Initial Comment:
PyOpenGL-2.0.0.44-1.src.rpm tries to install some files
with the owner "twburton":

> rpm --install /gslice/rpms/PyOpenGL-2.0.0.44-1.src.rpm
warning: user twburton does not exist - using root
warning: group twburton does not exist - using root
warning: user twburton does not exist - using root
warning: group twburton does not exist - using root


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=629239&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-629236 ] source install failed on RH8.0

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

Bugs item #629236, was opened at 2002-10-26 13:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=629236&group_id=5988

Category: install
Group: v2.0
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: source install failed on RH8.0

Initial Comment:
Tried to install PyOpenGL-2.0.0.44-1.src.rpm on Redhat
8.0 with:

rpm --install /gslice/rpms/PyOpenGL-2.0.0.44-1.src.rpm

I get the following error:

error: cannot create %sourcedir /usr/src/redhat/SOURCES

There's no directory /usr/src/redhat on my Redhat 8.0
machine...



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=629236&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-624324 ] gl*Pointer not usable with Numeric-22.0

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

Bugs item #624324, was opened at 2002-10-16 15:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=624324&group_id=5988

Category: GL
Group: v2.0
Status: Open
Resolution: None
Priority: 5
Submitted By: Shane Holloway (shane_holloway)
Assigned to: Nobody/Anonymous (nobody)
Summary: gl*Pointer not usable with Numeric-22.0

Initial Comment:
After a very long debugging session, I found that 
Numeric-22.0 appears to break all code that uses 
gl*Pointer, resulting in either no geometry, or 
an "Application Error".  

Simply reverting back to Numeric-21.3 restores code to 
working order.

Behavior was verified with various demos provided in 
both PyOpenGL and PyOpenGLContext, including:
    OpenGL\Demo\da\dots.py
    OpenGL\Demo\tom\arraytest.py
    OpenGL\Demo\tom\poly.py
    OpenGLContext\tests\gldrawarrays.py

#~ Start code example ~~~~~~~~~
Verticies = Numeric.transpose([Numeric.arange
(0.,1.,1./1000., Numeric.Float)]*3)

glPushClientAttrib(GL_CLIENT_VERTEX_ARRAY_BIT)
glVertexPointerd(Verticies)
glEnableClientState(GL_VERTEX_ARRAY)
glDrawArrays(GL_POINTS, 0, len(Verticies))
glPopClientAttrib()
#~ End code example ~~~~~~~~~

System Configuration:
    Windows 2000 & XP
    Numeric 22.0
    Python 2.2.2 & 2.2.1
    PyOpenGL 2.0


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

>Comment By: Shane Holloway (shane_holloway)
Date: 2002-10-16 17:47

Message:
Logged In: YES 
user_id=283742

Works with current version (2.0.1.47.a1) from CVS and 
Numeric-22.0.

Perhaps the WinInstallers should be labeled with the version 
number of Numeric it was built with as well?



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

Comment By: Shane Holloway (shane_holloway)
Date: 2002-10-16 17:38

Message:
Logged In: YES 
user_id=283742

Config Note:
PyOpenGL 2.0.0.44 from the SourceForge Files area



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=624324&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-624324 ] gl*Pointer not usable with Numeric-22.0

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

Bugs item #624324, was opened at 2002-10-16 15:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=624324&group_id=5988

Category: GL
Group: v2.0
Status: Open
Resolution: None
Priority: 5
Submitted By: Shane Holloway (shane_holloway)
Assigned to: Nobody/Anonymous (nobody)
Summary: gl*Pointer not usable with Numeric-22.0

Initial Comment:
After a very long debugging session, I found that 
Numeric-22.0 appears to break all code that uses 
gl*Pointer, resulting in either no geometry, or 
an "Application Error".  

Simply reverting back to Numeric-21.3 restores code to 
working order.

Behavior was verified with various demos provided in 
both PyOpenGL and PyOpenGLContext, including:
    OpenGL\Demo\da\dots.py
    OpenGL\Demo\tom\arraytest.py
    OpenGL\Demo\tom\poly.py
    OpenGLContext\tests\gldrawarrays.py

#~ Start code example ~~~~~~~~~
Verticies = Numeric.transpose([Numeric.arange
(0.,1.,1./1000., Numeric.Float)]*3)

glPushClientAttrib(GL_CLIENT_VERTEX_ARRAY_BIT)
glVertexPointerd(Verticies)
glEnableClientState(GL_VERTEX_ARRAY)
glDrawArrays(GL_POINTS, 0, len(Verticies))
glPopClientAttrib()
#~ End code example ~~~~~~~~~

System Configuration:
    Windows 2000 & XP
    Numeric 22.0
    Python 2.2.2 & 2.2.1
    PyOpenGL 2.0


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

>Comment By: Shane Holloway (shane_holloway)
Date: 2002-10-16 17:38

Message:
Logged In: YES 
user_id=283742

Config Note:
PyOpenGL 2.0.0.44 from the SourceForge Files area



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=624324&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-624324 ] gl*Pointer not usable with Numeric-22.0

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

Bugs item #624324, was opened at 2002-10-16 15:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=624324&group_id=5988

Category: GL
Group: v2.0
Status: Open
Resolution: None
Priority: 5
Submitted By: Shane Holloway (shane_holloway)
Assigned to: Nobody/Anonymous (nobody)
Summary: gl*Pointer not usable with Numeric-22.0

Initial Comment:
After a very long debugging session, I found that 
Numeric-22.0 appears to break all code that uses 
gl*Pointer, resulting in either no geometry, or 
an "Application Error".  

Simply reverting back to Numeric-21.3 restores code to 
working order.

Behavior was verified with various demos provided in 
both PyOpenGL and PyOpenGLContext, including:
    OpenGL\Demo\da\dots.py
    OpenGL\Demo\tom\arraytest.py
    OpenGL\Demo\tom\poly.py
    OpenGLContext\tests\gldrawarrays.py

#~ Start code example ~~~~~~~~~
Verticies = Numeric.transpose([Numeric.arange
(0.,1.,1./1000., Numeric.Float)]*3)

glPushClientAttrib(GL_CLIENT_VERTEX_ARRAY_BIT)
glVertexPointerd(Verticies)
glEnableClientState(GL_VERTEX_ARRAY)
glDrawArrays(GL_POINTS, 0, len(Verticies))
glPopClientAttrib()
#~ End code example ~~~~~~~~~

System Configuration:
    Windows 2000 & XP
    Numeric 22.0
    Python 2.2.2 & 2.2.1
    PyOpenGL 2.0


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=624324&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-621504 ] Error/Typo in glTexImage2D documentation

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

Bugs item #621504, was opened at 2002-10-10 14:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=621504&group_id=5988

Category: doc
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Boggs (tboggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error/Typo in glTexImage2D documentation

Initial Comment:
In the documentation for glTexImage2D located at
http://pyopengl.sourceforge.net/documentation/manual/glTexImage2D.3G.html,
the documenation specifies that the width and height of
the image must be
    2 n + 2 (border),
where n is an integer. I attempted to call the function
with a bitmap matching that criterion and it raised an
exception with
    "[Errno 1281] invalid value".

I found another OpenGL document somewhere on the web
which stated that the image dimensions must each be
    2^n + 2 (border),
where n is an integer.  That eliminated the problem.

I'm not sure if it's a typo or a formatting problem in
the html.

-thomas


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=621504&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-617949 ] demo/redbook/fog.py nonworking

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

Bugs item #617949, was opened at 2002-10-03 03:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=617949&group_id=5988

Category: Demo
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: John Lehmann (grandiose)
>Assigned to: Mike C. Fletcher (mcfletch)
Summary: demo/redbook/fog.py nonworking

Initial Comment:

The supplied demo/redbook/fog.py script doesn't display
the differences between fog equations as desired due to
an indentation error.

FWIW, the attached fog.py fixes this (and adds double
buffering)... 

John 'sorry for not supplying a diff' Lehmann





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

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2002-10-03 11:53

Message:
Logged In: YES 
user_id=34901

Fixed in CVS, should show up in the next release.  Also
fixed the indentation in the module while I was there. 
Thanks for the report.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=617949&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-617949 ] demo/redbook/fog.py nonworking

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

Bugs item #617949, was opened at 2002-10-03 07:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=617949&group_id=5988

Category: Demo
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Lehmann (grandiose)
Assigned to: Nobody/Anonymous (nobody)
Summary: demo/redbook/fog.py nonworking

Initial Comment:

The supplied demo/redbook/fog.py script doesn't display
the differences between fog equations as desired due to
an indentation error.

FWIW, the attached fog.py fixes this (and adds double
buffering)... 

John 'sorry for not supplying a diff' Lehmann





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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=617949&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-532670 ] bug in _glTexCoordPointer

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

Bugs item #532670, was opened at 2002-03-20 14:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=532670&group_id=5988

Category: GL
Group: v2.0
>Status: Closed
>Resolution: Fixed
Priority: 9
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Mike C. Fletcher (mcfletch)
Summary: bug in _glTexCoordPointer

Initial Comment:
_glTexCoordPointer calls

decrementPointerLock(GL_TEXTURE_COORD_ARRAY);

instead of

decrementPointerLock(GL_TEXTURE_COORD_ARRAY_POINTER);

causing (inscrutable) runtime errors.  Tried to fix
this in the .i file but some of the typemaps are
incompatible with swig 1.3.11u, the version I have
installed.

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

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2002-09-26 11:48

Message:
Logged In: YES 
user_id=34901

Andy Sy (apparently the original submitter) gave a test app
on the PyGame list, so I went ahead and applied the change
to the CVS repository version.  There was one other case
where a  decrementPointerLock call is made on something not
explicitly called a "pointer", but that seems to be
legitimate (it's the Sun triangle.i extension).

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

Comment By: Rene Dudfield (illume)
Date: 2002-07-30 11:08

Message:
Logged In: YES 
user_id=2042

Tried changing it to GL_TEXTURE_COORD_ARRAY_POINTER in a
test app and it does not work.  The app works with some code
from the 1.5x pyopengl distrib.  I'm looking at a fix some
more tommorow, after some sleep :)

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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2002-05-27 06:01

Message:
Logged In: YES 
user_id=34901

I'm told this fix is working for some other users already.
I'd prefer a test case to see if the error is fixed after
applying the fix, but the problem appears to be a fairly
straightforward one? so might just go ahead and do the fix.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=532670&group_id=5988

[PyOpenGL-Devel] Fwd: Re: [Togl-chat] Adding support for Tk 8.4?

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

Hi all,

I got this mail from Jonas (thanks Jonas) on the Togl-chat list, 
suggesting that if we use the 1.6 version of Togl then Tk 8.4 support is 
automatic.  Another post tells me that to get 8.4 support in Python 
2.2.1 will require a rebuild of Python, so...

I've just confirmed that dropping the CVS version of Togl into the 
PyOpenGL2 source tree as src/Togl-1.6 (and un-commenting line 23 in 
togl_setup.py, which I assume was from Rene doing the same thing) will 
allow us to build with the 1.6 version of Togl (though it seems to 
declare itself to be the 1.5 version) compiled against Python's current 
Tk version (in my case 8.3).

I still haven't tried re-compiling Python with Tk 8.4, so can't be sure 
what happens there, but from Jonas' post it sounds like if you can get 
Togl 1.6 compiled you should have it available with every current 
version of Tk, which should in turn make it available for all versions 
of PyOpenGL if I understand correctly.

So, basically:
	get latest CVS version of Togl
	copy files to PyOpenGL/src/Togl-1.6
	uncomment line 23 in togl_setup.py
	run setup.py build --force
	run setup.py install

If Tk is properly linked to Python, that _should_ just work.  Torsten, 
could you confirm that it does with your Tk8.4-linked version of Python? 
  If so, I'll write it up in the docs.  Otherwise I'll have to byte the 
bullet and figure out how to build Python with Tk8.4.

Hope 8.4 is really a killer advance :o) ,
Mike

-------- Original Message --------
Subject: Re: [Togl-chat] Adding support for Tk 8.4?
Date: Tue, 24 Sep 2002 11:52:52 +0200
From: Jonas Beskow <be...@sp...>
Organization: KTH, Centre for Speech Technology
To: Mike C. Fletcher <mcf...@ro...>
CC: tog...@li...
References: <3D8...@ro...>

The current CVS-version og Togl should work just fine with Tcl/Tk 8.4.0
since it is stubs-enabled (it shouldn't even have to be re-compiled). I
have tried it with previous 8.4aX-releases on linux and windows.

-Jonas


-- 
Jonas Beskow				Tel: +46 8 790 8965
Centre for Speech Technology		Fax: +46 8 790 7854
KTH				       be...@sp...
SE-10044 Stockholm, Sweden	  www.speech.kth.se/~beskow