pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] Loading PyOpenGL from embedded Python interpreter

[Patrick H. <pa...@vr...>]

Thomas,
	Your suggestions all seem right on target, but for some reason, they 
don't work for me.  I've verified that all the options I know about are 
being used, including the ones you mention.  I'm testing with my original 
build of PyOpenGL that doesn't have any of the modifications I described 
in the original message.  I guess I'll keep scanning the ld(1) manpage in 
case there's something I am missing.
	Regarding Python 2.3, unfortunately, I have a deadline in two weeks, so 
I can't wait for it--though I may try an alpha or a beta version if I get 
totally frustrated.

  -Patrick

Thomas Wouters wrote:
> On Fri, Apr 25, 2003 at 06:59:39AM -0500, Patrick Hartling wrote:
> 
> 
>>My group is having some problems trying to load a Python module that
>>uses PyOpenGL (2.0.0.44) from C++ code that includes an embedded Python
>>interpreter.  This is happening on Red Hat Linux 8 and FreeBSD 5.
> 
> 
>>The first issue we ran into was unresolved Python/C symbols in various
>>.so files in the PyOpenGL installation.  I attempted to fix this by
>>changing the PyOpenGL build so that all the .so's are linked with
>>-lpython2.2 and -lutil.  This appears to address the unresovled symbol
>>problem, but now I have a new problem that I can't seem to figure out.
> 
> 
> I think this 'solution' actually caused your new problem. Instead, you need
> to build your application in a dlopen()-friendly way: tell your linker to
> export all symbols in your application to the dynamic symbol table. This is
> not the default behaviour, but practically always necessary for applications
> that want to dlopen().
> 
> I haven't used Boost myself, nor built C++ applications, nor embedded Python
> using distutils or other more 'modern' built systems, but way back when
> (cough) you were supposed to use the Makefile.pre that came with the Python
> against which you were building. Makefile.pre is a template makefile that
> contains the right variables to embed Python into your program -- which
> libraries to link to, for instance, which compiler to use, et cetera. It
> still gets built, and indeed, on my Linux system, it contains (among other
> things):
> 
> CCSHARED=       -fPIC
> LINKFORSHARED=  -Xlinker -export-dynamic
> LIBS=           -lrt -ldl  -lpthread -lutil
> 
> I can't imagine e.g. distutils and whatever-Boost-does not providing this,
> as it's quite crucial information for embedding, and it can vary per
> platform (for instance, -lutil is not always necessary or available.)
> 
> 
>>When I run the C++ application that loads the Python module, I get this
>>error:
> 
> 
>>Fatal Python error: Interpreter not initialized (version mismatch?)
> 
> 
> Because you only have libpython2.2.a, using -lpython2.2 means that Python
> 2.2.2 is linked statically into the PyOpenGL .so's (and each seperately, at
> that.) You should not link those .so's with -lpython2.2, and preferably not
> with -lutil either (but that one probably is shared, so might turn out
> okay.) If you really don't want to do the above, you can built
> libpython2.2.so using one of the patches out there (many Python
> distributions do that) or you can wait for Python 2.3, which can build
> libpython2.3.so for more platforms (using --enable-shared).
> 



-- 
Patrick L. Hartling                     | Research Assistant, VRAC
pa...@vr...                | 2624 Howe Hall: 1.515.294.4916
http://www.137.org/patrick/             | http://www.vrac.iastate.edu/

Re: [PyOpenGL-Users] Loading PyOpenGL from embedded Python interpreter

[Thomas W. <th...@xs...>]

On Fri, Apr 25, 2003 at 06:59:39AM -0500, Patrick Hartling wrote:

> My group is having some problems trying to load a Python module that
> uses PyOpenGL (2.0.0.44) from C++ code that includes an embedded Python
> interpreter.  This is happening on Red Hat Linux 8 and FreeBSD 5.

> The first issue we ran into was unresolved Python/C symbols in various
> .so files in the PyOpenGL installation.  I attempted to fix this by
> changing the PyOpenGL build so that all the .so's are linked with
> -lpython2.2 and -lutil.  This appears to address the unresovled symbol
> problem, but now I have a new problem that I can't seem to figure out.

I think this 'solution' actually caused your new problem. Instead, you need
to build your application in a dlopen()-friendly way: tell your linker to
export all symbols in your application to the dynamic symbol table. This is
not the default behaviour, but practically always necessary for applications
that want to dlopen().

I haven't used Boost myself, nor built C++ applications, nor embedded Python
using distutils or other more 'modern' built systems, but way back when
(cough) you were supposed to use the Makefile.pre that came with the Python
against which you were building. Makefile.pre is a template makefile that
contains the right variables to embed Python into your program -- which
libraries to link to, for instance, which compiler to use, et cetera. It
still gets built, and indeed, on my Linux system, it contains (among other
things):

CCSHARED=       -fPIC
LINKFORSHARED=  -Xlinker -export-dynamic
LIBS=           -lrt -ldl  -lpthread -lutil

I can't imagine e.g. distutils and whatever-Boost-does not providing this,
as it's quite crucial information for embedding, and it can vary per
platform (for instance, -lutil is not always necessary or available.)

> When I run the C++ application that loads the Python module, I get this
> error:

> Fatal Python error: Interpreter not initialized (version mismatch?)

Because you only have libpython2.2.a, using -lpython2.2 means that Python
2.2.2 is linked statically into the PyOpenGL .so's (and each seperately, at
that.) You should not link those .so's with -lpython2.2, and preferably not
with -lutil either (but that one probably is shared, so might turn out
okay.) If you really don't want to do the above, you can built
libpython2.2.so using one of the patches out there (many Python
distributions do that) or you can wait for Python 2.3, which can build
libpython2.3.so for more platforms (using --enable-shared).

-- 
Thomas Wouters <th...@xs...>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

[PyOpenGL-Users] Loading PyOpenGL from embedded Python interpreter

[Patrick H. <pa...@vr...>]

[Note: This is a reposting of a message I misdirected to pyopengl-devel 
last night.  I apologize for the reposting, but I wanted to be sure this 
reaches the right audience.]

My group is having some problems trying to load a Python module that
uses PyOpenGL (2.0.0.44) from C++ code that includes an embedded Python
interpreter.  This is happening on Red Hat Linux 8 and FreeBSD 5.

The first issue we ran into was unresolved Python/C symbols in various
.so files in the PyOpenGL installation.  I attempted to fix this by
changing the PyOpenGL build so that all the .so's are linked with
-lpython2.2 and -lutil.  This appears to address the unresovled symbol
problem, but now I have a new problem that I can't seem to figure out.

When I run the C++ application that loads the Python module, I get this
error:

Fatal Python error: Interpreter not initialized (version mismatch?)

I am certain that the interpreter is initialized because I added an
assertion that calls Py_IsInitialized() immediately before trying to
load the Python module.  However, within OpenGL/GL/__init___.so,
Py_IsInitialized() is invoked by Py_InitModule4(), and here,
Py_IsInitialized() returns false.  I am not sure why this is, but I have
a theory.

