Jump to content

Search In
  • More options...
Find results that contain...
Find results in...


Popular Content

Showing content with the highest reputation on 09/08/2019 in all areas

  1. 3 points
    Hi @mechaniac Welcome to the forum and thanks for joining Club GreenSock. That's a limitation of SVG for now.(SVG 2 may be different) You can't rotate those child elements in 3D space, but you can rotate the entire SVG. https://codepen.io/PointC/pen/oNvEExq Hopefully that helps. Happy tweening and welcome aboard.
  2. 2 points
    It's not in the current version of the docs, and it should be probably be on the main page of the plugin page showing how to use, just like this. I wouldn't expect that many users to actually click on the registerPIXI method. import * as PIXI from "pixi.js"; import { PixiPlugin } from "gsap/PixiPlugin"; PixiPlugin.registerPIXI(PIXI); He did scaling, which the plugin currently does.
  3. 2 points
    Interesting. Is everything in the production build, or just the dev build? Like I said earlier, I haven't worked with modules (the tree shaking part) with PixiJS, so I don't know what should happen. To minimize the build, select what you want from here. It will show you what to import. Be sure to click on the "Bundler" button in the top-right. https://pixijs.io/customize/ That has nothing to do with es6. Tree shaking is an optimization done by build tools. You will now be required to register plugins. gsap.registerPlugin(SomePlugin, AnotherPlugin); That is the only way to prevent tree shaking from removing plugins that you don't call directly. That will also prevent every plugin you import from becoming a global when using modules. Currently everything you import is global.
  4. 1 point
    But how would the plugin get the appropriate stuff from PIXI then? For example, it must access PIXI.filters.ColorMatrixFilter, PIXI.Graphics, etc. Where would the pointers go?
  5. 1 point
    Yes. If a plugin is already registered, it will just ignore it.
  6. 1 point
    Yep, if you'd like early access, just shoot me a direct message or something. I think you're gonna dig what's coming next.
  7. 1 point
    I see. I absolutely would NOT use an actual grid for this sort of animation as grid elements are much harder to animate than elements positioned in other ways. There are also a lot of existing implementations of carousels that do this sort of thing for example:
  8. 1 point
    Sorry about that. I have added it and it will be included in the next version of the GSAP documentation. Would you mind sharing the code for that? Perhaps we can learn from it and upgrade our PixiPlugin (when we have time to).
  9. 1 point
    I believe this is a misinterpretation a lot of people have. With this to me they are saying that there is not 'default' export, so it's impossible to do import PIXI from 'pixi.js' , so if we'd like to import everything from pixi, we need to import * as PIXI from 'pixi.js' They are not writing or advising we should always import the whole lib. It would also not make much sense to have a default in the pixi lib, because we should be able to import everything per module too. Also take a look here: https://www.npmjs.com/package/@pixi/sprite https://www.npmjs.com/package/@pixi/display etc. import { Sprite } from '@pixi/sprite'; const sprite = new Sprite(); That's also their 'official' documentation. So they have npm packages for every single module, pixi namespaced. To even be able to only install the modules you need. Than the other modules aren't even in the node_modules folder. That was one of more goals of pixi 5: being even more modular. But it's also possible to just use 'pixi.js' and import all modules/classes you need from it: import { Container } from 'pixi.js'; Than you don't need to install all modules as seperate npm modules, but just the pixi.js lib and import from it whatever you need. BTW Greensock remains amazing. I am now creating my own plugin for just the scaling and rotating in pixi using the TEMPLATE_Plugin.js. And that file is full of very insightful help-comments. And there even seem to be a full plugin documentation available on the greensock website. Thanks @GreenSock Jack! Amazing!
  10. 1 point
  11. 1 point
    You should read "Writing Smarter Animation Code" by our very own Carl if you haven't already. It shows how to modularize your timelines for easier manipulation. There is always some penalty for abstraction (think of extra parsing/function calls, etc.). But I think it is so small that is can safely be ignored in this case. Especially in the modern day web where function calls are not very expensive (they used to be). This sort of abstraction shouldn't be noticed unless you're doing it thousands upon thousands of times in a small duration.
  12. 1 point
    Hello @vibhor4all and welcome to the GreenSock Forum! Like @mikel advised you can check DOM and window. This way you only run your animation when the HTML, SVG, Canvas, and other assets are ready and loaded to be animated. It is best to wait until the DOM is ready then check if the window is loaded. Since both DOM ready and window loaded can fire at different times based on the server wait response and client building the DOM. Also its optional to also only run on the next requestAnimationFrame() to help prevent jank when first loaded. Wait until: DOM ready: Even if the window is loaded before the DOM, the window will fire immediately. window loaded: If the DOM is ready before the window is loaded the window will just fire when it is fully loaded. OPTIONAL - Run code on next render tick. Waits until next requestAnimationFrame() which prevents running code in the middle of render tick Vanilla JS way: // wait until DOM is ready document.addEventListener("DOMContentLoaded", function(event) { // wait until window is loaded - all images, styles-sheets, fonts, links, and other media assets // you could also use addEventListener() instead window.onload = function() { // OPTIONAL - waits til next tick render to run code (prevents running in the middle of render tick) window.requestAnimationFrame(function() { // GSAP custom code goes here }); }; }); Or the jQuery way: // wait until DOM is ready $(document).ready(function(){ // wait until window is loaded - all images, styles-sheets, fonts, links, and other media assets $(window).on("load", function(){ // OPTIONAL - waits til next tick render to run code (prevents running in the middle of render tick) window.requestAnimationFrame(function() { // GSAP custom code goes here }); }); }); But a codepen will be appreciated to help you better Resources: DomContentLoaded() : https://developer.mozilla.org/en-US/docs/Web/Events/DOMContentLoaded requestAnimationFrame() : https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame window onload : https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onload Happy Tweening
  13. 1 point
    I still need to fix my first example in IE11 since it is doing some weird overlapping and stacking behavior. But I don't have time to test and debug it. Sometimes i just want to punch Microsoft, especially IE in their big fat nose.
  14. 1 point
    Very nice! One problem with the click example is that rotation gets out sync if you repeatedly click a button because you are using relative values. I don't know if there's a simple solution for that. Here's what I came up with. Store the rotation value on the element, and tween it using cycle. http://codepen.io/osublake/pen/QNpxEo?editors=0010
  15. 1 point
    Getting rid of jQuery isn't too hard. Here's a good site to help you out. http://youmightnotneedjquery.com/ And here's a fork of your pen to help you get started. Make sure you don't have CSS transitions and GSAP animating the same properties. Note that I didn't convert all your CSS transform stuff over to GSAP. Just enough to get it working. http://codepen.io/osublake/pen/QNppmB?editors=0010