limited 3D transforms to textures ?

[lezebulon]

Hi
for a simple isometric game I'm drawing things like that :

(click to show/hide)

I'm just drawing a tiles with a diamong shape and then on top a vertex array of diamond "borders" in cyan.

would it be possible in SFML to instead, define all of this as a simple top-view grid with regular "rectangular" tile images, and then perform3D  transformations to obtain the picture I just posted?

Also, would it be possible to do something like that  ?

(click to show/hide)

ie I somehow define 2 textures and their orientation, and I have the ordering be correctly drawn after I do some transformation

Would it be possible in SFML or would I need to use the underlying OpenGL calls?

thanks!

[Ixrec]

It should be fairly easy to turn "flat terrain" to "isomorphic terrain" with a vertex shader, though for a transformation this simple it might be best to stick with your existing solution.

[lezebulon]

It should be fairly easy to do that with a vertex shader, though for a transformation this simple it might be best to stick with your existing solution.

for which image?

for the first one it's indeed pretty simple.
The general problem I'd like to avoid would be to manually detect which tiles are behind / in front of the character (for instance when you go behind a building), that's why I was thinking of making one vertexarray for each "face" of the building and somehow have them draw correctly according to where the blue plane is in my 2nd picture. So would it still be possible?

[Ixrec]

The general problem I'd like to avoid would be to manually detect which tiles are behind / in front of the character (for instance when you go behind a building), that's why I was thinking of making one vertexarray for each "face" of the building and somehow have them draw correctly according to where the blue plane is in my 2nd picture. So would it still be possible?

I'm not sure I understand why this is a problem.  If you simply draw the tiles (and what's in them) from top to bottom, then buildings on lower tiles will naturally get drawn over some of the objects standing on higher tiles.  There's no need to explicitly/manually check for overlaps, at least not for rendering purposes.

The main purpose of vertex arrays is to draw a single texture (or several subsections of a single texture) in several different places at once, since graphics cards are optimized for that.  For different sides of a building, which I assume would look different, you should just use different sprites, or better yet keep it simple and use a single sprite for the whole building (since this is isometric and all).  You'd only turn that building into a vertex array when you want to draw it in several places.

This is part of the reason I said it might be best to stick with your existing solution rather than try to transform a flat map to an isometric one: it's easy to do that transformation, but the added complexity makes it harder or at least more awkward to place things on top of the map.

[lezebulon]

If you simply draw the tiles (and what's in them) from top to bottom, then buildings on lower tiles will naturally get drawn over some of the objects standing on higher tiles.

yes, that's what I'm doing and it's working great (for instance in the pic you see the grass overlapping the sand tiles a bit)
the issue would be when a character is partially behind elements that are drawn in the vertex array. Since the vertex array is drawn in a single draw call, there's no way I can interleave a drawing of the character

[Ixrec]

Ah, that's true.  I thought you were just asking about what's possible or necessary, but now this is more of a best practices or design question.

The general rule of thumb here is to avoid premature optimization.  Until you run into a performance problem (so far you haven't said there was one), drawing the buildings and characters one at a time is probably the better way to go.

Does the ground need to overlap the character?  If so that might be worth some effort to optimize right away, but be sure to do some speed tests with the naive sprite implementation to make sure it's a real problem.

[lezebulon]

yeah you're right for the buildings, I should probably use a sf::sprite for now and handle manually the ordering, there probably wouldn't be tons of building sprites at once on the screen, and anyway I can't do this with the same vertex array.

about the ground tile potentially overllaping the characters, would you have any idea how to achieve this ?The only solution I see would be to have each new horizontal line of tile in its own vertex array, and then draw them according their depth.

[Ixrec]

The first thing that comes to mind is you probably have very few characters compared to ground tiles, so perhaps you could check which tiles each character is on/near and pull those out of the vertex array, so you draw almost all the tiles in one go and then the last handful one at a time.

But again, make sure you do some actual speed tests before trying to implement tricks like that.  The last thing we want is to waste time optimizing something that wasn't slow to begin with.