Wingy Weebles (and he falls down, too)

Remember Weebles? Weebles wobble… but they don’t fall down!

There’s Willie Weeble - my “first edition” attempted CannonJS-physics Weeble… and EVERYTHING is broken.

  • Lines 39/40 are attempts to lower origin/pivotPoint of Willy Weeble. Weebled.
  • Lines 52-60 attempts “fell off the platform” -recovery system… weebled.
  • Lines 61-67 attempted periodic random lateral impulsing 4 units above sphere center… I think this works.

Almost nothing is cooperating… but if anyone would like to “mess with it”… it’s ok by me. I’m not sure if I have EVER tried to change the center of gravity on a sphereImpostor, or ANY impostor, for that matter. We might need to go native, or maybe go to the old rock quarry, and see if we can mine a clue.

Please feel free to run with this, anyone and everyone. Try to teach others as you play (especially teach ME) :slight_smile: Thx! (Here is an AmmoJS version with a MeshImpostor on sphere - different.)


you just dated yourself sooo hard, I love it!

This is very helpful.

1 Like

Yes :slight_smile:

I’m pretty sure I had that submarine.

1 Like

I’ve never played with physics,
I’m having fun :).

@Wingnut we have error in #8C98MU#13
Open console, Hit RUN

Is it normal that i can’t change the rotation of mesh, after physicsImpostor? Or something I missed?

1 Like

I’m glad you’re having fun, Arte, and it’s good to see you again.

Um… the errors… I don’t see at console in #13… FF esr. But sometimes, physics engines lose scope, after many PG edits. Sometimes ya gotta do a fresh save, and then do an unconditional reload (shift-control-r in firefox). The scene just goes physics-stupid, somehow.

I’m not sure that this is what is happening in YOUR case, but maybe.

Generally, you are not supposed to set .rotation(or even .position or .scaling) on a mesh that has an impostor. But if you do, line 57 sphere1.physicsImpostor.forceUpdate(); was supposed to make it all better… but that was “back in the old days”. ForceUpdate removes the old impostor and makes a fresh one (along with possibly some other actions).

Scaling a mesh… supposedly has a special updater for IT… impostor.setScalingUpdated()… which I think INCLUDES a forceUpdate() call, too.

And, after a physicsImpostor has been added to a mesh, its rotation is under Quaternion control. So, sphere1.rotationQuaternion gets added and becomes active, and so does… umm… sphere1.physicsImpostor.physicsBody.quaternion (or similarly-named property). PhysicsBody is the “rigidBody” of a physics engine, so it is called “native”. The property might not be named .quaternion. No matter what it is named, it holds the current rotation of the rigidBody… in Quaternion (4-value) form.

A Quaternion was once described to me as… 3 values to aim an arrow in a certain direction, and a 4th value to determine mesh rotation AROUND that arrow’s shaft. Quaternions are often used in applications where a phenomenon called “Gimbal Lock” is to be avoided.

“We’re flirting with gimbal lock!” - Tom Hanks - during a frantic manual-piloting of an engine burn - in movie Apollo 13. :slight_smile:

Mostly, people tend to use impostor.setAngularVelocity(vec3value)… to start a physics object rotating, and do the same with vec3zero when they want it to stop. Not so easy to set it to an exact angle. ForceUpdate might be the only way, or remove impostor, rotate object, add a new impostor. You probably tried that, eh Arte? Removing impostors is a great way to make a physics engine “go stupid in the playground”… as mentioned earlier. heh.

These days, I’m not sure what does what with which engine… I kind of got physics-lost across the years. Things changed faster than I could keep-up.


Thank you very much for your comments and suggestions.
Error: I’m using google chrome. Same error on fresh save.
I completely agree with you about “Things changed faster than I could keep-up”.

1 Like

Hi again, Arte.

I did some error “swallowing” and tested in G-Chrome.

I show… run it first time… no errors. Run it again, it starts reporting impostor = null at console… caused by line 66, and occasionally… line 62 is causing an error… again… impostor being null for some reason. (also reports same problem with setLinearVelocity and angularVelocity, too, as you mentioned)

