Tutorial Talk

[gryff]

@Wingnut:

 

1. Type in some text you wish to use as the link description eg : My Link or Lights Test or Camera Test etc.

2. Hightlight the text you have typed in with your mouse.

3. Now click on the link icon (looks like a chain with a + added - two buttons over from the add image button)

4. Paste your URL into the box and hit OK.

 

Nothing fancy - but I use it because I hate long drawn out URLs

 

cheers, gryff

[Wingnut]

Thanks, gryff!  Cooool!

 

On another subject, I think davrous did a real nice job on the youtube video presentation!  Check it out, forum readers.

 

"I have a fun job, so you will have to kill me if you want my job" haha!  Ol' davrous does not smile very often, but he smiled when he said that.    So did we.

 

Is that you in the front row, deltakosh?

 

No news on tutorials, lately.  I am going to study cameras carefully, soon, so I can see if there are any weaknesses in tutorial #5.  I think it is a bit short.    I can lengthen it with ease.  heh

 

I have never had any problems or confusion with cameras, so far.  Fellow users, if you have had confusion using cameras, please tell us about it here, soon, so we can improve tutorial #5 if/where needed.  Thanks!

 

I am thinking about adding sections about keys, moveSensibility (moveSensitivity), angularSensibility, fov (field of view), inertia, and speed. 

 

Aside: I don't think ANYONE in my country... uses the word 'sensibility'.    It is a 'legal' word, but, most often, we say sensitivity.  It is probably one of those 'too late to change' things, though.  In America, I think the word 'sensibility' would be used to describe a person's ability to have/use good sense (wise, fore-thoughtful, logical, careful, etc).  On the other hand, 'sensitivity' is used to describe gentleness, or fine-ness, or coarseness, or amplification, etc.  For example, I think spotlight.intensity is not able to dim a spotlight enough.  It is low on sensitivity.  It needs more power... more 'beef'... less gentleness. 

 

It needs more power to reduce the power of a spotlight.  It has TOO MUCH power to melt my meshes and burn brown spots onto my canvas.  heh

 

Back to tutorials (ahem), I may also try to explain alpha, beta, radius, and their limits... for ArcRotateCamera.  I think maybe omit ortho, minz, maxz, oculus, and touch.  That is for the 'advanced camera tutorial'.   Or maybe best written by the young and mobile people. I am a desktop man. 

 

Maybe...  camera.setKeys( up: 87, down: 83, left: 65, right: 68);  ??

And maybe even... camera.setKeys( up: [87, 38], down: [83, 40], left: [65, 37], right: [68, 39]);  ??

 

Darn, now I have gone off-topic.    Okay, about tutorials... (yeah, right, Wingleberry)

 

Does anyone know why there is a setPosition() method on arcRotate?  There is no setPosition() method on freeCam.  What is the difference (from a user point of view)... between setting the .position property, and calling the setPosition() function?  *shrug*  Comments quite welcomed.

 

I have much to learn and test, so ignore me, as wanted.    Take care!

[Xanmia]

I have yet to use the setPosition on it, I keep setting a target instead... I think an explanation on the alpha, beta, and radius would be great, since at first for me it was a little confusing.

[gryff]

I think davrous did a real nice job on the youtube video presentation!  Check it out, forum readers.

 

 

 

Yes he did. But, but, but ... now I want to know more about using Octrees. Any tuts, examples etc anywhere?

 

cheers, gryff

[Wingnut]

http://en.wikipedia.org/wiki/Octree 

 

Oh, by the way, once you have it figured out, and have coded 20-30 BJS demos using it, would you be so kind as to write a tutorial in GitHub markdown format, for us?  Yes?  Cool!  Thanks. 

[gryff]

Any tuts, examples etc anywhere?

 

 

I guess the answer Is No!

 

would you be so kind as to write a tutorial in GitHub markdown format, for us?

 

 

Er ... well, I'm still a rookie at this - not sure I would trust any tut I wrote . And as for GitHub markdown format - not even sure I know what that is ;-)

 

cheers, gryff

[GameMonetize]

Hey, good to know for 'sensibility'

[GameMonetize]

ArcRotateCamera need a setPosition because it computes its position using two angle (alpha and beta) and a radius because this camera moves on a virtual 3D sphere around a center

[Wingnut]