In Python 2.2.2 (and in most other versions, I presume), there is a
static variable that is used to keep track of whether the interpreter is
initialized (see Python-2.2.2/Python/pythonrun.c).  If there were
different verions of that static variable in memory, there would be
problems in determining whether the interpreter is actually initialized. 
  On FreeBSD and Red Hat Linux, there is no dynamically loadable version
of the Python runtime library--it only exists as libpython2.2.a.  With
the code I am using and the rebuilt PyOpenGL, there are at least
two--possibly three--places where libpython2.2.a is linked.  One is our
C++ code since it is using the Python/C API, and the other is in my
build of PyOpenGL's .so files.  The third place is in Boost.Python, the
library we're using to help our C++ code talk to Python.  All of those
PyOpenGL .so files are loaded at runtime, so is it possible that the
runtime loader isn't handling the symbol resolution correctly?  In other
words, is the runtime loader allowing the existence two or more versions
of various static variables within libpython2.2.a?  I'm not an expert in
how linkers or loaders work, so I could be way off here.  I have read a 
little bit saying that Python modules in C and C++ may not get along 
well unless they are both linked with a C++ compiler, and my next effort 
is going to be linking the PyOpenGL .so's with a C++ compiler.

There are many more details I am leaving out, but I'm trying to include
only the relevant pieces in hopes of zeroing in on a solution more
quickly.  To cause the crash, however, it is sufficient for the Python
module loaded at runtime by the C++ code to be only the following:

from OpenGL.GL import *

The (Boost.Python) code that is doing the module loading looks like this:

std::string module("someModule");
python::handle<>
cur_name(python::borrowed(PyString_FromString(module.c_str())));
python::handle<>
cur_module(python::borrowed(PyImport_Import(cur_name.get())));

I believe that the Python interpreter is initialized correctly prior to
the above calls because everything works fine until the contents of
OpenGL.GL are imported.

I have the stack trace (from FreeBSD 5) leading up to the above error
message being printed, but because I don't have a debugging build of the
Python runtime, it may not be very useful.  Here it is nonetheless:

#0  0x286f9353 in kill () from /usr/lib/libc.so.5
#1  0x287627cc in abort () from /usr/lib/libc.so.5
#2  0x289e8267 in Py_FatalError ()
    from /home/patrick/lib/python/OpenGL/GL/__init___.so
#3  0x289e4ea7 in Py_InitModule4 ()
    from /home/patrick/lib/python/OpenGL/GL/__init___.so
#4  0x2899961f in init__init___ ()
    from /home/patrick/lib/python/OpenGL/GL/__init___.so
#5  0x288393ee in _PyImport_LoadDynamicModule ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#6  0x2883762c in load_module ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#7  0x28838303 in import_submodule ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#8  0x28837ed4 in load_next ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#9  0x28837afd in import_module_ex ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#10 0x28837c4e in PyImport_ImportModuleEx ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#11 0x28855cb3 in builtin___import__ ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#12 0x28804e6c in PyCFunction_Call ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#13 0x287efb19 in PyObject_Call ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#14 0x28826f53 in PyEval_CallObjectWithKeywords ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#15 0x28824f82 in eval_frame ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#16 0x28826339 in PyEval_EvalCodeEx ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#17 0x28823417 in PyEval_EvalCode ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#18 0x28836760 in PyImport_ExecCodeModuleEx ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#19 0x28836d66 in load_source_module ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#20 0x28837602 in load_module ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#21 0x28836ef2 in load_package ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#22 0x2883763d in load_module ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#23 0x28838303 in import_submodule ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#24 0x28837ed4 in load_next ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#25 0x28837afd in import_module_ex ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#26 0x28837c4e in PyImport_ImportModuleEx ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#27 0x28855cb3 in builtin___import__ ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#28 0x28804e6c in PyCFunction_Call ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#29 0x287efb19 in PyObject_Call ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#30 0x28826f53 in PyEval_CallObjectWithKeywords ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#31 0x28824f82 in eval_frame ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#32 0x28826339 in PyEval_EvalCodeEx ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#33 0x28823417 in PyEval_EvalCode ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#34 0x28836760 in PyImport_ExecCodeModuleEx ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#35 0x28836d66 in load_source_module ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#36 0x28837602 in load_module ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#37 0x28836ef2 in load_package ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#38 0x2883763d in load_module ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#39 0x28838303 in import_submodule ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#40 0x28837ed4 in load_next ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#41 0x28837afd in import_module_ex ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#42 0x28837c4e in PyImport_ImportModuleEx ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#43 0x28855cb3 in builtin___import__ ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#44 0x28804e6c in PyCFunction_Call ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#45 0x287efb19 in PyObject_Call ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#46 0x28826f53 in PyEval_CallObjectWithKeywords ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#47 0x28824f82 in eval_frame ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#48 0x28826339 in PyEval_EvalCodeEx ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#49 0x28823417 in PyEval_EvalCode ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#50 0x28836760 in PyImport_ExecCodeModuleEx ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#51 0x28836d66 in load_source_module ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#52 0x28837602 in load_module ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#53 0x28838303 in import_submodule ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#54 0x28837ed4 in load_next ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#55 0x28837afd in import_module_ex ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#56 0x28837c4e in PyImport_ImportModuleEx ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#57 0x28855cb3 in builtin___import__ ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#58 0x28804e6c in PyCFunction_Call ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#59 0x287efb19 in PyObject_Call ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#60 0x28826f53 in PyEval_CallObjectWithKeywords ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#61 0x287efae0 in PyObject_CallObject ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#62 0x287efc2c in PyObject_CallFunction ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#63 0x28838722 in PyImport_Import ()
    from /home/patrick/src/Juggler/Toolbox/simulators/PySim/PySim_drv.so
#64 0x287dace5 in simulators::PySim::switchDriver(std::string const&) (
     this=0x817b200, module=@0x817b37c) at PySim.cpp:350
#65 0x287d9e66 in
simulators::PySim::config(boost::shared_ptr<jccl::ConfigChunk>)
(this=0x817b200, c={px = 0x8157740, pn = {pi_ = 0x8157760}}) at
PySim.cpp:139
#66 0x280c38f3 in
vrj::SimViewport::config(boost::shared_ptr<jccl::ConfigChunk>)
(this=0x8177a00, chunk={px = 0x81576e0, pn = {pi_ = 0x8157720}})
     at
/home/patrick/src/Juggler/main/juggler/modules/vrjuggler/vrj/Display/SimViewport.cpp:94
#67 0x280a8006 in
vrj::Display::configViewports(boost::shared_ptr<jccl::ConfigChunk>)
(this=0x8172540, chunk={px = 0x811d740, pn = {pi_ = 0x811d760}})
     at