I tried putting the whole mess in a scene.onReady waiter in line 49… not sure if that did anything.

So, I have impostor=null checks/conditionals in lines 54/56, 57/59, and 66/68. Not sure if I/we have learned anything from any of this… except maybe G-Chrome is grumpy… with seemingly ALL THREE physics engines… Cannon, Oimo, and Ammo. hmm.

If anyone learns something about this, teach, eh? And Arte… thx for report about GC… interesting and puzzling. Likely, a problem with Wingnut’s code. I’ll keep thinkin’ and light-testing. Here in Bessemer, MI, USA, we picked up 14-16 inches of new snow in the past 24 hours, and the morning snowblowing was exhausting and gruesome. So, I am in screw-off mode for a few hours… and will likely boot-up a Val Kilmer movie… probably “Top Secret”, because it’s SO ridiculous. (I LOVE ridiculous). :slight_smile: Hot Shots 1 and Part Deaux are also in the running, and all 5 “Scary Movie” movies… I’ve got them all. Of course, nearly ANYTHING with Leslie Nielson in it, works, too. I suppose he is The King of Ridiculous. :slight_smile:

Happy New Years eve, everyone. (Wingy hugs his snowblower for kicking butt again today)

1 Like

Wingnut, I’m sorry I mixed everything up :upside_down_face:

I’m trying to understand physics.
Green box you can drag (mass:0), blue box (mass:0).
Question: How to make blue box static (like wall)? Is that make sense, what I’m trying to explain?

:slight_smile: Fun! Nice work!

I see you are trying the physics-ready dragBehavior challenge. Good deal. It’s a quick way to insanity, for sure. :smiley:

Um, I lifted the drag-able gray ghost mesh higher… so I could watch what was happening when greenbox hit bluebox. It’s pivoting at the lock-joint pivots. It also flips axes fairly easily. It’s NOT very “locked”, is it?

You can activate 76-78, and disable line 79… to try a hinge joint. No real change.

I toured-around thru the Cannon constraints… nothing looks any better, except maybe the point-to-point constraint… PointToPointConstraint - cannon . But, I don’t think we have a point-to-point joint available on the Cannon Plugin… so it will be challenging to spawn one (native).

sigh. I guess we ALL get some kinking and bending in our lockJoints as we get older… but this Cannon lockJoint is downright flaccid. I suppose we COULD look-for a fixedRotation = true on greenbox.physicsImpostor or on physicsImpostor.physicsBody… but… as soon as we freeze player rotation, we lose the ROTATION dragBehavior future possibilities. Ideally, this thing should easily toggle between positional dragger and rotational dragger, eh? You bet. Drag-scaling someday, too, right? :wink:

Junk. Off-planet-made lockJoints… plastics… fiberglass… crap. Back in MY day, when someone sold you a lockJoint, by God… IT LOCKED… and didn’t blow-around when the dog farted. :slight_smile:

I’ll keep thinking… but… apparently Cannon has weak joints. The other engines are the same. Accidentally whack a joint-shape with an applyImpulse, and it might just float-off into space, gone forever (joint detached from shape).

I DO love to see you experimenting with physics drag, though. That’s cool! Expect brain tumors. :smiley:

Ya know… NASA has determined that 24 thrusters is the magic number. That’s 3 “applyImpulse thruster ports” on each corner of the box. Might you want to convert drag-events… to thruster port firings? Remove the joint, and instead… wireless connection from dragBehvior… to “thrust manager” thrusters-control system? This gets you rotation, too. (phew)

Your system would only use setLinearVelocity and setAngularVelocity, likely. But ya gotta stop things when drag-done… and if that’s a 10-tonne mass… FULL REVERSE THRUSTERS to stop the trans or rot when drag done. Got overshoot? :slight_smile: Just kidding. setLin/Ang velocity to 0,0,0… instant stop.

Uncle Arte’s Physics-Active Wireless JointLess TransRot DragBehavior Controller. Alright!