Hi gang!  I have been thinking about, and testing, the hemispheric light .direction (to the sky) property.

 

In the lights tutorial, just before the spotlight section (at the bottom of the 'Note' section that teaches more about .direction), I said this...

 

"This information applies to all babylon.js lights that use the direction property."

 

Well, that is wrong for hemispheric lights, I think.  With the directional light, you can set .direction to aim at a mesh.position, and it lights that mesh, if the .direction is NOT (0,0,0).  The same is true for spotlight.direction. Now for hemisphericLight...

 

Imagine hemisphericLight.position (0,20,0). User wants light to aim at a mesh with position (0, -1, 0).

 

So, user sets hemisphericLight.direction to (0, -1, 0) to light mesh below the light.  Since .groundColor is default Color3 (0,0,0), the mesh will go dark.  User sets light.direction to aim UP (0, 1, 0), and mesh lights-up.  (Opposite of the way directionalLight and spotLight work).

 

With hemisphericLight, user sets .direction away from light, to make the mesh below it... get light.

 

crap, crap, crap, crap, and darnit!

 

So my line should read...

 

"This information applies to all babylon.js lights that use the direction property, except for the hemisphericLight, which essentially operates opposite of this."

 

Or maybe... hmmm.

 

"This information also applies to spotlights, which is the next light that we will be learning about."

 

Or maybe...

 

"This information also applies to spotlights, which is the next light that we will be learning about.  The .direction property on our hemispheric light, essentially works opposite."

 

SIGH! 

 

Am I making sensibility? 

 

We need to invert-y on the light, so that a user can set hemisphericLight.direction to aim at a mesh.position, but the bottom side, opposite side, far side, back side, etc (of the mesh)... would be lit in the color that is now .groundColor.  (and maybe we rename .groundColor to .backsideColor or maybe .backColor) .

 

Doing this, would make h-light be much easier to teach, and .direction would be consistent with other light .directions.  Thoughts?

 

Yeah, I know, I know.  Backward compatibility.  *sigh*.  But dk, SIGH!  The framework is SO NEW.  It seems that there was no time/chance to "wring out" the api.  Don't you feel handcuffed by this backward compat strife?  It seems to me... that one year of 'shakedown cruise' (test driving) is needed and normal... before an api should get frozen.  I wish you could tell us what these "big projects" are... that keep us/you from adjusting the hemispheric light.  (No, not by adding an optional invertY parameter to the constructor).    Let us know who/where these big projects are... that need this backward compat SO MUCH, and let me go in there and show them how to do search/replace in their code editors.  C'mon! 

[GameMonetize]

What do you suggest ? Renaming direction to directionToSky ?

[Wingnut]

@dk, no... but we have good news.

 

Today, I had to make a trip, and I drove and drove and drove my little truck, and I am thinking and thinking...  "What hemisphere?  Where is the hemisphere?  What is the purpose of this light?  How does it act?  WHAT HEMISPHERE?"

 

And then suddenly, the skies lit up (pun intended), and it all became clear, and I smiled and laughed a little, and I wanted to give deltakosh a big hug.  Why? 

 

Deltakosh REALLY wanted to name this light...  Atmospheric light!  Yes?  The direction to the sky... that now makes perfect sense.  The .groundColor... makes perfect sense.  The way the light operates.... now makes perfect sense.

 

I am correct, yes?  (God, I hope so.)

[gryff]

What hemisphere?  Where is the hemisphere?  What is the purpose of this light?  How does it act?

 

....

 

The direction to the sky... that now makes perfect sense.

 

 

 

The definition of the Hemi light as it applies to Blender which can be exported to babylon.js:

 

The Hemi lamp provides light from the direction of a 180° hemisphere, designed to simulate the light coming from a heavily clouded or otherwise uniform sky. In other words, it is a light which is shed, uniformly, by a glowing dome surrounding the scene. What makes the Hemi different is that it does not have a shadow. It cannot cast a shadow and so all of the light coming from it is very soft and makes an excellent fill light.

 

 

 

 

cheers, gryff

[Wingnut]

Hunh, well I'll be darned.  Thanks gryff.  Here I thought I had made some kind of magic discovery, but nooooooo.  I guess I should take Blender for a drive one of these days.  Well don't I look the fool, eh?  Nothing unusual there. 

 

