continued_at_new_forum The Wingnut Chronicles

[Wingnut]

Repeat message deleted here.  See next message.

[Wingnut]

Hi Kids!  Here is an interesting little demo that tests the .groundColor property of a hemispheric light.

 

http://urbanproductions.com/wingy/babylon/hemiplay/hemiplay.htm (.zip is there, too)

 

According to http://blogs.msdn.com/b/eternalcoding/archive/2013/07/08/babylon-js-using-lights-in-your-babylon-js-game.aspx ...

 

"A hemispheric light is defined by a direction to the sky and by 3 colors: one for the diffuse (the sky color), one for the ground (the color when the pixel is not towards the sky) and one for the specular."

 

The part I was interested-in... was "the color when the pixel is not towards the sky"

 

That is exactly right.  The box and the ground in this demo... have no .diffuseColor or .specularColor.  Both meshes get their color from the HemisphericLight.diffuse and HemisphericLight.specular (both red) and from the HemisphericLight.groundColor (green).  The bottom of the box is indeed green, because it is NOT toward/facing the sky (caused by .groundColor).  The sides of the box show various levels of tan/brown (a mix of green and red)... and the top of the box, which faces the sky... is red... from the light's .diffuse and .specular.

 

Yeah, its simple, but it sure is fascinating, yes?  I think so.  When I first saw the .groundColor property, I said "hmm, the light can be a certain color normally, and a different color when it strikes a 'ground'"?  Incorrect, Wingnut. The .groundColor is the color of a HemisphericLight for pixels/faces... that are toward the ground.  It could be thought-of as 'downColor', and the sky color could be thought-of as 'upColor'. 

 

This light was created... via...

 

var hemilight = new BABYLON.HemisphericLight("Hemi", new BABYLON.Vector3(0, 15, 0), scene);

 

I think that Vector3... sets "a direction to the sky".  Make that be -15, and you have set the "direction to the sky" to DOWN.  Now the downColor is the upColor, and vice versa, and the whole thing reverses itself... I think.  I have not tested that to be true, but readers... grab the zip, and experiment.  Maybe instead of rotating the box under the light, you might want to 'orbit' the light around the box!  (Where is light.lookAt when we need it, eh?) 

 

Just like particleSystem gravity and scene gravity, you can make 'a direction to the sky' be ANY direction.  TOO MUCH FUN!

 

All in all, BABYLON's HemisphericLight is an interesting light, huh?  *nod*.  I hope everyone is well!

[GameMonetize]

lol:)

[GameMonetize]

And please, publish your update for tutorial 4  I'm sure this will be great!

[Temechon]

+1 !

[Wingnut]

Erf!  I just purchased MarkdownPad 2 Pro.. offline GitHub-ready 'markdown' editor... $15.  Now I am REALLY scared... but... it seems to be pretty nice.  My nads have dropped a bit... about half way.  It downloads the GitHub markdown processor API and uses that for the document preview... and it gets the pictures... so it SHOULD be a nice, clean way to edit that alien debris (markDown) used in the tutorials.

 

Sigh.  It is a mere $15, but, somehow, I feel like I have just sold my soul to the devil.  hehe.  But BJS and its authors and supporters... have been nothing short of FANTASTIC to me... and I should not be hesitant at all in contributing to the team however possible.  I am making backups of everything I edit, and I plan to run a tight ship, if I can.

 

DK/Forum Admin... can the name of this thread be changed to "The Wingnut Chronicles"  ?  Do it if you can and want.  Thanks.  Party on!  :/

[GameMonetize]

Done

[Wingnut]

Tutorial 4 editing complete... except for the 150,000 mistakes I surely made.  Adjust at will... of course. 

 

EVERYONE, PLEASE, proofread the hell out of https://github.com/BabylonJS/Babylon.js/wiki/04-Materials for "us". 

 

My nads are way up high again.  But I did it!  I got an edit done!  Ain't I just something!!!  (Wingy pees a little.)

 

I'm thinking maybe some hot cocoa and a Bugs Bunny cartoon, now.  Respirer, Monsieur Wingnut! Respirer!

[GameMonetize]

Just a word: THIS IS PERFECT:)

[Wingnut]

Thanks DK.  That's three words, though. 

 

Very kind of you.  Also, I will remember... that even though I have an offline editor, I will always start an edit using the CURRENT published version, and not some version I have on my hard drive.  You and others will be making edits as time goes by, and I must must must ALWAYS start with the current published version.

 

