Algodoo

niceeee.

OMG, this is awesome! I have been trying to do exactly what you have done and you beat me to it. I am impressed beyond words.

Oh, by the way, I have been thinking about working on other motions with the cube such as changing the scale and translation, and maybe even displaying it in perspective projection. Those challenges would probably take me many weeks to learn the math, and then to design and debug the code, so would you be interested in tackling those things? You are much more gifted than I am when it comes to those sorts of things.

Thanks guys. Adding perspective wasn't too bad but figuring out the order of polygon creation was a struggle.

Wow, you never cease to amaze me, Mr Noonan!

Oh, and I'm happy that you placed comments in your code because it helps me (and others) to understand what's going on. I just began learning about affine transformations a few years ago, and now using the math in a real-world application helps me to understand most of it. Thanks again!

Yeah!! this is what i was talking about i don't know how the code works but it is awesome

s_noonan -- There's a little glitch in my code that always bothered me and I see that it transferred over to your scene. When rotating x, y, or z axes there's a little "hiccup" that occurs when the theta switches from -pi to +pi OR from +pi to -pi. I found that the transition can be made a lot smoother by adding a small +0.1 or -0.1 offset when the transition occurs. Here is the code change that seems to work well. Try it and let me know what you think about it:

keys.isDown("right") ? {
_a = _a < - math.pi + 0.1 ? math.pi : _a - 0.05
} : {};
keys.isDown("left") ? {
_a = _a > math.pi - 0.1 ? - math.pi : _a + 0.05
} : {};
keys.isDown("up") ? {
_b = _b < - math.pi + 0.1 ? math.pi : _b - 0.05
} : {};
keys.isDown("down") ? {
_b = _b > math.pi - 0.1 ? - math.pi : _b + 0.05
} : {};
keys.isDown("[1]") ? {
_c = _c < - math.pi + 0.1 ? math.pi : _c - 0.05
} : {};
keys.isDown("[0]") ? {
_c = _c > math.pi - 0.1 ? - math.pi : _c + 0.05
} : {};

Thanks. I changed the code per your recommendation and see the improvement, but now I'm wondering why the code has the +/- math.pi limitation. _a = _a - 0.05 seems to work OK. _a = _a % (2.0* math.pi) - 0.05 also seems to work OK.

Quote: "...I'm wondering why the code has the +/- math.pi limitation"

Reply: I think it's because rotations are calculated in radians, but not sure. There are 2pi radians in 360 degrees, which might explain the +/- math.pi limits.

I understand that Thyme angle functions work in radians, but I don't believe that the added (pi limiting) code does anything useful. I was hesitant to remove the code since Chesterton's fence quote states "Don't ever take a fence down until you know the reason it was put up.". Since you don't know why pi limiting is in there, then I will probably take it out. The only issue I see with removing the limitation is that if you did enough rotations, the angle could be so large that the angular resolution suffers. That won't happen with this scene. At first I thought the limitation might have something to do with gimbal lock, but I don't believe that to be the case.

Quote: "The only issue I see with removing the limitation is that if you did enough rotations, the angle could be so large that the angular resolution suffers."

Reply: I didn't think of that, but you are right.

More: I like how you changed the code to make a smooth rotation. I won't blame you at all if you decided to not add variable scale and translation because the code has gotten rather complex at this point. Adding more features might muddle the design. You already have done some very impressive work in my view.

Scale and translation should not be too hard to add. I will probably add it within the next week but OK if you beat me to it. Use any of my code that you want since I copied most of yours. While you are at it you could add a texture to one face of the cube.

Okay, I'll see what I can do with it. Thanks.

I had no problem adding textures to the surfaces but I am really struggling to make those textures rotate properly with their respective polygons.

I don't know if texture matrix supports projective transformations. I know tm supports scale, offset, and rotation. I haven't seen tm do any keystoning of images.

Quote: "I haven't seen tm do any keystoning of images. "

Yup, I believe that's the problem.

If we don't use perspective projection on the cube then there should be a way to make the image fit. The information is in Transform Polygon and/or Rotate Polygon.

Quote: "If we don't use perspective projection on the cube then there should be a way to make the image fit."

I agree, but it just isn't working out for me. Your code is a lot different than mine, and because of that I'm having trouble understanding it and getting it to work. I don't have the coding knowledge and experience that you have which makes it much more difficult for me to attempt to modify it. I might be able to get something to sort of work, but it will take a lot of time, and you would probably point out how it could have been done more efficiently in terms of lines of code and execution speed. So, I'm hoping that you would still be interested in taking on the task of doing those things that we have discussed earlier. I'm always impressed by the awesome Algodoo scenes that you have posted over the years, and I learn a lot from them, as I'm sure others do too.

I will probably give it a shot. I remember struggling with Rotate Polygon. Where's Kilinich when you need him?

Quote: "Where's Kilinich when you need him?"

I don't know, but I sure hope he'll come back to Algobox and upload more of his amazing scenes!

That is amazing! well done

Thanks lololoer!

Hey, my friend..... It's been about three years since you've uploaded your last scene. Is there a chance you might decide to create and upload a few more in the near future? Your scenes are amazing too!