continued_at_new_forum The Wingnut Chronicles

[gwenael]

BABYLON.Scene.prototype.setActiveCamera = function (cameraOrIdOrName) {        if (cameraOrIdOrName instanceof BABYLON.Camera) {            this.activeCamera = cameraOrIdOrName;            return;        }        // By ID ?        var camera = this.getCameraByID(cameraOrIdOrName);        if (camera) {            this.activeCamera = camera;            return;        }        // By Name ?        camera = this.getCameraByName(cameraOrIdOrName);        if (camera) {            this.activeCamera = camera;            return;        }    };

 

Must "by id" be done before "by name" because if you look for the camera by providing its name, it's not efficient: two for loops instead of one for loop which could check for both id and name on each iteration? I'm also concerned about the fact that the name of the camera you are looking for could be the id of another camera. Bad luck.

 

As far as I'm concerned, I would provide three different functions instead of one but maybe it was a private joke between you guys

[Dad72]

You seem to have the skills to create your guénaël engine. Go 

[Wingnut]

THANKS gwenael.  You help me understand DK's thinking on this.

 

I forgot about setActiveCamera(a camera).  Yes, three possibilities... and doing all three in one method... is an 'overloading' of that method to a degree.  NOW I see DK's reason for ById and ByName in setters  (and ByCamera).

 

hmmm.  There is a trade-off here. 

 

1: Simple-but-overloaded  vs  2: Fast-but-three-ways 

 

1: Use one function:

     setActiveCamera (instanceof BABYLON.Camera OR string OR number)

 

2: Use three functions -

    setActiveCamera (instanceof BABYLON.Camera)

    setActiveCameraById (string or number)

    setActiveCameraByName (string)

 

I think I understand now.  Sorry I was so slow and blind.

 

There was no (significant) private joking going-on. Gryff, DK, and I... were just looking at the API... discovering what was available for non-mesh-item look-ups, and value gets and sets. (cameras and lights).

 

I am only concerned about the name(s) of the function(s) making English sense and programming sense.  And, this is a big change.  Maybe we should start a new thread in the forum and gather opinions.  (decision by committee) (ouch)

 

Maybe... ONLY... setActiveCamera (instanceof BABYLON.Camera) ... and nothing else.  Maybe.  *shrug*

 

There is scene.activeCameras - an array.  Does that mean there can be more than one active camera?  If so, that is big big trouble for this conversation, too.  Sigh!!!

 

Maybe I should have kept my mouth shut from square one. 

 

Thanks again, gwenael.  You opened my eyes to WHY the framework sometimes uses ByID and ByName in setters.  Are there more opinions?  Let's hear them.

[gwenael]

You're welcome.

 

Let's start a new thread. Please, I'm begging you

[GameMonetize]

Thank you for your help Gwenael.

Finally this is always the same trade-off between convenience and performance

 

Let's look a this function: setActiveCamera vs setActiveCameraByName and setAciveCameraById. The first one is simple, convenient and does everything for you.

 

BUT it is not efficient, can lead to bugs (name or id first) and maybe hard to understand (how do I know that I can use id, name or camera??)

 

So this is why some functions may sound weird. They are all created with convenience AND performance in mind

[Wingnut]

Thanks DK!  Nicely worded, i understand completely.  My opinion, use your best judgement on what to do.

 

Gwenael... go start your thread.  Nobody is going to post to it, because everyone knows that this thread is 'the' happening place to be. hehe.

 

Let's do an experiment.  fire up a Google search box, and enter...

 

setActiveCamera (instanceof BABYLON.Camera) 

 

... something said in this thread a mere 4 posts ago.

 

See what returned?  The Wingnut Chronicles - Page 12 - Babylon.js... in the #2 slot!  That shows... that you can use Google... to find out about ANY BJS infomation...  easily, no matter how cluttered any thread is.  And...  you can get the URL for any post in the forum...  by right clicking on its number in the upper right... and using 'copy link location' or similar.

 

So then... you can say...  "Hey you guys... regarding http://www.html5gamedevs.com/topic/2571-the-wingnut-chronicles/page-12#entry30323 ... I think blah blah blah, and foo foo foo, and etc etc etc".  All of us here in the superstar thread... will whack that link, see what the hell you are referring-to, and be on-subject with you.  Easy, right?

 

Now... regarding this page... http://www.html5gamedevs.com/forum/16-babylonjs/page-11?prune_day=100&sort_by=Z-A&sort_key=last_post&topicfilter=all  ... notice that there are 11 pages of 'topics' in the forum.  See... its a big fat pig, too, and just as hard to find topics in that way.  I have 12 pages here... one more page than that.  What's the difference?  You got two choices.  Find topics in this big fat pig area, or find topics in that big fat pig area, right?

 

Maybe I'm confused.    I really like you, g-man... but... don't be harshin' my mellow.  hehe.  (I know the Eurites really like American colloquialisms like those.  They make software-based language translators get tumors). 

 

harshin' my mellow - making me think about concerns and responsibilities... when I am in a relaxed state. 

[Wingnut]

Hi gang!  As some of you may know, I have been spending a lot of time with lights, mostly trying to fire-up a spotlight to shine on the inside walls of a huge standard box.  And likely, some of you know that such things just do not work.  It likely has something to do with "normals" or some other phenomena that I don't understand. 

 

I ended-up writing my own make-a-box function, which makes a box out of 6 planes.  This also enabled me to leave some gaps at the seams of the box... which allows the scene.clearColor to shine through those gaps.  This makes it easier to 'feel' the camera orientation while you (and your camera and lights) are inside-of the box.  It lets you see the seams between the 6 planes (a bit like flat-shading would do).  Now that I have my new 6-plane box, the spotlight is working nicely inside, and I can do further in-box experiments with lights. 

 

Ok, now back to a standard Babylon.js box...

 

For standardbox.material.emissiveColor, wouldn't it be cool if emissiveColor... when set... flat-shaded the inside of that box (so I could see the seams on the inside of the standard box)? 

 

I think box.convertToFlatShadedMesh(); would need to be done, of course.  And normally, I think you need to use a PointLight for flat shading.  But, I wonder if .emissiveColor could be told to 'behave' like a PointLight on meshes that have had .convertToFlatShadedMesh() performed on them... and thus... look flat-shaded... even without ANY light.  I wonder.  Unlikely.    By definition, I think .emissiveColor is NOT supposed-to behave like that.

 

All in all, I am having a whole lot of fun with Babylon.js today, as always. I will be trying to parent a spotlight to an invisible mesh, and then using mesh.rotation to aim the spotlight... instead of using spotlight.direction.  I might try out some new (to me) Math.sin and Math.cos things that deltakosh (dk) showed me, to see if I can give myself a seizure from too many moving lights on my monitor screen.    No demo for the readers today... maybe tomorrow.

 

Gwenael... I hope you are not disgruntled with me.  I have been a bit brutal to lots of people lately.  I get that way sometimes.  Darned constipation.    Party on!

[GameMonetize]

The problem with emissiveColor is that the color is constant on all the object. There is no shading then

[Wingnut]

nod, thx.  Yep, I thought that would be the case.  As best I can tell, flat shading is VERY dependent upon light direction... to determine what color variations to use on the different faces.  (I have SO much to learn!)

 

In the case of my 6-plane box, I suppose a person could use a slightly different .diffuseColor on each plane, and thus 'fake' flat shading in that way.

 

Interesting.  I think I will do that, and then see what the lights do in that situation.  I'm such a simpleton.

 

I was reading the ragdoll thread earlier.  Boy, that looks like some gruesome work.  My flyer quaternion problem is 'small potatoes' compared to the challenges being raised by those guys.  phew.  And DK, you just got on their frequency and jumped right in there like you were sitting next to them, analysing their code.  Amazing.

 

I would LOVE to see your folder of tests, tools, and demos, DK.  I bet you have a folder full of torture tests that is just... unbelieveable.  You should zip it all up and give it to me, yes?  Even if its junk that doesn't run... I'd be glad to have anything out of that folder-from-hell.  Its probably more than a folder, huh?  More like 3-4 hard drives, probably.    Be well.

[Artem]

Hi Kids!

 

Umm...  Should...

 

BABYLON.BoundingBox.prototype.isInFrustrum

 

be changed to...

 

BABYLON.BoundingBox.prototype.isInFrustum ?

 

(last 'r' removed)  *shrug*  Be good, gang.

 

Oh, gawd! Hurry to change it here as well:

http://doc.babylonjs.com/page.php?p=24688

 

I just got a headache because of this "r". Thank god now I know what was wrong, damn it

[Wingnut]

Ooops, my apologies, Artem.  I did not do good follow-up on this.  I will PM (personal message) the sokrate team and search framework code (and pass findings to authors and maintainers). 

 

There are many surnames on the planet that end in 'strom', and that causes easy mistakes when saying and then typing 'frustum'. 

 

Problems like these can be 'frustrating'.  They will cause a low 'frust rating'.  hehe  (ahem - sorry)

 

Maybe we need ... var relief = new BABYLON.Engine.CreateAspirin(size). 

 

Thank you for your reminder and I hope you did not suffer too much. And, good to hear from you!

 

Update:  No findings when I Windows-searched Babylon 1.9.0 master directory for content:frustrum.  Framework code is a-ok.  Sokrate managers informed.  Soon fixed.  Thanks again, Artem!

[Wingnut]

Hi gang!

    Today, I am still testing the spotlight, and, I think it is going to be the death of me. 

 

http://urbanproductions.com/wingy/babylon/misc/spotlight.jpg   (camera is looking +z)

 

1. I can't seem to get that white spotlight to shine onto that wall of my 5-plane box.  That wall IS the backface of that plane.  When I turn that wall around, the light DOES shine on the wall.  Is this normal?  Spotlights do not work against non-culled backfaces of planes?  That appears to be the case.

 

2. Look at the numbers at the top.  Apparently 'light.direction' is not like mesh.rotation at all.  At first, I set the light.direction to 0,-1,0, and the light shined straight down the -y axis.  Then I set the light.direction to 0,-50,0, and it shined exactly the same.  Apparently I still have much to learn about the light.direction property.  The light in the picture is...

 

spotlight.direction = new BABYLON.Vector3(-.9,-1,0);

 

But, the light appears to be rotated around the z axis.  I'm SO confused.  Off I go to read about 3D lighting and the .direction property of such things.    Maybe I will go find the person who designed openGL lighting... and have a little talk with them.  I hope everyone is well.  Comments certainly welcome, always.

 

ps: Both the arrow and the light are .position origin (0,0,0) if that matters to anyone.

[Wingnut]

Ok, we have some success...

 

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

 

I turned the planes of the workshop... so that the frontfaces were toward the inside.  Then, I set the spotlight.direction to (0,-1,0)... ( never set it to (0,0,0) according to http://msdn.microsoft.com/en-us/library/aa917100.aspx ).  Next, I set spotlight.parent = the spinning box (litehndl)... and behold, we have seisure-causing spotlight movement.

 

Using this system of parenting a light to a (invisible) mesh... is making light aiming a whole lot easier for me.  .direction, is hard.  We might have to add a big fat section to the lights tutorial... just to help with the .direction property.  Cuzzzz... its hard (difficult) (tumor-causing).
 

In IE11, the demo above runs really fast... and the spotlight appears red.  In firefox 21, it appears white.  Also, if you fly the camera toward the rotating box, you will see its color suddenly become brighter.  That is because you have flown your camera through the partially .visible 6th plane (-z facing).

 

Here are two more non-zipped similar light demos...

 

http://urbanproductions.com/wingy/babylon/lights/lightplay4.htm

(parent-rotating a point light)

 

http://urbanproductions.com/wingy/babylon/lights/lightplay5.htm

(parent-rotating a directional light)

 

Both are interesting, I say.  Point lights... are somewhat like the sun.  And one would think... that spinning the sun around... would make little difference in its light.  But you will see in lightplay4 demo, that the point light is not exactly like the sun... and you can easily see the affect/effect of rotating it.  I think its a beautiful effect.  Be sure to fly your camera to the back side of the box, too.  Again, we see slightly different results between Firefox 21 and Internet Explorer 11.

 

Call me simple, but I really enjoy playing with babylon.js lights!  Its... fascinating!  "What happens when you rotate a hemispheric light?" you ask?  Nothing. The hemispheric light is as solid as a rock, and Mister Wingnut's goofy spinning light parent... had zero affect.  Party on!

 

ps: Also, I learned a little bit more about light.direction.  Light.direction is actually a 'position' to a place in space.  What place in space do you want the light to aim-at?  So you could think of it as a targetPlace.  I will likely adjust the basic series Lights Tutorial #6 to explain .direction better.

[Temechon]

Hi all, 

 

Just popping in, don't mind me.

 

Update:  No findings when I Windows-searched Babylon 1.9.0 master directory for content:frustrum.  Framework code is a-ok.  Sokrate managers informed.  Soon fixed.  Thanks again, Artem!

 

It will be fixed on Monday. Thanks !

 

Cheers, 

 

EDIT : And it's fixed ! 

[Wingnut]

Hi kids.  A different kind of comment, today.

 

http://translate.google.com/translate?sl=fr&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fwww.catuhe.com

 

I have Puppy Syndrome, a large case of it.  I am going to try to lose it... and also try to help deltakosh keep puppy attacks to a manageable level.  DK, I am sorry for all the times I have been an attacking puppy (many). I hope others will join me in trying not to be biting puppies, and try, instead, to explain to grumpy puppies... how open source projects work.

 

It is easy to forget that a webGL framework must follow the rules and laws of OpenGL.  I, (and many others) do not know what those rules are.  We think the framework can be adjusted to fit our every whim and dream, and that is not the case.  I think it would help all grumpy puppies... to learn as much about OpenGL as possible.  Learn the OpenGL rules and laws that the authors of babylon.js... are required to adhere to.  By doing that, puppies like myself can KNOW when we are asking for something feasible and possible, and when we are asking for the moon and the stars. 

 

Lastly, we must be patient... not only with our forum questions, but with ourselves... as we learn the seemingly unfriendly world of 3D computer graphics, and its many rules.  Party on!

[GameMonetize]

I promise I was not thinking of you when I wrote that!

[Wingnut]

Oh, I realize that.  It is kind of you to make sure that I realize it, though.

 

@deltakosh:  I still have that 'puppy syndrome' problem, and have contributed to the puppy stampede.  I have wondered many times... how you keep from going insane.  A little puppy syndrome here, a little there, it adds up to a whole lot of PS upon you.  I am going to try to reduce your load, and I think others should do the same whenever possible.

 

I do not know much about other countries, but Americans can be some self-centered SOB's... and I am one of them.  We tend to want to be "serviced", and we forget that somebody has to clean the bathrooms.  We are a country full of spoiled brats.  I was in the US Air Force for 9 years, and I loved the "commune" of it.  Everyone had to "pull KP" sometimes (work in the kitchen), and everyone took care of one another, and everyone was treated the same, and fairly.  Am I a commie?  Probably.  I like commune-ity.  I like teams.  But there is a problem with teams.  A lack of humility from members of that team who are starving for empowerment. 

 

Decision by committee is difficult, and inexperienced team members sometimes forget to respect the knowledge of the tribal elders.  Many times, the team needs to let the most-experienced team member... make the decision.  THEN, they need to defend that decision maker from the barrage of "Why did you do it THAT way?" puppy attacks.

 

Heavy psychology talk.  All in all, I think people (including me) should AT LEAST be aware of the heavy loads that can be unintentionally placed upon very valuable team members... like you.  The rest of us just CANNOT let you be crushed by the fans of your own great project.  You are too needed and valuable.  Not one of us would blame you if you run into the closet and hide, sometimes, or often.  Ask any Hollywood star, and they will tell you how brutal their fans can be.  YOU... are OUR Hollywood star, deltakosh.  Don't let us crush you.

 

Paris star?  That's even cooler! 

[Dad72]

I promise I was not thinking of you when I wrote that!

 

C'est drôle je me sens visé sur la fin. Je ne suis pas venue vous pourrir par MP, Je vous ai juste demander pourquoi vous ignorer mes postes. c'étais une question, je ne demandais pas a ce que l'on face le travaille pour moi. Cela à été votre traduction, pas ma pensé. Vous avez juste mal compris ma question. Je vous respecte pourtant et vous apprécie pour le travail que vous faite, mais je vois que vous ne m'apprécier pas beaucoup a cause d'un mauvais jugement ou d'un mal entendu.

[GameMonetize]

It was not for you dad72 neither. I was upset at that time by some users of hand.js that kept sending me mails and message on codeplex:)

[Dad72]

It could loan confusing, your blog post dated the same day as my MP.

[GameMonetize]

Ok bad luck so:)

