continued_at_new_forum The Wingnut Chronicles

[GameMonetize]

For Octave, I have updated this blog with a way to make things works on IIS and APache:

http://blogs.msdn.com/b/eternalcoding/archive/2013/06/28/babylon-js-how-to-load-a-babylon-file-produced-with-blender.aspx

[Wingnut]

Hi, thx for the replies.  If all the assets for a scene... are in a folder called assets... located in the same folder as the scenestart.htm, and if all the JS is put in a folder called JS... located in the same folder as scenestart.htm... then XHR never needs to go cross-domain, right?  All the files needed to run the demo... are at 'principal', yes?  They are located 'under' the scenestart.htm.

 

 

Nice clean directory, all where it should be... and not a problem with XHR at all.  And here it is... running (rough) as a stand-alone.

 

http://urbanproductions.com/wingy/babylon/physics/physics.htm

 

In the recently adjusted zip... the folder structure is the same.

 

https://github.com/BabylonJS/Babylon.js ... I/we use that 'download zip' in the lower right corner... and suck every asset known to man.  But try to put the train demo into a structure like that in the picture... moving all its needed assets into /assets folder... and moving all its needed JS into /js folder...  forget it.  error: 0, manifest not well formed, fail... and I can't see why it fails.  XHR doesn't need to go cross-domain at all.

 

XHR should be happy, and according to the error log, it is.  There's another reason for demos that use .babylon (too-big-to-ever-beautify json?) files... failing.  Its not XHR as far as i can tell. 

 

Octave probably did (with Omega Crusher) exactly what I did for MY three failed attempts to get the train demo running at home.  Could somebody please explain... why the physics demo works fine at my home and at urban productions webserver...  and why the train demo and Omega Crusher... can't?  Why do demos with .babylon files... fail to work when all their assets and JS are local and 'under' the startscene.htm principal?

 

What am I missing, here? Am I being my normal 'stupid' here, somehow?  I do that pretty often, ya know?

 

Anyhoo... here's a cool threeJS-based toxiclibs-powered mesh generator that some crazy people made.  I think it will port to Babylon just fine.  http://urbanproductions.com/wingy/threeJS/sh/sh.htm  Why do I love dynamic geometry SO MUCH? I think its beautiful. Oh, and notice that it runs on ANY server or on ANY home harddrive. (wink wink).  Portable, ya know?  Hold the 'D' key while moving mouse = slew (ped and dolly).  Right mouse button drag works, too.  Hold 'S' key while moving mouse = zoom (truck-in/truck-out).

 

Yes, I know BJS is a community project, but the larger the community, the better, yes?  The easier it is for 'community' to learn and 'deal with' BJS, the more chance they'll stay and play, in my feeble opinion.  Merry Christmas, everyone!  I'll be working with BabylonJS today.  That's how much I care about it.  hehe.  (Ok, ok, maybe I just have no life.)

 

UPDATE:  I'm seeing some better results from the physics demo...  when less objects are dropped.  yay!  For my project...  I need small 'thrusters' with particle emitters. I think it will work... maybe.  Sometimes, for BJS Space Taxi 2014, a taxi pilot needs to fly into caves to get a fare or drop one off.  Now... make the particle emitter spray little tiny cubes, put the physics device onto the sprayed cubes... and we got a physics-ready spacecraft thruster.  YAY!!!  ahem.  The GameFX kids should have The Generic Physics-Active Particle-Emitting Spacecraft Thruster... DONE by now.  pffft.  hehe. BABYLON.createThruster(etc blah etc); 

[Wingnut]

Hi kids!  I modified DK's physics demo some more...  demented.  Its called rubber room.  You need to keep reloading it over and over and over and over and over... and every so often... its almost entertaining. Its just 4 gorgeous-textured boxes (from DK's demo)... but oh how they love their new trampoline.    I suggest getting a safety helmet for the camera operator.

 

http://urbanproductions.com/wingy/babylon/physics/rubber_room.htm

[GameMonetize]

.babylon files failed to load locally because they are not standard MIME type files and so they are consider as unsafe

[gwenael]

Could they have the json extension instead? Would they be considered as safe? I guess Deltakosh that you are not a big fan of this idea since you may want to keep the babylon extension when you use binary format.

