continued_at_new_forum The Wingnut Chronicles

[Wingnut]

Thanks for the info, Temechon.  Your ship... is a "smart" ship in many ways.  It maintains states/conditions about itself,  and the actionManager can use those as conditions.  (I should have gone to programming school.)  Yep, I like the idea of smart mesh.  For an advanced ship, the ship could contain its own methods and properties to do things like extend/retract its antennas and landing gear, for example.

 

Unless... the user decides to use an ActionManager interpolator to rotate the gear/antennas in and out.  But the actionManger also has ExecuteCode actions, which could call gear and antenna deployment methods located on the ship-class object.  Its all cool, and I love talking about this kind of thing.

 

I was recently looking at this: http://wiki.blender.org/index.php/Org:Institute/Open_projects/Apricot/BGELogic ...sort of a roadmap for Blender's game called Frankie.  I cannot really tell if Frankie-class has methods.  I suspect the methods are called 'actions' in that document.  I suppose they are Python, so it might be worthless to export those methods during Babylon exporting.  But if the Frankie-class object has named its methods well, then the Frankie-class API would be fairly easy to duplicate in JS, by hand.

 

Then I started thinking about... what SHOULD a smart mesh do for itself, and what it shouldn't.  (ie. how much power to put on Ship).  Collisions came to mind.  Let's say that smart ship... runs into a smart planet.  If there was an ActionManager (AM) on Ship, its OnIntersectionEnterTrigger would fire.  If there was one on planet, ITS OnIntersectionEnterTrigger would also fire.  The planet AM could take care of its collision reaction (dust cloud, scorch mark, etc), and same for the Ship.  They each could contain their own code to react to a collision.  The smart planet knows how to react to being hit by a ship, and the smart ship knows how to react to hitting a planet.  That's pretty cool.  Event driven, and it promotes code re-use.

 

So, when Temechon creates his Ship-class object, the geometry of it... is really a secondary thing.  More important than that, the ship has methods and properties that are used for ship management.  The buildings could also be self-contained... knowing how to blow themselves up, for example.  Yep, I like these things.

 

An untrained coder like me... would have just overloaded a standard box... with a bunch of methods and properties.  I HAVE used prototype in some of my projects, but I never really understood why.  I just copied examples from real coders. In my recent three demos teaching position, rotation, and scaling, I could have made the box be a smart box, self-monitoring which phase of the animation it was in, and each containing their own personal methods to position, rotate, or scale themselves.  Self-animating box class objects.    Smart boxes!  Cooooool.

 

See what I mean, Gryff?  Most of my BJS demos are perfect examples of the wrong way to do things. 

[Wingnut]

BTW, Temechon... that's an excellent new Oimo demo.  Damn, you're a good coder.  I like looking at your code... it makes me drool sometimes.   I get easily excited, though, but still, I love seeing other people's code, especially when it's teaching me something that I can understand, like yours.

 

I looked at the source code for the oimo demo.  Nice clean jumptable-like structure in its html file.  Yum. 

 

Any chance we could talk you into renaming all of your 'initScene' functions and file names... into being 'createScene'  (and createScene.js)?  I would LOVE to get everyone to use the name createScene... to help promote the use of the playground.  The playground is such a good share-the-code device, that I wanted to try to make copying and pasting to and from the PG editor... be very painless.  So, part of that endeavor, is attempting to standardize the name 'createScene'.

 

We could also adjust the playground to accept functions named initScene, too, I suppose.  Think it over, if you want to.  If renaming all your occurences of initScene... to be createScene... would cause ANY hassles for you at all... just ignore me.  If it is no big deal, I would LOVE for you to do that in your current tutorials and in future ones.  Thanks!

 

Yes, I know, the term 'initScene' does not really have the same meaning as 'createScene'.  This has me thinking (everyone duck).  Your initScene() needs no parameters/args.... perfect for pasting into the playground editor.  But your other functions lie outside of the initScene() function, so if a user DID want to paste your code into our playground, they would need to paste-in more than just initScene().  (they would need to paste-in the tag-along functions, too.)

 

