Friebel

For projects I was working with a pretty old version of Draggable (with Throwpropsplugin), so I decided to upgrade these to the latest v3 ones from the latest Club Greensock. I found out I had to rename ThrowPropsPlugin to IntertiaPlugin and so now I use inertia: true inside a rotating draggable config. But both morphing and draggable (rotation) are somehow not working as before. What I'm experiencing now is that in whatever browser I use (Firefox / Chromium type browsers) the interaction (both mouse and touch) with the rotating draggable is not working right anymore, which was working fine in v2 with the old pluginversions; when rotating the disc it's rotating all over the place. Sometimes it suddenly reverses direction and even moves the other side in an instant. BTW I replaced the full gsap folder inside node_modules by the one from the Club Greensock zip (v3.1.1) This is how I initialize: import { gsap, CSSPlugin, Draggable, InertiaPlugin, Linear, Sine, Back, } from 'gsap/all'; gsap.registerPlugin(CSSPlugin, Draggable, InertiaPlugin, MorphSVGPlugin); gsap.defaults({ overwrite: 'auto' }); This is how I config the disc: gsap.set(this.wheel, { transformOrigin: '50% 50%' }); Draggable.create(this.wheel, { type: 'rotation', inertia: true, dragResistance: 0.005, edgeResistance: 0.01, }); So it seems like the new plugins (of coarse I also switched to gsap v3 and its new syntax, using npm and webpack btw) for some reason need a different approuch, have different value-ranges or something like that. Reading through the migration page on Greensock I don't see anything so far about this and looking at the parameters of the new plugins on the Greensock website on v3, I don't see much difference either. The methods and parameters I use still seem to be the same. Also things are wrong now with the locations of elements inside the svg. These elements are animating still, but seem to have a much smaller position-delta (scale) then before. I thought maybe this was about the transformOrigin, but it doesn't seem to be changed in v3. Weird. BTW I'm working with SVG here and all other code and the graphics (svg) are not changed. [edit] the draggable direction change (and suddenly moving in reverse direction) seems to be happening on a quart of the wheel only, the other 3 quarts seem to work as expected while dragging, but this quart moves in reverse. As if there is a problem with the angle-calculation there. I thought replacing gsap and the plugins to the new v3 would be effortless and would almost be compatible in terms of API, but I seem to be missing something here. Before spending a lot of time in creating a smaller project with this, could anybody perhaps tell me if there is something I need to know according to the migration to v3 and Draggable and why this is not working as before? Are perhaps things changed like value-ranges?

Thanks. I have and had no hard feelings and I respect your contributions on the forum. I just wanted to get it out of the way, because you were explaining some things I already know for quite some time now and wanted to spare both our times by skipping some basics. Have a nice evening!

Not sure which point you want to make here, but according to a few of your reactions in this thread I get the feeling you think I'm beginner programmer or something. Just to clear things up; I'm not at all new to pixi nor (graphics) programming. So I know some things about pixi's inner workings and webgl already and I'm following new developments closely too. If Greensock animates a filter, than the animation will not be done by the GPU but in Javascript. So to animate colors it's always faster to animate inside a shader. Not saying it's always needed to be this fast nor that Greensock should change something, just saying I in my projects would probably go for that route in a big project instead of using the plugin. But it all depends on the project and the scene. I was about to edit my last post, but saw your reaction coming, so move it here as follow up on my last post: So my suggestion would than be to have a SimplePixiPlugin per Pixi-version (if the innerworkings change per pixi version). By chosing SimplePixiPlugin4 we address pixi 4, by chosing SimplePixiPlugin5 we address pixi 5. If it only does the properties as described in the code above, it doesn't need to have pointers to either a filter or a Graphics object. That's only needed if we animate colors. In my experience of the projects I did with pixi I never needed to animate colors. So my guess would be most people could use a SimplePixiPlugin addressing a pixi version directly for most if not all projects. Only if we would need to animate with a colors that, lets's say, AdvancedPixiPlugin4 or AdvancedPixiPlugin5 should maybe (I'm not sure if it's really needed, as the target object probably has a lot of handy references already) need pointers to pixi objects. Just a suggestion. Nothing more, nothing less.

