OnPointerOverTrigger Trouble

[Xeonzinc]

Hi folks,

 

I've been studying and learning Babylon js for a couple of months now, great stuff so far! However I've run into an issue, which seems to be either with OnPointerOverTrigger or ExecuteCodeAction.

 

Basically I want to call a function when you either mouse over/out a mesh, however the function only receives the meshUnderPointer on the OnPointerOutTrigger, not OnPointerOverTrigger. Is this a bug or am i misunderstanding how this is meant to work? I've put an example on the playground, the console log shows no meshUnderPointer for the OnPointerOverTrigger event.

 

http://www.babylonjs.com/playground/#8ULNX#6

 

Thanks

[GameMonetize]

Bug fixed. Thank you very much for your feedback

 

I updated the playground so if you force a refresh you should see it working

[Xeonzinc]

Hey,

 

I've found another issue with this function you can see here:

 

OnPointerOutTrigger appears to fire for the wrong object when the OnPointerOverTrigger triggers over another object at the same time. You can observe if you move the mouse directly from one sphere to the other, the OnPointerOutTrigger  shows the new object, not the old one. I suspect this is going to be something do with the timings?

 

http://www.babylonjs.com/playground/#8ULNX#13

 

 

 

As a separate point, is there a good way to get an actions like these to automatically also apply to the children meshes? (so in the example ground object would also act the same as sphere 1)? 

[GameMonetize]

This is not a bug this time

 

here is how to make it work:

http://www.babylonjs.com/playground/#8ULNX#14

[Wingnut]

Xeonzinc, welcome to the forum.  This is a cool little demo.  Thanks for showing it to us.  And Deltakosh, thanks for tweaking it.

 

Xeonzinc... in the last line of your post, you asked about cascading an action onto one or all child meshes.  I don't think there is an easy .includeChildren property on ActionManagers, but it is an interesting idea.  You talked about actions, but would you want triggers to do the same?  The children of a mesh that has an ActionManager... can trigger the parent's ActionManager?  (if a flag is set to allow it)

 

I bet that would be a pain in the butt to code.    But I am certainly no expert.

 

So, that would mean... when the framework checks-for... "Is there an actionManager on this mesh?"... it could instead check-for "Is there an actionManager on this mesh or its parent?".  And if there IS one on the parent and the parent's actionManager.includeChildren = true, then allow the child to trigger the parent's actionManager as needed.  Right?  And maybe even receive the resulting actions that the parent receives!  Wow!! 

 

Ok, let's stop thinking about "non-actionManaged child... triggering parental actionManager" now (my brain hurts).  The experts might want to comment on that potential new feature.  I'm not an expert... I'm a blowhard. 

 

Let's talk about parent-to-child actions. As you likely know, our meshes don't have a .children array,  but they DO have a .getChildren() method that returns an array.  So you can loop through that array and do the action to each child.  Maybe take a look at this...

 

http://www.babylonjs.com/playground/#8ULNX#15

 

I pushed the parent into the children array along with the children, and then looped... doing the action to everything in the children array.  It seems to work... for passing-down actions (the hard way). 

 

But let's pretend that your action WAS NOT an executeCode and instead an InterpolateValue (see ActionManager docs).  Now we got trouble, right?  If the property we are poking interpolated values-into... is a .position or .rotation, no problems.  The children will automatically translate or rotate if the parent does so.

 

But what if we are changing the value of a color?  Let's say we change (via actionManager interpolator) the parent's material.diffuseColor from red to green.  We want the CHILDREN of that parent... to change from red to green, too, and without writing any executeCode function... right? 

 

Well forget it!  This is way too complicated for ALL of us, so I think we should go to the park and have a nice picnic instead, eh?  *nod*   Just kidding, of course.

 

Sigh.  ActionManager.acceptTriggersFromChildren and ActionManager.performActionsOnChildren   ... yuh yuh yuh... it could get ugly.  hehe

 

Interesting topic, though, Xeonzinc.  Way to go!    Now we all have brain tumors.

[Wingnut]

I have been doing some more thinking about this ActionManager parent-child stuff.  (oh no!)

 

What about ... hmm.  A parent-slave relationship allowed between ActionManagers. Or maybe a "patch cord" that can attach two or more ActionManagers together?

 

hmm.  In X's example (and demo), the ground would not need to be parented to the sphere.  It could have its own 'slave' ActionManager. 

 

AND the slave could be a 'master' as well, and have sphere(1) as its (counter-) slave.  Reciprocity.  Yeah, that's the word.  Half-duplex and full-duplex.  A one-way master-slave relationship, or a two-way.  (Sounds like a good way to start an endless triggering loop, eh?)

 

In effect, there could be an ActionManager patch panel... where a triggered/action on ANY ActionManager... would check if any slave ActionManagers are "patched-in", and cross-mesh propagate to all other 'listening' ActionManagers... to see if THEY have registered actions that also need triggering.

 

Ouch.  Or, I could drop the subject and we could move-on with life, safe from things that scare us. 

 

"cross-mesh propagate"...  pfft...  fancy words...  too fancy for Wingnut to be using.