pyopengl-users Mailing List for PyOpenGL (Page 5)
Brought to you by:
mcfletch
Menu
▾
▴
pyopengl-users — Discussion of all PyOpenGL matters.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(81) |
Oct
(41) |
Nov
(55) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(34) |
Feb
(3) |
Mar
(16) |
Apr
(5) |
May
(10) |
Jun
(13) |
Jul
(24) |
Aug
(14) |
Sep
(14) |
Oct
(9) |
Nov
(10) |
Dec
(16) |
| 2003 |
Jan
(25) |
Feb
(59) |
Mar
(9) |
Apr
(21) |
May
(54) |
Jun
(4) |
Jul
(16) |
Aug
(19) |
Sep
(19) |
Oct
(15) |
Nov
(13) |
Dec
(22) |
| 2004 |
Jan
(19) |
Feb
(8) |
Mar
(20) |
Apr
(16) |
May
(13) |
Jun
(18) |
Jul
(18) |
Aug
(14) |
Sep
(24) |
Oct
(47) |
Nov
(20) |
Dec
(10) |
| 2005 |
Jan
(23) |
Feb
(31) |
Mar
(11) |
Apr
(29) |
May
(18) |
Jun
(7) |
Jul
(11) |
Aug
(12) |
Sep
(8) |
Oct
(4) |
Nov
(11) |
Dec
(7) |
| 2006 |
Jan
(7) |
Feb
(8) |
Mar
(15) |
Apr
(3) |
May
(8) |
Jun
(25) |
Jul
(19) |
Aug
(3) |
Sep
(17) |
Oct
(27) |
Nov
(24) |
Dec
(9) |
| 2007 |
Jan
(6) |
Feb
(43) |
Mar
(33) |
Apr
(8) |
May
(20) |
Jun
(11) |
Jul
(7) |
Aug
(8) |
Sep
(11) |
Oct
(22) |
Nov
(15) |
Dec
(18) |
| 2008 |
Jan
(14) |
Feb
(6) |
Mar
(6) |
Apr
(37) |
May
(13) |
Jun
(17) |
Jul
(22) |
Aug
(16) |
Sep
(14) |
Oct
(16) |
Nov
(29) |
Dec
(13) |
| 2009 |
Jan
(7) |
Feb
(25) |
Mar
(38) |
Apr
(57) |
May
(12) |
Jun
(32) |
Jul
(32) |
Aug
(35) |
Sep
(10) |
Oct
(28) |
Nov
(16) |
Dec
(49) |
| 2010 |
Jan
(57) |
Feb
(37) |
Mar
(22) |
Apr
(15) |
May
(45) |
Jun
(25) |
Jul
(32) |
Aug
(7) |
Sep
(13) |
Oct
(2) |
Nov
(11) |
Dec
(28) |
| 2011 |
Jan
(35) |
Feb
(39) |
Mar
|
Apr
(25) |
May
(32) |
Jun
(17) |
Jul
(29) |
Aug
(10) |
Sep
(26) |
Oct
(9) |
Nov
(28) |
Dec
(4) |
| 2012 |
Jan
(24) |
Feb
(47) |
Mar
(4) |
Apr
(8) |
May
(9) |
Jun
(6) |
Jul
(4) |
Aug
(1) |
Sep
(4) |
Oct
(28) |
Nov
(2) |
Dec
(2) |
| 2013 |
Jan
(11) |
Feb
(3) |
Mar
(4) |
Apr
(38) |
May
(15) |
Jun
(11) |
Jul
(15) |
Aug
(2) |
Sep
(2) |
Oct
(4) |
Nov
(3) |
Dec
(14) |
| 2014 |
Jan
(24) |
Feb
(31) |
Mar
(28) |
Apr
(16) |
May
(7) |
Jun
(6) |
Jul
(1) |
Aug
(10) |
Sep
(10) |
Oct
(2) |
Nov
|
Dec
|
| 2015 |
Jan
(6) |
Feb
(5) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
(1) |
Nov
(19) |
Dec
|
| 2016 |
Jan
(6) |
Feb
(1) |
Mar
(7) |
Apr
|
May
(6) |
Jun
|
Jul
(3) |
Aug
(7) |
Sep
|
Oct
(2) |
Nov
(2) |
Dec
|
| 2017 |
Jan
|
Feb
(6) |
Mar
(8) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(3) |
Oct
(2) |
Nov
|
Dec
|
| 2018 |
Jan
(9) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(6) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Stéphane A. <san...@fr...> - 2015-11-26 08:45:13
|
On 11/11/2015 19:26, Mike C. Fletcher wrote: > On 15/10/15 12:26, Stéphane ANCELOT wrote: >> Hi, >> >> I have noticed in my recent linux systems I was no more able to use >> GLE API with pyopengl. >> >> I tried reinstalling the sources, the problem is the same : >> I can import GLE but not use any functions . >> >> OpenGL.error.NullFunctionError: Attempt to call an undefined function >> gleSetJoinStyle, check for bool(gleSetJoinStyle) before calling >> >> I have found similar people with same problem, but no answer. >> >> I am a bit surprised, since setting up Release 3.0.2 from source is >> working , but not releases 3.1.x . >> >> I tried using ctypes and loading libgle libs, no problem. >> >> So, If there is no "good" reason, to inhibit it in 3.1.x releases it >> should work. > > Could you give more details as to *what* Linux systems? PyOpenGL is > primarily written on Kubuntu machines (12.04 and 15.10) and on both > GLE tests using PyOpenGL-Demo and OpenGLContext are all working. > OpenSuse 13.2 64 bits system. (you can testdrive it on susestudio.com) > Are you sure that you've created a GL context before calling any GLE > functions? This is a working / running application, with context, no problem. > I was working on getting the final 3.1.1 release out today, but it > seems that will need to wait until we address this (afraid I haven't > been monitoring my PyOpenGL folder as I worked on my conference > presentation). It looks like you are using ctypes, so I made few investigations and tried this : I had the /usr/lib64/libgle.so library file in the system. I made a symlink named "libGLE.so" in the same directory ===> now, PyOpenGL can run gle Commands ! That may give you some ideas... without any context, the following gle command should work : gleGetJoinStyle() gleSetJoinStyle(...) > Take care, > Mike > > > > -- > ________________________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://www.vrplumber.com > http://blog.vrplumber.com > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users |
|
From: Nicolas P. R. <Nic...@in...> - 2015-11-11 20:43:02
|
Thank you very much Mike. This worked as expected and fixed my problem. If you have some free time, can you mail me your glumpy install problem ? Nicolas > On 11 Nov 2015, at 20:23, Mike C. Fletcher <mcf...@vr...> wrote: > > On 09/11/15 11:05, Chris Barker - NOAA Federal wrote: >> It looks like accelerate is written in Cython. So you should be able >> to refactor it to use memoryviews, which I _think_ will work out of >> the box with proper nearest subclasses. > > I thought so too ;) . But in fact the behaviour of PyOpenGL is > sufficiently generic that it *doesn't* work with memoryviews (I was told > by the cython folks, basically "yeah, don't do that"). > > It *is*, however, supposed to work with subclasses of known/supported > types. It takes an unknown type and walks the __mro__ to find a type > that it *does* recognize... but apparently that's failing. To explicitly > register a type, you can do the following: > > from OpenGL.plugins import FormatHandler > FormatHandler( 'glumpy','OpenGL.arrays.numpymodule.NumpyHandler',[ > 'glumpy.gloo.buffer.VertexBuffer', > ]) > > which will register the handler name 'glumpy' to use the NumpyHandler, > which *should* AFAIK work. I can't get glumpy to compile/install, so I'm > afraid I actually can't test it at the moment. > > Take care, > Mike > >> On Nov 9, 2015, at 5:22 AM, Nicolas P. Rougier <Nic...@in...> wrote: >> >> >> Ok, thanks for the explanation, I'll look into that then. >> >> Nicolas >> >> >> >>>> On 08 Nov 2015, at 18:04, Chris Barker <chr...@no...> wrote: >>>> >>>> On Sun, Nov 8, 2015 at 8:20 AM, Rob McMullen - NOAA Affiliate <rob...@no...> wrote: >>>> I know I've run into that problem when my VBO data was in recarray format. Defining the VBO as a view of the array in dtype=np.float32 format worked. >>>> >>>> I haven't lloked an ANY of the relevant coce here, but this seems to indicae that PyOpenGL_accelerate can't handle subclasses of ndarray -- which doesn't surprise me -- it's notoriously difficult to do that. >>>> >>>> but the error: >>>> >>>> File "arraydatatype.pyx", line 57, in OpenGL_accelerate.arraydatatype.HandlerRegistry.c_lookup (src/arraydatatype.c:2230) >>>> TypeError: No array-type handler for type <class 'glumpy.gloo.buffer.VertexBuffer'> (value: VertexBuffer([151, 10, 1, ..., 0, 128, 63], ) registered >>>> >>>> makes me think that arraydatatype.HandlerRegistry is where you need to put awareness of a new subclass. >>>> >>>> or it needs to be fixed to recognize ndarray subclasses -- either by directly checking if it is a proper subclass, or by using the array protocol -- which I think is the __array__ method... >>>> >>>> HTH, >>>> >>>> -CHris >>>> >>>> >>>> >>>> Rob >>>> >>>> On Thu, Nov 5, 2015 at 11:08 PM, Nicolas P. Rougier <Nic...@in...> wrote: >>>> >>>> I've made a numpy array subclass for a vertex buffer that works great with PyOpenGL but does not work if PyOpenGL_accelerate is installed, it complains about about missing handler: >>>> >>>> File "/Users/rougier/Development/Public/glumpy/glumpy/gloo/buffer.py", line 75, in _update >>>> gl.glBufferSubData(self.target, offset, nbytes, data) >>>> File "latebind.pyx", line 44, in OpenGL_accelerate.latebind.Curry.__call__ (src/latebind.c:1201) >>>> File "/usr/locaL/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/OpenGL/GL/VERSION/GL_1_5.py", line 122, in glBufferSubData >>>> data = ArrayDatatype.asArray( data ) >>>> File "arraydatatype.pyx", line 174, in OpenGL_accelerate.arraydatatype.ArrayDatatype.asArray (src/arraydatatype.c:4221) >>>> File "arraydatatype.pyx", line 57, in OpenGL_accelerate.arraydatatype.HandlerRegistry.c_lookup (src/arraydatatype.c:2230) >>>> TypeError: No array-type handler for type <class 'glumpy.gloo.buffer.VertexBuffer'> (value: VertexBuffer([151, 10, 1, ..., 0, 128, 63], ) registered >>>> >>>> >>>> Python: 3.5 >>>> PyOpenGL: 3.1.0 >>>> PyOpenGL_accelerate: 3.1.0 >>>> The package I'm developing: http://glumpy.github.io >>>> >>>> Any idea ? >>>> >>>> Nicolas >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> PyOpenGL Homepage >>>> http://pyopengl.sourceforge.net >>>> _______________________________________________ >>>> PyOpenGL-Users mailing list >>>> PyO...@li... >>>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> 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... >> ------------------------------------------------------------------------------ >> Presto, an open source distributed SQL query engine for big data, initially >> developed by Facebook, enables you to easily query your data on Hadoop in a >> more interactive manner. Teradata is also now providing full enterprise >> support for Presto. Download a free open source copy now. >> http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140 >> _______________________________________________ >> 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 > > > ------------------------------------------------------------------------------ > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users |
|
From: Mike C. F. <mcf...@vr...> - 2015-11-11 19:23:47
|
On 09/11/15 11:05, Chris Barker - NOAA Federal wrote:
> It looks like accelerate is written in Cython. So you should be able
> to refactor it to use memoryviews, which I _think_ will work out of
> the box with proper nearest subclasses.
I thought so too ;) . But in fact the behaviour of PyOpenGL is
sufficiently generic that it *doesn't* work with memoryviews (I was told
by the cython folks, basically "yeah, don't do that").
It *is*, however, supposed to work with subclasses of known/supported
types. It takes an unknown type and walks the __mro__ to find a type
that it *does* recognize... but apparently that's failing. To explicitly
register a type, you can do the following:
from OpenGL.plugins import FormatHandler
FormatHandler( 'glumpy','OpenGL.arrays.numpymodule.NumpyHandler',[
'glumpy.gloo.buffer.VertexBuffer',
])
which will register the handler name 'glumpy' to use the NumpyHandler,
which *should* AFAIK work. I can't get glumpy to compile/install, so I'm
afraid I actually can't test it at the moment.
Take care,
Mike
> On Nov 9, 2015, at 5:22 AM, Nicolas P. Rougier <Nic...@in...> wrote:
>
>
> Ok, thanks for the explanation, I'll look into that then.
>
> Nicolas
>
>
>
>>> On 08 Nov 2015, at 18:04, Chris Barker <chr...@no...> wrote:
>>>
>>> On Sun, Nov 8, 2015 at 8:20 AM, Rob McMullen - NOAA Affiliate <rob...@no...> wrote:
>>> I know I've run into that problem when my VBO data was in recarray format. Defining the VBO as a view of the array in dtype=np.float32 format worked.
>>>
>>> I haven't lloked an ANY of the relevant coce here, but this seems to indicae that PyOpenGL_accelerate can't handle subclasses of ndarray -- which doesn't surprise me -- it's notoriously difficult to do that.
>>>
>>> but the error:
>>>
>>> File "arraydatatype.pyx", line 57, in OpenGL_accelerate.arraydatatype.HandlerRegistry.c_lookup (src/arraydatatype.c:2230)
>>> TypeError: No array-type handler for type <class 'glumpy.gloo.buffer.VertexBuffer'> (value: VertexBuffer([151, 10, 1, ..., 0, 128, 63], ) registered
>>>
>>> makes me think that arraydatatype.HandlerRegistry is where you need to put awareness of a new subclass.
>>>
>>> or it needs to be fixed to recognize ndarray subclasses -- either by directly checking if it is a proper subclass, or by using the array protocol -- which I think is the __array__ method...
>>>
>>> HTH,
>>>
>>> -CHris
>>>
>>>
>>>
>>> Rob
>>>
>>> On Thu, Nov 5, 2015 at 11:08 PM, Nicolas P. Rougier <Nic...@in...> wrote:
>>>
>>> I've made a numpy array subclass for a vertex buffer that works great with PyOpenGL but does not work if PyOpenGL_accelerate is installed, it complains about about missing handler:
>>>
>>> File "/Users/rougier/Development/Public/glumpy/glumpy/gloo/buffer.py", line 75, in _update
>>> gl.glBufferSubData(self.target, offset, nbytes, data)
>>> File "latebind.pyx", line 44, in OpenGL_accelerate.latebind.Curry.__call__ (src/latebind.c:1201)
>>> File "/usr/locaL/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/OpenGL/GL/VERSION/GL_1_5.py", line 122, in glBufferSubData
>>> data = ArrayDatatype.asArray( data )
>>> File "arraydatatype.pyx", line 174, in OpenGL_accelerate.arraydatatype.ArrayDatatype.asArray (src/arraydatatype.c:4221)
>>> File "arraydatatype.pyx", line 57, in OpenGL_accelerate.arraydatatype.HandlerRegistry.c_lookup (src/arraydatatype.c:2230)
>>> TypeError: No array-type handler for type <class 'glumpy.gloo.buffer.VertexBuffer'> (value: VertexBuffer([151, 10, 1, ..., 0, 128, 63], ) registered
>>>
>>>
>>> Python: 3.5
>>> PyOpenGL: 3.1.0
>>> PyOpenGL_accelerate: 3.1.0
>>> The package I'm developing: http://glumpy.github.io
>>>
>>> Any idea ?
>>>
>>> Nicolas
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> PyOpenGL Homepage
>>> http://pyopengl.sourceforge.net
>>> _______________________________________________
>>> PyOpenGL-Users mailing list
>>> PyO...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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...
> ------------------------------------------------------------------------------
> Presto, an open source distributed SQL query engine for big data, initially
> developed by Facebook, enables you to easily query your data on Hadoop in a
> more interactive manner. Teradata is also now providing full enterprise
> support for Presto. Download a free open source copy now.
> http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140
> _______________________________________________
> 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
|
|
From: Mike C. F. <mcf...@vr...> - 2015-11-11 18:45:10
|
On 15/10/15 12:26, Stéphane ANCELOT wrote: > Hi, > > I have noticed in my recent linux systems I was no more able to use > GLE API with pyopengl. > > I tried reinstalling the sources, the problem is the same : > I can import GLE but not use any functions . > > OpenGL.error.NullFunctionError: Attempt to call an undefined function > gleSetJoinStyle, check for bool(gleSetJoinStyle) before calling > > I have found similar people with same problem, but no answer. > > I am a bit surprised, since setting up Release 3.0.2 from source is > working , but not releases 3.1.x . > > I tried using ctypes and loading libgle libs, no problem. > > So, If there is no "good" reason, to inhibit it in 3.1.x releases it > should work. Could you give more details as to *what* Linux systems? PyOpenGL is primarily written on Kubuntu machines (12.04 and 15.10) and on both GLE tests using PyOpenGL-Demo and OpenGLContext are all working. Are you sure that you've created a GL context before calling any GLE functions? I was working on getting the final 3.1.1 release out today, but it seems that will need to wait until we address this (afraid I haven't been monitoring my PyOpenGL folder as I worked on my conference presentation). Take care, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
|
From: Chris B. - N. F. <chr...@no...> - 2015-11-09 16:05:32
|
It looks like accelerate is written in Cython. So you should be able to refactor it to use memoryviews, which I _think_ will work out of the box with proper nearest subclasses. -CHB > On Nov 9, 2015, at 5:22 AM, Nicolas P. Rougier <Nic...@in...> wrote: > > > Ok, thanks for the explanation, I'll look into that then. > > Nicolas > > > >> On 08 Nov 2015, at 18:04, Chris Barker <chr...@no...> wrote: >> >> On Sun, Nov 8, 2015 at 8:20 AM, Rob McMullen - NOAA Affiliate <rob...@no...> wrote: >> I know I've run into that problem when my VBO data was in recarray format. Defining the VBO as a view of the array in dtype=np.float32 format worked. >> >> I haven't lloked an ANY of the relevant coce here, but this seems to indicae that PyOpenGL_accelerate can't handle subclasses of ndarray -- which doesn't surprise me -- it's notoriously difficult to do that. >> >> but the error: >> >> File "arraydatatype.pyx", line 57, in OpenGL_accelerate.arraydatatype.HandlerRegistry.c_lookup (src/arraydatatype.c:2230) >> TypeError: No array-type handler for type <class 'glumpy.gloo.buffer.VertexBuffer'> (value: VertexBuffer([151, 10, 1, ..., 0, 128, 63], ) registered >> >> makes me think that arraydatatype.HandlerRegistry is where you need to put awareness of a new subclass. >> >> or it needs to be fixed to recognize ndarray subclasses -- either by directly checking if it is a proper subclass, or by using the array protocol -- which I think is the __array__ method... >> >> HTH, >> >> -CHris >> >> >> >> Rob >> >> On Thu, Nov 5, 2015 at 11:08 PM, Nicolas P. Rougier <Nic...@in...> wrote: >> >> I've made a numpy array subclass for a vertex buffer that works great with PyOpenGL but does not work if PyOpenGL_accelerate is installed, it complains about about missing handler: >> >> File "/Users/rougier/Development/Public/glumpy/glumpy/gloo/buffer.py", line 75, in _update >> gl.glBufferSubData(self.target, offset, nbytes, data) >> File "latebind.pyx", line 44, in OpenGL_accelerate.latebind.Curry.__call__ (src/latebind.c:1201) >> File "/usr/locaL/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/OpenGL/GL/VERSION/GL_1_5.py", line 122, in glBufferSubData >> data = ArrayDatatype.asArray( data ) >> File "arraydatatype.pyx", line 174, in OpenGL_accelerate.arraydatatype.ArrayDatatype.asArray (src/arraydatatype.c:4221) >> File "arraydatatype.pyx", line 57, in OpenGL_accelerate.arraydatatype.HandlerRegistry.c_lookup (src/arraydatatype.c:2230) >> TypeError: No array-type handler for type <class 'glumpy.gloo.buffer.VertexBuffer'> (value: VertexBuffer([151, 10, 1, ..., 0, 128, 63], ) registered >> >> >> Python: 3.5 >> PyOpenGL: 3.1.0 >> PyOpenGL_accelerate: 3.1.0 >> The package I'm developing: http://glumpy.github.io >> >> Any idea ? >> >> Nicolas >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> PyOpenGL Homepage >> http://pyopengl.sourceforge.net >> _______________________________________________ >> PyOpenGL-Users mailing list >> PyO...@li... >> https://lists.sourceforge.net/lists/listinfo/pyopengl-users >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> 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... > |
|
From: Nicolas P. R. <Nic...@in...> - 2015-11-09 13:22:10
|
Ok, thanks for the explanation, I'll look into that then. Nicolas > On 08 Nov 2015, at 18:04, Chris Barker <chr...@no...> wrote: > > On Sun, Nov 8, 2015 at 8:20 AM, Rob McMullen - NOAA Affiliate <rob...@no...> wrote: > I know I've run into that problem when my VBO data was in recarray format. Defining the VBO as a view of the array in dtype=np.float32 format worked. > > I haven't lloked an ANY of the relevant coce here, but this seems to indicae that PyOpenGL_accelerate can't handle subclasses of ndarray -- which doesn't surprise me -- it's notoriously difficult to do that. > > but the error: > > File "arraydatatype.pyx", line 57, in OpenGL_accelerate.arraydatatype.HandlerRegistry.c_lookup (src/arraydatatype.c:2230) > TypeError: No array-type handler for type <class 'glumpy.gloo.buffer.VertexBuffer'> (value: VertexBuffer([151, 10, 1, ..., 0, 128, 63], ) registered > > makes me think that arraydatatype.HandlerRegistry is where you need to put awareness of a new subclass. > > or it needs to be fixed to recognize ndarray subclasses -- either by directly checking if it is a proper subclass, or by using the array protocol -- which I think is the __array__ method... > > HTH, > > -CHris > > > > Rob > > On Thu, Nov 5, 2015 at 11:08 PM, Nicolas P. Rougier <Nic...@in...> wrote: > > I've made a numpy array subclass for a vertex buffer that works great with PyOpenGL but does not work if PyOpenGL_accelerate is installed, it complains about about missing handler: > > File "/Users/rougier/Development/Public/glumpy/glumpy/gloo/buffer.py", line 75, in _update > gl.glBufferSubData(self.target, offset, nbytes, data) > File "latebind.pyx", line 44, in OpenGL_accelerate.latebind.Curry.__call__ (src/latebind.c:1201) > File "/usr/locaL/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/OpenGL/GL/VERSION/GL_1_5.py", line 122, in glBufferSubData > data = ArrayDatatype.asArray( data ) > File "arraydatatype.pyx", line 174, in OpenGL_accelerate.arraydatatype.ArrayDatatype.asArray (src/arraydatatype.c:4221) > File "arraydatatype.pyx", line 57, in OpenGL_accelerate.arraydatatype.HandlerRegistry.c_lookup (src/arraydatatype.c:2230) > TypeError: No array-type handler for type <class 'glumpy.gloo.buffer.VertexBuffer'> (value: VertexBuffer([151, 10, 1, ..., 0, 128, 63], ) registered > > > Python: 3.5 > PyOpenGL: 3.1.0 > PyOpenGL_accelerate: 3.1.0 > The package I'm developing: http://glumpy.github.io > > Any idea ? > > Nicolas > > > > ------------------------------------------------------------------------------ > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > > > ------------------------------------------------------------------------------ > > _______________________________________________ > 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... |
|
From: Chris B. <chr...@no...> - 2015-11-08 17:29:54
|
On Sun, Nov 8, 2015 at 8:20 AM, Rob McMullen - NOAA Affiliate < rob...@no...> wrote: > I know I've run into that problem when my VBO data was in recarray format. > Defining the VBO as a view of the array in dtype=np.float32 format worked. > I haven't lloked an ANY of the relevant coce here, but this seems to indicae that PyOpenGL_accelerate can't handle subclasses of ndarray -- which doesn't surprise me -- it's notoriously difficult to do that. but the error: File "arraydatatype.pyx", line 57, in OpenGL_accelerate. arraydatatype.HandlerRegistry.c_lookup (src/arraydatatype.c:2230) TypeError: No array-type handler for type <class 'glumpy.gloo.buffer.VertexBuffer'> (value: VertexBuffer([151, 10, 1, ..., 0, 128, 63], ) registered makes me think that arraydatatype.HandlerRegistry is where you need to put awareness of a new subclass. or it needs to be fixed to recognize ndarray subclasses -- either by directly checking if it is a proper subclass, or by using the array protocol -- which I think is the __array__ method... HTH, -CHris > Rob > > On Thu, Nov 5, 2015 at 11:08 PM, Nicolas P. Rougier < > Nic...@in...> wrote: > >> >> I've made a numpy array subclass for a vertex buffer that works great >> with PyOpenGL but does not work if PyOpenGL_accelerate is installed, it >> complains about about missing handler: >> >> File "/Users/rougier/Development/Public/glumpy/glumpy/gloo/buffer.py", >> line 75, in _update >> gl.glBufferSubData(self.target, offset, nbytes, data) >> File "latebind.pyx", line 44, in >> OpenGL_accelerate.latebind.Curry.__call__ (src/latebind.c:1201) >> File >> "/usr/locaL/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/OpenGL/GL/VERSION/GL_1_5.py", >> line 122, in glBufferSubData >> data = ArrayDatatype.asArray( data ) >> File "arraydatatype.pyx", line 174, in >> OpenGL_accelerate.arraydatatype.ArrayDatatype.asArray >> (src/arraydatatype.c:4221) >> File "arraydatatype.pyx", line 57, in >> OpenGL_accelerate.arraydatatype.HandlerRegistry.c_lookup >> (src/arraydatatype.c:2230) >> TypeError: No array-type handler for type <class >> 'glumpy.gloo.buffer.VertexBuffer'> (value: VertexBuffer([151, 10, 1, >> ..., 0, 128, 63], ) registered >> >> >> Python: 3.5 >> PyOpenGL: 3.1.0 >> PyOpenGL_accelerate: 3.1.0 >> The package I'm developing: http://glumpy.github.io >> >> Any idea ? >> >> Nicolas >> >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> PyOpenGL Homepage >> http://pyopengl.sourceforge.net >> _______________________________________________ >> PyOpenGL-Users mailing list >> PyO...@li... >> https://lists.sourceforge.net/lists/listinfo/pyopengl-users >> > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > 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... |
|
From: Rob M. - N. A. <rob...@no...> - 2015-11-08 16:20:32
|
I know I've run into that problem when my VBO data was in recarray format. Defining the VBO as a view of the array in dtype=np.float32 format worked. Rob On Thu, Nov 5, 2015 at 11:08 PM, Nicolas P. Rougier < Nic...@in...> wrote: > > I've made a numpy array subclass for a vertex buffer that works great with > PyOpenGL but does not work if PyOpenGL_accelerate is installed, it > complains about about missing handler: > > File "/Users/rougier/Development/Public/glumpy/glumpy/gloo/buffer.py", > line 75, in _update > gl.glBufferSubData(self.target, offset, nbytes, data) > File "latebind.pyx", line 44, in > OpenGL_accelerate.latebind.Curry.__call__ (src/latebind.c:1201) > File > "/usr/locaL/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/OpenGL/GL/VERSION/GL_1_5.py", > line 122, in glBufferSubData > data = ArrayDatatype.asArray( data ) > File "arraydatatype.pyx", line 174, in > OpenGL_accelerate.arraydatatype.ArrayDatatype.asArray > (src/arraydatatype.c:4221) > File "arraydatatype.pyx", line 57, in > OpenGL_accelerate.arraydatatype.HandlerRegistry.c_lookup > (src/arraydatatype.c:2230) > TypeError: No array-type handler for type <class > 'glumpy.gloo.buffer.VertexBuffer'> (value: VertexBuffer([151, 10, 1, > ..., 0, 128, 63], ) registered > > > Python: 3.5 > PyOpenGL: 3.1.0 > PyOpenGL_accelerate: 3.1.0 > The package I'm developing: http://glumpy.github.io > > Any idea ? > > Nicolas > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > |
|
From: Nicolas P. R. <Nic...@in...> - 2015-11-06 07:08:52
|
I've made a numpy array subclass for a vertex buffer that works great with PyOpenGL but does not work if PyOpenGL_accelerate is installed, it complains about about missing handler:
File "/Users/rougier/Development/Public/glumpy/glumpy/gloo/buffer.py", line 75, in _update
gl.glBufferSubData(self.target, offset, nbytes, data)
File "latebind.pyx", line 44, in OpenGL_accelerate.latebind.Curry.__call__ (src/latebind.c:1201)
File "/usr/locaL/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/OpenGL/GL/VERSION/GL_1_5.py", line 122, in glBufferSubData
data = ArrayDatatype.asArray( data )
File "arraydatatype.pyx", line 174, in OpenGL_accelerate.arraydatatype.ArrayDatatype.asArray (src/arraydatatype.c:4221)
File "arraydatatype.pyx", line 57, in OpenGL_accelerate.arraydatatype.HandlerRegistry.c_lookup (src/arraydatatype.c:2230)
TypeError: No array-type handler for type <class 'glumpy.gloo.buffer.VertexBuffer'> (value: VertexBuffer([151, 10, 1, ..., 0, 128, 63], ) registered
Python: 3.5
PyOpenGL: 3.1.0
PyOpenGL_accelerate: 3.1.0
The package I'm developing: http://glumpy.github.io
Any idea ?
Nicolas
|
|
From: Stéphane A. <san...@fr...> - 2015-10-15 16:27:01
|
Hi, I have noticed in my recent linux systems I was no more able to use GLE API with pyopengl. I tried reinstalling the sources, the problem is the same : I can import GLE but not use any functions . OpenGL.error.NullFunctionError: Attempt to call an undefined function gleSetJoinStyle, check for bool(gleSetJoinStyle) before calling I have found similar people with same problem, but no answer. I am a bit surprised, since setting up Release 3.0.2 from source is working , but not releases 3.1.x . I tried using ctypes and loading libgle libs, no problem. So, If there is no "good" reason, to inhibit it in 3.1.x releases it should work. Please can you correct it in 3.1.x release .Thanks. Regards, S.Ancelot |
|
From: Ian M. <ia...@ge...> - 2015-09-24 03:11:28
|
You need an OpenGL context first. |
|
From: famc2 <fa...@16...> - 2015-09-22 06:03:40
|
hello folks
I want to get the version of OpenGL:
from OpenGL.GL import glGetString, GL_VERSION
glGetString(GL_VERSION)
But I got error:
===============================================================
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Python27\lib\site-packages\OpenGL\error.py", line 232, in glCheckErro
r
baseOperation = baseOperation,
OpenGL.error.GLError: GLError(
err = 1282,
description = '\xce\xde\xd0\xa7\xb2\xd9\xd7\xf7',
baseOperation = glGetString,
cArguments = (GL_VERSION,)
)
===============================================================
What's the problem?
Thanks very much!
|
|
From: Mike C. F. <mcf...@vr...> - 2015-08-12 18:45:11
|
On 15-07-31 01:17 PM, Stuart Axon wrote: > Hi, > I've been trying to get the shader_instanced example at > http://pyopengl.sourceforge.net/context/tutorials/shader_instanced.html working, > but having some trouble. > > I've been using the fixed version from here > http://stackoverflow.com/questions/16945500/why-is-this-tutorial-example-of-a-shader-not-displaying-any-geometry-as-it-is-su > > But get this error > > RuntimeError: ('Shader compile failure (0): 0:1(10): error: GLSL 3.30 > is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, > and 3.00 ES\n', ['#version 330\n void main() > {\n gl_Position = gl_ModelViewProjectionMatrix * > gl_Vertex;\n }'], GL_VERTEX_SHADER) > > Is it possible to make the testcontext be OpenGL 3.3, glxinfo tells me: Not sure if that demo actually *requires* GLSL version 3.3, or whether it just declares that because it's what my machine has. Your driver apparently would give you 3.3 if it were a core context (I haven't seen that before), but only 1.3 for compat context. OpenGLContext is rather old, so it doesn't have support for core profile contexts. That said, you could likely take a core-profile demo, copy the shaders over to it, and run the result. Good luck, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
|
From: Stuart A. <st...@ya...> - 2015-07-31 17:17:12
|
Hi, I've been trying to get the shader_instanced example at http://pyopengl.sourceforge.net/context/tutorials/shader_instanced.html working, but having some trouble. I've been using the fixed version from herehttp://stackoverflow.com/questions/16945500/why-is-this-tutorial-example-of-a-shader-not-displaying-any-geometry-as-it-is-su But get this error RuntimeError: ('Shader compile failure (0): 0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES\n', ['#version 330\n void main() {\n gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;\n }'], GL_VERTEX_SHADER) Is it possible to make the testcontext be OpenGL 3.3, glxinfo tells me: OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.7.0-devel (git-7830e46 2015-07-31 vivid-oibaf-ppa) OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 10.7.0-devel (git-7830e46 2015-07-31 vivid-oibaf-ppa) OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.7.0-devel (git-7830e46 2015-07-31 vivid-oibaf-ppa) OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00 OpenGL ES profile extensions: S++ |
|
From: Gmail <fun...@gm...> - 2015-04-20 21:06:16
|
When I try and do x = glGetDoublev(MODELVIEW_MATRIX), It prints some crazy memory shit. (<haiieidx82992828000> or something). No idea why this is. Pyopengl 3 Sent from my iPhone |
|
From: rndblnch <rnd...@gm...> - 2015-02-23 15:42:21
|
Johannes Bauer <dfnsonfsduifb <at> gmx.de> writes: > > Hello list, > > I'm trying to store objects (currently only vertices) on the graphics > card so that I can avoid lots of: > > glBegin() > glVertex(...) > [...] > glEnd() you may find this tutorial useful: https://bitbucket.org/rndblnch/opengl-programmable/src it shows the transformation of a minimal sample from direct mode to the "modern" programmable pipeline step by step. you can easily diff two successive versions of the code, e.g.: diff 01-direct.py 03-array.py 5c5 < 01-direct.py --- > 03-array.py 7c7 < OpenGL 1.0 rendering using per vertex primitive --- > OpenGL 1.1 rendering using arrays 71a72,75 > def flatten(*lll): > return [u for ll in lll for l in ll for u in l] > > 72a77,83 > # enabling arrays > glEnableClientState(GL_VERTEX_ARRAY) > glEnableClientState(GL_TEXTURE_COORD_ARRAY) > glEnableClientState(GL_NORMAL_ARRAY) > glEnableClientState(GL_COLOR_ARRAY) > > # model data 76,79c87,90 < verticies, tex_coords, normals, colors = (model.verticies, < model.tex_coords, < model.normals, < model.colors) --- > verticies = flatten(model.verticies) > tex_coords = flatten(model.tex_coords) > normals = flatten(model.normals) > colors = flatten(model.colors) 82a94,98 > glVertexPointer(3, GL_FLOAT, 0, verticies) > glTexCoordPointer(3, GL_FLOAT, 0, tex_coords) > glNormalPointer(GL_FLOAT, 0, normals) > glColorPointer(3, GL_FLOAT, 0, colors) > 90,97c106,108 < glBegin(GL_TRIANGLE_STRIP) < for i in range(offset, offset+size): < index = indicies[i] < glColor3f(*colors[index]) < glNormal3f(*normals[index]) < glTexCoord3f(*tex_coords[index]) < glVertex3f(*verticies[index]) < glEnd() --- > glDrawElements(GL_TRIANGLE_STRIP, > size, GL_UNSIGNED_INT, > indicies[offset:offset+size]) renaud |
|
From: Mads I. <mad...@gm...> - 2015-02-12 06:52:26
|
This tutorial/sample initially got me going: http://www.lighthouse3d.com/cg-topics/code-samples/opengl-3-3-glsl-1-5-sample/ On 27/01/15 21:36, Johannes Bauer wrote: > Hello list, > > I'm trying to store objects (currently only vertices) on the graphics > card so that I can avoid lots of: > > glBegin() > glVertex(...) > [...] > glEnd() > > I've tried lots and lots of code now (none of which fully did what I > wanted) and really am losing my mind soon :-( I could adapt this to work > with my code: > > https://gist.github.com/MorganBorman/4243336 > > And it does work, but when integrated in my 3D environment I noticed > that the drawn objects are not rendered perspectively, but just a flat > object. > > I'm looking for the easiest way to dump a bunch of vertices onto the > graphics card and later reference those vertices to draw some object and > have it render as if I had used glBegin(), glVertex(), glEnd(). Is this > possible at all? Which approach should I look into? > > In general I've seen two different approaches, one that involes (usually > super-primitive) shaders, others do not. I do not see why I would need a > custom-shader for this task, is this really necessary? > > My goal ultimately is to store surfaces (i.e. vertices, their normals, > their texture UV coordinates) on the graphics card. > > Any help is greatly appreciated, > Johannes > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > -- +---------------------------------------------------------------------+ | Mads Ipsen | +----------------------------------+----------------------------------+ | Overgaden Oven Vandet 106, 4.tv | phone: +45-29716388 | | DK-1415 København K | email: mad...@gm... | | Denmark | map : https://goo.gl/maps/oQ6y6 | +----------------------------------+----------------------------------+ |
|
From: Mike C. F. <mcf...@vr...> - 2015-02-11 14:55:10
|
On 15-02-10 12:32 PM, Henry Gomersall wrote: > Setting the last argument of glVertexAttribPointer (the pointer offset) > to anything other than None seems to cause the vertex buffer to not work > (at least, I don't seem to be able to render it - that's about as far as > I'm competent to debug). > > Using pyglet.gl seems to work fine, but PyOpenGL not so much. PyOpenGL will treat a bald number as an array of length 1 with that value as the value in the array. You need to pass a GL.GLvoidp( offset ) to get it to treat the value as an offset pointer. If you are using the VBO class, you can pass your_VBO + offset as well. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
|
From: Henry G. <he...@ca...> - 2015-02-10 17:58:48
|
Apologies, just correcting the subject. |
|
From: Henry G. <he...@ca...> - 2015-02-10 17:43:41
|
Setting the last argument of glVertexAttribPointer (the pointer offset) to anything other than None seems to cause the vertex buffer to not work (at least, I don't seem to be able to render it - that's about as far as I'm competent to debug). Using pyglet.gl seems to work fine, but PyOpenGL not so much. Cheers, Henry |
|
From: Chris B. <chr...@no...> - 2015-01-28 06:33:40
|
On Tue, Jan 27, 2015 at 9:26 PM, Nicolas P. Rougier < Nic...@in...> wrote: > > Yes, glumpy is kind of personal laboratory for experiencing new rendering > techniques. In the end (next March), as in a couple months? or more than a year? But it looks like Glumpy is a good place to look for sample code, in any case. Thanks, -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... |
|
From: Nicolas P. R. <Nic...@in...> - 2015-01-28 05:26:50
|
Yes, glumpy is kind of personal laboratory for experiencing new rendering techniques. In the end (next March), everything that is in glumpy should be available in vispy as well. Nicolas > On 27 Jan 2015, at 23:44, Chris Barker <chr...@no...> wrote: > > Nicolas, > > It looks from docs like VisPY is kind of a next-generation Glumpy -- but is there still stuff in Glumpy that isn't in VisPy? > > -Chris > > > On Tue, Jan 27, 2015 at 2:33 PM, Nicolas P. Rougier <Nic...@in...> wrote: > > Maybe this tutorial can help you: > > http://www.labri.fr/perso/nrougier/teaching/opengl/ > > > Along with these two projects: > > * http://glumpy.github.io > * http://vispy.org > > > Nicolas > > > > On 27 Jan 2015, at 22:39, Chris Barker <chr...@no...> wrote: > > > > Sorry, I'm going to be really vague here, as it's been a while. > > > > glBegin() > > glVertex(...) > > [...] > > glEnd() > > > > is the "old" way, and you are right, you really don't want to do that. > > > > The "new" way is all the shader magic - it may be time to bite the bullet and learn that. > > > > But the semi-new way is to use Vertex Buffer OBjects (VBOs) to efficiently store your vertices on the Card. A little googling should get you started. > > > > -CHB > > > > > > > > On Tue, Jan 27, 2015 at 12:36 PM, Johannes Bauer <dfn...@gm...> wrote: > > Hello list, > > > > I'm trying to store objects (currently only vertices) on the graphics > > card so that I can avoid lots of: > > > > glBegin() > > glVertex(...) > > [...] > > glEnd() > > > > I've tried lots and lots of code now (none of which fully did what I > > wanted) and really am losing my mind soon :-( I could adapt this to work > > with my code: > > > > https://gist.github.com/MorganBorman/4243336 > > > > And it does work, but when integrated in my 3D environment I noticed > > that the drawn objects are not rendered perspectively, but just a flat > > object. > > > > I'm looking for the easiest way to dump a bunch of vertices onto the > > graphics card and later reference those vertices to draw some object and > > have it render as if I had used glBegin(), glVertex(), glEnd(). Is this > > possible at all? Which approach should I look into? > > > > In general I've seen two different approaches, one that involes (usually > > super-primitive) shaders, others do not. I do not see why I would need a > > custom-shader for this task, is this really necessary? > > > > My goal ultimately is to store surfaces (i.e. vertices, their normals, > > their texture UV coordinates) on the graphics card. > > > > Any help is greatly appreciated, > > Johannes > > > > ------------------------------------------------------------------------------ > > Dive into the World of Parallel Programming. The Go Parallel Website, > > sponsored by Intel and developed in partnership with Slashdot Media, is your > > hub for all things parallel software development, from weekly thought > > leadership blogs to news, videos, case studies, tutorials and more. Take a > > look and join the conversation now. http://goparallel.sourceforge.net/ > > _______________________________________________ > > 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... > > ------------------------------------------------------------------------------ > > Dive into the World of Parallel Programming. The Go Parallel Website, > > sponsored by Intel and developed in partnership with Slashdot Media, is your > > hub for all things parallel software development, from weekly thought > > leadership blogs to news, videos, case studies, tutorials and more. Take a > > look and join the conversation now. http://goparallel.sourceforge.net/_______________________________________________ > > 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... |
|
From: Chris B. <chr...@no...> - 2015-01-27 22:45:19
|
Nicolas, It looks from docs like VisPY is kind of a next-generation Glumpy -- but is there still stuff in Glumpy that isn't in VisPy? -Chris On Tue, Jan 27, 2015 at 2:33 PM, Nicolas P. Rougier < Nic...@in...> wrote: > > Maybe this tutorial can help you: > > http://www.labri.fr/perso/nrougier/teaching/opengl/ > > > Along with these two projects: > > * http://glumpy.github.io > * http://vispy.org > > > Nicolas > > > > On 27 Jan 2015, at 22:39, Chris Barker <chr...@no...> wrote: > > > > Sorry, I'm going to be really vague here, as it's been a while. > > > > glBegin() > > glVertex(...) > > [...] > > glEnd() > > > > is the "old" way, and you are right, you really don't want to do that. > > > > The "new" way is all the shader magic - it may be time to bite the > bullet and learn that. > > > > But the semi-new way is to use Vertex Buffer OBjects (VBOs) to > efficiently store your vertices on the Card. A little googling should get > you started. > > > > -CHB > > > > > > > > On Tue, Jan 27, 2015 at 12:36 PM, Johannes Bauer <dfn...@gm...> > wrote: > > Hello list, > > > > I'm trying to store objects (currently only vertices) on the graphics > > card so that I can avoid lots of: > > > > glBegin() > > glVertex(...) > > [...] > > glEnd() > > > > I've tried lots and lots of code now (none of which fully did what I > > wanted) and really am losing my mind soon :-( I could adapt this to work > > with my code: > > > > https://gist.github.com/MorganBorman/4243336 > > > > And it does work, but when integrated in my 3D environment I noticed > > that the drawn objects are not rendered perspectively, but just a flat > > object. > > > > I'm looking for the easiest way to dump a bunch of vertices onto the > > graphics card and later reference those vertices to draw some object and > > have it render as if I had used glBegin(), glVertex(), glEnd(). Is this > > possible at all? Which approach should I look into? > > > > In general I've seen two different approaches, one that involes (usually > > super-primitive) shaders, others do not. I do not see why I would need a > > custom-shader for this task, is this really necessary? > > > > My goal ultimately is to store surfaces (i.e. vertices, their normals, > > their texture UV coordinates) on the graphics card. > > > > Any help is greatly appreciated, > > Johannes > > > > > ------------------------------------------------------------------------------ > > Dive into the World of Parallel Programming. The Go Parallel Website, > > sponsored by Intel and developed in partnership with Slashdot Media, is > your > > hub for all things parallel software development, from weekly thought > > leadership blogs to news, videos, case studies, tutorials and more. Take > a > > look and join the conversation now. http://goparallel.sourceforge.net/ > > _______________________________________________ > > 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... > > > ------------------------------------------------------------------------------ > > Dive into the World of Parallel Programming. The Go Parallel Website, > > sponsored by Intel and developed in partnership with Slashdot Media, is > your > > hub for all things parallel software development, from weekly thought > > leadership blogs to news, videos, case studies, tutorials and more. Take > a > > look and join the conversation now. > http://goparallel.sourceforge.net/_______________________________________________ > > 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... |
|
From: Nicolas P. R. <Nic...@in...> - 2015-01-27 22:33:09
|
Maybe this tutorial can help you: http://www.labri.fr/perso/nrougier/teaching/opengl/ Along with these two projects: * http://glumpy.github.io * http://vispy.org Nicolas > On 27 Jan 2015, at 22:39, Chris Barker <chr...@no...> wrote: > > Sorry, I'm going to be really vague here, as it's been a while. > > glBegin() > glVertex(...) > [...] > glEnd() > > is the "old" way, and you are right, you really don't want to do that. > > The "new" way is all the shader magic - it may be time to bite the bullet and learn that. > > But the semi-new way is to use Vertex Buffer OBjects (VBOs) to efficiently store your vertices on the Card. A little googling should get you started. > > -CHB > > > > On Tue, Jan 27, 2015 at 12:36 PM, Johannes Bauer <dfn...@gm...> wrote: > Hello list, > > I'm trying to store objects (currently only vertices) on the graphics > card so that I can avoid lots of: > > glBegin() > glVertex(...) > [...] > glEnd() > > I've tried lots and lots of code now (none of which fully did what I > wanted) and really am losing my mind soon :-( I could adapt this to work > with my code: > > https://gist.github.com/MorganBorman/4243336 > > And it does work, but when integrated in my 3D environment I noticed > that the drawn objects are not rendered perspectively, but just a flat > object. > > I'm looking for the easiest way to dump a bunch of vertices onto the > graphics card and later reference those vertices to draw some object and > have it render as if I had used glBegin(), glVertex(), glEnd(). Is this > possible at all? Which approach should I look into? > > In general I've seen two different approaches, one that involes (usually > super-primitive) shaders, others do not. I do not see why I would need a > custom-shader for this task, is this really necessary? > > My goal ultimately is to store surfaces (i.e. vertices, their normals, > their texture UV coordinates) on the graphics card. > > Any help is greatly appreciated, > Johannes > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > 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... > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/_______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users |
|
From: Chris B. <chr...@no...> - 2015-01-27 21:39:49
|
Sorry, I'm going to be really vague here, as it's been a while. glBegin() glVertex(...) [...] glEnd() is the "old" way, and you are right, you really don't want to do that. The "new" way is all the shader magic - it may be time to bite the bullet and learn that. But the semi-new way is to use Vertex Buffer OBjects (VBOs) to efficiently store your vertices on the Card. A little googling should get you started. -CHB On Tue, Jan 27, 2015 at 12:36 PM, Johannes Bauer <dfn...@gm...> wrote: > Hello list, > > I'm trying to store objects (currently only vertices) on the graphics > card so that I can avoid lots of: > > glBegin() > glVertex(...) > [...] > glEnd() > > I've tried lots and lots of code now (none of which fully did what I > wanted) and really am losing my mind soon :-( I could adapt this to work > with my code: > > https://gist.github.com/MorganBorman/4243336 > > And it does work, but when integrated in my 3D environment I noticed > that the drawn objects are not rendered perspectively, but just a flat > object. > > I'm looking for the easiest way to dump a bunch of vertices onto the > graphics card and later reference those vertices to draw some object and > have it render as if I had used glBegin(), glVertex(), glEnd(). Is this > possible at all? Which approach should I look into? > > In general I've seen two different approaches, one that involes (usually > super-primitive) shaders, others do not. I do not see why I would need a > custom-shader for this task, is this really necessary? > > My goal ultimately is to store surfaces (i.e. vertices, their normals, > their texture UV coordinates) on the graphics card. > > Any help is greatly appreciated, > Johannes > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > 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... |
74 messages has been excluded from this view by a project administrator.
