batch best practices?

[B W]

Howdy again.

Would anyone happen to have collected or written any best practices docs, examples, or utilities for working with batches and groups, or simply have any fundamental tips?

Reason I ask is that my first attempt, built upon the brief description in the Pyglet programming guide, resulted in many subclasses of graphics.Group and some hairy problems like how to elegantly insert translations for a group of textures. For example, a cube made out of six quads.

I ended up doing something like this:

        # Add hierarchical group to batch (init the modes, lights, and transformations)
        group = TextureEnableGroup(parent=
            LightingOnGroup(parent=
                ShadeModelGroup(parent=
                    TranslationGroup(parent=pyglet.graphics.OrderedGroup(0))))
        batch.add(1, 0, group, '0g1f')
        group = TextureBindGroup(parent=
            pyglet.graphics.OrderedGroup(1))
        # add cube vertex lists to batch
        for name in cube_sides:  # 'top', 'front', etc.
            verts = cube_sides[name]
            norms = cube_normals[name]
            texcoords = cube_tex_coords[name]
            batch.add(len(verts), GL_QUAD, group,
                # vertex list specs...
            )
        # Add hierarchical group to batch (Unset-modes in the same manner as the first group)

Hope that conveys the general idea. If not, I've uploaded the full program here:
http://worldkit.googlecode.com/files/block_vs_group.zip -- see class ShadedCubeScene or TexturedCubeScene.

Initially, I found it unwieldy to specify one polygon just to init the modes via a hierarchical group, all but one polygon in a loop for economy, and the final polygon to unset the modes via another group. What if I only had one polygon, I'd be SOL. :) So naturally I wonder how it's typically done.

Grasping for ideas, I discovered that Pyglet batches would let me add an empty generic vertex attribute with a group that simply changes state, as shown above. I have no idea what the generic vertex attributes are intended for, and half expect the practice might be considered an abuse. Would anyone comment on this, please?

Also, if anyone has the guts to dig into my noob code I would greatly appreciate his/her constructive feedback. =) If I'm doing anything particularly wrong, I'd prefer to nip the bad habit in the bud. (And you'll notice light and shadow are a work in progress.)

Thanks in advance for your sage advice! :)

Gumm

[B W]

Maybe "best" practice is aiming too high.

Does anyone even have a personal opinion on, or have good/bad experiences with using graphics.Group to wrap vertex lists in a batch for turning GL states on/off, or insert nested rotations, translations, etc.? What works well, what doesn't?

I'm wondering what the Pyglet designer(s) envisioned; because these are fundamentally necessary actions, even for something as simple as a moon orbiting a planet.

And what is the intent of the generic vertex list attributes? Can I use them like I did in the block demo?

Gumm

[B W]

http://groups.google.com/group/pyglet-users/browse_thread/thread/3e9b5d96f98fd66b/1b82c05c22096e96?hl=en&lnk=gst&q=batch+group#1b82c05c22096e96

After a day of reading through previous pyglet-users posts I just found this topic about zero-length vertex lists from 11/2008. Any estimate on when Pyglet 1.2, Alex? =) I will try the trunk version. But developing against pre-release builds is, in my humble opinion, not always a good choice.

Gumm

[Tristam MacDonald]

On Wed, Oct 27, 2010 at 10:24 AM, B W <stabbin...@gmail.com> wrote:

http://groups.google.com/group/pyglet-users/browse_thread/thread/3e9b5d96f98fd66b/1b82c05c22096e96?hl=en&lnk=gst&q=batch+group#1b82c05c22096e96

After a day of reading through previous pyglet-users posts I just found this topic about zero-length vertex lists from 11/2008. Any estimate on when Pyglet 1.2, Alex? =) I will try the trunk version. But developing against pre-release builds is, in my humble opinion, not always a good choice.

Gumm

I was fairly sure that this fix had made it into versions 1.1.4 (the current stable version) - if it was committed to trunk in all the way back in Nov 2008, then it definitely should have been.

Have you actually tried to use a zero-length vertex list?

On Wed, Oct 27, 2010 at 6:51 AM, B W <stabbin...@gmail.com> wrote:

