Hey, nice fades! You’re doing pretty well.
Let’s take a look at the API for a GUI Control -class object. See all those properties? Well THOSE are the properties you get to animate… on BJS GUI Control-class objects. Certain subTypes have more properties… such as .thickness (border width). Some have colors and font settings. It takes some time/research to learn which properties are available on which type of controls… but notice one thing for sure: They are not “node” -class (mesh, camera, or light). They have no .animations property to “push” animations into.
So, let’s leave behind the keys and pushing, and dive-into where you REALLY want to be… and that’s using createAndStartAnimation, the world’s easiest animation method.
BUT… createAndStartAnimation (code-name ‘CASA’? nod)… prefers mesh, and not GUI controls. But I found a way to keep CASA happy… when animating GUI Control properties… and that’s line 2 of THIS #12 playground.
Mesh… have a getScene() function… and when I tried to use CASA on a GUI Control, it was erroring… no .getScene function. SOoo… line 2 adds a getScene() function to all GUI Control-class objects, and that makes CASA happy.
Now let’s look at lines 28-39… two functions I made… similar to other functions I have made… and they both use CASA. myspin() is animating the single float value control.rotation (neg or pos ok). Controls can ONLY rotate around z-axis… because they are flat. IF you would have put EACH text panel on a NON-full-screen GUI (instead, use the FOR-A-MESH version of GUI)… then we could have fully animated the panels… spinning them on ANY axis… because their GUI would be upon a mesh (such as a plane or box). But for FULL-SCREEN GUI, the dynamic texture is used on a screen “layer” and not upon a mesh. And thus, we can only spin them around Z-axis, as my +button is doing (to label).
Lastly, we need to call these two CASA animators… somewhere. Let’s head-down to line 229 area… your onClick event handler zone. Hey, there they are… lines 230 and 231.
Not TOO difficult, eh? Not too easy, either. Notice you have some OTHER animatable properties on GUI Control-class… like .centerX and .centerY, .top, .left, .color, .width, .height… all can be animated with CASA… if you find that somehow entertaining.
Let’s say you DID decide to make a separate createGUIForMesh for EACH text panel. THEN… you get a little more animating power… because there’s lots of fun properties on Mesh-class objects… including… physics. Panels hanging by chains)?
And, of course, mesh can be used as particle emitters, and cast shadows, and get fancy animated shader-textures such as clouds floating past or lava flow. It can get REALLY out of ‘control’… and fun.
Sometimes there’s trouble. With on-a-mesh GUI… the camera is allowed to navigate away-from the GUI, so… some kind of parent-meshpanel-to-camera might be needed. I think our GUI 3D system… is basically… every control gets a mesh of its own… so… YOU putting each panel on a plane… not so unusual at all.
I like-but-question your creation of TWO full-screen GUI layers… that you did, but I think you simply re-created the same one. Not sure what you did, there, yet… but it’s fascinating.
According to GUI docs, that cannot be done. Use the Babylon GUI - Babylon.js Documentation “Please note that only one fullscreen mode GUI is allowed per scene”. Maybe the docs are lying to us.
All in all, scroll down a bit from that above docs link… and you’ll find:
var advancedTexture2 = BABYLON.GUI.AdvancedDynamicTexture.CreateForMesh(myPlane, 1024, 1024); Ahh, createForMesh version, yum. You can create HUNDREDS of those, if you wish.
Perhaps, to stay organized… first create 3 planes… plane1, plane2, plane3. THEN…
plane1.gui = BABYLON.GUI.AdvancedDynamicTexture.CreateForMesh(plane1, 1024, 1024);
plane2.gui = BABYLON.GUI.AdvancedDynamicTexture.CreateForMesh(plane2, 1024, 1024);
plane3.gui = BABYLON.GUI.AdvancedDynamicTexture.CreateForMesh(plane3, 1024, 1024);
That way, each of your planes… sort of carries its gui WITH it… in a property-pocket called .gui Perhaps handy… IF you choose to try multiple createForMesh gui’s. Those connecting-lines… COULD be a challenge… if using multiple createForMesh gui’s. The BJS LinesMesh might work… a non-GUI lines-drawing system.
The AdvancedDynamicTexture (sometimes called ADT) IS a type of GUI Control (a container)… so IT can animate its .left, .top, .rotation, etc, etc, too. Slide an entire ADT off-screen left/right/up/down… and/or rotate it and scaleX/scaleY it, just like I did for label. Can do. FUN! Mad scientist experiments!
Ok, I hope I have been helpful. Animating GUI controls on a full-screen GUI… is a bit limited. Animating GUI controls that EACH have a standard BJS plane or box mesh… MORE powerful (cuz you’d have GUI animation AND mesh animation power).
Update: In PG #13, I tried adding a myLineSlider()… trying to slide the green line off-screen to the left… while keeping it vertical. I got dummymesh and dummycontrol… and I switch green line3 linkedMesh and connectedControl to the dummies… just after click. Then try to move them with the myLineSlider animation, but line3 linkedMesh seems to want to STAY linked to the hedragon and… well it’s just a mess… and STILL fun! Maybe we/I/you should just set line3.isVisible = false (upon click) and then go have a beer and call it a day.
A last note. Whenever you try to animate .left and .top… it might be wiser to use .leftInPixels and .topInPixels… to avoid needing to add “px” to the values…used inside the animation function. Same goes for linkOffsetXInPixels and linkOffsetYInPixels.