Re: [PyOpenGL-Users] PyOpenGL Deprecation & New Methods

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

Greg Ewing wrote:
> Mike C. Fletcher wrote:
>
>   
>> For the broader OpenGL market, VBOs, FBOs, PBOs and shaders are a more
>> open-ended solutions.
>>     
>
> You're speaking as if VBOs/shaders and display lists are
> mutually exclusive, but they're not. You can put all your
> vertex data into VBOs, and compile calls using the VBOs,
> along with switching shaders and textures etc., into the
> display lists.
>
> There are certainly limits to what can be achieved that
> way, but in a Python context it's still a very useful tool
> to have available, IMO.
>   
Sure, but the key there is "in a Python context", other languages have
compilers that give them native speed *without* needing display lists. 
Since display lists are just implemented in the driver using C, the
general 3d programming populace, the "broader OpenGL market", who almost
exclusively use C/C++ for programming OpenGL, has no particular use for
them.  They can get exactly the same speed by just writing code to make
the OpenGL calls in C/C++ and they don't have to worry about
display-list restrictions or anything else.  OpenGL is deprecating this
functionality because for the broader market (read C programmers) it is
of little or no use.

There's absolutely nothing stopping you from creating a display-list
implementation for Python, but when you sit down to do it... well...
it's close to the same amount of work as creating a scenegraph engine
that does what you want with direct C-level calls at native speed...
which can be as flexible and optimized as you need for your particular
rendering task and can do frustum culling, LOD-ing and the like while
it's rendering rather than being restricted to always playing back the
same sequence of commands.  There's likely a "market" for such a library
among, for instance, PyOpenGL's traditional users, but the OpenGL ARB
isn't interested in that market segment AFAICS.

Just trying to explain why it seems to be happening... I have no input
or special insight into the ARB's decision processes,
Mike

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