hmm.

 

Maybe Deltakosh would be ok with allowing functions named initScene to be pasted into the playground, too.  *shrug*

 

No problem either way, we all love what you have been producing, lately.  When you come out of the closet to wrangle some mesh, you certainly do it wonderfully.  Phew.  Yum!  Now I am going back to staring at your code some more... and wiping-up envy drool. 

[Vousk-prod.]

Ah, don't have regret about not being in programming schools... in fact you don't really learn programming in that kind of schools... all you do there is "lots and lots of projects" which leads you to pay attention to every aspects of coding and to check for every piece of info you're able to find anywhere about your current programming problem.

That's why your way of coding (made of tries, experimentations, reading other's advices, twisting and rubing everyone's piece of code, trying to understand other's good practices) is the good one. That's the real way of learning programming. Each time you have fun with code you learn as much as (or even more than) in an "official programming school".

About createScene and initScene, to add my voice to this (maybe) starting debate, I think that they're not really substituable. What sounds logical to me would be to have at first a createScene, to bring the scene to life, and then, if needed (but it's quite always needed ) an initScene, to properly set up everything to let this scene be able to start actualy living its life.

The difference may seems subtle, but sometimes this mechanism is required.

[Vousk-prod.]

In fact the best way to learn programming is to take part in well structured projects, to work as a team with other great coders. That the most instructive way, a real learning curve.

[Temechon]

 

 

Ah, don't have regret about not being in programming schools... in fact you don't really learn programming in that kind of schools... all you do there is "lots and lots of projects" which leads you to pay attention to every aspects of coding and to check for every piece of info you're able to find anywhere about your current programming problem.

 

I don't really agree with this, it depends of the school really. I was in one of these programming schools, and I really have the feeling to have learn a lot.

 

 

In fact the best way to learn programming is to take part in well structured projects, to work as a team with other great coders. That the most instructive way, a real learning curve.

 

+ 1 !

 

 

 

Any chance we could talk you into renaming all of your 'initScene' functions and file names... into being 'createScene'  (and createScene.js)?

 

I will do it this weekend. You will see in my last demo (WARNING ! lots of cubes !!) I used 'createScene'. The file is not renamed yet, but it will be for my next tutorial (about Oimo of course:) )

 

Cheers !

[Wingnut]

Thanks Temechon... I appreciate it.  Vousky, I agree with the part about initScene and createScene not being interchangable.  I feel your pain.  Ideally, if we all use 'createScene' as often as is possible and applicable, that would be great.  When Deltakosh asks "Could you make a playground scene of your problem?" (for the 12954th time), we want that newbie to say "I'll have that for you in 2 minutes". 

 

The playground is great.  It helps newbies, it finds framework trouble, it's a nice show-and-tell application, and that editor works good.  It's not really appropriate for bigger projects like Temechon's demos, of course, but, it still has a fond and useful place in our community.

 

Schools - I took a Pascal class at U of Alaska, once.  The class looked fine, but the instructor said "uhh" every third word of every sentence he spoke... and it drove me bananas... had to drop the class.  Probably good, because I much-preferred REXX back then.  That was in the pre-oop years.  As we can easily see, Wingnut did not make a graceful transition into OOP.  These days, apparently people PLAN their software.  Back then, we started with a line of code, and 3000 pots of coffee later, it had grown into 100k lines of disorganized chicken scratch and pig slop.  "Reusable code?  What's that?"

 

  yuh yuh yuh, good times.  Party on!

[Wingnut]

Hi gang!

   I could use help/advice with a project, if anyone feels so inclined.  I want to put a texture on the INSIDE of a low-height cylinder, and I want the texture to be a 360 degree "ruler" with hash marks at least every .5 radians with numbers marking those... and maybe the +x and +z and -x and -z at the 90 degree marks... also annotated.  I want to put this 'compass ring' around scenes...  a way for young users to always know their orientation (camera direction) in a scene.

 

