continued_at_new_forum The Wingnut Chronicles

[Wingnut]

Hey, cloning worked great!  Sweet!  Of course the wires sparkle somewhat, but we will call that a feature and not a problem.    It certainly makes entering indices numbers much easier.  Good job!  Hurray.

 

 

At first, I thought: bound2.scaling = new BABYLON.Vector3(1.001,1.001,1.001);   ...would make the sparkles clear-up, but since the bounder is a single mesh, it made the wires disappear on the insides of the brackets.  The wires quit sparkling on the outside of the brackets, though. 

 

This solution will work JUST FINE for my needs!  Good idea, DK!  Easy.  No fussing with bindAndDraw.  Yay!

 

While I have your ear (considering you are nearby), might you have anything to say about the numbers in the blue box... at http://www.html5gamedevs.com/topic/5204-a-problem-with-multi-viewport-screen-layout-positions/?p=31776 ?   (Lots of numbers in blue boxes happening in this post, eh?) 

 

Do those multi-viewport numbers (at that post) look correct to you, per what the demo shows?  The multi-viewport demo linked-to, there, is now correct per what I wanted to do... but those numbers in the blue box (there)... seem unexpected to me.  They don't make sense to me.  They work fine, but they seem illogical.

 

If you have some words or thoughts on those numbers, feel free to say them here, or in that thread.  (I prefer in that thread).  Or maybe do some tests on the framework and see if multi-viewports 'position layout' is behaving in a way that you think is correct.  It looks like MAYBE... multi-viewports positioning happens on a _gl level.  *shrug*  Maybe the framework doesn't have much control over how multi-viewports behave.  Thanks for that, and thanks again for the wireframe solution.  Coooool! 

 

Now, it's snow-blowing time again.  9 inches of fresh white stuff.  And here I thought it was spring.  (sigh)  :/

[Wingnut]

I was recently looking at BABYLON.VertexData, and wow, people (probably Deltakosh) grow things like my Bounder... using all JS math... much more dynamic than my way.  Cool.  I need to learn how to do that.  For example, the way babylon's sphere vertex positions are plotted... is nothing short of amazing. 

 

I'll learn it.    (with the help of some code-borrowing).  A person (like me) can save many hours of manual plotting... by learning how to do all my plotting with JS.  And I think Bounder would be a perfect project to learn how to do it.

 

Using JS to do all the positions plotting (and also the normals, indices, and UV's)... is how to make all those fancy, pretty polyhedra, too.  Earlier in this thread, we talked about Stemkoski's JSON database object.... packed with position numbers to make fancy primitives.  But a really powerful database of primitives... would be packed with JS algorhythms.  Our new 'repository' of vertexData... is not as much vertexData... as it is vertexData GENERATORS.  I love it.  I am going to learn how to 'generate' vertex data even if it kills me, because it is SO FRIGGIN' COOL!  Math formulas meets JS meets Babylon applyToMesh.  Yum!  (drool) 

[GameMonetize]

I look for new basic mesh ideas (I added TOrusKnot this time)

[Wingnut]

Oh my goodness!  People, if you haven't seen this wonderful post by deltakosh on his eternalcoding blog, drop whatever you are doing, and go see it right now.  You have never seen a torus knot like this, ever.  EVER.  I have done some raytracing in my time, but the 'shader chrome' that deltakosh put onto his new torus knot...  phew... it's just way way way beautiful!

 

And the post itself... is just packed with excellent knowledge and great diagrams.  Too cool!  Wow!  Go see this post.  Do it now.  You are going to crap a log.  I am going to borrow that chrome torus knot, get it rotating full screen on my home computer, and let it run for a week while I continually mop-up my drool. 

 

Way to go, DK!!!  Fantastic!!!  You don't build scenes very often, but when you do, man, they are planet crackers, for sure.  Alright!  MEGA-PARTY ON!

[Dad72]

You had not seen it? I have you talk here. This tutorial in the wiki came with version 1.11.  It's true that it's great.

 

 

[Wingnut]

Yes, i did see you mention the shader tutorial.  I did not have time to see it then. Last night, I was searching Google for Oculus Rift, so I could learn about that and write about it in the cameras tutorial.  That's how I first saw the shaders post. 

 

I wish I could play with shaders, but I have 5 new cameras to learn and write about.  Then, I need to adjust 12 more tutorials in the Playpen Series, and then convert all advanced tutorials into .md documents. Then, by the time I am finished with that... in about 4 months, 200 new features will have been added to BJS and I will start refreshing the tutorials AGAIN, from step one.  Very busy.  Lots to do.

 

I have put some hours into learning the new vertexData class, lately.  I will need to write about that, soon.  The mesh-to-mesh collisions tutorial needs better pictures.  That's coming soon. 

 

I don't know what is part of 1.10 and what is part of 1.11.  I have a flyerframe (Space Taxi/Lunar Lander) that is stalled due to my lack of knowledge of quaternions (I don't foresee EVER getting to work/play with that ever again), I have an Artillery Duel game that is stalled because of multi-viewports testing, and the physics engine needs a great tutorial and some simple, new-user demos.  (I was going to use that 'polyGUN' Artillery Duel mini-game to teach all about the physics engine.  A 'cannon' is the perfect way to teach 'cannon'.js, eh?  Learning with a smile.)    Few notice these fun word-play 'nuances'.  Mostly a language barrier problem.

 

