Thinking of pyglet 3.0 I guess quirks I've noticed in pyglet that I would change:
- Label and Sprite could be standardised (eg width for both instead of content_width and width) - More control over the animation in Sprite, such as an ability to set the frame_index of the animation and easily switch off auto-advancing. - I could never really get HTMLLabel working properly (perhaps a bug in 1.2) - I'd love to get pyglet working with tkinter but my attempts to unpack the pyglet event loop to manually advance it have always failed - Batching working with z-position could be useful but I don't know if its possible - We should consider adding a higher level class above Sprite to allow switching between animations (eg an Actor) - Custom font use in pyglet is noble but confusing. It's not enough to just have the font file, you need to know the name of the font too to use it, which since it is baked into the file is not always easily apparent. On 6 September 2017 at 12:07, Benjamin Moran <[email protected]> wrote: > Update: > > I implemented basic *UniformBlock* and *BufferObject* classes to handle > *UniformBufferObjects*: https://www.khronos.org/ > opengl/wiki/Uniform_Buffer_Object > > Basically, each *ShaderProgram* has a *uniform_blocks* dictionary. This > contains instances of whatever UniformBlocks are in the shader program, > referenced by name. (The default shaders contains a "WindowBlock" uniform > block, with a few simple attributes such as window size). The UniformBlock > class also contains a method to query the offsets, and sizes of each > uniform in the block (it doesn't do any stride or matrix querying yet). > > The *BufferObject* class is used to update UniformBlocks. It takes one > UniformBlock instance when creating it, and has a method to bind additional > ones. Internally, I'm using the existing MappableBufferObject classes to do > all the hard work. These are already really nice classes, so no need to > reinvent the wheel. The way I set this up for now, is that the default > Group has one BufferObject instance that's created with the default > shader's UniformBlock. The Sprite module, which has it's own shader, binds > it's own UniformBlock to the existing BufferObject. The text module will > also bind it's shader there. > > All of these things will need going over in the future, but I think the > basic design and layout of things makes sense. I've also cleaned up a lot > of the existing code when I touched it to remove a lot of legacy OpenGL > cruft, but a lot more cleanup should be possible. I think we can really > clean things up. > > > On Monday, September 4, 2017 at 5:06:00 PM UTC+9, Benjamin Moran wrote: >> >> *Just another info dump: * >> >> I had a look at the text module the other day. It's a bit gnarly since it >> has a lot of nested Groups, but should be updatable without too much >> trouble. A simple shader will need to be written. >> >> I think the Shader and ShaderProgram classes are fairly functional at >> this point, but need a little finishing work. The Shader class is generic, >> and Shader objects can be reused among multiple ShaderPrograms. The >> ShaderProgram does introspection for basic Uniforms types on creation, and >> allows Pythonic getting and setting of Uniforms via *__setitem__* and >> *__getitem__* magic methods. Users do not need to use ctypes directly. >> >> One thing that is not ideal at the moment is that both the default >> shader, and the Sprite shaders need to have their Uniforms set for the >> current window size (as will the text module shaders, most likely). I've >> since started working on Uniform Block + Uniform Buffer Object support, so >> that we can use a default Uniform Block for basic Uniforms such as window >> size, etc. We should then be able to update this single UniformBufferObject >> using the Window.on_resize() event, and all default shaders used by pyglet >> will have the correct values. UBO support is going to be necessary for >> users anyway, so might as well implement it. >> >> On Tuesday, August 22, 2017 at 1:54:20 PM UTC+9, Benjamin Moran wrote: >>> >>> Things have slowed down towards the pyglet v1.3 release (mostly tiny >>> fixes now), so I've been hacking on my GL3+ fork recently. >>> I made a bit more progress. Most of my original ideas turned out to be >>> possible, so I've managed to get pyglet running on (currently) OpenGL 3.3, >>> with the existing API unchanged. The Sprite module now works as intended, >>> with all attributes working as they did before. Basically, the SpriteGroup >>> has a very simple shader with the needed attributes to mimic the old >>> behavior. Going forward, we could probably move the scaling and rotation >>> parts of the Sprite class inside the shader to save a ton of CPU. Setting >>> the sprite rotation, etc. would just need to update a single uniform and >>> let the shader do it, rather than wasting CPU resources. For now, however, >>> my goal is just to get things working. So what's left? >>> >>> 1. I *think* my Shader and ShaderProgram classes are reasonably >>> designed, but they might need a rewrite. They work for now. Better >>> shaders >>> will definitely have to be written, by someone who knows what they're >>> doing >>> :) >>> 2. The text module hasn't been touched yet. This will need tweaks to >>> get working. >>> 3. The image and graphics modules will need a going over. >>> 4. Proper exceptions will need to be written for some things. >>> 5. The IndexedVertexDomain has serious bugs! Needs to be fixed. >>> >>> #5 is a big one. I discovered the IndexedVertexDomain has bugs with >>> deleting vertex_lists. The GL3+ branch uses indexed drawing because of the >>> switch from QUADS to TRIANGLES, so this needs to be fixed. The alternative >>> is to just use standard drawing without indexing, but this would create a >>> lot of needless index data to be written everywhere. >>> >>> >>> >>> >>> >>> On Monday, June 5, 2017 at 12:50:31 AM UTC+9, Benjamin Moran wrote: >>>> >>>> Hi all, >>>> >>>> This thread is to discuss migrating pyglet to an OpenGL 3+ core profile >>>> at some point in the future. The cons are losing support for (what is now) >>>> very old graphics hardware. The pros are many, but include allowing usage >>>> of modern shaders and OpenGL features. We would want to keep pyglet usable >>>> without any OpenGL knowledge, which would mean a set of basic shaders that >>>> mimic the current functionality. >>>> >>>> I've already hacked on my personal branch of pyglet to see if this is >>>> possible while keeping with the current pyglet structure, and I think it >>>> might be. I'm no OpenGL expert, but I think the following ideas will work: >>>> >>>> 1. Each Batch encompasses one VAO. >>>> 2. Each Group can contain shader programs. >>>> 3. The current default Group, which is a NullGroup, will instead >>>> contain a basic shader program. >>>> 4. The pyglet.graphics module remains the same. The default shaders >>>> will contain attributes that match the expected names. >>>> 5. If you wish to use your own shaders, and wish to use the >>>> pyglet.graphics.attribute clases, you must use the same attribute names >>>> (as >>>> these are hardcoded in the module). >>>> >>>> I've already tried this, in that I hacked the pyglet.graphics module to >>>> work with OpenGL 3+. This means vertex lists and batches both work, and you >>>> can create and draw primitives just like normal. The Sprite module is also >>>> working, but is broken because the current default shader is too crude to >>>> handle texture data correctly. It's just a proof of concept at this stage. >>>> You can find my fork here: >>>> >>>> https://bitbucket.org/HigashiNoKaze/pyglet/branch/shaders >>>> >>>> >>>> >>>> >> ... > > [Message clipped] -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
