Jump to content
GreenSock

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

Extend hitTest functionality to all of GreenSock?

Recommended Posts

I've been playing around with the new hitTest functionality this morning, and I have to say it's pretty fantastic and elegant, which is ideal. I'm wondering, though, if this same functionality can be extended to TweenMax to work with any GreenSock functionality and not just draggable.

 

What I'm wanting to do is move elements around with the keyboard (or really any event) and be able to simply detect whether two or more elements are overlapping without that element having Draggable invoked on it. I've currently been writing my own collision detection engine to accomplish this, but being able to do it with a simple hitTest check would be far, far preferable, particularly as it would be elegantly integrated with GreenSock.

 

As a simple example of one thing I'm doing right now: I invoke an animation which uses 3D transforms to move an element, and when that occurs I'd like to be able to do a simple check to know if during that animation the element collides with another, and allows me to then invoke another function at that point (such as stopping the animation).

 

It would also be great if it could detect specifically which side of an element it collides with (left, top, right, bottom).

Link to comment
Share on other sites

Glad to hear you're enjoying the hitTest() stuff. As far as moving it from Draggable to TweenMax or something, we're exploring that. Actually, we're working on a utility that's aimed at solving some problems developers face that are specific to CSS transforms like being able to translate coordinates between contexts, like if an element is nested inside another element that is scaled and/or rotated which is also inside another element that has transforms applied (like a skew, scale, rotation, etc.). Maybe you need to figure out where exactly that point is in the global context, or where it is inside another nested element, etc. If you're a Flash guy, it's like the localToGlobal() and globalToLocal() stuff. 

 

So we're trying to determine how to best "package" these tools. Yes, we could continually add things to TweenMax but I worry it might get too big (API-wise or file size-wise). Maybe we'll create a new CSSTransform class that has static methods like localToGlobal(), globalToLocal(), get2DMatrix(), getBounds(), etc. and that may be the best place for the hitTest() to live rather than TweenMax. Maybe it's best to use a structure similar to jQuery in that we have a base "GS" or "g" object to which things get added dynamically at runtime, extending functionality (plugins). Like if you load CSSTransform, you could call GS.localToGlobal(...). This diverges from more structured languages like ActionScript (and we may eventually port the engine to other class-based languages that don't permit "loosie-goosie" stuff like that). Plus it can be tougher to document. 

 

We'd love to hear suggestions from anyone who wants to chime in. 

  • Like 2
Link to comment
Share on other sites

I think those are interesting ideas. As far as it not being integrated with TweenMax - and instead using one of the other approaches you mentioned - I'm not particular on that. Maybe having collision detection be another plugin might be a good solution?

Any way you choose to pursue it, I look forward to this becoming part of the library. I know it will open a great deal of potential for me as I continue to use it in my products.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×