cesare.polonara

Yeah sorry, not meaning a "coincidence" in that way, your explanation was pretty straight"forward" Thanks!

Hi Jack, thanks for the answer, yes I imagined the overlapping was bad, I was fooled by the fact that it worked well in forward mode, I guess that's just a coincidence due to the fact the SVG is on a vertical straight line hence the x is not animated on the last motion path hence the overlapping animation can make that bending. Yes I fixed it by changing the SVG line to make a slight bending to the left and then start the staggering animation.

Hi, I'm in this situation and I don't know how to manage the fact that MotionPath animation takes control on the translateX property when reversing the scroll ( go to the very end of the scroll animation, then reverse scrolling back, you will see the circles going to the straight right instead of doing the bending curve as they did in forward mode ). `overwrite:auto` does not seem to help, and `overwrite:true` breaks the animation. TIA.

Yeah I eventually found out that it's just the result of the mathematical composition of the functions from right to left!

Yeah I stumbled upon the Gimbal Lock issue yesterday on a Unity forum, not sure if this is the case, or it's a limitation of how the browser composes the transform functions: https://henrikingo.github.io/presentations/3D study/plaincss.html . Thanks anyway!

Hi again, I got a new problem, I realized that during CSS transform rotations, the X axis ( green one ) is relative to the element axis, meaning that if the element rotates on Y or Z axis and the element X axis changes its space orientation, then the subsequent rotation on X axis is performed on the element new X axis orientation, while that does not work for Y and Z axes. I made this visual example since I couldn't understand the behaviour during rotations and hoped a visual representation of the axes would have helped me... I looked into transform specs https://www.w3.org/TR/css-transforms-2/#funcdef-rotatez but did not see anything mentioned, what am I missing ? I feel pretty stupid right now since it looked like an easy task to perform sequential rotations, but I got stuck... Thanks. UPDATE: I realized the behaviour depends on the transform string order, meaning that the last rotate property written will make the axis relative to the element and not to the viewport, and it looks to me that GSAP places in the right order from right to left ( since transform string is composed from right to left according to specs ) rotateX, rotateY, and rotateZ. So if for example there's not a rotation on X axis then the rotation on Y axis will be relative to the element, but if there's a rotation on X that will be the only dynamic axis. This thread maybe clears it: In the first pen of the trade he places scaleZ() as first to the right, that way the Z axis is dynamic and you can display the top face directly with a rotation on the viewport X axis. In the second dice pen, if you check how it goes from number 4 to number 5, it does a sort of a hack, since at that point it's not possible to just make a 90° rotation on viewport X axis, since GSAP places it as dynamic. I think you can see it here: https://codepen.io/kais3rp/pen/GRXqdON Both X and Z axis after number 4 shows are on the same axis. I made this other codepen to try to understand how to display in specific orders the faces of a cube https://codepen.io/kais3rp/pen/JjaoywZ but it looks like some movements are just not possible without hacking the order of the transform string...

This looks amazing dude. This low level API looks pretty powerful, thanks for taking your time of showing this, the more I use GSAP the more I realize I need to learn how to use it properly... Marked as definitely solved. UPDATE: Implemented it and it's noticeably smoother than the proxy version plus now rotations are pretty precise.

Well the example I posted was just a minimum abstraction to understand how to animate scaleZ, in practice the animation is a complex scrollTrigger timeline, and on that cube there are applied a lot of different transforms, mainly translate, rotate, and scale on all the axis with different start/end times, and I'd like to keep the timeline code itself as cleanest as possible avoiding to write inline functions. About performance you are right, that probably sucks, I just wrote that yesterday to make the things work and I'm biased to write functional code, but in this case it' s definitely bad performance wise. Do you think it would perform better this way, with no loops at all inside the update function? const cube = document.querySelector('#my-cube'); const cubeProxy = { translateX: '-50%', translateY: '-50%', translateZ: '0vw', rotateX: '0deg', rotateY: '0deg', rotateZ: '0deg', rotate3d: '0,0,0,0deg', scale3d: '0,0,0', }; const updateCube = () => { const transformString = `translateX(${cubeProxy.translateX}) translateY(${cubeProxy.translateY}) translateZ(${cubeProxy.translateZ}) rotateX(${cubeProxy.rotateX}) rotateY(${cubeProxy.rotateY}) rotateZ(${cubeProxy.rotateZ}) scale3d(${cubeProxy.scale3d})`; cube.style.transform = transformString; }; Do you have any more elegant solution to granularly change in the transformString only the property that actually changes? I even tried with an actual JS Proxy and a custom setter to intercept the prop change to avoid the onUpdate function but it does not seem to work at all and that's not probably a good idea in any case... I have no way to benchmark this now. Thanks.

Good to know, I ended up following Jack's suggestion yesterday btw, so I wrote a specific util to handle the transform string update and it's behaving averagely well leaving the timeline code clean enough, it just does not like very much if you do incremental string interpolation like "+=" but I can live without that: const updateTransform = (selector, proxy) => { const el = document.querySelector(selector); const transformString = Object.entries(proxy).reduce( (acc, curr) => curr[0] === '_gsap' ? acc + '' : acc + ` ${curr[0]}(${curr[1]})`, '' ); el.style.transform = transformString; }; // Actual cube proxy props const cubeProxy = { translateX: '-50%', translateY: '-50%', translateZ: '0vw', rotateX: '0deg', rotateY: '0deg', rotateZ: '0deg', rotate3d: '0,0,0,0deg', scale3d: '0,0,0', }; // Then use it onUpdate: const updateCube = () => updateTransform('#my-cube', cubeProxy);

Great to know, thanks for your time !

Yeah I got the requirement to perform string interpolation, in fact I was doing this: gsap.fromTo(".cube", { transform: "rotateX(0deg) rotateY(0deg) scale3d(1,1,1)" },{ transform: "rotateX(120deg) rotateY(110deg) scale3d(2,2,2)", } But if I understood correctly the point is that when you animate the `transform` property of an object of type HTMLElement it's actually performing a custom parsing of the string you pass and not using string interpolation, while if you use a POJO like a proxy, it has no way to know the `transform` property is a css property so it just tries to string interpolate it, I got that about right ?

Ahah I know it's not a common use case since I'd as well usually use canvas 3D to achieve this sort of stuff, but this is a project using a sort of cube in CSS only that I use to perform weird animations, and your solution works pretty well! Could I ask why it works animating the proxy object and it doesn't when trying to animate directly the style object of the element ? I naively was thinking it would have used that complex string interpolation automatically. Thanks BTW, always a great support!

Hi guys, I' ve been trying for a few hours now to be able to scale proportionally a CSS cube to no avail . It looks like it converts the scale3d(x,y,z) directive to the 2d version, scale(x,y). I attach a codepen with the example. TIA.

Thanks Mikel, GreenSock's approach worked best for me, thanks for taking time to reply btw !

Thanks dude, this is definitely the simplest, yet most effective approach to achieve what I wanted, it works like a charm! Love gsap and the great support you get on forum, it's the first time I write cause usually I always find the right answer just by reading other posts, hope this will help someone else too !