Circus rings are a low-height cylinder.  This would be similar to that, with a 'ruler' mapped onto the inside face... all the way around the 6.28 radians of it.

 

Would I need to 'negate' all the UV's on a cylinder... to map a texture onto the inside of it? Maybe just don't cull the backface, and do a few wrap and offset tweaks?  y-invert the texture?  I suppose I need an un-capped cylinder, too.  *scratch scratch*

 

What would be a good image width for this 'panorama' of radian and/or degrees graduations?  Any thoughts or ideas are quite welcome, thanks.

 

I am still looking for more ways to make compasses.    In a way, these thoughts are likely to lead to a skybox that is full of numbers and hash/grad marks.  But skyboxes do some odd stretching of images at their corners.  So, building a skybox with properly-proportioned line graphs and rulers on the inside... might be difficult. 

 

Oooh, http://pubs.usgs.gov/of/2001/of01-041/template/con2_70.jpg  10k pixels wide!  Wow!  But no, we need radians on one of the scales, and degrees on the other.  (And I mean 'we' in a loose sense.) 

 

Still thinking.  Party on.

[Dad72]

Hi Wingunt,
 
just to tell you, once you had pointed out to me that I had never anything present as demo. and now it is made here : 
 
http://www.html5gamedevs.com/topic/8647-game-prototype-clickn-points-escape-to-a-penitentiary/?p=51451
 
It is not yet complete, but ca will be much faster to complete than CastorEngine. 

[Wingnut]

Yep, good looking demo, dad72...  I must now eat my previous words.    I also like seeing those smiles and funny faces in your post.  It is good to see that you are not all work and no play.

 

Great graphics, and a VERY interesting story to go with it.  I hope hope hope that the theme is not indicative or reflective of your personal real life, though.    If you ever feel trapped in real life, make sure you talk to people about it right away, even to me.  I'll gather a team to come to France and get you out of the 'penitentiary'... if you somehow get put into one, when innocent. 

 

I don't know where the French people run to escape traps and avoid responsibilities, but here in the USA... we run to Mexico.  hehe

 

Cool demo!  Well done!

[Dad72]

No, it reflects nothing my personal life. I found the topic interesting to operate which serves as starting point. the following games might be after the escape in the way that television series are, but there, I made it in the form of small game. I tap several theme, because this will not be the only game, there'll have others.

 

I have never done in prison, fortunately.

 

Thanks for your comments on the game. I hope that I did not bad translation with English.

[Wingnut]

Hi kids!

   I have been playing with a new playground demo ... one that has buttons to create all the types of cameras that Babylon.js currently supports.  It's been quite an endeavor, so far.  By the way, the OculusOrientedCamera is now called OculusCamera.  I'll get that information updated, and the FollowCamera added...  to the cameras tutorial soon... I promise.    The above demo is part of that process.  I need a great, all-in-one camera-testing playground scene... to link-to in that tutorial.  So I am trying to build one (badly).

 

For the longest time, I fought-with trying to get OUT OF Oculus camera mode (stereo).  In other words, I had problems getting out-of two-eye mode. 

 

Finally, I discovered it was all quite easy once I emptied scene.activeCameras array.  Apparently 2 OculusInnerCamera objects were still in there, and this caused all of my early attempts to .dispose() the Oculus... to fail.  Once I set scene.activeCameras = {}; (probably should be [] but it worked anyway)... all was well.  You can easily click in-to and out-of Oculus mode... in the above demo.

 

Another problem area... is the VirtualJoysticksCamera.  It uses some fancy operations, and it does not mix well with scenes that have some JS-added HTML at the top (such as the above demo).  Event.clientY is affected by HTML that is 'placed' above the canvas, and so... there's trouble when you try to click on the HTML. 

 

You can see this in the demo, too.  Once you select virtualJoysticksCamera, you will not be able to click any more blue HTML buttons (the dynamically-added buttons).  Event.clientX needs a Y offset.  I included some inactive code in the demo... where I tried to make a +50 pixel Y-offset for the joysticks (so they would de-activate when they happened on the HTML buttons.) 

 