/home/patrick/src/Juggler/main/juggler/modules/vrjuggler/vrj/Display/Display.cpp:130
#68 0x280a7298 in
vrj::Display::config(boost::shared_ptr<jccl::ConfigChunk>) (
     this=0x8172540, chunk={px = 0x811d740, pn = {pi_ = 0x811d760}})
     at
/home/patrick/src/Juggler/main/juggler/modules/vrjuggler/vrj/Display/Display.cpp:58
#69 0x280acfff in
vrj::DisplayManager::configAddDisplay(boost::shared_ptr<jccl::ConfigChunk>)
(this=0x81461c0, chunk={px = 0x811d740, pn = {pi_ = 0x811d760}})
     at
/home/patrick/src/Juggler/main/juggler/modules/vrjuggler/vrj/Display/DisplayManager.cpp:210
#70 0x280abca9 in
vrj::DisplayManager::configAdd(boost::shared_ptr<jccl::ConfigChunk>)
(this=0x81461c0, chunk={px = 0x811d740, pn = {pi_ = 0x811d760}})
     at
/home/patrick/src/Juggler/main/juggler/modules/vrjuggler/vrj/Display/DisplayManager.cpp:119
#71 0x2838f91f in jccl::ConfigChunkHandler::configProcessPending() (
     this=0x81461c0)
     at
/home/patrick/src/Juggler/main/juggler/modules/jackal/rtrc/jccl/RTRC/ConfigChunkHandler.cpp:95
#72 0x283961d5 in jccl::ConfigManager::attemptReconfiguration() (
     this=0x8071440)
     at
/home/patrick/src/Juggler/main/juggler/modules/jackal/rtrc/jccl/RTRC/ConfigManager.cpp:477
#73 0x280b6756 in vrj::Kernel::checkForReconfig() (this=0x8070180)
     at
/home/patrick/src/Juggler/main/juggler/modules/vrjuggler/vrj/Kernel/Kernel.cpp:235
#74 0x280b61af in vrj::Kernel::controlLoop(void*) (this=0x8070180,
     nullParam=0x0)
     at
/home/patrick/src/Juggler/main/juggler/modules/vrjuggler/vrj/Kernel/Kernel.cpp:184
#75 0x280bdf4d in vpr::ThreadMemberFunctor<vrj::Kernel>::operator()() (
     this=0x811de40) at Thread/ThreadFunctor.h:127
#76 0x2840bfd8 in vpr::ThreadPosix::startThread(void*) (this=0x8144940,
     null_param=0x0)
     at
/home/patrick/src/Juggler/main/juggler/modules/vapor/vpr/md/POSIX/Thread/ThreadPosix.cpp:299
#77 0x2840cafd in vpr::ThreadMemberFunctor<vpr::ThreadPosix>::operator()() (
     this=0x811de60) at Thread/ThreadFunctor.h:127
#78 0x28407cd5 in vprThreadFunctorFunction (args=0x811de60)
#79 0x286944ee in _thread_start () from /usr/lib/libc_r.so.5

Any help or insight would be greatly appreciated.

  -Patrick


-- 
Patrick L. Hartling                     | Research Assistant, VRAC
pa...@vr...                | 2624 Howe Hall: 1.515.294.4916
http://www.137.org/patrick/             | http://www.vrac.iastate.edu/

Re: [newsletters] Re: [PyOpenGL-Users] OpenGl + Mouse Selection

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

Setup the projection matrix to be slightly larger than a single point 
(OpenGLContext gives you a 2x2 area).  Here's the code from 
OpenGLContext/renderpass's SelectRenderPass class (matrixSize is just a 
tuple of (2,2) in this case):

    def PickProjection( self ):
        """Setup the constrained picking matrix and result buffer

        We set up the view frustum to be a
        box centered around the picking point of size
        self.matrixSize, projecting back into the screen
        from our current viewpoint.

        We then set up the selection buffer into which
        our results will be saved, and then switch to
        selection-mode rendering.
        """
        glMatrixMode(GL_PROJECTION)
        glLoadIdentity()
        glInitNames()
        x,y = self.pickPoint
        gluPickMatrix(
            x,y,
            self.matrixSize [0], self.matrixSize [1],
            self.getViewport()
        )
        glSelectBuffer(self.bufferSize)
        glRenderMode(GL_SELECT)

You can find documentation on gluPickMatrix here:
http://pyopengl.sourceforge.net/documentation/manual/gluPickMatrix.3G.html

HTH,
Mike

sebastien HEITZMANN wrote:

> I use this method with good success.
>
> I just have a little problem. My program paint some line on the OpenGL 
> panel and when i try to select one, I need to be very close to select 
> it. Is it a way to make the select area more large ?
>
> Thanks in advance.
>
> SEB
>
> Jasper Phillips a écrit:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> That sounds like what I want.  Thanks for the search reference!
>> - -Jasper
>>
>> On Mon, 21 Apr 2003, Mike C. Fletcher wrote:
>>  
>>
>>> There are a number of ways to do this, but the most common way I've 
>>> encountered is to use the glSelectBuffer-based selection mechanisms 
>>> which come with OpenGL.  You can find sample code for the 
>>> glSelectBuffer stuff in OpenGLContext or just about any OpenGL 
>>> reference or programming Web site (such as NeHe).
>>>
>>> The basic approach is to re-render the scene in "select" mode, 
>>> pushing "names" (integers) onto the selection stack as you render to 
>>> a frustum which is the projection of your picking point to 
>>> infinity.  When you exit the select rendering mode you receive a 
>>> list of records indicating which names were active when items were 
>>> rendered to the frustum.
>>>
>>> Hope this helps,
>>> Mike
>>>   
>>
>>
>> [snip my original question]
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.0.6 (GNU/Linux)
>> Comment: For info see http://www.gnupg.org
>>
>> iD8DBQE+pFYa8EpjZ7/X9bIRAj6zAJ9Qd3y0PFhixkxbplYA+dxw4vCnYQCgwnGY
>> ic7GD51sUgA+UrrgT+jii2M=
>> =04I+
>> -----END PGP SIGNATURE-----
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by:ThinkGeek
>> Welcome to geek heaven.
>> http://thinkgeek.com/sf
>> _______________________________________________
>> PyOpenGL Homepage
>> http://pyopengl.sourceforge.net
>> _______________________________________________
>> PyOpenGL-Users mailing list
>> PyO...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>>
>>
>>  
>>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

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

Re: [newsletters] Re: [PyOpenGL-Users] OpenGl + Mouse Selection

[sebastien H. <2l...@2l...>]

I use this method with good success.

I just have a little problem. My program paint some line on the OpenGL 
panel and when i try to select one, I need to be very close to select 
it. Is it a way to make the select area more large ?

Thanks in advance.

SEB

