@Benjamin: This would be a nice addition to the wishlist/todolist you were proposing in slack. Each point seems like a valid concern to address.
Rob Op zaterdag 25 november 2017 01:59:04 UTC+1 schreef dodgyville: > > 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] > <javascript:>> 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.