The CSG system needs a tutorial and many more tests and demos. 

 

Post-processes needs a great tutorial. 

 

'Effect' needs a great tutorial. 

 

All the new 'inputController'-class things need a tutorial. 

 

Layer needs learning and a tutorial.

 

Multi-materials need better explaining.

 

Submeshes need explaining.

 

(I could go-on for hours.)

Lots of work ahead, to try to reduce the amount of forum questions.

 

I think Temechon has commited suicide from trying to keep-up with the insanely fast-moving Sokrate API.  I probably need to fly-in to where he was last seen, and see if he needs food, water, a psychiatrist, and a thousand hugs.  Xanmia has evaporated, gryff has evaporated, Gwenael is elusive and may need rescue.

 

I got SO much to do, I may explode.  BJS is really quite new to the USA, and it is wonderful, but it is changing SO FAST that few Americans (and likely many nationalities) are getting time to be introduced to the basics, including me.  I see function names that are English illogical, and question them, and get few well-explained answers.  The answers I get are... "Other engines do it that way", and "that's how Blender does it" and "too much trouble to change it now".  None of those answers help me teach... in the tutorials.  If I write the tutorials wrong, THEY will generate forum questions, too.  And forum questions is what I am trying to eliminate... by writing great Playpen Series tutorials.  So, I have a chance to "hang myself" in this area.  Fun!

 

The forum activity is exploding with questions, and it is because Wingnut is TOO SLOW at making better tutorials.  See why I am begging for help (from neoRiley, and gryff, and xanmia, and you)?  I am falling behind, while the forum goes crazy with new (and often repeated) questions.

 

And now you want changes to the physics system?  Heck, nobody has written even a first tutorial about it, explaining force vectors and contact points and gravity and friction and mass and imposters.  Yes, trailblazing and innovation and trying to keep-up with Blender changes... is BIG FUN... for some.  For tutorial writers who barely know how to make boxes... it is a different kind of 'big fun'. 

 

But yes, the chrome-sim shader sure is pretty, and it is a fine document telling about it.  That is one part of BJS that I will not need to re-explain... maybe.

 

I don't think that document has been tested in Firefox though, as I see a big, blank green panel next to the canvas.  I hope someone else troubleshoots that.  Likely some anomaly with the CSS of the ACE editor.

 

Be well.

 

PS:  DK, would you consider making larger, bolder, and/or more-color-contrasted fonts for the bottom section of the BJS main website?  For these...  sandbox      forum      wiki      github      documentation  .  Thanks!  I think they need to be more obvious.  I'm sure others will argue with me, though.  What's new?  Lately, i seem to bring out the very best in people.    Also, DK, you might want to put a 'date' inside your new 'announcements' so it doesn't look like BJS 111 came out on Jan 19th.  Right now, it looks like an old announcement, when in fact, it is very new.  *shrug*

[GameMonetize]

date: done

larger links for babylon.js footer: done

[Wingnut]

Thanks, DK! 

 