Jasper Phillips a écrit:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>That sounds like what I want.  Thanks for the search reference!
>- -Jasper
>
>On Mon, 21 Apr 2003, Mike C. Fletcher wrote:
>  
>
>>There are a number of ways to do this, but the most common way I've 
>>encountered is to use the glSelectBuffer-based selection mechanisms 
>>which come with OpenGL.  You can find sample code for the glSelectBuffer 
>>stuff in OpenGLContext or just about any OpenGL reference or programming 
>>Web site (such as NeHe).
>>
>>The basic approach is to re-render the scene in "select" mode, pushing 
>>"names" (integers) onto the selection stack as you render to a frustum 
>>which is the projection of your picking point to infinity.  When you 
>>exit the select rendering mode you receive a list of records indicating 
>>which names were active when items were rendered to the frustum.
>>
>>Hope this helps,
>>Mike
>>    
>>
>
>[snip my original question]
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.6 (GNU/Linux)
>Comment: For info see http://www.gnupg.org
>
>iD8DBQE+pFYa8EpjZ7/X9bIRAj6zAJ9Qd3y0PFhixkxbplYA+dxw4vCnYQCgwnGY
>ic7GD51sUgA+UrrgT+jii2M=
>=04I+
>-----END PGP SIGNATURE-----
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>PyOpenGL Homepage
>http://pyopengl.sourceforge.net
>_______________________________________________
>PyOpenGL-Users mailing list
>PyO...@li...
>https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>
>  
>

Re: [PyOpenGL-Users] gluNurbsCurve error 100253

[John A. T. <tu...@la...>]

Mike C. Fletcher wrote:

> I'd be very interested in knowing how the build failed for you.  VC6 one 
> of the major build targets, so a failure there is a pretty significant 
> event.  Are you following the 2.0.1 build instructions on the web-site?  
> These mostly consist of installing the dependencies (esp. the right 
> version of SWIG) and then running "setup.py install".

ok, I spent some more time with this, but seem to be stuck

here's what I've done so far...

o my Python 2.2.2 is in C:\Programs\Python22

o unzip the PyOpenGL 2.0.1.03a dist in the above dir

o download swigwin 1.3.13 from:

   http://sourceforge.net/project/showfiles.php?group_id=1645&release_id=50594

  > unzip into C:\Programs\Python22
  > copy swig.exe into C:\Programs\Python22 so it'll be in my PATH

o place OpenGL headers appropriately
  > create C:\Programs\Python22\PyOpenGL-2.0.1.03\include
  > copy GL.h, GLAUX.h, GLU.h, glut.h from

    C:\"Program Files"\"Microsoft Visual Studio"\VC98\Include\GL

    into C:\Programs\Python22\PyOpenGL-2.0.1.03\include
  > look around for glsmap.h - Google to the rescue - found it here:

    http://web.mit.edu/afs/athena/course/6/6.837/include/GL/glsmap.h

    copy it into C:\Programs\Python22\PyOpenGL-2.0.1.03\include as well

o in C:\Programs\Python22\PyOpenGL-2.0.1.03 do:

    python setup.py install

    after a while, build fails with:

building "Togl"
C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD /W3 /GX -I..\include 
-IC:\Programs\Python22\include\numarray -IC:\Programs\Python22\include\Numeric -IC:\Programs\Python22\include -Isrc\Togl-1.6 
-IC:\Programs\Python22\tcl\tk8.3\..\..\include -I..\include -IC:\Programs\Python22\include\numarray 
-IC:\Programs\Python22\include\Numeric -IC:\Programs\Python22\include /Tcsrc\Togl-1.6\togl.c 
/Fobuild\temp.win32-2.2\Release\togl.obj -DWIN32=1 togl.c
src\Togl-1.6\togl.c(55) : fatal error C1083: Cannot open include file: 'tcl.h': No such file or directory
error: command '"C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe"' failed with exit status 2

so, a problem with finding the right Tcl, apparently - but the Installing (and Building)
page seems to indicate that for 2.2.x I shouldn't need to do anything special - I
looked around a bit and can't find tcl.h anywhere in the Python22 tree, though - do I
need to install Tcl/Tk separately?

thx,

-John Turner

Re: [PyOpenGL-Users] OpenGl + Mouse Selection

