My iPad Air must be getting really old, only ran at 15 fps and took a couple minutes to setup all the triangles
That looks awesome!
You could cut the object count almost in half for it though, by creating one large black cube behind the colored squares instead of one square behind each.
Also, I believe the blue and green faces should be on opposing sides, same for orange-red and white-yellow.
It loads & runs slowly (~25fps) on an iPad Air 2 that I have as well. The rates noted above were with an iPhone 8.
The loading time can be significantly improved by setting up clones in parallel, however initially I coded it serially to make it easier to work out the algorithm for iterating through all the surfaces.
I used 9 smaller black squares instead of 1 large one to test the FPS. And also because the borders of each individual square will need to rotate with the square when I add the functionality & additional 3D tranformations so the cube actually works. To make it look completely right, even more black squares will be needed for the interior surfaces that can be partially seen as you’re rotating a given row/column.
Those additional surfaces and 3D tranformations will further slow the FPS so I think you’re right, the number of surfaces will need to be optimized. However, to do that I might be able to use a custom image for the right triangle. It’ll have a border only on 1 side so 4 triangles can make the square without lines across its face. Although that may be problematic for the rendering algorithm as I’m not sure if the triangles are always oriented with the same edge on the border. We’ll see.
If that doesn’t work, there’s always more efficient ways to utilize a smaller number to squares, but will add complication.
I’ll fix the colors. Thanks. Didn’t pay much attention when assigning them.
That’s true. I suppose the rotating will be animated?
About the custom image, there might be a problem if the line gets thicker/thinner depending on the set width and height.
You could make 3 different images with a black line on one of the sides each. That way you wouldn’t need to change the rendering algorithm.
Have you thought of adding perspective or are you going to keep it orthographic? It might not make too big of a difference on that scale, but could be nice for realism. Also, it might mess with the hiding of faces that are turned away from the camera.
I’m going to test something here:
It works in a web browser believe it or not but not the app
That’s really cool though. You discovered this, right?
Yes, a few days ago I realized that ThinBuffalo’s 3D rendering worked in web browsers but no the app, even though everyone has the beta version’s webplayer (pushed out December 20th)
It is definitely the beta webplayer in the app, though something in the native app code doesn’t let the project run with the new features
rip idea of functioning MC in HS
The embedded project is cool. How do you do that?
Yes, I’m planning to animate the row/column rotations. Using different images with different borders is a good idea, if necessary. Although after thinking on it some more, I believe the triangles are always oriented with the hypotenuse requiring the border.
I was planning to retain the orthographic projection. Don’t think perspective is necessary for that specific project. Although I do want to change the rotation control to a virtual trackball if possible.
<iframe width="640" height="480" src="https://c.gethopscotch.com/e/zx1c0jzs6" frameborder="0" allowfullscreen></iframe>
Well, there goes all practical uses of large-scale 3D rendering unless you are on this year’s iPad Pro
True, but projects with fewer faces to render can still be impressive & inspirational. Too many “older” Hopscotchers seem to think the language isn’t capable of sophisticated projects, but I tend to think they just lack the education, experience, and/or imagination to understand what’s possible. Let’s change that perception
Yes, I was able to use the Set Width/Height block on a project created in an older version of the app.
I mean large 1:1 creations like a Minecraft recreation, full scale iPad remake like E-Pad, or something of that matter – that’d run at 4 FPS on the newest devices thanks to the great webplayer performance.
I consider a Rubik’s cube like that still small-medium scale, turning into medium-large scale when turning gets added. @ThinBuffalo
That is why I made Minigames 2 – to greatly reduce objects and maximize efficiency of each one to 1. reduce lag and 2. make a better version of the original.
That is also why MagmaPOP (3% of people will understand what I mean)
@ThinBuffalo I’m looking a bit at the Rubiks cube project and I noticed a few things in the code.
- I’m not sure if THT fixed the null frame after ”when Pressed”, but otherwise you could double the actual framerate by considering that.
- I know you aren’t currently using it, but where it should be ”set P3🌎z” it currently is ”set P2🌍z”.
That would be rendering rate, but I don’t think it would make much difference since the highest project FPS we’ve seen for this is about 40
I appreciate the comments COAN. I’ve corrected the latter in draft versions (and I’ve also made the loading into a parallel, rather than serial, process so it goes very quickly now). And I’m planning to, at some point, change the When Pressed rule. If for no other reason, then the cube can be rendered after the surfaces are initialized rather than waiting for the press event.
But first I have many more pressing changes to make (pun intended ). Adding an additional set of transformations to calculate the local rotations prior to the global cube transformations, is easy enough mathematically. But that adds many additional complications.
Internal surfaces are required as can be seen from the image above.
The whole cube will rotate with a drag on the background, but the cube will “twist” with a drag on one of the squares. To determine which way the cube twists requires an additional calculation to correlate the angle dragged on the screen to the axes of the object’s coordinate system. And a determination of which set of faces to rotate is also needed. (The local rotation shown above was a pre-determined test rotation, just to test the 3D calculations)
Then there’s also the matter of Z order. With a “solid cube” no surfaces can cover other surfaces, other than surfaces facing away from the screen. So it’s straightforward to hide the surfaces facing away from the screen based on the face normals. However, during the twisting, the Z order of the rendering gets more complicated. Tilting the cube shown above to look at it from the bottom illustrates the issue, as the green & orange surfaces need to be above the blue & red surfaces.
The ability to directly set an object’s Z order would be really helpful here… Since we don’t have that, an algorithm based on the normal direction of rotation plane will be needed. E.g., When the cube is tilted “up”, the bottom row needs to be above the middle row, which in turn is above to top row.
Much to do…
So do you use 2 triangles every square, and two more for the border?
This rendering concept can make any shape out of triangles. Each triangle requires 2 “right triangle” objects to render the triangle at any 3D angle. So each square is actually 4 triangle objects. And the border currently is another square behind the colored square (so another 4 triangle objects), although I may change the colored square to use images that include the border (which would cut the number of objects in half). I say “may” because that’s not as straight forward as it sounds.
There’s more discussion above if you read through the previous posts.
Thought I’d follow up on the subject of using custom images that include the face border (to approximately halve the clone count)
I finally gave it a serious try, and it didn’t work out…
I used a 300 x 300 triangle image with a border along the hypotenuse (the lower-left is white so it can be colored, the upper-right is transparent)
Note all the significantly misaligned corners, like the one that’s circled. A little misalignment would be ok, but that’s so misaligned that it’s visually distracting.
The reason becomes obvious when I randomize the surface colors so you can see the individual triangle images.
Note the size difference between the indicated magenta & yellow triangles. The resultant width of the border is dependent on the image size, so the magenta triangle’s border is proportionally too wide compared to the yellow triangle and the corners are visually misaligned.
Oh well, it was worth a try…