continued_at_new_forum The Wingnut Chronicles

[jerome]

Congrats Wingy 

Welcome onboard the *$%!#& hell of git/gihub

[jerome]

FF simd latest news : https://blog.mozilla.org/javascript/2015/03/10/state-of-simd-js-performance-in-firefox/

[Vousk-prod.]

BTW, to deal with Git very easily on windows, I advise you to have a look at GitExtension (doc : https://git-extensions-documentation.readthedocs.org/en/latest/ ).

Clearly the best git companion I found on Windows.

And if you'd like to experiment some linux-like way of life, it also allows you to use git bash manually.

[Wingnut]

Thanks VP, that's a nice interface to git.  To others who decide to try it... if the installation stalls at around 50%, look for another window that has opened on the taskbar, asking for a permission.   Click OK on that, and the installation will continue to success.

 

Dummy Wingnut.    I sat there stalled for 15 minutes before I pulled my head out of my butt.

 

So, who's curious about DK's baby?  I am.  I hope things are going well with that.  Have we got any "My Name is Earl" fans?  Remember when Joy was trying to induce birth?  Too funny.  Status reports are quite welcome here, DK... should you decide you want to share some.  Best wishes with that!

 

No time for demos at this time.  I have been playing a bit with animated jMesh "tubes" trying to make the cartoon cannon for the Artillery Duel game that I'll never get done.  I also want to try cannonball firing and bounce (without rotations)... using only maths and no physics engine.  But my personal life got busy with trying to clean-out and sell a house, just like last summer, so I am using this opportunity to beg to Jerome and others... to help me with the cannonball project.

 

The cartoon cannon is fairly simple, animation wise.  It's length scales to 50% and the tube bulges fat in the center (or across the entire length)... for the cannon "pucker" or "anticipation".  When it fires, it animates to 200% length and goes thin in diameter in the middle or across the entire length... ideally a bit concaved (opposite of spherified).

 

The ball firing and bounce... without a physics engine?  Phew.  The formulas are available.  In 6-8 months, I bet I could understand them enough to fire a bouncing ball.    I bet Jerome or similar math experts... could do it in an hour.   So, HELP (anyone, and if you want-to).  (thx, tons)  There's a forum chap who is making an Arkanoid/Breakout-like game.  He might be able to use some non-physics-engine ball-bounce code, someday, too.

 

Be well!  Party on!

[jerome]

Hi

 

Yep, we all expect (good) news from DK's baby !

 

Cannonball project :

some tips ...

no real physics are needed for this, I guess

 

For the cannon tube, we could start from a regular tube, a cylinder : linear axis (path), constant radius

Let's imagine we have 20 points on a line for the path and a fixed radius

 

Then for animating, we could for a given number of frames morph the tube this way :

- its path could keep the same number of vector3, 20, but they could become closer and closer and the same line

- meanwhile the radius could be a radiusFunction, a simple one, say, a sinus function with angle varying from zero to PI along the point positions multiplied by a bulging factor, so the start and the end of the tube radius would be almost zero and its center would be bulged ( a x² function would do the job also, this would just give a different bulging)

 

Then for firing, for some other frames, we could just invert the former morphing, but far more quick and add then an extra morphing :

- the 20 points path would be longer and longer (points further from each other)

- the radius slightly incurving (cosinus as formerly, with lowest bulging factor)

 

For the ball, the simplest and most realistic curve is a simple parabolic curve :  y = x²

which gives in parametric equation :

x = k;

y =  - f * k * k + height;

z = 0;

 

(f = factor to emulate initial ball speed, heigth = the starting height, the cannon hole)

and k varies in a for loop from and to the right values.

If we want the ball to bounce on the ground, we need to re-apply this formula (with another f to simulate loss of energy) each time the ball touches the ground (if y== 0) as if the ball were re-fired from the ground into the air with a lower speed each time

 

No time now to try a PG 

 

hope it helps

[jerome]

tonight Q&D attempt : http://www.babylonjs-playground.com/#25OQ8V#3

wait 5" before it fires

 

have fun hacking this 

[jerome]

almost done here : http://www.babylonjs-playground.com/#25OQ8V#4

 

it could be improved with less hard-coded values of course, especially initial ball position and speed values.

 

Something I don't get : in this former example, I designed an oblique tube, so with no mesh rotation. It works.

The morphing is smooth.

 

Now look at this : http://www.babylonjs-playground.com/#25OQ8V#5

line 35 : var y = 0 my tube axis is not oblique, but parallel to the ground.

line 47 : cannon.rotation.z = Math.PI / 4;

=>  the straight mesh is now rotated

If I run this example, I see the cannon mesh flickering when morphing on my computer.

 

Is there a reason ?

I know rotation apply after mesh recomputation... but I don't get why it's flickering in this case.

[Wingnut]

Jerome, fantastic advancing!  THANKS!  Very good.

 

Yeah, I see some flicker, too, and I don't know the reason for it.

 

I'd love for it to run about 4 times faster, but we'll look into that later.    Right now, it's a good speed to view what's happening.

 

At first glance, it looks like you are using distance-between-points tube animation (for cannon-length).  Axis.  Interesting.  I need to study it.

 

The attempts I tried... used standard .scaling for length adjusting during the animation.  I'm not sure that I know what I'm talking about, but, I think distance cannot be used (in custom radius funcs) when doing standard .scaling (or at all).  I think distance becomes inconsistent with standard scaling, but i (the path index) works just fine, still.  (of course)  You didn't use distance, either, as best I can tell.  It appears that you use an x-axis array for both "buggle" and fire animation phases.

 

I suppose standard mesh.scaling affects the "sphere-ness" of the buggle.  *shrug*

 

Thanks for "running with this", Jerome!  You're very kind.  Weapons that "lob" their projectile... will be using your code forever, Jerome!  Many are medieval siege weapons.  So cool!  I love 'em.  We might see a time when we need more than one shot active at the same time, but maybe that's not plausible.  I'm not sure what kind of performance we can expect, but now we have some code to play-with.  Very good!

 

This is also the beginning of a basketball game. 

[jerome]

http://www.babylonjs-playground.com/#25OQ8V#6

 

line 68 : play with var speedFactor to speed up the projectile 

[Wingnut]

You're just the best, J-man! 

 

The cannon animation has to finish in 3-seconds or less, I suspect.  More like 2 seconds.  That's about the same as a classic cartoon cannon.  Do you think we can get there?

 

When I was playing with animating jTubes, I made lots of mistakes, but every mistake had such interesting visual results... that I kept stopping to play-with the mistakes... and lost track of the objective.  hehe.

 

I need to improve this tri-view.

 

http://urbanproductions.com/wingy/babylon/polygun/polygun03.htm

 

(.zip available there, too)

 

(press fire AGAIN... just before the projectile hits the ground, for some more fun)

 

I wrote it back when I was REALLY new to BJS, and it shows.  The blue divider lines are camera views of blue planes placed far away from scene origin.    I think they could be 2D divider lines (canvas strokes), somehow, and help speed up the scene.

 

In the classic Artillery Duel, left view is your cannon, right view is enemy cannon, and bottom view is full of knobs and stuff to aim and powder your cannon, plus current winds information.  The objective was to blow away the platform where the enemy cannon is sitting... or a direct hit on his cannon.  All of that can be done without a physics engine.  Objective... keep game speeds UP UP UP. 

 

REALLY bad code (the tri view).  It uses a special box... made in a different file... out of planes... JUST SO I could leave a little crack at the corners where the planes meet.  (workbox)  (and it causes fall-thru of physics objects, so it sucks).  Now we have flatshading and bounding boxes... all sorts of ways to see the box corners better.

 

But really, we want to take the cannon and ball.... out into the mountains of a heightMap, right?  Cooooool. 

 

Ignore the rotation situation.... that can be faked if needed, for artillery duel.  For rolling a ball around in the mountains... that might be a different story. 

[jerome]

http://www.babylonjs-playground.com/#25OQ8V#7

 

I changed and commented things so it is easier to understand and to set up

sequences :

  var start = 0.0;  var startBuggling = 1.0;   // seconds after initial start  var startFiring = 2.0; // idem  var startBall = 2.2; // idem

the cannon starts buggling 1 second after the script begins to run

then it fires at 2 seconds

and the ball leaves the cannon at 2.2 seconds (I assume you are at 60 fps here)

 

you can change these values

 

physics :

  var x0 = 10; // initial ball fire position x  var y0 = 10; // initial ball fire position y  var vx = 30; // x speed ball  var vy = 25; // y speed ball  var g = 9.81; // gravity

the ball starts at (10,10, 0)... hardcoded because I'm lazy... this could have been computed from the cannon position and length

the ball has an initial speed vector of (30, 25, 0) here.. set what you want, it gives initial direction and speed. This could have been computed too from cannon orientation

gravity can be changed, the higher, the fastest the ball falls down to the ground

 

  var loss = 0.8;  // bounce energy loss  var speedFactor = 5.0;  var buggleFactor = 2.0;

loss = the speed decrease each bounce, here it's 80%. Can be changed.

speedFactor = a time accelerator when the ball flies, can be changed. Set it to 1 to understand or see things well.

buggleFactor = to increase/decrease buggling during the buggling sequence

[Wingnut]

Oh man, I love it!  It makes me laugh and smile for some reason.  About 18 fps in FF, here... on this sloth box (expected).   9 fps on IE.

[jerome]

18 fps ???

I've got 60 fps on my 2007 old Fujitsu laptop with chromium... definetly not a race machine

 

 

Well, see line 26, var dt = 1 / 60

You can tune it to approach your fps so it will close the real time

var dt = 1 / 18;

for instance

[jerome]

Ooopps

I realized I forgot to update the speed vector at the very moment of the bounce

done : http://www.babylonjs-playground.com/#25OQ8V#8

 

Now, the trajectory is finally realistic.

 

Consider the var loss as the ball elasticity : 

1 == ball 100% elastic, no energy loss when bouncing

0.8 == 80% elastic, 20% energy lost at each contact

etc ...

[Wingnut]

Hi gang!  I did a bit of advancement on the tri-view (eventually to be used on Artillery Duel).  It's now a 2-view with html gui in the third view.  This one is much cleaner than my old 3-view.

The targeting systems on these new artillery units are much more computerized than the old ones.

http://playground.babylonjs.com/#1VXHZA#6

You were fooled for a moment, weren't you?  You thought it was a REAL panel full of gui down there, didn't you?  Nope, it's just an img element, which could easily be an iframe element, which could easily hold an html document PACKED with knobs, buttons, and readouts.  YAY!

Of course, if the gui/menu document is iframed into existence... then we probably have scope problems.  Our JS may not be able to get events from it, or set the values of readouts on it... due to the security isolation of an iframed document.

Further tests ahead.  We don't need to use iframe for the bottom area.  It could be a DIV, and we could stuff it full of HTML directly... with JS.  We will also need to set the CSS styles that same way.  You will see some of that... in this demo. 

It spurns spurs the imagination, doesn't it?  *nod*   Have fun, comments welcome.

[Wingnut]

Hi gang!

I'm trying to convert Temechon's pivot scene (done in JsFiddle)... into a playground scene.  I just started.... got interrupted, and I have the dreaded "c is undefined" error.  If anyone would like to help fix it, I'd be most gratified.

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

Maybe the context2D stuff can be replaced with BabylonJS Lines, too.  *shrug*  Good luck, and thanks for all assistance.  Pivot on!

[Samuel Girardin]

Hi wingnut, 

 

the bjs playgrount said me 'scenes" with a s is undifined. And some weird conversion from v2 to v3. But it ' s true I 'm writing under the influence of red wine, froget my pôst ! 

[Temechon]

Hey Wingnut, 

 

It's not my demo, I think it's samuel's (I'm not good enough at coding to create something like this). And I think you define two engine and two scenes in your playground. That may be the problem.