Does anyone even have a personal opinion on, or have good/bad experiences with using graphics.Group to wrap vertex lists in a batch for turning GL states on/off, or insert nested rotations, translations, etc.? What works well, what doesn't?

I'm wondering what the Pyglet designer(s) envisioned; because these are fundamentally necessary actions, even for something as simple as a moon orbiting a planet.

This kind of "hierarchical management" was very popular in graphics engines, a long time ago. Since then, most people have reallised that many things are better managed outside of the graphics engine. To go with your example, a moon orbiting a planet is better dealt with as a physics problem than a graphics problem.
 

And what is the intent of the generic vertex list attributes? Can I use them like I did in the block demo?

Generic vertex list attributes are designed to support shaders. If you aren't using shaders, you can safely ignore them (but you probably should be using shaders...)

--
Tristam MacDonald
http://swiftcoder.wordpress.com/

[B W]

Hi, Tristam. Thanks for your reply.

On Wed, Oct 27, 2010 at 7:42 AM, Tristam MacDonald <swift...@gmail.com> wrote:

On Wed, Oct 27, 2010 at 10:24 AM, B W <stabbin...@gmail.com> wrote:

http://groups.google.com/group/pyglet-users/browse_thread/thread/3e9b5d96f98fd66b/1b82c05c22096e96?hl=en&lnk=gst&q=batch+group#1b82c05c22096e96

After a day of reading through previous pyglet-users posts I just found this topic about zero-length vertex lists from 11/2008. Any estimate on when Pyglet 1.2, Alex? =) I will try the trunk version. But developing against pre-release builds is, in my humble opinion, not always a good choice.

Gumm

I was fairly sure that this fix had made it into versions 1.1.4 (the current stable version) - if it was committed to trunk in all the way back in Nov 2008, then it definitely should have been.

Have you actually tried to use a zero-length vertex list?

A zero length list was the first thing I tried. For example,

    v = batch.add(0, 0, group, 'v2f')

gets me this:

[...]
  File "C:\Python26\Lib\site-packages\pyglet\graphics\vertexdomain.py", line 219, in _safe_alloc
    return self.allocator.alloc(count)
  File "C:\Python26\Lib\site-packages\pyglet\graphics\allocation.py", line 145, in alloc
    assert size > 0
AssertionError

Same thing happens if I use a valid geometry type like GL_QUADS.
 
This is with Pyglet 1.1.4.

On Wed, Oct 27, 2010 at 6:51 AM, B W <stabbin...@gmail.com> wrote:

Does anyone even have a personal opinion on, or have good/bad experiences with using graphics.Group to wrap vertex lists in a batch for turning GL states on/off, or insert nested rotations, translations, etc.? What works well, what doesn't?

I'm wondering what the Pyglet designer(s) envisioned; because these are fundamentally necessary actions, even for something as simple as a moon orbiting a planet.

This kind of "hierarchical management" was very popular in graphics engines, a long time ago. Since then, most people have reallised that many things are better managed outside of the graphics engine. To go with your example, a moon orbiting a planet is better dealt with as a physics problem than a graphics problem.

