Depth buffer for tile sorting?

[Ben Sizer]

Am I right in thinking there is no explicit depth-buffer support in
pyglet?

I have a tile-game which has some raised tiles which obscure the tile
behind them. I was hoping to be able to render the ground tiles as
Sprites, and then the character Sprites on top. But this won't work
when the character is behind the raised tile as they just get drawn in
front of that tile.

It doesn't lend itself well to a simple layers scheme as I would need
2 layers per row of tiles, one for the tiles and one for the
characters. On a big map that would be awkward and maybe slow.

The quickest way to do this both in terms of code and in rendering
speed would probably be to have Z values for the tiles and characters.
But I can't see any easy way of doing this.

Does anybody have any suggestions? Perhaps there is code for a custom
Group class to do this?

--
Ben Sizer

[Tristam MacDonald]

On Fri, Oct 2, 2009 at 6:18 PM, Ben Sizer <kyl...@gmail.com> wrote:

Does anybody have any suggestions? Perhaps there is code for a custom
Group class to do this?

--
Ben Sizer

A simple solution would be to have one OrderedGroup for each layer. It isn't immediately clear to me why you would need a separate group per row - unless adjacent tiles overlap?

--
Tristam MacDonald
http://swiftcoder.wordpress.com/

[Florian Bösch]

On Oct 3, 12:18 am, Ben Sizer <kylo...@gmail.com> wrote:
> Am I right in thinking there is no explicit depth-buffer support in
> pyglet?

I've got no idea what you mean by "explicit depth-buffer"