[Wingnut]

Ahh, sorry Temechon.  It's Gwenael's, I guess. 

Yep, I used-to get you and Gwenael confused quite often, and I see those days aren't yet done.    And thanks for finding my pasting mistake, T!  http://playground.babylonjs.com/#1WI6NQ#1 We're rolling now.

And, you're an excellent coder and teacher, Temechon.  I worship the water you walk on!

I think Sam was trying to tell me about the same thing... scenes with an 's' (as in plural, as in too many scenes)    He was a little blurry and I didn't pick-up on his hint.  Maybe I was the blurry one, eh?

Thanks guys!  I'm trying to clone the jsFiddle found here... http://www.html5gamedevs.com/topic/3083-spaces-world-parent-pivot-local/  And yes, it's a thread started by Gwenael, and a post by Gwenael, and likely a jsFiddle by Gwenael.  Yet I somehow think Temechon created it all.  I'm quite the genius, eh?  hehe  phew.

Does anyone see the context2D lines, either in Gwenael's JsFiddle or in my barely-operational playground?  I haven't seen them, but I guess there's supposed to be some lines there.  More troubleshooting ahead, I suspect.  Thanks again!  Be well!

[Temechon]

I'm sure you can use BABYLON.Line instead of context2D Sam used (line were not existing at this point).

