continued_at_new_forum The Wingnut Chronicles

[Wingnut]

Yep, Wingnut mistake.   Thx DK.   (Wingy tries to memorize that info). 

Now I try again to repro impostor.physicsBody is null or e.physicsBody is undefined .  Maybe P8 can repro.

I'm glad... if it is ONLY a Wingnut mistake.  No bug in plugins... yay!

Still, hmm.  How the heck... can keypress event capture... affect a physicsBody being found/not?  WEIRD!  *scratch scratch*  I need aspirin! 

Impostor was busy on a worker thread... when the un-captured 2nd applyImpulse keypress happened?  (speculation fun)

Someday, I'll work-on figgin' that curiosity. 

Edit:  I got a new variation when working this issue:   this._physicsEngine is undefined   

ALL occurrences of these errors... are happening when working-with keypresses.  hmm.  There's a theme, here. 

[Wingnut]

Hi gang.  I recently did some light playing with dynamically generated log cabins.  Just getting "rolling".  http://playground.babylonjs.com/#1XVEKZ#2

I must be in a Lincoln Logs frame-of-mind, today, huh?  I, once, started assembling one in Simply 3D or Bryce or somewhere.  Didn't finish. 

Lifting the logs with JS... is sure easier than in real life, I tell ya. 

Feel free to run-with this playground, gang.  Let's see your log cabins, should you decide to assemble some.  Log on!

Update:  [latest]  Look at the swirly saw blade marks... on the butt-ends of my tube-based half-log.  Coooooool.

Another update: http://playground.babylonjs.com/#1XVEKZ#7  This is SO fun!!!  

[Wingnut]

Yet another basic dyna-cabin.  http://playground.babylonjs.com/#1XVEKZ#11

MUCH MORE scalable/dynamic, now... with many "knobs" in lines 76-84.  FUN!  I'm still too scared to add the var howManyLogsHigh value. 

Log fencing to go with it, you say?   Yeah!  On Bonanza, the Ponderosa Ranch didn't have many fences, but the few they had... were all-wood, I think.  No barbed wire for those guys.  They were always kind to animals, especially when Hop Singh would cook steaks for the boys. 

[JCPalmer]

ahh...Admit it you've been watching daytime MeTV.  Who remembers the name of the cook.

On your PG, I must admit I bookmarked it.  I am only interested in the Balsa.  BTW, Pixar released an entire library of repeating textures under Creative Commons.

[gryff]

@Wingnut: Looking at your "log cabin" PG got me thinking of all the ways that humans have sought and created shelter in the real world. Wood of all kinds, plants, animal skins, grass and sod, and of course stone and rock.

Ty Hyll (The Ugly House) - Originally built of stone and moss - no mortar - and legend suggests in 24 hours.

But this is perhaps the most curious construction material that I have ever seen for a building - a Vancouver Island Cafe . A good example of recycling?

Ohh ...er.. and I think Hop Sing(h) - unless he was perhaps a Sikh from India .

@JCPalmer: TY for that link Jeff

cheers, gryff

 

[Vousk-prod.]

On 26/03/2017 at 8:29 PM, JCPalmer said:

ahh...Admit it you've been watching daytime MeTV.  Who remembers the name of the cook.

Too many cooks 

[Wingnut]

hehe... you guyz is funnnnnny! 

http://playground.babylonjs.com/#12SEYV#18

Yet another goofy playground distraction.  Using @jerome's fun playground as a starter (runs faster than mine, I'll work on that), and using Solid Particle System boxes, with direct access to OIMO (no plugin usage)... I am trying to make a "snow plow".  (a plane that plows SPS particles).

Lines 84-93 sets the 'bodyConfig' used for the plow "blade".   Its size and pos parameters match the blade's mesh.  When the blade sits still, it seems to block particles fine, but when I start it moving, it seems to leave its impostor behind. 

Play at-will.    Attempts to move the body.body... are available in lines 123-124 area.  Possibly need to move the blade with applyImpulse or linearVelocity, I suppose.  Party on!

