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