pyopengl-users — Discussion of all PyOpenGL matters.

[PyOpenGL-Users] PyOpenGL_accelerate isn’t installing on Window 8.1 + Python 3.4.1

[Bravery, G. S <gav...@im...>]

Hi
I am attempting to log a bug for PyOpenGL_accelerate 3.1.0

Trying to install using pip on Windows 8.1, Python 3.4 .1 (cython etc is already installed and working, and I have installed previous version of pyopengl_accelerate).

For some reason PyOpenGL_accelerate isn’t installing.

The last version that will is when I use this:
pip install "PyOpenGL_accelerate==3.0.2"

If I move to anything beyond this I see the below (see bottom of email).

Please let me know if there is anything more I can give you – more than happy to help where I can.

Regards

Gavin Bravery



<stuff that seems to work OK removed>
…
running install_egg_info

running egg_info

writing dependency_links to PyOpenGL_accelerate.egg-info\dependency_links.txt

writing PyOpenGL_accelerate.egg-info\PKG-INFO

writing top-level names to PyOpenGL_accelerate.egg-info\top_level.txt

Unable to import numpy, skipping numpy extension building

warning: manifest_maker: standard file '-c' not found



reading manifest file 'PyOpenGL_accelerate.egg-info\SOURCES.txt'

Traceback (most recent call last):

  File "<string>", line 1, in <module>

  File "C:\Users\gbravery\AppData\Local\Temp\pip_build_gbravery\PyOpenGL-accelerate\setup.py", line 137, in <module>

    **extraArguments

  File "C:\Python34\lib\distutils\core.py", line 148, in setup

    dist.run_commands()

  File "C:\Python34\lib\distutils\dist.py", line 955, in run_commands

    self.run_command(cmd)

  File "C:\Python34\lib\distutils\dist.py", line 974, in run_command

    cmd_obj.run()

  File "C:\Python34\lib\site-packages\setuptools\command\install.py", line 61, in run

    return orig.install.run(self)

  File "C:\Python34\lib\distutils\command\install.py", line 566, in run

    self.run_command(cmd_name)

  File "C:\Python34\lib\distutils\cmd.py", line 313, in run_command

    self.distribution.run_command(command)

  File "C:\Python34\lib\distutils\dist.py", line 974, in run_command

    cmd_obj.run()

  File "C:\Python34\lib\site-packages\setuptools\command\install_egg_info.py", line 33, in run

    self.run_command('egg_info')

  File "C:\Python34\lib\distutils\cmd.py", line 313, in run_command

    self.distribution.run_command(command)

  File "C:\Python34\lib\distutils\dist.py", line 974, in run_command

    cmd_obj.run()

  File "C:\Python34\lib\site-packages\setuptools\command\egg_info.py", line 168, in run

    self.find_sources()

  File "C:\Python34\lib\site-packages\setuptools\command\egg_info.py", line 193, in find_sources

    mm.run()

  File "C:\Python34\lib\site-packages\setuptools\command\egg_info.py", line 277, in run

    self.add_defaults()

  File "C:\Python34\lib\site-packages\setuptools\command\egg_info.py", line 313, in add_defaults

    self.read_manifest()

  File "C:\Python34\lib\site-packages\setuptools\command\sdist.py", line 249, in read_manifest

    self.filelist.append(line)

  File "C:\Python34\lib\site-packages\setuptools\command\egg_info.py", line 218, in append

    path = convert_path(item)

  File "C:\Python34\lib\distutils\util.py", line 125, in convert_path

    raise ValueError("path '%s' cannot be absolute" % pathname)

ValueError: path '/mnt/homevar/var/pylive/src/OpenGL-dev/pyopengl/OpenGL_accelerate/src/arraydatatype.pyx' cannot be absolute

----------------------------------------
  Rolling back uninstall of pyopengl-accelerate
