"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!

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.

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.

Share this post

Link to post

Share on other sites

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!

Share this post

Link to post

Share on other sites

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.

Share this post

Link to post

Share on other sites

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 andmakes an excellent fill light.

Share this post

Link to post

Share on other sites

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.

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.

Share this post

Link to post

Share on other sites

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.

Share this post

Link to post

Share on other sites

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.

Share this post

Link to post

Share on other sites

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)

Share this post

Link to post

Share on other sites

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.

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.

Share on other sites

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.)

"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.