I'm not communicating clearly, I think. What I really need is a method to modify pyglet's batch draw methods so that the batch guarantees a particular ordering - whether that order is calculated on the CPU or GPU is not important. Sorting in python is trivial. Making a few thousand OpenGL calls via sprite.draw() every frame is not.
So, for example, it looks like pyglet uses glDrawArray for batches. Maybe the best approach is to build an implementation using glMultiDrawElements and expose that with a draw_list method in batch that will construct the correct index list for vertices. My problem doing this is that it requires tracking which vertices belong to which sprite at the VertexDomain level, and I am still foggy as hell about how the vertex data from a sprite actually gets into a VertexDomain. But I'll keep reading. On Tuesday, December 8, 2015 at 5:49:14 PM UTC-6, swiftcoder wrote: > > It's not OpenGL's problem, to sort your draw calls. > > You can certainly sort a few thousand sprites by their z value every frame > - since you resort every frame, the list will always be mostly sorted > already, and an algorithm like merge sort will perform very well. > On Tue, Dec 8, 2015 at 3:03 PM Josh <[email protected] <javascript:>> > wrote: > >> As you say, that really only works if you never have overlapping sprites >> in the same layer - for example, you never let a character walk behind some >> trees. That's pretty limiting aesthetically. It would be nice if there was >> a way to just give sprites a floating point "z" value (not actually an >> OpenGL coordinate) that determines rendering order, rather than the >> discrete ordered groups we have to use currently. Then in an orthographic >> view you just implement a map y -> z. But maybe sorting by a floating point >> every frame is not something that can be done efficiently in OpenGL? >> >> >> On Monday, December 7, 2015 at 11:04:23 PM UTC-6, swiftcoder wrote: >>> >>> Traditionally one just organizes one's tiles such that they are rendered >>> from back-to-front, with either alpha test or alpha blending, depending on >>> how your sprites were designed to be combined. >>> >>> The depth buffer is primarily useful when individual meshes may be >>> self-intersecting, two meshes mutually overlapping, or other such exotic >>> situation that naturally arises in 3D. Rendering in 2D, the depth buffer is >>> usually overkill, and plain old sorting is both cheaper and more reliable. >>> >>> It also greatly simplifies tile management of one can arrange them in >>> layers. Say, an opaque terrain layer, an alpha-tested layer for trees or >>> environmental props, and an alpha-blended layer for characters and npcs... >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "pyglet-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