I'm really just reminding myself of this.    Collaborative workflow is a bit new to me.  Living documents.  Scary.  Do you and/or others... grab backups of things every so often?

 

In function createSceneTuto...  the [...] looks a bit strange.  Not sure what's shakin' with that.

 

Also, I see someone removed the horizontal rules that wrapped the 'More About Textures" section.  Would you prefer I avoid horizontal rules as a rule?  I can do that.

[Dad72]

Yes, it is perfect, if all tutorials can be written like that, that would be awesome. We would have more details. 

 

Thank you Wingnut

[Wingnut]

Thanks dad72, but I did not change very much.  The tutorials are quite nice already.  I can only hope to measure-up to the same high standards that the tutorials currently hold... with any future editing that I do.

 

What is TRULY amazing... is that people like YOU, and Temechon, deltakosh, gwenael, dav74, davrous, ProfessorF, Ariel Yust, reddozen, hw3web, zincman320, isigui, Nico, neoRiley, Girardin, Artem, and many others... built and contributed-to the already-near-perfect tutorials... long before I arrived.  AND, English is not the native language for most of you.  THAT... is the truly amazing thing.

 

AND... not only are you all very very smart and talented... but you are really nice people, too.  I am proud and honored to be on the team and in the online community with all of you.  You are all heroes of mine, and fine coders and artists.  Keep up the great work!

[Wingnut]

Hi girls!  Ok, lets drop a bombshell, here... see what blows up. 

 

I am going to assume... that light.diffuse... and light.specular... was/is a mistake.  It should have been light.diffuseColor and light.specularColor from day 1, I suspect.  I could easily be wrong, though. 

 

To change it now, will break MANY demos and projects.  If this is changed... it should be done in a 'major revision'...  ie.  babylon.js 2.0.  I think it should be done.  Then we fix all the demos and projects, no matter how painful.

 

Since we would be in high pain ALREADY... I propose more major changes...

 

I propose... no more Color3 and Color4 for users.  Only Color.  If Color has 3 args, it is assumed/cast to be a Color3.  If it has 4 args, it is assumed/cast to be a Color4.  I have no experience with Color4.  When is Color4 used?  I HAVE used Color4 to set StandardMaterial's .diffuse/specular/ambient/emissiveColor properties, and it DOES work for those, but the 4th arg is probably ignored.

 

I propose... no more Vector2 and Vector3 for users.  Only Vector.  If Vector has 2 args, it is assumed/cast to be a Vector2.  If 3 args - Vector3.

 

I propose that ArcRotateCamera... be renamed to OrbitalCamera.

 

I propose that texture uAng, vAng and wAng... be changed to uAngle, vAngle, and wAngle.

 

I propose that texture wrapU and wrapV... be changed to uWrap and vWrap.

 

In Color4, alpha is set with an arg (a parameter - the 4th).  So...

 

I propose ...  foo = new BABYLON.Texture(url, scene, alpha, noMipmap, invertY);  (new third arg - alpha)  If alpha > 0... then Texture.alpha is set to the value of the new third arg, and Texture.hasAlpha is set to true.  This would end the user initially setting Texture.alpha (a percentage) and Texture.hasAlpha (a boolean).  Texture.alpha would still exist... for those who want to dynamically set the alpha programatically (maybe in the render loop - to make textured meshes appear and disappear - maybe slowly pulsing/oscillating).

 

I propose ... foo = new BABYLON.Material(name, scene, alpha); (new third arg - alpha)  If alpha > 0... then Material.alpha is set to the value of the new third arg.

 

I propose ... foo = new BABYLON.StandardMaterial(name, scene, alpha); (new third arg - alpha)  If alpha > 0... then StandardMaterial.alpha is set to the value of the new third arg.

 

I noticed that there is a property... StandardMaterial.opacityTexture.  Is opacity and alpha the same thing?  If so, I think StandardMaterial.alpha could become StandardMaterial.opacity.  Or maybe better...  StandardMaterial.opacityTexture could become StandardMaterial.alphaTexture.  Or maybe ignore this completely.  hehe.

 

I am a newbie and thus I do not see "the big picture" yet, so I expect most of these proposals to be shot down for reasons that I cannot yet understand.  Its cool.  These are just some things that can be "mulled over". 

 