1 Like

“Top Secret”, because it’s SO ridiculous :rofl: :rofl: :rofl:

Forget about blue box.
Removed joint from player
Player.position = ghost.position
Reduced player
Made the red box smaller.
As you drag the player towards the red box, squeeze the “Weeble wobble”. In my opinion physics started to fail :face_with_raised_eyebrow:
Everything go’s crazy :woozy_face:

1 Like

Very nice… good violence. :slight_smile: Same PG, but with all restitutions (bounce) set to 0.

Let’s define some abbreviations.

  • P-mesh = physics-active mesh
  • PE - physics engine
  • PP - physics plugin
  • PI - physics impostor (a BJS object-class)
  • PB - physics body (a PE object-class)
  • LV - linear velocity (translation)
    (can be set/read directly, or set with single applyImpulse or applyForce)
  • AV - angular velocity (rotation)
    (can be set/read directly, or set with dual “twisting” applyImpulse or applyForce)

This “violence” is the same issue we’ve seen… when using keypresses to move non-jointed p-mesh. A keypress or drag-amount… is not a “request-to-move”. It is a hard-coded move… commanded by JS… not open for discussion with any PE’s. :slight_smile:

Now, I must ask… "What is the VELOCITY of a no-discussion, JS-forced “move COMMAND”? About a gazillion KPH/MPH, right? PE says “Hey, I just saw two PB’s intersect/overlap-a-bit… at a gazillion MPH. I need to react accordingly.” And it does… with a restitution bounce of nearly a gazillion MPH.

In brief, a JS-forced-move… is a hard-move… a demand. ApplyImpulse or applyForce (or setLV/setAV) is a soft-move… a request, done only if PB’s say it’s okay to do.

This is why I suggested the “only move player via setLV” in the previous email. It is a “request to move” and not a forced “step this distance right now” demand. In your most-recent PG, you replaced the joint… with this…

