continued_at_new_forum The Wingnut Chronicles

[JCPalmer]

Let's maybe crash this topic!! If the # of views is 16 bit, then we are within reach.  To be honest there is likely much good information here, but who the hell could find it.

[Wingnut]

Whatever ya need, but forum search will find it.  Dump-to-html doc b4 axing... would be nice.  Still searchable, then.   Probably need to run-it-past DK when he returns from vacation.

Mostly, I care about my previous post... Q&A questions going long-un-answered.  That's more important than the length of this thread, at this time, imho.

Let's see if @rich will visit and give us some pointers.  I STRONGLY-prefer dump-to-webpage before killing.  Force-set views to 0, at will, Rich/whomever.

[JCPalmer]

Probability is actually kind of low. This forum software is probably database backed.  The column would have to be UNSIGNED SMALLINT.  People usually just say INTEGER.

[Wingnut]

*nod*  thx.  Good catch... views nearing 65536.

Time for another goofy PG demo?  Ok... here.   

Raanan's cloth demo used "particleImpostors", and they don't work against the meshImpostor hemisphere bowl.  So I changed them to sphereImposters, and I set the resolution of each "point-shape" very low.  AND, I made the points fatter. 

This runs slow as molasses on my machine, but I probably have a big fat bog-log in the code somewhere. 

Lines 107-112 is where the points get their physics.  If the point is a yellow "stead", it gets no mass.  It is a hang-point.  Otherwise, it gets mass.  Set some mass in line 109, and the cloth will drop to bottom of bowl.  Set restitution to 1.3 in lines 109 and 112, and things can get violent.    So much so, that portions of the cloth are blasted-thru the sides of the bowl.  Fun!

When using 2.5 mode, cloth POSITION is off-centered... in a corner quadrant, which is EXACTLY the problem I see with the heightMapImpostor (another thread).  HeightmapImpostor works in one quadrant of the terrain.  Other 3 quadrants are fall-thru.  I smell boundingBox.extendSize (and .center) issues, I do... in 3.0.

Hey, I wasn't playing with this PG, people.  I was working a forum customer service ticket.  No, really, I was.  I was hauling a big truckload of research to an issue, and this PG jumped-out in-front-of my truck.  I had to lock-up the air brakes.  Had to take a detour.  Really.  I would never lie. 

How about a trampoline or tennis racket mesh?  fun!

[Wingnut]

[branched topic] 

rant deleted - but everyone...PLEASE help us with forum Q&A as much as you can.  Provide a link to playgrounds/searches that apply to the issue.  Teach and care.  thx.

 

[Wingnut]

There's some fancy new PG loading screens and logo graphics in Babylonia, eh?  Looks pretty nice!  Congrats to whomever... well done.

[GameMonetize]

Yep I wanted a new logo to celebrate v3.0

And a lot of people were complaining about PG loading times..so now they have a fancy logo to watch while waiting for editor to load

[Wingnut]

Tiz very nice. I like it.

On another subject, are we seeing a general "push" to move some BJS tasks... to GPU/post-processing?  Perf thing?

I was thinking about... when a BJS operation/task moves to post-processing or GPU-based, it loses user-hack-ability.  It moves out-of-reach to non-shader people.

I'm not sure what ramifications this will have... upon "How easy is BJS?"

Does anyone understand this?  Want to talk about it?

Does anyone think... that SOMEDAY, we could make "hijacking something into the playground"... be automated? 

IF that "brought-into-playground" func/task was very dependent upon a shader/post-process to do its job... could CYOS/shaderEditor buttons become available in playground, so a user can SEE (and someday, edit/hack) the shaders used in this task?

All in all, when a new user begins exploring BJS code... trying to learn how something works, I think many of them will stop exploring when they hit the accompanying shader(s).  TS is readable, even for noobs.  But shader code... that is a wall that blocks the explorer... it seems.  (it blocks me) 