[Wingnut]

Maybe I should not link to catuhe.com   I started widespread worry.  I do not speak for deltakosh, but for me - I like you dad72.  And that gui/ide you have... yummy!

 

dad72... do you know what MVC is? (model - view - controller) (mdi?).  Are you using some MVC thinking in your gui / ide?  I think your gui is beautiful and interesting.  Or, in American English...  its 'rad' and 'sweet'.  It 'rocks!'. 

 

That davrous guy... boy, he's a pretty good coder, too, eh?  Phew.  He has made some real nice things for bjs.  Scary-level smart.    And he teaches us how he did it!  Too cool!

 

But back to dad72 smarts.  Hot!  Plenty of smart (and creative, too). 

[Dad72]

I'm not sure to understand what is a MVC (model - view - controller). What do mean you by what is my IDE uses the MVC.

 

My IDE is a WYSIWYG editor mode (for the terrain). This is what you wanted to say?

It will also use a system of script with code Babylon for the dynamic the game.

 

 

[Wingnut]

nod.  MVC is a database-to-user-to-GUI thing.  All your scene items would be stored in a database (the data model).  Then the GUI user can choose how to VIEW the scene.  One view would be in webGL.  Another view is with a hierarchical tree view.  Another way would be a list view.  A HTML table is yet another 'view' of a scene.  Your gui... could have many windows that can be dragged and positioned.  One window shows the webGL view, another shows the tree view, another the html view, etc. 

 

The 'controller' part is user input.  The user can change the scene-model in the data base, by doing input on any of the views.  User could drag or rotate a mesh, which causes an event that propagates to the database model of the scene, and all the other 'views' of the scene, would update instantly.  (because the data base saw a user event - the re-position or the rotation... or a scene item delete or add.)  The user can even use an input box to change the database model, or even enter some javascript.

 

And, a really good MVC gui... uses tabs, like your GUI, and sub-view resizers and gutters (lots of drag and drop power).  And you can make any sub-window (view) click to go full-screen, and then click again to make it a sub-view again.  (put it back in the multi-view gui). 

 

MVC is a system... that interfaces the user (controller) and the view (webGL/treeview, etc) with a data base (the model/scene graph)..  *shrug*.  Not easy to explain.  Maybe try http://tinyurl.com/ls55uzh

[Dad72]

So yes my editor in part uses the MVC