2.5D graphics on rotating boxes

Hello,
Im just trying to make few 2D boxes look more like 3D object.
I use physics engine to move these around and interact with each other…

Box looks like this:
box_big

There is “face” of the box and two parts of picture that makes it look more 3D (top and right side).

It looks fine but when this box starts to rotate and f.e. finishes upside down, you shold be able to see different parts of box (bottom and left part instead of top and right part).

I dont know if it is what I ment so I made a simple example:
boxes_example.rar (83.1 KB)

Could someone please advice me or give me some tips on how to manage this boxes look?

I thought about Runtime ( “enterFrame” ) listener to check rotation of the box and show/hide right parts of box but there might be some better way.

My other thought was just to limit rotation of boxes so they dont go to some strange looking angles (Im not sure this is even possible with physics engine).

Im aware of this 2.5D guide.

Thank you for all advice or tips I can get on this topic.
Jiří

Hi there!

It’ll definitely take some work but here’s an idea…
If you use a “2.5D” ground then the physics body is already good, and what you need is just a purely visual modification.

Cut the front face of the box and start with that as your base. You’ll apply the physics the same as you already did in your example.
You’ll need the top and right sides as you see in the original image, but use separate rectangles for those, each side as its own rectangle.
You would need to apply this on all 4 sides.

At the start, modify the paths (x1,y1 through x4,y4) on all sides so that the left and bottom ones are a single line (not visible) on the edge of the front face.

As you rotate the box start changing the paths so that the top and right side get closer to the edge of the front face of the box while the left and bottom start to expand giving you the same visual look.

It would probably be easier to show a visual but I hope you understand what I mean. :sweat_smile:

Hey Juni. Thank you for this idea. I understand what you say. Could we take this idea further? I would probably need to keep all 5 images together somehow… I thought about putting all images in one group and try add whole group as physics body but I didnt try what this would do yet…

I did some testing, making the object and rotation was not a problem.

It got too complicated for me trying to modify the paths as it rotates. Got it to work for some but not for all.
I think doing it this way might be over complicating things… I don’t have enough experience with 2.5D, but was worth the shot. :slightly_smiling_face:

Thank you for trying!

Did you manage to move all pictures together? Do I understand that there needs to be 5 pictures for this (1+4)?

Yes, 5, since you’re not rotating on a z axis. What you’re looking at is essentially a cube that has 6 sides, but the back side is never shown so not need to do that one. :slightly_smiling_face:

You would have 2 ways to approach this:

  1. As you rotate the face you would keep all other sides relative to its position; a bit complicated on the math side, and you also would have to modify the paths for each side while doing this.

  2. A simpler approach, use a container for each of your box. Each container has all box parts aligned as usual. You would then just rotate the container itself, not the box’s front face. Doing it in this manner, you would just have to modify the paths of the sides as the container rotates to make the 3D perspective come to life.

By container you mean display group object? Or is there some other option?

While I can’t be sure about the original meaning, there’s also this:

https://docs.coronalabs.com/api/library/display/newContainer.html

It can be pretty useful, so I figured it’s worth a mention either way. :slight_smile:

Yup, what @Gil44liG said. :slightly_smiling_face:

A container is the same as a display group except you can limit it’s boundaries.

Because of issues with Physics bodies in different display groups, you can create a rectangle the size of the container (don’t put it inside the container though) and apply the Physics body to it; keep the rectangle invisible.

You can get the container to mirror the rectangle’s physics behavior by applying its x,y and rotation.

This is perfectly doable, but far from trivial.

You don’t need to bother with a container. Just create a display group and add the screen facing side to the middle of the group. Then you need to add the four remaining sides to the group. At this point, the crate should look a bit like a plus sign.

Now, the difficult part is that you need to manage which two of the four sides should be visible and update the rect paths for the two sides that are visible (not counting the screen facing side). Essentially, whenever the crate’s (group’s) rotation increases or decreases by 90 degrees, the visible sides change.

As for the rect paths, you’ll need to use trigonometry to calculate the offsets. This ought to be quite straightforward as you already know the angle based on your chosen perspective.


I haven’t tested this, but it might also be possible that you don’t need to manually toggle the visibility at all. Simply managing the rect paths might do the trick in hiding the four other sides behind the screen facing side.

Thank you all for advice.

I didnt know about containers, they look pretty usefull.

I gave it another thought and had another thought.
What if I created sprite animation containing animation of 4 sides in different agles, had it moving with center and used animation:setFrame to change frame according to rotation…

Im not sure which approach try first. Im a little woried about computing demands of doing goniometry calculations every frame in first option. What you guys think about second option?

Yes, that can also work.
The more frames you have the smoother it’ll look in the transition. :slightly_smiling_face:

Hey, I managed to create listener that deforms sides of the box so it looks 3Dish. I wasnt actually as hard as it appeared.
However I didnt realize that it is only easier part of the problem. Im currently struggling with draw order of boxes…

It is very hard for me to identify which box is to right (or above) from other box. If boxes didnt rotate, it is quite easy to do but not for rotating boxes of different sizes.

If you had some tips on draw order topic or some tips on how to approach this, please share. I can share my example project with sides redrawing implemented if someone was interested but it is not finished as boxes dont draw in correct order…

Thank you
Jiří

Glad to see you’re still at it. :slightly_smiling_face:

Not sure which solution you went with, but it would seem if you compare 2 boxes’ location then the lower y and/or the greater x should toFront().

I started with this but I found first problem here:
01 02
Green Y is smaller and red X is bigger on both pictures but there should be red box in front on first picture and green box in front on second one (as on pictures).

Also, it gets complicated on boxes of different sizes…and it gets even “funnier” when boxes start to rotate.
So I tried to define space where boxes should be with different incline of it etc. Now It got really messy (and still not working well) so Im looking for another way to do this.

I thought about using physics.rayCast () to detect boxes above or right from box. Im not sure if this call is CPU costly and if it is wise to call it every frame. I might use about 7 rays for each box (but maybe I could check only one box per frame)… What do you think?

You could use box2d in general.

Otherwise, what you would be looking for is line and dot Intersection formula. A dot for each corner of the box, and the lines of each side of the box.

Just some weeks ago I had to deal with all this in a different scenario. I found the following site very helpful to help get started on manually doing these kind of stuff. It simple to follow, just remember in Solar2D the default anchor of a rect is at its center. :slightly_smiling_face:

Edit:
A more precise solution would be rectangle with rectangle collision, but you’ll also need to throw in the rotation.

Thank you, seems like a useful site indeed. I might try some of its approaches.

Hello everyone.
If someone is interested in this topic as well, here is what I made:
https://github.com/JiriAtanasovsky/boxes-2.5D

It re-draws sides of box each frame as box rotates and it manages boxes draw order (physics.rayCast is used for this).
I tried to write plenty of notes to explain what I was doing in the code.
It has some flaws but it runs stable.

This is s first thing I have ever put to github :).

3 Likes