pyopengl-users

[PyOpenGL-Users] OpenGLContext 1.0a3 available

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

This is a bug-fix release of 1.0a2.  Bugs fixed are the setup bug (data 
files copied to wrong locations) and the filename case mismatches on 
case-sensitive systems.

Also included is the profile.py test, which demonstrates using a PyGame 
context to allow for standard Python profiling in PyOpenGL projects.

http://sourceforge.net/project/showfiles.php?group_id=5988&release_id=66619

Enjoy all,
Mike
_______________________________________
   Mike C. Fletcher
   http://members.rogers.com/mcfletch/

[PyOpenGL-Users] Modelview and projection matrices

[Jan E. <ch...@in...>]

Hi,

I've been trying to implement some form of view frustum culling. I found
some interesting code on:

	http://www.markmorley.com/opengl/frustumculling.html

The code is in C, so I need to translate it to Python. Central in that
approach is the use the current modelview and projection matrices. So I
get the using:

        projection = glGetFloatv ( GL_PROJECTION_MATRIX )
        modelview  = glGetFloatv ( GL_MODELVIEW_MATRIX )

However, the Python versions return a [4][4] matrix, while the C versions
return a [16] array. The code on the page above uses a [16] array for all
indexing, so I'd like to translate the matrices I get from glGetFloatv to
arrays.

The problem is now that I'm not sure how the returned matrix should be
"flattened". Should I go by row or column, i.e. the first element in the
array should be [0][0], but should the second be [0][1] or [1][0] and so
on?

I have tried both ways, but my code still won't work, so I'd like to rule
out at least this possibility for error. Ny ideas?

	Chakie

-- 
 The Emperor had all the qualifications for a corpse except, as it were, the
         most vital one.
                                       -- Terry Pratchett, Interesting Times

Re: [PyOpenGL-Users] Modelview and projection matrices

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

On Sat, 5 Jan 2002 23:46, Jan Ekholm wrote:
> Hi,
>
> I've been trying to implement some form of view frustum culling. I found
> some interesting code on:
>
> 	http://www.markmorley.com/opengl/frustumculling.html
>
> The code is in C, so I need to translate it to Python. Central in that
> approach is the use the current modelview and projection matrices. So I
> get the using:
>
>         projection = glGetFloatv ( GL_PROJECTION_MATRIX )
>         modelview  = glGetFloatv ( GL_MODELVIEW_MATRIX )
>
> However, the Python versions return a [4][4] matrix, while the C versions
> return a [16] array. The code on the page above uses a [16] array for all
> indexing, so I'd like to translate the matrices I get from glGetFloatv to
> arrays.

Code (interchangeable python and C modules for frustum culling and octree 
storage) attached :)

You can also get this code by downloading the tarball from 
http://goanna.adroit.net/~richard/ufo/ where there is some octree code that 
uses the frustum culling too. Note that since I discovered that the code is 
_significantly_ faster when it just draws _everything_ rather than tries to 
cull, the current ufo.py doesn't actually call the frustum or octree code. In 
a nutshell, define objects like the triangle object, stuff them into the 
octree with octree.insertPolygon or octree.insertObject for each of the 
object's bounding vertexes. The call octree.render with the frustum and it 
calls each of the appropriate sub-object's render() method.

Note that I do _all_ my view projection manipulation in the projection 
matrix, so I don't include the modelview matrix. It's simple enough to 
un-comment the appropriate code though.


    Richard

Re: [PyOpenGL-Users] Modelview and projection matrices

[Jan E. <ch...@in...>]

On Sun, 6 Jan 2002, Richard Jones wrote:

>Code (interchangeable python and C modules for frustum culling and octree 
>storage) attached :)

Wow. This was a little bit more than I was asking for, but I humbly bow
and will try to use your code. :) Thanks a lot for the code.

Hmm, I tested your code now, and I don't get it. Nothing is inside the
frustum, all points I give it are outside. Strange. maybe gluLookAt() is
pure evil wrt these kinds of operations. I'll try to dig some more.

>You can also get this code by downloading the tarball from 
>http://goanna.adroit.net/~richard/ufo/ where there is some octree code that 
>uses the frustum culling too. Note that since I discovered that the code is 
>_significantly_ faster when it just draws _everything_ rather than tries to 
>cull, the current ufo.py doesn't actually call the frustum or octree code. In 
>a nutshell, define objects like the triangle object, stuff them into the 
>octree with octree.insertPolygon or octree.insertObject for each of the 
>object's bounding vertexes. The call octree.render with the frustum and it 
>calls each of the appropriate sub-object's render() method.

Ok. I was thinking about some kind of simplified octree myself, or mainly
just do divide the terrain into, say, 16 pieces (4x4) and just cull those
pieces. Should not be too much Python code each frame. 

