continued_at_new_forum The Wingnut Chronicles

[Wingnut]

Ok, let's try cleaning-the-PG, again.  That worked last time... for bug-finding (thx JohnK).

https://www.babylonjs-playground.com/#1ND6TH#151

No physics, pulsars, quasars, custom plugins, or custom impostors.

Line 4:   Property .linkedMeshOffset ...added to Control class.  Vector3 dataType.
Lines 34/35:  Adds all set control.linkedMeshOffset values... to variable position ONCE.  This code is inside-of a "For Each Control, DO" loop... which is running near-constantly.
Lines 169/170  &  179/180:  Positions label1 line and target circle... -4 units below green part1 center.  Works fine.

Lines 207/208  &  217/218:  Attempt to position label2 target/line... upward THREE units above pink ghost1.  Fail.  Currently positioned ONE unit above pink ghost1 (due to position-fighting with label4)

Lines 246/255:  Set label3 target/line to aim precisely at pink ghost1 (no offsetting wanted/set).  Fail.  Currently positioned ONE unit above pink ghost1  (due to position-fighting with label2)

Lines 283/284  &  293/294:  Attempt to position label4 target/line... downward TWO units below pink ghost1.  Fail.  Currently positioned ONE unit above pink ghost1 (due to position-fighting with label2)

Goals: 
    label2 target/line should be 3 units above pink ghost1.  (teal-colored target circle)
    label3 target/line should precisely target pink ghost1.     (gold-colored target circle)
    label4 target/line should be 2 units below pink ghost1.    (teal-colored target circle)

Ok, there we go.  Issue and PG simplified.  Now, the solution will magically fall on my head, right?  heh.  It worked last time. 

I think.... SOMETHING within/used-by BJS GUI system...  is saying...

"Hey, all 6 of these controls use .linkWithMesh = 'ghost1' so, I'm going to use the same worldspace position for all 6, no matter what Wingy's line 34/35 modding wishes to do."  heh

That's what I THINK is happening.   But, I make numerous mistakes.  I was dropped on my head MANY TIMES... as a baby.  (crib-diving without a proper bungee cord). 

Assistance welcome, as always.

[Wingnut]

Hi again.  Ok, I've bailed on hope for any divine intervention (ideas for better GUI target tracking)... so... I'm back at the render loop method.

No customized AdvancedDynamicTexture._checkUpdate() in-use.  If anyone needs to know WHY the method used in my last post... failed... just holler.  In brief, even though I was adjusting position variable, the projectedPosition variable derived in the next section... was still using mesh original position, not my adjusted position.  Adjusting the projectedPosition would require too many mods for Mr. Wingnut.  SO,  here we go, back to renderLoop force-adjusting, without help from ADT._checkUpdate().

https://www.babylonjs-playground.com/#1ND6TH#159

A reasonably tight renderLoop at line 2182... keeps my 5-of-7 "floating in space" label targets... accurate, thru extreme camera tilts and mousewheels.

If you look at the target and line for label 7  (lines 2168 and 2177)... you'll see a little 2-element array.  One could call it... a custom linkedMesh "pack".  It contains a mesh and a vec3 offset value.

And, the renderLoop processesssszzzzzzzz that array, and applies [thx to control.moveToVector3()] my custom linkedMesh+offsets.

Lookin' good.  You can click pulsars, click quasars, mousewheel violently, do severe camera tilts, pan-around rebelliously... ALL 5 of my not-pointing-at-a-mesh-origin targets and lines... stay tracking perfectly. 

Good ol' moveToVector3().  (line 2186).  It's my friend. 

Phew.  Ok, I guess I can FINALLY move-along... back to chasing the unwanted bouncing/rubbery joints (joint 1a and joint 1b).

Sorry for letting the campfire burn down.  Maybe there's still enough embers to re-kindle.  :/  Maybe there was never a fire.    Certainly not much "gathering around" happening. 