[GameMonetize]

Exactly and for sure .json won't be safer alas

[Wingnut]

Thanks for the replies... I am starting to understand.  I appreciate the patience and kindness you have shown.

 

I'm playing with a dynamic babylonJS system sniffer today.  Man, I suck at coding. :/  But I can tear up a guitar!

 

Here's the sniffer so far...

 

http://urbanproductions.com/wingy/babylon/dynasniff/sniff.htm

 

At least THIS pathetic make-an-api attempt doesn't need manual updating like my last attempt.  It also doesn't cover as many aspects of BabylonJS, but its ok for the newbies... like me.

[Wingnut]

Hi

 

I was thinking some more about the PAPEST (physics-active particle-emitting spacecraft thruster).  I think it will need 4 particle emitters on it. One for fire on/off, one for smoke (exhaust) on/off, one for ice crystals or soot (longer duration particles)... and one for physics... which can probably stay the quads that they are now, seeing the physics engine does planes.

 

So lets say my space taxi's right rear lower vernier thruster... is within a few inches of a physics-ready cave wall.  Fire the thruster... and the fireEmitter... COULD be close enough to "fan-out" as it hits the cave wall, but maybe that's asking for the moon.  The smokeEmitter... REALLY could use fanning-out as it hits the wall (collision and restitution (recoil))... as that would look sweet.    The ice particles and soot... (debrisEmitter) could REALLY REALLY use fanning-out as its particles hit the wall... cuz then they could drift past the running lights on the taxi and twinkle and sparkle cool.    And the 4th emitter... is pure physics... so probably emitting invisible physics-active quads... against a physics-ready cave wall.  Or, under normal open-space conditions, those quads would push against space molecules or air... which would likely be an invisible physics-ready plane or completely faked (faked is probably the best way - no physics really needed in open space).

 

Probably no geometry to the thruster by default, huh?  We want game authors to attach the thruster to any geometry.  Or maybe... optional cone or box-with-cone.  *shrug*  "A Frustum of Thrust'em" 

 

Thoughts? Ideas? I know smart people have built these things before, so I'm just grasping at straws, I suspect.

[Wingnut]

Hi!  Yet another demo from the fine people at http://www.3delyvisions.com/ and, from the fine folks at BabylonJS... and me! 

 

http://urbanproductions.com/wingy/babylon/skyboxes/skybox_tour.htm ( .zip is there also )  Please talk to the folks at http://www.3delyvisions.com/ for licensing information.

 

39 skyboxes in one... 'thing'.  Its pretty fun!  I had a good time making it. 

 

Control-mousewheel to change font size on the 'toolbar' gui in the scene.  I hate when it wraps, don't you?

[GameMonetize]

Excellent!!

[Wingnut]

Thanks deltakosh!  Truth is, the 'excellent' BabylonJS framework makes it easy and automatically beautiful... along with some help from some fine texture makers. 

Generally speaking, I have a hard time finding the scene, engine, and scene items... when I'm inside of a function (without using a global).  They are out of scope.  I think if the BABYLON object had a getScene(sceneName) and getEngine(engineName) or something like that... I could re-lookup the handles to scene objects easier... within the funcs.  Maybe it already does. 

I'm real new at all this and not a very good JS coder. I'm sure I'll improve at it.  Suggestions certainly welcome.  Thanks!  And thanks again for the fantastic framework... its quite fun and easy.  And yay for the Sokrates API doc too, eh?  HANDY!  And yay for Dk's shadows demo, which started it all. 

Did you start writing PAPEST for me yet?  C'MON!  hehe.  (I'm lazy, huh?)  A physics-ready particle emitter... the more particles speed or amount, the more 'restitution' (thrust-force).  I'm scared!  I think that's going to be difficult... but when in doubt, I can fake it!  I already tested 4 particle systems on one emitter object... works fine.  Beautiful, too.  Confetti machine.    Hope everyone's well.

[Wingnut]

Hi

Hey dk... (if you are around)... do you think the skybox tour is good enough to get that 8th slot in the 'third party' section of the BabylonJS main webpage?  Maybe after you tweak it per your liking?  Feel free to tweak, and feel free to ignore me, too, of course.