Thanks for your reaction and solid point @GreenSock Jack. I never used tweening on PIXI.ColorMatrixFilter and PIXI.Graphics through the PixiPlugin. All projects I do are happy with all properties I described above and animate with the now stripped down 'SimplePixiPlugin' is fine for me. If I would animate anything color-related I would probably directly use a custom shader for best performance to run it directly on the GPU. And for most pixi projects I don't use the pixiplugin as a lot of times it's more code to have the plugin than to write position and scaling a little different to make it work in one tween in the timelines. Just to be clear: I love greensock and there is nothing wrong with the pixiplugin or whatever. It's fine. I just liked it better to strip down the plugin to the core of what I needed into a custom plugin and make it work directly with Pixi 5 which I use in all projects now anyway, instead of handing the plugin a fake object just to let it know I use it with Pixi 5.

How will this be when different modules use the same plugin(s)? So for example module A uses the PixiPlugin and calls gsap.registerPlugin('pixiPlugin') and module B (that doesn't know of the existence of module A) also uses the PixiPlugin and therefor calls gsap.registerPlugin('pixiPlugin') too. Can we call registerPlugin() more than once to register the same plugin?

Yes, here it is; I decided to stripdown the Greensock PixiPlugin to position, scale, skew, pivot, anchor, tilePosition and tileScale, converted to ES6 as far as possible and I removed the pixi version check, so it works directly with Pixi5 (the thing I needed). It uses pixi 5's 'angle' instead of 'rotation' to skip the degrees to radians conversion. I also skipped some other things I don't use on this project, like the color tweens (which looks nice, but I never used it with pixi so that is some redundant code for my projects I'd rather not include in production builds if I was working on the file anyway) and removed the degrees to radians conversion for skew, because I already have a degr2rad() function in my project to use if needed, so now I always pass the original values directly to pixi without conversion. So basically it's the PixiPlugin light, but now without PIXI versionchecks and build directly for Pixi 5. I like it that way, because I rather have a plugin per pixi version instead of one plugin addressing them all with sniffing. Because I only use one pixi version per project. /* eslint-disable no-restricted-syntax */ /* eslint-disable guard-for-in */ /* eslint-disable no-underscore-dangle */ import { _gsScope } from 'gsap/TweenLite'; const SimplePixi5Plugin = _gsScope._gsDefine.plugin({ propName: 'pixi', priority: 0, API: 2, global: true, version: '1.0.1', init: function init(target, values, tween, index) { let p; let axis; const xyContexts = [ 'position', 'scale', 'skew', 'pivot', 'anchor', 'tilePosition', 'tileScale', ]; const contexts = { x: 'position', y: 'position', tileX: 'tilePosition', tileY: 'tilePosition', }; for (let i = 0; i < xyContexts.length; i++) { p = xyContexts[i]; contexts[`${p}X`] = p; contexts[`${p}Y`] = p; } let context; let value; for (p in values) { context = contexts[p]; value = values[p]; if (typeof value === 'function') { value = value(index || 0, target); } if (context) { axis = (p.charAt(p.length - 1).toLowerCase().indexOf('x') !== -1) ? 'x' : 'y'; this._addTween(target[context], axis, target[context][axis], value, p); } else if (p === 'scale' || p === 'anchor' || p === 'pivot' || p === 'tileScale') { this._addTween(target[p], 'x', target[p].x, value, `${p}X`); this._addTween(target[p], 'y', target[p].y, value, `${p}Y`); } else if (p === 'angle') { this._addTween(target, p, target.angle, value, p); } this._overwriteProps.push(p); } return true; }, }); export { SimplePixi5Plugin, SimplePixi5Plugin as default }; So in short my suggestion would be: Create a PixiPlugin per pixi-version if the pixi innerworkings change. In my opinion that's easier to use and doesn't need extra code to sniff the pixi version. It also doesn't need the PIXI-object or some workaround just to register the pixi version we already know. The PIXI object isn't always available when using bundlers like Webpack and why do extra work inside the plugin to detect the pixi version if we already know which PIXI version we are using, so we could pick the right pixiPlugin (4 or 5) directly. The propertyname at use in tweens could still be 'pixi' for both PixiPlugin4 as well as PixiPlugin5 and so on, only the innerworkings could be different (like using 'angle' instead of 'rotation' for Pixi v5).

Nice. Would be great if that supports real es6 imports and es6 internal code and we don't need the 'const required = []' constructions anymore. Looking forward to it!

BTW I'm doing some tests and with Webpack it doesn't matter at all if we import from 'pixi.js' or from 'pixi.js/lib/pixi.es'. The output has the exact same size. Also it looks like when importing from either of those everything is included in the package. ALso the modules that has not been imported, like the particles module, which should definitely shouldn't be in there as I don't import it. So I'm going to convert the imports to the namespaces @pixi ones to see if that helps in leaving out the unwanted parts. As pixi is always pretty big (twice as big as Easel-projects, still with v5, eventhough it's 100kB smaller than v4 for most projects I use pixi for). My goal is to have the smallest output size possible. I once recreated this project from an EaselJs project, and it's literally twice as big build with Pixi v5 (with dropped canvas-support) as with EaslJs (with no webGl support). So although I understand the underlying webGL code is a lot, it should be possible to have a much smaller output than this. BTW, I just read the github PR about pixi's skew according to changing it to degrees. And indeed they decided to leave it with radians. Which is a fine decision to me. Makes calculations as fast as possible at least. And it's easy to create a degr2rad function anyway, or just use a calculator. Anway, this is not really about greensock anymore, although pixijs is much fun an very interesting . Keep up the great work. I'm trying out the modular versions later to see if that makes the output smaller (which I really hope).

Thanks a lot for your help @OSUBlake. As I wrote above I started creating my own gsap-pixi plugin. That one is finished now and and everything is working fine now! The project is now completely converted from pixi 4 to pixi 5. As extra bonus with this I skipped the color functions I don't use and directly use the angle in degrees without the radians to degrees conversion for rotations. Also no checking for pixi version, as I know I'm using version 5. And so don't need to create a dummy PIXI object. So now that I finished that one and everything is done I might as well keep that one (BTW: the skew in pixijs is still in radians. For some reason they didn't added an extra function to that to enter values in degrees) Also nice to know now how to write gsap plugins. Although the existing gsap plugins are great and never really missed something. Thanks again! In case I need to use the full plugin with color methods and everything for another project I'm probably going to use your method.