I agree (I think, but I acknowledge the possibility that we're on different wavelengths). I had planned to do the physics in the update() cycles, and apply them to the group; where the group would be a subclass that exposed a method to set some thing like rotation or translation.

The only other seemingly sound idea I had was to have a number of batches, basically one for each sphere/cube/running man arm/leg/etc., and churn through the many batches in on_draw(). This seemed not so object oriented and elegant, though. And there's the overhead of potentially many function calls.

So what's the upshot: are people really only using graphics.OrderedGroup to sequence their batches, and wrapping the batch calls in immediate mode glEnable/glDisable/glPushMatrix/glPopMatrix calls in on_draw()?
 

And what is the intent of the generic vertex list attributes? Can I use them like I did in the block demo?

Generic vertex list attributes are designed to support shaders. If you aren't using shaders, you can safely ignore them (but you probably should be using shaders...)

Curses. I haven't even looked at shaders yet. :)

Gumm

[Tristam MacDonald]

On Wed, Oct 27, 2010 at 11:04 PM, B W <stabbin...@gmail.com> wrote:

So what's the upshot: are people really only using graphics.OrderedGroup to sequence their batches, and wrapping the batch calls in immediate mode glEnable/glDisable/glPushMatrix/glPopMatrix calls in on_draw()?

This is all legacy stuff: Enable/Disable go away when you move to shaders, Push/PopMatrix go away with OpenGL 3+... I haven't ever used the fixed-function pipeline in Pyglet (beyond the examples in the distribution), so I can't help you much with that.

Once one moves to shaders, it is much simplified: you bind a shader, bind the necessary textures, update the uniform matrices and draw the batch. Rinse and repeat - it is well suited to encapsulating in single class.

[Jonathan Hartley]

> Curses. I haven't even looked at shaders yet. :)
>
> Gumm

I put off looking at shaders for years, thinking that there was plenty
in OpenGL that I hadn't figured out yet, so why add even further to
the complications? When I finally sat down to figure shaders out, I
wished I had done it right from the start. As Tristam says, some
things turn out simpler.

Personally, I used the OpenGL Orange Book to get me started on
shaders, although be warned that, like the other official OpenGL
books, it does focus on the theory of OpenGL-the-interface too much at
some times, completely ignoring all details of any particular
implementation. This gives it a timeless relevance, but mean that it
does things like describe in loving detail functions which exist in
the spec but are not actually implemented by most graphics cards/
drivers (e.g. perlin noise generators.)

I just ordered the OpenGL SuperBible this week. I understand the
latest 5th edition is now written entirely in an 'opengl 3 using
shaders' style.

[Casey Duncan]

One thing to bear in mind with shaders is that they will greatly
diminish portability. Many portable graphics chipsets in the wild have
little or no support for them. And, like programming for the browser
in javascript, there are very annoying bugs that vary from chipset to
chipset. Also, some implementations of shaders are done in software
(e.g., older MacBooks/iBooks) thus performance can vary a lot.

So if you plan to distribute your application, be prepared for those issues.

One way to get good portability, and still take advantage of newer
OpenGL features, is to make everything work against the OpenGL ES
feature set, which is a sort of lowest common denominator. Then layer
on shaders and whatnot in a way that they can degrade gracefully when
they aren't available or fully implemented. That may be more
complicated overall than just using shaders for everything, but it can
be implemented in stages.

-Casey

> --
> You received this message because you are subscribed to the Google Groups "pyglet-users" group.
> To post to this group, send email to pyglet...@googlegroups.com.
> To unsubscribe from this group, send email to pyglet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
>
>

[Tristam MacDonald]

On Thu, Oct 28, 2010 at 11:21 AM, Casey Duncan <casey....@gmail.com> wrote:

One thing to bear in mind with shaders is that they will greatly
diminish portability.

I don't know that 'portability' is a good term for it - shaders certainly will raise your minimum requirements for simple games, however.
 

Many portable graphics chipsets in the wild have
little or no support for them.

My experience is that those chipsets have not enough fixed-function power to do anything significant with - I ended up at the performance ceiling of my Intel chipset even for a moderately complex fixed-function game.

Also worth mentioning that some integrated chipsets (i.e. Intel's X3100 present in older MacBooks), are actually *faster* using shaders...
 

And, like programming for the browser
in javascript, there are very annoying bugs that vary from chipset to
chipset.

Most of these are however in low-end Intel integrated chipsets, and very old Radeon discrete parts, so raising your minimum spec takes care of those as well. On the software side, driver bugs bite fixed-function at least as often (and usually more often) as they do shaders.
 

Also, some implementations of shaders are done in software
(e.g., older MacBooks/iBooks) thus performance can vary a lot.

The GMA 950 in the original MacBook and most older netbooks does have hardware support for pixel shaders - only vertex shaders are emulated in software. Since pixel shaders usually comprise the bulk of the work, this isn't actually as bad as it sounds.

However, if you want to get into shaders, you want to use GLSL (preferably OpenGL 2+), so that rules out the GMA 950 anyway.

 

One way to get good portability, and still take advantage of newer
OpenGL features, is to make everything work against the OpenGL ES
feature set, which is a sort of lowest common denominator. Then layer
on shaders and whatnot in a way that they can degrade gracefully when
they aren't available or fully implemented.

Sadly, it doesn't work like that. OpenGL ES has only been bridged over to core OpenGL in the latest versions (effectively versions 4+), and these versions are bridged to ES2.0, which has *no* fixed-function support.

ES1.0 does have fixed function support, but it has no shader support and is not forward-compatible with ES 2.0.

[Casey Duncan]

On Thu, Oct 28, 2010 at 11:27 AM, Tristam MacDonald
<swift...@gmail.com> wrote:
> On Thu, Oct 28, 2010 at 11:21 AM, Casey Duncan <casey....@gmail.com>
> wrote:
>>
>> One thing to bear in mind with shaders is that they will greatly
>> diminish portability.
>
> I don't know that 'portability' is a good term for it - shaders certainly
> will raise your minimum requirements for simple games, however.

meaning the number of "platforms" that will run your game/app.

>> Many portable graphics chipsets in the wild have
>> little or no support for them.
>
> My experience is that those chipsets have not enough fixed-function power to
> do anything significant with - I ended up at the performance ceiling of my
> Intel chipset even for a moderately complex fixed-function game.
>
> Also worth mentioning that some integrated chipsets (i.e. Intel's X3100
> present in older MacBooks), are actually *faster* using shaders...

fair enough.

>> And, like programming for the browser
>> in javascript, there are very annoying bugs that vary from chipset to
>> chipset.
>
> Most of these are however in low-end Intel integrated chipsets, and very old
> Radeon discrete parts, so raising your minimum spec takes care of those as
> well. On the software side, driver bugs bite fixed-function at least as
> often (and usually more often) as they do shaders.

I agree that raising the minimum platform requirements is a fine
solution. Just wanted to point out that it may be necessary.

>> Also, some implementations of shaders are done in software
>> (e.g., older MacBooks/iBooks) thus performance can vary a lot.
>
> The GMA 950 in the original MacBook and most older netbooks does have
> hardware support for pixel shaders - only vertex shaders are emulated in
> software. Since pixel shaders usually comprise the bulk of the work, this
> isn't actually as bad as it sounds.
>
> However, if you want to get into shaders, you want to use GLSL (preferably
> OpenGL 2+), so that rules out the GMA 950 anyway.

Right, there are lots of GMA 950 machines out there, but as you say
getting any decent measure of performance from them is problematic.

>> One way to get good portability, and still take advantage of newer
>> OpenGL features, is to make everything work against the OpenGL ES
>> feature set, which is a sort of lowest common denominator. Then layer
>> on shaders and whatnot in a way that they can degrade gracefully when
>> they aren't available or fully implemented.
>
> Sadly, it doesn't work like that. OpenGL ES has only been bridged over to
> core OpenGL in the latest versions (effectively versions 4+), and these
> versions are bridged to ES2.0, which has *no* fixed-function support.
>
> ES1.0 does have fixed function support, but it has no shader support and is
> not forward-compatible with ES 2.0.

I guess I was generalizing too much. My point was to start with
things like VBOs and whatnot using fixed-function
texturing and lighting (if necessary). Wholly avoid stuff like
immediate mode and display lists, though I have to admit
that I still like the latter ;^)

What generally sucks about OpenGL support is that many cards/chipsets
claim to support specific versions, yet do not
necessarily fully implement them. Makes the whole thing a lot more
frustrating that it needs to be IMO. But that's what
happens when you channel a standards-committee through a marketing dept.

-Casey

[Richard Jones]

On Thu, Oct 28, 2010 at 7:40 PM, Jonathan Hartley <tar...@tartley.com> wrote:
> I just ordered the OpenGL SuperBible this week. I understand the
> latest 5th edition is now written entirely in an 'opengl 3 using
> shaders' style.

Thanks for this tip - but sadly I have discovered through the OpenGL
Extensions Viewer (http://www.realtech-vr.com/glview/download.html via
the SuperBible site) that my MacBook (GeForce 9400M) doesn't have
support for the minimum of OpenGL 3.2 required by the 5th edition :-(

Apparently I have OpenGL 2.1 fully supported (shading language 1.20)
and *some* features of 2.0, 2.1 and 3.2. Nothing beyond that :-(

I'd still like to investigate this new world of shaders and ditching
the fixed function pipeline, but now I'm not sure it's a good idea.
What sorts of things could I reasonably replace, given the low level
of support I have?

Richard

[B W]

On Thu, Oct 28, 2010 at 10:27 AM, Tristam MacDonald <swift...@gmail.com> wrote:

However, if you want to get into shaders, you want to use GLSL (preferably OpenGL 2+), so that rules out the GMA 950 anyway.

I seem to recall someone--maybe you, Tristam?--wrote a Python binding for GLSL.

There is also one here: http://code.google.com/p/pyglet-shaders/

Could you recommend a good choice for a beginner?

Gumm

[Richard Jones]

On Fri, Oct 29, 2010 at 11:23 AM, Richard Jones <r1char...@gmail.com> wrote:
> Apparently I have OpenGL 2.1 fully supported (shading language 1.20)
> and *some* features of 2.0, 2.1 and 3.2. Nothing beyond that :-(

Wow, that came out completely wrong. It should have said I have some
features of 3.0, 3.1 and 3.2.

Apparently this is an OS X issue across the board, not specific to my hardware.

Richard

[Tristam MacDonald]

Ja, Apple never rolled out full OpenGL 3 support. We were hoping for it in Snow Leopard, but rumour has it that they will go straight to OpenGL 4 support in Lion - we can dream at least...

However, OpenGL 3 is basically a rolling-in-to-core of extensions against OpenGL 2, and almost all of those extensions are present on your 9400 (though Apple misses/renames a couple). You should be absolutely fine targeting version 3 features on that hardware.

However, has anyone brought pyglet up to date with OpenGL 3? Last I checked we didn't have OpenGL 3 functions generated...

[Andreas Schiefer]

On 29 Okt., 04:04, Tristam MacDonald <swiftco...@gmail.com> wrote:
> However, has anyone brought pyglet up to date with OpenGL 3? Last I checked
> we didn't have OpenGL 3 functions generated...

I've updated the OpenGL bindings of pyglet a while ago (on your
request, see http://groups.google.com/group/pyglet-users/browse_thread/thread/0f83b02417c268a0#).
So all OpenGL 3.x functions should be already available in pyglet-
trunk. Due to the lack of OpenGL 3.x support on my laptop, I've not
tried them myself (just checked if some of them are defined in
pyglet.gl).


Andy

[Jonathan Hartley]

On Oct 29, 1:23 am, Richard Jones <r1chardj0...@gmail.com> wrote:

Gah! I hadn't realised Superbible explicitly requires OpenGL 3.2. My
own personal linux/XP laptop is also at OpenGL 2.1. I figured I might
have to wing it around some parts where Superbible requires newer
OpenGL than that, but since I have VBOs and shaders, I had anticipated
this wouldn't amount to much. Maybe I was wrong. We shall see.

[Jonathan Hartley]

On Oct 29, 1:30 am, B W <stabbingfin...@gmail.com> wrote:

> On Thu, Oct 28, 2010 at 10:27 AM, Tristam MacDonald <swiftco...@gmail.com>wrote:
>
>
>
> > However, if you want to get into shaders, you want to use GLSL (preferably
> > OpenGL 2+), so that rules out the GMA 950 anyway.
>
> > I seem to recall someone--maybe you, Tristam?--wrote a Python binding for
>
> GLSL.
>
> There is also one here:http://code.google.com/p/pyglet-shaders/
>
> Could you recommend a good choice for a beginner?
>
> Gumm

I'm the author of the pyglet-shaders repo linked above. It works great
for my uses, but only has a basic useage in mind, i.e. it's good for
loading and compiling one vertex shader and one fragment shader,
binding them at the start of the program, and using them for
everything the program does. Presumably it could be cajoled into using
different shaders for different draw calls without too much trouble,
but I personally haven't done that.

I wrote it mostly for my own education, based upon looking at other
people's shader code, which I generally found by searching
code.google.com for python and the appropriate shader-compiling opengl
calls.

Jonathan

[Jonathan Hartley]

On reflection, there shader-wrapping code in PyOpenGL, which is far
better than my pyglet-shaders repo.

PyOpenGL's equivalent covers a much broader set of use cases (caters
to binding uniform variables, etc, which I didn't even attempt)

Also, it is well-documented:
http://pyopengl.sourceforge.net/documentation/pydoc/OpenGL.GL.shaders.html

And comes with a shaders-from-pyopengl tutorial:
http://pyopengl.sourceforge.net/context/tutorials/index.xhtml

I have long wanted to sit down and work through this tutorial, and by
co-incidence I have carved out time to do it this coming week. If
anyone else wants to work through it in parallel and email each other
our questions, observations and show-off our respective working code,
then I'd love to do that.

Jonathan

[Richard Jones]

For what it's worth I've ordered a copy anyway (the Aussie dollar
being so high it's hard to resist impulse buying books like this ;-)
so I'll soon be finding out how practical it is to apply its methods
to 2.1 as well.... altho it'd be really nice if Apple just supported
OpenGL 3 :-)

Richard

[Jonathan Hartley]

On Oct 29, 12:23 pm, Jonathan Hartley <tart...@tartley.com> wrote:
> PyOpenGL's equivalent covers a much broader set of use cases (caters
> to binding uniform variables, etc, which I didn't even attempt)
>

> Also, it is well-documented:http://pyopengl.sourceforge.net/documentation/pydoc/OpenGL.GL.shaders...

>
> And comes with a shaders-from-pyopengl tutorial:http://pyopengl.sourceforge.net/context/tutorials/index.xhtml
>
> I have long wanted to sit down and work through this tutorial, and by
> co-incidence I have carved out time to do it this coming week. If
> anyone else wants to work through it in parallel and email each other
> our questions, observations and show-off our respective working code,
> then I'd love to do that.
>
>   Jonathan

For the record, I'm working through these pyopengl tutorials right
now. In case anyone else with old hardware is considering it, you
should know:

It's all been plain sailing up until the seventh tutorial, which adds
multiple light sources:
http://pyopengl.sourceforge.net/context/tutorials/shader_7.xhtml

The shaders fail to link for me, with:

Fragment shader not supported by HW.

I'm assuming this is because my OpenGL 2.1 hardware can't deal with
GLSL uniforms which are arrays - which are introduced for the first
time in this tutorial. I've modified the tutorial source code to use a
bunch of explicitly declared scalar uniforms instead of the array, and
unrolled the loops that iterate on the arrays:
https://bitbucket.org/tartley/tutorials/src/tip/pyopengl/06-multiple-lights.py

This works, but it's considerably slowed my progress.

Jonathan

[Tristam MacDonald]

On Sun, Oct 31, 2010 at 7:50 PM, Jonathan Hartley <tar...@tartley.com> wrote:

I'm assuming this is because my OpenGL 2.1 hardware can't deal with
GLSL uniforms which are arrays - which are introduced for the first
time in this tutorial. I've modified the tutorial source code to use a
bunch of explicitly declared scalar uniforms instead of the array, and
unrolled the loops that iterate on the arrays:
https://bitbucket.org/tartley/tutorials/src/tip/pyopengl/06-multiple-lights.py

This works, but it's considerably slowed my progress.

What hardware are you running? And what OS/drivers?

I seem to recall that this was a common ATI driver issue on 2.1-era hardware. 

[Ben Smith]

In hopes that it's useful, the 4th Edition of the SuperBible covers
2.1 stuff. 5th Ed is a rewrite without deprecated bits.

I hacked together a bunch of the examples from 4th edition in pyglet
at http://github.com/BenSmith/PythonOpenGLSuperBible4 - still needs
work, I used to have more free time. Maybe it can help build a bridge
between old and new, even if some of it renders upside-down.

-b


On Oct 29, 1:59 pm, Richard Jones <r1chardj0...@gmail.com> wrote:

[Jonathan Hartley]

On Nov 1, 12:30 am, Tristam MacDonald <swiftco...@gmail.com> wrote:

> On Sun, Oct 31, 2010 at 7:50 PM, Jonathan Hartley <tart...@tartley.com>wrote:
>
> > I'm assuming this is because my OpenGL 2.1 hardware can't deal with
> > GLSL uniforms which are arrays - which are introduced for the first
> > time in this tutorial. I've modified the tutorial source code to use a
> > bunch of explicitly declared scalar uniforms instead of the array, and
> > unrolled the loops that iterate on the arrays:
>

> >https://bitbucket.org/tartley/tutorials/src/tip/pyopengl/06-multiple-...

>
> > This works, but it's considerably slowed my progress.
>
> What hardware are you running? And what OS/drivers?
>
> I seem to recall that this was a common ATI driver issue on 2.1-era
> hardware.
>
> --
> Tristam MacDonaldhttp://swiftcoder.wordpress.com/

You're spot-on - thanks for the confirmation. I'm on ATI Mobile Radeon
X1400. Not the first time I've bumped up against its limitations while
noodling around with graphics. I really should get a new laptop.

[Jonathan Hartley]

On Nov 1, 12:30 am, Tristam MacDonald <swiftco...@gmail.com> wrote:

> On Sun, Oct 31, 2010 at 7:50 PM, Jonathan Hartley <tart...@tartley.com>wrote:
>
> > I'm assuming this is because my OpenGL 2.1 hardware can't deal with
> > GLSL uniforms which are arrays - which are introduced for the first
> > time in this tutorial. I've modified the tutorial source code to use a
> > bunch of explicitly declared scalar uniforms instead of the array, and
> > unrolled the loops that iterate on the arrays:
>

> >https://bitbucket.org/tartley/tutorials/src/tip/pyopengl/06-multiple-...

>
> > This works, but it's considerably slowed my progress.
>
> What hardware are you running? And what OS/drivers?
>
> I seem to recall that this was a common ATI driver issue on 2.1-era
> hardware.
>
> --

[B W]

On Sun, Oct 31, 2010 at 4:50 PM, Jonathan Hartley <tar...@tartley.com> wrote:

For the record, I'm working through these pyopengl tutorials right
now. In case anyone else with old hardware is considering it, you
should know:

It's all been plain sailing up until the seventh tutorial, which adds
multiple light sources:
http://pyopengl.sourceforge.net/context/tutorials/shader_7.xhtml

I'm stuck on number 4. My problem is with the shader code, which operates on the same color buffer for both sets of vertices. This doesn't fit in a consolidated batch paradigm. Not entirely stuck; I'm thinking now two batches will be needed, or two shaders. (Or maybe I'll just skip this one, which appears would be best solved as it is. It is conceptual, not something I envision doing in a real application.)

Did you convert these examples to Pyglet batches, Jonathon? I'm curious to see what you've accomplished.

Gumm

[devon]

"The GMA 950 in the original MacBook and most older netbooks does
have
hardware support for pixel shaders - only vertex shaders are emulated
in
software. Since pixel shaders usually comprise the bulk of the work,
this
isn't actually as bad as it sounds.

However, if you want to get into shaders, you want to use GLSL
(preferably
OpenGL 2+), so that rules out the GMA 950 anyway. "

I'm pretty sure you can use GLSL on the GMA 950 on OSX.. but the
vertex shader will be emulated. It's just windows that only has ARB
shader support. That's why I hackintoshed this Lenovo X60t
afterall :), but I haven't actually ran in glsl code on it... I'll let
you know. Intel seems to be allergic to opengl on windows, I have so
many more extensions available on the osx extension viewer. One good
thing about the GMA 950 is it's easy to hackintosh :). Btw anybody
want to buy a hackintosh dell netbook mini10v? I have too many laptops
now with this horrible video card...

-Devon

On Oct 28, 12:27 pm, Tristam MacDonald <swiftco...@gmail.com> wrote:

[Tristam MacDonald]

On Mon, Nov 1, 2010 at 3:36 PM, devon <devon.sc...@gmail.com> wrote:

"The GMA 950 in the original MacBook and most older netbooks does
have hardware support for pixel shaders - only vertex shaders are emulated
in software. Since pixel shaders usually comprise the bulk of the work,
this isn't actually as bad as it sounds.

However, if you want to get into shaders, you want to use GLSL
(preferably OpenGL 2+), so that rules out the GMA 950 anyway. "

I'm pretty sure you can use GLSL on the GMA 950 on OSX.. but the
vertex shader will be emulated. It's just windows that only has ARB
shader support.

Well, yes, it does. However, I think you will find that it is GLSL compiled down to ARB assembly, and suffers from a few odd limitations/bugs as a result. I was never very happy with the results last I had access to a 950. 

 

That's why I hackintoshed this Lenovo X60t
afterall :), but I haven't actually ran in glsl code on it... I'll let
you know.  Intel seems to be allergic to opengl on windows, I have so
many more extensions available on the osx extension viewer.

Unfortunately, pretty much all of those extras will be emulated in software. Apple just loves to make things look all nice and shiny...

One good
thing about the GMA 950 is it's easy to hackintosh :).  Btw anybody
want to buy a hackintosh dell netbook mini10v? I have too many laptops
now with this horrible video card...

Depends how cheap it is... ;) 