Here is some code I did on another project to draw for a mesh the mesh axis, maybe it can help : 

var debug = function (mesh, scene) {    mesh.computeWorldMatrix();    var m = mesh.getWorldMatrix();    var v3 = BABYLON.Vector3;    var s = 5;    var x = new v3(s,0,0);    var y = new v3(0,s,0);    var z = new v3(0,0,s);    var startInWorld = mesh.getAbsolutePosition();    var endInWorld = BABYLON.Vector3.TransformCoordinates(x, m);    if (mesh._xAxis) {        mesh._xAxis.dispose();    }    mesh._xAxis = BABYLON.Mesh.CreateLines("lines", [        startInWorld,        endInWorld    ], scene);    mesh._xAxis.color = BABYLON.Color3.Red();    var endInWorld = BABYLON.Vector3.TransformCoordinates(y, m);    if (mesh._yAxis) {        mesh._yAxis.dispose();    }    mesh._yAxis = BABYLON.Mesh.CreateLines("lines",        [startInWorld,        endInWorld    ], scene);    mesh._yAxis.color = BABYLON.Color3.Green();    var endInWorld = BABYLON.Vector3.TransformCoordinates(z, m);    if (mesh._zAxis) {        mesh._zAxis.dispose();    }    mesh._zAxis = BABYLON.Mesh.CreateLines("lines", [        startInWorld,        endInWorld    ], scene);    mesh._zAxis.color = BABYLON.Color3.Blue();

[Wingnut]

Ok, I've got lines happening...

http://playground.babylonjs.com/#1WI6NQ#2

The axes are not in the correct positions, nor is anything else correct... but we got lines!  YAY!

See how the lines/axes change position very strangely as you pan the camera around?  Cool, eh?  That's because the camera's viewMatrix is used for things.  COOOL.  But... hmmm.   The lines (in the original pivot demo) were done on 2D.  I had to convert to 3D (BJS Lines)... and so... maybe... I don't need line 145 anymore.  It WAS used for calculating WHERE on a 2D canvas... to put the lines.  In the 3D lines version, I just put the lines WITH the boxes.  BUT... line 145 is still in-use and so the lines move-around with camera panning.  Fun!

Lines 152 and 156 used to be Vector2, now Vector3.  I set z to zero... but I am still experimenting in those areas (yawn).  Improvements by others VERY welcomed - thx!

[dbawel]

So the next step is to draw lines in real time, hmm....

[Wingnut]

Lines 246-251 mean anything to ya? 

 

Those lines are very much real time.

 

(this kind of stuff scares my dog) 

[dbawel]

I was looking at those lines in your script specifically.  

 

I have to finish a mult-user real time creative drawing app by the 17th which will be a v1.  However for v2, I envision a 3 dimensional brush design to also draw vector lines dimensionally, and to use a proximity function to weld these lines and create verticies at their intersections.  Now I have something to look forward to.

[Wingnut]

Wow, in 4 days?  You are going to get a tumor, DB! 

 

So, I guess you want users to make shapes that are different from BJS built-in shapes. 

 

You understand that all bjs mesh are made-up of triangular faces, and the clockwise/counterclockwise order of the indices... determines frontface/backface?

 

Users will use a mouse to plot a point in 3D?  How will they "see" the z?  (how "deep" to plot the point).

 

I think most modelers use tri-grids.  Create a point, keep it highlighted, allow dragging it on any of the three grid planes.

 

Go get 'em, DB!  Tri-Grid is probably a decent tool to contribute to the framework, too.   With images on the grid-planes (for the grid lines), you will want to map it perfectly onto a proper plane.  In other words, each grid cell should be 10 by 10 webGL units... or similar.  That could be called a 10-to-1 grid.  The demo above... is 100-to-16.  (goofy calibration, eh?) 

 

SOME fancy drawing programs scale the grids as the camera gets closer.  Get closer, 8-to-1 grid, closer, 6-to-1, and get close enough... 1-to-1.  1 grid cell to 1 webGL unit.  Fancy.  Bitch is, you really need to TELL the user when a grid has scaled. 

 

The user could place their camera VERY close to the ground grid (so it has a 1 cell-to-2 webGL units scaling)... but farther from the right side grid (it is 1-to-4)... and even farther from the back-wall grid (it is 1 cell = 10 webGL units). 

 

And if you are wanting proximity snaps, those snappings will happen at grid line intersections, which must snap on all three of the tri-grids, and each might be scaled different.  phew. 

 

In a way, grid intersection snap "sensitivity" is directly related-to grid scaling.  When a grid is... say... 10-to-1, it's 1 grid cell per 10 BJS units.  So, the grid cells will be big, and thus snap-granularity/sensitivity will be "coarse" grain.  With a tighter grid, snapping to intersections will be "fine" grain.

 

Maybe the correct term is "selectivity", a term I learned studying radio tuners.  A high-rez (many-cell) grid-plane... would have "high selectivity".

 

Weird.  Hard thinking.  I'm glad it's you and not me.   Darned interesting, though.  Good luck, and keep us posted if you would be so kind. thx!  Party on!