Yes. It works both with the single '@pixi/sprite'-like npm packages as modules as well as loading from 'pixi.js' (installing the pixi.js module).

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!

Thanks for this extra info and the effort you put into searching for this!

I appreciate your help @OSUblake. But I have to respectfully dissagree on this point. I don't want to import everything. And I don't believe we are 'supposed to' do it like that either. I only use some parts of pixijs. Importing per module/object is the whole idea of modular imports. Even if Webpack would still treeshake when importing everything from 'pixi.js' with an asterix (I'm not sure if that's the case, but it might be as it is Webpack), it still makes code more structured, logical and clean to me if I only import what's needed in the module. I think that's a much cleaner and structured way of coding and I value being aware of what is actually in use by the module too. So I'd rather not import * from pixi just to use the pixiplugin. (BTW, We could even import from namespaced modules, like '@pixi/loaders') I understand I don't need this plugin and I'm aware it might even be overkill for just using rotation and scale in my case, but also a very helpful plugin in a lot of cases. I also understand how I can do it without it and there is a threshhold in when the plugin is getting useful; and that's with a bigger project that uses a lot of scaling and rotating. Eventhough I don't animate colors in pixi now. Seeing now the pixiplugin contains a lot of color functions inside I don't use I might decide to create a smaller plugin just for this project and directly address v5 or use onUpdate to set the scaling and rotating from a single animation-object instead. Than I could just use { scaleX, scaleY, rotation} and transform it to .scale.x, .scale.y, .angle in the onUpdate. Thanks for you help. I appreciate it!