However, you could enable depth tests and give your sprites different
Z values to get opengl to draw some on top of others.
You could use ordered groups if that fits your fancy.
You could write a vertex shader that derives the Z value from they Y
value, thereby making unecessary to maintain Z yourself (assuming you
mean ordering by Y
You could setup a slightly skewed orthographic projection where the Y
component would contribute to the modelview transformed Z

[Ben Sizer]

On Oct 3, 12:32 am, Tristam MacDonald <swiftco...@gmail.com> wrote:
> A simple solution would be to have one OrderedGroup for each layer. It isn't
> immediately clear to me why you would need a separate group per row - unless
> adjacent tiles overlap?

Tiles have different heights, which means a tile closer to the viewer
can partially obscure the one behind it on the next row up, as well as
any characters/obstacles on it. So basically the simple 'layer' scheme
doesn't work.

I could start splitting tiles into different layers according to their
height, but that starts getting awkward. Being able to use one z-value
per tile would solve this.

--
Ben Sizer

[Ben Sizer]

On Oct 3, 10:26 am, Florian Bösch <pya...@gmail.com> wrote:
> On Oct 3, 12:18 am, Ben Sizer <kylo...@gmail.com> wrote:> Am I right in thinking there is no explicit depth-buffer support in
> > pyglet?
>
> I've got no idea what you mean by "explicit depth-buffer"

I mean explicit support for the depth buffer, not support for an
explicit depth buffer (whatever that may be!)

> However, you could enable depth tests and give your sprites different
> Z values to get opengl to draw some on top of others.
> You could use ordered groups if that fits your fancy.

Basically I'm asking if someone has done this already - I am not
familiar enough with how to write my own groups or how to hack the
pyglet sprites to get them to use a z-value. I can enable the depth
buffer and testing without a problem - the issue is how to get
pyglet's sprite system to make use of this.

> You could write a vertex shader that derives the Z value from they Y
> value, thereby making unecessary to maintain Z yourself (assuming you
> mean ordering by Y
> You could setup a slightly skewed orthographic projection where the Y
> component would contribute to the modelview transformed Z

This is all a bit complex for me, unfortunately. I just want to be
able to render a sprite using the normal pyglet calls with an
arbitrary z value of my choice, no shaders or custom projections. Can
you or anybody else suggest a method for me to be able to do this?

--
Ben Sizer

[Alejandro Castellanos]

Hello. If I understand correctly your situation, you can easily do
that using ordered groups and it really isn't that complicated.

If it's a side-scroller that you want, I think I might be able to lend
you a hand with this little code:
#
#
#
import pyglet

batch = pyglet.graphics.Batch()# I defined a batch(a "box" where you
store Sprites)...

"""What follows is so we can have a very specific order in which we
want the elements of the batch to be drawn(kind of like using
layers)."""

"""Now, I create two groups, unoe called background, and another
called foreground, and I give them number labels, 0 and 1. 0 will
always be drawn first and 1 one will always be drawn later; to put
it more succintly, background is always drawn first and foreground
second."""

background = pyglet.graphics.OrderedGroup(0)
foreground = pyglet.graphics.OrderedGroup(1)


"""I define my sprites:"""

image1_image = pyglet.image.load('image1.jpg')#just put an image named
image 1 somewehere in the same folder as this program(a jpg in this
case).

sprite1 = pyglet.sprite.Sprite(image1_image, x=0, y=0, batch=batch,
group = background)#Notice how I had to specify the batch I'm using,
and the group that background goes in, in the last two fields of this
line.

image2_image = pyglet.image.load('image2.jpg')#just put an image named
image 2 somewehere in the same folder as this program(a jpg in this
case).

sprite2 = pyglet.sprite.Sprite(image2_image, x=0, y=0, batch=batch,
group = foreground)#Notice how I had to specify the batch I'm using,
and the group that background goes in, in the last two fields of this
line.

window = pyglet.window.Window(800,533,resizable=True)

@window.event
def on_draw():
batch.draw()#Basically you draw the box, which draws the sprites
you want, and in the order of their respective groups' order.

pyglet.app.run()
#
#
#


Hoped that helped you. Using batches and groups is not as daunting as
it seems at first hand, just give it a spit with some help of this
little code

[Ben Sizer]

On Oct 4, 8:56 pm, Alejandro Castellanos <uberbomber...@gmail.com>
wrote:

> Hello. If I understand correctly your situation, you can easily do
> that using ordered groups and it really isn't that complicated.

Unfortunately I don't think you understand my situation correctly :)
But that's ok, I think a few others have the same problem, so my
explanation is lacking.

See this picture: http://lostgarden.com/uploaded_images/CuteGodMockup-723198.jpg

This particular example is a bit misleading because it is built up of
explicit layers. Instead of a simple background and foreground, there
are 4 or 5 'background' layers and then characters and obstacles are
drawn on top.

But look at the ramp near the top of the middle of the picture. It
obscures the view of the house behind it, even though both are on the
same vertical level and would intuitively go on the same layer - ie.
in the same ordered group. To get that to work the way I'd expect, I'd
not just need to order objects vertically, but also from front to
back. To do this, I would appear to require (height x depth) ordered
groups, since pyglet.graphics.OrderedGroup doesn't appear to guarantee
ordering within a group, only between groups. (The same seems to be
implied at http://www.pyglet.org/doc/programming_guide/displaying_images.html#sprites.)

This is pretty awkward to implement, especially when characters move
around and change group. It's probably inefficient too (since I have
to interleave rendering of terrain with characters instead of being
able to do all of one and then all of the other). More efficient would
be a z-buffer based approach, but I am open to alternatives.

--
Ben Sizer

[Tristam MacDonald]

On Mon, Oct 5, 2009 at 6:40 AM, Ben Sizer <kyl...@gmail.com> wrote:

This is pretty awkward to implement, especially when characters move
around and change group. It's probably inefficient too (since I have
to interleave rendering of terrain with characters instead of being
able to do all of one and then all of the other). More efficient would
be a z-buffer based approach, but I am open to alternatives.

I agree with you fully on the depth buffer approach, which allows a single group, with height * depth z-layers.

There was some discussion a while ago about adding a z-coordinate to all Sprites, but I don't think it was ever resolved.

The easiest route would be to subclass pyglet.sprite.Sprite to add a z-coodinate, and override the rendering methods as necessary to set it.

[Casey Duncan]

+1 on adding an (optional) z coordinate to sprites, specifying z-index
explicitly for 2D games is pretty important methinks. Aside from being
able to leverage the depth buffer, you could also add functionality
renders sprites in depth-order when composing with transparency.

Also on a side note, last time I checked sprites used integer vertex
coordinates. That always seemed weird to me, as it doesn't allow
leveraging sub-pixel rendering and makes movement along oblique angles
inaccurate if you use the sprite coordinate as the authoritative
position. Is there a good reason for them to be integers, or am I just
smoking crack (again)?