[Jasper P. <ja...@pe...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


That sounds like what I want.  Thanks for the search reference!
- -Jasper

On Mon, 21 Apr 2003, Mike C. Fletcher wrote:
> There are a number of ways to do this, but the most common way I've 
> encountered is to use the glSelectBuffer-based selection mechanisms 
> which come with OpenGL.  You can find sample code for the glSelectBuffer 
> stuff in OpenGLContext or just about any OpenGL reference or programming 
> Web site (such as NeHe).
> 
> The basic approach is to re-render the scene in "select" mode, pushing 
> "names" (integers) onto the selection stack as you render to a frustum 
> which is the projection of your picking point to infinity.  When you 
> exit the select rendering mode you receive a list of records indicating 
> which names were active when items were rendered to the frustum.
> 
> Hope this helps,
> Mike

[snip my original question]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+pFYa8EpjZ7/X9bIRAj6zAJ9Qd3y0PFhixkxbplYA+dxw4vCnYQCgwnGY
ic7GD51sUgA+UrrgT+jii2M=
=04I+
-----END PGP SIGNATURE-----

Re: [PyOpenGL-Users] gluNurbsCurve error 100253

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

In fact, I have plenty of time to do this (it only takes about 5 minutes 
once you have everything properly set up), I just don't own a VC6 
compiler with which to create the binaries.  We have a volunteer to 
build the major releases once we're to beta stage, and some day soon 
(hopefully) Rene will have a VC6 compiler he can use so we can churn out 
distros for every little point release.  Until then I don't really want 
to bother our volunteer with the minor releases.

I'd be very interested in knowing how the build failed for you.  VC6 one 
of the major build targets, so a failure there is a pretty significant 
event.  Are you following the 2.0.1 build instructions on the web-site?  
These mostly consist of installing the dependencies (esp. the right 
version of SWIG) and then running "setup.py install".

BTW, 2.0.1 is mostly a collection of bug-fix and build-fix releases 
beyond 2.0.0, the API (and indeed most of the system) is entirely 
static, so the decision not to build for Win32 is mostly just husbanding 
minimal resources, not one of rapidly changing systems making releases 
pointless.

Enjoy yourself,
Mike

John A. Turner wrote:

> oops - meant to send that to the list rather than to you personally -
> I realize you probably don't have time - want me to forward it to the
> list and see if anyone else has wrapped up a win32 installer for
> 2.0.1.03a?
>
> -JT
>
> John A. Turner wrote:
>
>> Mike C. Fletcher wrote:
>>
>>> Just to be sure, you are using Numeric v21 or _less_ with Python 
>>> 2.2?  Numeric 22+ is incompatible with the PyOpenGL 2.0.0.44 
>>> binary.  It will load, but fail in lots of simple ways like this.  I 
>>> can't (at the moment) think of anything else that would cause a 
>>> problem with Python 2.2 to 2.1 transition for PyOpenGL.
>>
>>
>>
>> would it be possible to wrap up a win32 installer of 2.0.1.03a, or is
>> it changing too rapidly to make it worthwhile?
>>
>> (I tried building from source but was unsuccessful...)
>>
>> -John Turner
>>
_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

Re: [PyOpenGL-Users] OpenGl + Mouse Selection

[Gary H. <gh...@is...>]

On Monday 21 April 2003 12:11 pm, Jasper Phillips wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I want to be able to "select" different entities rendered in OpenGL w/
> a mouse -- essentially asking which shape the mouse pointer is over.
> Ideally this could be used to select game pieces to move, etc.
>
> This is fairly easy to compute when rending in an orthographic view, as you
> can simply translate mouse coordinates to viewpane coordinates.  However,
> this doesn't work well for perspective views!
>
> It would be nice to simply ask opengl what lies behind a certain screen
> coordinate, but I haven't been able to find anything amongst the "glut"
> (rimshot!) of opengl documentation about this.
>
> Has anyone here had any experience with something like this?  I suspect
> there must be an easy way to do it, as obviously the information is
> available inside of opengl.


OpenGL has a way to do this.  Look at glSelectBuffer, and also
glInitNames, glLoadName, glPushName, and gluPickMaatrix.

Like most things in OpenGL, these are low level tools which provide
much power, but will take a little time to learn to use.

Good Luck,
Gary Herron

Re: [PyOpenGL-Users] OpenGl + Mouse Selection

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

There are a number of ways to do this, but the most common way I've 
encountered is to use the glSelectBuffer-based selection mechanisms 
which come with OpenGL.  You can find sample code for the glSelectBuffer 
stuff in OpenGLContext or just about any OpenGL reference or programming 
Web site (such as NeHe).

The basic approach is to re-render the scene in "select" mode, pushing 
"names" (integers) onto the selection stack as you render to a frustum 
which is the projection of your picking point to infinity.  When you 
exit the select rendering mode you receive a list of records indicating 
which names were active when items were rendered to the frustum.

Hope this helps,
Mike

Jasper Phillips wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I want to be able to "select" different entities rendered in OpenGL w/
>a mouse -- essentially asking which shape the mouse pointer is over.
>Ideally this could be used to select game pieces to move, etc.
>
>This is fairly easy to compute when rending in an orthographic view, as you
>can simply translate mouse coordinates to viewpane coordinates.  However,
>this doesn't work well for perspective views!
>
>It would be nice to simply ask opengl what lies behind a certain screen
>coordinate, but I haven't been able to find anything amongst the "glut"
>(rimshot!) of opengl documentation about this.
>
>Has anyone here had any experience with something like this?  I suspect
>there must be an easy way to do it, as obviously the information is
>available inside of opengl.
>
>- -Jasper
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.6 (GNU/Linux)
>Comment: For info see http://www.gnupg.org
>
>iD8DBQE+pEJN8EpjZ7/X9bIRAilwAKDWUmh9ltlv1HiYRh7G5WO0TlJwWQCg1F3N
>v9HHh5Eip+cBteBTCcPFMbE=
>=c8Xf
>-----END PGP SIGNATURE-----
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>PyOpenGL Homepage
>http://pyopengl.sourceforge.net
>_______________________________________________
>PyOpenGL-Users mailing list
>PyO...@li...
>https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>  
>

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

[PyOpenGL-Users] OpenGl + Mouse Selection

[Jasper P. <ja...@pe...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I want to be able to "select" different entities rendered in OpenGL w/
a mouse -- essentially asking which shape the mouse pointer is over.
Ideally this could be used to select game pieces to move, etc.

This is fairly easy to compute when rending in an orthographic view, as you
can simply translate mouse coordinates to viewpane coordinates.  However,
this doesn't work well for perspective views!

It would be nice to simply ask opengl what lies behind a certain screen
coordinate, but I haven't been able to find anything amongst the "glut"
(rimshot!) of opengl documentation about this.

Has anyone here had any experience with something like this?  I suspect
there must be an easy way to do it, as obviously the information is
available inside of opengl.

- -Jasper

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+pEJN8EpjZ7/X9bIRAilwAKDWUmh9ltlv1HiYRh7G5WO0TlJwWQCg1F3N
v9HHh5Eip+cBteBTCcPFMbE=
=c8Xf
-----END PGP SIGNATURE-----

Re: [PyOpenGL-Users] gluNurbsCurve error 100253

[<2l...@2l...>]

It works

Thank you very very much.

Maybe it should be written in very big on the download page of PyOpenGL
SEB



Mike C. Fletcher a =E9crit:

> Just to be sure, you are using Numeric v21 or _less_ with Python 2.2? =20
> Numeric 22+ is incompatible with the PyOpenGL 2.0.0.44 binary.  It=20
> will load, but fail in lots of simple ways like this.  I can't (at the=20
> moment) think of anything else that would cause a problem with Python=20
> 2.2 to 2.1 transition for PyOpenGL.
>
> HTH,
> Mike
>
> S=E9bastien HEITZMANN wrote:
>
>> Hi, I'm trying to port one of mine program from Python 2.1 to Python 2=
.2
>>
>> I use PyOpenGL-2.0.0.44 binary for Windows with a Nvidia TNT2 opengl=20
>> driver.
>>
>> Everythings works well with Python2.1 on an other machine.
>>
>> I use this function
>>
>> gluNurbsCurve(nurb, crv.uknots, crv.cntrl, GL_MAP1_VERTEX_4)
>>
>> where
>
>
> ...
>
>> Traceback (most recent call last):
>>   File "GLCrv.py", line 99, in ?
>>     main()
>>   File "GLCrv.py", line 88, in main
>>     gluNurbsCurve(nurb, crv.uknots, Numeric.transpose(crv.cntrl),=20
>> GL_MAP1_VERTEX
>> _4)
>> OpenGL.GLU.GLUerror: [Errno 100253] l'=DAtendue du n=A3ud valide est v=
ide
>
>
> ...
>
> _______________________________________
>  Mike C. Fletcher
>  Designer, VR Plumber, Coder
>  http://members.rogers.com/mcfletch/
>
>
>

Re: [PyOpenGL-Users] gluNurbsCurve error 100253

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

Just to be sure, you are using Numeric v21 or _less_ with Python 2.2?  
Numeric 22+ is incompatible with the PyOpenGL 2.0.0.44 binary.  It will 
load, but fail in lots of simple ways like this.  I can't (at the 
moment) think of anything else that would cause a problem with Python 
2.2 to 2.1 transition for PyOpenGL.

HTH,
Mike

Sébastien HEITZMANN wrote:

> Hi, I'm trying to port one of mine program from Python 2.1 to Python 2.2
>
> I use PyOpenGL-2.0.0.44 binary for Windows with a Nvidia TNT2 opengl 
> driver.
>
> Everythings works well with Python2.1 on an other machine.
>
> I use this function
>
> gluNurbsCurve(nurb, crv.uknots, crv.cntrl, GL_MAP1_VERTEX_4)
>
> where

...