I propose... that Wingnut stop making proposals.  All in favor?  Yays have it.  YAY!!! 

[Dad72]

but I did not change very much.

 

Yes, but on what you change, the explanations are clear and more detail, everything should be written like this.

and I never contribute to the tutorial for my part. My English is too bad to edit tutorials.

 

I have no experience with Color4.  When is Color4 used?

 

Color4 is use to add the alpha color: Color4(0, 0, 0, 0.4) will give a transparent black 

[GameMonetize]

light.diffuse... and light.specular... was/is a mistake.  It should have been light.diffuseColor and light.specularColor

 

 

There are colors and because there are no associated texture I prefred keeping the name short

 

For color3/4 and vector3/4 this is for performance: We cannot afford spending time to check the type of every parameter each time we need to use it. For a scene like Espilit there are more than 6000 mathematicals operations *per* frame.

 

I propose that ArcRotateCamera... be renamed to OrbitalCamera.

 

I propose that texture uAng, vAng and wAng... be changed to uAngle, vAngle, and wAngle.

 

I propose that texture wrapU and wrapV... be changed to uWrap and vWrap

 

 

Nice but too late. We must keep the naming compatibility now

I propose ...  foo = new BABYLON.Texture(url, scene, alpha, noMipmap, invertY);  (new third arg - alpha)  If alpha > 0... then Texture.alpha is set to the value of the new third arg, and Texture.hasAlpha is set to true.  This would end the user initially setting Texture.alpha (a percentage) and Texture.hasAlpha (a boolean).  Texture.alpha would still exist... for those who want to dynamically set the alpha programatically (maybe in the render loop - to make textured meshes appear and disappear - maybe slowly pulsing/oscillating).

 

I propose ... foo = new BABYLON.Material(name, scene, alpha); (new third arg - alpha)  If alpha > 0... then Material.alpha is set to the value of the new third arg.

 

I propose ... foo = new BABYLON.StandardMaterial(name, scene, alpha); (new third arg - alpha)  If alpha > 0... then StandardMaterial.alpha is set to the value of the new third arg.

 

 

We cannot change the signature but we can add helpers: static functions that do what you suggest

 

I noticed that there is a property... StandardMaterial.opacityTexture.  Is opacity and alpha the same thing?  If so, I think StandardMaterial.alpha could become StandardMaterial.opacity.  Or maybe better...  StandardMaterial.opacityTexture could become StandardMaterial.alphaTexture

 

 

stdMaterial.alpha is the global alpha (transparency) of the material. stdMaterial.opacityTexture is a texture use to compute opacity (inverse of alpha) on a per-pixel basis instead of globally. Name comes from blender and 3dsmax.

[Wingnut]

Ok, thanks for the replies.... and the teachings.  I appreciate that.

 

This also tells me a bit about where the limitations of "our" babylon.js are.  That might sound mean, but its just the way it is. 

 

It is not easy to see where the borders are... between "community project" and DK's ownership.  DK, now do you see why I said that the tutorials.. are YOUR documents?  Sure ya do.  There are borders.  It will take some time for "we" to find out where those borders are located and how flexible they are.

 

NOW I bet DK doesn't like me NEAR as much, huh? 

 

I ran into this same 'phenomena' with MOO/MUD, too.  Collaborative, community project... to a point.  That point is dependent upon how much of a control freak the wizard was, and how much he/she thought of his/her users... as 'disciples'.  I have not seen any indications from DK... that he is playing "God" in any way.  He has been quite accommodating (friendly and helpful).

 

BUT... "we" are coming up to BJS version 2 and its "too late".  I would like a list of ALL the things that "we" are "too late" for.  hehe.  That scares me a little.  And I wish "we" could have allowed the other users some time to "weigh-in" on the proposals.

 

Am I the only North American on the forum?  I bet so.  :/  i don't know how that is pertinent, though, but interesting.

 

*shrug*.  I don't know how to work these things.  Does anyone else?  The proposals are no big deal.  The study of the fencing/borders... is interesting.  No deductions or judgements have been made.  Just studying.  Comments welcome. 

 

I am headed to Saxon, WI. USA tonight (a one-horse town) to play country rock bass with my ... a three piece band... for a club full of drunks. YEEEE HAA.  Ride em' cowboy! 

[GameMonetize]

You are not mean and I'm not upset

 

