continued_at_new_forum The Wingnut Chronicles

[joeBImagine]

@Wingnut you asked what am I working on!!  So I will share in the wingnut chronicles!!  

I am currently working on a babylon prop loader and texture changer.  As I love 3d, and have had a desire to get better with my javascript (and a desire to move to the web team ), I thought learning babylon and Javascript at the same time would be an awesome endeavor.  Couldn't do it without this awesome community however.  As they say sharing is caring, so my source code is here:  https://github.com/jbimagine/Babylon1  and a live demo here:  jbimagine.github.io.  It is still very much a work in process, and extremely rough around the edges.  

[Wingnut]

Thx joe! 

Wingnut had a demented idea, again.  (I have to type them here, whenever I have one... federal law)

Ok, let's say we got a big fat textBlock in the middle of an AdvancedDynamicTexture fullscreen... "Happy Holidays"  Big fonts... uses most of the screen.

Now... grab a particleSystem, grab the imageBuffer for the textBlock control, and use the particleSystem customStartPosition feature/func... to put a particle at every pixel of the image.

Then use the particleSystem customUpdate feature/func... to random-color them puppies... or wiggle them... see if you can make some sparkly glitter. 

Possible?  Sure it is. 

Someone run-with-it!  I'm too lazy.  (I sort-of hate dealing-with Context2d image buffers, too.) 

But, in the grander picture, I have been having thoughts-of "particles as textures", lately.  Billboarding off, coat the surface of ANY mesh... with particles.  Glitter boxes.  Glitter spheres.  Santa Claus is coming to town, so it's tinsel time.  Time to get sparkly.   

If everyone else screws-off long enough, I guess I'll have to build it.  But, please, somebody, feel free to build one.  Glittering/sparkling GUI text/borders... would be SO... holiday-cooool!    What's that?  A particle for EVERY pixel... is too much?  Yeah, maybe so.  Every OTHER pixel that has color, eh?  *nod*

Ok, that is all.

[Wingnut]

Wow, I can see that the response is overwhelming!  SO many users logging-on to participate in this "idea", that it looked liked a forum denial-of-service attack!  heh.

BABYLON.GuiEffects v1.0.  Makes ANY (renderable) BABYLON GUI control... into a Christmas tree ornament!  C'mon!

And for mesh with (advanced)DynamicTexture's... well... we ALL know that there's only ONE WAY to get sparkly snow on your terrain.  Yep... particles-as-texture, or customShaderMaterial, or direct high-speed manipulation of image buffer data used for GUI and other dynamicTextures.

Okay, fine, there's THREE ways to get sparkly GUI text, borders, and snowy terrain.  But particles-as-texture would be the WORST way, so that's the best way for us.  It is most demented.