> Traceback (most recent call last):
>   File "GLCrv.py", line 99, in ?
>     main()
>   File "GLCrv.py", line 88, in main
>     gluNurbsCurve(nurb, crv.uknots, Numeric.transpose(crv.cntrl), 
> GL_MAP1_VERTEX
> _4)
> OpenGL.GLU.GLUerror: [Errno 100253] l'Útendue du n£ud valide est vide

...

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

[PyOpenGL-Users] gluNurbsCurve error 100253

[<2l...@2l...>]

Hi, I'm trying to port one of mine program from Python 2.1 to Python 2.2

I use PyOpenGL-2.0.0.44 binary for Windows with a Nvidia TNT2 opengl driv=
er.

Everythings works well with Python2.1 on an other machine.

I use this function

gluNurbsCurve(nurb, crv.uknots, crv.cntrl, GL_MAP1_VERTEX_4)

where

crv.uknots=3D [ 0.   0.   0.   0.2  0.4  0.6  0.8  1.   1.   1. ]
crv.cntlr=3D
[[-5.   2.5  0.   1. ]
  [-7.5  5.   0.   1. ]
  [ 2.5  5.   0.   1. ]
  [ 0.   0.   0.   1. ]
  [-2.5 -5.   0.   1. ]
  [ 7.5 -5.   0.   1. ]
  [ 5.   2.5  0.   1. ]]

And that what i obtain :

Traceback (most recent call last):
   File "GLCrv.py", line 99, in ?
     main()
   File "GLCrv.py", line 88, in main
     gluNurbsCurve(nurb, crv.uknots, Numeric.transpose(crv.cntrl),=20
GL_MAP1_VERTEX
_4)
OpenGL.GLU.GLUerror: [Errno 100253] l'=DAtendue du n=A3ud valide est vide


I've already passed a couple of day on this problem which drive me crazy.

Thanks for any help.

S=E9bastien HEITZMANN

Re: [PyOpenGL-Users] memory trouble with a very simple program

[Champ H. <cha...@be...>]

Dear Mike Fletcher,

Thank you for your reply.

Here is my system configuration:
- windows XP professional
- python 2.2.2
- PyOpenGL 2.0.0.44
- wxPython 2.4.0.7u

I also noticed that the memory in use by the application decrease to a
minimum when I minimize the window then reach an intermidiate level
when I restore it (from 15 Mo to 700Ko then back to 3Mo). Then from
this point the memory seems to grow steadily as I hide and show the
application window with another window.

I don't know if this remark can help your diagnosis.

Bernard


Quoting "Mike C. Fletcher" <mcf...@ro...>:
> ---------------- Beginning of the original message ------------------
> I'm unable to provoke the symptoms you describe on Win2K with
> wxPython 
> 2.4.0 and PyOpenGL 2.0.1.03.  Note that there quite a few
> memory leaks 
> patched in the 2.0.1.xx series (which is still in alpha
> testing).  If 
> you're using 2.0.1, please give more details regarding your
> system (e.g. 
> Python version, PyOpenGL version, wxPython version).  I only
> have Win2K 
> for testing, but the code is the same, so if the leak's on our
> side it's 
> likely going to show up in 2K as well as XP.
> 
> Enjoy,
> Mike
> 

Re: [PyOpenGL-Users] memory trouble with a very simple program

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

I'm unable to provoke the symptoms you describe on Win2K with wxPython 
2.4.0 and PyOpenGL 2.0.1.03.  Note that there quite a few memory leaks 
patched in the 2.0.1.xx series (which is still in alpha testing).  If 
you're using 2.0.1, please give more details regarding your system (e.g. 
Python version, PyOpenGL version, wxPython version).  I only have Win2K 
for testing, but the code is the same, so if the leak's on our side it's 
likely going to show up in 2K as well as XP.

Enjoy,
Mike

Champ Hippy wrote:

>Hi,
>
>When I run the following program (see below), the memory that is used
>by my system (windows XP) as indicated by the task manager is
>constantly increasing when I hide and show this PyOpenGL application
>with another window (like the task manager for instance). Of course,
>the memory increase is not huge (4 Ko at a time in general) but it
>does not seem to reach an upper limit. Furthermore, I have the same
>problem for another (more complex) application where I refresh the
>window with new drawings : in this case the memory trouble gets really
>problematic.
>
>What am I doing wrong?
>
>Thanks for your reply.
>
>Bernard
>
>#----------------------------------------------------------------------
>from wxPython.wx        import *
>from wxPython.glcanvas  import *
>from OpenGL.GL          import *
>from OpenGL.GLUT        import *
>
>class MyCanvasBase(wxGLCanvas):
>    def __init__(self, parent):
>        wxGLCanvas.__init__(self, parent, -1)
>        self.init = False
>        EVT_ERASE_BACKGROUND(self, self.OnEraseBackground)
>        EVT_SIZE(self, self.OnSize)
>        EVT_PAINT(self, self.OnPaint)
>
>    def OnEraseBackground(self, event):
>        pass # Do nothing, to avoid flashing on MSW.
>
>    def OnSize(self, event):
>        size = self.GetClientSize()
>        if self.GetContext():
>            self.SetCurrent()
>            glViewport(0, 0, size.width, size.height)
>
>    def OnPaint(self, event):
>        dc = wxPaintDC(self)
>        self.SetCurrent()
>        if not self.init:
>            self.InitGL()
>            self.init = True
>        self.OnDraw()
>
>class RectangleCanvas(MyCanvasBase):
>    def InitGL(self):
>        glMatrixMode(GL_PROJECTION);
>        glFrustum(-0.5, 0.5, -0.5, 0.5, 1.0, 3.0);
>        glMatrixMode(GL_MODELVIEW);
>        glTranslatef(0.0, 0.0, -2.0);
>
>    def OnDraw(self):
>        glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
>        glColor3f(0.0,0.0,1.0)
>        glRectf(-0.5,-0.5,0.5,0.5)
>
>        self.SwapBuffers()
>
>#----------------------------------------------------------------------
>
>def _test():
>    class MyApp(wxApp):
>        def OnInit(self):
>            frame = wxFrame(None, -1, "Test", wxDefaultPosition,
>wxSize(600,300))
>            win = RectangleCanvas(frame)
>            frame.Show(True)
>            ##self.SetTopWindow(frame)
>            return True
>
>    app = MyApp(0)
>    app.MainLoop()
>
>if __name__ == '__main__':
>    _test()
>    
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: ValueWeb: 
>Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
>No other company gives more support or power for your dedicated server
>http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
>_______________________________________________
>PyOpenGL Homepage
>http://pyopengl.sourceforge.net
>_______________________________________________
>PyOpenGL-Users mailing list
>PyO...@li...
>https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>  
>

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

[PyOpenGL-Users] memory trouble with a very simple program

[Champ H. <cha...@be...>]

Hi,

