need OnPickOutTrigger...

[MasterK]

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

[NasimiAsl]

you need Move Trigger and some variable for manage that

[MasterK]

1 hour ago, NasimiAsl said:

you need Move Trigger and some variable for manage that

there is no MoveTrigger.

maybe use onPoinerMove will ok. but they are not the same way to deal this.

[MasterK]

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.setScale(1.1);
    }));
s.actionManager.registerAction(new BABYLON.ExecuteCodeAction(BABYLON.ActionManager.OnPickUpTrigger,
    function () {
        _this.downSprite = null;
        s.setScale(1);
    }));
scene.onPointerMove = function(evt, pickResult){
    if(_this.downSprite){
        if(!pickResult.hit || pickResult.pickedSprite !== _this.downSprite){
            _this.downSprite.setScale(1);
            _this.downSprite = null;
        }
    }
}

 

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

 

[Wingnut]

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...

http://www.babylonjs-playground.com/#G1QID

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. 

http://www.babylonjs-playground.com/#G1QID#1

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.

[GameMonetize]

This is not a bug  Moving to questions

[GameMonetize]

Is the new onPointerPick enough? https://github.com/BabylonJS/Babylon.js/pull/930

[Wingnut]

http://www.babylonjs-playground.com/#G1QID#2

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.

http://www.babylonjs-playground.com/#G1QID#3

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.

[GameMonetize]

Correct! But we could add it to sprites easily I guess.

 

Your PG seems to fix the problem though.

[Wingnut]

Well, it sort-of does.  It still waits for the pointerUp.  The alternative way: the sprite would go to normal size when the pointer leaves the sprite area (onPointerOut).  (NOT waiting for pointerUP)

[GameMonetize]

Please remind me to add pointerUp when 2.3 will be out. I do not want to mess with all my testing for now 

[Wingnut]

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.

[Temechon]

1 hour ago, Wingnut said:

I think I heard Temechon say that DOM ops were not available on Android

Only on some android wrapper - like Cocoon (Canvas+) for example. DOM is available for all devices of course

[GameMonetize]

I see no problem adding it. Just a matter of time

[GameMonetize]

Ok I added support for OnPickTrigger on sprites which is exactly what you need to replace the OnPickUpTrigger

[Wingnut]

Thanks!  Would you please make a repro in the playground. 

http://www.babylonjs-playground.com/#G1QID#4

Show me how this works, please.  (thx)

 

 

[GameMonetize]

your PG works well

[Wingnut]

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.

http://www.babylonjs-playground.com/#G1QID#3

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)

[GameMonetize]

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!

[GameMonetize]

All right gentlemen

clean your cache and check this one: http://www.babylonjs-playground.com/#G1QID#5

Nothing changed on your side  I've just added support for this specific case

 

[GameMonetize]

Actually I changed my mind

I added an OnPickOut trigger because OnPIckUp should NOT be fired if you are not on the sprite:

http://www.babylonjs-playground.com/#G1QID#6

[Wingnut]

#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.    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. 

[GameMonetize]

I also added support for OnPointerOut and OnPointerOver for sprites. SO now we should be good:)

[Wingnut]

You did?  Excellent!!  And friggin' fast, omg!

I wanna be like YOU when I grow up, DK! 

[Wingnut]

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.