If anyone has any ideas about how avoid that wall... that would be great.  I couldn't think of many ideas.

But, if we ARE trying to move more and more tasks... from CPU to GPU, then we are losing/changing the CPU code... and building those walls.  I worry about those walls... from a noob-teacher perspective.  Thoughts, anyone?

[GameMonetize]

If I push something to the GPU be assured that:

- either it will be feature comparable to before

- etiher the CPU version will stay to let users have more control over it

[Vousk-prod.]

And don't forget the real purpose of a rendering engine: doing evil tasks behind the scene, for the sake of the user. A process pushed GPU side is, for most users, a garanty that it is optimised and do not require too much hard work to be used. That's valuable. Of course, it also means more difficult to understand and adapt if needed, but it is specific cases, not usual usage.

[meteoritool]

Yeah we need a shepherd, leading us to the wonderful world of shaders ! It took me time to even understand what a shader is, this word is, in my humble opinion, not self-explanatory at all !

One year ago, I didn't know anything about 3D and very little javascript ... but now I use blender, instances, shadows, loops, LOD, animations, I know what anisotropic filtering is, etc ... 
I have yet to master a lotta other stuff, but I DO hope that one day someone will write a comprehensive guide on how to write shaders !
Yeah, DOCS and classes library are very important, I relate to them all the time !

[JohnK]

On 23/06/2017 at 9:43 AM, meteoritool said:

I DO hope that one day someone will write a comprehensive guide on how to write shaders !

As a very much beginner to the world of shaders I did produce some tutorials on them, as much for me to refer back to as anything else.

The first is here http://babylonjsguide.github.io/advanced/Overview with links to one or two more here http://babylonjsguide.github.io/advanced.html (click on shaders button to see short list).Definitely not comprehensive but a start.

Deltakosh also has a decent shader tutorial at https://www.eternalcoding.com/?p=113

[Wingnut]

Thanks Guys... good comments and links.

Wingnut has been advancing the "Hey Bobsled Taxi" project a bit.

http://www.babylonjs-playground.com/#PBVEM#135

All physics-flown with keypress and applyImpulses. 

Hold-down-able hotkeys are...

SHIFTED  arrow/cursor keys = translate forward, backward, left, right.  Also works for arrow keys on numeric keypad  (2, 4, 6, 8)
SHIFTED  PageUp/PageDown = translate up, down.   Also works for numeric keypad + and -
CONTROL  arrow/cursor keys = rotate pitch-up, pitch-down, roll-left, roll-right.  Also works for arrow keys on numeric keypad  (2, 4, 6, 8)
CONTROL  PageUp/PageDown = rotate yaw-left, yaw-right.   Also works for numeric keypad + and -

SHIFTED-CONTROL  L = all stop.  Also works for numeric keypad 5.

Not much fun-flying to do, yet... but hey, it's working.  Hooray!  GUI and HUD coming soon (yeah right).    Party on!

Extra crap:  Right now, if you make an edit to the code, it won't RUN again... until after re-saving.  TypeError: e.physicsBody is null - babylon.js:35:11311  Not sure why that's happening.  Likely scope problems or onDispose issues.  I don't use "objects" very often, such-as Wingnut-created BABYLON.FlyerFrameController, so I get into scoping problems quite easily.  Still learning... trying to be more oopy, but not doing so well. 

A new BABYLON.FlyerFrameController is placed into bobsled.controller.  With the help of many jQuery keypress handlers, it uses its functions to fire applyImpulses against the white box in the center.  That white box is bobsled.handle, the master parent for all bobsled pieces, and the only mesh with a physicsImpostor.

Controller is also "ready" to activate 24 particle thrusters, and is essentially a 24-thruster cubical space satellite... with full maneuvering.  It might become re-usable someday!  I would be honored!  But it needs serious cleanup, and might be better if it used setLinearVelocity and setAngularVelocity... instead of using applyImpulses.  The code would be LOTS shorter, that's for sure.  We'll talk.