It didn't work so I remarked it out.  I need to study that issue more thoroughly, yet.  Help welcomed, always.

 

Another issue with the VirtualJoysticks(cam) is ...  well...  hmm.  Click and hold down a left mouseButton to start a virtualJoystick near the horizontal center of the screen.  Now keep the button held down, and mouse all around.  See the rings not being erased... when the joystick is dragged onto the "other side" of the screen? 

 

This problem MIGHT also be caused by event.clientY value.  (y-offset due to dynamic html buttons added by the scene code).

 

Maybe it would be better if we had event.canvasY (and event.canvasX) values to use, eh?  ClientX and ClientY might not be aware-of dynamically-added HTML that is placed above the canvas.

 

So, it's not really the problem of the VirtualJoysticks or VirtualJoystickCamera.  It's more a problem of where I have dynamically-placed the buttons.  Maybe I'll move the buttonbar to BELOW the canvas, and see if the VirtualJoysticks operate better after that.

 

I am also looking at an issue where some GamepadCamera text... remains on the screen after changing to a different camera.  Still learning.

 

It's all good fun. Ideas, help, comments, grumbles ... welcome.    Party On!

 

Oh yeah, one other thing.  Pushing the playground's RUN button... when-in VirtualJoystickCamera mode...  will crash most browsers.  Ain't it great?!  I haven't investigated why... at all yet.  It might crash when pushing ANY Playground buttons/gui.  I'm proud when I can find something that can crash both of the "big browsers".  It makes me feel powerful.  hehe

[Dad72]

It's cool to have an example of each camera to see their behaviour. Thank you for your works.

[AlexB]

By the way guys, here is a demo of how the FollowCamera is supposed to work. In this game, it's set to follow the little guy around (sorry, this game is no longer up on the web)

 

[Wingnut]

Cool, thanks AlexB.  That looks great!

 

Yeah, as far as I can tell, the BJS version is working perfectly, now.  When I animate the yellow box, I add a tiny amount to the FollowCamera.rotationOffset... and it gently orbits around the yellow orbiter.  (the camera is slowly 'trucking left' / 'dollying left'.)

 

I like the way it feels/looks, and it's easy to use.  Good asset/resource.  Thanks again.

[Wingnut]

Hi gang.  Here's another version of the 10-camera demo.  I solved one of the virtualJoystickCamera problems mentioned earlier.  You can now click on the blue html buttons... when in virtualJoystickCamera mode.  I was able to locate the vjCanvas (an extra HTML canvas element that is appended onto document.body when virtualJoysticks are used).  Once I got a handle on that, I was able to set its CSS .top = "70px" (below the dynamic html) and set its CSS .height = "95%" (not as tall).

 

The other two problems still exist. 

 

1. Left-Mouse-Button dragging a yellow virtualJoystick onto the cyan side... draws rings. And Left-Mouse-Button dragging a yellow virtualJoystick onto the cyan side... draws rings.  Still learning.

 

2. FF and IE crashing if you hit the Playground's RUN button while being in, or after being in... virtualJoysticksCamera mode.  hmm.

 

Fun! 

[Wingnut]

Here's a little playground scene for testing the crash... if anyone is bored and wants to try to help figure out the problem... with VirtualJoysticksCamera (when used in the Playground).  http://www.babylonjs.com/playground/#2EBYAK

 

Just visit the link, and hit the playground's RUN button.  POOM!  Browser crash... at least for me, FF or IE. 

 

Rumor has it that the RUN button does a type of 'eval' (duh?) and... hmm...  why doesn't the Playground (or the browser itself) like to DO that eval... after a VirJoyCam has been created? 

 

I think it has something to do with the left virtual joystick (which can be activated atop the editor portion of the playground).

 

Any thoughts, anyone?  (thx)

[Dad72]

You have found a bug that should be reported to Deltakosh after returning from holiday.

[Wingnut]

Well yes, but... wouldn't it be a nice welcome-back for him if we already knew what was causing it?  It would show that we could "handle the shop" when the boss is away.

[Dad72]