http://wiki.blender.org/index.php/Doc:2.6/Manual/Lighting/Lamps/Hemi

 

No .groundColor or similar, either.

 

I found this... 

 

http://forum.unity3d.com/threads/149575-Hemispheric-Ambient-Lighting

 

He mentions an up and down color.

 

And here...

 

http://www.pixelnerve.com/v/2012/03/17/shader-hemispherical-lighting/

There it says "Technically it just blends between two colors defined as ground and sky."

 

In 3d Max, I see a "skylight" and a Mental Ray "sky portal", but neither mention a groundColor, so I do not think those apply here, or at least not perfectly accurately.

 

Here is our code:

 

BABYLON.HemisphericLight.prototype.transferToEffect = function (effect, directionUniformName, groundColorUniformName) {
        var normalizeDirection = BABYLON.Vector3.Normalize(this.direction);
        effect.setFloat4(directionUniformName, normalizeDirection.x, normalizeDirection.y, normalizeDirection.z, 0);
        effect.setColor3(groundColorUniformName, this.groundColor.scale(this.intensity));
};

 

Over my head. Dk, can you tell me if a "blending" is happening in our code, or maybe at the GL shaders somewhere beneath?  And would a user even CARE if a blending is happening?  Maybe not in the 'basic series', anyway. 

 

I guess my next question would be...

In babylon.js, does the .groundColor have any affect on the rendered colors of the hemi-light diffuse and specular?

 

Reworded...  if you set a hemilight.diffuse of blue, and then set a .groundColor of red, does the blue get some red added, when rendered?

 

I will also run some more tests on it... see what I can determine. Thanks again, gryff and deltakosh.  Sorry if I am being a pain in the butt, but I want to teach and word this accurately in our tutorial.  Blend on!

 

Update:  I built a little test to see if togglling .groundColor from red to black, would affect the blue of the light's .diffuse.  (to see if blending of ground and sky color was being done).  I see no change in the blue, when the red groundColor toggles on and off.  Zipped version is there, too.

[Wingnut]

Hi gang.  Minor adjustments have been made to the hemispheric light section.  Some talk of cloudy days and soft lighting.  I mentioned that this light cannot produce shadows.  If that is incorrect, somebody please correct me. 

 

Currently, I think the directional light is the only light that can produce shadows, and the point light is the only light that can produce flat shading.  We have told the user that only directional lights can produce shadows... via tutorial #17 about shadows.  As far as I know, we have not yet told users that points lights are needed for flat shading.  (Also, I am about to go through the shadows tutorial and fix a spelling mistake... and maybe some other simple things.)

 

Flat shading is not a materials thing.  And mesh.convertToFlatShadedMesh  (maybe better named .convertToFlatShaded)  ... is not really a lighting operation.  I am not sure where or how to teach flat shaded procedures.  Maybe... insert a line in the point light section:

 

"Point lights are the type of light used for lighting mesh that have been converted to flat shaded."

 

But, I can understand if a user would think that flat shading... is a materials operation, and they may mistakenly look there for info about flat shading.  Thoughts?  Thanks!  I hope everyone is well.

[GameMonetize]

For flat shading I do not agree, all lights could produce flat shading. This is not related to light but to how I compute normals

[gryff]

Some talk of cloudy days and soft lighting.  I mentioned that this light cannot produce shadows.

 

 

 

@Wingnut: That is my understanding of how the hemispherical light performs. I think of the "Sun" lamp/light as a plane that emits rays of light perpendicular to its surface so all rays are parallel - so light only strikes the faces of a mesh facing the light.. In the case of the "Hemi", we can apply the same principle - at each point on its surface it emits a ray of light perpendicular to its surface- but the surface is spherical so the rays of light are now striking a mesh  faces from all angles and are not parallel - so they fill in the shadow areas.

 

However, I still can not get my head around the exact functionality of this "groundColor" property/parameter. I've been trying some experiments - but no results that make any sense.

 

And I see flat shading as a property of the geometry not the material - compare to the creaseAngle parameter of an IndexFaceSet (mesh) in VRML.

 

cheers, gryff

[Wingnut]

Thanks gryff, that makes sense.  The hemi light certainly seems to act just that way.  Thanks for your input on that.

 