[jerome]

I think these are adam's PG, not mine ;-)

[Wingnut]

Ahh, thx, and thanks to @adam, too, then. 

Yuh, here is Jerome's version, with sphere-based motor-grader blade, plowing funny-looking gravel.    http://playground.babylonjs.com/#PBVEM

Jerome's blade is moving well, and no physics engine.  Cooooool.  But can his particles... "embank"?  Will they mound-up when plowed?  How well does all that... "stack-up"    hmm.  Tonka-Land (toys in mud) is still... just barely... out of reach, it seems.  We only need about a ka-zillion particles.

Here's the thread that covers it all.  Mad men in there, I tell ya. 

Anyone ever see TV show Highway Thru Hell?  It chronicles a "heavy wrecker" service (Jamie Davis Heavy Rescue) and they use big wreckers to rescue flipped semi-trucks in heavy snow-storms.  Fun.  If I had a sceneful of BJS mud or gravel (or snow)... I could figure out some things to do with it.  heh.

GTA5 fans who use the MenYoo cheat... may have played with muscle cars in snowy North Yankton.  Pretty damned fun.  Slippery, but no "embanking" allowed there, either.  SpinTires game... also way fun, with SOME embanking of mud (on each side of tire trenches), but no bulldozing or road-grading. 

[jerome]

here are all the adam's PG about this test : 

 

[Wingnut]

Thanks @jerome.   Speaking of @adam, I used (his?) showNormals() function to do some troubleshooting on my dyna-genned bobsled model.  Kind of a "heavy" scene.

Remember to use mousewheel and control-dragging, as needed... to get close looks at white 'normals' lines. 

I had to do some transform-bakes, because showNormals() does not take into account mesh position, rotation, or scaling, apparently.  I tried to modify showNormals() and made SOME progress - but bailed on that idea.  Doing my mesh positioning, scaling, and rotating FIRST, then baking-in those transforms, THEN using showNormals()... seemed easiest in the end. 

For the noobs:  You can set .scaling, .rotation, and .position on a mesh, then call mesh.bakeCurrentTransformIntoVertices(), and BJS will (re-)set mesh .position, .rotation, and .scaling... to values Vector3(0, 0, 0)... yet leave the displayed mesh unchanged.   Handy, sometimes.

The actual scene issue:   The tail cowling has nice "specular shine", when viewed at good over-head angle.  Long lighting "streaks" travel across its top surface, when camera is moved in a certain way.  Looks good.

The nose cowling... does not have the same nice specular shine (no long light reflections), and I think it SHOULD.  (Wingy kicks the nose cowling) 

The angles of the normals across the top curvature of the tail cowling... are more straight-up... than those on the top curvature of the nose cowling.  Not sure why, but keep reading.

The 20 thin mesh that make-up the cockpit area... have the same problem.  Normals angled... not perpendicular... not "90-degree orthogonal".  See it?  Steep angles on some of the nose and cockpit-segment normals. 

Possible hint:  The tail cowling is scaled approximately the same amount on all three axes (near proportionately).  The nose and cockpit segments... are scaled far less "all-axes proportionate".  I think that is what causes these "bent normals".

33.  nose.scaling = new BABYLON.Vector3(2, 4, .5);  // disproportionate
69.  segments[segment].scaling = new BABYLON.Vector3(100, 25, 6);  // disproportionate
97.  tail.scaling = new BABYLON.Vector3(11.12, 10, 8.35);  // near proportionate

Ideally, "The Bake" should "square-up" the scaling-bent normals... FOR US.  (I think.)  Perhaps a parameter: .bakeCurrentTransformIntoVertices(retainScaledNormals?);  [bool flag] 

The tail cowling has good-looking normals.  They all seem orthogonal to the 4 faces that surround each one.  hmm. 

Does anyone know if computeNormals() or some similar "thing"... could "fix" these odd-colored, odd-shine... nose cowling & cockpit-segment normals? 