I'd be totally honored if it was good enough to own that slot, but I'd want credit to go to http://www.3delyvisions.com first, and me second... if there's room for all that.  YOU should get a bunch of credit too.  It uses your framework and started by modifying your shadow demo. 

And if not... no big deal... I'll make something even cooler... and I'll eventually get that 8th slot.  Its calling my name. 

Ok, maybe the 12th or 28th or 100th slot... but I'll get there, someday.  Its just a matter of time.    Thanks.

Maybe the 'third party' section is for actual applications and is not a good place for scene making 'helper tools' like skybox tour.  I understand.

[GameMonetize]

The 8th slot is yours:)

Just send me a 400x250 jpg pictures and a title (short) and the credit you want (not too long)

[Wingnut]

ALRIGHT!!!  YAY!  I'M FINALLY 'SOMEBODY'! 

 

The screenshot is...

 

http://urbanproductions.com/wingy/babylon/skyboxes/tour.jpg

 

The JS could be...

 

{ title: "3delyvisions SKYBOX TOUR", url: "http://urbanproductions.com/wingy/babylon/skyboxes/skybox_tour.htm", screenshot: "tour.jpg", size: "by Wingnut" }

 

Adjust as wanted.  I haven't been in contact with the folks at 3delyvisions at all.  I hope they are cool with all this.  They were given attaboys on 18 of the cube bottoms, so, maybe they are happy.  If not, they will likely tell us.    Also, feel free to host this on a webserver of your own.  My buddy's webserver is solid... but... it could weeble and wobble someday.

 

The first 18 skyboxes that I got from 3dely... had only 5 textures.  I had to make a 6th (bottom) for all of those, so why not use them to talk talk talk... something I apparently LOVE to do?  See, I was born on the planet called Radio Shack Color Computer, and then I moved to Commodore 64, a fun planet.  After that, Commodore 128, and then Amiga 500... and then... Win 3.1-486.  Now I live with a Dell "Walmart Special"... and she has treated me well for 3 years now... but she can't cook food worth a hoot.  hmm.

 

THANKS DELTAKOSH!  Very cool!!!  YAY!  I have already put 8 hours into Space Taxi 2014 (mostly making a 'work grid' out of thin strips of createGround).  Be ready!  Babylon JS is a game-making MACHINE!  PS: That WorldMonger water... custom shader stuff... is JUST GORGEOUS!  WAY nice!  (droool)

[GameMonetize]

LOL:)

 

I added you for the next update (Mid January).. Thank you very much for your support!

 

( I had an amstrad464, an ATARI STE, an AMIGA 520 and then a 486:))

[Wingnut]

  Amstrad.  I haven't heard that word in a LONG time. 

 

Not much news in Wingyville.  I began work on the PAPEST thruster...

 

http://urbanproductions.com/wingy/babylon/thruster/js/thruster02.js

 

