I think the ideal method should be how it works now, whn using the pyglet.resource module. Things are packed together as much as possible, but it should still be able to function normally if you create your own textures or texture atlases. It would be slower of course, but I think it should at least work.
I've been reading up on various order independent transparancy techniches, such as the one described in this blog: https://mynameismjp.wordpress.com/2014/02/03/weighted-blended-oit/ There is a link to the original PDF there as well. All very interesting stuff. The impression that I'm getting is that transparancy is not really a solved issue in the OpenGL world. On Wednesday, October 19, 2016 at 7:45:39 AM UTC+9, Charles wrote: > > I would be very interested to see these changes and additions to test out. > > One thing with the texture atlas containing everything, many graphics > cards have max texture size limits, would a change like this cause problems > then? > > On Monday, October 3, 2016 at 3:17:08 PM UTC-5, Josh wrote: >> >> I have the code with some bug fixes from after I sent it to you. It's not >> in a public repository right now but I can put it somewhere. It's still not >> thoroughly tested, it just worked for my project. >> >> Call for call, I think there isn't much difference between DrawArrays and >> DrawElements (or if there is, it's on the GPU side). The huge advantage of >> DrawElements is that you can render your entire game with just the one >> call, and do it in whatever order you want. In current pyglet, when you >> call batch.draw(), pyglet makes a separate DrawArrays call for each >> separate texture that needs to be rendered. >> >> What if we subclass VertexDomain with OrderedVertexDomain, create a >> ZSpriteGroup class, and create a ZSprite class? That keeps backwards >> compatibility. ZSprites would be initialized with a fixed ZSpriteGroup. >> Unlike normal groups, ZSpriteGroups would maintain a TextureAtlas, a sorted >> list of indices, and an OrderedVertexDomain, and would not allow children. >> Batch methods would be modified so the batch always associates a ZGroup's >> domain, and only that domain, with that group. This requires changes to >> Batch.migrate, Batch._get_domain, Batch._add_group that explicitly check if >> a group is a ZSpriteGroup. >> >> >> On Monday, October 3, 2016 at 5:02:59 AM UTC-5, Benjamin Moran wrote: >>> >>> Thanks for the lengthy writeup, Josh. It seems like this is one of those >>> issues that has no "perfect" solution. I was able to find the code you >>> shared before, and it looks like a nice bit of work. Do you still have an >>> active branch of this somewhere? >>> I'm also curious what your experience with glDrawArrays vs >>> glDrawElements is, performance wise. Most of the talk on the subject is >>> pretty old, so I'm wondering just what the differnce really is. >>> >>> Not breaking code would be ideal. I think as long as there are fallbacks >>> (even if slow fallbacks) would be a requirement, so as not to regress in >>> functionality. Additionally, not to impose any behaviour that would >>> negatively affect people who don't even use the sprite class at all. >>> >>> >>> >>> On Monday, October 3, 2016 at 4:30:07 AM UTC+9, Josh wrote: >>>> >>>> Hi all, >>>> >>>> Been a while since I dealt with this, but here is the core of the >>>> solution I came up with. Currently VertexDomain uses glDrawArrays to >>>> render >>>> sprites. This requires the correct texture for each sprite has to be bound >>>> before it can be rendered. So if you have, say, 100 distinct images being >>>> rendered as sprites, that's (usually) 100 glDrawArrays calls per frame. >>>> Also, all sprites sharing a texture are always rendered simultaneously if >>>> they belong to the same batch. >>>> >>>> To solve this problem, I created a new method draw_ordered for >>>> VertexDomain that uses glDrawElements. This allows you to pass a list of >>>> indices that specifies the order the elements will be rendered in. >>>> However, >>>> because you have to choose one texture to have bound before calling >>>> DrawElements, everything in the domain still has to have a common texture. >>>> So to make this solution work,* all sprites in a batch must take their >>>> textures as regions from a single master textur**e *(in pyglet, >>>> TextureAtlas was convenient for this; it automatically sets the texture >>>> coordinates for the sprite vertices correctly). >>>> >>>> I still think the huge gains in efficiency make it worth changing to >>>> glDrawArrays. To make it work with the existing pyglet framework, I >>>> created >>>> a new rendering hierarchy in parallel with the existing pyglet methods: >>>> OrderedBatch, OrderedSprite, AtlasAnimation, AnimationRegion. But a better >>>> solution would be to have a singleton TextureAtlas. Getting images through >>>> the pyglet resource tools would automatically enter them in the singleton, >>>> and most users would not have to worry about the change in rendering >>>> method. But definitely some code would break. >>>> >>> -- 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 pyglet-users+unsubscr...@googlegroups.com. To post to this group, send email to pyglet-users@googlegroups.com. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