Cleaning up...
Command C:\Python34\python.exe -c "import setuptools, tokenize;__file__='C:\\Use
rs\\gbravery\\AppData\\Local\\Temp\\pip_build_gbravery\\PyOpenGL-accelerate\\set
up.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r
\n', '\n'), __file__, 'exec'))" install --record C:\Users\gbravery\AppData\Local
\Temp\pip-qq3r59zu-record\install-record.txt --single-version-externally-managed
--compile failed with error code 1 in C:\Users\gbravery\AppData\Local\Temp\pip_
build_gbravery\PyOpenGL-accelerate
Storing debug log for failure in C:\Users\gbravery\pip\pip.log

[PyOpenGL-Users] PyOpenGL 3.1.0 Released

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

PyOpenGL 3.1.0 (final) is now available. Headline changes:

  * Generation of wrappers substantially more automatic and based on
    Khronos source-files with annotations from the Chromium/regal project
  * Common code-base for Python 2.6, 2.7, 3.3 and 3.4, Python 2.5 is no
    longer supported
  * Better isolation and pervasive lazy-loading behaviour to prevent
    loading unused libraries (e.g. GLUT in non-GLUT contexts or GLES in
    OpenGL contexts)
  * Automated wrappers now (generally) allow passing in output arrays
    rather than having them generated
  * Experimental support for GLES and EGL
  * Many bug-fixes and minor improvements

Installation can be done from PyPI:

     pip install PyOpenGL PyOpenGL_accelerate

Source code is available on Launchpad:

     bzr branch lp:pyopengl

The homepage, including documentation, remains:

     http://pyopengl.sourceforge.net/

Enjoy,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com

Re: [PyOpenGL-Users] PyOpenGL 3.1.0b3 is out

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

On 14-05-27 09:51 AM, Mike C. Fletcher wrote:
> PyOpenGL 3.1.0b3 is out. Unless something show-stopping happens, this 
> should be the same code shipped in 3.1.0 final. However, there has 
> been *far* more churn than I was intending, so treat this as a real 
> beta; test your libraries/apps.

Crickets chirping has been the only response, so I think we'll consider 
the beta finished.

I'll try to get some time this week to do the final release of 3.1.0

Have fun,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com

Re: [PyOpenGL-Users] Weird zbuffer error on certain hardware

[Ian M. <ia...@ge...>]

On Thu, Jun 5, 2014 at 2:46 AM, Oly <ol...@gm...> wrote:

> I have been writing an example app demonstrating opengl python and gtk,
> however i have hit a weird issue you can see in the video below.
>
> This only happens on one device i have tested another displays perfectly,
> basically i am getting bleed through when rotating the objects and i am at
> a loss as to why.
>
> Any one able to help or suggest what might be causing this issue ?
>
> http://youtu.be/74zD9wIodvQ
>
​That looks like a depth error to me. You should check that you have
enabled depth testing ("glEnable(GL_DEPTH_TEST)"), depth writes, and that
you requested a depth buffer when creating your OpenGL context.

[PyOpenGL-Users] Weird zbuffer error on certain hardware

[Oly <ol...@gm...>]

I have been writing an example app demonstrating opengl python and gtk,
however i have hit a weird issue you can see in the video below.

This only happens on one device i have tested another displays perfectly,
basically i am getting bleed through when rotating the objects and i am at
a loss as to why.

Any one able to help or suggest what might be causing this issue ?

http://youtu.be/74zD9wIodvQ

http://bazaar.launchpad.net/~oly/python-examples/trunk/view/head:/python-examples/gtk3/tut15/sample.py

[PyOpenGL-Users] Oh, addendum to PyOpenGL 3.1.0b3; Py_buffer on Python3 unsupported

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

Almost forgot to mention this:

  * as of b3, I'm having to declare the ctypes implementation of the
    OpenGL/arrays/_buffer.py handler to be non-functional on Python 3.x,
    it consistently results in memory faults
      o the *cython* (accelerated) version works fine in all supported
        CPython releases
      o the Python 2.7 version does work in all of my testing

I've burned way too much time trying to debug that little bit of code, 
so I'm just declaring that configuration unsupported for now.

Take care,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com

