continued_at_new_forum The Wingnut Chronicles

[Wingnut]

Wow, I finally took a look at...

 

https://github.com/BabylonJS/Babylon.js/blob/master/Babylon/Actions/babylon.interpolateValueAction.js

 

It wraps a standard Babylon animation object!  Cool!

 

https://github.com/BabylonJS/Babylon.js/blob/master/Babylon/Animations/babylon.animation.js

 

On the animation object... is where the interpolators are.  Yuh, yuh, yuh.  I have SO MUCH to learn!  :/

 

JC, that Pace object is a gruesome dog, yessir.  Interesting!  I think I am going to need a Cray before everything is said and done. 

 

Sometimes, I am glad I work with boxes.  heh.

[JCPalmer]

Wingnut,

My design goals are to first separate "what to be done", from actually doing it.  Pace is only called once per frame, to determine the ratio to interpolate, not for every vertex to be interpolated in the shape key group. InterpolateValueAction does the actual execution too, which means you have to fork it.

 

Also, straight line, or linear execution is the only thing possible with InterpolateValueAction.  Now I could make a custom LinearPace class, but the amount of time saved per frame is minimal.  Still might be worth doing, but do not want make things unless I am sure I need them.

 

Jeff

[Temechon]

Hey guys, I heard you talked about Actions...

 

Wow, I finally took a look at...

 

https://github.com/BabylonJS/Babylon.js/blob/master/Babylon/Actions/babylon.interpolateValueAction.js

 

Check this out : http://www.sokrate.fr/documentation/babylonjs/1.12/index.html

 

Shhhh.... Don't tell anyone, it's just a preview version   (only the folder 'Actions')

 

The rest of the documentation will follow soon. 

 

Cheers !

[Wingnut]

Very nice, Temechon!  Thanks for your great work on our API.  I love it!

 

