continued_at_new_forum The Wingnut Chronicles

[Wingnut]

Hi again.  The great hip joint tests continue.

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

This is the first use of "H3J" system (the assembly of a currently-non-existent Oimo Hinge3Joint, using 3 "stacked" standard hinge joints). 

Lines 608-688 shows the activation of 3 standard hinge joints, one for X, one for Y and one for Z.  They are connected by 'ghost' mesh, which are currently just small colored boxes  (later invisible, and atop each other, using no leg space).  Each little box has a high-powered quasar attached, and red part2 (femur) still has it's low-powered quasar rotater. 

The 3 hingeJoints and 2 ghost mesh are spaced-apart a bit on the Y-pivot-points... to make them easier to see/test.  Later, they will be invisible, and there will be no gap between green part1 (hip), and red part2 (femur).  (Did I say that already?)

No limits are set, yet, but I DID use the BABYLON.MotorEnabledJoint class... in the joint creations.  I think all three joints are ready for min/max and/or limit settings. 

Why ghost1 and ghost2 are so reluctant to spin (high-powered quasars needed - line 1080/1081)... COULD BE because of the joint axes.  The "top gap" is a X-axis hingeJoint, middle gap... Y axis, bottom gap... Z axis.  (Too bad nobody is working-on a joint/impostor/motor-labeling GUI layer, eh?) 

Anyway, we know the joints are there, or else our ghost boxes and part2 would fall to the ground. 

We might need to adjust min/max-angle... one joint/ghost at a time, here.  We might need to disable gravity and place the femur into a more leg-like position (like horizontal sitting position).  But, we're on our way to Raanan's "stacked hinges" idea for a 3-rotational-axes "connection".  Patience is a virtue.  (erf)  heh

