continued_at_new_forum The Wingnut Chronicles

[JCPalmer]

@gryff, think your analogy was updated by Southpark for election purposes to: "A giant douche vs a turd sandwich".  Your not still upset they invaded Canada in their movie, are you?

[Wingnut]

haha..  "Blame Canada, Blame Canada".  Ahhh... JC knows South Park stuff, huh?  Cool. 

And that movie is SO packed with not-very-hidden symbolism, "eh"?   Wonderful music, too.

TV and movies are a great "common connector", too... even for folks as backwoods and "out there" as Canadians. 

JC, you and I will be on the front lines, when they drunkenly stumble across our northern border.  I guess we better stock-up on the Kielbasa.  We'll feed 'em to death.  hah.  Truth is, though, they don't want to conquer the USA.  If anything, they want to build a wall to keep-out American tourists.  hah

Gryff... yeah, I don't know if you back-read to the start of the button-talk posts.  This is going to be a FAT menu... with no other enabled mesh in the scene.  And it's 14k with wireframe ghost mesh.  7k in production. 

I fig about 20 buttons on the full menu... each button with physics imposter... with mesh hanging from chains/ropes (physics joints), blowing in the wind... squeaking.    Possibly the #1 heaviest, gaudiest webGL menu EVER... and darned pretty.  Possibly woodgrain.  Maybe dynamic-genned logs... with hatchet-hewn flat faces... to put the labels-upon.  SO pretty... SO Canadian-ish.

I need one/all of you guys... to code-up worldSpaceCanvas2d.convertToDynamicTexture()... soon.  It needs to be "live updating"... so that when I make a change to a Text2D font or label text... the dynamicTexture is updated, too.  This live-wired worldSpaceCanv-to-dynamicTexture... will allow the wsc2d to map-onto the curve-faced button (and onto sphere-shaped buttons).  The label will follow the curves (uv mapped).

BUT... you know the problem.  Wsc2d's are SO MUCH MORE than a texture.  The ACTUAL wsc2d (the source of the dynamicTexture)... will likely have to continue existing, un-rendered, after the conversion (if the dynamicTexture is to be "updatable"). 

One other thing to think about.  Sometimes the programmer will only want to allow click-on-label.  Sometimes they will want click-anywhere-on-button, including its mesh.  Would this be called "Event ganging"? 

For example... a click on the button's MESH... will be observed as a click on the Text2D and/or its Rect2D container... because they are all "ganged" together.  A nice programmer-choice feature... for this new FatButton class. 

In the end... I can edit button.currentFont, then...

- the un-rendered wsc2d updates its Text2D
- the convert-to-dynamicTexture happens again
- the change is displayed on the uv-mapped dynamicTexture of my fat-vert button
- Wingy begs someone to code... "allow click only where there is texture" option... for mesh/actionManagers. 

Smooth as gravel!  YUM!

New button version!  (fleshing a class - 101)  The code is ALMOST readable!  Ralph, the button... he's cool.  But Gryff is right to question the 7000+ vertices... for that button's mesh.  It seems it could be "generated" with far less.  Hmm.   Too bad that "Superello" code scares me so much.  ANYONE, feel free to "hack" the 3 mesh generator funcs at the bottom.  They scare me.  I stole them from somebody's playground. 

[Wingnut]

Hi kids!  Okay, advancements are happening in FatButtonville.

http://www.babylonjs-playground.com/#14VFYX#18

Physics active, handlers operational (simple color changing)... working/looking pretty good.  FUN!  I don't think the joints are correct between button3 and button 4.  They seem stiff... almost like button 3 and button 4 are hard-connected.  Joint 4 and joint 8... debugging ahead.

Click away!  Click quickly, if you dare.

What's that?  You say you need another weird playground?  Ok, here we go.    Muh - Muh - Muh - MY CORONA!

[Pryme8]

Dude thats fun, it would be really cool to see them replaces with like wooden planks that have text carved into them and some ropes connecting them then I could totally see that as a home screen for a game.

[Wingnut]

Hi gang.  This is a branch from http://www.html5gamedevs.com/topic/26110-angle-of-mesh-intersection/?do=findComment&comment=150937