[Wingnut]

Hi gang.  Here's a fresh version of my physics-active canvas2d-based menu-o-buttons.  Nothing new... it just needed some minor repairs and I thought I would do a show'n'tell.  Currently, this is using OimoJS, our default physics engine.

Click a button, it should change its mesh color, and then cause the "buttons hanging by chains" to start swinging.  That is because a physics applyImpulse is "fired" when you click the physics active buttons.

It still has "issues".  The 8 needed physics joints are created in lines 340-436, and installed on the buttons in lines 441-453 (just after they are created).

I think there are problems with the springs on the joints.  I don't know much about springs, yet.  The buttons CAN... "roll-up" and entangle... if clicked repeatedly.  More mass helps, but it makes the swinging be SO SLOW.  erf.

And, button 2 and 3 seem inconsistent about changing their mesh color when clicked.  It doesn't ALWAYS work.  hmm.

Also... joints 4 and 8... connect button 3 to button 4 (the last button in the chain-o-buttons).  They look stiff, to me.  They do not appear to bend very well.  The joints between button 2 and 3... seem nicely flexible.  The joints between button 3 and 4... not so flexible.  I could use help discovering why.  Thx! 

I hope everyone is well and having a great summer.

[Pryme8]

On 5/26/2017 at 7:30 AM, Wingnut said:

Time for another goofy PG demo?  Ok... here.   

I have been wanting to see stuff like this for a while, got any other cloth simulations?

[Wingnut]

  No, I don't... but it is easy to modify into anything.  They're just joint-a-thons.    Joints quickly suck the life-force from CPU's.

I'm about to go fishing in my little pram-boat, but I have a challenge, should anyone need one.

I think I need a word-wrapper for Babylon.GUI text.  It needs to be a container... of course.  I don't need overflow/scrollbars... just a container HEIGHT auto-expander, and only downward.  I don't need the container to stay y-centered on screen. 

Extra credit - for expanding the bottom of a plane that the Babylon.GUI is mapped-onto (non-fullscreen advancedDynamicTexture).  Newline expander. 

2x credit - for forced-newline via secret embedded-in-text character.

4x credit - for per-word text color/font changes allowed.    Purrrrrty.

8x credit - for automatic re-wrap when container width is live-changed, dynamically.

Now, let's see, where did the Earth creators hide them muskies?  hmm.  I'm strictly catch'n'release and often smash the hook "barbs" with pliers, so, you know, kind to fish and all that.    But still, they need a good tug-o-war with Wingnut sometimes... keeps them strong.  I'm part of nature, too. 

[Raggar]

18 hours ago, Wingnut said:

Joints quickly suck the life-force from CPU's.

They certainly do. I did this constraint test a while ago:

https://www.babylonjs-playground.com/#15U9CT#48

Try picking different boxes to simulate a destructive wall. Not the way to do it if you need more than a small wall

[Wingnut]

Nice!

Calling all helpers:  I still have a problem with the flying bobsled... https://www.babylonjs-playground.com/#PBVEM#140

Same ol' control-arrows with control-pgUp/pgDown (for rotation),  AND shift-arrows with shift-pgUp/pgDown, (for translation)  AND shift-control-"L" (for all-stop).
   (tap them many times, or hold them down)

Problem is... this gets an error if RUN twice... in the playground app.  The second time it is run, I get a e.physicsBody is null error... upon using one of the above keypresses.

Help, please!

Perhaps it is scope-related.  bobsled is a plain-jane JS object, bobsled.handle is a master-parent box, and is the ONLY mesh with a physics impostor.

Why can't the darned playground just re-run the code?  Currently, I have to SAVE each playground edit, and then close the old scene, and reload the new save.

