Thread: [PyOpenGL-Users] glDrawRangeElements, GL_MAX_ELEMENTS_VERTICES & GL_MAX_ELEMENTS_INDICES
Brought to you by:
mcfletch
From: <ba...@fr...> - 2003-12-14 11:42:18
|
hi, i wanted to use glDrawRangeElements, so i have to know what are the value= s of glGetIntegerv(GL_MAX_ELEMENTS_VERTICES) and glGetIntegerv(GL_MAX_ELEMENTS_INDICES)... but these keywords appear to be unknown to my pyOpenGl... a grep in the pyOpenGL directory gives no resul= t (although a grep in the GL-includes demonstrates that these keywords are presents in my GL.h). I know this functionnality are new in OpenGL1.3, but if this functionnali= ty is documented, what's the difficulty ? PB |
From: Andrew S. <as...@in...> - 2003-12-14 13:22:48
|
Check this thread out: http://sourceforge.net/mailarchive/message.php?msg_id=6131991 (Note the continuations seem to be a month later!) I think we should implement a Python runtime check for OpenGL version number and modify the namespace accordingly. Too bad I don't have time for the next several months, at least! Cheers! Andrew On Sunday, Dec 14, 2003, at 22:12 Australia/Adelaide, <ba...@fr...> wrote: > hi, > i wanted to use glDrawRangeElements, so i have to know what are the > values > of glGetIntegerv(GL_MAX_ELEMENTS_VERTICES) and > glGetIntegerv(GL_MAX_ELEMENTS_INDICES)... but these keywords appear to > be > unknown to my pyOpenGl... a grep in the pyOpenGL directory gives no > result > (although a grep in the GL-includes demonstrates that these keywords > are > presents in my GL.h). > I know this functionnality are new in OpenGL1.3, but if this > functionnality > is documented, what's the difficulty ? > > > PB > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > 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...@ro...> - 2003-12-14 22:05:46
|
Andrew Straw wrote: > Check this thread out: > > http://sourceforge.net/mailarchive/message.php?msg_id=6131991 > > (Note the continuations seem to be a month later!) > > I think we should implement a Python runtime check for OpenGL version > number and modify the namespace accordingly. Too bad I don't have > time for the next several months, at least! Hmm, I think that would require that the system used to build the binary have up to 1.3/1.4 available in it's library, wouldn't it? The wrappers are generated for each version of OpenGL present in the platform's OpenGL library. Without those libraries I can't see how to compile the wrappers. I may be missing something, though. Would be nice to get a 1.4 windows DLL to test all these hypothetically supported features :) . Anyway, to the OP, for this particular case, it's quite easy just to use the numeric values for the GL_MAX_ELEMENTS_VERTICES constants. Not a solution, but a work-around. Take care, Mike > > Cheers! > > Andrew > ... >> I know this functionnality are new in OpenGL1.3, but if this >> functionnality >> is documented, what's the difficulty ? >> >> >> PB > ... |
From: Andrew S. <as...@in...> - 2003-12-15 02:21:16
|
> Andrew Straw wrote: > >> Check this thread out: >> >> http://sourceforge.net/mailarchive/message.php?msg_id=6131991 >> >> (Note the continuations seem to be a month later!) >> >> I think we should implement a Python runtime check for OpenGL version >> number and modify the namespace accordingly. Too bad I don't have >> time for the next several months, at least! > > Hmm, I think that would require that the system used to build the binary > have up to 1.3/1.4 available in it's library, wouldn't it? The wrappers > are generated for each version of OpenGL present in the platform's > OpenGL library. Without those libraries I can't see how to compile the > wrappers. I may be missing something, though. I think you're mainly right, although with dynamic library access using something like ctypes, it should be possible using just a header file, not necessarily the lib. (Although with ctypes, as you pointed out before, this may be a bit slow.) I guess this mimcs the present situation of building on a platform with 1.2 binaries but running on a 1.1 platform. We really should implement some sort of runtime version check to limit the namespace, at least, because it's rather confusing to have a bunch of 1.2 symbols available when your system is only 1.1. |