Well, I spent most of today trying to get dynamicText looking nice so I could show new users... readouts... in playground scenes... helping teach.  (part of that 'picture worth a thousand words" thing).  Then I thought... "Wingy, how would you do readouts on scenes that ARE NOT in the playground?"  Well, I would use the way Gryff and I have used before... HTML tags at the top of our canvas... printing to them live.  But we are not able to put html tags at the top of the playground's canvas.  Or are we?

 

http://www.babylonjs.com/playground/#1ITKPB

 

Ahh, we just KNEW the playground had the abilities to play with itself!  (ahem).  And since we can do text fields (divs and spans), then we can do buttons with onclicks, too.  I didn't take it that far, yet, though.

 

I was thinking about doing a random number generator and feeding those values to the canvas element's left and top margins... causing a canvas earthquake.    But nah... I'll leave that to some other demented playground experimenter.  Party on!

 

PS: Want to see something interesting?  Try setting that light.groundColor to (0, 1, 0) and hit Run.  Now look at the bottom of the box.  No green.  Now set the box's diffuseColor to (0.5, 0.1, 0.5) and hit Run.  Suddenly, box bottom has some green.  Yep, it appears that the box's diffuseColor must have SOME green-ness to it, or else the hemisphericLight's .groundColor cannot green-ify it. 

[Wingnut]

Want worse?  I knew ya did.  http://www.babylonjs.com/playground/#1HFJEN

You might need to control-mousewheel this one a bit (on the html areas, not on the canvas area).  It picked up quite a bit of space between the colored text lines.  Not sure why. 

 

Only the position is being animated, so far.

 

Really, though, I just wanted to make sure I still held the record for the most-bloated playground scene. 

 

My mom got a letter from the town council... accusing me of abusing the playground equipment.  heh.

[Wingnut]

Ok, Deltakosh is gone for the weekend.  When the cat's away, the mice will play.  What kind of mischief can we get into?    Does anyone have any of his passwords?  How about the keys to his house?  hmm, there's got to be SOMETHING we can do to mess with him. 

[Wingnut]

A more finalized version... http://www.babylonjs.com/playground/#ICDBU#2  Full ridiculous mode ON! 

 

Lots of read-outs, and not much space (and no read-outs in fullscreen mode, understandable).  These read-outs aren't just information.  I am trying to show the newbie... the actual commands they can use in their scripts.  As you can see, I dynamically adjusted some playground window widths.  Goofy.

 

Comments?  Do you think a day-1 user (extreme newbie) of BJS... would learn anything from staring at this?  Or would they run away from BJS and never look back?  I'm trying to teach the youngsters SO MUCH with one scene... erf.  I don't know.  sigh. 

 

The struggles of a day-1 tutorial writer, I tell ya.    I'm all stressed out.  heh.

 

I bet SOMEDAY, we could make a draggable vertical divider between the editor window and the canvas window!  Well, not 'we', but... maybe Davrous or Deltakosh.  I bet it is possible.    I hope everyone is well!

[Dad72]

Hi,

 

If you want to teach babylon, I think we should start with something simple and easy to understand and with minimal code. avoid unnecessary. your scene is huge for so may of thing that can be carried out in 2 times less code.

 

Yes I think your scene might scare because they may feel it takes a lot of code to do what you did on your scene.

 

In general, the better the code block must not exceed 2 times the height of the heigth screen max. 

[Wingnut]

Hi. 

Dad72, I agree, and I wish I could hide the code completely. I was hoping to have the users ONLY stare at the rendered scene.  Maybe I CAN hide the code by setting the jsEditor.style.display = none.  The 'fullscreen' button hides the code, but I lose the read-outs. (And my mouse pointer disappears and the camera acts strangely, too)

 

Yep, the code is ugly and out of control.  And as FR pointed out, the rendered scene is confusing, too, and it doesn't have a box showing .scaling yet.

 

Maybe a better approach... is one simple saved playground scene... for each characteristic.  One simple scene showing animated positioning, one scene showing animated rotations, one showing animated scaling... and maybe no color changer.  The purpose of this Babylon.js Primer demo... is to get the new users to understand axis orientation of a basic scene. You know, learning which directions are X, Y and Z, and seeing positioning-along... and rotations-around...  those axes.  (That's why the color changer doesn't belong there, and should, instead, be a .scaling box.)

 

With the existence of the playground, ALL the Playpen Series tutorials can change in a unique and interesting way.  In any tutorial, I can install MANY links to saved playground scenes (especially nice if I could get those playground links to 'open in a new window' - doubtful). 

 

As the user reads down through the tutorial, they can have link after link of playground scenes... showing each stage of the tutorial.  As BJS evolves, we can edit the tutorial, and, because of the playground, easily edit the demos that go WITH that tutorial.  Nice options.

 

These demos that I'm making now... will not go into the playground's built-in demos list.  They are just SAVED demos... for linking-to in that Babylon.js Primer that is currently being poorly written. 

 

Teaching aids.    You see, text needs translating to other languages.  So if I can teach with pictures/scenes...  that's better.  Pictures/scenes are automatically multilingual.

 

Hard thinkings.  Curriculum development is a pain in the butt!

 

Thanks for the comments, gang, and keep them coming, if you please.  I need all the good ideas I can get.

[Wingnut]

Hi gang!  http://www.babylonjs.com/playground/#10P0IP - Abusing the playground some more, in case anyone is bored.   This time I added some buttons, changed .diffuseColor animation to .scaling animation, and generally just got demented, as usual.  Is everyone about sick of this scene?  Me, too.  But I wanted to see if I could do hide/show editor buttons.  Having fun, causing trouble. 

 

Hey, I changed all my functions from...

 

function xxxxx() { ... }

 

   to

 

var xxxxx = function () { ... };

 

Deltakosh taught me that if you do it the second way, and define your functions before calling them... then you keep the functions off-of the WINDOW object and keep them within the scope of the scene... which is better.  You put the functions INSIDE-OF the createScene function, and again, you must define them BEFORE you make any calls to them, or you will get 'function not found' errors.  Thanks for the cool tip, DK!

 

I'll learn this Javascript stuff yet, I will.    Party on!

[Dad72]

the 2 methods have their usefulness and one is not necessarily better than the other.

 

The first is known as a named function where the second is known as an anonymous function. 
The key practical difference is in when you can use the sum function. 

 

For example:

var z = sum(2, 3);function sum(x, y) {    return x+y;}

 advantage :

1. The name "sum" shows up in the stacktrace which makes debugging easier in many browsers.
2. The name "sum" can be used inside the function body which makes it easier to use for recursive functions.
3. function declarations are "hoisted" in javascript, so in the first case, the function is guaranteed to be defined exactly once.

4. Semicolon insertion causes

 

z is assigned 5 whereas this:
 

var z = sum(2, 3);var sum = function(x, y) {    return x+y;};

 
Will fail since at the time the first line has executed the variable sum has not yet been assigned the function.
Named functions are parsed and assigned to their names before execution begins which is why a named function can be utalised in code that preceeds its definition. 
Variables assigned a function by code can clearly only be used as function once execution has proceeded past the assignment.

[Wingnut]

Hey Dad72, thanks for that information!  Nicely done!  Named functions, and anonymous functions.  Very good.

 

Well, here's yet another PG (playground) demo.  This time I am ONLY trying to illustrate positioning.  Have you noticed that we don't specifically teach .positions in our Basic Series tutorials?  We have a tutorial for rotation and scaling, though.

 

(Isn't it strange... how you can see a mesh's bounding box... through a textured plane?  hmm.)

 

This time, I hide the PG's jsEditor by default.  Dad72 pointed out that showing the new users lots of code in the editor window (especially when I need to use a bunch of dynamic html)... scares the new users. 

 

He's right.  Hell, it scares ME and I coded it. 

 

So, if I hide the editor by default AND maybe not allow them to turn it ON at all... then their attention will be on the scene itself.  And that's where I want it to be.  A picture is worth a thousand words, and I believe that this scene... teaches everything that the new user needs to know... about positioning.

 

In which tutorial will I present this scene?  Who knows?    Maybe in tutorial #00... which is still being written.  Maybe position should be combined with the scaling and rotation tutorial.  But then its title will be "Position, Scaling, and Rotation", and that's a pretty long tutorial title.

 

Anyway, I thought about remaking my grid() function... with the new LINES system.  And I thought about outlining my red box with LINES, instead of using redbox.showBoundingBox. *shrug*

 

I was hoping, by now, that somebody would have answered my begging in another thread... to make a really tight grid() function with a sleak FOR loop.  I wonder which BJS genius can write a nice re-usable grid() function, using LINES... in the least number of code lines?  (ahem). 

 

Hey, thanks deltakosh, for adding some lines to PG demo #2!  Cool!  That is how I tested to see if a 'lines' is treated as a single mesh object, and thus has a single .position, .rotation, and .scaling.  It does.  Tiz good, because a grid made of lines... can then be moved up and down the Y axis easily, if needed.  And an arrow made of lines, can easily be scaled, positioned, and rotated... useful things for an arrow.

 

Lines seem like a real handy thing, and I am going to play with them, soon.  But back to that lines-based grid() and arrow().  C'mon kids, let's see some functions.  Don't make Wingnut write the lines-based grid() and arrow() functions... they'll surely be bloated due to my weak math and poor FOR-loop expertise. 

 

And how about compass()... a lines-based, always-facing-camera thing... that tells us which way the activeCamera is looking?  C'mon hot coders... impress me... by writing some cool lines-based functions.  Hurry. 

 

I hope everyone is well.  Party on!

[Dad72]

You hairless make your grid like this:

var grid = BABYLON.Mesh.CreateGround("Grid", 100, 100, 90, scene, false);var materialGrid = new BABYLON.StandardMaterial("textureGrid", scene);materialGrid.wireframe = true;materialGrid.diffuseColor = new BABYLON.Color3(0.12, 0, 0.67);materialGrid.specularColor = new BABYLON.Color3(0, 0, 0);grid.material = materialGrid;

[Wingnut]

Yes, that method is well known, but that gives you triangles instead of squares.  And, its not easy to make a rainbow wireframe, where each line is a different color.    Thanks for the suggestion, though.

 

Actually, I suppose a person could set the colors of the vertexData for a ground mesh, if a person chose to.

 

I think I did a rainbow wireframe demo, once.  Watch it for some time... to see it change to wireframe.

 

Maybe you are on the right track, Dad72.  Maybe a grid of triangles will be all the grid that anyone would ever need. *shrug*

[Dad72]

Yes it's true, the grid of triangles. I wanted to do this once with that of carrer, but I find that it was heavy to do otherwise. me I prefer the possible shortest method that will sense doubt the fastest.

 

But your idea to do with line may very well by creating a function that you allow to create a number of column and line numbers and generate your grid.

[Wingnut]

Yeah, I agree...  heavy.  My grid() function uses thin strips of plane (so I can change the line width), and it definitely adds lots of polygons.  It has another problem, too.

 

http://urbanproductions.com/wingy/babylon/thruster/t26/flyer26.htm

 

Use 's' to back-out the camera until you can see most of the grid.  It sparkles... a lot.  Like a "jaggies" festival.    Yep, there is lots of problems with my grid of thin planes.  It is a poor way to make a grid, that's for certain.

[Dad72]

with CreateGround seems to be well, but it actually are triangles, but this isn't too lifeless I think, it's just aesthetic.

[Wingnut]

Hi girls!

 

    From the folks who brought you such classics as Insomnia and Indigestion...

 

...comes yet another training scene! http://www.babylonjs.com/playground/#2DJQVF#1. 

 

Teaching rotation, yee ha!  It just doesn't get any more exciting than this!

 

He was a torn man, desparate to decide whether or not to rotate the far "Z".  She was a lovely French librarian... with all the necessary credentials.  Passion, drama, intrigue!  Come see what critics are calling the feel-good scene of the year!  (snore)

[Wingnut]

Hi kids!  I have been working more on training scenes and on tutorial #00.  Here's another rough draft.  It is now 170 km long, and weighs more than a road grader.  *sigh*  Yep, give a talker... a text editor, and you're just ASKING for trouble.  And it is surely packed with WRONG things and things Wingnut just "made up" out of some fantasy.    Man, that's hard... dragging a newbie into Javascript objects and values.  Hard to teach... especially when I'm incompetent.  Comments welcome, as always, either here or in the Tutorial Talk thread.

 

https://github.com/BabylonJS/Babylon.js/wiki/Babylon.js-Primer

 

So, then... pffft... right in the middle of my profuse bleeding, both physically and mentally, which comes from writing tutorials about rudimentary 'stuff', friggin' Temechon writes a damned tutorial that just blows us all away!  What the hell is that all about?  Who would have thought that Temechon was not only a great API maintainer, but also a game coder that is willing to talk about how he did it?  Wow!

 

Mild mannered Julian Chenard, a reporter for the Daily Planet, suddenly becomes SUPER CODER-TEACHER-GUY!    That rotten son of a bi...  errr... I mean... wow, nice tutorial and toad game, T-Dog!  Cooooooooool!

 

Toads, huh?  Yuh yuh yuh.  NOW we know what T-Doggy-Dog is 'into'.  I hereby officially suggest that Temechon's new game... be named Toad Lickin'.  Yay!    It's fun for the entire family!  errrr... no, maybe that isn't a good name.

[Temechon]

Your tutorial is really great my dear Larry :==)