I'd like to normalize these normals.  heh.  Any help/ideas... appreciated.  Party on!

[jerome]

about showNormals(), you shoudl use this one  https://github.com/BabylonJS/UserFunctions/blob/master/showNormals.js what uses a LineSystem instead a line per normal (old version)

[adam]

Hi @Wingnut, I can't take credit for that showNormals function.

[adam]

Here it is with the showNormals function that Jerome suggested:

http://playground.babylonjs.com/#PBVEM#84

[jerome]

Actually, this time, it's mine 

[Wingnut]

haha!  Well I'm batting 10 for 10, here, huh?  heh.  I might as well give-up trying to remember who invented what.  Too much brain damage on my part. 

Thanks for the showNormals help/info, guys.  I gain-backed some FPS on PG #84 - good deal.

I was thinking about this bent/tilted normals problem... as I slept last night.  The normals are tilted in the direction of the most-up-scaled axis.  That makes sense.

That discovery doesn't yet give the bobsled a consistent material across all parts.  I was hoping that pinging two of the best plot-masters EVER... would get me a morning miracle.  Hmm.  Darn.  Thanks for thinking about the issue (and the showNormals stuff too), just the same.  Ideas welcome, from anyone.

I tried some stuff in PG #85... in lines 33-46 area.  I copy original normals, then re-install them after scaling and baking.  This changed tilt angles of the nose normals, but still tilted.

	var  nose = BABYLON.MeshBuilder.CreateSphere("h", {diameter:  noseRadius*2, slice: 0.5, segments: 24}, scene, true, BABYLON.Mesh.DOUBLESIDE);

        //  grab copy of original normals
        var origNormals = nose.getVerticesData(BABYLON.VertexBuffer.NormalKind);

	nose.material = new BABYLON.StandardMaterial(" noseMat", scene);
	nose.material.diffuseColor = new BABYLON.Color3(0, 1, 0);
	nose.material.backFaceCulling = false;

        //  This didn't do anything, but it sure was named nice. :) It's for parametric shapes.
        // nose.freezeNormals();

        // do my stuff, including scaling
	nose.rotation.x = Math.PI/2;
        nose.scaling = new BABYLON.Vector3(2, 4, .5);
        nose.position = new BABYLON.Vector3(0, 0, 10);

        // Put back original normals - no change.
        // nose.setVerticesData(BABYLON.VertexBuffer.NormalKind, origNormals);

        // bake-o-rama
        nose.bakeCurrentTransformIntoVertices();

        // Put back original normals AFTER bake - makes nose normals tilted differently.  :)
        nose.setVerticesData(BABYLON.VertexBuffer.NormalKind, origNormals);

Oh well, it SOUNDED like a plausible idea... inside my head. 

[adam]

Calling updateFacetData updates the normals:

http://playground.babylonjs.com/#PBVEM#86

[Wingnut]

EXCELLENT!  Thanks Adam!  I didn't get much specular shine improvement (or tail-color-matching improvement) on the nose cowling, but hey, I can't blame the lighting normals anymore, can I? 

Here is a version with all showWireframe and showNormals off.  Easy to see color and specular anomalies.

Okay, hmm.  Materials issue?  I guess that's where I'm heading next. 

I think... the material needs inverting, top/bottom.  Material that is on-bottom of nose and segments... needs to be on-top, and vice-versa.    Something is wrong with my material clampers or wrappers or something. 

And yes, I tried rotating the entire nose mesh, but that is not the solve.  The material/shader KNOWS when I try to cheat... by z-rotating the nose, or by scaling it on different axes.  No matter how I roll, scale, or bake, the darker green low-shine side of that material... stays on the +y side of the nose mesh.  What the heck?

Everything is good... on tail and fins.  hmm.

Thx agn for the orthog-o-norms, Adam. Well done!  You're SUCH a hero of mine, you really are.  Truth.

[Wingnut]

Update:  Another bobsled.  Everything is FRONTside, now.  Slightly cleaner code.  Added gap between cockpit segments (yawn). 