-Casey

[Alejandro Castellanos]

Frak...

Now I understand the problem...and it is EXACTLY the one problem that
I'm having just right now. I created a topic that somewhat treaded the
same grounds as these, but I was trying to use ordered groups.

Crap, this means things are way more complicated than I thought.

There go my rpg aspirations. I'll have to settle with sidescrollers or
fighting games, then...

Or maybe I'll keep hacking at the ordered groups, who knows.

On 5 oct, 09:45, Casey Duncan <casey.dun...@gmail.com> wrote:
> +1 on adding an (optional) z coordinate to sprites, specifying z-index
> explicitly for 2D games is pretty important methinks. Aside from being
> able to leverage the depth buffer, you could also add functionality
> renders sprites in depth-order when composing with transparency.
>
> Also on a side note, last time I checked sprites used integer vertex
> coordinates. That always seemed weird to me, as it doesn't allow
> leveraging sub-pixel rendering and makes movement along oblique angles
> inaccurate if you use the sprite coordinate as the authoritative
> position. Is there a good reason for them to be integers, or am I just
> smoking crack (again)?
>
> -Casey
>

> On Mon, Oct 5, 2009 at 6:01 AM, Tristam MacDonald <swiftco...@gmail.com> wrote:

[Richard Jones]

On 06/10/2009, at 3:45 AM, Casey Duncan wrote:
> Also on a side note, last time I checked sprites used integer vertex
> coordinates. That always seemed weird to me, as it doesn't allow
> leveraging sub-pixel rendering

You say "leveraging", I say "the visual errors that usually result
from" :)

Sub-pixel rendering requires a lot of manual effort to ensure there's
no strange visual artefacts on the borders. Hence the standard Sprite
implementation avoids it.

Richard

[Brian Fisher]

On Mon, Oct 5, 2009 at 4:29 PM, Richard Jones <r1char...@gmail.com> wrote:

Sub-pixel rendering requires a lot of manual effort to ensure there's
no strange visual artefacts on the borders. Hence the standard Sprite
implementation avoids it.

Richard, can you elaborate a bit on what you mean? I'm assuming you are mean when the edges of a sprite either blackening or whitening as the sprite moves on subpixel coordinates?

...If you are, then I think what you are talking about is what happens when pixels are bilinearly interpolated from an opaque to a transparent pixel in the common RGBA color and blending model (dest = src*alpha + dest*(1-alpha)). It's not just a problem for subpixel - it's also a problem for scaling and rotation, so avoiding subpixel rendering is a bad way to "solve" the problem. Also, that border problem, is solved extremely easily, without a lot of "manual" effort, simply by using the (poorly named) "premultiplied alpha" for your textures and colors passed to gl and using the appropriate blending model (dest = src + dest*(1-alpha))

The basic problem is that in the type of RGBA photoshop uses, a color like (0,0,0,0) has a bizarre meaning that can't be mapped to the real world - the pixel is both fully transparent and completely black. But when people use that color, they usually just intend to mean fully transparent, and most of the time they happily live with the delusion of (0,0,0,0) meaning a transparent pixel cause the truth doesn't matter (like when they use integer sprite positions)

... but then in comes bilinear filter - which says interpolate linearly from one color to the other on RGBA independently... so when (0,0,0,0) meets, say, a fully yellow pixel (255,255,0,255), and they get interpolated evenly, you get (128,128,0,128), which is a half transparent, brown pixel. suddenly, that nice sharp yellow border of your sprite becomes a brown muddy mess as you sprite slides half a pixel over... all of a sudden, the fact that what you thought was transparent, was actually transparent black, comes into play, and "strange visual artefacts" occur.

Contrast that with "premultiplied alpha" (I like to call it light-opacity RGBA). In this model, the source color gets added to the dest without being multiplied by alpha - in this way, the RGB channels mean simply what to add when you are drawing. The Alpha channel on the other hand, gets multiplied by the dest to take away it's RGB. In this way, the alpha means simply how much of the dest to block, or what the "opacity" of what you are drawing is. So now when you say (0,0,0,0), you are saying to add no color (no light, really), and to take none of the original value away. That actually means transparent, which is what most people really want when they give that value - there's no color to the transparency to confuse things.