Deltakosh, I understand.  But as it currently stands, point light is the only light that can be used for flat shading, correct?  Would we want to tell the users that, in some place?  Where should we tell them?  (thx)

[Wingnut]

Here is a new picture that might be headed for tutorial #5, eventually, and upon approval.  I think it might be rendered a a bit too large at the moment.  Exciting, huh?  (yawn)  http://urbanproductions.com/wingy/babylon/misc/arc01.jpg  Maybe I need to remove the periods.  *shrug*  Comments and criticism welcome, as always.

[gwenael]

Usually, only alpha or beta goes from 0 to 2PI and the other one goes from -PI to PI since it's enough to cover the whole sphere but I don't know how it is in babylon.js

[Wingnut]

That's near correct.  By default, .beta (up/down) has min/max limits.  Beta zero is straight overhead... and beta +PI is directly beneath. 

 

By default, .alpha (sideways) has no min/max limits.  Alpha = 0 makes cam face -x. (I would have thought that would be +z, because a freecam defaults to facing +z, I believe.). 

 

Incrementing alpha makes cam move counter-clockwise returning home at 2*PI  (facing -x again).  Decrementing alpha does the same, except counter-clockwise.

 

Here is a little demo.  And here is a zipped version.  NOTE!  Cam is facing -x!  Most of my demos put cam facing +z.  I put an alert at the beginning, that tells of the default limits, and after you close the alert, I set all limits to 0.  I think zero is clearing the limit because of...

 

default arccam.lowerBetaLimit: 0.01    <== NOT a cleared limit.

 

Still learning.    Comments welcome and thanks for them.  The more the better.  This may all seem off-topic, but it IS in preparation for writing good tutorials, of course.

[GameMonetize]

You can use directional light with flat shaded mesh, no?

[Wingnut]

Hi dk.  At first, I didn't think so.  But, yes, it does.  (thx dk!)

 

And in proving that to be true, I discovered I have big big big trouble in my recent extra teaching about the .direction property of lights.  In that section of the lights tutorial, I said that you can use the .position of a mesh... as the .direction of a light.

 

Wrong-o, Wingnut! *sigh*.  Yes, directionalLights do flat shading... once you get a proper .direction set on them.  (Wingnut made tons of mistakes during earlier tests.)

 

.direction is going to kill me, I am sure of it. (Wingy starts crying) 

 

Ok, back to the lights tutorial where I tell the user...

 

"The .direction property is a genuine pain in the butt to set, so don't even bother trying."  heh

 

The .direction property (on directional, spot, and hemispheric lights... seems to use a vector3 where each value is a float... negative 1 to positive 1.  If I were to attempt to put it in my own words, each value determines the amount of 'pull' or 'influence'... to try to aim the light in that direction.  I'm still studying it.  I don't know HOW to teach it.  I think I am getting a tumor. 

 

Maybe deltakosh (or any other local genius that is willing to take the job)... will (help) code a new method called Light.setDirectionByTarget(any .position_or_target)  Yes?  I am going to look into it... to see if others have tried, or see if I can do it myself.  Not easy.  I think we need the folks who underststand matrix transformations, and I am not one of them.

 

We all know that users are going to try to set somelight.direction to (0,0,0) about a billion times, and ask why it failed.  But if we teach light.setDirectionToTarget() instead, then the code inside that function... can auto-repair every time they target (0,0,0).  Essentially, we will be hiding the .direction property from general users, and make them use light.setDirectionToTarget(any .position) instead. 

 

For new users:  Setting a light's .direction to (0,0,0) will make that light fail.  .direction needs SOME magnitude in SOME direction... in order to work at all.

 

Thoughts?

[GameMonetize]

The proof:

http://jsfiddle.net/WTqLQ/1/

[Wingnut]

Thanks dk.  I have been editing my previous post for about an hour.  Please re-read it if you have a moment.

 

I recently tweaked the animations tutorial #7, nothing major, and I removed the extra section in the lighting tutorial #6, about .direction. 

 

I do not know enough about light.direction yet.  I need to learn it myself, then learn a better method to explain it to others.

[gryff]

As there is a lot of talk about lights, I'm curious about the "exponent" proprty/parameter of the point light. What does it reflect? When I export a point light from blender the value seems to be 0.3.

 

cheers, gryff