(and regarding Jerome's no-physics-engine ball-bounce code)

Given a playground like this, a guy SHOULD be able to launch the ball... in such a way... that the ball bounces continuously cross-ring, to a tile at a 175 degree angle, back and forth across the ring.  It would advance 5 degrees for each cross-ring bounce, yes? 

Phew!  Wow!  I bet Jerome could make that work.  (wink hint beg whine).  Perfect launch, perfect speed, perfect umm... math.  *sigh*

This is how we get our "Parabola Master" rating.    Ring-Pong!  heh.

Things get kind of pretty... if we get demented with this ring-o-tiles.  Fun! 

Here's another weirdness...

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

Each clone... has showBoundingBox = true.  But NOT the master (named 'platform') in the center.  It doesn't have showBoundingBox = true, yet it still has a one showing.  Weird.

Now look carefully at "the flower".  It has ONE "petal" that has no bounding box, and interestingly, it is the ONLY "petal" that has transparency!  WEIRD!! 

I had to take a shot of whiskey... over that one.  Mega-ponder.  heh.  Yet another haunted scene.   

Update: http://www.babylonjs-playground.com/#PBVEM#22  I added line 71... setting the alpha on each clone's material.  Now all petals have alpha.

Apparently...  hmm.  :/  Apparently, when alpha is set on a material (platformMat line 45), only the FIRST clone that uses that material... inherits that alpha.  Possibly a bug.  Not sure.

That other thread is still talking about ball bouncing-in-a-bowl.  Fun challenges and demos.  Cya there.

 

[Wingnut]

Ok, so, hi again.

http://www.babylonjs-playground.com/#PBVEM#38  (and my goofy physics-active version of SOMETHING, here)   

This is @adam's simu-intersect thing (in the first link).  Lookin' good, working good.  No classic fat physics engine, no bounding boxes, no intersectsMesh or moveWithCollisions.  Just raw horsepower (and trickery).

With the right Path3d, and the right half-pipe Tube... a guy could make a real nice Christmas-light-lined luge track, eh?  If the green origin traveled a curvy tube z-axis... and if the ball was a luge sled... hmm.  The luge could "swing" way up high on the banked luge track corners...  users carefully working their controllers... fighting with centrifugal and inertial forces... trying to keep the luge from flipping or leaving the tube.  Cooooool.

Just like Adam's intersect-free bouncer, the luge sled would never really touch the track. The track is only there for putting BJS adverts on the banked turns. 

The sled would act like a pendulum weight... hanging from a fast-moving invisible origin (green box)... traveling along a curvy/hilly Path3d.  (Exactly like Jerome's rollercoaster, only completely different. heh.)

7.5 miles of curvy, hilly hemisphere.  sigh.  Who's plotting the Path3d for the luge track TubeMesh?  Volunteers?  Anyone?    I'll make the Christmas lights along the track.  This is a perfect place to torture-test our BJS "hundreds-of-lights-per-material" feature.  What a sleigh ride we could build!

I wonder.  Will the AMOUNT of path3d points along our tube-center... which greenbox origin will travel-along....need to increase on the curves?  I think so.

Although the tube mesh is there MOSTLY for realism, it is also used for Adam's DistanceSquared work (line 81).  I think the path3D points (and likely tube mesh segments) will need to be closer-together around the tight curves, or Adam's distance measuring could get "jumpy"  (Possible coarse/steep angle-changes as luge sled goes around banked corners.) 

The diameter of the tube will be changing as we travel down the tube.  This is why Adam's distance measuring technique needs to be e used often...  constantly.  (It was only used once in the bowl demo, because the bowl stayed "concentric^?". 

Currently, tube diameter changing is done with a radiusFunction.   It could also be manually determined and stored, possibly stored on the vector3's of each path3D point (a v3).  OVERLOAD!    Path3d keyframes. 

We might need a single float rotation value stored on each point, as well.   Half pipe tube "twist" value.  The rollercoaster demo does twisting well.  It also uses constant distance between path points.  hmm.  Adam's distance measuring can measure anywhere, not just path points.  hmm.  But if the path point "stored" its own tube radius value... then Adam would not need to do the measuring at all.  He would do tube-radius interpolation between current point and next point (tube radius change per sled step).  Essentially, each path point stores it's distance to origin (tube radius distance).  Sled can "read" those values as it travels along.

Heavy.  hmm.  Smart path3d points, overloaded with added goodness... vitamin fortified.    Found half-pipes... sort of.    Essentially, the sled could draw its own track around itself... but reading data from each SmartPath3dPoint step.  The path3d is a magnetic tape and the sled is a digital data "read" head.  heh

Whomever "plots" our luge track/waterpark slide... must be a pro, and will likely need math and Bezier wrangling.  uh oh.  We see some excellent stuff.... already in the rollercoaster demo.

Rollercoaster Path3D Assistant V1.0? 

Once we have a really nice path3D generator, we can use these paths for light and camera flying, too.  EVERYONE loves Path3d's, as long as they don't have to manually plot them.   

(Wingy digs in his cool BJS toolbox and pulls out a dusty device)  Hmmm, curve3.  What the heck is this thing used for? 

[Wingnut]

Hi gang.  Playing with Sprite2D as a mouse pointer over renderCanvas.

http://www.babylonjs-playground.com/#14VFYX#20

Problems getting sprite background to be transparent (like here), and I need to reverse the Y-axis somehow.

Other than those minor issues, success!  Next up... particle emitter as mouse pointer!  Tinkerbell, eat your heart out!

DING!  Pizza is done. Time to eat.  Ya'll fix my sprite pointer, eh?  (thx for help)  Party on!

[joshcamas]

14 minutes ago, Wingnut said:

\ Ya'll fix my sprite pointer, eh?  (thx for help)  Party on!

Here ya go my friend: http://www.babylonjs-playground.com/#14VFYX#22

I simply subtracted the Y value from the height to invert it, and I just enabled alpha on the texture :3

[Wingnut]

Thankya Josh!  Well done.  My brain was mushy for some reason.   Hunger, I think. 

Update:  It's gettin' weirder, and more "spartical".  http://www.babylonjs-playground.com/#14VFYX#25

Wanna know how difficult it is... to glue a sphere onto the end of your pointer?  Lines 136-137... tumor makers!    And the sphere is TINY, and it is essentially stuck to the lens of my camera... like a booger.    Camera.minZ SO LOW, you can see the camera's circuit boards.  heh.

Speaking of cool playgrounds, I found this one leaning against a tree in Playground Park.  Nice!  Author unknown.

[Wingnut]

Ok, hi again, gang.  Hey, remember when @JCPalmer proposed the idea to put a "search for playgrounds" button/choice AT the playground page?  Well, I think it is time to DO that, eh?  I really like that idea.  Possibly, choice #0 in the select-a-demo pull-down menu.  Choose #0, and off you go to the playground search page.  AND... when we get to the playground search page, we could use some more instructions... about avoiding periods and underscores in the search terms.  Thoughts, anyone? 

I would be glad to add the "rules of playground search terms", IF I knew what they were.  So, would anyone like to test and document WHICH metachars (periods, slashes, *, etc ) are allowed in our playground search terms, and which are not allowed?  When a search term fails, the playground searcher often returns 1000 impertinent hits.  So... yeah, stuff could be done with that. 

I'm still thinking about my luge track idea.  But instead of using an ever-changing-radius, ever-twisting, half-pipe tube, I have been thinking about using particle quads and a custom updatePosition function.  With some precision positioning of particle quads... I can make a luge track completely from a single BJS particleSystem.  I can even re-use quads that are out-of-frustum behind the luge sled... to create new track ahead of the sled.  A type of camera frustum leap-frogging, moving particles from behind frustum... to beyond frustum... on the fly. 

Oh, what a custom positioning function it would be.  I'm scared.

But, BJS particleSystem is SO efficient... that I don't need to do real-time (on-the-fly) particle (re-)positioning.  I have about 50000 particles to build the entire track... before the game starts.   No problems.  And when you "grow" a luge track from particles and math like that, it is easy (well, it CAN be done) to make track changes and generate random tracks.  Need steeper turns and higher banked corners?  No problem... the track generator can do it fine, with the tweak of a variable.

By the way, luge tracks are also skateboard tubes and water-park slides. 

I think a particle-based luge track generator would still need to follow a path3D and curve3D to some extent, though.  If we use Adam's vector3.distance thing... to place the luge sled on the track, it will need a "track line" for its continuous measuring.  The track will often change tube diameter, so we need to do distance measuring from centerline (tube origin) to tube wall (the particle quads or a tube mesh) very often as the sled moves along on the track. 

This is because the track does not carry the sled.  It only LOOKS that way.  Instead, constantly doing distance-measuring (from tube-center to tube wall)... keeps the sled runners millimeters above the track surface.  The track has just two purposes.  1.  For looks.  2. Used for measuring distance/rotation... to place the sled position/orientation.

I think it will work.  But, this is a scary new world for Mister Wingnut.  Sculpting with particles.  We've seen @jerome and others create a sphere-of-particles, box-area of particles, and even a torus knot of particles.  I wonder if we (I) can create a luge-track-area of particles.    Have a rad weekend, everyone.  Party on!

 

[jerome]

http://www.babylonjs-playground.com/#21XXDF#1

[Wingnut]

purrrrrrrdy!  It has that beloved and famous "Jerome Gray" background color, too!   Gotta love it! 

I tried a few experiments with the luge track... goofin' around.  http://www.babylonjs-playground.com/#1EBCJY#5

I think I gave myself motion sickness, though.  I don't feel so good.  (sparf)  (sparkly barf)    Let's build a narrow "scenery box" to see if we can get more motion "feel".  http://www.babylonjs-playground.com/#1EBCJY#7  Better "scenery flying-by" feel, but poor edges blending.  hmm.

[gryff]

@Wingnut: I logged on tonight and find you made 1000 likes. I had hoped to be the poster of that 1000th like but had to make do with 1001

Anyway Wingy it is a tribute to all your contributions to BJS, the forum, the PG, tutorials and documentation. Ohh, and of course, your sense of humour 

You are one of the backbone members that make this forum such a good place to learn and improve one's skills.

So thank you for your time and dedication. I hope @Deltakosh and the other Microsoft members of the BJS team appreciate your contributions.

And to quote you, "Party On!!!"

cheers, gryff

[Wingnut]

That's some very kind words, Gryff, thank you.

YOU are equally "backbone" and important 'round these parts, my friend.  Yeah, if the forum users only knew the fun that you and I have had... in PM here... they'd be seriously jealous.

(Gryff is a little public-shy, but he's a total "hoot-and-a-half" in the back alleys.  Seriously knowledgeable, and a personality that is every bit as zany as mine.  Possibly MORE so!) 

So, thank YOU, too, Gryff and all the other "golden warriors" of BJS.  Our future looks bright and fun, doesn't it?  We have great tools and even greater tool users.

(Wingy raises a mug of something purple...)  "Here's to us!   PARTY ON!" 

PS:  Do we still have Microsoft employees hanging around here?  I heard they were all fired for partying on.    My kind of people.

[Wingnut]

ooookay... back to our luge track project.  (our?)    umm... there is this other "thing" still looming.  IF players of this "sim" never need to see the entire luge track from a wide angle view, then... there is another option.

Live-morphing ribbons/tubes... dynamically.  The sled never moves on a z-axis at all.  Instead, we push ribbon strip after ribbon strip... AT the camera/sled.  The track goes past the sled, instead of the sled going down the track.  And the track... is drawn on the fly.  (never-ending road thing).

And THAT thought... might take us over to @NasimiAsl's geometry builder or shader builder.  Can we get the on-the-fly dynamic track generator... into the GPU? 

Things that make ya go "hmm".  And do we really need the luge track?  What we really want... is a sledding hill... so we can use innertubes, saucers, toboggans, Radio Flyers, skis, cardboard,  all sorts of ways to damage our bodies!  I have seen endless landscape engines from both Naz and Pryme8, and both could make one hell of a sledding hill.

Or is there "something" about the high-banks of a luge track?  Going past the 90 degree banking mark... on a tiny little sled?  That's GOTTA feel cool, in real life, and maybe even in-sim.

Using mountains and similar for our sledding hill... won't allow 90 degree banked corners... naturally.  We would need to build them out of models... positioned on the sides of hills and mountains (at track turns).  hmm.

Scenery, or track seams, or beer adverts, SOMETHING... has to be moving past the camera at high-speeds... to give us that "holy crap, are we hauling ass" -effect.  This is not easy to accomplish, either.  hmm.

When we were kids in northern Wisconsin, we didn't need all this thinking.  We just found a hill, slid down it on our devices... until it got real iced-up, and then it got too fast and started sending us kids to the doctors office for stitches and casts.    Times were simpler... back then. 

[NasimiAsl]

21 minutes ago, Wingnut said:

on-the-fly dynamic track

what is this Exactly ??

[Wingnut]

Thanks for interest, Naz.  It means... um... tube or roadway is made by program... and placed just beyond camera frustum... piece by piece.

then position pieces step by step... into frustum... toward camera.  Every step, a new piece of track is created beyond frustum (beyond camera.maxZ), then moved toward camera.

So track is actually being built all the time, and constantly re-positioned toward the non-moving vehicle/sled.  Sled never moves.  Instead, mesh-track (or simulated-by-shader-track) moves.

From a shader viewpoint, it is a never-ending tunnel... or funnel.  But... need z-twisting half-pipe.  See picture below.

I have seen shaders do never-ending tunnel/cave... but... we still want banked corners, and we still want some kind of scenery moving past... to indicate speed.

https://i.ytimg.com/vi/p1E432yh2oE/maxresdefault.jpg

Half-pipe.  Not a complete "tunnel". 

Pretend no track exists beyond what is seen in the picture.  As player rides tube... new track is placed out-of-view... "just in-time" to enter frustum.

That's "on-the-fly".  Generate track... just-in-time... ahead of player view.  (Good to see you.  Hope you're doing well.)

Naz, I am talking about luge track or "tube ride" or water park slide.

In my previous post, I also talked about "sledding hill"... and that is a different subject... but still could use your terrain gen to make endless "ski hill" to slide-down.  Maybe allow jumps!    (but no tubes/tracks on this type of sled ride).   That would be fun, too.  Tobaggan hill.  YAY! 

The "speed" effect is important, here.  Something has to move past the camera... on the sides... QUICK.... just like this, but better.  hmm.

[getzel]

15 hours ago, Wingnut said:

Yeah, if the forum users only knew the fun that you and I have had... in PM here... they'd be seriously jealous.

 

I want to know !
 

[Wingnut]

Getzy... you might not be able to "relate".  We were whiteboarding beaver porn.  You know... watching Canadian/NorthUSA woodland critters... having sex with each other.  Muskrat love and beaver beaver.  Are you into that?  It's a regional thing, for the most part.    (yikes, we're really reaching for the comedy, here)  heh

http://www.babylonjs-playground.com/#3XMWZ#56

These ribbon things that @jerome added to the core long ago... they have some track-building potential.  The smoothness of the curves is so nice.  This is an "enclosed" version of the ribbon.  See line 35... 3rd parameter... set true.  You can see the "bridger" (encloser) ribbon-piece... looking a little stretched-to-fit.

These ribbons are nice.  But can an "engine" be made to place ribbon after ribbon just beyond camera frustum (on-the-fly)... as the camera speeds-along on that track?  hmm.  Something tells me... yes... a ribbon-based on-the-fly waterpark slide tube-generator... IS possible.  (Wingy waxes-up his snow-saucer.)  We probably need a little camera shaking, too, when the speeds increase and we are powering the sled through a high-G banked corner. Could poke random values into the render canvas CSS top and left margins.  Earthquake the canvas.    FUN!  Heart-pumping fun!

[NasimiAsl]

Dear @Wingnut Challenge Accepted   wait for me 2 days

[Wingnut]

No work or duty, Naz.  Just fun.  Sledding play.    It's beginning of winter, here where I live.

Ok, Chronies, let's try a track-o-ribbon instances...  http://www.babylonjs-playground.com/#1EBCJY#9

Not too bad.  These are pre-generated, not on-the-fly.  *shrug*

Ooh, a luge track design study...  https://www.researchgate.net/publication/49709140_An_approximate_simulation_model_for_initial_luge_track_design

Innsbruck folk.  They know snow. 

I think its time for a new type of luge... maybe called "fluge".  Flying luge.  The long straight runs of the track... would allow flying (hydro-planing).  There would be airfoils on the luge, and if your speeds are good, you can lift the weight off the sled runners... using ground effect air currents.  WOW! 

I live 15 miles from Copper Peak... a former "ski flying" thing.  Perhaps... living THAT close to downhill retardation... has contaminated my common sense.

[NasimiAsl]

http://www.babylonjs-playground.com/#1V70NA#14

@Wingnut i try More for this  

 

 all do in GPU side this is  from ShaderBuilder so this have problem in collision 

** i can make it by GeometryBuilder too that is not use from GPU But that is optimized too (and not have any limitation ) 

 

[Wingnut]

haha  COOOOL!  Nicely done.  What a ride!    You're just amazing, Naz!

[Wingnut]

So... then... did ya'll notice that the JS files have disappeared from the BJS "src" folders?  Hmm.  This folder was the place where I stole all the code that I "hijacked" into playground scenes.  (Pasting bJS source code into playgrounds... is a good way to experiment with improvements to BJS functions and classes, and to do over-rides and work-arounds.)

I sure hope there will be a place where I can get bJS code to paste into playgrounds.  (Wingnut chews his fingernails to the bone with worrying, and retrieves a pair of knee-pads from his closet... in case kneeling and praying to Gods... is necessary.)  :/

[gryff]

@Wingnut : Hmmm ... all those :

"Removed javascript files from src folder 7 days ago"

tells us when the "theft" took place

Has the directory been checked for fingerprints?

cheers, gryff