I know it will be useful for the newcomers, as the page structure is very well detailed, the links are very well presented, everything is super clear. I know Delta and Davrous will love your work, as the whole community is loving it

 

And thank you for your compliments, it goes directly to my heart <3

[gryff]

I have been working more on training scenes and on tutorial #00.

 

Wingy, one thing I would like to see are all your demos in a short thread with a brief explanation of each - there are 18 pages of the "Wingnut Chronicles" - hard for a newbie to find them.

 

cheers, gryff

[Vousk-prod.]

Yes, great job !

A very good beginner tutorial you did there WN.

I love the "Big Picture" idea to present every important parts.

[Wingnut]

  Mercy and pity applause!  I knew I could beg it out of you guys,  haha.

 

Just havin' some fun with you guys, of course.  I don't really care about being petted.  What I care about is making mistakes and/or looking foolish.

 

Nah, come to think of it, I don't care about those things either.     Hhmm, what is it I care about, again?  I forgot.

 

Oh yeah, making sure newbies get "launched" well.  Yep, ALL of our tutorials care about THAT, right?  Even toad lickers care about that. 

 

Gryff... umm... yeah... I'm honored that you'd care enough about all the demos in this thread... to want to centrally index them.  Some are pretty old, though.  Many used real old Babylon.js versions.  They show up on Google and forum searches when the right keywords are searched-for,  but I'll look-into the central index possibility just the same.  Keep in mind... that many of the demos in this thread... are "Here's something strange-looking" demos, and not necessarily training scenes.  If anyone were to look at the code and techniques in many of my early demos, they could easily learn the wrong or insane way of doing things. 

 