When I run the following program (see below), the memory that is used
by my system (windows XP) as indicated by the task manager is
constantly increasing when I hide and show this PyOpenGL application
with another window (like the task manager for instance). Of course,
the memory increase is not huge (4 Ko at a time in general) but it
does not seem to reach an upper limit. Furthermore, I have the same
problem for another (more complex) application where I refresh the
window with new drawings : in this case the memory trouble gets really
problematic.

What am I doing wrong?

Thanks for your reply.

Bernard

#----------------------------------------------------------------------
from wxPython.wx        import *
from wxPython.glcanvas  import *
from OpenGL.GL          import *
from OpenGL.GLUT        import *

class MyCanvasBase(wxGLCanvas):
    def __init__(self, parent):
        wxGLCanvas.__init__(self, parent, -1)
        self.init = False
        EVT_ERASE_BACKGROUND(self, self.OnEraseBackground)
        EVT_SIZE(self, self.OnSize)
        EVT_PAINT(self, self.OnPaint)

    def OnEraseBackground(self, event):
        pass # Do nothing, to avoid flashing on MSW.

    def OnSize(self, event):
        size = self.GetClientSize()
        if self.GetContext():
            self.SetCurrent()
            glViewport(0, 0, size.width, size.height)

    def OnPaint(self, event):
        dc = wxPaintDC(self)
        self.SetCurrent()
        if not self.init:
            self.InitGL()
            self.init = True
        self.OnDraw()

class RectangleCanvas(MyCanvasBase):
    def InitGL(self):
        glMatrixMode(GL_PROJECTION);
        glFrustum(-0.5, 0.5, -0.5, 0.5, 1.0, 3.0);
        glMatrixMode(GL_MODELVIEW);
        glTranslatef(0.0, 0.0, -2.0);

    def OnDraw(self):
        glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
        glColor3f(0.0,0.0,1.0)
        glRectf(-0.5,-0.5,0.5,0.5)

        self.SwapBuffers()

#----------------------------------------------------------------------

def _test():
    class MyApp(wxApp):
        def OnInit(self):
            frame = wxFrame(None, -1, "Test", wxDefaultPosition,
wxSize(600,300))
            win = RectangleCanvas(frame)
            frame.Show(True)
            ##self.SetTopWindow(frame)
            return True

    app = MyApp(0)
    app.MainLoop()

if __name__ == '__main__':
    _test()
    

Re: [PyOpenGL-Users] nurbs

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

glMap is used in the PyOpenGL Dek/texturesurf demos.  However, it's used 
with the glEvalMesh variants, not the single-coordinate variant.  You 
can also see NURBs done using GLU's nurbs wrappers in 
OpenGLContext/scenegraph/nurbs and the RedBook demos.  The Red Book has, 
if I recall correctly, a rather extensive section on the glMap/glEval stuff.

Good luck,
Mike

Urmas Eero wrote:

> Hi,
> Are there any examples, how to use glMap and glEvalCoord1f ?
> I just don't seem to get it :(
>
> sammy
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open! Get 
> cracking and register here for some mind boggling fun and the chance 
> of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

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

[PyOpenGL-Users] nurbs

[Urmas E. <sa...@lo...>]

Hi, 

Are there any examples, how to use glMap and glEvalCoord1f ?
I just don't seem to get it :(

sammy

Re: [PyOpenGL-Users] Text in linux

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

PyGame can apparently render text to bitmaps quite nicely (so can 
wxPython, for that matter).  I've never gone this route myself.

GLUT has a very limited set of fonts available (see the 
OpenGLContext/tests directory for a quicky sample of using that). 
 That's cross-platform, and generally available when PyOpenGL is.

Until/unless we get one of the "proper" font-rendering libraries 
wrapped, those are probably your best bets.

HTH,
Mike

Andrew Jones wrote:

> I'm fairly new to OpenGL and have been searching for something that 
> will show me how to display text, but all the tutorials I have been 
> able to find have been using windows fonts.  For example, the 
> documentation for rendering text using OpenGLContext 
> (http://pyopengl.sourceforge.net/context/text.html) is only available 
> on Windows systems.  I need a method for displaying text which can be 
> used on both Linux and Windows platforms.  Could somebody point me in 
> the direction of the best way to do this?  Thanks,
>
> Andrew
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open! Get 
> cracking and register here for some mind boggling fun and the chance 
> of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

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

[PyOpenGL-Users] Text in linux

[Andrew J. <aj...@ne...>]

I'm fairly new to OpenGL and have been searching for something that will 
show me how to display text, but all the tutorials I have been able to 
find have been using windows fonts.  For example, the documentation for 
rendering text using OpenGLContext 
(http://pyopengl.sourceforge.net/context/text.html) is only available on 
Windows systems.  I need a method for displaying text which can be used 
on both Linux and Windows platforms.  Could somebody point me in the 
direction of the best way to do this?  Thanks,

Andrew

[PyOpenGL-Users] nehe1-10

[abekat a. <aa...@ho...>]

Hi there

I´m totally new to PyOpenGL, and to try and learn I´ve downloaded the NeHe 
"tutorials" from gamelets at pygame.org. But I have a problem, the examples 
from 6 and up won´t run on my system?

When I doubleclick the file from the folder the prompt in windows 2000 opens 
shortly and you can see that it attempts to open the pygame display, but 
then it shuts it down?

The first 5 examples work alright, why this difference in the running of the 
applications?

Another problem is that I cant seem to shut down the applications by closing 
the display, I have to kill python entirely via the task maneger, needless 
to say this is quite annoying.

I have absolutely no clue what is wrong, my system configuration is the same 
as the one used at my school - Where the exact same problem occurs on some 
machines and not on others - and they are all alike?!?

If additional information is needed let me know.

If anyone knows of a solution I would really appreciate it.

Kind regards
Martin Traberg

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

Re: [PyOpenGL-Users] Texture Blitting?

[Jasper P. <ja...@pe...>]

On Thu, 6 Mar 2003, Rene Dudfield wrote:
> I'm interested in what you've been doing with blitting
> in pygame.  If you posted your code, I'd like to play
> around with it.
>
> A while ago I wrote a pygame.sprite implementation
> which used opengl.  The idea was to be able to switch
> renderers.  It has a number of problems, but kind of
> works ok for some games.
> 
> Be good to get something which works well and fast on
> different computers/games.

I won't claim it's fast, but it should be cross platform!

> Again, if I could have a look at your code I'd like to
> play around with it :)

Sure, although the code is pretty rough, and just a simple an extension
cleanup of code I found on the net.  It can be a pain in the ass to figure
out the proper opengl chants without an example!

In short SurfaceTexture manages a surface that is tied to an opengl texture,
with methods for blitting images to it, and for reverting to the original
image.  The texture binding and drawing code is "static" so that it can be
freely used by other code.

-Jasper



# This Module is modified from Bob Ippolito's code, found in pygame mail list archives

from OpenGL.GL     import *
from OpenGL.GLU    import *
from pygame.locals import *
import pygame

POWERS = (32, 64, 128, 256, 512, 1024, 2048, 4096)

def nextPower(x):
    for y in POWERS:
      if y >= x:
        return y

def surfaceToOglTexture( imgsurf, texture=glGenTextures(1), scale=0, mipmap=0
):
    """Bind an image to opengl texture"""
    owidth, oheight = imgsurf.get_size()
    width, height   = tuple( map( nextPower,imgsurf.get_size() ) )
    imageStr        = pygame.image.tostring( imgsurf, "RGBA", 0 )

    glBindTexture( GL_TEXTURE_2D, texture )
    glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP )
    glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP )
    glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR )

    if mipmap:
        glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER,