>Note that I do _all_ my view projection manipulation in the projection 
>matrix, so I don't include the modelview matrix. It's simple enough to 
>un-comment the appropriate code though.

I assume you mean the line:
	
	self.c = c = p * m

-- 
         Real stupidity beats artificial intelligence every time.
                                              -- Terry Pratchett, Hogfather

Re: [PyOpenGL-Users] Modelview and projection matrices

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

On Sun, 6 Jan 2002 23:59, Jan Ekholm wrote:
> On Sun, 6 Jan 2002, Richard Jones wrote:
> >Code (interchangeable python and C modules for frustum culling and octree
> >storage) attached :)
>
> Wow. This was a little bit more than I was asking for, but I humbly bow
> and will try to use your code. :) Thanks a lot for the code.
>
> Hmm, I tested your code now, and I don't get it. Nothing is inside the
> frustum, all points I give it are outside. Strange. maybe gluLookAt() is
> pure evil wrt these kinds of operations. I'll try to dig some more.

That's odd... I use code like:

        # setup the projection matrix
        glMatrixMode(GL_PROJECTION)
        glLoadIdentity()
        # setup the projection
        # calculate left/right and top/bottom clipping planes based the
        # smallest square viewport
        width, height = self.viewport
        a = 9.0/min(width, height)
        lr, tb = a*width, a*height
        glFrustum(-lr, lr, -tb, tb, 50.0, 20000.0)
        # and place the camera
        x, y, z = self.ufo.x, self.ufo.y, self.ufo.z
        # TODO: move the camera up over the UFO as it climbs
        # TODO: figure if there is landscape between the camera and UFO
        gluLookAt(x, y+200, z-600, x, y, z, 0, 1, 0)
        self.frustum.calculate()

in my regular drawing loop. Note, this is obviously directly stolen from the 
ufo code :)


> >You can also get this code by downloading the tarball from
> >http://goanna.adroit.net/~richard/ufo/ where there is some octree code
> > that uses the frustum culling too. Note that since I discovered that the
> > code is _significantly_ faster when it just draws _everything_ rather
> > than tries to cull, the current ufo.py doesn't actually call the frustum
> > or octree code. In a nutshell, define objects like the triangle object,
> > stuff them into the octree with octree.insertPolygon or
> > octree.insertObject for each of the object's bounding vertexes. The call
> > octree.render with the frustum and it calls each of the appropriate
> > sub-object's render() method.
>
> Ok. I was thinking about some kind of simplified octree myself, or mainly
> just do divide the terrain into, say, 16 pieces (4x4) and just cull those
> pieces. Should not be too much Python code each frame.

As I mentioned in my post to pygame, the timings I got were something like 
this for a landscape stored in the octree:

             No C: 7fps
         C octree: 7fps
         C frusum: 8fps
       C triangle: 10fps
 C octree&frustum: 8fps
    C frustum&tri: 11fps
     C octree&tri: 26fps
              all: 41fps

... so there does seem to be some benefit in having the octree in C, but only 
when coupled with the lower-level objects also being in C.


> >Note that I do _all_ my view projection manipulation in the projection
> >matrix, so I don't include the modelview matrix. It's simple enough to
> >un-comment the appropriate code though.
>
> I assume you mean the line:
>
> 	self.c = c = p * m

Yes, and I just realised that my C module doesn't actually do the mult. Sorry 
about that...

    // matrix mult those two to get the clipping matrix
//    c = p *m

... uncommenting that line wouldn't do much :)


     Richard

Re: [PyOpenGL-Users] Modelview and projection matrices

[Maciej K. <ma...@dg...>]

On Sat, Jan 05, 2002 at 07:46:28AM -0500, Jan Ekholm wrote:
> However, the Python versions return a [4][4] matrix, while the C versions
> return a [16] array. The code on the page above uses a [16] array for all
> indexing, so I'd like to translate the matrices I get from glGetFloatv to
> arrays.
> 
> The problem is now that I'm not sure how the returned matrix should be
> "flattened". Should I go by row or column, i.e. the first element in the
> array should be [0][0], but should the second be [0][1] or [1][0] and so
> on?

The OpenGL matrices are stored in column-major order.  That is, the elements
from the flat [16] array correspond to the 4x4 matrix like this:

[  0  4  8 12 ]
[  1  5  9 13 ]
[  2  6 10 14 ]
[  3  7 11 15 ]

(Reference: "man" page for glMultMatrix)

-- 
Maciej Kalisiak|mac@] 
dgp.toronto.edu|www.] "He who laughs last thinks slowest!"
dgp.toronto.edu/~mac]