[Jonathan Hartley]

On Nov 1, 2:51 pm, B W <stabbingfin...@gmail.com> wrote:

Hey.

No, I haven't converted them to pyglet batches. I'm just using pyglet
to provide a window. I've stuck pretty close to the source code
directly from the pyopengl tutorials.

My source is here:
https://bitbucket.org/tartley/tutorials/src/71791893891b/pyopengl/
(except somehow I managed to lose my version of tutorial 4, I think I
saved over it with tutorial 5.)

The only significant deviations I've made from the original tutorial
source are:

a) remove all use of uniform arrays, as I mentioned before.
b) From tutorial 6 onwards, the RGBA values for lighting & materials
seem strangely chosen, to me. The specular highlights are so large
that they cover fully half of the sphere, and the other components are
so dark that the circle is pretty much black if you comment out
specular highlights. Is this just me, or do other people see the same?
To fix it, I turned up the ambient and diffuse brightnesses (both
light and material) to about 0.6, made the material colored and
changed the lights to be nearer to white, and I increased the material
shininess from 0.995 to about 50, much reducing the specular
highlights in size. This generates images more in keeping with how I
expected it to look. The three components (ambient, diffuse and
specular) can now be all be clearly seen and visually distinguished.

When I'm done I'm going to return to this other tutorial:
http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Chapter-1:-The-Graphics-Pipeline.html
which I started yesterday, but abandoned because in my translation
from C to Python, I've failed to get anything visible to show up.
Maybe I can figure how I broke it with fresh eyes later tonight.

