continued_at_new_forum The Wingnut Chronicles

[jerome]

 

If you want a more rapid result, change the number of max iteration at the line 33

http://www.babylonjs-playground.com/#24BDIX#1

 

http://www.babylonjs-playground.com/#24BDIX#2

[jerome]

@Raanan : forget all I said about the Chrome bug, now it works ...

[RaananW]

@Jerome, I guess this was a cache problem :-)

 

Your fractals are awesome! Physics with fractals - http://www.babylonjs-playground.com/#24BDIX#3 

Still a small problem with the surface above (it is simply being ignored...) no idea why, I need to debug this. But it's getting cooler and cooler :-)

[GameMonetize]

Can't agree more!

[Wingnut]

Ok, everyone is playing with balls and bowls... I'm jumping-in, too.

http://playground.babylonjs.com/#28XFHQ#3

My first dynamically-generated bowling image!  YAY!  Too fun!

Happy Halloween, for those who celebrate it! 

(I tried for the "eyeballs in the blood soup" effect, but I wasn't happy with the internet-found eyeball images.  So, I went with brick balls.)    Party on!

[jerome]

Casino roulette soon ?

[Wingnut]

  Works for me!

 

In my demo, I just stole a simple piece of canvas-drawing code from somewhere on the net, and I think I have a fill happening 60 times unnecessarily. 

 

What we really want is ALL strokes... hundreds of rings... to make the bowl.  And we need a Bezier easing for the gray-scale CHANGE-per-ring.  As we stroke ring after ring after ring... we ease-out of the black and ease-into the white... and we can adjust the speed and location of those easings.  Thus, like the potter's hands, we can (gray-scale-) contour the shape of the bowl or bell.

 

Yum!!! 

 

If someone wants to "run with" our demo... in that direction, that would be ok by me. 

[RaananW]

How many clicks do you need to put all of the balls in the pockets? http://playground.babylonjs.com/#DLBW7#7 first mini golf for BJS :-)

[Wingnut]

Fun!

 

I love the combo shots that use the bowl arc as part of the equation.  Good thing the balls aren't leaving roll-tracks in the fingerpaint. 

 

The little rigidBody cars are coming next, I suppose.  Put a bulldozer blade on the front... and 10000 little lo-rez spheres to clean-up after the landslide.  Bulldoze all that "dirt" into the ravine.  Hurry up, the boss is waiting. 

[Wingnut]

Man, I'm glad we have heightMap physics.  Too fun!  Thanks again, Raanan and contributors.

Well, it has been a while since I released a demented playground demo, so here we go!  Some control-mousewheel font-sizing might be necessary to "square things up".

What the hell is it? 

Well, it is somewhat like a previous physics joint test I made... but oh so different.

The story?  Well, to be brief, Oimo doesn't have an API doc like Cannon does.  (Not that I have yet found, anyway.)

But Oimo.js is nice clean JS code... no compression or obfuscation.  So, that's where I went to learn about Oimo.  (other places, too)

One of the issues when working with physics for BJS... is finding all the pieces.  There's physics code on AbstractMesh, and on Scene, and on BABYLON.PhysicsEngine... and on BABYLON.OimoJSPlugin, and on the OIMO object and all its support classes.  When the tools are spread-out like this, it makes learning the system... more difficult.  I also found this to be true with Animations, and that is why I made the "Everything about Animation Doc".

But this time, regarding physics... I decided to try a dynamic (generated) "Everything about BJS Physics".  If you look at the JS console on that PG demo, you will see my "gleaning" of physics properties and methods from Scene and AbstractMesh, as well as doing property name dumping for the BABYLON.PhysicsEngine and both physics plugins (Cannon and Oimo).  The object sniffers are between lines 372 and 432... and some of it uses the new array.filter feature.

And, you also see the brutal hacking of the playground... to add a dynamic table.  The objective was to attach a physics help table... to the bottom of a playground... essentially the first step in a "physics playground". 

But then I thought about WHY ATTACH TO PG when it is so easy to use a separate window for a help document?  (Because I have done some "live editing" of physics scenes using Firefox's built-in object inspector, and it was cool and fun, and I wanted to do the same... allow live-poking of physics props... by typing into table cells.  It might still happen.)

Meanwhile, that dynamic table of physics help... has been set-aside.  But, all the code is still there... and the scene.onDispose function recovers (sort of) from the HTML hacking (check by selecting a pre-built scene from the PG scene list and see if any of my old html is still on-screen.  It isn't, tested in IE or FF.) 

So, to be brief... the code and technique is here to hook some html to the bottom of any playground, and recover from it.  Its nicely steal-able for those who would like to have that code in their toolbox.

Ok, all that dynamic table and PG hacking aside, this demo does some strange things.  It makes 3 physics links... but NOT using the easy AbstractMesh.setPhysicsLinkWith().  I decided to do it "the hard way". 

The first physics link... lines 493-569, the second link... lines 570-643, and the third... lines 644-717.  Fascinating, huh?  I think so. Full power link-making, but I THINK that if you include the final "options" parameter/arg to our mesh.setPhysicsLinkWith()... you can have that same power.

All three links... use type jointHinge... so the linked boxes will only swing on one axis.  There is a mouseclick applyImpulse active on the seg3 (violet) box.  Click anywhere to impulse that seg3 box.

All three links have a +90 to -90 degree rotation constraint (limiting motor).  Collisions between the boxes... is OFF... so as you swing the boxes, you will see the mesh overlap, but the 90-degree limits are working perfectly.

Annoyed with seeing that goofy table?   Remark-out line 434 and your troubles are gone. 

Yep, another half-baked, incomplete, playground mess... from your buddy Wingnut - future Joint Master.     I LOVE joints!  Have fun, party on!

[Wingnut]

http://playground.babylonjs.com/#1VITPM#1

Having more steam train fun!  Boy, don't use cylinders for pivots.  They gotta be rotated, and oimo hates initial rotations.  More on that later.  Best to use boxes, and then cover them up with cylinders later. 

What a messy playground.  Bad impulsing... but it works... for going faster (click fast). 

No brakes yet.    First working compound physics object for me... if it IS working.  Not sure.  What a mess... but it's pretty fun! 

AltRealty... are you listening?  We're gettin' physics-active train-sim ready, here!  Yum!  Got your steam-powered applyImpulse ready? 

Notice the slight wheel wobble?  Ain't that cool?  It's hard on the bearings, but I'm using Genuine OimoLube, so I think we're ok.  heh

[Wingnut]

Hi gang!  Here's another.  http://playground.babylonjs.com/#1VITPM#2

(Experiment with the flywheel mass in line 401 for fun.  Click to apply wheel impulse in one direction.)

Have I been camping this nipple long enough?

Oh wait... most of you probably don't know what "camping a nipple" is... but you can deduce it, I'm sure.

I finally got cylinders rotated properly to be good axles/studs!  Yay!  Cylinders are vertical in BJS, so to use them for a lateral axle/stud, you need to rotate them 90 degrees.

Well, Oimo just hates that, or maybe our Oimo plugin hates it... or something... but I fought MANY hours against this.  My problem was... I was trying to rotate the objects AFTER I set their physics state.  Well... come to find out... it is much better to do a QUATERNION rotate BEFORE you set physics state. 

And it might be important to know that creating a compound imposter sets the physics state on the PARTS of that compound... automatically.  It also registers (in .registeredMeshes) the FIRST mesh in the parts array... called the initialMesh.  But compoundImposters have no mesh.body... not even on the initialMesh.  Compound imposters is a local invention... by one of our hometown heroes.  Cooool!  So, Oimo knows nothing about compound imposters, and thus won't assign a rigidBody to such a thing.  It's ok, our plugin-based compound imposters work superbly, so we don't care WHAT Oimo (or Cannon) thinks. 

All that is not really important.  The wheel and the green stud... are a compound object.  Look at lines 399-406 (if you please, and sorry for all the playground/workbench mess).  Notice how I set wheel1 quaternion rotation, and THEN create the compound (with wheel1 as the initialMesh).  Quaternion rotate FIRST, set physics state after.  Works pretty good.

The same is true in lines 409 and 410.  Axle1 (the white wheel axle) is not a compound imposter, but still, set the quaternion rotate, then set the physics state.

I'm sure there are ways of setting rotations AFTER setPhysicsState.  I still have lots to learn... but I am celebrating getting my cylinders rotated... yay!  Party on!

[Wingnut]

And another... http://playground.babylonjs.com/#1VITPM#3

It is starting to look train-like, huh?  Click fast, start the wheels spinning.

For a LONG time, I fought with this.  I could NOT get the wheels to spin.  They kept stopping abruptly for no apparent reason, with connecting bar (conn1) on or off.  I could spin one wheel fine, OR the other wheel fine, but when I applied impulse to both... they would start doing the unexpected stopping again.

Then, I brought the sunken ground upward until it was nearly touching the bottom of the wheels, and then suddenly, I could NOT get even one wheel to spin!  What the hell?

THEN... I turned-on showBoundingBox on both wheels... and yep, the corners of the bounding box were hitting the ground.  So I dropped the ground again, and then applyImpulse to both wheels, and boom, there it was.  The corners of the bounding boxes on the wheels... were hitting each other during the spin attempt.  I had the wheels too close together!  hehe.   I moved them apart a bit more, and that fixed the wheel spin problem.  (dummy me)

As you might be able to tell, I have some unwanted friction (or wrenching) here.  The blue connecting rod (conn1) has a mass of 1. That should be enough weight to ensure that the wheels "settle" in a studs-down position.  Let this thing run for a minute, and you will see that the wheels do not settle with studs down.  There is some resistance somewhere... even though all my frictions are set low or off.  This "settling to a stop" should take a much longer time, too.

Lines 396-405 is a play area.  Try this for fun.  Disable line 396 and RUN again.  Now the right wheel (wheel 1 where applyImpulse is active)... is free from the connection and spins for a LONG time.  Wheel2 (the left one) has a light blue two-by-four hanging from it's stud, but it ALSO seems to be friction free and spins long.

So, one can deduce... that it is the connection (conn1) causing the unwanted friction.  (When the connecting bar is in place on both ends).

This could be caused by a few things.  Take a look at lines 56-70 if you please.  The +18 and -18 in that area show that the two wheels are 36 units apart.

The code for the two connector bar links... starts at line 253 with a variable declare of halfspread = 18.  That sounds reasonable, right?  The halfspread variable is used in lines 294 and 359... setting the LOCATION of the link on the wheel1/stud1 and wheel2/stud2 compound objects.  You see... with compound objects like these... stud1 and stud2 are not "official" physics items.  They are both "parts" of wheel1 and wheel2 compound objects... and therefore I cannot link anything to stud1 or stud2.  Instead I need to link to wheel1 and wheel2 compounds (you can consider those the "initialMesh" of the compounds)... and then I offset the link locations to the proper position of the green studs (stud1 and stud2).

There is one other place of concern.  Notice line 297 and 300.  I link wheel1 on a Y axis, but I link conn1 on a Z axis.  The same thing happens on the other conn1 link... lines 362 and 365.  I call these things "the twists".  I can remove the twists, and shape the connecting bar differently in its constructor options, and adjust the link positions to compensate, but the symptom remains the same.  Unwanted friction. 

Besides, I think the free swinging seen by disconnecting either end of the connector bar... proves that those links are smooth.  The friction only happens... when both ends of the connecting bar are attached.  This COULD indicate that I have a distance problem in the halfspread variable.  If the distance between the stud links is too large or small, there will be some physics fighting... which COULD cause the unwanted friction (via wrenching).  This almost HAS TO BE the problem... it seems.

But I think I have halfspread set correctly.  Increasing or decreasing it slight amounts... makes things worse.

I think I have it all correct, but I still have unexpected and unwanted friction when the connector is in place.  Go fig.  I THINK I also see some vibrations... when the demo speeds are spun-up a bit.  hmm.  And I still got some wheel wobble.  hmm.  I suppose I should learn what the options.spring setting does.  Maybe its causing wobble.  Or maybe the center of mass on compound objects... has an issue.  hmm.

If anyone wants to experiment and help me find the source of the unwanted friction/wrenching, that would be great!  If not, that's ok, too.  I have about 20,000 man-hours into this already... what's a few more?  hehe!  Party on!

[Wingnut]

http://playground.babylonjs.com/#1VITPM#4  yay!   Operating much better, now.  I needed to dis-allow rigid body object sleeping  (lines 112, 121, 125, 129, 132).

Essentially, I needed to set MAX FLUIDITY mode. 

AND... it helps to keep that light blue crossbar at mass: 5 or more.  It keeps the fly-wheeling action hopping. 

Ponderance:  I'm not sure yet, but MAYBE... options.spring... only works in-conjunction with options.motor and/or options.limit properties.  Still learning.  I'm seeing no signs that the wheel wobbling is caused by .spring property.  Doing adjustments to options.spring... I see no affect.  (the settings in the demo were pasted in from another project... they might not be activated correctly). 

So... I am still hanging onto my limp theory... that the wheel wobble is caused by not offsetting the center of mass on the compound objects.  The green studs are acting like wheel weights on a car... and making things wobble. 

https://github.com/BabylonJS/Babylon.js/blob/master/src/Physics/Plugins/babylon.oimoJSPlugin.js#L120

See that?  Four parameters are packed onto an object called bodyParameters... .types, .sizes, .positions, and .rotations... and those are used to create the new "body" for the compound imposter (in a function just below that).

Is anyone thinking what I'm thinking?  If so, seek therapy. 

What if I lied, and told Mr. Oimo that the invisible body for the green studs... was longer, and positioned more z-ward.  In other words, even though the green studs protrude from only one side of the wheels, maybe tell Oimo to size and position the rigidBody as if the stud also protruded from the OTHER side of the wheel as well.  In a way, an invisible stud on the opposite side of the wheel from each real green stud.  Wow! 

All this hell, to eliminate a little wheel wobble?  Yeah. 

Maybe I'll try that.  Put on your safety gear and hold on!

Update:  http://playground.babylonjs.com/#1VITPM#5  Nope, I don't think the green studs are causing my wheel wobble.  Oh well, it sounded good in theory. 

PS:  Anyone seeing an issue with the PG's -Editor button?  Canvas not resizing to full, just moving to the left side?  *shrug*

[Wingnut]

Hi again.  Ok, maybe I have found the reason for the wheel wobble (but more likely, no).

http://playground.babylonjs.com/#1VITPM#25

Crossbar disconnected and well out of the way, keep hitting RUN on that playground.  See how the wheels change tilt angle... after the RUN?  I'm printing a bunch of after-render information to the JS console... so go take a look at the numbers.  They are live and continuous at the console.

What can be deduced from that seen wheel-tilt adjusting (camber), and from those off-by-a-little numbers?  I don't know.  The numbers SHOULD be moving a bit, as I have turned-off rigidBody sleeping.  But... those differences between Oimo's options.axe1 = [0,1,0] and Babylon's Quaternion.RotationYawPitchRoll(0, Math.PI/2, 0) are possibly real and pertinent.

In simpler words... options.axe1 = [0,1,0]    !==   RotationYawPitchRoll(0, Math.PI/2, 0)

Maybe, they don't produce the same radian values.  Maybe better worded... things aren't "squared-up"... maybe.  Maybe there is some Euler/Quaternion/Matrix conversion artifacts/slop inside Oimo math funcs?

Those wheels are changing camber after render... for SOME reason.  Babylon quaternion initially puts the wheels at a certain camber, and then when the physics links are established, the camber adjusts to match the link.  Why link axis !== quat?  

A reminder... we are talking about the links between the wheels, and the white axles.  There are no issues with the green studs... they have been re-centered to ensure they are not part of "the wobble factor".    But they, too, could have a wobble factor that I might need to address... eventually.

Things need to be aligned well... to get maximum fluidity.  Even though http://playground.babylonjs.com/#1VITPM#4 was an improvement of fluidity...  it still drags a bit.  It is "binding" somehow, it seems.  It should "coast" for a LONG time after being impulsed-up to train speeds.  It does NOT coast well... but the crossbar IS a bit heavy at the moment.  Still... it should coast much longer, I think.

Thoughts, anyone?  (thx)  Party on!

[RaananW]

I also found that calculating the rotation using the internal "roll pitch yaw" function is not correct. I believe that it's due to the axis order. My solution was to use the following :

var rot = new OIMO.Euler().setFromQuaternion({ x: mesh.rotationQuaternion.x, y: mesh.rotationQuaternion.y, z: mesh.rotationQuaternion.z, s: mesh.rotationQuaternion.w })

So, using oimo's internal function, which I assumed will work correctly. This is also what is done in the physics plugin for oimo.

[Wingnut]

Thanks R!  A great try, and probably pertinent in many situations, but I couldn't find a way to apply it for me.  What I really need is something like options.axe1 = [0, 1.002, 0] and that's a ridiculous idea.  But that's what I really (thought I) needed.  A way to square-up Oimo's [0, 1, 0] so it aligned with Babylon's Eulers.  It's really not doable, and that's not the problem... but it LOOKS like it's the problem.    Thanks again for the lead, though.

Step #1, simpler playground.

I know I can get a squared-up wheel on a hub... I've done it.

http://playground.babylonjs.com/#1VITPM#27  (click like hell to spin)

Nice and squared-up... but its not a compound.  Let's go back to compound...

http://playground.babylonjs.com/#1VITPM#26  (click like hell to spin)

I've added some power.  Line 65 lets us choose whether to use a compound or not.  Default is ON.  Spin it up.  Wobble.

Before we set it to false... activate lines 80 and 81... and run again.

Much nicer, eh?  I have been assuming that the act of creating a compound impostor... automatically set the physics state on the initialMesh (the first mesh in 'parts').  But does it?  When those 2 lines are active, I am setting the physics state on initialMesh (wheel1) AFTER making the compound impostor!  But I am NOT using comp1 as it's impostor for that.  I am using a cylinder impostor.  If you use comp1 as the imposter in line 80, it gets ugly quick. 

Strange stuff, eh?  The compound is causing the wobble (I think).  The mass that stud1 adds to the compound impostor... seems insignificant.  The whole imposter only has a mass of 0.1.  Stud1 never gets a physics state set (and thus has no personal mass) because it is a part of the compound.  But maybe stud1's size and position are much more important and pertinent.  Both of those are used in bodyParameters for the creation of the compound.   hmm.

Now set compoundIt = false, if you wish, and see a perfect camber wheel.  Stud1 probably can't have anything linked to it, though.  It is not physics active in the non-compound version.

Learning learning learning.  *scratch scratch* 

Update:  http://playground.babylonjs.com/#1VITPM#28  I tried using the comp1 impostor in line 80... and it works nice.  I needed to adjust the apply impulse in line 162 WAY WAY down.  I wonder if that is indicative of something... ie. maybe I just eliminated a TON of friction and binding. (yay!)  hmm. 

I'll learn how to use these compound impostors yet, I will.    This would mean that I was completely wrong about scene.createCompoundImpostor automatically registering/setPhysicsState.  Instead, it just makes an impostor, which STILL needs to be used in an initialMesh.setPhysicsState construct somewhere else/later.  hmm.

That makes sense. 

[Wingnut]

Yet another.    http://playground.babylonjs.com/#1VITPM#29  Sick of this, yet?

No compounds, no parenting.  Everything is held together by links (joints)... and they are a bit wobbly yet.  But, by avoiding compounds and parenting, I think I am seeing a truer "kinetics?".  Spin this up with repeated clicking (not TOO fast, though).  I am impulsing the right wheel (2) only. 

As the speeds come up, we see the green studs bending and thus the blue connector bending... and we see SOME wheel wobble... but...  all of this could be expected/normal with mass: 1 on the blue conn1 connector bar.  It's a bit heavy.

I see some bad things happening here, yet.  The blue bar is moving around on the green studs.  The green studs are bending, and likely moving around on the wheel cylinders (can't tell).  All this COULD be caused by options.spring, and someday I will try to learn what that does.    There are also constraints I could activate... but I like it "raw" for now.

I may have axes1 / axes2 issues yet... still experimenting.  I still use an axis "twist" on the blue bar.

But there is one WONDERFUL thing I see in this demo.  It coasts and coasts (lower speeds), and has very little friction and/or binding.  Yay!  There is still some trouble at high speeds due to joint wobble.  Yeah, joint wobble!  

Increase clicking speed GENTLY on this demo, or you'll get weeble-wobble impulsing freak-out.    Stay loose!

[RaananW]

On 11/23/2015 at 8:43 PM, Wingnut said:

Yet another.    http://playground.babylonjs.com/#1VITPM#29  Sick of this, yet?

Nope, not sick of it at all. Actually, it is rather fascinating.

I keep on wondering how to integrate your playful demos in the framework itself.

You are constantly using lower-level functionalities from Oimo. I try to convert it to a generic way, to be able to implement it to cannon.js as well and implement it in the plugins.

I'll need some more time

[Wingnut]

That's good to hear, Raanan, thanks.  The reason I chose Oimo is because it has a documentation weakness, but I want to thank all the local people that have done SOME docs.   You have taught me a ton about physics, Ranaan, and so has Temechon, Davrous, and DK... and some others.  But the various joint types are not well documented or AT ALL.  For example... the jointWheel type.  One would think that jointWheel would be exactly the joint type needed for my tasks, here, but I have not had any success using it.

It might not be proper for this project, though.  Source comment...

jointWheel : rotation between two rigid bodies along two axes and translation for the suspension.

That sounds like a car/truck wheel.  All my "wheels" are rotational-only, and I want no translation.  So, maybe jointHinge is correct for what I'm trying.

For those who have not noticed the names-relationship between these physics engines, I believe they all started with Bullet Physics.  Bullet, CannonJS, AmmoJS, OimoJS, these names seem to have a general "ballistics" theme.  Thus, if we can find the docs to Bullet, we might get some help with the documentation for those JS-based libs.

As far as using setPhysicsLinkWith vs. Oimo.Link... they look nicely interchangeable, with the help of the options objects.  I'm not sure who wrote our physics plugins, but they are both very good.  It doesn't take long to learn them, and plenty of knowledge about the physics engines themselves... can be gotten from some easy studying of the plugins.  But Oimo and Cannon are quite powerful, and there's still plenty of physics features to experiment-with.  We'll all need some more time, R.  Personally, I could use some more brain power. 

But... (I say that often, don't I?)... what about PhysX and similar?  Will we see physics being built into hardware or machine language on the next gen computers?  Will that help us here in JS land?  JS-based physics can be slow slow slow. 

The good thing is IF we do see a JS interface to PhysX, some of the same joints and collide features found in our Oimo and Cannon libs... will likely be seen on the PhysX interface, too.  In many ways, a physics engine is a physics engine, and it seems that they all have SOME repeated basic functionality.  I think we'll need parallel processing to accomplish the fast physics, and that might never be available to JS in browsers... according to things I've heard. 

I guess we'll wait and see what the future holds, and keep experimenting with what we currently have.  At minimum, maybe an "Everything You Ever Wanted to Know About Physics Joints" document... is on the far horizon.  A basic task in that quest... is knowing what parameters are available on the options objects for Oimo and Cannon, and our plugin author(s) have helped with that A TON!  Thanks plugin coders!  Only my weak brain and another 20,000 hours of experimenting... stands in the way. 

Comments certainly welcome... as always.  Here's some interesting "physics links" if anyone is bored. 

http://www.wildbunny.co.uk/blog/2011/04/06/physics-engines-for-dummies

https://coronalabs.com/blog/2014/07/22/tutorial-physics-joints-explained-part-1

[Wingnut]

Hi gang!

    Well, it's the holiday season in some parts of the world, and you know what that means... tinsel and lights.  Such things taste delicious with Uncle Wingy's world famous 420 egg nog.       http://il8.picdn.net/shutterstock/videos/8277475/thumb/1.jpg

Simulating chrome tinsel requires high reflection, and the best webGL reflection I have ever seen... comes from the Spherical Environment Mapping done in our fantastic CYOS shader editor.  So, I had to grab a zip of that and cram it into a playground, and start having fun.

http://playground.babylonjs.com/#16UICJ#1

Ok, ok, it's not exactly tinsel... but it's still lots of fun.

But we don't require shaders in order to accomplish great reflections.  Hey, who put that box inside my xmas ornament?

We all know where our webGL limitations are.  Four lights per material.  And we all know where our work-around talents are limited... not at all. 

So, I invite you all to try your hand at strings of non-light lights and reflections and tinsel.  Our friend and hero Ranaan didn't have a December challenge for us, so, here's a last minute non-judged challenge should anyone decide to participate. 

Show us your holiday sparklies and glitter.  Post the URL's right here in this thread.  Some of you have gotten quite good-at positioning particles, so don't forget the power of sparkly particles to make holiday light strings.   Above all, have fun!   Happy holidays!

[Nikos123]

Nice work guys!

[Wingnut]

Thx Nikos!

Hi gang!  It's been awhile, and we're going through forum adjustment shock, but I always like to show strange and unexpected playground discoveries.

So, here we go! 

http://playground.babylonjs.com/#10JNZ8#1

Red inner polygon with gray outer box!  Flashing bounding box lines!  (at least that's what it looks like on MY computer)

SO much effect, SO little code!  WOW!  Love that BabylonJS!

No, you better not ask me why it's doing all this.  I suspect it's possessed. 

[jerome]

Painting a white bounding box exactly at the same position than a red box... it's possession, but YOU are the devil to do such things 

[Wingnut]

  Soooo, what are you working-on, Jerome?  Up to anything demented?  You're SUCH a hero of mine.  It's almost time that we drag some of your SPS and Spherical Harmonics demos down main street, again... start another hero parade.  I still drool over your SH, at least once per week.  SO pretty.  But so is this... http://www.babylonjs-playground.com/#21QRSK#9   Just gorgeous... and brought to you by who else?  Jerome!  Yay!  I'd like everyone to know that Jerome was courageous and emailed Prof. Hart and Prof. Stemkoski, AND wrote a nice usage-rights presentation at our github site, AND showed both Professors that presentation... AND got us clearance to republish all those pre-formed shapes.  YOU ROCK, JEROME!!!

I haven't seen professional scene-crafter Steve Synergy around, lately, either.  That usually means that HE is building something diabolical.  (He does that pretty often... always scares the dog... runs under the bed, and I don't even own a dog!)   

Some of Steve's musical things... brought out the musician in you, too, eh Jerome?  You play an instrument? 

There seems to be lots of (closet) musicians lurking in BJS shadows.

I came across Deltakosh's pointLight shadows thing again, recently.  http://www.babylonjs-playground.com/#LYCSQ#12  Man, that is SUCH a nice demo/effect!  Pan around and look at the poles of the sphere inside.  Look at the way those shadows look on that "tall ceiling".  That... feels... cathedral-like.  Awesome!  Big, in your face, realism... breath-taking to a degree.  Coooooooooooooooooool!  Torches and candles are in hot demand, now. 

I yacked-up a storm on the Q&A node, today.  Even did a little time in our "pinned" default node.  phew.  I learned a TON from Forum Chief Administrator Rich, today. He got my head on straight.  Thanks Rich.   (My head was severely bent.  I snowblow alot around here... mighta got caught in something.)

Talk talk talk!  It seems that every subject that people were talking about... was really interesting.  Still is.  BJS is hoppin'! 
And yay, 2.3 release!  Congrats to DK and the team!  Smokin!