I still have color/specular differences between tail... and nose/cockpit segments.  

Verts is verts, normals is normals, what the heck am I missing?   Hmm.  Ideas?  (thx)

update:  (not like anyone is needing updates)   http://playground.babylonjs.com/#PBVEM#100

Version 100... merge the nose, tail, and cockpit segments, and boom... everything is fixed.  Good specular shine, good color match.  YAY, but go fig.  :/

[Wingnut]

Ok, fresh, simple testing scene - looking at specular and color on spheres and planes.  http://playground.babylonjs.com/#11YE88#3

First, planes.  They look pretty good - bright green color.  When camera is above, there is a big, soft specular shine that moves-around with the camera.

Now DE-activate line 15, and activate line 16 (change to spheres).  Scaling on line 19 makes the spheres flat and wide.  But look at the color and specular shine.

Overhead view again... the sphere colors are darker than the planes colors, and the specular is weak and doesn't move with the camera. 

Take the camera UNDER the spheres, and we see SOME specular shine that moves, but, that's not normal, either.

At the risk of being (more of) an idiot, I am now ready to proclaim that there is SOMETHING wrong with the way materials are mapped-onto spheres and ribbons. 

I think planes and extrudeShape are both fine.  The fins and the tail of the bobsled... are both extrudeShape.  The cockpit segments are ribbons, and the nose is a sphere (hemi-sphere).

Something happened when I merged the tail, cockpit segments, and nose... of the bobsled.  It "fixed" the nose and cockpit segments.  Weird.

Anyone agree? 

[Wingnut]

Damn, it's quiet here in The Chronicles.  I guess everyone is busy.

Ok, Jerome's infinite terrain thing... (drag forward to go go go)... umm... WHAT IF... the terrain could be "influenced" by a tube/path?  Luge track!!! 

This "tube", besides having its normal customRadius function feature... would also have a customWeight function.  This per-pathPoint weight value would determine how -Y deep... the tube-contour would be "sunk" into the terrain (into the hills/mountains, etc.)  Influencing power, ya know?  Proximity-to terrain points... heightMap-weighting thing. 

It doesn't matter if a valley suddenly happens and the tube can't bend extremely to match valley contour.  We want the tube to be somewhat linear (smooth bends)... so we can "fly" a bobsled along that "terrain groove".  The bobsled will NOT be inside the tube. The tube is only used to counter-act the noise heights for terrain gen.  The bobsled can fly high and leap far (well outside-of the diameter of the terrain-influencing tube).  Don't worry, it has thrusters. 

How about it, Jerome?  Inventors?  Anyone?

"Hey Mister DynamicTerrain... please use the noise-height data freely EXCEPT... where you find a jerome tube.  There... make-way for it.  Contour yourself smoothly, but avoid intersecting the tube."

(there's no reply from Mister DT.  He doesn't know me yet)

Lastly, the tube radius could get wider... on hard turns.  I know I can't expect "under-cut" banked turns... like on a real luge track.  But... on steep turns... the bobsled will try to +y climb-up the turn embankment (UP the sides of the mountain ridge or ravine walls).  So... you know... the cooler the better, and likely, larger tube diameters on hard turns... would be good.  CustomRadius func should handle that fine.

Ravine Cutter v1.0 - Gettin' Groovy!  Yeah!  From Gorge Productions, Inc.  (the folks who brought you RiverRouter and Lake'n'Bake)

FUN!  I have a dream!  Bobsledding!  Now, back to that material mapping thing.  What the heck?    C'mon experts.  heh

[Wingnut]