Jonathan

[Jonathan Hartley]

On Nov 1, 2:51 pm, B W <stabbingfin...@gmail.com> wrote:

[Tristam MacDonald]

/offtopic: for some reason, all of your recent emails show up *twice*.

--

You received this message because you are subscribed to the Google Groups "pyglet-users" group.
To post to this group, send email to pyglet...@googlegroups.com.
To unsubscribe from this group, send email to pyglet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.

[Jonathan Hartley]

On Nov 1, 2:51 pm, B W <stabbingfin...@gmail.com> wrote:

Hey Gumm.

No, I haven't been converting the tutorials to pyglet batches. I've
been sticking fairly closely to the original pyopengl tutorial source.
My source is all here:
https://bitbucket.org/tartley/tutorials/src/tip/pyopengl/

The only substantive changes I've made are:
a) remove use of arrays, as previously mentioned
b) Alter the parameter values used to initialise lights, from tutorial
6 onward.

I probably made a mistake in typing / copying the tutorial code, but I
made change (b) because the once the tutorials introduce specular
highlights, the lighting parameters produce strange-looking results
for me. The ambient and diffuse terms are so low the the sphere is
practically black if I turn off specular highlights. I boosted these
terms from around 0.1 to around 0.6, in materials and lighting. Plus,
the specular highlight itself is massive, covering a full half of the
sphere. Does anyone else see this? Or did I just break the tutorial
code somehow? I reduced the specular highlight size by changing the
material shininess from 0.995 to 50. This produced a result much more
in keeping with what I was expecting to see. All three components of
the lighting (ambient, diffuse and specular) are now clearly visually
distinguishable. I also made the material's specular color equal to
white, and made each light source's color closer to white, just to
give a more 'real-world' looking image.

Jonathan