[PyOpenGL-Users] PyOpenGL 3.1.0b3 is out

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

PyOpenGL 3.1.0b3 is out. Unless something show-stopping happens, this 
should be the same code shipped in 3.1.0 final. However, there has been 
*far* more churn than I was intending, so treat this as a real beta; 
test your libraries/apps.

Changes since 3.1.0b2:

  * Bug fixes:
      o Eliminate numpy dependencies from some non-numpy-related format
        handlers
      o Eliminate OpenGL dependency from non-OpenGL array handling code
      o Provide a more useful "You don't have GLUT" message when GLUT is
        missing
      o OS-X build-failure workaround (known-bad flag)
      o Unicode argument handling fix (and test for the same), Py2/3 fixes
      o Bug fix in VBO slice assignment logic
      o Bug fix in lists handler error-on-copy raised errors
      o Bug fix in string format handler error raising
      o Bug fix for automatic input/output argument handling with arrays
        (avoid array-of-boolean comparisons, do explicit "is" checks)
      o Export ctypes ArgumentError explicitly from OpenGL.error
      o Provide fgDeinitialize entry-point for FreeGLUT to work around
        FreeGLUT bug in test suites
      o Catch failures in oldStyleReturn where size-calculation isn't
        possible (missing glGet* ENUM) and just return the value unmolested
  * Testing
      o Test for debug messages support
      o Much broader test case running
          + Tests added to test core can now be run across all of Python
            2.6, 2.7, 3.3, 3.4 with and without numpy and with each of
            the major flags on/off
      o Configuration Flags can now be set on the command line
          + PYOPENGL_USE_ACCELERATE=False python <yourscript>.py
  * Newly generated wrappers from the registry
  * Wrapper/Automation (glGet* automation)
      o GLGet sizes pulled from Chromium/regal project, get-sizes
        largely automated now
      o Output annotations largely automated, multi-argument calcsize
        and the like still manual
      o Automated output-based-on-run-time-lookup (glGet*( *_SIZE))
      o Reworking/simplification of wrapper code to just use the
        automated wrappers

Basically the rabbit-hole of trying to get the input/output sizes 
automatically calculated led to far more changes than I'd intended, as 
it went from being a way to get a few missing constants defined to 
actually allowing a lot of wrapper code to be dropped and/or simplified. 
The implementation of the test runner also caught quite a few small bugs 
in corner cases (e.g. Python3, operation of various flags, etc).

Enjoy,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com

Re: [PyOpenGL-Users] any official announcement for 3.1b3?

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

On 05/27/2014 03:41 AM, renaud wrote:
> hello,
> i just noticed the version bump of pyopengl to 3.1b3.
> is there any official announcement somewhere?
> renaud

I'm just sitting down to write it now. My planned time-block to complete 
the release got eaten by work-tasks half-way through.

HTH,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com

[PyOpenGL-Users] any official announcement for 3.1b3?

[renaud <rnd...@gm...>]

hello,
i just noticed the version bump of pyopengl to 3.1b3.
is there any official announcement somewhere?
renaud

Re: [PyOpenGL-Users] glUseProgramObjectARB Invalid Operation

[Ian M. <ia...@ge...>]

On Fri, May 16, 2014 at 6:10 AM, Mike C. Fletcher <mcf...@vr...>wrote:

> I can reproduce it here on a Kubuntu 14.04 laptop.  The shaderInfoLog on
> Intel driver may not be generated (compilation may not actually occur)
> until use-time (some drivers do not actually compile until use of the
> shader occurs).  You're seeing a failure to compile and that's causing this
> message to be generated:
>
>     ['0:2(42): error: syntax error, unexpected IDENTIFIER, expecting
> EOL\n', 'error: linking with uncompiled shader']
>
> where the linking with uncompiled shader is the proximate failure, while
> the previous one is the provoking failure. I just added a try/except around
> the call and called glGetShaderInfoLog for all of the program and shader
> ids.
>
Indeed, the problem was that glGetInfoLogARB wasn't returning what I had
hoped. By changing to glGetShaderInfoLog/glGetProgramInfoLog the errors are
caught and output.

In this case, it seems the extension (required for the modulus operator)
was unrecognized. Getting around this with some integer arithmetic reveals
it doesn't support the switch statement either. I am currently waiting on
the user's input, but for now the test can move forward.

Hope that helps,
> Mike
>
​Thanks for the hint,
Ian​

Re: [PyOpenGL-Users] glUseProgramObjectARB Invalid Operation

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

On 05/16/2014 12:05 AM, Ian Mallett wrote:
> Hi,
>
> A user has reported an invalid operation OpenGL error from calling 
> glUseProgramObjectARB. The important part of the trace:
>   File "/home/sigurd/Documents/Test/5.00/shader.py", line 119, in use
>     glUseProgramObjectARB(shader.shader)
>   File 
> "/usr/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py", 
> line 379, in __call__
>     return self( *args, **named )
>   File "/usr/lib/python2.7/dist-packages/OpenGL/error.py", line 208, 
> in glCheckError
>     baseOperation = baseOperation,
> GLError: GLError(
>     err = 1282,
>     description = 'invalid operation',
>     baseOperation = glUseProgramObjectARB,
>     cArguments = (2L,)
> )
>
> The exact source can be obtained by downloading the program from my 
> website (here 
> <http://geometrian.com/data/programming/projects/Mandelbrot%20Set/Viewer%205.00/Mandelbrot%20Set%20Viewer%205.00.zip>). 
> The program creates the shader after an OpenGL context has been 
> created, and in any case works on all the computers /I/ have tested it on.
>
> The user reports Python 2.7, PyGame 1.9.1, and PyOpenGL 3.1.0b2 
> running on Ubuntu 14.04 (x86-64). The GPU is an Intel Haswell Mobile.
>
> I upgraded my PyOpenGL to the same version, but was unable to 
> reproduce the problem myself (NVIDIA GeForce GTX 580M).

I can reproduce it here on a Kubuntu 14.04 laptop.  The shaderInfoLog on 
Intel driver may not be generated (compilation may not actually occur) 
until use-time (some drivers do not actually compile until use of the 
shader occurs).  You're seeing a failure to compile and that's causing 
this message to be generated:

     ['0:2(42): error: syntax error, unexpected IDENTIFIER, expecting 
EOL\n', 'error: linking with uncompiled shader']

where the linking with uncompiled shader is the proximate failure, while 
the previous one is the provoking failure. I just added a try/except 
around the call and called glGetShaderInfoLog for all of the program and 
shader ids.

Hope that helps,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com

[PyOpenGL-Users] glUseProgramObjectARB Invalid Operation

[Ian M. <ia...@ge...>]

Hi,

A user has reported an invalid operation OpenGL error from calling
glUseProgramObjectARB. The important part of the trace:
  File "/home/sigurd/Documents/Test/5.00/shader.py", line 119, in use
    glUseProgramObjectARB(shader.shader)
  File "/usr/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py",
line 379, in __call__
    return self( *args, **named )
  File "/usr/lib/python2.7/dist-packages/OpenGL/error.py", line 208, in
glCheckError
     baseOperation = baseOperation,
GLError: GLError(
    err = 1282,
    description = 'invalid operation',
    baseOperation = glUseProgramObjectARB,
    cArguments = (2L,)
)

The exact source can be obtained by downloading the program from my website
(here<http://geometrian.com/data/programming/projects/Mandelbrot%20Set/Viewer%205.00/Mandelbrot%20Set%20Viewer%205.00.zip>).
The program creates the shader after an OpenGL context has been created,
and in any case works on all the computers *I* have tested it on.

The user reports Python 2.7, PyGame 1.9.1, and PyOpenGL 3.1.0b2 running on
Ubuntu 14.04 (x86-64). The GPU is an Intel Haswell Mobile.

I upgraded my PyOpenGL to the same version, but was unable to reproduce the
problem myself (NVIDIA GeForce GTX 580M).

Any ideas, anyone?

Thanks,
Ian

Re: [PyOpenGL-Users] glGetInteger with GL_READ_FRAMEBUFFER_BINDING

[Ákos T. <dxm...@gm...>]

This may be related to the mail where you asked us to get the sizes for the
glGet return values (which I completely forgot about, up until 5 seconds
after I sent the mail), if so, disregard me.


On 14 April 2014 15:54, Ákos Tóth <dxm...@gm...> wrote:

> While trying to get the currently bound read buffer, I encountered the
> following error:
>
>   File "/home/marquesas/PycharmProjects/pygrafjatek/pyge/buffer.py", line
> 56, in blit
>     previous = glGetInteger(GL_READ_FRAMEBUFFER_BINDING)
>   File "latebind.pyx", line 32, in
> OpenGL_accelerate.latebind.LateBind.__call__
> (/tmp/pip_build_root/pyopengl-accelerate/src/latebind.c:989)
>   File "wrapper.pyx", line 303, in
> OpenGL_accelerate.wrapper.Wrapper.__call__
> (/tmp/pip_build_root/pyopengl-accelerate/src/wrapper.c:6338)
>   File "wrapper.pyx", line 88, in
> OpenGL_accelerate.wrapper.CArgCalculator.c_call
> (/tmp/pip_build_root/pyopengl-accelerate/src/wrapper.c:2984)
>   File "wrapper.pyx", line 69, in
> OpenGL_accelerate.wrapper.CArgCalculatorElement.c_call
> (/tmp/pip_build_root/pyopengl-accelerate/src/wrapper.c:2536)
>   File "wrapper.pyx", line 64, in
> OpenGL_accelerate.wrapper.CArgCalculatorElement.c_call
> (/tmp/pip_build_root/pyopengl-accelerate/src/wrapper.c:2422)
>   File "arraydatatype.pyx", line 353, in
> OpenGL_accelerate.arraydatatype.SizedOutputOrInput.c_call
> (/tmp/pip_build_root/pyopengl-accelerate/src/arraydatatype.c:7180)
>   File "arraydatatype.pyx", line 346, in
> OpenGL_accelerate.arraydatatype.SizedOutput.c_getSize
> (/tmp/pip_build_root/pyopengl-accelerate/src/arraydatatype.c:6977)
> KeyError: ('Unknown specifier GL_READ_FRAMEBUFFER_BINDING (36010) (lookup
> = <built-in method __getitem__ of dict object at 0x7fb6692b8e60>)', 1,
> <OpenGL.platform.baseplatform.glGetIntegerv object at 0x7fb6692b7c30>)
>
> This is exclusive to GL_READ_FRAMEBUFFER_BINDING; trying to read
> GL_DRAW_FRAMEBUFFER_BINDING works.
>

[PyOpenGL-Users] glGetInteger with GL_READ_FRAMEBUFFER_BINDING

[Ákos T. <dxm...@gm...>]

While trying to get the currently bound read buffer, I encountered the
following error:

  File "/home/marquesas/PycharmProjects/pygrafjatek/pyge/buffer.py", line
56, in blit
    previous = glGetInteger(GL_READ_FRAMEBUFFER_BINDING)
  File "latebind.pyx", line 32, in
OpenGL_accelerate.latebind.LateBind.__call__
(/tmp/pip_build_root/pyopengl-accelerate/src/latebind.c:989)
  File "wrapper.pyx", line 303, in
OpenGL_accelerate.wrapper.Wrapper.__call__
(/tmp/pip_build_root/pyopengl-accelerate/src/wrapper.c:6338)
  File "wrapper.pyx", line 88, in
OpenGL_accelerate.wrapper.CArgCalculator.c_call
(/tmp/pip_build_root/pyopengl-accelerate/src/wrapper.c:2984)
  File "wrapper.pyx", line 69, in
OpenGL_accelerate.wrapper.CArgCalculatorElement.c_call
(/tmp/pip_build_root/pyopengl-accelerate/src/wrapper.c:2536)
  File "wrapper.pyx", line 64, in
OpenGL_accelerate.wrapper.CArgCalculatorElement.c_call
(/tmp/pip_build_root/pyopengl-accelerate/src/wrapper.c:2422)
  File "arraydatatype.pyx", line 353, in
OpenGL_accelerate.arraydatatype.SizedOutputOrInput.c_call
(/tmp/pip_build_root/pyopengl-accelerate/src/arraydatatype.c:7180)
  File "arraydatatype.pyx", line 346, in
OpenGL_accelerate.arraydatatype.SizedOutput.c_getSize
(/tmp/pip_build_root/pyopengl-accelerate/src/arraydatatype.c:6977)
KeyError: ('Unknown specifier GL_READ_FRAMEBUFFER_BINDING (36010) (lookup =
<built-in method __getitem__ of dict object at 0x7fb6692b8e60>)', 1,
<OpenGL.platform.baseplatform.glGetIntegerv object at 0x7fb6692b7c30>)

This is exclusive to GL_READ_FRAMEBUFFER_BINDING; trying to read
GL_DRAW_FRAMEBUFFER_BINDING works.

Re: [PyOpenGL-Users] Anyone feel like looking up glGet constant return sizes?

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

On 14-04-10 12:41 PM, Walter White wrote:
> I guess you mean COMPSIZE()? Did some research on this and
> I found a Python script in Chromium git repo
> that parses the OpenGL specs.
>
> Starting at line 202 is a function parse_arg which parses
> the COMPSIZE parameter starting at line 234.
> It looks a bit cryptic to me, but maybe you can find out
> what they are doing.
>
> You can find it here:
>
> http://git.chromium.org/gitweb/?p=external/p3/regal.git;a=blob_plain;f=src/apitrace/specs/scripts/glspec.py;hb=f21b08d5bf82f6670ecea07a44a77d537cfc4f24
Thanks, that's exactly what I needed. They appear to be using a manually 
maintained mapping in regaltrace.cpp, but that's okay, someone else's 
manual can be our automatic. The approach of having all getsizes in the 
same mapping works nicely too, as we can use the same code/lookup for 
all of the output parameters.

Much obliged,
Mike


> Am 08.04.2014 06:15, schrieb Mike C. Fletcher:
>> On 14-04-03 05:53 AM, Walter White wrote:
>>> I hope this is what you are looking for...just asked the OpenGL IRC.
>>> They told me they are listed in the xml files in this folder
>>>
>>> https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/
>>>
>>> and can be parsed.
>>>
>>> Or in glcorearb.h
>>> https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/GL/glcorearb.h
>>>
>>> Hope that helps,
>>>
>>> Walter
>> It did help, as it reminded me that the enum-groups are present in the
>> xml files, so I can be sure we get all of the constants groups/tracked.
>> However the xml files don't specify the *sizes* of the result arrays.
>> That is, there's a notation saying CALCSIZE() in the xml files, but
>> nothing I can see that tells you what the CALCSIZE() operation should do
>> given a particular parameter.
>>
>> I suppose we could have a fallback path where we did what PyOpenGL 1.x
>> did, namely allocate a huge buffer, fill it with an obscure value, and
>> count how many values are not set to the obscure value on completion.
>> That feels pretty gross, though.
>>
>> Thanks,
>> Mike
>>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> 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://www.vrplumber.com
   http://blog.vrplumber.com

Re: [PyOpenGL-Users] Anyone feel like looking up glGet constant return sizes?

[Walter W. <hom...@gm...>]

I guess you mean COMPSIZE()? Did some research on this and
I found a Python script in Chromium git repo
that parses the OpenGL specs.

Starting at line 202 is a function parse_arg which parses
the COMPSIZE parameter starting at line 234.
It looks a bit cryptic to me, but maybe you can find out
what they are doing.

You can find it here:

http://git.chromium.org/gitweb/?p=external/p3/regal.git;a=blob_plain;f=src/apitrace/specs/scripts/glspec.py;hb=f21b08d5bf82f6670ecea07a44a77d537cfc4f24

Kind regards,
Walter


Am 08.04.2014 06:15, schrieb Mike C. Fletcher:
> On 14-04-03 05:53 AM, Walter White wrote:
>> I hope this is what you are looking for...just asked the OpenGL IRC.
>> They told me they are listed in the xml files in this folder
>>
>> https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/
>>
>> and can be parsed.
>>
>> Or in glcorearb.h
>> https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/GL/glcorearb.h
>>
>> Hope that helps,
>>
>> Walter
> It did help, as it reminded me that the enum-groups are present in the
> xml files, so I can be sure we get all of the constants groups/tracked.
> However the xml files don't specify the *sizes* of the result arrays.
> That is, there's a notation saying CALCSIZE() in the xml files, but
> nothing I can see that tells you what the CALCSIZE() operation should do
> given a particular parameter.
>
> I suppose we could have a fallback path where we did what PyOpenGL 1.x
> did, namely allocate a huge buffer, fill it with an obscure value, and
> count how many values are not set to the obscure value on completion.
> That feels pretty gross, though.
>
> Thanks,
> Mike
>

Re: [PyOpenGL-Users] Anyone feel like looking up glGet constant return sizes?

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

On 14-04-03 05:53 AM, Walter White wrote:
> I hope this is what you are looking for...just asked the OpenGL IRC.
> They told me they are listed in the xml files in this folder
>
> https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/
>
> and can be parsed.
>
> Or in glcorearb.h
> https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/GL/glcorearb.h
>
> Hope that helps,
>
> Walter
It did help, as it reminded me that the enum-groups are present in the 
xml files, so I can be sure we get all of the constants groups/tracked. 
However the xml files don't specify the *sizes* of the result arrays. 
That is, there's a notation saying CALCSIZE() in the xml files, but 
nothing I can see that tells you what the CALCSIZE() operation should do 
given a particular parameter.

I suppose we could have a fallback path where we did what PyOpenGL 1.x 
did, namely allocate a huge buffer, fill it with an obscure value, and 
count how many values are not set to the obscure value on completion. 
That feels pretty gross, though.

Thanks,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com

Re: [PyOpenGL-Users] Load image only with PyOpenGL?

[rndblnch <rnd...@gm...>]

Robinson Risquez <rg868 <at> hotmail.com> writes:

> Hi, there is a way to load and render a simple image only with PyOpenGL
without using PIL, Pygame, FreeImage or others  librarys outside PyOpenGL?
no matter if I use a strange image format or something. I want to avoid
external libraries. Thanks!.

you are looking for one of the netpbm [0] format.
0. Netpbm format
https://en.wikipedia.org/wiki/Netpbm_format

renaud

Re: [PyOpenGL-Users] Load image only with PyOpenGL?

[Chris B. <chr...@no...>]

On Mon, Apr 7, 2014 at 10:46 AM, Ian Mallett <ia...@ge...> wrote:


> PyGame has good support for a wide variety of formats, and works nicely
> with PyOpenGL textures. Using PyGame is doubly justifiable since you need a
> windowing system and GLUT is a terrible choice.
>

Good point -- if you are not using PyGame, you probably want to use SOME
windowing system, and the GUI toolkits all have image file support:

wxPython, pyQT, GTK, ....

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [PyOpenGL-Users] Load image only with PyOpenGL?

[Chris B. <chr...@no...>]

On Fri, Apr 4, 2014 at 10:01 PM, Robinson Risquez <rg...@ho...> wrote:

> Hi, there is a way to load and render a simple image only with PyOpenGL without
> using PIL, Pygame, FreeImage or others librarys outside PyOpenGL? no
> matter if I use a strange image format or something.
>

you could use raw RGB  or RGBA bytes as your format, and then just load
them up into a bytes object and create a texture from  that.

and the stdlib included a couple compression modules:

https://docs.python.org/2/library/archiving.html

so you could write a little custom compressed format with those.

-Chris



>  I want to avoid external libraries. Thanks!.
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [PyOpenGL-Users] Load image only with PyOpenGL?

[Ian M. <ia...@ge...>]

On Fri, Apr 4, 2014 at 11:01 PM, Robinson Risquez <rg...@ho...> wrote:

> Hi, there is a way to load and render a simple image only with PyOpenGL without
> using PIL, Pygame, FreeImage or others librarys outside PyOpenGL? no
> matter if I use a strange image format or something. I want to avoid external
> libraries. Thanks!.
>
This is technically possible, but probably silly. You could try .gif
images, which are fairly straightforward, or maybe roll your own format,
but I see no reason to do so.

PyGame has good support for a wide variety of formats, and works nicely
with PyOpenGL textures. Using PyGame is doubly justifiable since you need a
windowing system and GLUT is a terrible choice.

Re: [PyOpenGL-Users] experimental "buffer" protocol array support in 3.1

[Antoine M. <an...@na...>]

On 25/02/14 04:13, Mike C. Fletcher wrote:
> On 14-02-24 10:36 AM, Antoine Martin wrote:
>> Hi,
>>
>> Can you expand on this new buffer protocol? Is worth using yet?
> At the moment it's only registered for __builtin__.memoryview and 
> __builtin__.bytearray objects. Internally it uses memoryview on the 
> buffer-api supporting objects, and the <buffer> object doesn't *seem* to 
> be compatible (?? weird).
Yes, that's really annoying. See "Ugliness of 2.7":
http://demianbrecht.github.io/posts/2013/02/10/buffer-and-memoryview/#ugliness
>  If you can get your buffer object into a 
> buffer-api supporting object (something you can call memoryview() on) 
> you should be able to pass it into the APIs.
>
> As for testing for support,
>
>      if OpenGL.version.__version__.split('.')[:2] >= ['3','1']:
>
> then you should have the buffer api handler.
Thanks!
I have finally tested it properly and it all works fine.

Cheers
Antoine

[PyOpenGL-Users] Load image only with PyOpenGL?

[Robinson R. <rg...@ho...>]

Hi, there is a way to load and render a simple image only with PyOpenGL without using PIL, Pygame, FreeImage or others  librarys outside PyOpenGL? no matter if I use a strange image format or something. I want to avoid external libraries. Thanks!. 		 	   		  

Re: [PyOpenGL-Users] Anyone feel like looking up glGet constant return sizes?

[Walter W. <hom...@gm...>]

I hope this is what you are looking for...just asked the OpenGL IRC.
They told me they are listed in the xml files in this folder

https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/

and can be parsed.

Or in glcorearb.h
https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/GL/glcorearb.h

Hope that helps,

Walter

[PyOpenGL-Users] Anyone feel like looking up glGet constant return sizes?

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

One of the things that PyOpenGL does when you call GL's glGet* family of 
functions is to auto-allocate the return array. It does this with a 
(manually maintained) mapping from enum/constant -> array-dimensions 
which is defined in src/glgetsizes.csv in the source tree. I have fallen 
*way* behind in keeping up with this list, so there are currently 54 
known glGet-capable constants that don't have a defined size (there are 
*other* constants that should be mapped I'm sure, but only those 
constants which show up in a formal extension description on OpenGL.org 
actually get automatically recognized as ones to annotate).

The work is mostly mechanical, you have to look up the constant, find 
the spec, read through it to see what is expected when you do glGet* for 
that constant, and determine what the array shape should be. Most of the 
glGet operations return a single value, but every once in a while you'll 
find one that returns an array, a string, etc.  If anyone feels like 
hunting down some of those constants and sending me a ping with their 
values, that would be great. If you felt like checking out the source, 
doing a few dozen, and sending a bzr patch, that would be even nicer.

The fact that I've fallen so far behind was brought to my attention by 
the fact that the constants for the various debug extensions were not 
properly mapped in glGet, so you had to manually pass in the data arrays 
to do any debug extension work.

Enjoy,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com