GL_LINEAR_MIPMAP_LINEAR )
        gluBuild2DMipmaps( GL_TEXTURE_2D, GL_RGBA, owidth, oheight, GL_RGBA,
GL_UNSIGNED_BYTE, imageStr )
    else:
        glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR )
        if scale:
            image = gluScaleImage( GL_RGBA, owidth, oheight, imageStr, width,
height, GL_UNSIGNED_BYTE )
            glTexImage2D( GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0,
GL_RGBA, GL_UNSIGNED_BYTE, image )
        else:
            glTexImage2D( GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0,
GL_RGBA, GL_UNSIGNED_BYTE, None )
            glTexSubImage2D( GL_TEXTURE_2D, 0, 0, 0, owidth, oheight,
GL_RGBA, GL_UNSIGNED_BYTE, imageStr )

    return texture


def drawTexture( (x,y), (w,h), texture, (screenXRes,screenYRes) ):
    """Draw a Quad in Orthogonal mode with the specified texture"""
    pMatrix = glGetDoublev( GL_PROJECTION_MATRIX )
    mMatrix = glGetDoublev( GL_MODELVIEW_MATRIX )
    glMatrixMode( GL_PROJECTION )
    glLoadIdentity()
    gluOrtho2D( 0, screenXRes, screenYRes, 0 )

    glMatrixMode( GL_MODELVIEW )
    glLoadIdentity()
    glTranslatef( x, y, 0 )

    glEnable( GL_TEXTURE_2D )
    glBindTexture( GL_TEXTURE_2D, texture )

    glBegin( GL_QUADS )
    glTexCoord2f( 0.0, 0.0 ) ; glVertex2f( 0.0, 0.0 )
    glTexCoord2f( 0.0, 1.0 ) ; glVertex2f( 0.0, h )
    glTexCoord2f( 1.0, 1.0 ) ; glVertex2f( w,   h )
    glTexCoord2f( 1.0, 0.0 ) ; glVertex2f( w,   0.0 )
    glEnd()

    glDisable( GL_TEXTURE_2D )

    glMatrixMode( GL_PROJECTION )
    glLoadMatrixd( pMatrix )
    glMatrixMode( GL_MODELVIEW )
    glLoadMatrixd( mMatrix )


class SurfaceTexture:
    """A class for drawing and blitting 'sprites' to images as textures in OpenGL"""
    def __init__( self, surface, screenRes, size=None, pos=(0,0), scale=0, mipmap=0 ):
        self.surface   = surface.convert()
        self.texture   = surfaceToOglTexture( surface, scale=scale, mipmap=mipmap )
        self.screenRes = screenRes
        self.pos       = pos
        if size:
            self.size = size
        else:
            self.size = screenRes

        self.original   = surface.convert()
        self.dirtyRects = []

    def delete( self ):
        glDeleteTextures( [self.texture] )

    def moveTo( self, pos ):
        self.pos = pos

    def moveBy( self, pos ):
        self.pos = ( self.pos[0]+pos[0], self.pos[1]+pos[1] )

    def draw( self ):
        drawTexture( self.pos, self.size, self.texture, self.screenRes )

    def blit( self, sprites ):
        self.surface.lock()
        for sprite in sprites:
            self.surface.blit( sprite.image, sprite.rect )
        self.surface.unlock()
        self.dirtyRects.extend( [sprite.rect for sprite in sprites] )

    def clear( self, sprites ):
        self.surface.lock()
        for sprite in sprites:
            self.surface.blit( self.original.subsurface( sprite.rect ), sprite.rect )
        self.surface.unlock()
        self.dirtyRects.extend( [sprite.rect for sprite in sprites] )

    def updateTexture( self ):
        for rect in self.dirtyRects:
            subSurf  = self.surface.subsurface( rect )
            imageStr = pygame.image.tostring( subSurf, "RGBA", 0 )
            x,y,w,h  = rect

            glBindTexture( GL_TEXTURE_2D, self.texture )
            glTexSubImage2D( GL_TEXTURE_2D, 0, x, y, w, h, GL_RGBA, GL_UNSIGNED_BYTE, imageStr )
        self.dirtyRects = []

Re: [PyOpenGL-Users] Texture Blitting?

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

Hello,

I'm interested in what you've been doing with blitting
in pygame.  If you posted your code, I'd like to play
around with it.

A while ago I wrote a pygame.sprite implementation
which used opengl.  The idea was to be able to switch
renderers.  It has a number of problems, but kind of
works ok for some games.

Be good to get something which works well and fast on
different computers/games.

Again, if I could have a look at your code I'd like to
play around with it :)



 --- Jasper Phillips <ja...@pe...> wrote: > I've
just recently started to use pygame, and am
> rendering in OpenGL as that
> allows smooth full screen scrolling without
> blitting, zooming, etc.  However,
> I still want to change "texture" surfaces, and thus
> need to blit to them.
> This seems simple enough in concept, once you know
> about OpenGL's
> glTexSubImage2d(), but I'm getting strange
> behavior...
> 
> My texture updates work, except on mipmapped
> textures -- then they seem to
> "blend" with the original surface.  Even weirder, if
> multiple blits target
> the same "texels", only the latest blit is "blended"
> with the original
> image!?  Obviously I'm missing something...
> 
> Does anyone know how to make this work correctly
> with mipmapping?  I tried
> changing the "level" argument to glTexSubImage2d(),
> as it's docs allude
> to a connection with mipmapping, but that just
> crashes.
> 
> -Jasper

__________________________________________________
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-Users] Texture Blitting?

[Jasper P. <ja...@pe...>]

I've just recently started to use pygame, and am rendering in OpenGL as that
allows smooth full screen scrolling without blitting, zooming, etc.  However,
I still want to change "texture" surfaces, and thus need to blit to them.
This seems simple enough in concept, once you know about OpenGL's
glTexSubImage2d(), but I'm getting strange behavior...

My texture updates work, except on mipmapped textures -- then they seem to
"blend" with the original surface.  Even weirder, if multiple blits target
the same "texels", only the latest blit is "blended" with the original
image!?  Obviously I'm missing something...

Does anyone know how to make this work correctly with mipmapping?  I tried
changing the "level" argument to glTexSubImage2d(), as it's docs allude
to a connection with mipmapping, but that just crashes.

-Jasper