So now what happens when bilinear filter comes in, and blends your full yellow opaque pixel (255,255,0,255) halfway to your transparent pixel (0,0,0,0) in the light-opacity (premultiplied alpha) model? well bilinear filter didn't change, so you get the same numbers: (128,128,0,128). But the new model makes it mean a very different thing - now that value means take half of the dest away, and add in half a yellow. expressed in the common RGBA model, it's be the same as (255,255,0,128), or a half transparent yellow. No "strange visual artefacts" on your sharp yellow edge this time...

note that this model is nothing new - it's very common in 3d multipass rendering (even if people using it aren't fully aware why), it's the normal format 3d studio max always wrote to tga's in, and it's been in papers and such. Lots of hardware accelerated games on all kinds of platforms use it specifically because in light-opacity/premultiplied model, bilinear filtering actualy works right - it does what they actually wanted it to do with transparent and opaque pixels.

...Also, the problem with common RGBA blending going wrong is also an old problem lots of people have struggled with. If the art uses (255,255,255,0) edges whiten instead of blacken, and the fact the difference between (255,255,255,0) and (0,0,0,0) is not visible, has led to a lot of confusion. Quite often, artists have worked around the problem by extended their colors from the edges out to color the transparent pixels so they will blend right, just assuming it's what needs to be done - but it's sad so much effort was applied to something that should have been fixed with using better math. It's actually a very simple thing to do to convert existing stuff over to it (just convert pixels before you upload them to the card, convert your colors before passing them to the card, and change the gl blending model), and I've done it in a few games shortly before they ship (games in beta, for ones using openGL, directX and wii hardware rendering), without messing up the schedule at all.


...if on the other hand, you didn't mean the edges blackening/whitening as sprites move subpixel, I'm really curious to hear (or see) what it is you were thinking of :)

[Mikael Lind]

Hi,

I wrote a patch a few weeks (months?) ago that adds a "subpixel"
option to pyglet sprites. It's attached to the issue tracker:

http://code.google.com/p/pyglet/issues/detail?id=371

Regards,
Mikael

2009/10/6 Richard Jones <r1char...@gmail.com>:

--
Mikael Lind
http://elemel.se/

[claudio canepa]

On Tue, Oct 6, 2009 at 3:44 AM, Brian Fisher <thor...@gmail.com> wrote:

On Mon, Oct 5, 2009 at 4:29 PM, Richard Jones <r1char...@gmail.com> wrote:

Sub-pixel rendering requires a lot of manual effort to ensure there's
no strange visual artefacts on the borders. Hence the standard Sprite
implementation avoids it.

Richard, can you elaborate a bit on what you mean? I'm assuming you are mean when the edges of a sprite either blackening or whitening as the sprite moves on subpixel coordinates?

 

[snip detailed bilinear interpolation problem description and fix] 

 

...if on the other hand, you didn't mean the edges blackening/whitening as sprites move subpixel, I'm really curious to hear (or see) what it is you were thinking of :)

 

Thanks Brian for such detailed problem description and solution, that is valuable info.

I appreciate the time you took to wrote it.

Having know the Richard push for int coords, I vaguely associate it with cracks between tiles, or problems in layout gui elements with proportional coords, but I have not seen a concrete discussion or demo case.

Really would be good if Richard can give some details :)

  

In a tangential note, coming to produce some demo from the vague ideas, I started to draw a board with a naive approach to later experiment. ( attached pyglet_board.py , tile.png)

In a sense, intyfing stabilizes the visuals while scrolling. ( set yourself the flag in the code to try, note that the code takes extra steps to maintain ints).

But I think the naive approach, which works well in fixed resolution raster render, is not adequate to openGL rendering: associating a mesh with the board seems more sensible (untested).

But I doubt Richard was referencing a situation like this.

--

claudio

[Richard Jones]

On 06/10/2009, at 5:44 PM, Brian Fisher wrote:

On Mon, Oct 5, 2009 at 4:29 PM, Richard Jones <r1char...@gmail.com> wrote:

Sub-pixel rendering requires a lot of manual effort to ensure there's
no strange visual artefacts on the borders. Hence the standard Sprite
implementation avoids it.

<snip lengthy discussion of various rendering errors and workarounds>

The Sprite module is intended to be used by people who don't necessarily even know what sub-pixel positioning is, let alone what the rendering repercussions are and certainly not how to avoid them.

       Richard

[Tristam MacDonald]

That sounds like a solid justification for expanding the documentation or adding an FAQ item, but not so much for restricting to integer coordinates.

In the spirit of full disclosure, I will mention that all of my 2D pyglet projects to date have used a replacement sprite class, partly to gain sub-pixel positioning, and partly to gain proper animation support (i.e. seek, loop and pause).

[Brian Fisher]

I think you are completely missing the point of my email - my point was that one of the major "rendering repercussions" of using subpixel rendering (bilinear filtering coloring your opaque-transparent transitions) can be handled automatically by using pre-multiplied alpha in a way that is invisible to the user of the sprite class.

My thinking is that if you really break down the objections to sub-pixel rendering being supported in the sprite class, you will find that you can rework pyglet pieces in way that will both resolve those objections without burdening the users of the library, and will most likely result in a better engine overall (at least in the bilinear filter thing, it also prevents edge coloring for scaling and rotation artifacts as well)

[Ben Sizer]

On Oct 5, 1:01 pm, Tristam MacDonald <swiftco...@gmail.com> wrote:
>
> The easiest route would be to subclass pyglet.sprite.Sprite to add a
> z-coodinate, and override the rendering methods as necessary to set it.

Ok, I gave that a try. I can't work out how to upload things to this
Google Group so the 35K zip file is up here instead:

http://www.twilightsembrace.com/_misc/07October09/zsprite.zip

Unzip the lot into a new directory and run depthbuffertest.py.
Hopefully the use of one sloping tile and a couple of taller tiles
will demonstrate that it's working, even when the code shuffles the
sprites and renders them in an arbitrary order.

I'm not much of an OpenGL coder so I expect there to be bugs. Also, I
am not greatly familiar with the depths of pyglet so I may have missed
a trick or two. So if one or two of you could cast your eye over it
I'd be grateful. Much of it is copy and pasted code since the existing
classes don't lend themselves terribly well to extension.

(Legalese: the included tile gfx are by Dan Cook at lostgarden.com,
and fall under the Creative Common Attributions 3.0 licence. Consider
my code to be BSD-licensed, like pyglet.)

--
Ben Sizer

[claudio canepa]

On Tue, Oct 6, 2009 at 9:33 PM, Ben Sizer <kyl...@gmail.com> wrote:

On Oct 5, 1:01 pm, Tristam MacDonald <swiftco...@gmail.com> wrote:
>
> The easiest route would be to subclass pyglet.sprite.Sprite to add a
> z-coodinate, and override the rendering methods as necessary to set it.

Ok, I gave that a try. I can't work out how to upload things to this
Google Group so the 35K zip file is up here instead:

http://www.twilightsembrace.com/_misc/07October09/zsprite.zip

Unzip the lot into a new directory and run depthbuffertest.py.
 

 

just for the record, you cant attach from the google group web page, but if you log into gmail and send a mail to pyglet...@googlegroups.com, then you can attach as usual.

--

claudio

 

[Alejandro Castellanos]

Ben, I just checked your zsprite in the example that you posted the
link to, and was came away very interested, and not to be the slow one
here, but how exactly does it work?

Is it exactly like the one sprite pyglet has with the exception that
the higher the y value of the sprite the later it gets drawn? I'm not
an Opengl wiz so I couldn't really make much out of the coding of the
sprite itself, but judging from the module calls it seems to be
somewhat similar.

On 6 oct, 17:55, claudio canepa <ccanep...@gmail.com> wrote:

[Brian Fisher]

On Mon, Oct 5, 2009 at 3:40 AM, Ben Sizer <kyl...@gmail.com> wrote:

See this picture: http://lostgarden.com/uploaded_images/CuteGodMockup-723198.jpg

Ben, I think you may not want depth buffer at all. The reason I say that, is that in the mockup you provided above, there is definitely antialiasing on all the art (both tiles and characters/items). Z-buffer doesn't work quite right with anti-aliasing (or transparency either for that matter). Only painters algorithm gets alpha blending right for ordered items.