scene.registerBeforeRender(function () {
   player.position = ghost.position;

That looks like a rather demanding thing, there. :slight_smile: Hey green player… follow the ghost perfectly, even if the ghost walks thru a wall (in your demo, ghost has no impostor, so it CAN move-thru walls, AND be positioned “inside”-of greenPlayer). Greenplayer tries to follow, but PE says… um… unless you set my collisionMask and collisionGroups in a non-colliding way, I MUST calculate the green-player’s collide.

Perhaps, for now, ponder dragBehavior’s JS-forced move-step… and the velocity-of-impact that PE could “see” from that move (and it’s appropriate reaction). Faster draggings (bigger drag-steps), more physics violence, likely. Soft, gentle drags… maybe less reactionary activity from Mr. PE. :slight_smile:

Ok, that’s about all I got. I THINK this is what happens. Evidence says “yes”, but, I’m certainly no expert. Either way… fun experimenting, eh? Addictive as hell. :slight_smile:

Are you still working in Google Chrome? It is a shame that G-chrome is grumbling about setLV/AV and getLV/AV. (Google Chrome can’t see/find those methods on mesh.physicsImpostor, but MAYBE ONLY after scene re-run.) I hope we can get that fixed soon. It MIGHT BE… a slight “security loosening” of a Google Chrome pref/config… to allow the “alien” physics engine to stay in-scope, after a PG re-run. Maybe.

I grabbed a zip of this PG, took it home, looking for errors. None seen so far, but I can’t get “mesh fell off ground” recovery system to “trigger” yet. if (sphere1.getAbsolutePosition().y < -20) not triggering. I might need to reach into native lands… sphere1.physicsImpostor.physicsBody.position.y. I’m going to sample some native cuisine while I’m there. :slight_smile: Update: Can’t get console.log() to work at home - Chrome. hmm. odd. Wingy new to G-Chrome.

Also, it might be wise to move forward with version #6 of this playground… which fixes the scene,onDispose. (a comma/period typo on my part).

1 Like

I replaced rotation with rotationQuaternion (I’m sure you’ve tried it 100 times). Commented out forceUpdate, I’m not sure if forceUpdate does something :face_with_raised_eyebrow:
If I understood you correctly. Everything works as expected.

“Are you still working in Google Chrome?” Yes, but G-C starting to drive me crazy.

I’m fully aware of MPH/KPH or copying ghost position. This makes it easier to see what’s going on, at least for me.

I’ll try to dig deeper until “Weeble wobble” falls on my head :lying_face:

I was thinkin’ some more. (oh no). I’m thinkin’… during a translation drag (position)… um… fixedRotation is probably wise. Body - cannon (But alas, having the Weeble wobble… after a positional drag ends… would be lost - sniff. Drag-acceleration Weeble lean-back… at start of drag… would be gone, too. erf.) :slight_smile:

Likely, it would be easy to do PI.setAngularVelocity(BABYLON.Vector3.Zero())… at every drag step. But still… that is a velocity-setter and not a rotation-setter using rotQuat.Zero() or rotQuat.Identity(). The onDrag update speeds COULD… allow a little “tilt” if the dragging-user was dragging-around violently, colliding with piles of other mesh. After many drag-collisions, greenPlayer could be tilted/angled. (mosh pit?) :wink:

Even if you/we periodically add/remove…
onBeforeRenderObserver => PI.setAngularVelocity(BABYLON.Vector3.Zero())

…the user COULD “drag and bang” during the drag… enough to rotate the greenbox a little bit.

So, HOW does a person continuously set p-mesh.pi.pb.quaternion… to 0,0,0,0 DURING a position drag? Maybe setting p-mesh.rotationQuaternion to 0,0,0,0 (or maybe 0,0,0,1)… continuously, during drag… would be a rotation “fixer”, too. But we should watch-out for mesh-shape… going out-of-sync with impostor.body.quat… an out-of-body experience. :wink:

Yup. In France we used to call that “Bidibulle”.

Reminds me also a stupid web serie “Weebl and Bob” in early 2K.


I’m still scratching my head from thinking (drag P, using physics) :thinking: And here you are with “Bidibulle”, “Weebl and Bob” :rofl: :joy: :sweat_smile:

@Wingnut do we have something like OnPhysicsCollideEND?

physicsImpostor.unregisterOnPhysicsCollide not working?!
Line 176-178

Geez, I’m getting a lot of impostor = null from firefox, too, now… line 157. Always on 2nd+ running. First runs, no errors/warnings. I need to get that setInterval and onDispose thing out of there. 4 gui buttons instead… weebleSphere control buttons… left, right, forward, backward. That interval-based random thing is making the physics engines vomit. NOTHING likes setInterval… me thinks. :slight_smile:

Update: Version with setInterval on redSphere removed… works better for me.

Anyway, look at lines 170-182… to understand a bit more about registering and un-registering functions… which run when physics collide happens. Here, we first register a function named barney… in line 175. Drag greenbox against red sphere while watching console. Lots of collide indicators. After 10 seconds, I unregister barney… so no more greenbox->redsphere console-report-on-collision… after 10 seconds.

I don’t think we have OnPhysicsCollideEND or similar, at least not at plugin layer. Deep in physics engine native lands… maybe it’s available. Arte, if you are (seriously) working-on a physics-based “snap” (possibly for your cabinet-making project or similar projects), then I’ll try to research how physics engines de-overlap and clear-collisions… on impostors. Each does it somewhat differently, I suspect.

I also suspect an impostor can be colliding with multiple other impostors at the same time. There may be a collisionsManager on a physics engine world-class object. If you are going deep-diving, I’ll do my best to help… but… those physics formulas (solvers) are rather “tight’n’terse”… easily surpassing Wingnut’s math intelligence levels. At a certain point in the deep research, it is probably best to move me from a tech role… to a food’n’beer-fetching role. :slight_smile:

Extra: @Cedric taught me that “static objects” and “dynamic objects” are two different classes of physics bodies, and not just a difference of state or a difference of a property. i think this is why sphere->ground collisions are not registered as onCollides (as best I can tell). it is because ground has mass=0… making it static… I suspect. This means that setMass() is our switching method… to switch a physicsBody object from being… for example, isSleeping dynamic object, to a static, and reverse.

Here’s where the defecation hits the fan. There is a plugin-layer setMass(), AND a native-level way to set the physicsBody mass, ALSO. I believe, the plugin-level setMass()… also performs a forceUpdate (replaces the impostor with a new one)… which… will disconnect any joints that you once had attached to that shape. And naturally, there are ramifications to “going static” or “going dynamic”… especially if that impostor is currently doing joint-caused or force-caused physics movements. Also consider comparing plugin-level mass-setting methods (on the physicsImpostor)… with native-level ways (on the physicsImpostor.physicsBody). They may have differing side-effects.

Also, when calling native-level methods, you MIGHT have to use PE-types for your values. In other words, new CANNON.Vec3(x,y,z) instead of new BABYLON.Vector3(x,y,z). SOMETIMES the BJS datatypes cross-into/out-of native lands… nicely… but it is best to feed native functions… with native foods. :slight_smile: One particular point of interest… a Cannon Quaternion-type has a .toEuler(needsStuffHere)… and a Babylon Quaternion has a .toEulerAngles(nothingNeededHere). BOTH may be used fairly extensively (for console.logs)… when studying physics engines.

BUT, there is a lightly-tested theory/rumor… that mesh.rotationQuaternion is always exactly mirroring mesh.physicsImpostor.physicsBody.quaternion. In theory, they HAVE TO be mirroring, as that is the “rotational connection system” between mesh and physicsBody. Position is the other primary mesh-to-PB connection. The MOST un-tested part… is setting mesh.rotationQuaternion WHILE an impostor is already installed. Does the value get transfered all the way “down” -to PB.quaternion? Does the value get changed (casted?) from a BJS quat… into a Cannon quat… on the way? hmm.

@Arte , could you please do some Google Chrome tests on the PG version with removed setInterval/onDispose crap? Please report if you are able to call a setLinearVelocity or setAngularVelocity (and forceUpdate() and setMass(), too)… maybe after a short setTimeout delay. I think it will work without errors. I think setInterval is (was) causing our hassles… mostly because I don’t think Wingnut knows how to use it “properly”. I think the onDispose/clearInterval of fred… is somehow killing the physics engine for not-first-time-RUNs, when used in the playground. (what a mouthful of hypothesis, eh?)

Using G-C:
On #10 line 157 - impostor = null i get very unevenly.
#12 I tried everything, but i always get an error Capture
I’ll try more, when I have more time in the evening.

1 Like

Goofing around with using box1 (blue) as a below-the-floor “keel?” and I used joint1 lockJoint as a connector between red sphere1 and it. Red sphere1 is set very heavy. It is also set with high friction, but we all know that friction doesn’t have much affect on low-surface-contact spheres.

Line 133 sets sphere1 connect point at bottom of sphere1 (which has been up-scaled on Y to create the classic Weeble “egg shape”. You can drag player greenbox against the red weeble (sphere1) and it gets a little “pendulum” activity happening.

Line 36 attempt to lower the physics center-of-gravity… has been removed. The thru-floor lockjoint down to the fulcrum-weight… does that “CG” lowering, now. But, the pendulum swings SO SLOW… erf. I wonder what its problem is. May be problem with mass settings on sphere1 and box1 impostors… testing.

Hey @Arte … did you see the NEWEST post wanting physics-active dragBehavior? Drag collision effect That guy/gal REALLY needs physics “snap”, eh?

That’s… what? Three requests for physics-active drag, in the last month/2? Amazing. Your greenBox “ghost” is working sort-of ok for dragging a p-mesh (although it could use a fixedRotation on its “y” rot).

But physics drag-to-snap… that’s going to be a serious challenge, if possible at all. I suspect that it would require turning OFF all physics during the drag’n’drop (to a snapped position), and then re-activating all physics, and hopefully… all p-bodies will remain isSleeping after the re-activation. Otherwise, mesh will move/fly-away upon re-activation.

And WHAT IS a physics engine de-activate? According to my earlier theories, setMass(0) on every scene-active impostor… will make all bodies become static (frozen in place)… but we know that when ground was set mass=0 as it is now… NO collide events are reported to us (even though the floor/staticBody IS acting like a good “wall”… keeping other p-mesh from falling thru it).

SO, even if we setMass(0) on every physics-active mesh (p-mesh) except green player’s ghost, the physics engine might not help us to KNOW when a collide (against a 0-mass static) has happened. 0-mass static pb’s (such as our floor)… don’t seem to “register”/report onCollides. (Needs more testing.)

SO… we go back to standard non-physics “snap” while dragging, and that means… working exclusively with boundingBox and its extends/extendsWorld values… to accomplish the snap-positioning (and rotation-snapping, too).

Then, as soon as user is happy with dragging/snap, they lift the mouse button, and we re-activate physics on the other/all mesh… and hope that shit doesn’t go flying. :slight_smile:

I better get another cup of coffee. These thoughts are “multi-cups-of-coffee” -level… brain tumor-causing. heh. Another test PG - #16… adds line 175 to prevent violent spinning… when dragging-around green player box. Exciting stuff.

Let’s invite @lp920133349 to share our experimental physics-drag playgrounds. Physics-active dragging is certainly possible, as @Arte has proven. But… physics-active dragging WITH POSITION AND ROTATION “SNAP” - that’s brain tumor land. :slight_smile:

What might be fun… is to wire the dragBehavior… so that you can release dragged mesh… while it is moving. Essentially, this would be “throw a p-mesh”. We already have ice hockey, yes? Green box drag-player is hockey stick, red box is puck. :wink: But… “throwing” the greenBox player… by detaching it from ghost WHILE still being dragged… that’d be fun… and it would be the start of “slide-it-into-snapped-position”… somehow. Sort of like Curling Simulator 1.0 but not really. heh. Currently, greenPlayer box has no impostor, so it won’t slide anywhere, if ghost were to throw it. So, we need to throw the ghost… too.

if (dragEnd while pointer.isMoving) {


1 Like

A Weeble and a hockey puck… in the arena-o-massless statics. Drag around the green hockey stick. FUN! I was surprisd to (not-) see ghost… be able to drag greenPlayer (hockey stick) thru the arena walls. Interesting! hmm.

All in all, we needed the rink/arena… and in Tooty Frooty Wingnut colors, of course. This type of arena (rink) -building… easily allows single static boxes to be placed in the middle of the ice/surface, too. Simply ‘draw’ what you want… in lines 18-27. Here’s some badly-done goal “markers”, using a modified rink plotter.

The game of hockey would sure change and become more funny… if we put five 200 LB, 6 foot Weebles on the ice… during the entire game. Real players would be allowed to push them into other real players, and in general, they would get in the way and weeble alot… and make everyone laugh. Adult-sized bop-bags… but not so full of air. More like a boxer’s “body bag” used for their work-outs. Serious mass. If still not enough fun… put 10 of them on the rink during the game. Keep adding Bop’n’Weeble hockey “thugs” (“slugs”?) until the laughter starts. :slight_smile:

Allow 10 lucky hockey game fans-in-the-stands… to “thrust” the Weebleable “thugs” around on the ice, with remote controllers, using built-into-the-thug cold-thrust air tanks? It would allow fans to make “checks” on real players, during the game. FUN! Has a 6-foot Weeble or Bop Bag… EVER been on a hockey rink? Just maybe… the first time would be history-making? (duh?)

1 Like

You are really having fun. I really like way you set up a rink in lines 18-27.

Little by little, the game will evolves from all this :upside_down_face: “Hockey Weebles vs Ghost” :joy:

If seriously, I don’t think it’s a good idea to use physics for Drag-Drop-Snap. It would be easier to do without it. But we never know what it will bring.

The last few days have been very busy for me. I will definitely join you as I have time.

Weebles having Party!

1 Like