Ok, on the bobsled (#100)... when I merged the dark/dull mesh... with the bright/shiny mesh... the dark/dull changed to bright/shiny.  (yay)

SOMEthing happened to the dark mesh... during the merge.  Everything got bright and shiny.

So, yet another test... http://playground.babylonjs.com/#11YE88#9

I was hoping that merging the 16 bright/shiny boxes... with the 16 dark/dull spheres... would make the 16 spheres change to bright/shiny.

But NOOOOO.  Wingy is foiled.  hehe.  The giant 34 mesh merge... didn't improve the spheres' color/shine AT ALL. 

Apparently, not ALL merging with bright things... will make dark things... get brighter.    I thought sure I had a piece of hot evidence... something that could lead to a break in the case! 

Nope, just a big ol' air biscuit swing'n'miss.  heh.   hmm.  Aren't you glad I am chronicling all this?  (snore)

update:  Another test.  This time, ONLY the sphere (hemisphere) nose section.  The one on the left (the shiny, bright "good" mesh)... is the merged mesh.  I merged an instance of it... with NOTHING ELSE.  Only an instance of it... was put into the mergeList (line 70).  And, when merged, it went from dark and evil, to shiny and good.    What the hell?

Normals for both mesh are sent to console.  They look identical.  Too bad showNormals() is failing for the merged mesh.  Not sure why, yet.

And something is "fishy" with my nose.bakeCurrentTransformIntoVertices(), too (line 57 in demo #10).  He is involved in this situation, somehow.  If I don't nose bake before the merge, nothing changes in the merge.  The merged mesh stays dark. (more vertexData is sent to console, in THAT pg)

The problem involves a combination of baking and merging.  Erf!

Stay tuned, this story is getting better by the hour (snore).    I'll find the culprit/reasons, I will indeed!  Maybe.  Assistance welcome, though. heh

[Wingnut]

Aha!  hahaha!  KICKED ITS BUTT! 

http://www.babylonjs-playground.com/#11YE88#15

Look how bright and shiny those flattened spheres are!  [view previous version].

No merging needed.  YAY!  Notice lines 87-91... "the yay maneuver"    I stole it from a section of BJS mergeMeshes().

Okay, let's try 'the yay maneuver' on the nose and cockpit segments of the bobsled...

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

Perfect!  Nice shiny, bright bobsled pieces... all match.  No merging needed.  One "yay maneuver" for the nose cowling in lines 208-212.  Another is used for the cockpit "ribbons" in lines 220-224.

Go fig!  hmm.  Interesting!

[Wingnut]

Another test...  http://www.babylonjs-playground.com/#11YE88#18

Just a sphere, scaled flat and wide.  Many mesh, all scaled significantly.  Lines 44-52 are the yayManeuver(mesh) func, and it is called at line 87 (and other places).

    var yayManeuver = function(mesh) { 
        mesh.bakeCurrentTransformIntoVertices();
        mesh.updateFacetData();
        var myVertexData = BABYLON.VertexData.ExtractFromMesh(mesh, true);
        myVertexData.transform(mesh.getWorldMatrix());
        myVertexData.applyToMesh(mesh);
    }

There it is, the thing that "adjusts" flattened spheres (and certain ribbons, possibly SCALED ones).  I tried to remove the bake line, and the update line, and both.  No go.  All 5 lines are needed.  hmm.

I think... it would be cool to have this done to scaled spheres, by default (in core, automatically).  But, we CANNOT do that bake, by default.  I was SO wishing that the yayManeuver would work... WITHOUT the bake.  hmm. 

All in all, turn on/off (control /) line 87, do the comparison... if you wish.  Perhaps more soon.  I still want to test spheres scaled-at-creation-time... with meshBuilder.

Note:  Ooh, there are changes happening in/to the playground app... every 2-3 minutes, RIGHT NOW.  LIVE coding!  New playground features being added, right under my fingers!  Cooooool!  I'm excited!  I wonder what the big dogs are building?  (Wingy tries to spy, but, he wouldn't understand what he was seeing, anyway.) 

Note #2: The ORIGINAL #18 playground reffed in this post... was lost to alligator attack.  The NEW #18 is slightly different, showing MANY scaled mesh instead of ONLY the sphere.  Please read a few more posts in this thread... for more info.

[GameMonetize]

We will announce the changes soon bu I'm sure you're gonna love it