The problem you'll run into is that if you used depth buffer, and then drew that antialiased 2d art out of order, then stuff that is in-front will incorrectly obscure the stuff behind it on the antialiased edges. The basic problem is the depth buffer is just a simple z-test that says draw or don't draw a particular pixel. But if you are drawing behind the aliased edge of something, theres no easy way to tell the video card to blend behind it - you either fully draw the pixel (covering up your lovely antialiased edge, giving both items hard edges) or skip drawing it (giving the thing you are drawing now a weird aliased edge that looks like it's floating above the item behind it). You can set the alpha level for when to write to the z-buffer to try and minimize the effect, but you can't eliminate it with z-buffer.

If you did that mockup with sprites with z-buffer with the sprites drawn out of order, you'd get edges looking wrong and popping.

My recommendation would be to figure out how to do it painters algorithm. There is really nothing in that mockup that hasn't been done many times just using painters algorithm.
 

[Ben Sizer]

On Oct 7, 4:39 am, Brian Fisher <thorbr...@gmail.com> wrote:

> On Mon, Oct 5, 2009 at 3:40 AM, Ben Sizer <kylo...@gmail.com> wrote:
>
> > See this picture:
> >http://lostgarden.com/uploaded_images/CuteGodMockup-723198.jpg
>
>
> Ben, I think you may not want depth buffer at all. The reason I say that,
> is that in the mockup you provided above, there is definitely antialiasing
> on all the art (both tiles and characters/items). Z-buffer doesn't work
> quite right with anti-aliasing (or transparency either for that matter).
> Only painters algorithm gets alpha blending right for ordered items.

Yeah, I'm aware of the alpha blending and anti-aliasing issues you can
get. But this isn't my own art-work, just an example of a potential
arrangement of tiles that doesn't easily lend itself to a 2 or 3 layer
approach. Lots of free tilesets are colour-keyed and if they are
converted to use alpha values of 1 or 0 then they should work fine.

> You can set the alpha level for when to write to the
> z-buffer to try and minimize the effect, but you can't eliminate it with
> z-buffer.

Yep. I don't know if you saw the code that I linked to in my last post
but I provided a variable alpha test value for this purpose. It's not
perfect but it does allow you to get some usable results out of
certain tilesets.

> My recommendation would be to figure out how to do it painters algorithm.
> There is really nothing in that mockup that hasn't been done many times just
> using painters algorithm.

In pure 2D that is true, but unfortunately that's not always a great
approach with 3D renderers because of all the texture swapping you can
end up having to do. Premature optimisation? Maybe. But I assume
pyglet has the group and batch classes for a good reason.

--
Ben Sizer

[Ben Sizer]

On Oct 7, 2:59 am, Alejandro Castellanos <uberbomber...@gmail.com>
wrote:

> Ben, I just checked your zsprite in the example that you posted the
> link to, and was came away very interested, and not to be the slow one
> here, but how exactly does it work?

Basically OpenGL is a 3D system. In 2D mode you normally just use 2 of
the coordinates, X and Y, to plot your graphics. But there is a 3rd
coordinate Z which is the axis going into or coming out of the screen.
All I've done is give certain sprites smaller values of Z to make them
effectively further away, and the OpenGL depth buffer does the hard
work of remembering what Z values a previous sprite used and deciding
which parts of new sprites can be drawn based on that.

I picked the values of Z based on the row the tile was in, but you'd
have to decide how to do this for your own app.

(However, see Brian Fisher's note about alpha - anything with partial
alpha values still need to be rendered back to front for correct
results. If you have a lot of blending then this system may not help
you.)

--
Ben Sizer

[Alejandro Castellanos]

Thanks for answering, Ben.

In my case, I haver retorted to try a brute force approach(sorting
each sprite on a list, and drawing them individually) and see how my
system handles it. Since I'm not big on tile based games, I won't have
to redraw each piece of the map the characters might step into, and
since I don't plan on having an insane amount of moving sprites on the
screen(9 to 10, tops), that just might work; again, if my system can
handle it(knock on wood).

Again, thanks for answering.