Here gang... start with this.  A "custom start-position function" is in lines 12-15 (a custom start-pos func tells WHERE each new particle will spawn).  ANYWAY... with the help of getCart() and plot1(), it has placed ALL the particles... in a sphere-shape, almost like PARTICLES-AS-TEXTURES.  (I'm trying to emphasize that phrase.  Can ya tell?)

So, now, all ya gotta do... is put big fonted "HAPPY HOLIDAYS" on a plane, using a BJS GUI textBlock... grab its image buffer, and... you know... do some other difficult stuff... so that a single particle sits atop every 2px * 2px part of the image buffer... that has colors set.  (position them in-front-of the "Happy Holidays" text... on the plane.  SIMPLE! 

How about you, DeltaKlaus?  Doesn't "particles-impregnated GUI-colors"... sound like a cooooool feature?  Glitter! 

Or, at least... the Babylon.GuiEffect Class.  Wow... that sounds important!  A lib of post-process effects specifically for font-effects and border effects.  Far out, man! 

I wonder.  hmm.  On your average 512x512 image buffer... how many iterations thru it (to mess-with its colors)... could we do... per frame?  If we could get one "repaint" per frame or more... then we can do direct-attacks on the image buffer of GUI text, and NOT use particles, eh?  *nod*.  But... WILL a Babylon GUI textBlock... update its "paint"... if Jerome repainted the image buffer in Mandelbrot fractals?  (Must repaint only pixels where there is already a color - maintaining the character/font shape) 

Fractal-texture text for GUI?  TOO COOL!  (esp if it is animated real-time - like our fireTexture).  How about fonts as godrays emitters?  Wow!  "Happy Holidays " in sparkles and godrays!  Mega-demented!  Advertisers would love it.  Burn your brand name right into the viewer's retinas!   Jabylon BS!  errr...  hmm.

Speaking of a fireTextured bigtext-on-a-plane "Happy Holidays", ahem.  But we're not talking backgrounds, here.  We're talking the fonts themselves... have animated textures.  Can that be done?  What kind of idiot would it take... to TRY such madness?  hmm.  Let's get "moving"!    (I'm a pathetic cheerleader, eh?  I ain't got the legs for it.)  heh

[Arte]

@Wingnut Can you help me find class responsible for zoom (mouse wheel)?

[Wingnut]

Hi @Arte.  I think that's part of src/cameras/inputs/etc. 

https://github.com/BabylonJS/Babylon.js/blob/master/src/Cameras/Inputs/babylon.arcRotateCameraMouseWheelInput.ts

Just in case you need mousewheel stuff on a FREEcamera...  http://playground.babylonjs.com/#6FHKHC

Watch console while wheeling.  Lines 62-65 is a little wedge-in.  Forum message about it... here.  Party on.

[Wingnut]

Hi again, kids!  Anyone working-on particles-as-textures, yet?  C'mon!  Somebody code that for us! 

Ok... back to holiday sparkles, glitter, and light-bulb flashing.  Check this out...

https://www.babylonjs-playground.com/#14FG1S#2

I believe that was coded-up by @Nabroski and... well... it's morbid... but it does GREAT flashing, imho.

Remember last year's no-lights LiteBrite demo?  Certainly very little "intensity" in those light bulbs.  But perhaps... with some GodRays like Nabroski used... well... I dunno.

Nab's demo... man, that thing will burn retinas! 

I decided to do a "poor mans" sparkly-particles (sparticles)... 6-plane box... with "distributed emitting" (to avoid particles INSIDE-OF the box, encountered by using the particleSystem's 3D emitBox system). 

What a sentence, eh?  To word it more simple, a 6 planes box with each plane emitting particles with almost NO emitPower, and NO directions.  (But don't forget the PS custom update function... which causes "sparticles".)  No particles are inside-of the box volume.  Here we go...

https://www.babylonjs-playground.com/#1NXKLI#7

The particles are not evenly spaced/distributed on each plane, but it still has an interesting "look".   Fun for the entire family!

Tweak some knobs... here's another.  Line 100 max particles 800 (low).  I increased maxSize in line 107, and I have a huge emitRate in line 122.  MaxLifeTime is also important.  FUN! 

What's that you say?  You want a freeze-frame of a close-up, after 3 secs?  Okay... here we go.  Nice, eh?  Not really "frozen", either... cam works fine.  SO, set cam minZ LOW, set cam wheelPrecision HIGH, and we can tour the skin-of-particles.  Don't forget control-dragging... for camera.target slewing.  Pretty tour.

Good holiday "mega-twinkies"!    Twinkle-shaped star.jpg texture totally rocks.

I can certainly "imagine" GUI text (and maybe borders and other context2D-painted things)... sparkling just like that.  Coooooooool!   

But how does one "map" a "sheet of particles" as if it were a texture?  hmm.   Not easy, I suspect. 

Easter Egg:  Does anyone else... see the freeze-frame demo... lose all its colors after xx minutes?  I think I saw it... twice (after about 3 minute wait).  Bonus points for information leading to the arrest of "What the hell is going on with that?"    Perhaps switching-to custom update function #2, after 3 seconds, is not the best way to freeze particles in their tracks.

[Wingnut]

Hi again.  Whelp, I decided to hack some image buffer stuff on an advancedDynamicTexture (ADT), and see what I could blow-up.

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

There's my lame GUI text scroller once again... but this time, massive work is happening in lines 124-176.

This PG uses two ADT's... and the textADT (the scrolling non-picture-frame part) is the one being "attacked" by me. 

I am trying to change ALL pixels with alpha > 0 (all pixels which aren't transparent)... from black... to green.  (make all text green)

I think it is ALL working... EXCEPT... triggering the textADT to update (to use the new buffer called output).

Does anyone have any ideas about what the hell I'm doing wrong, and/or IF ADT's or textBlocks are allowed to update their image data (and how that might be done)??

I set various ._isDirty = true... and call various mark*AsDirty() methods, but no joy, so far.   I tried adt._render() and adt.update()... nope.

Btw, this is the "direct image buffer manipulation" I spoke-of, earlier.  This buffer is 1024*1024 with total bytes = 4,194,304.  I wanted to achieve at least one complete image buffer re-paint (swap-out) per frame... for making sparkly pixels on GUI text.  But one repaint every 5-10 frames would be fine, too.  I'll take whatever I can get.   

Perhaps I need to "re-create" the textADT (or the text1 textBlock) after each imgData re-paint/swap, huh?  hmm.  Text1GUI textBlock has no ._context for me to hack-on imgData for IT, but it does have .color = "black".   That COULD be over-riding my change-to-green-text operations, I suppose.  But setting/leaving text1.color = ""... has no affect.  Is text black by default - when no color is set?  hmm.  I might need to go core-diving. 

Any info/help.. quite welcomed.  Thx!

[Wingnut]

Hi gang.  Well, that last subject garnered so much interest... that I decide to try another. 

http://www.html5gamedevs.com/topic/20484-how-to-contribute-to-babylonjs/?tab=comments#comment-120412

I am trying to fix that link.  Does anyone know if/where a "terms of service" or "terms of usage" exists... for the playground app?  thx for info.

I also tried an animated .png as a lens flare texture... just for fun, but that didn't work.  No animation.  Shader refmap thing?  Thoust shalst not animate sample maps? *shrug*  I wonder how the BJS fireMaterial does it's animating.  I love that fireMaterial thing... it's nice.

Hey, a guy HAS TO try at least one demented experiment per day, right?  Party on!

[Wingnut]

Okay, let's try something new and extremely off-topic:

About owning a computer:

For this campfire-pondering, let's assume that before mankind arrived on the planet, there was no such thing as (en)titles-of-ownership, or price tags, or FOR SALE signs, or NO TRESPASSING signs.

Under most ownership laws, doesn't the initial "owner(s)" need to be contacted, and approve-of... all owning/selling attempts of ALL Earth materials (and things made-from those)?

All Earth "things" are made FROM these "we can't find the initial owner" Earth materials, right?

Per "standard" ownership laws, can "things" made from Earth materials... be "legally" owned?

There, that's a good "heavy" hippy campfire topic.    (Wingy digs-into a nearby cigar box... to find his computer sales-receipt) 

Okay, okay, we need a pretty playground to keep it SOMEWHAT on-topic.  Somebody made THIS most-excellent PG.  It blows!  (in the wind) 

[Wingnut]

Ok, https://www.babylonjs-playground.com/#1ND6TH#23

Hi gang.  Moving ahead with "the human leg" physics project.  @RaananW promised to help, but I think he was going to do his own thing. (I don't think he likes my physics coding style.) 

I haven't changed much from the initial demo, from another thread.  I got the sections a bit more proportioned.  Fast screen clicking impulses upper leg (red part)... both leftward and upward.

Boy, is that scene slow, eh?  It is for me.  Raanan says it has to do with world scale, and it only LOOKS slow.  But I don't quite understand.  For the mass weights I'm running, it IS slow.

Anyway. I am going to try Oimo hinge2joints, first, with their 2-axes and 2-limitMotor constraints.  (currently, set to single-axis hingeJoints) 

Early-on, we I should work-on the hip.  It should allow the upper leg to pivot about 80 degrees horizontal (spread 'em)... and about 170 degrees vertical (for those good cheerleader high-kicks) 

But, before this project advances toward Jointsburg, I want to "activate" my new "Pulsars" idea... little arrows that you can place upon physics active mesh... and click them to applyImpulse on the mesh's impostor... at that location and direction. MANY of them, on a single leg section.

I want to SEE that hip joint's lateral angle-constraints - in action.   Pitchew, pitchew... blasting those bones with the air hose... making sure they are acting correctly.  A true joints-testing laboratory!  YAY!

It's the start of teaching physics joints... with playground-based tutorials (PBT's).  DOUBLE YAY!!  

To properly watch a joint... sometimes you need to get the camera REAL close... and attach the micro-nozzle on the air hose.  Pitchew  Pitchew!

Seeing is believing.    Impulsing arrows.  Pulsars!  "Imps", if you wish.  Coming soon, to a leg NEAR YOU! 

Still, I think Oimo is somehow unduly lazy/slow.  It's got a boggy stepper... me thinks.    (Wingy greases Oimo's joints with hot bison snot.) 

To me, it looks like the scene starts-off pretty fast, but bogs after the first mesh collision.  hmm.  Anyone else see that?

[Wingnut]

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

A "sneak peek" at the first ever... Uncle Wingnut's 'PulsAr' - Physics ImPULSing ARrow... attached to a physics active mesh.  WOW!  (snore)

No, the pulsar doesn't yet apply any impulse, and it's not clickable, or bound to a keypress, or anything FUN, yet.  But, it looks kind of goofy, eh?

HighlightLayer "glow"... flutters when it moves.  Purrrrdy.  A temporary impulsing is available with quick screen clicking.

-21 Y-offset needed in line 292... to position pulsar upon the mesh at the wanted place?  hmm.  Something is wrong there, or in line 271.  *scratch scratch*  I was hoping for something like -3... considering part2 (red) has a height of 8.

Note:   For IE users:  https://www.babylonjs-playground.com/#1ND6TH#27  IE (for me)... does NOT like this structure:  =()=>    Also, it hates when I type a trailing comma... on the last item in an array/list.  SO bitchy, that browser!    Both things cause a "syntax error" in IE.  I tested in IE.. to see if Oimo would speed-up.  Nope, still SLOIMO.  (Wingnut checks the physics-oil bottle, to see if it was made in maple syrup country.) 

[JackFalcon]

Like pulsars! And sparticles... etc.

 

What if it scaled slightly?

 

[Wingnut]

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

There's another version of the pulsars.  Three of them active on our leg, all clickable.

Seems ok.  Party on!

[JackFalcon]

Likes that so much, glowing triangles... favorite!!!

Rigging in Babylon... see you...

~...

[JackFalcon]

SIDE-NOTE: @Wingnut - is there concept of maximum-physics and/or minimum-physics solutions...?

Happy holidays.

 

[Wingnut]

  Nothing at BJS level (that I know-of), other than minimizing meshImpostors and heightmapImpostors.  But most of our physics engines are written in JS, which means... you can hack the solver formulas... make them weaker, and thus run faster, but with less "features".

But, you get the same performance bump by doing things like fixedRotation, or setting restitution, friction or mass to 0.

At some point of de-powering, you would probably start to consider writing your own "hybrid" physics system.  Our ellipsoid/moveWithCollisions system could be considered a hybrid, I think.

Jerome once wrote a cannonball parabolic-flyer with ground-bounce.  He uses it in his Artillery Duel demo on his website, and I think a PG is nearby, too.  That would also be a hybrid physics engine.  No need for full physics engine for firing cannonballs at things.  And you've seen the new "explode" thing,  and we have chunky particles with SPS and .manualEmitCounts... so... even when it comes time to blow-up the cannonball target, a person could avoid standard physics engines there, too.

It's difficult to determine where the line is... between minimum/maximum.  That line would move-around depending upon the project/needs.

Deep hacking into the physics engine solvers, and learning about broad phase, and narrow phase, and islands... phew... it's likely a 3-year power-study to get it "by the balls"... but... you'd be a physics superstar afterwards.    You'd probably release 3-10 "new" versions of Oimo. 

Perhaps it is also wise to think about... What physics help will we get... from hardware, in the next gen of puters?  Is there a chance for soft-bodies in the next gen?  If so, that's a whole new ballgame.   

Just my opinion.  I'm not really qualified to answer a question like that. 

[Wingnut]

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

OMG!  I don't know about everyone else... but the speeds on this version have FINALLY awoken!

This thing is wiggling so fast, I can't get a 2nd mouse click on a moving pulsar arrow.  It's like shooting walnuts from atop a friend's head with a very heavy muzzle-loader while seriously drunk! 

(increasing the pulsAr-row sizes is easy, no sweat)

I can't describe what a great relief it is... to see Oimo operating-at (my) expected speed/fluidity. 

Line 419 did it all.  scene.getPhysicsEngine().getPhysicsPlugin().world.timeStep = .05;  Default value for that... is 0.01666.   Essentially, I tripled it.

I'm still looking for input from others, trying to determine IF/NOT the NEED for this step-value change... is caused by something on MY computer ONLY.  The speeds were slow in both FF and IE, here, but @RaananW didn't think it was unduly slow.  So, perhaps timeStep = .01666 was working perfectly fine... FOR HIM.

And there's always the possibility that he forgot what a SMOKIN'-FAST (simple) physics scene SHOULD look like. 

To me, now, this scene is up-to-speed and looking good.  I increased gravity from to -9, which is near earth gravity. 

My part masses are all 0.1 so they are still somewhat low. 

I NEEDED-TO really crank-up the power of the impulse arrows.   I added a "gf" global force amplifier in lines 366-367.  No problems, still quite normal.

ahhhhhhh.  Life is good again.  This friggin' leg will swing back and forth... for HOURS!  The Bison Snot physics lube that I applied to the joint bearings, earlier... is workin' great!

(Wingy dances around like an idiot, high-fiving everything in sight, including the ceiling fan blades)   GAME ON, BABY! 

I would like reports... PM or public, from anyone who saw no problems with early versions (which i called SLOW), and who see this new version as SO FAST that it is un-usable. 

To be briefer, I want comments from anyone who thinks this new version... is MUCH TOO FAST/WILD.  I am looking for speed differences in Oimo, across various platforms.  THX!!!

 

Update:  https://www.babylonjs-playground.com/#1ND6TH#42  Nothing new, just some cleanup, looking at wireframe, adjust cam a bit, bumped pulsar sizes up a bit... and made a global size setting for sizing.  I realized something, today.  Hinge2Joints will never satisfy the hip joint of our human leg, because Hinge2Joints have TWO axes of pivot, but the human hip... has 3. 

#1.  Pitch up/down around Z axis in my scene orientation (cheerleader high-kick),  #2 - yaw around Y axis (sitting with knees spread wide), and #3 roll - around X axis in my scene ('jumping jacks' sideways leg movement).  Me thinks we will need a ball/socket joint (which I think RaananW suggested), but we need THREE, yes THREE rotational constraint limit-motors.  Holy crap! 

I think Raanan and another suggested that we could "stack" three standard hinge joints (each one servicing a different axis), with some no-space-taking invisible mesh in-between.  But really, a 3-axes... 3-rot-angle-constrained ball/socket joint... is more like real life.  So, if we can do that, let's do that.  Demos welcome.    Third hit when searching this document... for 'socket'.  There it is... the Oimo BallAndSocket joint.  Quite basic.  No sign of 3 limit-motors seen.  I'm scared.   

 

Aw heck... ballAndSocketJoint on all three joints.  HERE WE GO...    All pulsars active, but you might need to pan camera... to attain click-ability on the back ones. 

All pulsars were active in previous versions, too, but the z-axis pulsars (front and back) were constrained to small "hinge slop" movement.  This is the same "slop" seen in my CannonJS train wheel demo.  See the wheel "bearing slop"? 

For those curious about CannonJS, I tried to speed-up THAT scene, too.  I found two properties on the Cannon world object... called .dt and .default_dt.  I can assume that means "delta time".  Both values were set to .01666, just like Oimo's .timeStep.  In lines 168/169, I tried the "triple the value" trick, and the scene... is still as slow as molasses.    Oh well... that is ONLY attempt #1.  More available. 

[Wingnut]

Hi again, gang!  Today, I introduce a new physics "widget" called a "Quasar" (sister to Pulsars).

Quasar stands for QUAternion Symmetrical Axial Rotater.  Wow, huh? 

Let's take a first-look.  https://www.babylonjs-playground.com/#1ND6TH#54

It looks similar to most other rotation widgets.  We have one for each leg-section.

Although quasars always apply their mesh.physicsImpostor._physicsBody.setAngularVelocity() at the center of the target... parenting is a CHOICE, and positional offset is available.  The 3 quasar shown in the scene... are NOT parented to their corresponding mesh, and they each have position offsets of x = 5;  See lines 529-531.

createQuasar("q1", "part2", 1, new BABYLON.Vector3(5,0,0), 3, null, null, false);

Params are:

quasar name (str),
name or direct ref to target mesh (str or obj),
quasar spin-power, (float)
positional offset, (vector3)
quasar size, (float)
unused quasar color, (color3)
quasar glow color, (color3)
parentToTarget?  (bool)

On any quasar, there are SIX (6) actionManager click-areas.  They are each a different color.  Do some clicking on the 6 sections, and watch the corresponding mesh/impostor TRY to follow your commands.  Currently, repeated clicks are NOT 'cumulative' (they don't keep adding more and more angularVelocity), but that can be easily adjusted.

I should probably change to directionalLights (a few of 'em) so the flat shading of the boxes... looks nicer.  We need, what... three dirLights of differing intensity... to light-up all sides of a box, yet maximize the "flat-shaded look"?   Perhaps only two... aiming-in from -1,-1,-1, and from 1,1,1 directions?  Somebody take care of that for me, eh?    Don't forget the handy light.setDirectionToTarget(somePosition), if you are setting dirLight positions.  DirectionalLight position-setting is only needed for... umm.... shadows?  Otherwise, they only need a direction... I think.

Quasars - just another fun physics toy... from the folks who brought you pulsars.  Comments/ideas welcome.  Expect bugs.  Party on!

Update:   Version 56 - Here, Quasar-clicks are cumulative.  Forces caused by each click upon any of six click-areas... is ADDED-TO mesh's current angularVelocity.  Heavy mods to quasar.impulse() func at line 265.  (yawn)

[Arte]

@Wingnut 

I couldn't resist to play with playground. I'm so sorry.

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

Christmas party on!!! 

 

 Merry Christmas to all of you!

[Wingnut]

Thanks, and same to you, Arte! 

Yuh, yuh, yuh.  While the rest of the forum tries to "get a leg up", Arte gets a tree up. 

On another subject, I'm ready to say goodbye to "This PG has missing metadata.  Click save to add them."  annoyance line.  Anyone else?  How about surrounding the metadata button with a border... if the PG has no metadata set?  Would that be enough?  Where do we vote? 

[Wingnut]

Ok, here we go... more leg-work.  Let's talk about our hip joint.  Likely, we CAN INDEED "stack" 3 standard Oimo hingeJoint's (with tiny invisible mesh between each), but I really want to pursue a "3-limit-motor" ball and socket joint.  (Note: In that playground, you can disconnect bones below the thigh/femur... by disabling line 176)

So, I went web-searching.  Check this out:   https://docs.unity3d.com/Manual/class-CharacterJoint.html

Doesn't THAT look delicious, eh?   A twist axis, and swing axes 1 and 2!   Perfect! 

We could build one of those, I bet.  A bottle of Wild Turkey and a 6-figure contract, and we'd be "off and running", right?  

But, at a certain point of over-engineering, one should probably think about "the stopper pin".  You sometimes see these stopper pins... keeping speedometer needles from dropping below 0.  In a different application of stopper pins, the railroad industry calls them "buffers".  I think REAL human hips... use bone collision as their angle-limiting method.  I don't recall ANY mention of "limit motors" in my basic anatomy classes. 

For us, buffers are simply an (invisible) physics-active mesh that is positioned near the pivot point of a ball-socket joint.  Because of colliding, they can be used as angle-limiters... on ANY of the three axes.

We would probably need 6 of these "buffers"... to get min/max on each of the 3 axes. Perhaps they need to be planes, and slightly angling these planes... would let us adjust separate/individual negative/positive limits.  For example, a high-kicking cheerleader can kick nearly straight-up, when kicking forward.  High-kicking backwards... is much more limited.   

We must be careful here.  Upper/lower limits can be expressed in AMOUNT OF degrees of allowed rotation (mesh local-space poles, which could be tumbling), OR in world-space rotation FROM... perhaps, camera.Down()/Up().  Essentially, "What IS centered/idle?".  "What reference angle do we measure angle-limits FROM?"  We'll talk.  (I'll talk)

When using precisely-positioned buffer planes as our limiters, adjusting precise angles, in degrees, would likely be "hunt'n'peck" (lots of tweaking of the buffer positions until satisfied).  Naturally, angle-constraining to 45 and 90 degrees... would be fairly simple.  But, odd angles might be more challenging.  It is not a very precise way of angle-constraining, but it is quick and dirty.

These are just some things I'm thinking-about, today.  I am also trying to study the "generic" Oimo limitMotor... to see if we can easily "add"/"extend" an Oimo B'n'S (ball and socket)... WITH 3 of those motors.

All info/research welcomed... of course.   And if any of you are experts in XSL, would you consider writing an XSL stylesheet that makes this document... much nicer formatted?  That would be great.  Just possibly, Oimo is an accurate JS version of Ammo/Bullet... and we could use Ammo/Bullet docs... for Oimo as well.  *shrug*.  Lots to learn.  Party on!

[Wingnut]

Oooh, check this out, guys.  [document]  Search for 'Rotational3Constraint'.  " A three-axis rotational constraint for various joints. "

Oi mo goodness!  This sounds promising.

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

I tried to activate one at line 563.  It's grumbling at me.   

Ahh, Raanan once showed us the source for it... https://github.com/lo-th/Oimo.js/blob/gh-pages/src/constraint/joint/base/Rotational3Constraint.js

Yuh, it's a container for 3 limit motors.  It looks like I need to make them, first. 

Update:  [link]  lines 555-570.  Created 3 limit motors, lm1, 2, 3.  Added them to Oimo world, but not sure if that was needed. 

var test = new OIMO.Rotational3Constraint(joint1.physicsJoint, lm1, lm2, lm3);

I had that line wrong, at first. "joint1" is a Babylon object, and it had no .b1 and .b2 properties.  I needed to use the actual (Oimo)  .physicsJoint for the first parameter.

So, it APPEARS that we (I) have installed a Rotational3Constraint on joint1!  YAY!  I have chopped-off the leg at the knee... and now it's just us (me)... and an out-of-constraint hip joint.  Let the experimenting begin!  According to docs, we enable all three motors first, and then it's r3c.upperLimit1-3 and r3c.lowerLimit1-3.  Six fun knobs to turn.  r3c is currently named test.

Another update:  [PG #63]  Lines 555-610... I activate every delicious-looking property found on a rotation3constraint object.  Most were set NaN before I put values into them.  Now, most of the values are set to .5, which is weak, as far as forces go.    

The power of repeatedly-clicking various axes on the quasar... MIGHT be over-powering the .maxImpulse and .maxForce of the r3c.  With me?  (snore).

It is possible that I need to set values on r3c.limitMotor1/2/3.  That seems dumb, though.  R3c looks like it is designed to hand-down property values... to the 3 limitMotors... automatically.  This "assign" thing is somehow pertinent.  It appears to SUCK the values off-of the 3 limitMotors... and put them onto r3c.  hmm.  I wonder if/how I call that.

Another:  [PG #64]  Lines 611-636 - stocks some values into r3c.limitMotor1/2/3 properties.  No limits/results seen yet... when whackin' the quasar.  "Whackin' the quasar"    I wonder if these limits work with radians, or degrees.  I should read the docs, eh?

Side thought:   Who thinks options/parameters objects could be a bad idea... because the parameter names cannot be translated to a different language... IF our docs were ever translated?  For example... the Spanish word for tessellation... is mosaico.  But even if our docs were being viewed in Spanish, the users could NOT use 'mosaico' in an options object.  It is hard-wired to be 'tessellation'.  Discuss.  

[Wingnut]

Hi gang.  Just trying some new things on the hip joint challenge.  https://www.babylonjs-playground.com/#1ND6TH#68

Line 167 - create a Oimo jointConfig and stock it with some goods.

Line 184 - create a "generic" Oimo joint, using jointConfig as the param.  Also tried var joint1 = new OIMO.BallAndSocketJoint(jc);  error type[0] is undefined.

Line 602 - added joint1 to OIMO world.  604-606 create limitMotors for 3 different axes.  See next line.

Line 614 - Create the rotational3Constraint (r3c), using joint1 as first param, and those 3 limitMotors as the last 3 params.

Line 616 - optional line to do world.add(r3c).  Not sure if needed.  Constraints don't sound like the kind of thing that needs adding to a world.  More likely, added to a joint.

Lines 622 - 692 - attempt to stock the r3c with some values.

No luck at all, so far.  Joint is not working at all.  Femur falling failure. 

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

That "assign"... I don't understand what that is used-for, or how.  Hopefully, it's "for internal use". 

Version #69 hijacks entire Oimo plugin into PG.  (So I can have a quick-ref to wise things from Raanan and others who have written code in there.)

sigh.  Back to work.  Assistance welcome, as always.  Sorry for messy playground.  If someone wants to move pulsars and quasars to someplace more sane, like Babylon physicsTools.ts/js... that would be fine with me.  Feel free to make them better, too.  And then take ownership/custodianship of them, and maintain them forever.  Thx. 

[Wingnut]

Hi guys.  Okay, today I'm moving forward with the Oimo 'WheelJoint' (line 570).  In its source code, it shows (line 10) that it imports-in a Rotational3Constraint... possibly "by default".  I don't need the Translational3Constraint imported-in at line 9, so I'll probably "fix-ate" that baby. 

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

Just getting started. So far, console says it exists (line 1005)... but our Femur has disappeared.  It flew away.     I'll find it.  I think the dog might have dragged it off somewhere.  heh

Umm... it all started... when I noticed a conspicuous property on a ball'n'socket joint... named .lc.  After touring B'n'S code, I discovered that 'lc' stands-for "linear constraint", or in other words, translational constraint.  "Well sheeeeoooot", I said.  "There must be an .rc (rotationalConstraint) there, somewhere, and I will put my manually-created r3c constraint... into that property."

Well sheeeeeeooot... ball'n'socket had no .rc... only .lc.  Well then I started sniffin' around... and re-discovered the WheelJoint... looking very ready to go.  It has .r3 and .t3 ... which means... rotational3 and translational3.  Yum!  THAT sounds like something we could work-with, eh?  Chew Bacca!

SO... off we go, into the land of wheelJoints.    Nog-on!

PS: Seriously off-topic, but for anyone who follows my OTHER hobby (destroying capitalism), I had a nice little exchange with a gentleman in the UK, recently.  He got holiday-busy (or the questions got too hard), but hopefully, "Martin" will engage again.  He has a tasty, no-anticap-censoring, no-joining, no annoying-ads blog, so, climb aboard.  Leave some opinions in the comments section, if you wish.  Even bash Wingnut to a bloody pulp... it's all good pain.

[Wingnut]

Hi.  Back to the physics 'hip joint' project... https://www.babylonjs-playground.com/#1ND6TH#74

I found the Femur.  I needed to add lines 574 and 575.  I thought... that I didn't need any axis settings, because, a WheelJoint (with its r3 and t3 constraints)... is an ALL AXES thing.  I didn't want to 'impose' a preferred/initial axis... upon it. 

But, no.  WheelJoints apparently need an initial axes of SOME kind.  And take careful note of the NEGATIVE value in line 575.

        mainAxis: BABYLON.Axis.Z,
        connectedAxis: -BABYLON.Axis.Z,

One would think... that the joint could 'derive' its initial axis/direction... from its .body1 and .body2 positions.

I had tried adding these lines MANY times, but I never added the - sign.  Without the - sign, the Femur is gone gone gone. 

Okay, now THAT goose-chase is done.  Phew, that was a gruesome side-trail... swampy and mucky... stinky... bug-infested.... snakes.

Now we're back to the high ground.  Our Femur is operational, ready for demented knob-turning (lines 1022-1094).  PARTY!

Currently, clicks on the quasar... indicate that this joint is firmly Y-constrained.  The Femur will NOT initially rotate on its Y-axis (tried at scene startup).  Click horizontal quasar disk just after scene start.  Y-axis is frozen.  Hmm.  

Actually, I guess it is rotation around the Z axis that is frozen, NOT the Y axis.  Things are sort-of spun-around a bit, likely due-to the way I created part1-part4, using meshBuilder.  I probably elongated the wrong mesh axis.  I will experiment, perhaps do some holiday vert-baking.    For now, Z-axis is vertical.

IF I change 574/575 to...

        mainAxis: BABYLON.Axis.Y,
        connectedAxis: -BABYLON.Axis.Y,

...stuff changes.  The joint is still working, somewhat.  Now, left/right pulsar arrows don't work.  Neither does blue and purple quasar clicks.  hmm.  Interesting.  Learning.  Perhaps Oimo is z-vertical... by its nature.  I should read the physics docs someday. 

In general, I have a bad feeling about this wheelJoint.  Line 13 of WheelJoint source:  "A wheel joint allows for relative rotation between two rigid bodies along two axes."  That's not enough axes to satisfy our objective, is it?  hmm.  We would still need to add an invisible/tiny dummy-shape between part1 and part2, and use a single axis hingeJoint there, to satisfy our 3rd constrained axis.  Remember - the human hip allows some Femur-rotation on all three axes).  Same as an automotive ball-hitch, for towing.

But, we might be able to "hack" the wheel joint... making it 3-axes.  The Oimo wheelJoint "holds" a rotational3constraint (an r3c or r3).  And an r3c... "holds" 3 Oimo limitMotors.  SO, just possibly, umm... hack! 

Essentially, it appears that wheelJoint isn't performing any calcs on one of the axes.  But perhaps I can do a little "hot-wiring".  Or, just a blatant re-coding of the wheelJoint class. 

Yeah!  WingJoint, a custom joint class.  Coooooooool.    (Wingy starts printing joint rolling papers with hippy-symbols and BJS screen-grabs)

Also, in these latest versions of the scene, repeated clicks on the green "spine" will reset leg to start-up orientation/energy.  I haven't learned how to do it in a single click, yet. 

Feel free to experiment, make more saves, show'n'tell your playgrounds...  teach us stuff!  Thx!  Wheel on!

PS:  Sometimes I use terms like "constrained axis" when I really mean min/max angle-limited axis.  A "joint" is considered a "constraint", actually.  CannonJS regularly uses "constraint" instead-of "joint"... in their API/doc.  A joint/constraint... constrains movement to ONLY the joint's mainAxis and connectedAxis.  THAT IS a constraint.  The amount/min/max angles of allowed-rotation... is known as 'limits'.  Sorry for my sloppy terminology.