Jump to content

need OnPickOutTrigger...


Recommended Posts

ActionManager._OnPickDownTrigger = 5;
ActionManager._OnPickUpTrigger = 6;

when pick down, i make the sprite scale 1.2,

when pick up, i make the sprite revert scale to 1.0

but when i pick down and move the mouse out of the sprite, it can't scale to 1.0

Link to comment
Share on other sites

s.actionManager = new BABYLON.ActionManager(scene);
var _this = this;
_this.downSprite = null;
s.actionManager.registerAction(new BABYLON.ExecuteCodeAction(BABYLON.ActionManager.OnPickDownTrigger,
    function () {
        _this.downSprite = s;
s.actionManager.registerAction(new BABYLON.ExecuteCodeAction(BABYLON.ActionManager.OnPickUpTrigger,
    function () {
        _this.downSprite = null;
scene.onPointerMove = function(evt, pickResult){
        if(!pickResult.hit || pickResult.pickedSprite !== _this.downSprite){
            _this.downSprite = null;


it's not self control... will make scene function ugly..


Link to comment
Share on other sites

Hi guys!

   Is this issue solved?  Maybe we need a playground for this.

Problem recap:  Sprite.actionManager onPickUpTrigger doesn't happen IF mouse pointer is moved OFF-OF the sprite during onPickDown?  Sprite gets stuck in BIG size.  Correct?  (thx)  Like this...


And you/we prefer NOT to use canvas.addEventListener("pointerup", onPointerUp, false); or scene.ActionManager.onPickUpTrigger (which wouldn't work anyway)... because... you/we want it all self-contained on the sprite itself.  You/We feel it would be ugly if the sprite needs help from canvas or scene... to return to normal size.

I agree.  It would be nice if the sprite onPickUpTrigger happens even if the pointer has left the sprite area.  Or, maybe it should happen WHEN the pointer leaves the sprite area.  hmm. 

I tried some experiments with adding onPointerOverTrigger and onPointerOutTrigger to the sprite's actionManager, but I couldn't get those to trigger. 


Maybe the non-pick triggers are not activated on sprites yet, or ever.  I'll keep experimenting, but I am not an expert.  Maybe others will comment and give ideas.  :)  Stay tuned.

Link to comment
Share on other sites


scene.onPointerPick doesn't work on sprites  (unless I'm missing something, which is quite possible).

Keep in mind that I haven't yet verified what the user wants, for sure.  I THINK I understand, though.


This does the job, but it needs help from scene.onPointerUp.  I think user wants the events to be sprite-only... not needing any help from scene events.

Not sure if it's possible.  The sprite's actionManager would need to listen for its own .onPointerOutTrigger and when it saw one, trigger a Sprite.actionManager.onPickUpTrigger.  (or it could re-size the sprite to normal in a Sprite.actionManager.onPointerOutTrigger handler).

Then everything is on the sprite itself... no need for help from scene.onPointerUp.  *shrug*  Mouse off-of the sprite while mouse button down, and it acts like a Sprite.actionManager.onPickUpTrigger happened.

Link to comment
Share on other sites

And only if it is wise, Deltakosh.  There could be issues that mere mortals like I (and MasterK) can't foresee or conceive.  In other words, don't do anything unwise just to make this happen.  :)  Your judgment of wisdom... comes first, in my opinion.  Please don't bloat-up the framework for something you see as a rarely-used feature.

I suspect folks are using these sprites, as touch buttons.  So... maybe full-powered actionManagers on sprites... is a good eventual goal.  Not sure.  I think I heard Temechon say that DOM ops were not available on Android... and therefore... they can't use an absolute-positioned clickable IMAGE element (with an animated gif).  That would be the DOM-based alternative to a spriteButton.  Just speculating.

Maybe each spriteManager could (optional?) use a single standard invisible mesh.  Maybe call it an actionMesh, and it is positioned and sized just like each sprite.  Then, maybe, actionManagers are not really placed on spriteManagers anymore.  They are placed on spriteManager.actionMesh.  Then maybe ALL of actionManager's triggers.... can be used with sprites.  Maybe not.   It's just another Wingnut half-baked idea.  :)

Maybe the same principle could be used on particleSystems, too.  This new ActionMesh would act as a proxy for sprite/particle actionManagers, and special code would be put on these ActionMesh.  ActionManager doesn't change, then.  ActionMesh does "middleware" work so that sprites and particles can use STANDARD actionManagers (as best they can).  *shrug*

Possibly useful for decals, too.  When a decal crosses a corner, and you turn on its bounding box, you can see that the mesh that carries the decal... CAN be rather large and much thicker than one would think.  IF a user wants to do ActionManager pointerIn/Out/Over and picking, etc... they might ONLY want picking on the sides of the box that contain the decal image.  In other words, they don't want the whole decal mesh to be pickable.  They only want the decal image pickable/pointerable.  So, a special ActionMesh middleware glue-code might be useful there, too.  Dunno.  Just yapping.  :)

We would no longer adapt the ActionManager to "special-use cases".  Instead, we adapt the picked/pointed system... so that it can use a STANDARD actionManager.  I kind of like that idea.  ActionMesh... the u-code-it interface that makes ANYTHING hookable to a BJS actionManager... even your dog.

Link to comment
Share on other sites

Nuh uh.  There's no un-pick section in my demo.  I was hoping you would code that for us, DK.  :)

Our picking was fine, no problems with that.  It is un-picking when pick held and pointer moved off-of sprite... that has trouble.


See?  OnPickDownTrigger with sprite.actionManager... working fine.  onPickUpTrigger... working fine, too... except...

1.  User clicks on sprite, and while held, moves pointer off-of sprite.  (could fire sprite.actionManager.onPickUpTrigger then - one way)

2.  User clicks on sprite, and while held, moves pointer off-of sprite and then lifts mouse button.  (could fire sprite.actionManager.onPickUpTrigger then - another way)

No scene.onPointerAnything allowed.  All must be on sprite.actionManager (if possible).

I don't see how coding .onPickTrigger... helps this.  I think we needed .onPointerOutTrigger for sprites... to make this work.  And I think THAT will ONLY work for #1.   #2 might need... hehe...  .onPickUpAfterPointerOutTrigger  (omg)  :)

Am I missing something?  (thx)

Link to comment
Share on other sites

This one works as intended for me: http://www.babylonjs-playground.com/#G1QID#4

If you click and release the mouse on sprite, your code is executed

if you click and while held, move pointer off-of sprite, then your code is not executed.


But now, after re-reading the initial ask I understand the question. I should definitely read posts completely :)


Let me get back to you folks!

Link to comment
Share on other sites

#2 - working good!  Thanks DK!  Well done.

Any chance for #1?  Am I asking for the moon and stars?  :)

Reminder:  #1 needs sprite.actionManager.onPointerOutTrigger. 
Pick normal, hold button, and sprite goes back to normal size when the pointer leaves the sprite area (no need to lift button).

#1 is MY goofy idea.  MasterK didn't ask for it, but, I still raised it as a future possibility.

We need a way to make a sprite become behaviorally-identical to a standard BJS plane... as far as the actionManager is concerned.  If that could be done, then maybe ALL actionManager triggers would be active on sprites (same as would be available with a plane).  (Invisible actionMesh overlaying sprites?)  (dream)

I just saw your recent change come in.  onPickOut.  Interesting.

You are "feeling" that once the pointer is OFF the sprite... the spriteManager.actionManager should not be involved anymore, even if the down-pick STARTED on the sprite, right?  Once the pointer is off the sprite, scene.someEvent should take-over, right?  If so, yes, I sort of felt like that, too.  Sprite.actionManager is needing to up-pick-recover from a down-pick whose pointer is no longer located ON/OVER it.  It feels wrong.

But, to give sprites maximum power to be buttons, all these things need thinkin', I suppose.  :D  I CAN see why MasterK wants all the pick/pointer behaviors to be carried on the spriteManager, though.  He wants portability of the buttons... via the spriteManager.actionManager.  hmm.  Good to see you tonight, DK, btw.  Stayin' warm and happy?  I hope so.

For anyone following along, we are assuming that each spriteMANAGER is a single animated button.  Not each sprite.  :)  That's why I ponder the invention of spriteManager.actionMesh... a single standard BJS mesh to-which the actionManager attaches, and therefore can use ALL the triggers.  It would be an all-triggers-active proxy layer.  It probably wouldn't work.  :)

Link to comment
Share on other sites

I suppose we should start thinking about particleSystem.actionManager, too, soon, huh?  ;)

Some user... writes a little customUpdate function that positions 16 stationary particles on the screen, and then wants to use them as buttons.

Hunt-down the user and beat them up?  *nod*  ;)  pickable particles would certainly have very limited applications.

And... we gotta think about picking decals... where the picks and pointers happen ONLY on the image-side of the decal's bounding box.  All other sides can be optionally set unpickable and un-pointerable.  (.pickImageFacesOnly)  :)  Trouble!  Same with pointerOver and pointerOut.  On decals, there needs to be an option for triggering ONLY on the image part of the decal (and not react to the size of the decal's bounding box, which CAN be big if a decal goes around a corner).

It's fun to discover strange places to put actionManagers.  Maybe it's my new hobby.  (Wingy checks DK for cadiac arrest)  heh.


Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...