I do not think that the bug report is so bad, or a bad thing to do. But I understand what you mean. There is no emergency at the reported. 

[Wingnut]

  Bug reports CAN be bad when you are a software author that takes pride in keeping his code as perfect as possible (ie. Deltakosh)... and the thought of that bug won't let him stay on the beach anymore.    You wait and see, Dad72.  You will be vacationing, relaxing, fishing in the Himalayas...  and a text will arrive that says "CastorEngine has a bug"... and you will have to come home early (possibly rated as a "bad" thing).  hehe.  You are CastorEngine's dad... and if it gets in trouble... you'll come runnin'. 

 

I have been playing with "the crash" a bit.  http://www.babylonjs.com/playground/#IXC3G .

 

In this playground demo, the virtualJoysticks won't work anymore, because I remove the vjCanvas that is appended onto document.body ... by virtualJoysticks code:

 

https://github.com/BabylonJS/Babylon.js/blob/master/Babylon/Tools/babylon.virtualJoystick.js  line 69

 

Clicking the RUN button (again)... no longer crashes the big-boy browsers, but it also fails to re-RUN... Compilation error - Node was not found.  Interesting.

 

It is becoming my theory... that the RUN button... does not "enjoy" having vjCanvas be document.body.lastChild. But the fail-to-re-run is interesting and possibly against that theory.  *shrug*  Party on!

[GameMonetize]

This is why I did not check the forum during my vacation

 

I pinged David (davrous) for this one

[GameMonetize]

Oh BTW I found the bug

 

Fix in progress!

[Wingnut]

Ok, let's see here.  Has "the fix" been performed?  (no hurry, or course)

 

Currently... regarding the 10 camera demo http://www.babylonjs.com/playground/#1EFJ1I ...

 

IE11 - gamepad camera... I see some "tops" of some text at the bottom of the screen... likely it's the "activate gamepad camera" line.  Other than that, looks ok.  It switches to other cameras (with button clicks)... just fine.

 

Firefox 30:  Select Gamepad... I fully see the "activate gamepad camera" text, but then the camera noses-down continuously (beta axis) and when I try to leave Gamepad camera and pick a different camera, it fails to change cameras:  TypeError: Argument 1 of Node.removeChild is not an object - babylon.js:15 .  Firefox only.

 

It's hard to find these errors in the error console... among the near-continuous "reflow 0ms" lines streaming to the console - at the playground.  I don't know when those reflow console messages started (within the last month I think)... but they suck.

 

The VirtualJoysticksCamera is looking much much better in both big-boy browsers (thanks to everyone who helped with that fix), but something happened to the GamepadCamera for Firefox... during the fix.  Any help with that... would be very appreciated. 

 

I think the FF camera switching problem would be the highest priority. (the type error)

 

We can address the camera nose-downing in FF after that. I could use some verification on this.  Do others see the continuous nose-down falling in Firefox GamepadCamera choice?

 

After that, we can talk about the mostly-offscreen "activate gamepad camera" text in ie11.  And I could use verification on that, too.  Anyone else see only the top of some text (at canvas bottom)... in ie11... with the gamepad camera?  Thanks everyone!

[JCPalmer]

 

It's hard to find these errors in the error console... among the near-continuous "reflow 0ms" lines streaming to the console - at the playground.  I don't know when those reflow console messages started (within the last month I think)... but they suck.

I agree.  Now that I can build a babylon.js it is just a matter of time before I hunt down that line of code to comment out when I am trying to use the console for my own debugging.

[Wingnut]

I don't know if they are caused by BJS console.log writes.  Wouldn't the filename and line number of the console message... be written in the right column of the console pane... if it was? 

 

Also, I don't see them in ie11, so that might tell me that FF itself is producing the reflow log writes.  Still learning.

 

Update:  https://developer.mozilla.org/en-US/docs/Tools/Web_Console#Reflow_events

 

They ARE coming from the browser, apparently.  I'll have a little talk with them about it.  (yeah, right)    Unclicking the CSS button seems to stop it.