Any ideas, scope-help... welcome.  Again, keep in mind that bobsled.handle is the parent for all bobsled "parts" (nose, cockpit, tail, foils)... but bobsled itself is not a mesh-class object.  Do I need to add .dispose() funcs on my classes?  What the heck? 

Also, inside the jQuery keypress-handler funcs... bobsled.controller is reffed often.  That doesn't feel right, somehow.

Maybe these (hard-)refs to bobsled.controller... are a bad idea.

I struggle with... umm... "hard" references and "loose" references, etc.  I don't understand them well.  Thx for advice.

[Wingnut]

Ok, hi again, TWC followers.  I finally got the PG re-RUN physics error fixed on the bobsled/space taxi [pg #157].  Yay!  It needed better scene.onDispose operations.

I'm beginning work on space taxi physics landing gear [PG #3 / PG #4].  Nothing working, yet.  Trying a sliderJoint on each of 4 "legs"... but failing, so far (like car shock-absorber - inner cyl/outer cyl, spring-loaded).  I need to study physics engines quite a bit more.

What might LOOK cooler... is a "scissors" style landing leg/strut.  The one in this picture uses two spring-loaded hinge joints, but really, only one is needed.  The more joints, the slower the scene will run during landing/launch ops.  Landing is the important one... because... you know... more stuff goes wrong during landings.  Big fat passengers all sitting on one side of the space taxi, ground winds, trees/obstructions, and pilot drinking. 

So, there's a trade-off.  It's fun to watch springy landing gear moving, its springs sometimes making the craft do unwanted restitutions/bounces.  But, joints eat CPU... so... ya know... we might need "diet landing gear", when we leave dream'n'drool land.  heh

Needless to say, ANYONE feel free to donate a physics-active landing gear leg (with at least one spring-loaded joint of some kind).  I would PREFER that these joints are mostly made-with BJS physics plugin calls, and to NOT ever create a joint... with a native call to a physics engine (native params-setting = okay). 

For those who don't know what a native call is, it is using funcs that are built-into the physics engine, and are "going around" similar calls on the BJS physics plugin.

Instead, I would like to test ALL joint calls on our Cannon and Oimo plugins.  Currently supported joints are shown in a table, there.  And now I see why my Cannon slider joint is not working in PG #4 above.  Cannon doesn't HAVE a slider joint, apparently.    (see hyphens in that table of joints)

See the place in the doc, there... " A further explanation of the joints (including illustrations) is soon to be written."

Well, in my opinion, Raanan finished that "further explanation" already... with his Physics Car Tutorial.  It is a NICE tutorial... with lots of talk about joints.  We have everything we need... to make some spring-loaded landing gear struts. Feel free to advance/adjust the starter landing gear playgrounds, above.  I would like 4 landing struts on the space taxi, each with independent suspension.  And, if anyone DOES start creating/testing landing struts for the taxi, I say keep them each 3 springy-joints, or less.  One joint is preferred.  

If wheels are used at bottom of gear, they should "castor" (probably difficult to do).  The space taxi can fly in any direction and can land while moving backwards or sideways.  This is why castored wheels, or pads that can slide in any direction, would be preferred (for "feet"). 

Lots of "motion" is preferred, too.  A simple shock-absorber-like (piston) spring-joint... is rather boring.  But a long-throw "scissoring" landing gear, similar to an engine hoist or inverted floor-jack (for auto servicing)... is much cooler.  Bug legs!  hehe.  These type have an "arm" that moves up and down.  Here's a combo scissors/piston, but no spring-loading is active on the scissors hinge joint.  The piston does all the spring-ing, I suspect.

Just thinkin', dreamin', researchin'... about joints (landing gear).    Comments/ideas/submits welcome, always.  (thx)

[Wingnut]

Landing Struts... update:  PG#7 - Hinge joints are active. (yay!)  I need to limit their rotational range, and I can't get min/max or limit to work... surely a Wingnut mistake.  I hope hingeJoints ALLOW "springs" (such as doors with auto-closing features - via spring-loaded hinges).  Perhaps not, though.

Very little progress, eh?  *nod*  But I guess that's the purpose of these chronicles, right?  See just how long it takes an old geezer to create some spring or motor-controlled hinged landing gear.  At this rate, we're looking-at about 2 years.   (I suspect Wingnut is doing too much fishing for pike, and not enough fishing for knowledge.)

The main thing... is that The Wingnut Chronicles provide the intriguing weekly stories and entertainment that make our readers keep coming back for more.  (cack/gag).  heh.

[Wingnut]

Hi again girls.  I have been thinking about my need for spring-loaded, angle-constrained hinge joints (for my landing gear hinge joints).

So far, I can find no way to angle-constrain a Cannon hinge joint (with min, max, limit) nor any way to add a coil spring around the hinge pivot.

What we seek... is landing gear "flex" and bounce... on each of the 4 landing struts.  (a 2-hinge version, nice)

Perhaps... I will need to use a motor on the hinge, and "fake" a coil spring around the pivot.  That seems HARD. 

The CannonJS hinge joint seems VERY limited.  Not many toys on it.

See the setMotorMaxForce (also motor speed)?  *nod*  Motor direction is nearby, too.

*sigh*  Fake springy-hinge... via forward/reverse motor, with ease-in, ease-out, code logic always working (sine waving) its way back to neutral position.  Weird.

I read a bit about coneTwist joints/constraints, and how they are used for skeleton/armature joints between bones (on human-ish skeletons/raggies).  And Raggar recently did that syncImpostorToBone thing.  hmm.  Should my landing gear be bones?  I'm thinkin' "yeah".  Each landing strut is very similar to a ragdoll leg, eh?  Thoughts?

My dog ran under the fridge again.    Party on!

[Raggar]

Unfortunately, I can't take credit for syncImpostorToBone

[NasimiAsl]

@Wingnut i like see you dog pic plz

 

[Wingnut]

Latest landing gear demo.  http://playground.babylonjs.com/#RLKVFF#9

Got a joint motor turned-on!  Holy crap!  Fun!!!

[Wingnut]

Hi gang!  Even more fun-with-joints 

http://playground.babylonjs.com/#RLKVFF#15

Concentrating on joint1 in lower left corner of box.

Lines 394/395 - I'm drilling all the way down to joint1 rotationalEquation1 (and 2) .maxAngle, trying to put some rotational limits on my motor-ready hinge joint.  But it really loves to spin, spin, spin. 

Objective is to allow pink parts of landing gear... to change angle SOMEWHAT when they impact the ground... and the weight of the craft settles-down onto them.

Joints don't seem to have a fixedRotation setting.  Besides, I don't really want a fixedRotation.  I am seeking a limited rotation... preferably with a minimum and maximum angle.  hmm.

Those 2 code-lines cause an odd pivot-axis angle adjustment.  Disable both code lines, RUN again, and compare, if interested.

Still learning... experimenting... having good fun.  Anyone... join-in, if you wish.  Make some playground edits/saves and show us your discoveries.  thx.

update:  Version 18 - Line 331 activates a "lockJoint".  When I first saw its name, I thought "How boring!".  But, I decided to activate one.  Click on the screen to see its wonderful springy-ness!  It is exactly the kind of "bouncing" I was looking-for!  Sinusoidal oscillation around a single axis, with a "centered" or "idle" position!  COOL!  YAY!

As for WHY it is strangely positioned, I dunno.  How to adjust?  Not sure, yet.  I did some unsuccessful experimenting in lines 319/320.  *shrug* 

Oh what a nice bouncy discovery... the motor-enabled lockJoint!  (lockJoints don't have motors, so its motor-enabled wrapper is not needed.)   

Fun!  If I can get them positioned and angled nicely, it should make-for some good springy landing gear.

PS: If you "time" your screen clicks well, and you can make the lockJoint switch sides/axes.