update: [link #88]  Here is a demo with ghost1 (fuchsia)  and ghost2 (blue) featured.  Camera is panned a bit left.  Joint1a (x-axis hinge) is in top gap.  Lines 653/654 set min/max of 30 degrees of allowed rotation around x.  Click red or orange area on top quasar... to see that... it works PERFECT!!!  YAY!  (Wingnut dances!)

Joint1b is in second gap.  It is a y-axis hinge, and lines 667/668 set -45/+45 degrees of rotation min/max.  Click green areas on 2nd quasar... to see that this ALSO WORKS PERFECT!  OMG!   YAY!  -45 degrees to +45 degrees rotation around Y-axis... lookin' good!

Activate line 689 to re-attach big fat femur, and ruin all the fun.     Work in progress, and some progress IS being seen.

[Wingnut]

Hi guys. 

My long-time-last-item on BJS Main Website... is failing in Firefox.  Still fine in IE.

http://urbanproductions.com/wingy/babylon/skyboxes/skybox_tour.htm

It has its own older version of BJS included from local folder.

I guess something changed in FF 56/57.   Shader error at console. 

Does anyone know why it would suddenly start failing in FF?  (thx).

[GameMonetize]

Not working on Chrome either..

Seems like you have a shader that does not work on webgl2

 

Do you use custom shader?

[Wingnut]

Hi @Deltakosh.  No custom shaders.  Same file from 3 years ago or more.  I didn't even know what shaders WERE, way-back when I made that. 

http://urbanproductions.com/wingy/babylon/skyboxes/skybox_tour.zip

I use window.whatever often... overloading DOM window object.  Probably not a good idea.

You can disable that demo on BJS web site.  I will try to update/repair it, soon.  thx.

[GameMonetize]

ok thanks

 

[Pryme8]

I think i got it!



Call the shadow stuff with a delay and see what happens.  Cause when I blackboxed it and stepped through it worked.

Or @Deltakosh fixed something, cause its just works in general for me now.
 

[Wingnut]

INTERESTING!!!  (thx for help).  Umm... I didn't change anything, anywhere, yet.  Still failing in FF after cache clear.

BUT... hmm... the skybox tour STARTED-as...

https://www.babylonjs.com/demos/shadows/

Look familiar?    THAT shadow demo still works for me, in FF.

Let's look at skybox tour shadows:

    var shadowGenerator1 = new BABYLON.ShadowGenerator(512, light1);
    shadowGenerator1.getShadowMap().renderList.push(torus1);
    shadowGenerator1.getShadowMap().renderList.push(torus2);
	window.sgen1 = shadowGenerator1;

	// wingy tmp addition
    shadowGenerator1.useVarianceShadowMap = false;

    var shadowGenerator2 = new BABYLON.ShadowGenerator(512, light2);
    shadowGenerator2.getShadowMap().renderList.push(torus1);
    shadowGenerator2.getShadowMap().renderList.push(torus2);
	window.sgen2 = shadowGenerator2;

    shadowGenerator2.useVarianceShadowMap = false;

    ground.receiveShadows = true;

Now, BJS website shadows demo... shadow code:
 

    // Shadows
    var shadowGenerator = new BABYLON.ShadowGenerator(512, light);
    shadowGenerator.getShadowMap().renderList.push(torus);
    shadowGenerator.getShadowMap().renderList.push(torus2);
    shadowGenerator.useVarianceShadowMap = true;
    
    var shadowGenerator2 = new BABYLON.ShadowGenerator(512, light2);
    shadowGenerator2.getShadowMap().renderList.push(torus);
    shadowGenerator2.getShadowMap().renderList.push(torus2);
    shadowGenerator2.useVarianceShadowMap = true;

    ground.receiveShadows = true;

Not much difference, other than useVariance true/false.  Current error:

Unable to compile effect: shadowMap        babylon.js:1:230665
Defines:
Optional defines: undefined

Unable to compile effect: default                  babylon.js:1:230665
Defines:
#define LIGHT0
#define POINTDIRLIGHT0

Skybox tour probably uses BJS version... ohhh... 1.08 - 1.18, which it loads from its local folders.  *shrug*

(Wingnut kicks Firefox and gives it the ol' stink-eye.)    hmm. 

I'm not going to modify original files... yet, or ever.  (Might make a different version, soon, though.) 

Leaving these files in the current condition... might help us learn more.

Thx for study!  For me, broken in FF 56 and 57.  Not sure about earlier versions.

[Dad72]

there is now this : addShadowCaster(mesh)  which replaces getShadowMap().renderList.push()

shadowGenerator.addShadowCaster(torus)

it's faster to add objects to the shadow generator

[Wingnut]

Thx d72.  Good new feature.  Won't work on this old BJS 1.18 scene, but good to know just the same (for when I update the Skybox Tour).

----------------------

On another subject (the physics-active human hip project)... I added some GUI in version #97. 

The scene wasn't yet big enough, so it needed more code.  heh.

I still don't understand WHY there is a big gap between part1 and ghost1, and between ghost1 and ghost2.  NO GAP (or spring-bounce) is seen between ghost2 and part2, and that's the way it SHOULD be, in my opinion.

All three hinge joints (lines 649-690) are set for no gap... for their main and connected pivot points.

The green spine is 10 units tall, so the mainPivot-Y on joint1a is set for -5.0.  AND the red femur is 8 units tall, so mainPivot-Y on joint1c is set for +4.0.  No gap-causers there.

The "issue" seems to be related to the SIZE of the two ghost mesh (they will be tiny/invisible in end result, adding NO GAP between hip and femur, in the end).

Ghost size is set in line 611.  Set that line to .25 and the gaps for joint1a and 1b... get ridiculous.  WHY?  Why should a size change of the ghosts... change the space they take up?

And joint1c between ghost2 and part2 femur... PERFECT.  Ghost2 is locked onto the top of part2 perfectly, as it should be.

Now try .75 in line 611.   The joints "tighten-up" rather nicely.  Why?  hmm.

Now try 1.0 in line 611.  Even tighter... but... there is some collision happening.  All joints are set collision:false, and all restitutions are set 0.

At gSize 1.0, tt appears that physicsBodies HATE being (perfectly?) atop each other, even with no collision calculations being made. 

That's an over-simplified statement.  Actually, blue ghost2 REFUSES to overlap green part1, yet there's no reason it shouldn't.  Pink ghost1 IS allowed to overlap red part2, it seems.  Although I cannot turn-on mass for part1, JUST POSSIBLY... since part1 has 0 mass, it set collisions

The H3J system... 3 stacked hinge joints... might be the death of me.  heh.  But, I think we MIGHT have some bugs, here.

Part2 (red femur) is NOT  <  1x1x1 in size.  Perhaps THAT is why joint1c just above it... is not springy and loose.  Ghost2 is firmly "jointed" (joint1c) to part2 top, as it should be.

Perhaps... whenever the shape attached at the connectedPivot.. is less than size 1x1x1... things go sloppy and springy.  There SHOULD BE NO springy-bounce in this scene at all, actually.

Help/ideas/tests welcomed. (thx)  PS:  To keep GUI sane, you might want to avoid mouse-wheeling and camera pitching/tilting.  Maybe pan left/right only. 

[Wingnut]

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

  (ignore some of the gui pointers in this one - there are some mis-alignments)

Another test, with line 611 gSize (ghost size) set to 1.0.  Ghost1 is overlapping part1 and part2 fine, but ghost2 refuses to enter/overlap part1 (green) volume.

In lines 532-535... I did some dangerous object-inspecting and hacking.  I tried to remove part1 from the physics island, tried to force it to be dynamic instead of static... no changes seen.  Believe it or not, the object inspector says part1 has a mass of 40 (perhaps physics engine makes ALL isStatic = true bodies... be mass: 40).  I set no mass: 40 on part 1. 

The point is, IF I was successful at "forcing" the p-body into isDynamic = true, then our green part1 would have PROBABLY fallen (like a mass: 40 body WOULD).  None of my experimental lines 532-535... caused part1 to fall.

Meantime, what the heck is making part1 REFUSE to accept overlap from ghost2?  (Wingy does a beard scratch)

The collision: false setting for joint1a (line 659)... probably set NO COLLISION ALLOWED WITH EACH OTHER... for the bodies used for THAT joint.  The bodies on each end of joint1a... are part1 and ghost1.  Likely, THAT is why ghost1 is allowed to overlap with part1.

But ghost2 has no such agreement with part1.  Ghost2 has that same no-collision agreement with ghost1, but not with part1.

Somewhere upon part1.physicsImpostor.physicsBody (I think)... there must be a setting that allows ghost1 to successfully overlap part1. Sort of like an array of .excludedFromCollision shapes. 

I need to add ghost2 to that setting/array, somehow.  Maybe that setting is on joint1a (which would be weird).  I'll find it, or die trying (not to be confused with tie-dying). 

Extra credit:  Ghost1 has no DON'T COLLIDE WITH ME agreement with red part2, yet pink ghost1 is allowed to overlap red part2.  Go fig.  Ghost1 has about a 50% overlap into part1 and 50% overlap into part2.  THAT is the expected successful behavior.  Ghost2 needs to do the same, and do 100% overlap with ghost1.  Ghost1 and ghost2 should be perfectly atop one another, both having 50% overlap with part1 and part2.  Stay tuned... we're just getting warmed-up.  Help welcome.

[Wingnut]

Update:  (the continuing HIP->FEMUR story)

I think... when one physics body is not allowed to overlap another, it is under the control of a contactRestraint.  When I was obj-inspecting part1.physicsImpostor.physicsBody, looking for learning, I saw contactLink and jointLink.  The contactLink area is rather nested (objects of objects of objects) and I got confused and scared.  I'll be going back into that area, soon.

I also scoured the Oimo source repository for clues, and here ya go.   https://github.com/lo-th/Oimo.js/tree/gh-pages/src/constraint/contact  It is an entire 'contact SYSTEM', eh?  It's only, perhaps, the MOST important part of a physics engine.  Prevent these contacts from being added to a body, and we prevent collision-processing, I believe.  THAT'S where my area of study... is heading next.  See ya there.  Slowly but surely, we write the Oimo docs.    Only 2-4 more physics engines to write docs-for, yet to come.  Easy.  (Wingy shoots himself, but his head is frozen solid and the bullet does no damage at all.)  heh

Oooh, check this out.  world.removeContact(contact).  https://github.com/lo-th/Oimo.js/blob/gh-pages/src/core/World.js#L379  hmm.  And this... https://github.com/lo-th/Oimo.js/blob/gh-pages/src/core/World.js#L806  -  belongsTo [what collision group] and collidesWith.   A couple of interesting parameters, eh?  hmm*2  I'm not exactly sure what the 'o' variable IS, but, it might be 'shape'  (shape == impostor, for BJS-Oimo, I believe).  Interesting! 

In lines 814/815, we see that collidesWith and belongsTo... 'live' alongside mass, friction, and restitution.  SO, although they are available 'native parameters', they MIGHT be able to be used as parameters within the Oimo plugin impostor-creator.  In other words, use collidesWIth and belongsTo... just after mass, friction, and restitution parameters.

I will try to verify that the Oimo plugin impostor creator... honors/uses those parameters.  https://www.babylonjs-playground.com/#1ND6TH#103

Lines 532/533 are the first attempt to get our green part1 to NOT COLLIDE WITH ANYTHING.    As you can see, ghost2 and red part2 (femur) ARE colliding with red part1.  Unwanted.   

We have the Oimo plugin in-PG!  Line 78, AND lines 310-331... don't look promising (as far as Oimo plugin honoring/including collidesWith and belongsTo params).  Oh well, we can do some "hot wiring" of our own, and perhaps, eventually, add some new features to our Oimo plugin.  Coooooool.  We have a pretty good testing PG for both of those new parameters.  Why not turn 'em on and try 'em out, right?  We have fireproof suits, leather gloves and safety goggles.  We're "dog-dirty and loaded for bear".  heh

In case you forgot the goal, get ghost2 box, and red part2 femur... to go somewhat INSIDE-OF green spine/pelvis part1.  Ideally, turn off ALL collisions for green part1.  Later, we'll worry about turning-on butt collisions, again.  (for Rock 'em Sock 'em Street Fighter 3D - Kickin' Butt & Takin' Names)  FUN!  We'll know how to dis-locate a hip joint... programmatically.  Cooooool. 

PS: Be sure to click-around on the 6 clickable areas of quasar #3 (the biggest widget).  It is nicely active.

[Wingnut]

Hi again.  Everyone sick of reading this crap?  (No Wingnut, we're not reading it AT ALL.)  I don't blame ya. 

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

Ok, here is the first of the "modded" Oimo stuff.  The BJS PhysicsImpostor class has been brought aboard... and has been modded to include collidesWith and belongsTo params. 

The first modded area is lines 126-127 of the impostor.  Essentially, I copied the format from mass (line 122).  All the 0 values (seen in the mass line 122) have been changed to 0x00 (for belongsTo and collidesWith), but I'm not sure if that is correct.   Lines 805 and 807 of Oimo worldClass...  states " The bits of the collision groups".  

Oimo's shapeConfig shows that belongsTo is an integer, and collidesWith is an 8-bit hex value.  Strange.  Not sure why they would be different data types, and not sure if they are interchangeable.  I think they are.  Maybe either 0-255 integer, or hex, is allowed.  Help/info welcome, as always.

Note:  In PG lines 954-961, we see talk (from the coders of our Oimo plugin) about Oimo density == mass.  In the Oimo ShapeConfig class line 23, we see it happening there.  No mention of 'mass' is seen in the Oimo shapeConfig class.  Just 'density'.  Interesting!  Anyway, moving onward...

Onto the Oimo plugin - the first area of mods is lines 181-201, where getters and setters are created.  Proof-readers welcome, as always.

Still on the plugin, we get to lines 718/719 where the two new parameters are harvested from the 'body config', which is used for impostor constructing.

Then, on to lines 974-986, for the plugin's 'wrappers' for the impostor getters and setters.  Again, proof-read at-will, and please report Wingy mistakes.

Then... our code lines 1191/1192... where green part1 belongsTo and collidesWith are both set to group 0.

Lastly, line 1204, where red part2 is set to group 1, and the same happens to ghost2 in line 1310 - set to group 1.

Quite similar to BJS LayerMasks, these belongsTo and collidesWith 'bits' allows up-to 255 discrete collision 'groups' (layers).  We can choose which shapes belong-to which groups, and then choose which groups collide-with which groups.  Powerful and handy. 

It is likely that these two parameters were not included in earlier versions of Oimo plugin and PhysicsImpostor class, because it was an advanced feature that wouldn't be used very often, which is true.  In this project, we are diving deeper into Oimo than usual.  AND... our mods to PhysicsImpostor class... MAY (likely) make it incompatible with ALL OTHER physics engines that operate under the BJS umbrella.  To permanently honor these two new parameters,  it is likely we would need a special for-Oimo-only impostor class.  That's quite possible/plausible for our physics phuture [sic]. 

Oimo has shown to be a versatile, fast, and stalwart physics engine.  The more I investigate it, the more I love it.  I hope we don't 'blow it off', as a community, in pursuit-of 'the next latest/greatest thing'.  Sometimes, it seems that we chase new stuff so hard/fast, that we fail to realize what we already have.

Anyway, the basic steps for activating Oimo collidesWith and belongsTo are on-board in this playground, and are (perhaps) ready for crazy experiments.  Modified physicsImpostor and Oimo plugin classes are here, and ALMOST ready-to-go.  The mods are not working properly, unfortunately... so, more work/tests ahead.  Help and experimenters welcome, as always.  Party on!

Extra Credit:  If anyone has figured-out HOW to make my GUI rectangles... stay well-positioned, no matter the screen size... I'd love to hear about it.  Right now, when I open my JS console, which is docked to the bottom of the browser window... the GUI rects are too low and partially obscured by the dev tools area.  Perhaps I need to take canvas height into consideration... for every rect.linkOffsetY (perhaps in line 1917 where a base offsetY is set).  Meantime, feel free to reduce 1917 value to around 300 when browser dev tools is open... but that screws-up all the line endings and targets.  Possibly, those ALSO need a scalable baseY.  Currently, they are 'hard-coded values'... such as lines 1945 and 1956.

Update:  SUCCESS!!  https://www.babylonjs-playground.com/#1ND6TH#114  Check out line 1192.  Setting that to 0xFF or 0x00 doesn't change anything.  But when set to 0xFE (group 254)... everything starts working.  Ghost2 and part2 are allowed to overlap part1 (although somewhat violently, yet).  Still... SUCCESS, after undertaking a far-bigger-than-wingnut sub-project!  Green part1 has ended its contact collisions.  CYA!   We have activated Oimo belongsTo and collidesWith, at least somewhat!  YAY!  (Wingy dances-around like an idiot.)  PARTY!!! 

MUCH more testing ahead, but perhaps... we can start talking PR.  Any TypeScript volunteers within earshot?  No hurry.  We also need to fig a way to make this "special" Babylon.PhysicsImpostor... compatible with the other physics engines used by BabylonJS.  They all use the same impostor class (until now).

[Wingnut]

Hi gang.  Yet another update, but I'm on vacation from physics, and working on GUI.

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

 

[Arte]

@Wingnut 

Emergency stop button is missing.! 

Arte

[Wingnut]

Another update:  https://www.babylonjs-playground.com/#1ND6TH#198

About the new Babylon.GUI.Control.meshCenterOffsetY ...Wingnut-invented property...

THERE IT IS... lines 1194-1198... used on the bottom/7th target circle/line-ending.  Notice I have disabled linkWithMesh and linkTargetOffsets for target7 and line7.  So, target7 and line7 should be positioned... nowhere... or at 0,0.  But they are not.  They are about 75% distance above part2.center... just where I want it, and without creating an extra mesh (like target1/line1 did).  No need to move any mesh origins/pivots, either.  Yay!

Yep, a little renderLoop wedge... lines 1195-1198, using the NICE control.moveToVector3() function... we can tell target7 and line7 to offsetY 3 units upward from part2 center.  This is exactly what I wanted.  Y-offset set via mesh-units, not pixels.  Works great!   Resize, tilt, mousewheel, no matter what... target7/line7 track the top of part2... perfectly. 

We essentially built our own linkWithMesh system (in that little renderLoop wedgy).  Fun!  GUI.Control.moveToVector3() is a powerhouse (esp for lines and their targets)!

[JackFalcon]

IDEA: To isolate "springy bug" ...

- find how to //DETECT, when it goes into (spin) error state, etc. ~When detected, can be corrected. 

If you can set a break-point, at the point of error - then reset by stepping-through. : )

Tough to find, often simple to solve and understand. //TODO: Name, ...Rename variables....

Fine-tune animations in debugger... watch the numbrs dance past ... 

...when you find the one that falls over. Then the physics reasoning become clear why. Oh!

It's weird. Hope that gives you new things to try. Happy new year... 

~ tough-physics-animation-detection-traps-for-fine-tuning_methodology fyi... lol...

idk, rock-n-roll, peace : )

[Wingnut]

*nod*  Good ideas.  This issue is an initialization problem, I think.  Lines 1358-1360... the physicsImpostor.addJoint() lines.

I think I might learn much... if I learn to add the joints... using Oimo 'native' methods. 

Right now, I suspect that SOMETHING within/near the Babylon.PhysicsImpostor.addJoint() func... is screwing-up... WHEN one of the shapes it is using... is < size 1, 1, 1.  That means the box impostor/body will be < 1 x 1 x 1, as well.

What really throws "the curveball"... is that joint1c is working properly, with ZERO spring and ZERO space to be springy (proper functionality per params set).  Why does THAT one work, and the other two... suck.   

Joint1c has ONE characteristic that is different from the other two joints.  Its body2/shape2 (red part2) is substantially bigger-sized that its body1/shape1 (ghost2).

Conversely... for joint1a, body1 is much larger than body2, and for joint1b, body1 and body2 are identical-sized.  *shrug* 

In other words, joint1c is the only joint... that DOESN'T have a .25, .25, .25 -sized body2.   (gSize line 1274)

All in all, I don't think hinge joints should EVER be springy... in the way that this scene is showing.  Goofy.  I need a shot. 

[Wingnut]

Ok, back to the GUI fun.

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

Here, I am trying to install control.linkMeshLocalOffsetX and control.linkMeshLocalOffsetY.  They are added-by Wingnut properties... to TRY to allow linkedMesh to have a target other than its origin.

In our tests, we want target7 and line7 to link-to the upper portion of red PART2 (without using pixel-based linkOffsetX/Y).  We want to raise the target point... in worldSpace units/meters, not in pixels.

So... at the bottom of the code... lines 2319-2321... links target7 to part2, and adds two new properties.  Needless to say, we want to attach-to part2... at a position that is 3 units above its origin/center.

At lines 2334-2336... we do the sae to line7. We link line7 to part2, and add those two new properties.  We want to attach-to part2... at a position that is 3 units above its origin/center.

Ok, lets go to the TOP of the code... lines 3-52.  Yep, I "hijacked" BABYLON.GUI.AdvancedDynamicTexture.prototype._checkUpdate() into the playground... and I'm going hacking.

Notice lines 29-31.  (Be careful.  Enabling line 29 bogs Firefox to a stand-still.)  But feel free to enable lines 30 & 31.  In theory, those two line SHOULD "add" the values of those two Wingnut-added properties (linkedMeshLocalOffsetX & linkedMeshLocalOffsetY) ... to the position of the controls (to the position of target7 and line7, in my test-case).  So let's turn-on lines 30/31!  Put on your safety helmet!

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

Aw shucks.  With lines 30/31 active, target7 and line7 are aiming toward the moon, and part2 refuses to render unless viewed from underneath.  Weird. 

I thought SURE we would have success.  We ALMOST made a mod/feature addition for GUI advancedDynamicTextures... but nooooo.  Fail.

I could have been somebody!  heh

I'm close, though.  I can smell success... it's nearby.     Control.linkMeshLocalOffsetX/Y might not be used very often, so perhaps they are "inini".  (infeasible'n'implausible'n'impractical).

[JohnK]

Hi Wingy, is it possible to produce a much simplified PG with just one set of components to attempt what you are trying for, eg no physics and one mesh with one linked control plus of course all the code you need for linkMeshLocalOffset?

[Wingnut]

  That's really difficult, actually.  That's why I give all the pertinent line numbers.

But yeah, we're pretty deep in the muck, aren't we?  *nod*.  And, two subjects running at once... even MORE fun.

Okay, here we go...  https://www.babylonjs-playground.com/#1ND6TH#130

Oh crap, I found a problem.  In lines 176 & 191... I use a very small offset.  See target7 and line7 CONTINUOUSLY rising?  Now I know what I did wrong.  After adding the offsets, I don't reset the offset values to null.   BABYLON.GUI.AdvancedDynamicTexture.prototype._checkUpdate is CONSTANTLY running, so it is REPEATEDLY adding the offsets in lines 32-34.

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

There we go.  THAT's... perfect.  Target7 and line7 are linked to the red mesh, but NOT at mesh center.  Yet we didn't use any pixel-based offsetting (lines 189-190, and 204-205).  SO, we can mousewheel in/out, tilt camera, slide the PG divider, open/close browser dev tools, and the target stays accurate.  Had we used pixel-based offsetting, camera tilting and mousewheeling would lose target tracking.

Lines 30-43... mis-indented on-purpose... those make it work.  Bad coding, probably.  Think it's a worthy permanent mod?  I like it... but who knows how it will work with right-handed coordinates mode and other drastic things?  Scary.  All core mods... scare me.  Too big... could affect too many people... if I screwed-up by not considering the FRR (far-reaching ramifications). 

On the 129 playground (the perfect-working PG)... notice line 185 and 200 only use a 1.5 offset.  Target7 and line7 are actually raised 3 units above mesh center.  Interesting.  I wouldn't mind fixing that... before any PR's might happen.

So, John... you have found my problem... just by telling me to simplify.  You're a genius!  Thank you!  Nice spurring.    Can you do anything with this user issue, by chance?  (thx)

I wouldn't mind hearing people's opinion... about making this a permanent feature. 

Notice that I added Z offset, too.  There's no reason that a "where-upon-the-linkedMesh-target"... can't be offset in the z-direction, also.  Naturally, the rendering of the target/line CONTROL... would still be at the depth of the ADT.  Here is a version with a negative Z offset... working fine.  This allows us to place controls... on the SURFACE of a mesh, too (even when the ADT is full-screen).  Cool.  But then again, MULTIPLE ADT's of BOTH types (mesh-texture or full-screen), all in the same scene... is allowed and easy.

Also... I need to carefully inspect AdvancedDynamicTexture and GUI.Control... to make sure that Deltakosh hasn't ALREADY ADDED this feature, somewhere else, somehow.  This feature might already exist... just a bit undocumented and hiding in a closet, nearby.    Thanks again.  Suggestions and code-tightenings and other ideas... very welcomed.

[Wingnut]

Whelp, here we are again.  I decided to "bail" on the permanent mods to advancedDynamicTexture._checkUpdate().

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

See lines 2185-2206.  That little renderLoop allows me to remove .linkedWithMesh from the controls called... target1, line1, target7 and line7  (the top and bottom lines and targets).

They are staying well-targeted thru camera tilts and mouse-wheels, so, good enough.  No more talk of framework mods, thank goodness.    (except BJS physicsImpostor additions of belongsTo and collidesWith)

As far as modding ADT.checukUpdate()... adding used-once code to ADT.checkUpdate(), and then having 3 if/thens adding bog to a continuously-running func... is stupid.

So, I can use this renderLoop to force "special targeting" for my special needs ONLY.  No need to load-down everyone's speeds, for MY special-needs purpose.

In the above playground, there are really only two teal-colored targets that are still being messed up by cam tilts and zooms... joint 1a (line2/target2) and joint 1b (line4/target4).

I'll try removing the .linkedWithMesh from target2, line2, target4, line4, and adding those controls to the renderLoop of unLinked controls (line 2173)...

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

Yeah, now the two teal-color circles above and below the little pink box... track nicely, no matter cam tilt or zoom.

Man, what a tangent onto GUI boulevard!  heh

Playing with the GUI was SUPPOSED TO BE my vacation from the physics stress.  Instead, it was almost equally stressful.  But, I needed my GUI targets working perfectly... because we will need to do MUCH cam tilting and zooming of these physics scenes, in the future.

As for fat code... I once tried to put pulsars and quasars into an external file.  https://github.com/Wingnutt/misc/blob/master/quasars_pulsars.js

It didn't work, because... I'm incompetent.    Everything fell out of scope, after the <script> include.  Getting pulsars and quasars (their creation code) OUT OF this code... will help. I LOVE using them, but I don't love carrying-along the code to create them... WITHIN the scene.  Babylon.PhysicsTools... yay! 

Then get the Oimo plugin and custom PhysicsImpostor removed... and then... the code might be tolerable.  But even then, if we build a full ragdoll... we're lookin' at a PILE of joints and impostors.  I think human shoulders are ALSO 3-axes, angle-limited joints... just like the hip.  Same for the neck.  Elbows are 2-axes, and knees, wrists, and ankles are 1-axis, I believe.  We might need ANOTHER 3-axes angle-limited joint(stack)... where the spine meets the pelvis.  (my green part1 mesh should ACTUALLY be labeled 'pelvis')

I needed the GUI to act exactly correct... to show where invisible joints are located (and survive cam tilts and zooms).  But wouldn't it be nice... if we could build a GUI layer... that AUTOMATICALLY labels all the joints and impostors in a scene?  THAT... would rock.  Probably hard to do, because joints really have no .position.  The GUI targets for my joints... are forced positions.  There is no joint.position for me to query from a joint object.

Anyway, movin' on, back to finding the reason for the bouncing.    I think this type of physics scene... is the start of many similar.  I'm pursuing some serious physics workshops... in our future.  Visualization of physics "stuff"... is very important.  Teaching joints, springs, and motors... is no small task.  Still, if BJS has THE BEST joints, springs, and motors (playground-based) tutorials, then we win (our users win).  Folks will come to BJS because they can learn it ALL, here. 

"ALL" would be easier to accomplish... if we would quit adding more/new physics engines for a year or two.    heh

[Wingnut]

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

The renderLoop 2167-2218... now does 'custom target positioning' for EVERY target/line EXCEPT ghost1/2.  (those two targets need no offsetting.  Targets at mesh center - good.)

I'm STILL thinking about ... maybe GUI.Control.linkedMeshOffset(vector3()). 

Piss on it, I'm going to ping @Deltakosh and ask his opinion, and see if he has ideas on how to install it in core GUI.

Deltakosh, this property... would be the worldspace offset... in meters/meshUnits... from a .linkedMesh center/origin.  Understand?

Currently, control.linkOffsetX/Y are in pixels or similar.  I need a linkedMesh offset... in meters.  Can this be easily done?  Bad idea?  Thoughts?

Why?:  When using current pixel-based Control.linkOffsetX/Y values, cam tilting and cam zooming... will make the target go off-track.  (Do extreme camera pitch/tilt and cam zoom on THIS PG to see it.)

In PG #129, lines 32-43 work fine, but I think that is sloppy, and will slightly bog-down BABYLON.GUI.AdvancedDynamicTexture.prototype._checkUpdate() func.

I think there is a BETTER place to install it... within GUI.AdvancedDynamicTexture (if the mod is approved at all).

Thoughts from ANYONE... welcome.

[GameMonetize]

Hello you would like to add a linkOffset but in world unit? In this case why not adding a hidden child to your mesh and offset it using the vector3 you want and then attach your GUI label to this dummy object?

[Wingnut]

Thx for reply, @Deltakosh.  You understand perfectly.

Using hidden mesh, there will be too many extra mesh in an already-messy work area.

I have only "illustrated" ONE human hip joint.  So far, 5 hidden mesh required.

Ragdoll = 5 more hidden mesh for neck, 5 more for other hip, 10 more for shoulders, 4 for elbows, 2 for wrists, 2 for knees, 2 for ankles. 

It's all your decision.  I see no place where position is initialized.  I think _checkUpdate() does all positioning, even first time.

I can use the custom BABYLON.GUI.AdvancedDynamicTexture.prototype._checkUpdate from PG #129

It will work fine, I think.  I could tighten its code though.    I like .linkedMeshOffset(vector3()) property name/type... best. 

I'm going to try to activate that property... inside my custom _checkUpdate().  I need to find the FASTEST code to add linkedMeshOffset... to position.    Maybe v3.addInPlace.  I think that is fast.

Thanks for thinking about it, and commenting about it, DK.  I'll "roll-with" whatever you think is good/right, core-wise.

Multiple options available... for this project, maybe.

[Wingnut]

Erf... sigh.

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

Line 4 - added BABYLON.GUI.Control.prototype.linkedMeshOffset = BABYLON.Vector3.Zero();

Lines 34-35:

position.addInPlace(control.linkedMeshOffset.clone().scaleInPlace(.5));
control.linkedMeshOffset = BABYLON.Vector3.Zero();

Label for part1... working great... offset from center -3 Y-units (target1/line1 positioned on bottom part of green mesh - perfect)

BUT, the next 3 labels (6 controls) ALL use ghost1 as their .linkWithMesh.  See lines 2041, 2051, 2078, 2087, 2114, and 2124.

Label 2 (target2/line2) is offset +2Y  (lines 2040 and 2050)

Label 4 (target4/line4) is offset -2Y  (lines 2115 and 2125)

Label3 is not offset at all (normal).  It should land EXACTLY upon the tiny ghost1 box.  (it does, but...)

Now change the '2' in lines 2040 and 2050... to '3'.  We are moving line2 and target2... upward ONE unit.  Run.

ALL THREE lines/targets (6 total controls) moved upward one unit.   https://www.babylonjs-playground.com/#1ND6TH#145

It is AS IF... BJS is "summing" the positions... for ALL SIX controls that have .linkWithMesh = 'ghost1'.  Go fig.

Darnit.  Cached position?  BJS thinks it has a ghost1.position that works for all 6 controls?  So it uses the same position for all 6?

I think maybe my line 34 is rotten (the top line in the black box... above).  *sigh*   Yet it still works fine for target1 and line1.  clone() probably not-needed.

I had high-hopes for using this method of modding ADT._checkUpdate().  But I've got some kind of 'value accumulating' in the position variable at line 34.

Any ideas, anyone?  Yeah, I know, the scene-code is fat and ugly again.  (grumble grumble)