(Wingy re-checks the "How To Tell Campfire Stories" manual... to see where/how he's failing.) 

I'd bring beer to the campfire, but we would all fall asleep before the end of chapter 1. 

[Wingnut]

Hi again, gang. 

As a (possibly) interesting re-kindling of "The 3-HingeJoint Human Hip Campfire Adventure", in this version #163, lines 1365-1367, I reverse the order of joint-adding. 

Things totally go to hell, and probably shouldn't.  Just possibly, we have some troubles in physics Engine/Impostor/Plugin .addJoint() funcs.   That's where I'm going investigating... in-search of the reason for rubbery joint1a and 1b (and now... also in-search-of the reason for the strange reversed-joint-adding-order issue). 

Joint-adding funcs on BJS physics Engine/Plugin/Impostor classes, are actually small and simple.  Initial look-see shows no signs of issues.  JointData and impostor sizing/centering data-dumps to console... all look good.

 Version 164 has BJS OimoPhysics plugin,  PhysicsImpostor, and PhysicsEngine... all in-playground.  (It barely saves, it's SO big.  We'll never fit a full ragdoll in a playground scene.  It's ok, we'll piece it out, while in-dev.) 

In #164, I returned to top-down joint-adding-order (now at line 1450 area).  You can experiment with terrible-working bottom-up joint-adding-order... at line 1445 area.

And don't forget our FIRST interesting indicator - line 1359 gSize variable.  The smaller the 2 ghost mesh (the smaller the gSize variable), the larger the spanned-space used by joint1a and 1b.  Not right, I don't think.  The amount of space used by j1a and j1b... should not be affected by the size of the two ghosts (in my opinion, but I could be wrong).

Yet joint1c is perfect, showing no space between it and part2.  Exactly correct.  Go fig.  It is the only joint in the scene... where the body2 shape is larger than the body1 shape.  hmm.

Wingy baffled, so far.  Nothing new.    Party on!

Another interesting thing:  Increase the diameter of part2 by increasing values in 1291 and 1292.  Run.  MORE gap!  It APPEARS that part2 got heavier (more mass)... but it didn't.  hmm.

[Wingnut]

What's that?  It's time for an interesting playground?  Ooooookay.  https://www.babylonjs-playground.com/#10IP8Y#1

What the heck is going-on, there?  Kind-of purrrrrdy.    See that '1000' in line 28 (ground subDivs)?  Increase that value... see if you can crash your browser.  FUN!

[Wingnut]

Wow, finally.

https://www.babylonjs-playground.com/#1ND6TH#166

YAY!  Phew.  No bouncing, no collision-fighting, ghost1/2 are almost atop one another, part1 and part2 are butted properly,   Damn!  Hooooooo-ray.

Solve?  Don't use Oimo joints on boxes/impostors smaller than 1x1x1.  That... was the solve. 

I'm not sure if that is normal, but that's what fixed these bouncy-joints.  (Ghost1/2 will be invisible... for the end-result.  SO, their size doesn't matter to the scene/project.)

We MIGHT come to discover that ONLY the joint's shape2/body2 must be 1x1x1 or larger.  PERHAPS... that is why joint1c was working correctly the entire time.  Part2... is joint1c's shape2/body2, and it was ALWAYS bigger than 1x1x1 units.  Also, I still have a TINY gap between part1 and part2.  So I STILL could be seeing SOME hinge stretch.  More on that below.

Another thing... it seems these .belongsTo hex values... are actually two 4-bit nibbles.  In other words, there might be only 16 collision groups. (I originally thought 256). 

Examples: 
Line 1326: part1 impostor = FE collision group
Line 1338: part2 impostor = E0 collision group
Line 1379: ghost1 impostor = D2 collision group
Line 1399: ghost2 impostor = C3 collision group

Each grouping... changes BOTH digits of the hex values (both nibbles). 

In earlier versions, I kept the 2nd digit (least significant nibble) the same for all impostors.  During the "re-overlap" aligning (tightening-up the joints until top of part2 butted against bottom of part1)... there appeared to be some "fighting".  Violent physics motions.  Not really colliding, but... impostors trying to escape being inside each other's volumes.  The unwanted motions seemed to disappear when I changed/varied all those least significant nibbles... in those .belongsTo parameters.

I will research this more... as the project advances, if it does.  Phew... it's great to see the H3J (build-it-yourself hinge3Joint from 3 stacked hingeJoints)... operating much more correctly.  Bonfire! 

No hinge angle min/max values are set/tested, yet.

I feel like I gave birth to a bulldozer.    Now, it's Miller Time.  Oh wait, it's only 7:30 AM here in Michigan's UP.  I better have some coffee royale, instead.  YAY!  (Wingy dances around but almost poops his pants, so he quits... and sits.)

Interesting note:  https://github.com/lo-th/Oimo.js/blob/gh-pages/src/shape/Box.js#L37  Notice that in Oimo... the width and height are used (along with density) in the calculation of the mass.  When I set my ghosts to gSize = .25, and if THAT was used as a "density" value by Oimo... then... hmm.  In lines 1105-1114 in my PG #166, we see our Oimo plugin talking 'density'.  hmm.  One wonders... if I had set SUPER-LOW (micro) mass values on the two ghosts, would bouncy joints be gone?  hmm.  Anyway, in Oimo, it seems that size affects mass.  But still, heavy mass should not "stretch" (elasticize) a hinge joint.

[Wingnut]

Hi again.

https://www.babylonjs-playground.com/#1ND6TH#168

Here, I went back to gSize = .25 (ghost1/2 size)... so I could get bouncy joints1a/1b issue to return.

A keen eye can catch blue ghost2... momentarily separating from the top of part2... when you fast-click the pulsars and quasars... to get part2 moving aggressively.  This indicates that joint1c is ALSO doing some stretching.  hmm.

I started thinking about "spring" (aren't we all?).    I think the spring native parameter is an array of two values... a frequency and a dampingRatio.  Not sure, though.  I need to read.

Anyway, in lines 1403/1404, I set a freq and damp value, and then I use those values in the spring native parameter... for all three hinge joints (lines 1414, 1429, and 1444).

I see no changes in hinge bounce, no matter the values. 

It is likely that "spring" is axial... matching the hinge's main/connected axes.  A hinge spring appears to NEED a limitMotor.  This makes sense.  Essentially, these are the springs on the swinging doors of old-west cowboy saloons.  Frequency is the speed of swinging, and dampingRatio is the "elasticity dissipation factor"  (what did he say?)  heh.

Although pulsars and quasars are quite good at applying hinge-testing and min/max-angle-testing forces in our recent playgrounds, motors COULD apply much more-precise and gently-metered testing forces.  If you think about it, 'spring' could be a motor-control "pattern' or 'sequence'.  It runs the motor forward, then backward, then forward, etc... just like a clock pendulum hinge.

Later, when we start "tweaking" our "range of motion" (ROM) angle limits on joint1a/1b/1c, we might want to devise a ROM (range-of-motion) motor-control sequence (specifically for our purposes).

Ease-in and ease-out speed controls seem possible, and likely handy.  The pulsars and quasars are "apply force right now... BANG" (a bit hard to control).  Conversely, ease-in/out motors... would allow for some real gentle and accurate hip testing, eh?  We could even install some fancier GUI... hingeJoints that display their current rotation in degrees or radians.  Nice.

[Wingnut]

https://www.babylonjs-playground.com/#1ND6TH#169

Check that out.  Sweet.

Small ghosts - I'm at gSize = 0.25  (line 1362)... and things are looking nice and tight. 

Near-perfect ghost1/ghost2 position overlay!  Near-perfect part1/part2 end-butting!

How?  A mass of 40 on ghost1 and ghost2 (lines 1375 and 1394).  Cooooool!   Whooooda thunkit?

Not micro-mass (as pondered 2 posts ago).  Instead, MEGA-mass!   Go fig.

Tight and firm.  I like 'em tight and firm.     Sorry for being so talkie.  I hope I'm not annoying anyone.  These adventures need to be chronicled.  Wingnut Chronicled 

[JohnK]

congratulations on your  success and perseverance.

[Wingnut]

Thanks JK, that's very kind of you to think/say.  JohnK... you certainly showed plenty of perseverance with your BJS docs re-org and fleshing.... with success, too.

I'm simply trying to keep up with you. 

Anyway, here is the first of the "motor tests".

https://www.babylonjs-playground.com/#1ND6TH#173

I locked-down ghost1/2 with 0 mass... just to keep them from spinning-around, temporarily.  (lines 1219 & 1238)

In lines 1301-1343... I have a motor-testing area.  Currently, I'm ONLY working-on joint1c motor, which is a Z-motor on a Z-joint (lines 1326-1342).  It join(t)s ghost2... with part2.

After 3-seconds, we "fire-up the motor".  Easy to see what happens.  Femur/part2 lifts to 3.11 radians upperLimit, at a motorSpeed (and direction) of .1, and a maxForce of 45. 

Then, after a few more seconds... I execute line 1340, which sets the maxForce to 0... allowing part2 to fall, due to its gravity.

FUN!!!  Try setting maxForce in line 1333... to 25, and see the motor NOT have enough power to lift part2 to upperLimit.  MORE fun!

Anyway, this PG is a reasonably fun place to start experimenting with physics motors.  We're doing it ALL with "native" methods, so far.  BUT...  we still want to learn about the spring native parameter and its frequency and dampingRatio values, if that's what they are.   Reference:  https://github.com/lo-th/Oimo.js/blob/gh-pages/src/constraint/joint/LimitMotor.js

Again, it is my theory... that spring and its frequency and dampingRatio values... is a motor controller.  Motor speeds and max forces... might be ignored... when the spring is activated.  Stay tuned... spring is coming.    Experiments and discoveries welcomed... wholeheartedly.  Motor on!

New widget thoughts:  I might need a new PhysicsTools widget.  Let's see... we have pulsars (pulsing arrows), quasars (quaternion symmetrical axial rotaters), and now we need... umm... what?  Motars?  MOTorized Axial Rotaters?  heh. 

Motars would be the first widget for joints.  Pulsars and quasars are for mesh/impostors.  Probably only 2 buttons on a MOTAR... motor forward and motor backward buttons.  But we could use some on-widget adjust-ability for upper/lower limits, and maxForce.  Three GUI drag-sliders and two GUI buttons?  Maybe.  But there is no mesh to GUI-track... only a joint.  SO... it also probably needs a label... telling WHICH JOINT any displayed motar... is bound-to. 

So, label, upperLimit slider, lowerLimit slider, maxPower slider, forward and backward motor RUN buttons.  Anyone got that built for me, yet?  huh? 

[Wingnut]

Hi kids.  Uncle Wingnut here... with another episode of "let's motorize a hip joint" 

https://www.babylonjs-playground.com/#1ND6TH#176

Motor-work happening in lines 1358 - 1373.  

In our last episode, we "lifted" (motored) the red femur around the z-axis (joint1c).

This time, I'm trying to "lift" the red femur around the X axis (joint1a) (femur moves away-from camera)... but...  I had to "unlock" ghost1 and ghost2... to make joint1a operational.  Unlock ghosts = set their mass to 40.  Lock: mass = 0.  The motor works fine (after 3 seconds) (1.5 motorSpeed is a little "hot") but... I can't seem to "lock" the Y-joint (joint1b) from spinning. 

In other words, I'm not getting a clean linear leg-lift with the motor.  It gets all weeble-wobble.    Set a .15 motorSpeed in line 1371... and you can more-easily see the unwanted spin-around after the motor starts running.

So, I went touring around in Oimo source... looking for an "enabled/disabled" on joints.  None found.  But, while I was there... I saw...

https://github.com/lo-th/Oimo.js/blob/gh-pages/src/constraint/joint/Joint.js#L192

A getPosition function on a joint!  Not working for BJSOimo, yet... but... getting the position of joints... WAS one of the BIGGEST problems... in a project to build a GUI layer... that automatically labels all the impostors and joints in ANY physics scene.  (cool project, eh?)

scene.showPhysicsInfo = true;     That would be great!

joint.getPosition() would be VERY handy in that project, should someone decide to try to code it (with an AdvancedDynamicTexture, surely).

Ok, that's it for this episode.  Trying to stop CERTAIN joints from wobbling-around... while trying to run a simple motor on a different joint...  not easy, so far (for our H3J stack of 3 hinges atop each other, each with a different axes).  Ahh... the home-built H3J... what an adventure it has been.

I think I saw a "physicsHelpers" class/thing in BJS source, the other day.  What the heck is that thing?    I think it might be a good place to put pulsars, quasars, and... motars (if they ever get invented).

Right now, I could use Babylon.PhysicsHelpers.JointBeStill(joint)    Weeble on!

[Wingnut]

Hi gang.  Continuing our physics project... I went looking-for information about HOW to "lock-up" certain joints (with or without using a limitMotor to do it).

While I was touring Oimo basic hinge joint code... I found this... https://github.com/lo-th/Oimo.js/blob/gh-pages/src/constraint/joint/HingeJoint.js#L52

Remember when we talked about "r3" earlier?  Rotational3Contraint! 

And look at line 52, there.  The parameters for creating a new Rotational3Constraint... contains THREE limitMotors!  So, let's go look at the code for an Oimo r3c... https://github.com/lo-th/Oimo.js/blob/gh-pages/src/constraint/joint/base/Rotational3Constraint.js

That is one big chunk of code, eh?  erf.

But, the important thing is... a SINGLE Oimo hinge joint... creates an r3c.  That r3c... has 3 limitMotors, each having a ton of power/knobs.  Are you thinkin' what I'm thinkin'?

Just possibly, with wise limitMotor controlling... we can eliminate 2 joints and 2 ghost mesh... and use a SINGLE Oimo hinge for our hip.

Having a single hinge joint in each joint of a ragdoll... would sure make our life much simpler.  For each of those single hinge joints... we could "program" the r3c's 3 limitMotors... to "act like a hip", or "act like a knee".  Essentially, we build a type of "r3c programming language".  More likely, it would be "advanced joint config data".  Our physics systems already use joint configData... but it is not (yet) designed to send parameters/values to an Oimo hinge's r3c object.

(Actually, our Oimo joint configData DOES install values into the joint's r3c, but ONLY into its FIRST (default) limitMotor.)

So, this is a new development and something worth thinking-about.  In the r3c source code... did you see how many properties are available?  Quite a few, but most of them are already familiar to us... from our recent motor experiments.  But, there are 3 properties there... of great interest to us:  enableMotor1, 2, and 3.  YUM!  Still, I am in question as-to... DOES a disabled axis-motor... LOCK IN PLACE?  Or does it release for completely-free pivoting?  Can it do EITHER... our choice?  YUM!

Perhaps, to "lock" an axis/motor, it needs to be enabled, and have plenty of motor speed/maxForce... but have ZERO allowance in upperLimit and lowerLimit values.  In other words, the motor is running strong and fast, with upper/lower angle limits of 0.  Is THAT how we lock an r3c axis motor?  (I'll try enableMotor2 first, of course.) 

I suppose we I will need to find-out.  I guess it starts with designing "advanced jointConfigData"... and doing even MORE hacking on this custom Oimo plugin that we have been hauling from PG version to PG version.  Yay for r3c's on Oimo hingeJoints, though, eh?  I wanted one to be on a ball-and-socket joint, but what the heck. 

this.r3 = new Rotational3Constraint( this, this.limitMotor, new LimitMotor( this.tan, true ), new LimitMotor( this.bin, true ) );

Notice that the r3c parameters... use the already-installed this.limitMotor, and then add 2-more limitMotors.  Those "2-more" are the important part.  ('bin' stands-for 'binaryAngle' as best I can tell.  Not sure.)

Just possibly, this is how the hinge joint does its stuff all the time.  These 2-more motors... are currently set "locked-up"... ie.  no pivoting allowed... around those two axes (a normal single-axis hinge).

But, by "messing-with" those 2-more motors... maybe I can make this single-axis hinge... do ANYTHING I WISH?  hmm.  This includes... having 3 active axes/motors instead of 1, and each using different lower/upper angle limits (a perfect hip joint).  Yum again!  hmm.

Did ya see the "clamp state" stuff at the bottom of the r3c source code?  See the "build jacobians" section?  This is THE meat'n'potatoes of the Oimo hingeJoint here, baby.  God-code.  Phew.  New adventures ahead.  Rotate on!

[Wingnut]

Hi gang... same subject... the hippy joint. 

https://www.babylonjs-playground.com/#1ND6TH#184

Changed to a 1-hinge system (OMG)... and... using the 3 motors (x, y, and z) contained on the hingeJoint's r3c (rotational3constraint) has been successful so far.  Even though it is a one-axis hinge joint, its 3 limit motors seem to work fine.  There's a certain way of activating them... that works best.  We'll talk about that later.  I'm still experimenting. 

Currently, lines 1239-1243 turns ON the X-axis motor, and 12 seconds later... lines 1272-1278 turns it off.

I wish our red femur would "swing freely" back and forth when the motor turns-off (and when maxMotorForce goes to zero)... but instead, it sort of "eases" back to down-position.  I'll study it more.  R3C calls such as... joint1a._physicsJoint.r3.enableMotor1 = false;  ...have not worked real well, but I am early in the tests and mistakes are likely.

And, of course, you can't miss the brand new GUI... painfully built in lines 1384-1678.  The R3C Motor Controller!  YAY!  (a 'motar'?)  (I don't really like that name... its not as cool as quasars and pulsars.) 

This new 'motar' GUI is not wired-up yet, but it's getting near. 

Likely, it needs more controls, yet.  I think I will need a motorSpeed and maxMotorForce sliders... for each axis.  SO, one more slider and one more label... per line, I guess (gettin' wide).  The current sliders will probably be motorSpeed and the slider "puck" will likely be centered.  Drag it left... motor runs one way, drag it right... the other way.  That's tomorrow's project. 

I might use 2-3 stacked sliders just like now, but instead of one for each axis... perhaps use checkBoxes to select "Which axis?"  That will save me some "real estate" space... keep the panel smaller, maybe.

Brand new stuff... with promising indicators.  I tried using the motors on all three axes of this single hinge joint, and they all worked fine... WITHOUT needing to lock any of the other axes (no spin-around problems.  Spin-around was a problem that was left behind when I returned to a single hinge joint and no ghosts). 

All good news, but keep in mind... that just because motors work on all three axes of this single hinge, it doesn't mean that it will act like a human hip when we smack our ragdoll with a beer truck.   

Motors are one thing... but forces imposed by beer truck bumpers... is a different thing.  Party on!

[Wingnut]

Hi girls. 

Another Update:  https://www.babylonjs-playground.com/#1ND6TH#185  Motor sliders operational, somewhat.  In lines 1492-1493, change Math.PI to Math.PI/2 (or some smaller values).  RUN, and use X-slider.  Notice how red mesh disappears when it hits an upper/lower angle limit?  hmm.  What the heck?  *scratch scratch* 

Also, I've been thinking about "motorImpulse" and "maxMotorImpulse"... as seen here.  We should probably be careful in our thinking, here.  Likely, "joint impulsing"... is completely different from impostor impulsing, yet both are still... MOMENTARY or INSTANT force, and then stop.  Hammer-hit.  Other interesting properties in that area... limitState, limitVelocity, and enableSpring.  hmm.

Maybe... when using impulsing... joints are allowed to swing back and forth freely (let's call it free-wheeling) after the impulse completes.  That sounds like something a spring might need, eh?

Free-wheeling is something I seek, sometimes, for after a motor is shut-off.  Continued spinning after motor disengaged, due-to momentum/mass/inertia.   I have much to learn, yet.  There is a difference between force-less motoring (dynamic braking or 'jake braking')... and motor completely-disengaged (neutral gear 'coasting'), in both real life, and maybe in Oimo, as well.  In an earlier post, I mentioned that the mesh "eases" back to downward position (after motor forces removed).  That... is a "jake-braking" indication, somewhat.

Moving on...

Slider->motorSpeed "bindings"... happen at lines 1490, 1583, and 1677 ... all slider onChange observers.  All maxMotorForce set to 25000.  FUN!!!   

There is a problem when X or Z sliders are dragged to their minimum/maximum.  Reason unknown, still.  Overall motor "power" is calculated with some kind of formula... using both motorSpeed and maxMotorForce values.  I haven't studied it well, yet.  Perhaps motorSpeeds (slider values) of > 2.0 or < 2.0... somehow crash that "overall power" calculation/formula.  Needs study.

And, I still get some "physics violence"  when multiple motors run at the same time, or run in certain sequences.  Still learning.  I dislike physics violence/spasms.  It makes my mesh... dizzy, and motion-sick. 

"I'm so dizzy, my mesh is spinnin'.  Like a whirlpool... it never ends." - Tommy Roe.

Yet another update:  https://www.babylonjs-playground.com/#1ND6TH#190  Added features to the R3C motor GUI panel.  You can now click on the red labels.  Click left side (of any red label)... you get an impulse that "works" THAT axis... with a NEGATIVE impulse (upon part2 mesh).  Click right side of a red label, you get a POSITIVE impulse.  HOW FAR left/right that you click upon any red label... determines the FORCE LEVEL of that impulse.

It is nice to see "free-wheeling" (pendulum swinging) still working, but all motors are shut-off for these click-on-label impulsings.  The impulsings are NOT currently "motor/hinge impulsings".  They are impulsings upon the part2 impostor itself.   BUT... ARE all motors shut-off when pendulum-swing free-wheeling?  Continuous logging of limitMotor angle property... during impulse pendulum-swing... shows values alternating between -1 and +1... matching the swing-rate.  Do the limitMotors (with the help of R3C) actually CAUSE/CREATE the pendulum swinging?  I'm thinkin' "YES".

Even IF the motors are being used for the impulsings, none of the motor upper/lower limits... are active/working.  (oh no!)  Wingnut mistakes likely.

For a proper hip joint... we need the impulsings to free-wheel (until muscles and tendons are added), but we still need angle limits... 6 of them, total. 

We need the femur to flop-around as it tumbles down the road after our ragdoll is hit by a beer truck.  But we need that "flop-around" to happen within the angle limits of a human hip (at least until the pelvic bones shatter - yum). 

Min/Max angles on each axis... while still maintaining free-wheeling... is the objective.  The only reason I am doing work on motors at all... is to TRY to have a system to accurately/precisely test angle-limits.  But perhaps I NEED motors to do ANY angle limits, whether for free-wheeling impulses, or for motorized hinge movements.  Currently, when a motorized hinge axis (an R3C axis)... hits an upper/lower limit... red part2 disappears.  Not sure why.  Un-wanted thing, of course. 

New Reset button currently doesn't reset motor sliders/values - only the label-click impulsings.  More experiments/learning ahead.  Party on!

[Wingnut]

*sigh*  Yet another.  https://www.babylonjs-playground.com/#1ND6TH#194

Lots of features being added to the R3C (rotational3constraint) Motor Controller.  Now, mouseover label-change on the red labels. 

Reminder: red label clicks produce applyImpulse actions on part2 femur - location sensitive - clicks on far-left side of label produces large NEGATIVE impulses, far right side clicks... large POSITIVE impulses..

Why Z impulse for X label, and X impulse for Z label?  Because...  part2 needs a Z-direction impulse... to make it rotate around X-axis of hinge. 

Same for last label.  To make Z hinge joint operate, part2 needs an X-direction impulsing. 

All 3 red labels are "variable-value dual-direction impulsers"... when clicked.  Fast-clicking allowed, too.

Also, you'll see 3 more "lines" added to the motor controller.  These are real-time readouts from the limitMotor angle values (a read-only property, as far as I know).

A renderLoop wedge powers the angle readouts... in lines 2201-2206.  s1label, s2label, and s3label onPointerDownObservables... is where the click-on-red-label impulsers are coded.

Not very exciting, huh?  But do some red-label impulsings and watch the angle readouts.  VERY unexpected behaviors from the angle readouts.  At first, it fooled me into thinking that I "bound" the wrong displays to the motor-angle values.  But nope, triple verified. 

A click on the top red label... makes the X AND Z angles swing/activate.  (limitMotor1 and limitMotor3)

A click on the bottom red label, makes the Y angle readout activate.  (limitMotor2)   Strange.

The middle red button is slightly different.  It does a dual-impulse "twist" to make part2 spin-around the Y axis.  Yet... the X-angle (limitMotor1) display... goes active.  But watch the Y and Z angle values.  They are active, too, toggling their signs, yet staying at 0.000.  Weird. 

Remember, the RESET button doesn't properly reset the scene... when sliders are used.  Re-RUN to reset... after slider-usage.

Who would EVER suspect... that there is THIS MUCH TO LEARN... about a darned Oimo hinge joint, eh?  It is like a mid-sized city!  SO MUCH to explore!    Fun!  (and scary!)

[Wingnut]

Hi gang!  Hey, I took a break from joints work... to play-with another project that I started earlier... sparkly GUI fonts.  (coooool).

Earlier, I thought I had everything I needed.  I was grabbing the context2d "canvas" (image buffer) that was used for the text.  Then I set EVERY pixel in that image... that had an .alpha >0... to a random color.

But, I could not figure out how to tell the advancedDynamicTexture (ADT)... to update to the NEW image buffer colors. Well, I figured that out.  (line 224)

https://www.babylonjs-playground.com/#11JINV#51

Other things:  I had to "hijack" two framework functions into my playground... ADT._render, and a helper object IT needed... called Measure.

She's pretty slow.  The paintIt() call in the renderLoop line 240... is a rather heavy load... considering it repaints the entire createdForMesh ADT canvas... once per frame.  (erf!)

The canvas dimensions in line 85... are quite important, speed-wise.  Feel free to adjust them, but be prepared to adjust fontSize in line 96... after adjustments to dimensions.

This same method can be used on standard dynamicTextures, too, so the entire surface of a mesh... can do these "sparkles", too.

BUT... shaders seem to animate materials better than ANYTHING my blit-animator can do.  https://www.babylonjs-playground.com/#TZSWRR#2

That's the "lava material".  If we still have a "fire material"... I think that has equally smooth animation.  That would look great... inside our fonts, eh?  Yum.

So, maybe, @NasimiAsl or some other shader Gods... will show us how to do sparklies... with a shader (for mesh materials, not GUI context2d stuff).

Ideally, though... it would be nice to have MANY quick-adjust "sparkle-styles" to "plug-into" the shader.  AND... bad news.  Since GUI fonts/controls/borders are NOT a mesh and don't use a material, we will still need a different method... to sparkle-animate GUI things.  I don't think GUI canvas-items are made-for post-processes or shaders... (yet)  (ahem).

All in all, I'm glad to see my CPU-heavy GUI font-sparkler... doing some sparkling.    Also, that "font canvas" doesn't NEED to animate, and can also be filled-with still-pic patterns (fake reflections of images inside the fonts), dynamic-genned fractal patterns, lace, fish scales, alligator-skin, bubbles, etc.  Even frames of video, I think.  Your fonts can have ANY "fill".  Your imagination is the only limit. 

Have a great weekend, everyone!  Party on!

Update:  It was like pulling teeth, but I finally got a loaded image (non-animated)... to be the fill of the fonts:

https://www.babylonjs-playground.com/#11JINV#56  Some water rings.  Exciting. 

Perhaps we can convince DeltaDawn to permanently add "fill image" to ALL of our textBlock controls, huh?     (I treat him like he's my techno-slave, don't I?  *nod*  Pathetic, I am.)

Fill images/patterns (both dynamic-generated and/or static-loaded) seem to work best... on fat/thick fonts, such as Impact font.  Notice the text1.lineSpacing = -15; in line 102?  Yep.  That is for helping me fill LOTS of screen space... with fonts/text.  Try some horizons or cityscape textures for the URL in line 216.   [pg#54 is a horizon demo]   You'll see... that it is sometimes difficult to "make out" the picture that is filling the fonts.  *shrug*  New stuff - still learning.  FUN!

[Wingnut]

Yay, sparticles (sparkly particles) are working again.  https://www.babylonjs-playground.com/#UP2O8#40

(Wingy dances around like a chicken).  There was a little bug that DeltaFlyer fixed for us.

Another, you say?  https://playground.babylonjs.com/#36UHXZ#24   (Recently updated to utilize the new non-offsetting setPivotMatrix feature.)    (might be memory-leaky or somehow CPU-heavy)

Fireworks junkies.  That's what I and all glitter-addicts... really are.  I love fireworks.

Another one?  Ok.  https://www.babylonjs-playground.com/#1NXKLI#13  6-planes with PS emitbox covering entire plane.  Strange, fun stuff.  Glitter generators... YAY!

Okay, time to get to work.  In our last episode, we put a picture inside the GUI fonts... https://www.babylonjs-playground.com/#11JINV#59

We also did some VERY FPS-SLOW color speckles inside the fonts.  https://www.babylonjs-playground.com/#11JINV#52

The real fun... is in mixing "sparticles"... with the GUI.  Here is my first attempt.  Just a plane-shaped 'emitBox" behind our message...

https://www.babylonjs-playground.com/#11JINV#60

I am still too scared to try repeatedly-painting a renderTargetTexture of the panel-o-sparticles... INSIDE the fonts.  But a guy COULD (i think)!

Back to our image of water rings... INSIDE the fonts.  https://www.babylonjs-playground.com/#11JINV#61

This time, I have turned-on line 304... which makes the image paint into the fonts over and over.  Look at the frame rates.  Pretty muddy, eh?  *nod*

Subtract another 10%, and we can predict the frame rate... IF we ever decided to grab the sparticles panel into a renderTargetTexture, and use THAT as our ANIMATED inside-the-fonts image.

Sparticles... INSIDE THE FONTS!  How cool would that be?   Perhaps I don't care HOW SLOW that would be, I may need to see it done... out of pure curiosity. 

So, who is a pro at renderTargetTextures?  Are there OTHER ways of showing the sparticles (sparkly particles) from PG#60... INSIDE the fonts ONLY?  Layermasking or renderGroups or blendingModes or some other complicated thing?  I would LOVE to see fully-animated sparticles... INSIDE the font volumes.   Anyone want to try it?  (please). 

I need to woof a bowl of Ralston and go do some snowblowing.  We got a little snow last night, and the mailperson paths and driveway... need cleaning.  Ahh, thank goodness spring is near.  Snow is fun, but sometimes it lasts too many months.     Snowblow on!

[Wingnut]

https://www.babylonjs-playground.com/#EYEPRI#3

Slow-loader, then... DROOOOOL!    BJS superhero @Sebavan is involved with this, somehow. 

(advanced shadow stuff, way the hell over my head). 

What a fine model/scene, eh?  *sigh*  So real it's unreal!  Don't forget control-dragging... to slew-around the cam target.

[Wingnut]

Ok, so, am I going crazy, or has the playground quit doing decent console errors?  I use-to get property not found, method not found, all sorts of noisy errors at the console... when doing playgrounds.

Now... lots of silent failures.  Sometimes, ya don't even know an error occurred... until you click on canvas and try camera nav (and learning its all locked up due to unreported error).

Something changed. 

Playground Intellisense got retarded, too.  Sometimes I actually have to TYPE-OUT 'getAbsolutePosition' and 'convertToFlatShadedMesh'.  That's HARD TYPIN'! 

Stuff happened.  Scope shiftings, it seems.   I know there's work in progress, and I know that half the blame... are these wobbly browsers we use.  Just curious about stuff... wondering if my friend the playground... is healthy and happy.    Ya'll have a fine weekend.

[Guest]

can you give me some examples of both intellisense and silent errors?

[Wingnut]

Hi DK.

http://www.html5gamedevs.com/topic/36894-lights-and-material-configurations/?do=findComment&comment=211209

Read there, and next 2 posts.  User andrewandrew taught me about why intellisense was not providing 'convertToFlatShadedMesh':

I think its because the "mesh" object gets interpreted as AbstractMesh, and there's no such function defined

Briefly:  https://www.babylonjs-playground.com/#LB4MVX#6  Line 25... try typing mesh.con...    'convertToFlatShadedMesh' ... is not a choice in the intelli-list. 

Cuz we're inside the loader callback?  Maybe.

Silent errors... next post.

[Wingnut]

Ok, here we go.  (thx for checking this out, too.  Likely Wingnut screw-up... you know me.)

https://www.babylonjs-playground.com/#XY4MQ5#24

Lines 80 and 82.  Should they cause console error?  Seems to me, yes.

[Wingnut]

Hi again.  Here's another of those "why no error?" situations... in Firefox 52 esr:

https://www.babylonjs-playground.com/#QKQHS#542

Not sure if my bitching is substantiated, but had I not used a try/catch... I would not know that I forgot to capitalize 'toRadians'.

Could be Firefox 52 causing the problems.  Help/advice/correcting-of-Wingnut-stupidity...  whole-heartedly welcome. 

Wingnut working-on a 22+ hour zero-reply first-timer question that SHOULD be easy to answer... but I'm not so sure.  de-quaternification ops     Quat-to-degrees, needed.  Prolly EZ, but Wingnut is Quat-impaired. 

Nobody uses 'delete' anymore.  Soooo, when I use it on box.rotationQuaternion... I get a little techno-woody.  heh. 

Does .rotation property return-to chief/boss... when .rotationQuaternion gets assassinated/murdered?  hmm.  Inquiring minds want to know.   

Does a rotQuat set == .Identity()... relinquish control to .rotation? 

How about a rotQuat set == .Zero()? 

(Wingy pokes-at a delicate section of the framework... with an oversize screwdriver... causing sparks!  He's an idiot, eh?  *nod*)

[Raggar]

1 hour ago, Wingnut said:

Does .rotation property return-to chief/boss... when .rotationQuaternion gets assassinated/murdered?  hmm.  Inquiring minds want to know.   

If you simply null it out, it will automatically use the .rotation property instead.

[Guest]

https://www.babylonjs-playground.com/#XY4MQ5#24: I can see console error:

[Wingnut]

Thanks Raggar - for rQuat info!

Delta:  Yeah, I don't see that error report in my FF.  hmm. 

Thx for the verification.   (junky browser, but still blocks ads). 

update:  Wingnut's Firefox 52 ESR... about:config... search for 'console'... I found that SOME errors were being filtered, there.  I turned off many/most of those console filters, and console errors began working better.  PARTY!!!