Thanks for your quick reaction @OSUblake. Faster than light! Great that there is a way to address pixi 5. registerPIXI doesn't seem to be in the documentation of the plugin https://greensock.com/docs/Plugins/PixiPlugin . So can't really look it up, so I am looking through the plugin-code itself now, because I don't have a full PIXI object to supply. It seems like to use the plugin we need to hand the full PIXI object to it to be able to sniff it's properties/methods. I was hoping I could just add a { VERSION: 5 } object to the registerPIXI function instead, but that doesn't seem to work as it looks like the plugin also want to sniff for available functions inside the PIXI object. Using webpack and direct imports like import { Container } from 'pixi.js' I don't have this full PIXI object available. Only the features I use directly, like 'Container', 'Renderer' and stuff like that. Is there a way to use it in a modular way or do we really need to provide the full PIXI object now to use this plugin? Basically the only thing I wish to use of this plugin is scaling and rotating. (BTW @GreenSock , I might be missing something or overlook things, but it looks to me like the registerPIXI function isn't documented in the plugin docs. If so, it might help others too to add it to avoid confusion) Thanks again,

Moving a project, that is using the pixiplugin, from Pixi v4 to Pixi v5, the pixiplugin doesn't seem to work with pixi v5. It is throwing these errors: 'Cannot read property 'DisplayObject' of undefined'. Pixi v5 moved some objects around in the hierarchy, so that's probably the reason. I've been looking for a version supporting pixi v5, but this is the most recent version and on github it doesn't have newer commits either. There are quite a lot pixi animations in this project, so it would be nice to be able to keep using this plugin instead of having to skip this plugin and replace all scaling and rotations to different tweens. Anybody knows if there will be an upgrade/fix for pixi v5 for this pretty handy plugin anytime soon? I otherwise might create a plugin myself for this, but if there's already a fix in the making, or something I am missing here, that would be nice. Thanks in advance!

This is no animation. This is a still frame from a 5,5 hour long animation I am currently building with all kinds of variations of the Greensock logo. Be patient. It will probably be finished in december 2039! I'll post a follow up in this thread when it's finished. Crazy particles will be in it! For now, the best for everybody for twenty ninetween! May all your wishes come true, you all have a great timeline this year! Love & Ease!

Happy Tween Year @GreenSock Jack! [edit] And ofcoarse also the best for 2019 for every other greensocker here! Spread the tweens!

@OSUblake There happened to be an issue with the terser npm package (just for people that don't know; terser is the 'new' uglifyjs also webpack is using/will be using). That issue is fixed now and helps a lot mangling the webpack bundle. There's still a little issue in mangling some constructions, but the creator of terser now fixed the dom mangle problems and perhaps we can tackle thisone later too so mangling finally works! I would expect a lot of developers are using these functionality, but guess I was wrong. Thanks for trying to help!

Have nice days everybody. Enjoy! Tweening home for Christmas! ? (I was about to upload a nice Christmas image, but am only allowed to upload 501.76kB (huh?). So use your imagination and think of the nicest picture of somebody on the road, full of snow, with you on the steering wheel, driving home.... uh... on a Greensock tween... so let's make it green snow or something. Well, enjoy! ?‍?‍?

Totally agree. Pretty fuzzy sorry, maybe I should have said this thread can be closed. This is something I have to find out for myself now. Sorry for being so fuzzy. I'm in some nasty private situation now, so my head was a little fuzzy yesterday. I'm looking for a button to close this thread, but can't find it. Anyway, this one can be closed. I'll rename the title. Thanks again everybody here for trying to help.

Thanks @OSUblake. My questions was pretty dumb and I posted it too soon. Thanks for bringing to my attention that everything inside svg is absolute. That's something I know. My problem here is in fact that the graphical software (in this case Affinity Designer for a project I'm working on now) is not (always) using transforms to position groups, but applies all positioning to all sub-objects of a group. That makes it pretty difficult to animate in Javascript, because then we have to position all children instead of the group. So, guess I wasn't really thinking when posting this question. Maybe a solution to this 'problem' would be to output transforms on groups again. But problem is that Designer is not always that nice in it's svg output, so it wouldn't surprise me if they still output pre-calculated positions on the group-children instead of letting the children stay on their zeros and just applying transforms to the group. But I will look for that. I was also thinking about using something like 'transformOrigin' to compensate the children positions back to 0, 0 by adding a transformOrigin to the group. That might work when reading out the first child offset (= position) inside the group and use that value negatively as a transformOrigin to the group. So then I could (hopefully) apply a transform to the group like as it was originated all elements around 0,0 to set it to absolute positions. But let's start with the first method! I don't like that second option. Don't have a clue if what I'm writing makes sense to anybody reading this, if I explained myself well, but anyway... thanks again for your help @OSUblake. Sorry for the silly newby question

Hi everybody, For projects I import svg-files created with graphical software like Illustrator and now mostly Affinity Designer. I'd like to do 'absolute' positioning of objects inside svg space most of the time. Till now I put the graphical elements on their 0,0 positions inside the svg by the graphical software to be able to do absolute positioning with TweenLite.set(... {x, y}...) or use transforms to put them on desired locations. But that's not my ideal workflow, because I have to change the design which generates the svg output. I prefer to keep the design as is and position the elements after loading the svg by javascript with TweenLite to the right positions by absolute svg-locations instead, but so far I can't find a way to do this. I understand some svg elements have attributes like cx and cy to set positions absolute, but a lot if time I need to animate svg groups <g> and they don't have these kind of properties. Or paths, wich would take a lot more extra code to change the data just to move an element. So Does anybody here know if it is possible to set absolute svg positions with TweenLite/-Max? That would help me a lot!! Thanks!

Thanks @OSUblake. I switched from UglifyJs 2 to 3 and then to Terser to make it work, but I happily switch back if that will do the trick. Any idea on which version is the version I should look for? (and perhaps a webpack plugin that suits that version if you happen to know by chance?). 'Cause it seems to be a real maze when walking through uglify-things (the uglify3 source inside uglify2 repo, that kind of things) I probably don't make it to my next deadline to tryout other uglify versions, but when I find a little more time (maybe in between) I'm eager to try it out and use it for a next project. A version number would be highly appreciated. Thanks again!

Thanks @GreenSock Jack. Wow, an overwrite mode and I see now even an onOverwrite event.. never knew about these. Guess I will spend some time later to go through all options there to see if there are more ones I didn't know about. But somehow had the feeling this was already build in, because it's pretty hard to think of something that isn't there. Also nice way to kill tweens of variables going through plugins. Thanks a lot for the beautiful work with obviously a lot of passion and experience put in there!

1) I want to start a tween on an x-parameter but there is a possibility another TweenLite is still tweening the same value. Now I think pretty highligh about Greensock and it wouldn't surprise me if it's clever enough to stop the running tween when starting a new one. But I'm not sure. On the moment I'm having a killTweensOf() before starting the new one, but is that really nececary? Or does TweenLite indeed kill the running tween when starting the new one on the same value-parameter? BTW, 2) I was about to killTweensOf a value uses with the PixiPlugin (which is pretty convenient for large projects BTW!). But I'm not sure how to killTweensOf parameters when we're using plugins. I can't find it in the greensock help, but might be overlooking something there. Is this the right approach if we want to kill all tweens tweening the x-position via the PixiPlugin?: TweenLite.killTweensOf(this.bmp, { pixi: { x: true } }); Or should we leave pixi and just use the x-value instead (so Gsap 'underwater' knows somehow the x goes through the pixiPlugin)?: TweenLite.killTweensOf(this.bmp, { x: true }); Thanks in advance! And I am happy tweening all day long. This lib is just so well made, it's just so fun to use! Especially together with svg, pixi and threejs! :)