Depth sorting - almost solved

I'm thinking that you will probably have to split objects into uniform sized pieces. This may be why isometric games use tiles that are all the same size instead of having some large and some small.

I've read this plainly stated in some documents regarding classic isometric games =(

Also, I just got the reasoning why Y-sorting could never possibly work with different heights.

Imagine an iso box stacked on top of another iso box, correctly sorted so that the one above is drawn on top of the other one.

Now imagine the box on top going down. It's not moving on Y, only on W (or Z or whatever). As soon as it goes below the other box, since Y has not changed, it will be incorrectly sorted, drawn above the box that sits on top of it.

SO you have GOT to involve height in the equation. I'm still on that. I just know now that Y-sorting only works for level objects.

Yeah without the 'Z' axis, sorting is cake. It just goes to the whole other side of the difficulty spectrum when you wanna add the 'Z'

You may have noticed, with height, I found it a lot easier to have one variable for the 'bottom' edge and another for the 'top' edge of the sprite just to make comparisions one hell of a lot easier. Plus you can use them to tell if something is standing on top of something else etc. I STILL can't however work out an equation that takes into account the actualy Y axis and the two Height variables that sorts them. That picture at the start of this thread was the only one I've thought of so far that had all three elements, if only it wasn't wrong...

Double sad, I need more brains.

i opened this bitchy ass can of worms when i started work on my own iso game. its a real freaking pain.

the only difficulty is getting sprites occupying the same space on the ground level, to sort correctly based on height. if one block exists things will go fine. if two exist, you can hack it so that any above thelower sprite go ontop, but if you add a whole bunch, it just starts getting too complex. y sorting works for objects when they dont share a space/dont cover up eachother. im probably just gonna hack it. yuck.

I guess it's okay for sorting not working when objects are overlapping in 3D space, but when they're not there is no reason it shouldn't work.

I tried using the distance to a camera at 45� (seeing as currently I'm displacing by Y = RY-W) but it didn't work. Then I realised my reference point is the farthest bottom point of every object, so that was probably a bad reference. I'll try again soon using the top of the object (I'll try both) and see what happens.

Edit: I see now my previous calculation was distance to the origin, which is totally wrong. I'll see what goes on now.

Seems that sorting by the edge of the virtual "box" closest to the viewer did the trick. Although if you go over the Y axis (in Construct located at the top of the layout) things will probably get inverted. So don't.

I present a stacked objects test case, working perfectly. The objects do clip when near the farthest edge of the object they're standing on, but it seems to be slight. Slopes clip horribly though, surely because slops are not accounted for at all in the sorting (yet). Horizontally sloped "walls" don't sort correctly either and never will, as there's no 3D info on such surfaces. Special sprites may be needed for such kind of thing.

Try this: http://octavoarte.cl/25d_concept.exe

hey that's pretty good, I gotta find out how you did those slopes too

What exactly are you doing in terms of sorting? I didn't quite understand entirely, hopefully what you did will work on my one. I'm about to try another method right now actually, just as an idea I had, probably won't work like all the other ideas lol

i knew measuring camera distance was the way to go., are you calculating the distance to a 45 degree plane from the top edge? or to a point from the top edge? it seems the plane would work just fine, seeing as a 2.5d projection has no perspective, and therefore the view "frustum" would just be a box, if you know what i mean. it might solve some problems doing things this way.

if you were doing this in iso, would you just sort from the closest corner, (bottom of top face) to the camera?

I don't think my approach can work on yours, as I'm not using the physics plugin... i could be wrong though, if you're doing collision on your own maybe it could.

Anyway, slopes are two factors (dwdx, dwdy) and you may obtain the real height at any point by measuring the distance to the hotspot and multiplying by the appropiate factor, which will give you a dw that you can add to the height.

About sorting, yes: 45� measured to the scene origin, sorting inverted (seeing as the "camera" doesn't really have a position in 3D space). I also thought bottom of top face would be the way to go but, strangely, bottom of bottom face yielded the best results O_o so I'm using that now.

As I'm not quite that good at maths, I'm not sure how to calculate the distance in the way you mentioned...

Do you think you could enlighten me a little? It should still work fine as the sorting and physics movement are completely separate really, although the angle I'd be using is 35.264

say that top is the measured top of the platform at a certain rx, ry position, where w is the distance from the base to the floor and h is the height of the 3D object.

top = w+h+((platform.rx - measure.rx)*dwdx)+((platform.ry - measure.ry)*dwdy)

hope that clears it up somewhat =)

Is that for slopes? It looks like slopes to me. Thanks a lot for the explanation though, I probably really need it. I'm sorry though, I meant could you explain the expression you used for your sorting, I tried doing it myself but I don't think i understood entirely what you were doing.

Are you comparing it to like a 'plane' where the camera is or are you comparing it to 0 on the Y axis?

When you said point of origin, what does that refer to? Sorry I'm so dense, I suck at maths lol

I would really love to know how to fix this sorting problem. thanks heaps

yeah that was for slopes.

For sorting I'm doing for each object, ordered by (object.bottom^2)+((object.3dheight+object.tallness)^2) send to back.

so far it's working nicely but you can't have flat objects that are also deep.

Thanks heaps for filling me in, however it's not working properly :S

Is it ascending or descending? Neither really work for me lol

when you say 3dheight and tallness, is the 3dheight how far it 'bottom side' is off the ground or how far the 'top side' of the object is from the ground? I'm assuming tallness means bottom edge to top edge.

I'm using nothing but cube shaped objects at the moment and it really isn't looking good lol

yeah my objects have height, width and depth

we're probably taking different approaches

Mine have height and width, just not depth..... would that really affect the sorting though?