Re: zsprites, or sorting sprites with the z buffer
Hello ! I am a newcomer in pyglet and i am looking for a way to render z sorting sprites, and so that's how I found your work The problem is that the link https://bitbucket.org/HigashiNoKaze/pyglet/branch/ordered_sprite is not working anymore, so where can I find your Ordered_sprite branch ? Thanks for all -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/pyglet-users/1240af3f-1867-4556-a0b1-4c1639a974a1%40googlegroups.com.
Re: zsprites, or sorting sprites with the z buffer
Sorry I didn't think to mention the texture atlas part, but that is definitely something that needs to be well documented. Just for clarity, and for others reading this, the current pyglet.resource module uses an internal TextureBin of 2048x2048 if possible, but will do a check first to see how big the card can actually handle. The TextureAtlas/Bin classes themselves have also added a check to fall back to the maximum size available if the requested size is not possible. This was done so that if another user runs your app/game on an older GPU, it might have a chance to run instead of just crashing. One thing you could do is to make more than one altas. This by itself will mean multiple draw calls of course, since you'll be using more than one texture. You can then use OrderedGroups to ensure that they draw in the order you want. On Thursday, March 23, 2017 at 1:10:38 AM UTC+9, Charles wrote: > > Thanks for the response, that makes sense now. That was kind of the > limitation I was wondering about initially. Unfortunately that kind of > makes it inconsistent for use since now the texture atlas size is > dynamically chosen based on machine configuration. You can't guarantee > texture atlas size without managing them all on your own and it would have > to be on the small side to maintain compatibility. Also this makes it > unusable for larger projects since, for instance, just my creatures can > take up one whole atlas by itself, leaving it unable to be ordered with the > world objects. However, using it in smaller projects this is a good > implementation and I agree with adding it as an option for people since > it's a common question these days. > > On Thursday, March 9, 2017 at 9:09:05 PM UTC-6, Benjamin Moran wrote: >> >> Hi Charles, >> >> Sorry it took me so long to get back to you on this. The answer is pretty >> simple: All of the sprites/images must be on the same TextureAtlas in >> order for the OrderedVertexDomain to work. If you just do a >> *pyglet.image.load* for each image, they are put into their own seperate >> Domains. This is because the the Groups/Domains can't be consolidated (and >> drawn together in one shot) when the texture is different. >> >> In your example, when each image is on it's own texture, you end up with >> two Groups - each Group containing a ton of VertexDomains under the hood. >> By making sure everything shares the same texture, you'll get two Groups >> with one big VertexDomain each (which can be ordered). Does this make >> sense? It might be a bit hard to visualize if you're not familiar with how >> things work in the graphics module. >> >> The easy way is to just use the pyglet.resource module for loading >> images, but of course you can manually create your own Atlas as well. >> >> >> >> On Monday, February 20, 2017 at 12:28:31 PM UTC+9, Charles wrote: >>> >>> Just saw your reply. The version I have is from 2/11/2017 >>> >>> On Sunday, February 19, 2017 at 8:00:19 PM UTC-6, Benjamin Moran wrote: Hey Charles, No worries. It's good to squash any bugs that might exist. First of all, are you using the latest version of the code? There wa a missing sort call that existed before, and would cause trouble. Unfortunately I haven't come across that issue, but I haven't stressed this code extensively in any of my personal projects. If it's at all possible, can you share an example of code that illustrates the problem? Even if it only happens sometimes, it would be a good start to track it down. Internally, the OrderedVertexDomain is quite simple. There is a single call to glMultiDrawArrays, which takes in two lists of starts/sizes, as well as primsize. The most crutial bit of the code is ensuring that these starts and sizes lists are regenerated when necessary. Basically any time you add, delete, migrate, or sort a vertex list, the domain is marked as dirty and is sorted before the next call. The only other thing I'm unsure of are the buffers + attributes that are bound before each call. I'm not very familar with that code (or honestly the deep OpenGL logic behind this), but it's a possibility that this is the cuprit. On Monday, February 20, 2017 at 4:26:11 AM UTC+9, Charles wrote: > > Hey Benjamin, I know it's been a while since our last posts, but I > have just started experimenting with the ordered sprite branch. > Everything > is working perfect (performance, implementation, ordering) except one > thing. > > Whenever a sprite uses the order attribute it will sometimes flicker. > So for an example I have my tiles with no order set, but in my 'game > objects' layer where everything is ordered by the order attribute. > Unfortunately it doesn't happen all the time, but when it does, it > flickers > all of the ordered sprites every co
Re: zsprites, or sorting sprites with the z buffer
Thanks for the response, that makes sense now. That was kind of the limitation I was wondering about initially. Unfortunately that kind of makes it inconsistent for use since now the texture atlas size is dynamically chosen based on machine configuration. You can't guarantee texture atlas size without managing them all on your own and it would have to be on the small side to maintain compatibility. Also this makes it unusable for larger projects since, for instance, just my creatures can take up one whole atlas by itself, leaving it unable to be ordered with the world objects. However, using it in smaller projects this is a good implementation and I agree with adding it as an option for people since it's a common question these days. On Thursday, March 9, 2017 at 9:09:05 PM UTC-6, Benjamin Moran wrote: > > Hi Charles, > > Sorry it took me so long to get back to you on this. The answer is pretty > simple: All of the sprites/images must be on the same TextureAtlas in > order for the OrderedVertexDomain to work. If you just do a > *pyglet.image.load* for each image, they are put into their own seperate > Domains. This is because the the Groups/Domains can't be consolidated (and > drawn together in one shot) when the texture is different. > > In your example, when each image is on it's own texture, you end up with > two Groups - each Group containing a ton of VertexDomains under the hood. > By making sure everything shares the same texture, you'll get two Groups > with one big VertexDomain each (which can be ordered). Does this make > sense? It might be a bit hard to visualize if you're not familiar with how > things work in the graphics module. > > The easy way is to just use the pyglet.resource module for loading images, > but of course you can manually create your own Atlas as well. > > > > On Monday, February 20, 2017 at 12:28:31 PM UTC+9, Charles wrote: >> >> Just saw your reply. The version I have is from 2/11/2017 >> >> On Sunday, February 19, 2017 at 8:00:19 PM UTC-6, Benjamin Moran wrote: >>> >>> Hey Charles, >>> >>> No worries. It's good to squash any bugs that might exist. First of >>> all, are you using the latest version of the code? There wa a missing sort >>> call that existed before, and would cause trouble. >>> >>> Unfortunately I haven't come across that issue, but I haven't stressed >>> this code extensively in any of my personal projects. If it's at all >>> possible, can you share an example of code that illustrates the problem? >>> Even if it only happens sometimes, it would be a good start to track it >>> down. Internally, the OrderedVertexDomain is quite simple. There is a >>> single call to glMultiDrawArrays, which takes in two lists of starts/sizes, >>> as well as primsize. The most crutial bit of the code is ensuring that >>> these starts and sizes lists are regenerated when necessary. Basically any >>> time you add, delete, migrate, or sort a vertex list, the domain is marked >>> as dirty and is sorted before the next call. >>> >>> The only other thing I'm unsure of are the buffers + attributes that are >>> bound before each call. I'm not very familar with that code (or honestly >>> the deep OpenGL logic behind this), but it's a possibility that this is the >>> cuprit. >>> >>> On Monday, February 20, 2017 at 4:26:11 AM UTC+9, Charles wrote: Hey Benjamin, I know it's been a while since our last posts, but I have just started experimenting with the ordered sprite branch. Everything is working perfect (performance, implementation, ordering) except one thing. Whenever a sprite uses the order attribute it will sometimes flicker. So for an example I have my tiles with no order set, but in my 'game objects' layer where everything is ordered by the order attribute. Unfortunately it doesn't happen all the time, but when it does, it flickers all of the ordered sprites every couple of seconds or so. Unfortunately it's hard to test since it's so inconsistent, majority of the time it seems ok. Just wondering if you've run across this issue before? Thanks. On Monday, January 9, 2017 at 2:07:13 AM UTC-6, Benjamin Moran wrote: > > Hi Charles, > > 1) No inherit limitations. Under the hood, it's functionally identical > to the normal VertexDomains, except that it keeps it's own additional > lists > of starts/sizes for the VertexLists in the Domain, which are sorted. > There > should be no Alpha/transparency issues, since everything is rendered in > order and will composite correctly. > > 2) This will be infinitely faster than OrderedGroups, *IF* you're > doing more than a few groups. The reason being is that Groups in pyglet > set > and unset OpenGL state, and each Group reqires a seperate draw process. > Pyglet consolidates Groups by default, so a batch with a lot of objects > using
Re: zsprites, or sorting sprites with the z buffer
Just wanted to let people know that my personal fork of pyglet containing this branch has changed. The new link is: https://bitbucket.org/HigashiNoKaze/pyglet/branch/ordered_sprite I'm thinking that, just like the IndexedVertexDomain, the OrderedVertexDomain is worthwhile to include in pyglet. I'd have to think about it after the 1.3.x release. I'm still not sure if it makes sense to changed the Sprite module at this time. It seems like there are perfectly valid reasons to go with ordering, OR zbuffer.. You can always do both, of course, but the OrderedVertexDomain does incur a bit of overhead when sorting. Due to the way it works, sorting is required when adding/deleting vertex lists, so for some use cases it could be slower. On Friday, March 10, 2017 at 12:09:05 PM UTC+9, Benjamin Moran wrote: > > Hi Charles, > > Sorry it took me so long to get back to you on this. The answer is pretty > simple: All of the sprites/images must be on the same TextureAtlas in > order for the OrderedVertexDomain to work. If you just do a > *pyglet.image.load* for each image, they are put into their own seperate > Domains. This is because the the Groups/Domains can't be consolidated (and > drawn together in one shot) when the texture is different. > > In your example, when each image is on it's own texture, you end up with > two Groups - each Group containing a ton of VertexDomains under the hood. > By making sure everything shares the same texture, you'll get two Groups > with one big VertexDomain each (which can be ordered). Does this make > sense? It might be a bit hard to visualize if you're not familiar with how > things work in the graphics module. > > The easy way is to just use the pyglet.resource module for loading images, > but of course you can manually create your own Atlas as well. > > > > On Monday, February 20, 2017 at 12:28:31 PM UTC+9, Charles wrote: >> >> Just saw your reply. The version I have is from 2/11/2017 >> >> On Sunday, February 19, 2017 at 8:00:19 PM UTC-6, Benjamin Moran wrote: >>> >>> Hey Charles, >>> >>> No worries. It's good to squash any bugs that might exist. First of >>> all, are you using the latest version of the code? There wa a missing sort >>> call that existed before, and would cause trouble. >>> >>> Unfortunately I haven't come across that issue, but I haven't stressed >>> this code extensively in any of my personal projects. If it's at all >>> possible, can you share an example of code that illustrates the problem? >>> Even if it only happens sometimes, it would be a good start to track it >>> down. Internally, the OrderedVertexDomain is quite simple. There is a >>> single call to glMultiDrawArrays, which takes in two lists of starts/sizes, >>> as well as primsize. The most crutial bit of the code is ensuring that >>> these starts and sizes lists are regenerated when necessary. Basically any >>> time you add, delete, migrate, or sort a vertex list, the domain is marked >>> as dirty and is sorted before the next call. >>> >>> The only other thing I'm unsure of are the buffers + attributes that are >>> bound before each call. I'm not very familar with that code (or honestly >>> the deep OpenGL logic behind this), but it's a possibility that this is the >>> cuprit. >>> >>> On Monday, February 20, 2017 at 4:26:11 AM UTC+9, Charles wrote: Hey Benjamin, I know it's been a while since our last posts, but I have just started experimenting with the ordered sprite branch. Everything is working perfect (performance, implementation, ordering) except one thing. Whenever a sprite uses the order attribute it will sometimes flicker. So for an example I have my tiles with no order set, but in my 'game objects' layer where everything is ordered by the order attribute. Unfortunately it doesn't happen all the time, but when it does, it flickers all of the ordered sprites every couple of seconds or so. Unfortunately it's hard to test since it's so inconsistent, majority of the time it seems ok. Just wondering if you've run across this issue before? Thanks. On Monday, January 9, 2017 at 2:07:13 AM UTC-6, Benjamin Moran wrote: > > Hi Charles, > > 1) No inherit limitations. Under the hood, it's functionally identical > to the normal VertexDomains, except that it keeps it's own additional > lists > of starts/sizes for the VertexLists in the Domain, which are sorted. > There > should be no Alpha/transparency issues, since everything is rendered in > order and will composite correctly. > > 2) This will be infinitely faster than OrderedGroups, *IF* you're > doing more than a few groups. The reason being is that Groups in pyglet > set > and unset OpenGL state, and each Group reqires a seperate draw process. > Pyglet consolidates Groups by default, so a batch with a lot of objects > using the s
Re: zsprites, or sorting sprites with the z buffer
Hi Charles, Sorry it took me so long to get back to you on this. The answer is pretty simple: All of the sprites/images must be on the same TextureAtlas in order for the OrderedVertexDomain to work. If you just do a *pyglet.image.load* for each image, they are put into their own seperate Domains. This is because the the Groups/Domains can't be consolidated (and drawn together in one shot) when the texture is different. In your example, when each image is on it's own texture, you end up with two Groups - each Group containing a ton of VertexDomains under the hood. By making sure everything shares the same texture, you'll get two Groups with one big VertexDomain each (which can be ordered). Does this make sense? It might be a bit hard to visualize if you're not familiar with how things work in the graphics module. The easy way is to just use the pyglet.resource module for loading images, but of course you can manually create your own Atlas as well. On Monday, February 20, 2017 at 12:28:31 PM UTC+9, Charles wrote: > > Just saw your reply. The version I have is from 2/11/2017 > > On Sunday, February 19, 2017 at 8:00:19 PM UTC-6, Benjamin Moran wrote: >> >> Hey Charles, >> >> No worries. It's good to squash any bugs that might exist. First of all, >> are you using the latest version of the code? There wa a missing sort call >> that existed before, and would cause trouble. >> >> Unfortunately I haven't come across that issue, but I haven't stressed >> this code extensively in any of my personal projects. If it's at all >> possible, can you share an example of code that illustrates the problem? >> Even if it only happens sometimes, it would be a good start to track it >> down. Internally, the OrderedVertexDomain is quite simple. There is a >> single call to glMultiDrawArrays, which takes in two lists of starts/sizes, >> as well as primsize. The most crutial bit of the code is ensuring that >> these starts and sizes lists are regenerated when necessary. Basically any >> time you add, delete, migrate, or sort a vertex list, the domain is marked >> as dirty and is sorted before the next call. >> >> The only other thing I'm unsure of are the buffers + attributes that are >> bound before each call. I'm not very familar with that code (or honestly >> the deep OpenGL logic behind this), but it's a possibility that this is the >> cuprit. >> >> On Monday, February 20, 2017 at 4:26:11 AM UTC+9, Charles wrote: >>> >>> Hey Benjamin, I know it's been a while since our last posts, but I have >>> just started experimenting with the ordered sprite branch. Everything is >>> working perfect (performance, implementation, ordering) except one thing. >>> >>> Whenever a sprite uses the order attribute it will sometimes flicker. So >>> for an example I have my tiles with no order set, but in my 'game objects' >>> layer where everything is ordered by the order attribute. Unfortunately it >>> doesn't happen all the time, but when it does, it flickers all of the >>> ordered sprites every couple of seconds or so. >>> >>> Unfortunately it's hard to test since it's so inconsistent, majority of >>> the time it seems ok. Just wondering if you've run across this issue >>> before? Thanks. >>> >>> On Monday, January 9, 2017 at 2:07:13 AM UTC-6, Benjamin Moran wrote: Hi Charles, 1) No inherit limitations. Under the hood, it's functionally identical to the normal VertexDomains, except that it keeps it's own additional lists of starts/sizes for the VertexLists in the Domain, which are sorted. There should be no Alpha/transparency issues, since everything is rendered in order and will composite correctly. 2) This will be infinitely faster than OrderedGroups, *IF* you're doing more than a few groups. The reason being is that Groups in pyglet set and unset OpenGL state, and each Group reqires a seperate draw process. Pyglet consolidates Groups by default, so a batch with a lot of objects using the same TextureAtlas, etc. will usually all draw together - most of the time your objects will be similar and automatically grouped into the same draw call. By using OrderedGroup, you are forcing a seperate draw call for every single group. A few groups, like "background", "midsection", "foreground", etc. is fine, but it will fall on it's face if you try to do a lot. The performance question is not so simple: For basic benchmarks of static sprites, the draw speed for OrderedVertexDomain is identical to the normal VertexDomain. Drawing 20,000 sprites takes about 0.010ms (@ 90fps). It doesn't matter how many different order levels there are. If you try to use OrderedGroups, it takes over 3 seconds(!) to draw the same amount of sprites. That said, the actual sorting process does use some CPU. Any time you add/delete/migrat
Re: zsprites, or sorting sprites with the z buffer
Thanks for all of the example code and detail Charles, that's plenty of info to go on. This is exactly the type of testing that needed to be done. I've actually not tested this with OrderedGroups, since ordering makes them redundant. However, there is no reason it shouldn't be able to work. Not working with OrderedGroups indicates that it probably won't work with custom Groups either. I'll first confirm that I have the same results, and then hopefully it's something that can be fixed at the domain level. On Monday, February 20, 2017 at 11:28:03 AM UTC+9, Charles wrote: > > I have done a lot of rounds of testing and found some issues. (tileImg = > 32x32, objectImg = 16x16) > > 1) No order set. > Sprites that sit on top of each other. > Same group. > > A majority of the time, the objectImg sprites will not load. Restarting > several times and they may show up half the time. Some issue there. > > Example: > tileGroup = pyglet.graphics.OrderedGroup(0) > objectGroup = pyglet.graphics.OrderedGroup(1) > sprites = [] > for i in xrange(50): > for j in xrange(50): > sprites.append(pyglet.sprite.Sprite(tileImg, x=i*32, y=j*32, batch > =batch, group=tileGroup)) > > > for i in xrange(50): > for j in xrange(50): > sprites.append(pyglet.sprite.Sprite(objectImg, x=i*32, y=j*32, > batch=batch, group=tileGroup)) > > > > 2) No order set: > Sprites that sit on top of eachother. > Different groups. > > Works as expected 100% of the time. Both groups of sprites show up. > > Example: > tileGroup = pyglet.graphics.OrderedGroup(0) > objectGroup = pyglet.graphics.OrderedGroup(1) > > sprites = [] > for i in xrange(50): > for j in xrange(50): > sprites.append(pyglet.sprite.Sprite(tileImg, x=i*32, y=j*32, batch > =batch, group=tileGroup)) > > > for i in xrange(50): > for j in xrange(50): > sprites.append(pyglet.sprite.Sprite(objectImg, x=i*32, y=j*32, > batch=batch, group=objectGroup)) > > > 3) Introduce a playerSprite into the mix and orders into the objectGroup. > Orders based on y. > Sprites may start on top of eachother (ie, object and player sprite start > at 0x0) > > Results: Sometimes the player sprite appears under the object sprites, > sometimes over the object sprites. Once the sprite appears over or under, > order will no longer have an effect. > For instance if it starts under all of the object sprites, changing the > order will not put it over the sprites it will always stay under. If the > sprite starts OVER the sprites, changing the order will not put it under > the sprites. > > > tileGroup = pyglet.graphics.OrderedGroup(0) > objectGroup = pyglet.graphics.OrderedGroup(1) > > sprites = [] > for i in xrange(50): > for j in xrange(50): > sprites.append(pyglet.sprite.Sprite(tileImg, x=i*32, y=j*32, > batch=batch, group=tileGroup)) > > for i in xrange(50): > for j in xrange(50): > sprites.append(pyglet.sprite.Sprite(objectImg, x=i*32, y=j*32, > order=j*32, batch=batch, group=objectGroup)) > > playerSprite = pyglet.sprite.Sprite(playerImg, x=0, y=0, > group=objectGroup, batch=batch) > > def moveChar(dt, axis, val): > if axis == "x": > playerSprite.update(x=playerSprite.x+val) > else: > playerSprite.update(y=playerSprite.y+val) > playerSprite.order = playerSprite.y > > > Under no circumstances can I get this method to actually work as intended > where the sprite will appear over the sprites in objectGroup up until it > passes the sprite and goes under it. > > On Sunday, February 19, 2017 at 1:26:11 PM UTC-6, Charles wrote: >> >> Hey Benjamin, I know it's been a while since our last posts, but I have >> just started experimenting with the ordered sprite branch. Everything is >> working perfect (performance, implementation, ordering) except one thing. >> >> Whenever a sprite uses the order attribute it will sometimes flicker. So >> for an example I have my tiles with no order set, but in my 'game objects' >> layer where everything is ordered by the order attribute. Unfortunately it >> doesn't happen all the time, but when it does, it flickers all of the >> ordered sprites every couple of seconds or so. >> >> Unfortunately it's hard to test since it's so inconsistent, majority of >> the time it seems ok. Just wondering if you've run across this issue >> before? Thanks. >> >> On Monday, January 9, 2017 at 2:07:13 AM UTC-6, Benjamin Moran wrote: >>> >>> Hi Charles, >>> >>> 1) No inherit limitations. Under the hood, it's functionally identical >>> to the normal VertexDomains, except that it keeps it's own additional lists >>> of starts/sizes for the VertexLists in the Domain, which are sorted. There >>> should be no Alpha/transparency issues, since everything is rendered in >>> order and will composite correctly. >>> >>> 2) This will be infinitely faster than OrderedGroups, *IF* you're >>> doing more than a few groups. The reason being is that Groups in pyglet set >>> and unset OpenGL sta
Re: zsprites, or sorting sprites with the z buffer
Just saw your reply. The version I have is from 2/11/2017 On Sunday, February 19, 2017 at 8:00:19 PM UTC-6, Benjamin Moran wrote: > > Hey Charles, > > No worries. It's good to squash any bugs that might exist. First of all, > are you using the latest version of the code? There wa a missing sort call > that existed before, and would cause trouble. > > Unfortunately I haven't come across that issue, but I haven't stressed > this code extensively in any of my personal projects. If it's at all > possible, can you share an example of code that illustrates the problem? > Even if it only happens sometimes, it would be a good start to track it > down. Internally, the OrderedVertexDomain is quite simple. There is a > single call to glMultiDrawArrays, which takes in two lists of starts/sizes, > as well as primsize. The most crutial bit of the code is ensuring that > these starts and sizes lists are regenerated when necessary. Basically any > time you add, delete, migrate, or sort a vertex list, the domain is marked > as dirty and is sorted before the next call. > > The only other thing I'm unsure of are the buffers + attributes that are > bound before each call. I'm not very familar with that code (or honestly > the deep OpenGL logic behind this), but it's a possibility that this is the > cuprit. > > On Monday, February 20, 2017 at 4:26:11 AM UTC+9, Charles wrote: >> >> Hey Benjamin, I know it's been a while since our last posts, but I have >> just started experimenting with the ordered sprite branch. Everything is >> working perfect (performance, implementation, ordering) except one thing. >> >> Whenever a sprite uses the order attribute it will sometimes flicker. So >> for an example I have my tiles with no order set, but in my 'game objects' >> layer where everything is ordered by the order attribute. Unfortunately it >> doesn't happen all the time, but when it does, it flickers all of the >> ordered sprites every couple of seconds or so. >> >> Unfortunately it's hard to test since it's so inconsistent, majority of >> the time it seems ok. Just wondering if you've run across this issue >> before? Thanks. >> >> On Monday, January 9, 2017 at 2:07:13 AM UTC-6, Benjamin Moran wrote: >>> >>> Hi Charles, >>> >>> 1) No inherit limitations. Under the hood, it's functionally identical >>> to the normal VertexDomains, except that it keeps it's own additional lists >>> of starts/sizes for the VertexLists in the Domain, which are sorted. There >>> should be no Alpha/transparency issues, since everything is rendered in >>> order and will composite correctly. >>> >>> 2) This will be infinitely faster than OrderedGroups, *IF* you're >>> doing more than a few groups. The reason being is that Groups in pyglet set >>> and unset OpenGL state, and each Group reqires a seperate draw process. >>> Pyglet consolidates Groups by default, so a batch with a lot of objects >>> using the same TextureAtlas, etc. will usually all draw together - most of >>> the time your objects will be similar and automatically grouped into the >>> same draw call. By using OrderedGroup, you are forcing a seperate draw >>> call for every single group. A few groups, like "background", "midsection", >>> "foreground", etc. is fine, but it will fall on it's face if you try to do >>> a lot. >>> >>> The performance question is not so simple: >>> For basic benchmarks of static sprites, the draw speed for >>> OrderedVertexDomain is identical to the normal VertexDomain. Drawing 20,000 >>> sprites takes about 0.010ms (@ 90fps). It doesn't matter how many different >>> order levels there are. If you try to use OrderedGroups, it takes over 3 >>> seconds(!) to draw the same amount of sprites. >>> >>> That said, the actual sorting process does use some CPU. Any time you >>> add/delete/migrate a sprite/vertex_list in an OrderedVertexDomain, it does >>> a sort before the next draw. Even if you're doing this every frame, it's >>> still good for thousands of sprites. I'm sure the sort process can be >>> optimized a bit more. >>> >>> >>> >>> >>> On Monday, January 9, 2017 at 10:24:14 AM UTC+9, Charles wrote: It's been a long time since I checked this thread, but it looks like there has been quite a lot of progress since I last looked. I have tested the test branch and so far I have found the ordering to work without issues. I guess my questions on the latest changes are: 1) Are there any limitations for this? I know last I looked and tested the z sprite issues, there were some alpha and transparency issues. 2) Have you done any benchmarks on ordered groups compared to this method? How does having a lot of different sprites (hundreds) on various order levels affect performance? Thanks for your work guys! >>> -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and
Re: zsprites, or sorting sprites with the z buffer
I have done a lot of rounds of testing and found some issues. (tileImg = 32x32, objectImg = 16x16) 1) No order set. Sprites that sit on top of each other. Same group. A majority of the time, the objectImg sprites will not load. Restarting several times and they may show up half the time. Some issue there. Example: tileGroup = pyglet.graphics.OrderedGroup(0) objectGroup = pyglet.graphics.OrderedGroup(1) sprites = [] for i in xrange(50): for j in xrange(50): sprites.append(pyglet.sprite.Sprite(tileImg, x=i*32, y=j*32, batch= batch, group=tileGroup)) for i in xrange(50): for j in xrange(50): sprites.append(pyglet.sprite.Sprite(objectImg, x=i*32, y=j*32, batch =batch, group=tileGroup)) 2) No order set: Sprites that sit on top of eachother. Different groups. Works as expected 100% of the time. Both groups of sprites show up. Example: tileGroup = pyglet.graphics.OrderedGroup(0) objectGroup = pyglet.graphics.OrderedGroup(1) sprites = [] for i in xrange(50): for j in xrange(50): sprites.append(pyglet.sprite.Sprite(tileImg, x=i*32, y=j*32, batch= batch, group=tileGroup)) for i in xrange(50): for j in xrange(50): sprites.append(pyglet.sprite.Sprite(objectImg, x=i*32, y=j*32, batch =batch, group=objectGroup)) 3) Introduce a playerSprite into the mix and orders into the objectGroup. Orders based on y. Sprites may start on top of eachother (ie, object and player sprite start at 0x0) Results: Sometimes the player sprite appears under the object sprites, sometimes over the object sprites. Once the sprite appears over or under, order will no longer have an effect. For instance if it starts under all of the object sprites, changing the order will not put it over the sprites it will always stay under. If the sprite starts OVER the sprites, changing the order will not put it under the sprites. tileGroup = pyglet.graphics.OrderedGroup(0) objectGroup = pyglet.graphics.OrderedGroup(1) sprites = [] for i in xrange(50): for j in xrange(50): sprites.append(pyglet.sprite.Sprite(tileImg, x=i*32, y=j*32, batch=batch, group=tileGroup)) for i in xrange(50): for j in xrange(50): sprites.append(pyglet.sprite.Sprite(objectImg, x=i*32, y=j*32, order=j*32, batch=batch, group=objectGroup)) playerSprite = pyglet.sprite.Sprite(playerImg, x=0, y=0, group=objectGroup, batch=batch) def moveChar(dt, axis, val): if axis == "x": playerSprite.update(x=playerSprite.x+val) else: playerSprite.update(y=playerSprite.y+val) playerSprite.order = playerSprite.y Under no circumstances can I get this method to actually work as intended where the sprite will appear over the sprites in objectGroup up until it passes the sprite and goes under it. On Sunday, February 19, 2017 at 1:26:11 PM UTC-6, Charles wrote: > > Hey Benjamin, I know it's been a while since our last posts, but I have > just started experimenting with the ordered sprite branch. Everything is > working perfect (performance, implementation, ordering) except one thing. > > Whenever a sprite uses the order attribute it will sometimes flicker. So > for an example I have my tiles with no order set, but in my 'game objects' > layer where everything is ordered by the order attribute. Unfortunately it > doesn't happen all the time, but when it does, it flickers all of the > ordered sprites every couple of seconds or so. > > Unfortunately it's hard to test since it's so inconsistent, majority of > the time it seems ok. Just wondering if you've run across this issue > before? Thanks. > > On Monday, January 9, 2017 at 2:07:13 AM UTC-6, Benjamin Moran wrote: >> >> Hi Charles, >> >> 1) No inherit limitations. Under the hood, it's functionally identical to >> the normal VertexDomains, except that it keeps it's own additional lists of >> starts/sizes for the VertexLists in the Domain, which are sorted. There >> should be no Alpha/transparency issues, since everything is rendered in >> order and will composite correctly. >> >> 2) This will be infinitely faster than OrderedGroups, *IF* you're doing >> more than a few groups. The reason being is that Groups in pyglet set and >> unset OpenGL state, and each Group reqires a seperate draw process. Pyglet >> consolidates Groups by default, so a batch with a lot of objects using the >> same TextureAtlas, etc. will usually all draw together - most of the time >> your objects will be similar and automatically grouped into the same draw >> call. By using OrderedGroup, you are forcing a seperate draw call for >> every single group. A few groups, like "background", "midsection", >> "foreground", etc. is fine, but it will fall on it's face if you try to do >> a lot. >> >> The performance question is not so simple: >> For basic benchmarks of static sprites, the draw speed for >> OrderedVertexDomain is identical to the normal VertexDomain. Drawing 20,000 >> sprites takes about 0.010ms (@ 90fps). It doesn't mat
Re: zsprites, or sorting sprites with the z buffer
Hey Charles, No worries. It's good to squash any bugs that might exist. First of all, are you using the latest version of the code? There wa a missing sort call that existed before, and would cause trouble. Unfortunately I haven't come across that issue, but I haven't stressed this code extensively in any of my personal projects. If it's at all possible, can you share an example of code that illustrates the problem? Even if it only happens sometimes, it would be a good start to track it down. Internally, the OrderedVertexDomain is quite simple. There is a single call to glMultiDrawArrays, which takes in two lists of starts/sizes, as well as primsize. The most crutial bit of the code is ensuring that these starts and sizes lists are regenerated when necessary. Basically any time you add, delete, migrate, or sort a vertex list, the domain is marked as dirty and is sorted before the next call. The only other thing I'm unsure of are the buffers + attributes that are bound before each call. I'm not very familar with that code (or honestly the deep OpenGL logic behind this), but it's a possibility that this is the cuprit. On Monday, February 20, 2017 at 4:26:11 AM UTC+9, Charles wrote: > > Hey Benjamin, I know it's been a while since our last posts, but I have > just started experimenting with the ordered sprite branch. Everything is > working perfect (performance, implementation, ordering) except one thing. > > Whenever a sprite uses the order attribute it will sometimes flicker. So > for an example I have my tiles with no order set, but in my 'game objects' > layer where everything is ordered by the order attribute. Unfortunately it > doesn't happen all the time, but when it does, it flickers all of the > ordered sprites every couple of seconds or so. > > Unfortunately it's hard to test since it's so inconsistent, majority of > the time it seems ok. Just wondering if you've run across this issue > before? Thanks. > > On Monday, January 9, 2017 at 2:07:13 AM UTC-6, Benjamin Moran wrote: >> >> Hi Charles, >> >> 1) No inherit limitations. Under the hood, it's functionally identical to >> the normal VertexDomains, except that it keeps it's own additional lists of >> starts/sizes for the VertexLists in the Domain, which are sorted. There >> should be no Alpha/transparency issues, since everything is rendered in >> order and will composite correctly. >> >> 2) This will be infinitely faster than OrderedGroups, *IF* you're doing >> more than a few groups. The reason being is that Groups in pyglet set and >> unset OpenGL state, and each Group reqires a seperate draw process. Pyglet >> consolidates Groups by default, so a batch with a lot of objects using the >> same TextureAtlas, etc. will usually all draw together - most of the time >> your objects will be similar and automatically grouped into the same draw >> call. By using OrderedGroup, you are forcing a seperate draw call for >> every single group. A few groups, like "background", "midsection", >> "foreground", etc. is fine, but it will fall on it's face if you try to do >> a lot. >> >> The performance question is not so simple: >> For basic benchmarks of static sprites, the draw speed for >> OrderedVertexDomain is identical to the normal VertexDomain. Drawing 20,000 >> sprites takes about 0.010ms (@ 90fps). It doesn't matter how many different >> order levels there are. If you try to use OrderedGroups, it takes over 3 >> seconds(!) to draw the same amount of sprites. >> >> That said, the actual sorting process does use some CPU. Any time you >> add/delete/migrate a sprite/vertex_list in an OrderedVertexDomain, it does >> a sort before the next draw. Even if you're doing this every frame, it's >> still good for thousands of sprites. I'm sure the sort process can be >> optimized a bit more. >> >> >> >> >> On Monday, January 9, 2017 at 10:24:14 AM UTC+9, Charles wrote: >>> >>> It's been a long time since I checked this thread, but it looks like >>> there has been quite a lot of progress since I last looked. I have tested >>> the test branch and so far I have found the ordering to work without issues. >>> >>> I guess my questions on the latest changes are: >>> 1) Are there any limitations for this? I know last I looked and tested >>> the z sprite issues, there were some alpha and transparency issues. >>> >>> 2) Have you done any benchmarks on ordered groups compared to this >>> method? How does having a lot of different sprites (hundreds) on various >>> order levels affect performance? >>> >>> Thanks for your work guys! >>> >> -- 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
Re: zsprites, or sorting sprites with the z buffer
Hey Benjamin, I know it's been a while since our last posts, but I have just started experimenting with the ordered sprite branch. Everything is working perfect (performance, implementation, ordering) except one thing. Whenever a sprite uses the order attribute it will sometimes flicker. So for an example I have my tiles with no order set, but in my 'game objects' layer where everything is ordered by the order attribute. Unfortunately it doesn't happen all the time, but when it does, it flickers all of the ordered sprites every couple of seconds or so. Unfortunately it's hard to test since it's so inconsistent, majority of the time it seems ok. Just wondering if you've run across this issue before? Thanks. On Monday, January 9, 2017 at 2:07:13 AM UTC-6, Benjamin Moran wrote: > > Hi Charles, > > 1) No inherit limitations. Under the hood, it's functionally identical to > the normal VertexDomains, except that it keeps it's own additional lists of > starts/sizes for the VertexLists in the Domain, which are sorted. There > should be no Alpha/transparency issues, since everything is rendered in > order and will composite correctly. > > 2) This will be infinitely faster than OrderedGroups, *IF* you're doing > more than a few groups. The reason being is that Groups in pyglet set and > unset OpenGL state, and each Group reqires a seperate draw process. Pyglet > consolidates Groups by default, so a batch with a lot of objects using the > same TextureAtlas, etc. will usually all draw together - most of the time > your objects will be similar and automatically grouped into the same draw > call. By using OrderedGroup, you are forcing a seperate draw call for > every single group. A few groups, like "background", "midsection", > "foreground", etc. is fine, but it will fall on it's face if you try to do > a lot. > > The performance question is not so simple: > For basic benchmarks of static sprites, the draw speed for > OrderedVertexDomain is identical to the normal VertexDomain. Drawing 20,000 > sprites takes about 0.010ms (@ 90fps). It doesn't matter how many different > order levels there are. If you try to use OrderedGroups, it takes over 3 > seconds(!) to draw the same amount of sprites. > > That said, the actual sorting process does use some CPU. Any time you > add/delete/migrate a sprite/vertex_list in an OrderedVertexDomain, it does > a sort before the next draw. Even if you're doing this every frame, it's > still good for thousands of sprites. I'm sure the sort process can be > optimized a bit more. > > > > > On Monday, January 9, 2017 at 10:24:14 AM UTC+9, Charles wrote: >> >> It's been a long time since I checked this thread, but it looks like >> there has been quite a lot of progress since I last looked. I have tested >> the test branch and so far I have found the ordering to work without issues. >> >> I guess my questions on the latest changes are: >> 1) Are there any limitations for this? I know last I looked and tested >> the z sprite issues, there were some alpha and transparency issues. >> >> 2) Have you done any benchmarks on ordered groups compared to this >> method? How does having a lot of different sprites (hundreds) on various >> order levels affect performance? >> >> Thanks for your work guys! >> > -- 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.
Re: zsprites, or sorting sprites with the z buffer
Hi Charles, 1) No inherit limitations. Under the hood, it's functionally identical to the normal VertexDomains, except that it keeps it's own additional lists of starts/sizes for the VertexLists in the Domain, which are sorted. There should be no Alpha/transparency issues, since everything is rendered in order and will composite correctly. 2) This will be infinitely faster than OrderedGroups, *IF* you're doing more than a few groups. The reason being is that Groups in pyglet set and unset OpenGL state, and each Group reqires a seperate draw process. Pyglet consolidates Groups by default, so a batch with a lot of objects using the same TextureAtlas, etc. will usually all draw together - most of the time your objects will be similar and automatically grouped into the same draw call. By using OrderedGroup, you are forcing a seperate draw call for every single group. A few groups, like "background", "midsection", "foreground", etc. is fine, but it will fall on it's face if you try to do a lot. The performance question is not so simple: For basic benchmarks of static sprites, the draw speed for OrderedVertexDomain is identical to the normal VertexDomain. Drawing 20,000 sprites takes about 0.010ms (@ 90fps). It doesn't matter how many different order levels there are. If you try to use OrderedGroups, it takes over 3 seconds(!) to draw the same amount of sprites. That said, the actual sorting process does use some CPU. Any time you add/delete/migrate a sprite/vertex_list in an OrderedVertexDomain, it does a sort before the next draw. Even if you're doing this every frame, it's still good for thousands of sprites. I'm sure the sort process can be optimized a bit more. On Monday, January 9, 2017 at 10:24:14 AM UTC+9, Charles wrote: > > It's been a long time since I checked this thread, but it looks like there > has been quite a lot of progress since I last looked. I have tested the > test branch and so far I have found the ordering to work without issues. > > I guess my questions on the latest changes are: > 1) Are there any limitations for this? I know last I looked and tested the > z sprite issues, there were some alpha and transparency issues. > > 2) Have you done any benchmarks on ordered groups compared to this method? > How does having a lot of different sprites (hundreds) on various order > levels affect performance? > > Thanks for your work guys! > -- 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.
Re: zsprites, or sorting sprites with the z buffer
It's been a long time since I checked this thread, but it looks like there has been quite a lot of progress since I last looked. I have tested the test branch and so far I have found the ordering to work without issues. I guess my questions on the latest changes are: 1) Are there any limitations for this? I know last I looked and tested the z sprite issues, there were some alpha and transparency issues. 2) Have you done any benchmarks on ordered groups compared to this method? How does having a lot of different sprites (hundreds) on various order levels affect performance? Thanks for your work guys! -- 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.
Re: zsprites, or sorting sprites with the z buffer
Great! As you can see in pyglet.graphics.vertexdomain.OrderedDomain, I moved all of the sorting stuff into it's own method. I tried to make the draw method as efficient as possible, but there might be some ways to speed up the sorting method. As it is, sorting is required under the following conditions: 1. A vertex_list/sprite gets added, deleted, or migrated to or from the batch/domain. 2. Any vertex_list/sprite's order attribute gets changed. As it stands, it's very similar to the standard VertexDomain except that it keeps it's own starts/sizes lists instead of using the lower level allocators lists. I think it would be nice to benchmark against VertexDomain to see how much of an impact this has. Maybe the following benchmarks would be a good start: 1. Creating several thousand sprites and moving them around each frame. No addition/deletion of anything, to avoid calling the sorting method. 2. The same test, but randomly delete/add sprites each frame. This will illustrate the sorting overhead. What do you think? On Friday, January 6, 2017 at 11:45:53 AM UTC+9, Josh wrote: > > I'm experimenting with this and it seems to be working so far. > > On Thursday, December 15, 2016 at 8:45:47 AM UTC-5, Benjamin Moran wrote: >> >> Hi guys, >> >> I was able to figure this out (I think). The solution was to just use >> glMultiDrawArrays, and forget about using glMultiDrawElements. The >> gl*Elements methods probably didn't make sense anyways, since the vertex >> lists are not really indexed anyway. With glMultiDrawArrays, we just need >> an array of the start + size of each vertex list. This information is >> pretty easily grabbed from each vertex list, so the implementation turned >> out to be very simple. Basically this: >> >> starts = [vert_list.start for vert_list in self._vertex_lists] >> sizes = [vert_list.get_size() for vert_list in self._vertex_lists] >> primcount = len(starts) >> starts = (GLint * primcount)(*starts) >> sizes = (GLsizei * primcount)(*sizes) >> glMultiDrawArrays(mode, starts, sizes, primcount) >> >> The starts and sizes can be moved out of the draw method so that this is >> only recalculated if the OrderedDomain is marked as dirty, and the >> sort_vertex_lists method is called. I'll probably do this soon. >> >> >> >> On Monday, December 12, 2016 at 6:54:23 PM UTC+9, Benjamin Moran wrote: >>> >>> Hi Elliot, >>> >>> That sounds pretty nice. The null triangles idea makes sense. I guess it >>> would be considered wasteful, but would be insignificant waste with even >>> semi-modern GPU memory. >>> I find the numpy stuff fascinating. I also love pyglet for being "pure >>> Python", as in only needing the standard library. I feel like there is a >>> need for pyglet in the Python world, but certainly a need for more focused >>> libraries like yours. >>> >>> >>> If you poke around my branch, you'll see it's fairly simple. It uses the >>> default vertex lists and allocator, so there is fragmentation when >>> deleting/migrating lists. I'm relying on the gl*Elements functions to draw >>> things out of the order in which they're allocated. >>> >>> The sort method is just a simple sort with lambda depth. The sort is >>> only called when a vertex lists depth attribute is changed, so it should >>> perform well if there aren't many changes. I hear the Python sort function >>> is fairly fast, but I've not benchmarked it. >>> >>> -- 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.
Re: zsprites, or sorting sprites with the z buffer
I'm experimenting with this and it seems to be working so far. On Thursday, December 15, 2016 at 8:45:47 AM UTC-5, Benjamin Moran wrote: > > Hi guys, > > I was able to figure this out (I think). The solution was to just use > glMultiDrawArrays, and forget about using glMultiDrawElements. The > gl*Elements methods probably didn't make sense anyways, since the vertex > lists are not really indexed anyway. With glMultiDrawArrays, we just need > an array of the start + size of each vertex list. This information is > pretty easily grabbed from each vertex list, so the implementation turned > out to be very simple. Basically this: > > starts = [vert_list.start for vert_list in self._vertex_lists] > sizes = [vert_list.get_size() for vert_list in self._vertex_lists] > primcount = len(starts) > starts = (GLint * primcount)(*starts) > sizes = (GLsizei * primcount)(*sizes) > glMultiDrawArrays(mode, starts, sizes, primcount) > > The starts and sizes can be moved out of the draw method so that this is > only recalculated if the OrderedDomain is marked as dirty, and the > sort_vertex_lists method is called. I'll probably do this soon. > > > > On Monday, December 12, 2016 at 6:54:23 PM UTC+9, Benjamin Moran wrote: >> >> Hi Elliot, >> >> That sounds pretty nice. The null triangles idea makes sense. I guess it >> would be considered wasteful, but would be insignificant waste with even >> semi-modern GPU memory. >> I find the numpy stuff fascinating. I also love pyglet for being "pure >> Python", as in only needing the standard library. I feel like there is a >> need for pyglet in the Python world, but certainly a need for more focused >> libraries like yours. >> >> >> If you poke around my branch, you'll see it's fairly simple. It uses the >> default vertex lists and allocator, so there is fragmentation when >> deleting/migrating lists. I'm relying on the gl*Elements functions to draw >> things out of the order in which they're allocated. >> >> The sort method is just a simple sort with lambda depth. The sort is only >> called when a vertex lists depth attribute is changed, so it should perform >> well if there aren't many changes. I hear the Python sort function is >> fairly fast, but I've not benchmarked it. >> >> -- 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.
Re: zsprites, or sorting sprites with the z buffer
Hi guys, I was able to figure this out (I think). The solution was to just use glMultiDrawArrays, and forget about using glMultiDrawElements. The gl*Elements methods probably didn't make sense anyways, since the vertex lists are not really indexed anyway. With glMultiDrawArrays, we just need an array of the start + size of each vertex list. This information is pretty easily grabbed from each vertex list, so the implementation turned out to be very simple. Basically this: starts = [vert_list.start for vert_list in self._vertex_lists] sizes = [vert_list.get_size() for vert_list in self._vertex_lists] primcount = len(starts) starts = (GLint * primcount)(*starts) sizes = (GLsizei * primcount)(*sizes) glMultiDrawArrays(mode, starts, sizes, primcount) The starts and sizes can be moved out of the draw method so that this is only recalculated if the OrderedDomain is marked as dirty, and the sort_vertex_lists method is called. I'll probably do this soon. On Monday, December 12, 2016 at 6:54:23 PM UTC+9, Benjamin Moran wrote: > > Hi Elliot, > > That sounds pretty nice. The null triangles idea makes sense. I guess it > would be considered wasteful, but would be insignificant waste with even > semi-modern GPU memory. > I find the numpy stuff fascinating. I also love pyglet for being "pure > Python", as in only needing the standard library. I feel like there is a > need for pyglet in the Python world, but certainly a need for more focused > libraries like yours. > > > If you poke around my branch, you'll see it's fairly simple. It uses the > default vertex lists and allocator, so there is fragmentation when > deleting/migrating lists. I'm relying on the gl*Elements functions to draw > things out of the order in which they're allocated. > > The sort method is just a simple sort with lambda depth. The sort is only > called when a vertex lists depth attribute is changed, so it should perform > well if there aren't many changes. I hear the Python sort function is > fairly fast, but I've not benchmarked it. > > -- 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.
Re: zsprites, or sorting sprites with the z buffer
Hi Elliot, That sounds pretty nice. The null triangles idea makes sense. I guess it would be considered wasteful, but would be insignificant waste with even semi-modern GPU memory. I find the numpy stuff fascinating. I also love pyglet for being "pure Python", as in only needing the standard library. I feel like there is a need for pyglet in the Python world, but certainly a need for more focused libraries like yours. If you poke around my branch, you'll see it's fairly simple. It uses the default vertex lists and allocator, so there is fragmentation when deleting/migrating lists. I'm relying on the gl*Elements functions to draw things out of the order in which they're allocated. The sort method is just a simple sort with lambda depth. The sort is only called when a vertex lists depth attribute is changed, so it should perform well if there aren't many changes. I hear the Python sort function is fairly fast, but I've not benchmarked it. -- 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.
Re: zsprites, or sorting sprites with the z buffer
How does it perform? I have not profiled the allocator. Being able to used numpy or numba vectorized operations to transform verticies was a massive performance improvement. Being able to have the rendering and game logic happen in separate processes (with multiprocessing) what use shared memory was a significant performance improvement. (for example, a 50 FPS physics simulation went to 600 FPS rendering and 180 physics time steps per second). Actually adding and deleting "vertex lists" from a Domain is likely very slow because much of the data gets shuffled around. IE: adding three elements that won't be next to each other involves reassigning six slices as it moves the data out of the way to make room and then inserts the new data. It would be an improvement if deleted areas just had null values assigned (ie, empty triangles), since if only some percentage of the buffer is "dead", it doesn't take much time to render empty triangles compared to shuffling data around. The fragmentation is only important because it simplifies and improves the performance of the numpy operations (they operate on contiguous arrays rather than indexing over arrays with dead values). I'll poke around your branch and see what your sorting/data shuffling code looks like. -Elliot On Sat, Dec 10, 2016 at 7:36 PM, Benjamin Moran wrote: > Hey Elliot, > > The defragmenting buffer sounds interesting. How does it perform? > > My solution to sorting was to keep a list of associated VertexLists in the > OrderedDomain. The VertexLists themselves all have a reference to their > parent domain (even if it's the default pyglet domain). Whenever any > VertexList's depth attribute was changed, the parent domain is marked as > dirty and gets sorted at the next draw call. It works fairly well, but I > didn't have time to figure out the glMultiDrawElements stuff. > > For an experiment I rebasing off of the IndexedVertexLists, but I > discovered that those seem to be broken. I don't know if this is just my > machine, but it seems like any batch/domain that contains indexed vertex > lists will fail to draw correctly if you delete any of the lists in the > middle of the order. Indexed vertex lists are not really necessary for the > sorting stuff, so I reverted back to plain vertex lists in my branch. > > > > > On Saturday, December 10, 2016 at 9:22:52 AM UTC+9, elliot wrote: >> >> Sounds like y'all are tackling the same issue I did when I wanted to do >> vectorized translations on vertex lists. I tried to use pyglets >> architecture but it was so tied to domains being dumb and not keeping track >> of what was in what they had allocated. This is for obvious performance >> reasons, but my idea didn't mesh at all. >> >> I made a defragmenting buffer that keeps track of each allocated entity, >> and an allocator that places new entities accordingly, rearranging the >> buffer as necessary. Everything (with a common gl state) is rendered with >> one glDrawArrays call. >> >> Sorry for the terse description. I'm on my phone. Let me know if I can >> help. I'd love if pyglet had native support for ordered, contiguous buffers >> that could interface with my entity component system. Maybe you can use >> some code from the allocator. Here's the project: >> >> https://github.com/Permafacture/data-oriented-pyglet >> >> Elliot >> > -- > 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. > -- 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.
Re: zsprites, or sorting sprites with the z buffer
Hey Elliot, The defragmenting buffer sounds interesting. How does it perform? My solution to sorting was to keep a list of associated VertexLists in the OrderedDomain. The VertexLists themselves all have a reference to their parent domain (even if it's the default pyglet domain). Whenever any VertexList's depth attribute was changed, the parent domain is marked as dirty and gets sorted at the next draw call. It works fairly well, but I didn't have time to figure out the glMultiDrawElements stuff. For an experiment I rebasing off of the IndexedVertexLists, but I discovered that those seem to be broken. I don't know if this is just my machine, but it seems like any batch/domain that contains indexed vertex lists will fail to draw correctly if you delete any of the lists in the middle of the order. Indexed vertex lists are not really necessary for the sorting stuff, so I reverted back to plain vertex lists in my branch. On Saturday, December 10, 2016 at 9:22:52 AM UTC+9, elliot wrote: > > Sounds like y'all are tackling the same issue I did when I wanted to do > vectorized translations on vertex lists. I tried to use pyglets > architecture but it was so tied to domains being dumb and not keeping track > of what was in what they had allocated. This is for obvious performance > reasons, but my idea didn't mesh at all. > > I made a defragmenting buffer that keeps track of each allocated entity, > and an allocator that places new entities accordingly, rearranging the > buffer as necessary. Everything (with a common gl state) is rendered with > one glDrawArrays call. > > Sorry for the terse description. I'm on my phone. Let me know if I can > help. I'd love if pyglet had native support for ordered, contiguous buffers > that could interface with my entity component system. Maybe you can use > some code from the allocator. Here's the project: > > https://github.com/Permafacture/data-oriented-pyglet > > Elliot > -- 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.
Re: zsprites, or sorting sprites with the z buffer
Sounds like y'all are tackling the same issue I did when I wanted to do vectorized translations on vertex lists. I tried to use pyglets architecture but it was so tied to domains being dumb and not keeping track of what was in what they had allocated. This is for obvious performance reasons, but my idea didn't mesh at all. I made a defragmenting buffer that keeps track of each allocated entity, and an allocator that places new entities accordingly, rearranging the buffer as necessary. Everything (with a common gl state) is rendered with one glDrawArrays call. Sorry for the terse description. I'm on my phone. Let me know if I can help. I'd love if pyglet had native support for ordered, contiguous buffers that could interface with my entity component system. Maybe you can use some code from the allocator. Here's the project: https://github.com/Permafacture/data-oriented-pyglet Elliot -- 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.
Re: zsprites, or sorting sprites with the z buffer
No worries about the time-frame. We're just experimenting here after all! As I understand it the OrderedGroups require a separate Domain.draw() call for each one, so it's pretty easy to see why they get slow when you use more than a few of them. I think the only work left to do is within the OrderedVertexList. The glDrawElements function that we're using works well with a contiguous Vertex list, but once you delete/migrate anything it doesn't work anymore. The glMultiDrawElements is the way to go, but it doesn't accept the simple integer index list like glDrawElements does. We can see that IndexedVertexList uses an actual buffer for the indexes instead of the simple integer list, which seems to be what glMultiDrawElements wants. I'm thinking that maybe it would be easier to base OrderedVertexList off of IndexedVertexList, instead of the simpler VertexList. On Thursday, December 8, 2016 at 6:18:50 AM UTC+9, Josh wrote: > > Hi Ben, > > I'll take a stab at it. Life is going to be hectic for a bit so I may not > get to it until January. I'll also try making a few benchmarks. My > suspicion is in almost all cases pyglet applications are CPU-bound, and > glDrawElements is just faster than using ordered groups. If we get this to > support migration, is there anything else that needs to be done for > backwards compatibility? > > On Sunday, December 4, 2016 at 9:03:14 AM UTC-6, Benjamin Moran wrote: >> >> Hey Josh, I've put this back on the back-burner for now, but It would be >> great if you wanted to keep at it. Anyone else with feedback would be >> welcome as well. The glMultiDrawElements index list was a little too much >> for me to figure out at the moment. >> >> I'm still considering that a simple zsprite implementation might be a >> good start, since it can probably be added without breaking any backwards >> compatibility. Having a z attribute wouldn't necessarily mean that the >> batch couldn't also be ordered if desired. >> >> >> On Wednesday, November 23, 2016 at 6:51:09 PM UTC+9, Benjamin Moran wrote: >>> >>> I ended up subclassing VertexList, and fixed the garbage collection >>> issue. I also added a vertex_index attribute to it, so during should be >>> faster. >>> >>> There are only two things left, which are: >>> 1. Migration. The code is there, but I don't think it's accurate. >>> 2. Handling of drawing OrderedVertexDomains with a primsize that is not >>> equal to 1. >>> >>> Number 2 is important, since drawing breaks if you delete vertex lists >>> from the middle (or migrated, if that worked). I haven't had time to figure >>> out glMultiDrawElements yet, which is what we need to use I think. Maybe a >>> different type of index list is needed. >>> >>> Feedback is appreciated. I'm thinking that maybe it would be a good idea >>> to benchmark this implementation before spending time finishing it up. >>> >>> -- 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.
Re: zsprites, or sorting sprites with the z buffer
Hi Ben, I'll take a stab at it. Life is going to be hectic for a bit so I may not get to it until January. I'll also try making a few benchmarks. My suspicion is in almost all cases pyglet applications are CPU-bound, and glDrawElements is just faster than using ordered groups. If we get this to support migration, is there anything else that needs to be done for backwards compatibility? On Sunday, December 4, 2016 at 9:03:14 AM UTC-6, Benjamin Moran wrote: > > Hey Josh, I've put this back on the back-burner for now, but It would be > great if you wanted to keep at it. Anyone else with feedback would be > welcome as well. The glMultiDrawElements index list was a little too much > for me to figure out at the moment. > > I'm still considering that a simple zsprite implementation might be a good > start, since it can probably be added without breaking any backwards > compatibility. Having a z attribute wouldn't necessarily mean that the > batch couldn't also be ordered if desired. > > > On Wednesday, November 23, 2016 at 6:51:09 PM UTC+9, Benjamin Moran wrote: >> >> I ended up subclassing VertexList, and fixed the garbage collection >> issue. I also added a vertex_index attribute to it, so during should be >> faster. >> >> There are only two things left, which are: >> 1. Migration. The code is there, but I don't think it's accurate. >> 2. Handling of drawing OrderedVertexDomains with a primsize that is not >> equal to 1. >> >> Number 2 is important, since drawing breaks if you delete vertex lists >> from the middle (or migrated, if that worked). I haven't had time to figure >> out glMultiDrawElements yet, which is what we need to use I think. Maybe a >> different type of index list is needed. >> >> Feedback is appreciated. I'm thinking that maybe it would be a good idea >> to benchmark this implementation before spending time finishing it up. >> >> -- 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.
Re: zsprites, or sorting sprites with the z buffer
Hey Josh, I've put this back on the back-burner for now, but It would be great if you wanted to keep at it. Anyone else with feedback would be welcome as well. The glMultiDrawElements index list was a little too much for me to figure out at the moment. I'm still considering that a simple zsprite implementation might be a good start, since it can probably be added without breaking any backwards compatibility. Having a z attribute wouldn't necessarily mean that the batch couldn't also be ordered if desired. On Wednesday, November 23, 2016 at 6:51:09 PM UTC+9, Benjamin Moran wrote: > > I ended up subclassing VertexList, and fixed the garbage collection issue. > I also added a vertex_index attribute to it, so during should be faster. > > There are only two things left, which are: > 1. Migration. The code is there, but I don't think it's accurate. > 2. Handling of drawing OrderedVertexDomains with a primsize that is not > equal to 1. > > Number 2 is important, since drawing breaks if you delete vertex lists > from the middle (or migrated, if that worked). I haven't had time to figure > out glMultiDrawElements yet, which is what we need to use I think. Maybe a > different type of index list is needed. > > Feedback is appreciated. I'm thinking that maybe it would be a good idea > to benchmark this implementation before spending time finishing it up. > > -- 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.
Re: zsprites, or sorting sprites with the z buffer
I ended up subclassing VertexList, and fixed the garbage collection issue. I also added a vertex_index attribute to it, so during should be faster. There are only two things left, which are: 1. Migration. The code is there, but I don't think it's accurate. 2. Handling of drawing OrderedVertexDomains with a primsize that is not equal to 1. Number 2 is important, since drawing breaks if you delete vertex lists from the middle (or migrated, if that worked). I haven't had time to figure out glMultiDrawElements yet, which is what we need to use I think. Maybe a different type of index list is needed. Feedback is appreciated. I'm thinking that maybe it would be a good idea to benchmark this implementation before spending time finishing it up. -- 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.
Re: zsprites, or sorting sprites with the z buffer
By the way, I guess you saw it already, but I modified your depth_sprite_test.py app in the root of the repository. Also, I think the cleanest way to fix the garbage collection issue caused by the OrderedVertexDomain._vertex_lists is probably by subclassing VertexList. A custom delete method can remove itself from the list, and the order attribute can be added so that OrderedVertexDomain.create can be neater. I'm curious just how slow this will be. I guess it all comes down to the sitting time, and glDrawArrays VS glDrawElements. -- 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.
Re: zsprites, or sorting sprites with the z buffer
Hey Josh,
As far as I understand it, the Batch is a group of domains that get drawn
together, or consolidated when possible. Also, it appears that there is
always a default batch, even if you don't explicitly create your own. The
additional code needed for Batch support was actually quite minimal
(assuming I didn't miss anything). In pyglet/graphics/__init__.py, I made
the following changes:
1. Added a new *Batch.add_ordered* method, underneith *Batch.add* and
*Batch.add_indexed*.
2. Modified *Batch._get_domain* so that it can create/return the
OrderedVertexDomain when requested.
3. Tweaked a few of the methods and the domain cache with an additional
*ordered=True* parameter, just like for *indexed=True*.
I accidentally left a *print("new domain")* in there, which illustrates the
consolidation that happens when the Sprites share the same TextureAtlas.
There is a bit more work to do in OrderedVertexDomain, such as the
migration code. Also, deleting vertex_lists probably won't work because of
the *OrderedVertexDomain._vertex_lists*.
On Monday, November 21, 2016 at 8:22:07 AM UTC+9, Josh wrote:
>
> Hi Ben,
>
> I like this solution for staying with the original API. Tested it with
> ordered groups and it still performs correctly. I'm missing a couple pieces
> in terms of how it works with batches, though. I can't find the code change
> that actually causes Batch to use OrderedVertexDomain - can you point me to
> it?
>
> On Saturday, November 19, 2016 at 8:30:59 AM UTC-6, Benjamin Moran wrote:
>>
>> Hi Josh,
>>
>> I took your work and ran with it a little, to see if it could be fit into
>> the existing api. So far, It seems to be going OK, but I would greatly
>> appreciate your feedback on this. I'm just kinda winging it here :)
>> You can find my "ordered_sprite" branch here:
>> https://bitbucket.org/treehousegames/pyglet/branch/ordered_sprite
>>
>> First of all, I implemented an OrderedVertexDomain which is a copy of
>> your OrderedDomain. The main difference is that it has it's own
>> vertex_lists list, and sorting method. It also has it's own "create"
>> method, which monkey patches an "order" attribute on the vertex_list, for
>> use by the sorting method. There is a simple "self.dirty" attribute that
>> determines if the vertex_lists list should be sorted automatically before
>> the next draw.
>>
>> By pushing all of that down the stack into the vertexdomain, The Sprite
>> and SpriteGroup classes could be left almost original. The only addition
>> being a "depth" property on the Sprite class which updates the vertex list
>> order attribute, and sets the domain to "dirty" so that it will be sorted
>> before the next draw.
>>
>> As for requiring all sprites to be on the same TextureAtlas for blending
>> to work correctly, that is still a requirement (no way around this in
>> OpenGL). However, it's up to the user to ensure this part. It would be
>> "automatic" if using the pyglet.resource module. If the user doesn't use a
>> single atlas, everything will still work fine - but of course sorting won't
>> work because they will be in different domains.
>>
>> I haven't tested any of it yet, but I think animations and such will work
>> fine since it's using the existing Groups and such.
>>
>> -Ben
>>
>>
>>
>> On Friday, November 18, 2016 at 5:46:52 AM UTC+9, Josh wrote:
>>>
>>> Hi Ben,
>>>
>>> There's no roadblock with migrating OrderedDomains, it's just something
>>> I skipped for now (similar to animation support). It will require going
>>> deeper into the weeds with pyglet's allocation system, and there are some
>>> aspects of that I still don't understand.
>>>
>>> Best,
>>>
>>> Josh
>>>
>>
--
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.
Re: zsprites, or sorting sprites with the z buffer
Hi Ben, I like this solution for staying with the original API. Tested it with ordered groups and it still performs correctly. I'm missing a couple pieces in terms of how it works with batches, though. I can't find the code change that actually causes Batch to use OrderedVertexDomain - can you point me to it? On Saturday, November 19, 2016 at 8:30:59 AM UTC-6, Benjamin Moran wrote: > > Hi Josh, > > I took your work and ran with it a little, to see if it could be fit into > the existing api. So far, It seems to be going OK, but I would greatly > appreciate your feedback on this. I'm just kinda winging it here :) > You can find my "ordered_sprite" branch here: > https://bitbucket.org/treehousegames/pyglet/branch/ordered_sprite > > First of all, I implemented an OrderedVertexDomain which is a copy of your > OrderedDomain. The main difference is that it has it's own vertex_lists > list, and sorting method. It also has it's own "create" method, which > monkey patches an "order" attribute on the vertex_list, for use by the > sorting method. There is a simple "self.dirty" attribute that determines if > the vertex_lists list should be sorted automatically before the next draw. > > By pushing all of that down the stack into the vertexdomain, The Sprite > and SpriteGroup classes could be left almost original. The only addition > being a "depth" property on the Sprite class which updates the vertex list > order attribute, and sets the domain to "dirty" so that it will be sorted > before the next draw. > > As for requiring all sprites to be on the same TextureAtlas for blending > to work correctly, that is still a requirement (no way around this in > OpenGL). However, it's up to the user to ensure this part. It would be > "automatic" if using the pyglet.resource module. If the user doesn't use a > single atlas, everything will still work fine - but of course sorting won't > work because they will be in different domains. > > I haven't tested any of it yet, but I think animations and such will work > fine since it's using the existing Groups and such. > > -Ben > > > > On Friday, November 18, 2016 at 5:46:52 AM UTC+9, Josh wrote: >> >> Hi Ben, >> >> There's no roadblock with migrating OrderedDomains, it's just something I >> skipped for now (similar to animation support). It will require going >> deeper into the weeds with pyglet's allocation system, and there are some >> aspects of that I still don't understand. >> >> Best, >> >> Josh >> > -- 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.
Re: zsprites, or sorting sprites with the z buffer
Hi Josh, I took your work and ran with it a little, to see if it could be fit into the existing api. So far, It seems to be going OK, but I would greatly appreciate your feedback on this. I'm just kinda winging it here :) You can find my "ordered_sprite" branch here: https://bitbucket.org/treehousegames/pyglet/branch/ordered_sprite First of all, I implemented an OrderedVertexDomain which is a copy of your OrderedDomain. The main difference is that it has it's own vertex_lists list, and sorting method. It also has it's own "create" method, which monkey patches an "order" attribute on the vertex_list, for use by the sorting method. There is a simple "self.dirty" attribute that determines if the vertex_lists list should be sorted automatically before the next draw. By pushing all of that down the stack into the vertexdomain, The Sprite and SpriteGroup classes could be left almost original. The only addition being a "depth" property on the Sprite class which updates the vertex list order attribute, and sets the domain to "dirty" so that it will be sorted before the next draw. As for requiring all sprites to be on the same TextureAtlas for blending to work correctly, that is still a requirement (no way around this in OpenGL). However, it's up to the user to ensure this part. It would be "automatic" if using the pyglet.resource module. If the user doesn't use a single atlas, everything will still work fine - but of course sorting won't work because they will be in different domains. I haven't tested any of it yet, but I think animations and such will work fine since it's using the existing Groups and such. -Ben On Friday, November 18, 2016 at 5:46:52 AM UTC+9, Josh wrote: > > Hi Ben, > > There's no roadblock with migrating OrderedDomains, it's just something I > skipped for now (similar to animation support). It will require going > deeper into the weeds with pyglet's allocation system, and there are some > aspects of that I still don't understand. > > Best, > > Josh > -- 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.
Re: zsprites, or sorting sprites with the z buffer
Thanks for the reply Josh, Pyglet's graphics module is a great piece of code, but I'd be lying if I said I fully understood it all either :) I haven't had time to really focus on this, but I've been poking around to see if we can fit the OrderedDomain into the existing API hierarchy. On Friday, November 18, 2016 at 5:46:52 AM UTC+9, Josh wrote: > > Hi Ben, > > There's no roadblock with migrating OrderedDomains, it's just something I > skipped for now (similar to animation support). It will require going > deeper into the weeds with pyglet's allocation system, and there are some > aspects of that I still don't understand. > > Best, > > Josh > -- 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.
Re: zsprites, or sorting sprites with the z buffer
Hi Ben, There's no roadblock with migrating OrderedDomains, it's just something I skipped for now (similar to animation support). It will require going deeper into the weeds with pyglet's allocation system, and there are some aspects of that I still don't understand. Best, Josh -- 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.
Re: zsprites, or sorting sprites with the z buffer
Hi Josh, I've been poking through your code, looking at Batch support. Was there a roadblock you ran into with OrderedDomain migration support, or you just skipped that for now? -Ben On Wednesday, November 2, 2016 at 1:48:04 AM UTC+9, Josh wrote: > > Hi Benjamin, > > When you say solid and translucent textures, are you assuming that the > entire texture is one or the other? The problem I had that I couldn't solve > with depth-invariant rendering order was with sprites that mix the two. > This is actually a much more common use case than it sounds: any > antialiased sprite that isn't a perfect rectangle will have translucent > boundaries. When I try to render these using depth testing and alpha > threshholding with these sprites, I wind up with really hideous artifacts > at the outlines. Did you find a solution to this? I would love to learn > more. > -- 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.
Re: zsprites, or sorting sprites with the z buffer
Hi Josh, You're probably right. I've only been testing with colored primitives and pixel-art style textures. When I say "solid", I mean textures that are opaque and might have pure transparency (basically 1 or 0 alpha only, like the "examples/pyglet.png" file). When I say translucency, I mean something like a glass window that has variable levels of opacity (like you get with the .opacity attribute on pyglet.Sprites). I'll have to make up some more varied test textures to really see how things look. My hope was that there is a way to make the current unordered batches work acceptably, even if it requires a few set/unset_state calls per draw. Something like depth peeling is probably overkill, and we'd be better off going with ordered batches similar to what you're working on. -Ben On Wednesday, November 2, 2016 at 1:48:04 AM UTC+9, Josh wrote: > > Hi Benjamin, > > When you say solid and translucent textures, are you assuming that the > entire texture is one or the other? The problem I had that I couldn't solve > with depth-invariant rendering order was with sprites that mix the two. > This is actually a much more common use case than it sounds: any > antialiased sprite that isn't a perfect rectangle will have translucent > boundaries. When I try to render these using depth testing and alpha > threshholding with these sprites, I wind up with really hideous artifacts > at the outlines. Did you find a solution to this? I would love to learn > more. > -- 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.
Re: zsprites, or sorting sprites with the z buffer
Hi Benjamin, When you say solid and translucent textures, are you assuming that the entire texture is one or the other? The problem I had that I couldn't solve with depth-invariant rendering order was with sprites that mix the two. This is actually a much more common use case than it sounds: any antialiased sprite that isn't a perfect rectangle will have translucent boundaries. When I try to render these using depth testing and alpha threshholding with these sprites, I wind up with really hideous artifacts at the outlines. Did you find a solution to this? I would love to learn more. -- 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.
Re: zsprites, or sorting sprites with the z buffer
Hi Josh,
Nice work, if a bit different from how the batches and groups are currently
used within pyglet.
I was looking over your code, and thinking about your texture atlases
implementation. The current sprite groups are combined if possible if they
share the same textures, so I was thinking about how to utilize this with
your implementation.
I've also been reading up on different "order independent translucency"
techniques, and realized that my quick zsprite hack does already do basic
translucency correctly if you simply make sure to render all of the solid
or simple transparent (1/0) textures first. This can easily be done by
using the existing OrderedGroups, but putting all "solid" textures in one
group, and all textues that need translucency in another. So basically, two
OrderedGroups for all sprites. For example:
solid = pyglet.graphics.OrderedGroup(0)
translucent = pyglet.graphics.OrderedGroup(1)
pyglet_image = pyglet.image.load("examples/pyglet.png")
spritea = pyglet.sprite.Sprite(img=pyglet_image, x=120, y=150, z=3,
batch=batch, group=translucent)
spriteb = pyglet.sprite.Sprite(img=pyglet_image, x=140, y=170, z=2,
batch=batch, group=translucent)
spritec = pyglet.sprite.Sprite(img=pyglet_image, x=160, y=190, z=1,
batch=batch, group=solid)
sprited = pyglet.sprite.Sprite(img=pyglet_image, x=180, y=210, z=0,
batch=batch, group=solid)
spritea.opacity = 200
spriteb.opacity = 200
This all works as expected, with the normal blending quirks. I wonder if
this might be enough? It wouldn't be hard to tweak the SpriteGroup more so
that Sprite.opacity == 0 sprites are automatically in one group, and
sprites with non-0 opacity values are in another.
On Monday, October 24, 2016 at 9:54:24 AM UTC+9, Josh wrote:
>
> Got up to the initial test working. Animations are NOT supported right
> now. Batches are not supported and there's really no point in supporting
> them with this pipeline. The basic method for rendering sprites that you
> want to have sorted is:
>
> group = pyglet.sprite.DepthSpriteGroup(2048, 2048) #the size of the
> texture atlas
> #load some image as img
> my_sprites = [pyglet.sprite.DepthSprite(img, group, x=i*10) for i in range
> (10)]
> window = pyglet.window.Window(500, 500)
> @window.event
> def on_draw():
> window.clear()
> group.draw()
>
> Note that sprites are bound to their group, and can't be migrated between
> groups. Each sprite has a depth attribute that controls rendering order.
> There is a self-contained test depth_sprite_test.py. Appreciate anyone who
> who can give it a shot!
>
> - Josh
>
> On Sunday, October 23, 2016 at 5:49:23 PM UTC-5, Josh wrote:
>>
>> Hi, sorry I've been out of the loop a few days. I put the fork on
>> bitbucket, https://bitbucket.org/clockmarket/zsprites
>>
>> On Friday, October 21, 2016 at 3:43:14 AM UTC-5, Benjamin Moran wrote:
>>>
>>> If it's a public fork, it works be great if you could share the link.
>>
>>
--
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.
Re: zsprites, or sorting sprites with the z buffer
Got up to the initial test working. Animations are NOT supported right now. Batches are not supported and there's really no point in supporting them with this pipeline. The basic method for rendering sprites that you want to have sorted is: group = pyglet.sprite.DepthSpriteGroup(2048, 2048) #the size of the texture atlas #load some image as img my_sprites = [pyglet.sprite.DepthSprite(img, group, x=i*10) for i in range( 10)] window = pyglet.window.Window(500, 500) @window.event def on_draw(): window.clear() group.draw() Note that sprites are bound to their group, and can't be migrated between groups. Each sprite has a depth attribute that controls rendering order. There is a self-contained test depth_sprite_test.py. Appreciate anyone who who can give it a shot! - Josh On Sunday, October 23, 2016 at 5:49:23 PM UTC-5, Josh wrote: > > Hi, sorry I've been out of the loop a few days. I put the fork on > bitbucket, https://bitbucket.org/clockmarket/zsprites > > On Friday, October 21, 2016 at 3:43:14 AM UTC-5, Benjamin Moran wrote: >> >> If it's a public fork, it works be great if you could share the link. > > -- 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.
Re: zsprites, or sorting sprites with the z buffer
Hi, sorry I've been out of the loop a few days. I put the fork on bitbucket, https://bitbucket.org/clockmarket/zsprites On Friday, October 21, 2016 at 3:43:14 AM UTC-5, Benjamin Moran wrote: > > If it's a public fork, it works be great if you could share the link. -- 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.
Re: zsprites, or sorting sprites with the z buffer
If it's a public fork, it works be great if you could share the link. -- 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.
Re: zsprites, or sorting sprites with the z buffer
I cloned the repo, working on a Zsprite branch. -- 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.
Re: zsprites, or sorting sprites with the z buffer
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,
Re: zsprites, or sorting sprites with the z buffer
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.
Re: zsprites, or sorting sprites with the z buffer
Sorry for the delay! How would you prefer to move forward on this? Would you prefer me make a branch that you could clone, or just clone to repo and start your own branch for now? On Friday, October 14, 2016 at 12:05:55 PM UTC+9, Josh wrote: > > I'd be willing to give it a shot. > > On Tuesday, October 4, 2016 at 9:03:57 AM UTC-5, Benjamin Moran wrote: >> >> Thanks for your insite with regards to DrawArrays/DrawElements. There is >> a lot of old bickering online about how one or the other is "better", but >> not so much recent discussion. >> >> I think having the separate implementation of these things is a good idea >> for a start. I don't think anyone would want to have two seperate >> implementations side by side in the long run, but it's nice to compare side >> by side. I think you've already worked out most of the messy stuff, so it >> would be a matter of seeing if this implementation is feasable if we add in >> some fallbacks to keep things simple. For example, pyglet is really fast if >> you use a batch, and rely on the resources module to load your images. It >> still works fine, however more slowly, if you are ignorant of that and load >> all of your textures manually. >> >> I have other things on my plate at the moment, but if you're keen to help >> make this happen we could open a new branch to experiment in. Let me know >> what you think. >> >> >> >> >> On Tuesday, October 4, 2016 at 5:17:08 AM UTC+9, 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).
Re: zsprites, or sorting sprites with the z buffer
I'd be willing to give it a shot. On Tuesday, October 4, 2016 at 9:03:57 AM UTC-5, Benjamin Moran wrote: > > Thanks for your insite with regards to DrawArrays/DrawElements. There is a > lot of old bickering online about how one or the other is "better", but not > so much recent discussion. > > I think having the separate implementation of these things is a good idea > for a start. I don't think anyone would want to have two seperate > implementations side by side in the long run, but it's nice to compare side > by side. I think you've already worked out most of the messy stuff, so it > would be a matter of seeing if this implementation is feasable if we add in > some fallbacks to keep things simple. For example, pyglet is really fast if > you use a batch, and rely on the resources module to load your images. It > still works fine, however more slowly, if you are ignorant of that and load > all of your textures manually. > > I have other things on my plate at the moment, but if you're keen to help > make this happen we could open a new branch to experiment in. Let me know > what you think. > > > > > On Tuesday, October 4, 2016 at 5:17:08 AM UTC+9, 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 hav
Re: zsprites, or sorting sprites with the z buffer
Thanks for your insite with regards to DrawArrays/DrawElements. There is a lot of old bickering online about how one or the other is "better", but not so much recent discussion. I think having the separate implementation of these things is a good idea for a start. I don't think anyone would want to have two seperate implementations side by side in the long run, but it's nice to compare side by side. I think you've already worked out most of the messy stuff, so it would be a matter of seeing if this implementation is feasable if we add in some fallbacks to keep things simple. For example, pyglet is really fast if you use a batch, and rely on the resources module to load your images. It still works fine, however more slowly, if you are ignorant of that and load all of your textures manually. I have other things on my plate at the moment, but if you're keen to help make this happen we could open a new branch to experiment in. Let me know what you think. On Tuesday, October 4, 2016 at 5:17:08 AM UTC+9, 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
Re: zsprites, or sorting sprites with the z buffer
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.
Re: zsprites, or sorting sprites with the z buffer
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.
Re: zsprites, or sorting sprites with the z buffer
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.