Babylon.js is an open source project that I created. WE as a community can work together to improve it (for instance the documentation or through pull request). But I will always remain as the final judge for quality and integration. When I created bjs I had a vision (!!!) of a very simple and powerful engine and that what I'm trying to do here.

 

Obvioulsy there are borders else the project will become like hell. I must keep a certain level of consistency. Nevertheless, all pull requests done since the beginning of the project were accepted. Sometimes I need to discuss to well understand what is going on but at the end of the day every contributor *can* influence the project.

 

When I say "too late", I mean: the API is already public, users are already using it so we cannot change it anymore (because I do not want to break compatibility). And for the basics structures (vector, color), there is also a problem of performance and usability (we tried to do that with mesh.rotation (both euler and quaternion depending on what you put in): But it was such a mess that I prefered adding a mesh.rotationQuaternion.

[GameMonetize]

Furthermore, next version will be 1.10 and not 2.0

[GameMonetize]

I learned a lot from three.js users telling me that the API changes are so painful. I do not want that for US

[Wingnut]

Hi! 

 

I understand.... and agree.  I can definitely understand the Color3/4 and Vector2/3 performance thing.  Checking for args length and datatypes before doing work... sucks.  Doing datatype error checks and reporting... sucks.  Sometimes it takes half of the function... just to find out if the user made the call correctly (set the args template correctly).

 

What do you think of maybe...  orbitManager?  It can animate-orbit a light, a mesh (and therefore a particle emitter), a camera, nearly anything.  It would use lookAt or target options, it could be made eliptical, it could have its orbit tilted, and of course... if a parent mesh is orbited, all its children go along for the ride. 

 

I guess 3dsMax 'path' is similar.  I don't know.  I am still real short on sleep, so I am likely babbling.  I guess SOME users have already been experimenting with sun paths and moon paths... maybe there are already techniques for orbiting pathing.  Keyframe animation is interesting.  I haven't used it... but... it seems that lookAt/target would be used often with that.

 

Doesn't it bother you when you see uOffset, and uScale being one 'format'...  and then uAng being abbreviated format, and wrapU being backwards format?  SHOULD we care if Blender and 3dsMax use those names?  There is 3 formats happening there.  Doesn't that make you itchy?    It would, me.  If someone were to write an advanced tutorial about textures... all three of those formats would be used in that tutorial.  That would 'feel' terrible to me (inconsistency feel).  I would shake my head often while writing such a tutorial (because of the differing naming conventions).

 

Now, a quick thought about textures used on lights.  I understand since textures are not used on lights, why add 'Color' to diffuse and specular.  I agree, that makes sense, though it still feels strange to me.  Do you see a future for light "gels"  ie. lenses with textures?  Projectors?  Here is a scene I once made in Bryce... a projection of the ISS onto the side of a hill... using a texture on a light (a gel).

 

http://webpages.charter.net/wingthing/img/projector.jpg

 

Could you see such things being used in BJS?  Is there already a method that can do this?  *shrug*.  Again, just babbling.  I'm not sure if texture 'gels' would have much use, but that is one use of textures... on lights.  And thus... it MIGHT warrant light.diffuse/specular... to be changed to diffuseColor and specularColor.  Changed API's can be published for different versions. 

 

I don't think we should let a published API stand in the way of making adjustments to the framework.  A published API should not be handcuffs, IMHO.    Temechon (and his team) are willing to adjust the docs readily, and Temechon seems to be here for the long-term future.  He seems very solid and active.  I almost like him.  hehe.

 

Thanks for the replies, DK.  Party On!

 

PS:  http://webpages.charter.net/wingthing/img/mcp02.jpg  Now THERE is a particle sprayer, eh? 

[Wingnut]

Hi again, gang!

 

I am testing lights... learning.  Mesh material colors... and lights... work together, of course.  (they are good buddies!).  I am using a basic scene with a single box and a single ground. I have a light...

 

var hemilight = new BABYLON.HemisphericLight("Hemi", new BABYLON.Vector3.Zero(), scene);
  hemilight.diffuse = new BABYLON.Color3(1,1,1);
  hemilight.specular = new BABYLON.Color3(1,1,1);
  hemilight.intensity = .1;
  hemilight.position = new BABYLON.Vector3(0,1,0);

 

The light is INSIDE-of the huge box, but for hemispheric lights, I do not think that matters.

 

For the Color3 on box.material.diffuseColor... I am seeing allowed ranges of 0-20 for each color (BJS 1.9.0).

 

Reworded...  box.material.diffuseColor = new BABYLON.Color3(0,0,20) is maximum blue box.  19 is less blue, 18 less blue, etc.

 

Isn't the range for a Color3 color... supposed to be 0-1?  Is this 'anomaly' related to lighting?  Am I making a mistake?  (likely)  Thoughts, anyone?  (thx)

 

Here is the tiny test demo...  http://urbanproductions.com/wingy/babylon/lights/lightplay.htm  (.zip is there, too).

 

(IE11 renderloop is MUCH faster than FF21, I tell ya.  COOKIN' along!)

 

Update:  Ok, it is BECAUSE the hemisphericLight.intensity is set to .1 (low)... that it takes Color3(0,0,20) to get the blue to go full saturation/vivid.  I tested it with a light.intensity = .01, and now it takes Color3(0, 0, 200) to make the blue full vivid.  The values of material.diffuseColor Color3 settings, are dependent-upon/related-to the light.intensity.  Interesting!  If hemiLight.intensity = 1, it still takes material.diffuseColor of Color3(0,0,2) to make the blue be full vivid.  I smell a bug. 

[Wingnut]

Hi again! 

 

Did something happen to .isEnabled on lights?  I don't see it in babylon.light.js.  If it was removed when .intensity was added, then we should adjust http://blogs.msdn.com/b/eternalcoding/archive/2013/07/08/babylon-js-using-lights-in-your-babylon-js-game.aspx .

 

ALSO.... maybe the lights tutorial should be moved to https://github.com/BabylonJS/Babylon.js/wiki/06-Lights .  That way I can edit it... and change it into a pile of mistakes. 

 

If that move is approved, I will begin typing the msdn document... into being GitHub markdown.  We might want to think about moving all tutorial pictures... into a github folder, too.  I might be wrong, though.

 

Thx!  Bye again!

 

PS:  That 'vision' you spoke-of earlier, DK...  its a very good one.  VERY good.  (but don't get cocky) 

[gryff]

Am I the only North American on the forum?

 

 

@Wingnut: Nahh. I live not far from Michigan though Bessemer is about as far away from me as you can get  and still be in Michigan ;-) Drove around Lake Superior once, so, I probably passed through your town

 

Living in Canada though, both my daughters speak French, and one teaches it

 

cheers, gryff

[GameMonetize]

Too many questions, I'm sure I will forget some of them

 

orbitManager: Good idea, let's work on it

Colors are between 0 and 1

Vectors are infinite

 

lights are Node so they "inherits" isEnabled from Node

 

For the naming issues I agree totally with you but we cannot change names right now, it is part of our history:)

[Wingnut]

Hi gryff!  COOOOOL!!  (literally)    Yep, you came through Bessemer.  I hope there was no permanent damage from it. 

 

VERY nice of you to drop a note and say hi.  I don't feel quite so naked and vulnerable now!  (Actually, I feel that way not due to location, but because these Euro kids are mighty smart and talented.  I'm pretty much sucking hind tit around here, and I try to hide it by blabbering like an idiot.) 

 

Have you fired-up any tests, demos, or major projects with this webGL framework?  If so, we all would love to see them and hear about them... even basic, simple stuff.  And, visit this thread and forum anytime, and talk about anything.  This is my thread, and I say off-topic is quite welcomed.  After all, learning new, complicated stuff... is emotional, and sometimes we need to vent about all sorts of crap, huh? 

 

Again, thanks for saying hi!  I'm glad you're aboard, and I hope you hang around with us for awhile or forever, and cause some big trouble like I have.  I'm going to go browsing for London, Canada now... take a little sniff-see at that town you're living in.  Take good care!

 

@deltakosh - thanks for the quick reply and information.  You DO know that you can scroll UP thru the thread while editing a new post, right?    (to remind you of the myriad of inane questions Wingnut has asked).  .isEnabled seems to be broken for lights.  I have not troubleshot it any further... but thanks for the info about node.  Color3 also appears broken... allowing (and requiring) settings well beyond 1.  Color3(0,0,1) is barely blue at all (using a hemiLight.intensity of .1).  Crank to Color3(0,0,20) and the blue goes full vivid, with the same light setting.  We'll talk more about it once you get a chance to drive my demo and do some testing of your own.