Yep, this thread is essentially "Babylon.js chat" so it gets long... especially with a yapper like me nearby.  Every community needs a cafe and coffee shoppe to spread gossip and vicious rumors within.

 

Party on, guys.

[Wingnut]

Ok Temechon, let's talk about your latest "thing".

 

See the way you make the ship?  What the hell is all that?  hehe. 

 

If you look closely at the ship-making point in the tutorial... there's a 4-way possibility there.

 

1. Just use a standard Mesh.CreateBox and avoid confusing users with a VertexData longer way.

2. Build the ship in the way you have done, casting a box shape onto a blank mesh, with applyToMesh and prototyping.

3. Take #2 further, and actually teach users to plot a basic ship. Full handhold tutorial on vertices, indices, UV's, normals, and colors.

4. Build a ship by assembling multiple basic shapes, and parenting them to a central 'gizmo'.

 

Temechon, how much do you think the new user knows about prototypes and vertexData and Ship "classes"?  Do you think your way of building a ship... could scare folk?

 

The playground, and my tutorial #00... are pushing the single-file method... just for ease of use for beginners.  I actually really like that your tutorial introduced class-making, and stored the Ship class in a separate file. You introduced them to multiple project files, and... you sort-of told them WHAT to put into those separate files (classes).  Cool.  That is another point of branching... where a whole other tutorial could be written about prototypes, supers, classes, and extending, etc.  Scary!  :/

 

Lastly, your references to The Fellowship of the Ring... are enjoyable.    Fun!

 

Wingnut - just thinking... yapping... quite aimlessly. 

[Temechon]

Hey Wingy, there are two points in your post : 1) the ship creation, and 2) the file method.

 

The notion of prototype is not the point of my tutorial : I assume the reader wants to know more about Babylon by knowing several notion of javascript. But you are right, this way could scare people... If there are some comments about it, I could create a tutorial about class and prototype

For the ship building : 

1) By using a simple box, all methods like move, initMovement would have been static functions, .... and I'm not fond of the functional programming (as you can see)

2) ok

3) I asked myself if I should stop at the box or go one with all the details (indice, positions, normals...). I didn't do it because this tuto was about Actionmanager, and with a lot of context (maybe too much?), I was afraid to lost my reader. Maybe in a next tutorial?

4) very good idea that I didn't have

 

 

About the file method, I believe a good practice is to have the javascript, css and html parts all separated. BUT a very beginner to javascript would rather have all his code in a single file (much easier to handle).

 

Thank you Wingnut for your comments, they are very valuabe for me

 

Cheers !