(I don't know much about object constructing so I stole a template from BJS)

 

Work happening WITH it...  http://urbanproductions.com/wingy/babylon/thruster/thruster10.zip

LOTS of fun work ahead yet.  I hope everyone is well!

[Wingnut]

Hi kids!  Quick question (yeah right) for anyone.

 

If a guy had a json-ish structure like this...

Tetrahedron : {"name":"Tetrahedron","category":["Platonic Solid"],"vertex":[[0,0,1.732051],[1.632993,0,-0.5773503],[-0.8164966,1.414214,-0.5773503],[-0.8164966,-1.414214,-0.5773503]],"edge":[[0,1],[0,2],[0,3],[1,2],[1,3],[2,3]],"face":[[0,1,2],[0,2,3],[0,3,1],[1,3,2]]}

...is that enough information to draw one in BJS? I see positions, normals, uvs, and indices mentioned at the bottom of the BJS CreateBox... but I'm not educated on those things yet. Do I need some 'indices'? Any nudge in the right direction would be highly appreciated. Hope everyone is well!

[GameMonetize]

You already have everything you need the indices are the array called faces here

[Wingnut]

  Oh I have everything I need, eh?  I was hoping for a LITTLE bigger nudge... but I'll take whatever I can get.  There's lots of reading that I need to do... about mesh.  It makes my brain a 'mesh', that's for certain.  Ok but...  sigh...

 

    box.setVerticesData(positions, b.VertexBuffer.PositionKind, updatable);
    box.setVerticesData(normals, b.VertexBuffer.NormalKind, updatable);
    box.setVerticesData(uvs, b.VertexBuffer.UVKind, updatable);
    box.setIndices(indices);
 

Its from the bottom of the bjs mesh.CreateBox.  FOUR things are getting stuffed into somewhere for some use.  In that json snot, I only have three things.  edges = normals?  And uvs?  Not included?

 

Objective... http://stemkoski.github.io/Three.js/js/polyhedra.js

 

Yes, its enemy territory, but its good stealable data that we could use around here.  I wish they were completely generated by JS instead of needing these pre-made coordinates, but I haven't got the math.  ALL in ALL, I think stealing that bucket of hedra is a worthwhile cause for ALL game-devvers using BJS.  They are interesting models that can be scaled, look pretty in games, have great low poly-counts, and SOMEBODY besides me COULD run-with that project.

 

We really really really need interesting 'hedra'!  And maybe some flat shading.    http://stemkoski.github.io/Three.js/Polyhedra.html  Look at that thing!  Stemmy is a GOD of webGL.  Too bad he's workin' for the enemy. 

 

YAY, CreateBox2() works!  I can make uncapped (tubed) long square-stock beams!  16 footers!  I need to build the flyerframe... similar-to a tall 4-post bed with no mattress or box... with 24 thrusters on it.. 6 on each bedpost.  A 'flyer' sort of like a spacewalker SAFER unit.  Its an object... lets ya set width, height, length.  THEN... users can instantiate one... and then strap (parent) it to ANY model, and it can fly!  Got a model of an old Winnebago camper?  Import that puppy in, slap-on one of my flyerframes, grab an official flyerframe controller, and go flying in your Winnebago!  FUN!!!

 

I feel the needra... for hedra!  sigh.  Its hard.  Mathematical.  sigh.  People as dumb as I... should not have to code the town's cool hedra generators.  There's got to be SOME math Gods using BJS, yes?  Who should I beg-to?  Am I whiny enough?  heh

[gwenael]

Hi Wingnut,

 

I've never played with Three.js, is http://stemkoski.github.io/Three.js/js/polyhedra.js an example of mesh file for Three.js like the .babylon files for BabylonJS? If it is and if they allow us to do that... we could write an exporter from Three.js to BabylonJS and you'll be able to import http://stemkoski.github.io/Three.js/js/polyhedra.js kind of directly in BabylonJS.

[Wingnut]

Hi gwenael (and everyone else)!  Good to hear from you again. And may I say, that is one interesting question/thought.  I'm probably not qualified to answer... but I can give you my 'take' on things.

A .babylon file is also a json/js as far as I can tell, but they are used to hold an entire 'scene'... and the formatting/structure of a .babylon file is specially made for the BJS 'SceneLoader' function.  The BJS SceneLoader uses a built-in-to-javascript device/object we call 'XHR' (XmlHttpRequest) to load a .babylon file, and then fancy code behind our SceneLoader... disassembles that file into a BJS scene.  The XHR object was security tightened a while ago... and it now causes problems when trying to work-with BJS demos that use .babylon files... when trying to load/view them off-line.  It has to do with allowed mimetypes for the XHR object.  As far as I know, .babylon files ARE a type of JSON/JS... but the JS objects 'grown' from a .babylon file... are specially designed for BabylonJS systems.  The code behind our SceneLoader command... understands exactly what to do with those objects and with THAT type of JSON structure.  Also, a .babylon file is quite compressed... and often too large to run through a 'beautify json' utility.  IF you WERE able to run a .babylon file through a beautify, the result might look quite a bit like Stemmy's polyhedra.js file... but there would be LOTS MORE of it.

Stemmy's polyhedra.js file... is being used as a database of 'shape definitions'.  Right about here... it might be wise to take a browse through the 6 BabylonJS-based experiments found here... https://ehret.me/page/2/ .  The github address for that is https://github.com/SiegfriedEhret/webgl-experiments and the polyhedra makers FOR those experiments is in that 'JS' folder.  Sniff around in there.  Our own CreateBox command... (2/3 down into https://github.com/BabylonJS/Babylon.js/blob/master/Babylon/Mesh/babylon.mesh.js ) uses the very same 4 final 'set' calls as Ehret's experiments pages... which are the 4 calls I listed in my last post.  These 4 calls have nothing to do with our SceneLoader at all.  They are instead made to take numbers... vertex, faces, normals, uvs, indices, and other alien debris... and make shapes out of them.  Ehret's experiments show how they work.  The code in our BJS CreateBox() just 'generates' those numbers with a fancy FOR-loop instead of using big greasy arrays like we see in Ehret's stuff, and like we see in Stemmy's polyhedra.js.  If you were to take a copy of BABYLON.Mesh.CreateBox function and paste it into your own code as a standard function... then call it with the correct args... but do this at the bottom...

    box.setVerticesData(positions, b.VertexBuffer.PositionKind, updatable);
    console.log("var positions = [ " + positions + " ];");

    box.setVerticesData(normals, b.VertexBuffer.NormalKind, updatable);
    console.log("var normals = [ " + normals + " ];");

    box.setVerticesData(uvs, b.VertexBuffer.UVKind, updatable);
    console.log("var uvs = [ " + uvs + " ];");

    box.setIndices(indices);
    console.log("var indices = [ " + indices + " ];");

 

(there's also a 5th call... for colors, sometimes)

 

...you would see in your log... that our CreateBox() function makes those very same big arrays of numbers... which are very much like those seen in polyhedra.js.  BUT... the array names are different.  So I don't know what to put where... in order to get those polyhedra to 'plot' in BJS.  Its very likely that its quite easy to do... for those who are more experienced than I... which is almost everyone.

Now, lets shorten this up.  Although a .js/json file COULD be used to store scenes for three.js, it is NOT being used for that in polyhedra.js or polyhedra.html.  It is being used as a little database of 'folders' of 'hedra definitions'... much more simple and basic than our .babylon files.

If you look at the source for http://stemkoski.github.io/Three.js/Polyhedra.html ... inside there... he just 'includes' polyhedra.js ... via... <script src="js/polyhedra.js"></script>.  Sniff around in that html source.  Doing that include... creates an object called POLYHEDRA... and early-on in his code... he does displayPolyhedron( POLYHEDRA.TruncatedIcosidodecahedron );  (the starting polyhedra).  We (BJS folk) could also include polyhedra.js in any BJS project, and the POLYHEDRA object would be there for BJS use too.  No need to use SceneLoader.  But... nobody has written a displayPolyhedron(data-from-THAT-JSON-structure) for BJS (yet), and in a way, I was sort of begging DK (or anyone else but me) to write one for me/us... because I am extremely lazy and don't like learning. haha. 

 

So, to TRY to be brief yet again, YES and NO.  Yes, a .babylon file IS a type of JS/JSON, so in that way... they are the same.  And... NO... the two files are not being used in the same way.  We CAN include-in that polyhedra.js file into our BJS projects just fine, and using the same method as Stemmy did (with a SCRIPT element).  We just don't have the code to do something WITH that data once we have it in our own POLYHEDRA object.

I'm sure others will want to correct me where necessary and make a few additions... so maybe give it some time before you reply.... let others correct my babble-on.   I don't guarantee that ANYTHING I've said here... is correct.  Its just MY understanding of it all.

Phew... what a great question and a terrible question all in one, gwenael!  Don't EVER do that again!  haha!
 

[Wingnut]

Hi girls!  An early version of the 96 particleSystem (4 per thruster) completely dynamic 'FlyerFrame' with all thrusters running (not normal in standard flight)... can be found here... http://urbanproductions.com/wingy/babylon/thruster/thruster10.htm .  Zip file is there, too... just change the .htm to .zip and re-browse.  This also has a new (s)ave camera views feature... for both of the cams in the demo, one arc, one free.  It uses sessionStorage so it holds thru scene edits.  Change it to localStorage object to save cam positions for MONTHS! 

 

Borrow those two funcs... just remove/workaround any refs to my GO object (global object).  Look for funcs called storeCamLocs and loadCamLocs or similar.  And may I say, even on my feeble machine... and even with 96 particle emitters running at once... we're still cookin'-fast. YAY!  (Firefox 21)  Not quite as smooth in IE11 though, for me.  Generally (in game environment), there's only 4 thrusters operating on the flyer at any given time.

 

No physics on the green particle sprayers yet... coming soon.  No thruster controllers done yet either, also coming soon.  Use 'c' key or button to toggle between the two cameras. The free cam starts badly positioned yet (bug).  Just swing it around (and then hit 's' to store its position for further reloads if ya want).  't' or tracking button... toggles camera tracking.  SHIFT-NUMPAD 2/8 will move the flyer up and down thru the scene... and do some fun particle trails. 

 

thruster02.js and flyerframe06.js... full of nightmare code... and so is the htm file.  FUN!  Lunar Lander, anyone? 

[Wingnut]

Hi again!

   So, today I fire up cannon.js on the 24-thruster flyerframe... and try out the dreaded setPhysicsState() and applyImpulse()...  put it on the 'box' that is the handle for the flyer... its master parent.... in the center of the frame.  Spin spin spin... no probs... but could only get it to 'translate' flatly... up the y-bar.  I could NOT get a translation on X or Z.  No matter what I seemed to do (other than flat trips up/down the y-axis), the flyerframe rotated/tumbled.  So, I read read read... find out about applyForce()... which is REALLY what I need.  Vernier thrusters like mine... are a continuous force, not a kick or punch impulse.  More accurately... for flat translates... I need applyCentralForce()... which is around, but not in cannonJS.  Lots to learn yet, and not many demos.

 

Ok, so, now the funny part.  I DO have good y-axis translating with applyImpulse... AND... each thruster... pushes on ITS y-axis.  SOooooo... I setPhysicsState on all 24 thrusters, set their thrust vector to THEIR y-axis...  and then bravely impulsed thruster #1.  Control-r...  POOM!  (actually, nothing THAT dramatic)

 

Almost all the thrusters lost their rotations... but their positions were fine.  In other words, the three thrusters at the top of a y-bar... were still there... just rotated oddly.  And what happened to thruster #1 you ask?  He gallantly left the flyerframe... flew past the camera... waved to the audience... and became yet another piece of space debris.  I was SO proud of my little astronaut.  I gave him a NASA-grade salute... and tossed him a bag lunch on the way past.  It all happened so fast that I didn't get a chance to ask him why he was ignoring his .parent property.    I have a feeling that the reason they lost their rotations... was because they no longer had a parent.  But wait... they KEPT their position atop the ybar, so the POSITION from parent... was still there, but not the rotation.  But if the POSITION was still well parent-attached... why did thruster 1 go on vacation?  Shouldn't he have taken the flyerframe WITH him?  hmmm.  Phun with Fiziks!  YAY!

 

I went out for a beer after that.  Life is good.    I think I'm going back to working with flyerframe.handle again... but who the hell knows?!  Cheers!

[Wingnut]

Hi yet again!  Wow, nobody corrected anything I said during my babble-on with gwenael.  Maybe YOU better come-in and correct my mistakes, now, gwenael.  I've been reading some of your posts in other threads... and you are a pretty sharp cookie. You didn't ask that sceneloading question just to mess with me, did you?    I'm pretty gullible.

 

Ok, back to the physics crap.  As best I can tell... setPhysicsState() is screwing up mesh rotations.  Here is a picture of a messed-up ybar... just after having its setPhysicsState done.

 

 

It lost its rotation. I was testing constraining (setPhysicsLinkWith) the runaway thruster #1... to ybar1.  The rotation (and position) settings on ybar1 were the same numbers before and after the setPhysicsState()... but visually, something is wrong.  We can also see the rotation problems happening on the thruster ports... after THEY got their setPhysicsState() done.  Something is not right.

 

In a wild guess, I'd say that the imposter is not being rotated to match the object that its impostering-for.  But like I'd know.  All in all, I think this might be some kind of implementation problem.  HELP!    I'll keep experimenting, though.  Hope everyone is well!

 

PS: http://urbanproductions.com/wingy/babylon/thruster/thruster11.htm  (phew) WASD on this one... not cursors or numpad.

[GameMonetize]

To keep things simple, I do not take in account rotation. So (for now) you have to create your object with baked transformation (sorry about that )