Hey DK... did spotLight, directionalLight (and maybe HemisphericLight)  ...  .setDirectionToTarget ...still have some problems?  ( I called it setDirectionByTarget, earlier, but changed it this time ) 

	function setDirectionToTarget(target) {		this.direction = BABYLON.Vector3.Normalize(target.subtract(this.position));		return this.direction;  // remove this line if wanted.	}

Is it broken, or decided not-needed or wanted in 1.11?  Later versions?  Thoughts? 

 

I still need to add that extra section in the lighting tutorial... 'More About Directions'.  I figure .setDirectionToTarget(target) would help in that area.

 

SpotLight and DirectionalLight, mainly.  Maybe HemisphericLight too. 

 

I have never tested if aiming a hemisphericLight toward the eastern skies in the mornings, and aiming toward the western skies in the evening... had any affect on the scene.  It might not make much difference... but hemisphericLight DOES have a .direction, so, might as well put .setDirectionToTarget() on all three lights.

 

We COULD use light.shineAt() too.  ?  (erf)  (Let's not)  :X  <= Wingnut's mouth taped shut. 

 

camera.lookAt()

mesh.faceAt()

light.shineAt()

 

perfect.  hehe.  Just shoot me. 

 

DK, you forgot all about setDirectionToTarget() for BJS 111, didn't you?  SO concerned about that goofy Oculus Rift thing that you left your good buddy Wingnut standing out in the cold, huh?  His first-ever potential contribution of code to the framework...  a big one-liner... where Wingnut could proudly wear his "I Contributed To Core" badge, and strut around town bragging about it, and you left him standing in the street, naked, dirty, and alone, instead, eh?  Nice.  hehe.

 

I already had the "I Contributed To Core" badge, flag, and T-shirt graphics... fully designed and ready to send to the printers.  I'll just burn it all now, and crawl into my closet and cry.  haha.  (just kidding, of course).

 

We could maybe think about .lockedtarget, too.  (double 'erf' with whipped cream topping)    mesh or Vector3.  Light will lock-on to an orbiting mesh, or orbiting light will lock-on to a [stationary] mesh.position. 

 

An orbiting spotlight could stay locked-on to an orbiting mesh.  Wow, huh?  And because camera.lockedtarget allows light.position or mesh.position, it could lock-on to either.  So... an orbiting camera... could be locked-on to an orbiting light...  which is locked-on to an orbiting mesh.  Cool! 

 

I bet you are starting to see how using .direction on lights... is pretty goofy (not dk's idea, of course).  Cameras don't use .direction.  Why do lights?  I think... lights and cameras should BOTH use .rotation (and .target/.lockedtarget).  That would have been SO much more consistent and standardized. 

 

Again, it's not dk's fault.  Someone long ago decided that lights needed .direction and cameras needed .rotation.  Goofy, in my opinion.  There is probably a logical reason... which I am too newbie to understand.  Oh well.  Everything is fine.    Lock on!

[GameMonetize]

Yes I forgot to add it. But I will definitely do that for next one

[Wingnut]

Hi gang!

 

   Somewhere I read... that one material... can only accept 4 lights.  I set out to prove them wrong with this new demo.  The zipped version is available, too.

 

15 lights on a single material!  What's that you say?  You claim I am lying?

 

Okay, okay, I AM lying.  There is really only two lights.  One hemispheric... keeping it from being pitch black, and one spotlight attached to the box, flashing on and off at "fool the viewer" places and times.    It is all part of the fun... of babylon.js!

 

PS: Congrats on the BabylonJS 1.11.0 official release, deltakosh and contributors!  Well done!  I used it in the above demo, and it is working like a charm.  I look forward to discovering and exploring its myriad of great new features.

[Wingnut]

Ok, here we are, safe and sound, back in low orbit around The Wingnut Chronicles planet.  (I know better than to leave orbit and fly through asteroid fields.)  heh.

 

Today's cool demo (and a zipped version) is not my work at all. It is the zip that comes with our Standard Series #10 Collisions Tutorial.  (Although I adjusted it slightly.)  Mouse wheel adjusts cam.radius.

 

When I first saw the picture at the top of that tutorial, I thought it looked strange.  "What am I seeing?  What does this picture show?  How did this author show bounding boxes long before we had a .showboundingbox property?  How did they show the 'non-precise' AABB bounding box on the left plane, and how did they show the 'precise' OBB bounding box on the right plane?  Who made this picture and how was it done?"

 

Well Mister Wingnut finally gathered enough intelligence to download the zip file linked-to at the end of the tutorial.  And there it was.  Much more explanation.  The "balloon" balls were animated... and they turned red when they collided with another mesh.  "Ahh, I see.  Now I understand the picture."

 

And the AABB and OBB bounding boxes?  Yep, faked... using wireframed meshes around non-wireframed meshes.

 

But I found more things in this demo.  Fascinating things.  Plane 1, the left plane, the AABB plane, was rotated to a 45 degree angle... using: rotation.x = -Math.PI / 4;  No big deal.  We have all seen mesh rotated with PI before.  Now for its fake bounding box:

var planAABB = new BABYLON.Mesh.CreateBox("AABB", 20, scene);planAABB.scaling = new BABYLON.Vector3(1, Math.cos(Math.PI / 4), Math.cos(Math.PI / 4));

Wow!  I have never seen anyone use PI and COSINE... to scale anything.  Newbies like me would have looked at the box from every angle, trial and error, adjust adjust adjust... until the box properly wrapped the angled plane.  But not the math-savvy author of our collisions demo. He/She knew... that if the plane was rotated Math.PI/4, he/she could scale the bounding box with Math.cos(Math.PI/4).  That... is just way too cool, in my opinion!

 

One would think that this is plenty of cool cosine usage for a single demo.  Any more, and a newbie's brain could pop from too much coolness.  But nope, our math-smart author was not done yet.  See the way the animation of the balls... slows when it reaches the top and bottom of their translations?  Sure ya do.  That ease-in and ease-out stuff is real nice.  You can't help but notice it.  And how is it done?  You got it.  More cool cosine usage...

	alpha += 0.01;	balloon1.position.y += Math.cos(alpha) / 10;	balloon2.position.y += Math.cos(alpha) / 10;	balloon3.position.y += Math.cos(alpha) / 10;

Wow 2.0!  TWO cool uses of cosine, and a fine collisions demo, too.  What a fun and smart demo!  Thanks, author!  (not me)  Party on!  Watch out for collisions... especially with asteroids. 

[Wingnut]

Hi Gang!

   Uncle Wingnut back again with yet another demo, and the zipped version.  This is a live particleSystem editor.  It is not wonderful, but it is something to play with.

 

A couple things you should know.  First, about left and right cursors.  Click on the canvas... to make left and right cursor arrows.... control the camera.  Click over in the input area, to make left and right cursors work in the input boxes.

 

You must press ENTER after you change the value of an input box.  If you hit TAB to leave an input box, you did not activate the change, and you will need to go back and hit enter to activate the live change.

 

Color3 or Color4 are fine.  Avoid using Math.PI and Math.random() in the input boxes.  Unexpected results may occur.  I am working to figure out why. 

 

blendMode input box accepts 0, or 1, or BLENDMODE_ONEONE, or BLENDMODE_STANDARD (yawn).

 

I provide a few textures in the ./textures folder. Included local textures are circle32.png, flake.jpg, flare.png, smoke.png.  Zoom-in or turn-up the maxSize... to see them well. The particleTexture field can also use a standard web URL to a particle texture.

 

This uses a Vector3 at 'origin' (0,0,0)... as the emitter, not a mesh.  The camera is quite far away. Feel free to fly it in closer, but if the camera won't fly with the cursor arrows, be sure to click on the canvas.  Then it should cursor / arrow fine.

 

Also, for Windows users, control-z works pretty good.  UNDO on other platforms may work fine, too.

 

Lots of 'debris' in the code.  This is not really finished... but it might not be worked-on further... until much later.  Feel free to advance this project and release it as your own.  My code is your code.  Have fun!

[gryff]

Nice Wingy

 

Funny, I was thinking about something just like this this last week - as I have never been able to see what a particle setup looks like from just the numbers. There was a guy in Second Life who had a really nice setup for doing this kind of thing.

 

When I was thinking about it, I thought it would be nice to use sliders (I'm not a typist, more a mouse person)  - but then I realised all those "Color4" and "Vector3" parameters would require a whole lot of sliders.

 

Really great. It should get more prominence because as the "Wingnut Chronicles" grow, this will get buried and hard for a newbie to find. Maybe a link in the particles tutorial or a post of its own on the forum?

 

cheers, gryff

 

Edit: Ooh and I got a nice surprise yesterday - a Firefox Update - and now I can open its web developer without it crashing while viewing WebGl content and can open the babylon sandbox without a lot of crap where the large white area is.

[Wingnut]

Thanks gryff, and hi all. Yeah, my stuff gets buried, but someday, I'll make a huge zip with all the garbage in it.    Plus, Google search does a pretty good job of finding various topics that are buried in this thread. That's because I talk so much.  Google sees my yapping, sees me mention a term like "particle" a bunch of times, and boom, I'm somebody (yikes). 

 

Gang, lately I have been thinking about canvas gui... like our virtual joysticks system.  Those joysticks are pieces of canvas overlayed atop our normal webGL canvas.  They use SVG-like drawing things (scalable vector graphics) (canvas painting).  Here is their source code.  Down in the drawVirtualJoystick() function... lots of SVG-like commands.  It is some interesting code.

 

At first, I went searching for XUL, the xml-based GUI-making system used for Firefox's GUI widgets.  Then I went searching for XAML, a XML-based markup used for WPF (windows presentation foundation) (another way to make gui widgets).

 

Then I found this... http://www.zephyrosanemos.com/

 

This guy named Stavros is really fun and has taken webGL canvas GUI to a whole new level.  Run that live demo.  It's amazing.  It is all powered by a big fat quad processor behind the scenes, but, still, wow.  I was looking to build a "dashboard" that people could easily put buttons and readouts upon, but this guy has gone well beyond that.  His system is a real fine canvas-based GUI.  It is NOT pure JS, though.

 

After wiping up the drool from seeing Stavros's stuff, I am still thinking about a "virtual dashboard" for basic buttons and readouts... for BJS.  Davrous wrote our virtual joysticks system, so maybe I will beg him to work on the virtual dashboard system.  I suppose we will need a "widgets" library of some kind.  I would love to see the buttons have outset borders, and then switch to inset borders onMouseDown... to make them look "depressed" when they are clicked.  And I would love to see font-adjusting power equal to CSS-grade font power.

 

Who remembers 'ismap' from back in the 2D days?    I guess they are just <map> and <area> these days.  It relates to this.  Clickable areas on an image.  We might be able to use that for something.  But clickable areas on image maps... tend to NOT allow you to "cave-in the button" when it is pressed (change button border from outset to inset, and back again).

 

But all of it... means stealing processing power from the scene... and that might make the whole idea... rather troublesome.  And, of course, we would want the GUI to be touch-events ready, too.  Pick meets Touch - the new frontier of BJS events.  Maybe they will fall in love (I doubt it). 

 

Speaking of pick meets touch, a person COULD make their buttons... out of mesh, and parent them to the active camera, so that the buttons stay with the camera as it moves.  That would be an interesting type of dashboard.

 

  Thinking thinking thinking.  Comments certainly welcome.

[gryff]

Interesting demo - but unlike the pics at his site - I only got 8-9 fps.with and intel I5 quad (but no hyperthreading)  and a Nividia GTX650. Mind you one of the little screens did seem to indicate 400,000+ "visible triangles" which is quite a load.

 

I think you have been reading my mind as I played around with a number of possibilities

 

1. In <div> tags - hide or show with keyboard input worked ok though not fancy graphics.

 

Who remembers 'ismap' from back in the 2D days?

 

2. Also looked at that   There was a little utility that allowed mapping of an image - can't remember the name.

 

Speaking of pick meets touch, a person COULD make their buttons... out of mesh, and parent them to the active camera, so that the buttons stay with the camera as it moves.

 

3. Could be an interesting way to create certain features - speedometer, tachometer, compass - with moving hand/pointer. I tried  it but ran into issues with the lighting as the "Free Camera" moves around. Maybe you would have to "exclude" those meshes from most of the lights and maybe give it its own light. Could get complicated.

 

cheers, gryff

[Wingnut]

hehe.  Gryff, you're interesting as hell, ya know?  You have cool ideas.   Yeah, as far as the Stavros GUI demo, I didn't get framerates worth a crap, either, but it sure is pretty GUI.  It tells of some possibilities, that's for sure.

 

Ok, it's time for yet another demo... and the zipped version.  This is a virtual joysticks demo... a red one on the left side, a green one on the right.  It was easy to make a pair of virtual joysticks (VJ's) for my own use.  After fooling around with them for awhile, I learned that they output values via VJ.deltaPosition property... or more specfically, VJ.deltaPosition.x and VJ.deltaPosition.y.

 

So, I have two joysticks... each producing x and y values... so I had 4 values that could be hooked-up to SOMETHING.  So what did I decide to hook them to?  Yep, a torus knot... our newest babylon.js 'primitive' shape. 

 

There are 4 'values' that seem to have lots of affect on a torus knot.  They are radius, tubing size,  P-factor, and Q-factor. The constructor for a BJS torus knot... looks like this:

BABYLON.Mesh.CreateTorusKnot(name, radius, tube, radialSegments, tubularSegments, p, q, scene, updatable)

But guess what.  Once you create a torus knot, there is no .radius, .tube, .p, and .q properties.  Apparently Deltakosh didn't think that anyone would be crazy enough to dynamically modify an already-created torus knot.  Or maybe he just hasn't had the time to flesh-out this primitive. 

 

So... everytime I saw a change on a VJ, I had to dispose() the old torus knot, and re-create it... using the new values.  No problems, but it added a tiny bit of weight to the code.

 

I put a 'holder' object on the the torus knot.  Then, when it was time to update the torus knot with the new VJ values, I removed the holder just before I did the dispose() on the old torus knot.  Then I created the new torus knot with the 'different' values than the old one.  Then I stored the new values in the holder, and put the holder onto the NEW torus knot  (in it's .holder property which I created myself) (ain't JS great?).

 

All in all, this uses a standard arcRotateCamera which can be cursor-arrow controlled and mousewheel zoomed.  The scene has an active VJ to the left of the torus knot...  that controls the radius and tube size, and an active VJ to the right... that controls the P and Q factors.  And, this demo is likely touch-events ready, so if you have touch-ready portable devices, give it a try there, too.

 

As far as determining "WHAT THE HELL IS HAPPENING?" ... when you adjust the P and Q factors with the right virtual joystick... I have no idea.  You'll see some strange tearing and mesh retardation... but I think that is normal for a torus knot.  I think... the P and Q factors might be a ratio.  You can learn lots about minding your P's and Q's right here.  My initial torus knot was constructed like this:

var ts = BABYLON.Mesh.CreateTorusKnot("ts", 4, 1.5, 256, 16, 3, 5, scene);

Deltakosh constructed his fancy ray-tracy torus knot like this:

var mesh = BABYLON.Mesh.CreateTorusKnot("mesh", 2, 0.5, 128, 64, 2, 3, scene)

Of course Deltakosh needed a higher tubularSegments number because he had a fancy chrome torus knot.  It needed nice linear reflections.  Mine is a low-rent-district wireframe torus knot.  And we all know that wireframe and flat shaded things... look cooler when they are low face-count.    (poly-unsaturated)  (ar ar ar!)

 

Ok, enjoy the demo, use the code, and don't blame me if your computer blows up.  Party On!

[GameMonetize]

Alas there is no efficient way to update a torus (or a box). You are doing the best thing: dispose and recreate

[GameMonetize]

Actually there is perhaps a way: create the Knot as updatable (the last boolean) and each time you want to update it, just use VertexData to create a new geometry and call mesh.updateVerticeData with new position

 

Am I clear?

[Wingnut]

Thx Dk.  Yeah, I understand, you are being clear.  I have never tried that before, and I don't know that the efficiency gain would be much improved.  But that would be a way to do it without a dispose().  hmm.  Interesting.

[Wingnut]

Hi gang!

 

Man, the tests and demos are coming fast, lately, yes?  You betcha!  This time, it is more of a test.  In this test, (and its zip version)... I am testing if there is ever a use for tilting a hemisphericLight.direction.

 

A few posts ago, Deltakosh and I were talking about the future helper function for lights... called setDirectionToTarget(target).  It has already been installed on spotlights and directional lights.  (Thank you, Deltakosh!  Feel free to remove the last line... 'return this.direction' if you think that is wise.  No problems for me.  Do what is smart... for that.)

 

There was some question... as to whether or not hemisphericLight.direction ever needed tilting (sun-following).  Most times, a HemisphericLight.direction is simply set to Vector3(0,1,0)... straight up.  Under most circumstances, there is no reason to do any fancy direction settings.

 

Hemispheric lights are supposed to simulate cloudy skies, I hear (thx gryff).  They use a 'direction to the sky' and not a 'direction to the sun'. 

 

So, I decided to test... what happens if you made a hemisphericLight.direction...  follow the sun instead of aiming straight up toward the sky.  Does the scene look any different when the sun is rising in the east, or setting in the west?  Was there EVER a need... to tilt the .direction... of a hemispheric light?

 

Well, I say there is.  Look at the specular highlights on the mesh as we follow the sun across the sky.  A hemispheric light has no .position and no .rotation... but it does have a .direction... to the sky... or maybe... to the sun.

 

IF we DID put a setDirectionToTarget() on the hemispheric light... it must be slightly different.  There is no .position.  The function must look something like this:

HemisphericLight.prototype.setDirectionToTarget = function (target) {    this.direction = BABYLON.Vector3.Normalize(target.subtract(new BABYLON.Vector3.Zero()));    return this.direction;};

(Again, remove that 'return' line if you think that would be wise, DK.) 

 

Where this light uses 'new BABYLON.Vector3.Zero()', the spotLight and directionalLight use 'this.position'.  Again, the hemispheric light has no .position property, so we use 'origin' zero().  That is what was used in the above test... to follow an invisible sphere across the sky.  The arrow is tracking it, using mesh.lookAt(sunsphere).  Users/admin... feel free to grab the zip, edit the source, and make the sun visible.  (What power you have!) 

 

Now, what are the chances that anyone will EVER use hemisphericLight.setDirectionToTarget(the sun)?  Probably quite low.

 

So, I don't know.  I am still on the fence (undecided).  I vote... hmm...  umm... I don't know.  I think maybe...  hmm... maybe yes, put the setDirectionToTarget(target) on the hemisphericLight also, if everyone is cool with that. 

 

Can we afford the bloat?    Feel free to over-ride my vote without remorse, DK.  My feelings will not be hurt whatsoever.  But tilting a hemisphericLight.direction... does indeed affect the scene, so, there is some merit, justification, and substantiation (but tiny)... to the adding of the function.  Maybe.    I don't know.  *scratch scratch*

 

It is a goofy-looking test demo, isn't it?  I laugh at it quite a bit.  It is quite ugly.    Party on!

[gryff]

Interesting

 

cheers, gryff

[Wingnut]

hehe, why thank you, Gryff!  I think so, too.    I got to use my new racing arrow.  Its got souped-up color data in its source code.   Scroll down into the colors section.  See them 3.3's in there?  We don't screw around with 0-1 colors... we use the 0-5 colors.  (In BJS, you can set Color3(0-5, 0-5, 0-5)... for extra color horsepower.)    The arrow was kind of dark until I beefed-up the color powers.  But shhhh... don't tell Deltakosh about the 0-5 color powers... because I like them.  He might try to make them be 0-1 again... and take away our secret anti-drab weaponry. 

[GameMonetize]

You can just use 

BABYLON.Vector3.Zero()

 instead of 

new BABYLON.Vector3.Zero()

 And btw this function is cool. It will be in the next version of babylon.js!

[GameMonetize]

extract of the upcoming what's new:

 

 - ```setDirectionToTarget``` function added to SpotLight, HemisphericLight and DirectionalLight ([Wingnutt](https://github.com/Wingnutt))

[Wingnut]

Thanks DK!  I actually found the 'subtract' part of the code... on the web somewhere.  But that normalize...  that I found with pure sweat and hard coding.  hehe.  (Thank goodness someone around here created a normalize function for me to 'find').

 

I did very little to make the new function happen, but I'm going to shine-up my "I contributed code to BabylonJS" badge just the same, and maybe go hit the local bars and brag.    Maybe I will get some 'action'.  "Yep, that's right, darling.  That badge means I'm a superstar (in my own mind - shhh).  Wanna touch it?"  heh