Hi, Tristam. Thanks for your reply. On Wed, Oct 27, 2010 at 7:42 AM, Tristam MacDonald <[email protected]>wrote:
> On Wed, Oct 27, 2010 at 10:24 AM, B W <[email protected]> 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 <[email protected]> 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 -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
