continued_at_new_forum The Wingnut Chronicles

[gwenael]

Hi Wingnut,

 

About "it now causes problems when trying to work-with BJS demos that use .babylon files... when trying to load/view them off-line" of your post, you may be interested by http://www.html5gamedevs.com/topic/3083-spaces-world-parent-pivot-local/?p=19938.

 

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

 

I don't really have time right now to work on the question but I'm pretty sure http://stemkoski.github.io/Three.js/js/polyhedra.js could be automatically parsed and transformed to a .babylon file like it's already done to convert from Blender to BabylonJS.

[Wingnut]

Thanks gwenael.  You must have seen my arrows.    Yeah, worldspace, localspace, matrix transformations... ouch.  Unfortunately, I couldn't get Wcegj to run on jsfiddle for me.  But I'm not sure what that has to do with the XHR cross-domain and mimetype situation.  I'll think on it, though.  And, converting polyhedra.js into a .babylon file and expecting something magical to happen when parsed back into BJS scene items... seems like taking the long bus to school.  But I'll ponder your thoughts just the same... and maybe do some experiments... seeing the flyerframe project has come to a gruesome halt.

 

Thanks for the info, DK.  I THINK I understand what you mean by baked transformations. The items which require physics... must not have a .rotation setting, right?  They must be modeled in such a way as to not need .rotation, or each locally-rotated item must be sent thru Mesh.bakeTransformIntoVertices(transform) with the proper matrix... to have their rotation and position set back to 000/000?  (while keeping them properly rotated for the scene.)  They get 'nulled out' to origin... without changing their rotations in the scene... because of the applied matrix transform?  Hard to explain, especially for me.  I suppose there is no...

 

mesh.null_rotation_settings_while_keeping_this_object_in_current_rotational_attitude()

 

...function, huh?    Sigh.  I'm screwed.  Project screwed (physics-wise).  Its ok.  A lack of applyCentralImpulse() (on the flyer's handle) was going to take me out of the ballgame anyway (IF I couldn't get each thruster to have impulse).  I need flat x/z translations... whether by individual thruster impulses, or by flatly impulsing the handle (centralImpulse). 

 

http://urbanproductions.com/wingy/babylon/thruster/thruster12.htm is still sort of fun.  WASD for camera... SHIFTED numpad 2, 4, 6, 8, +, - for doing rotating translations (except up the y-axis - that's nice and flat).  I'm going to go cry now.  :/  Thanks for the replies, guys.

[gwenael]

Oops, sorry, actually it was a wrong "paste". Here's the right link: http://www.html5gamedevs.com/topic/3062-visual-studio-solution-to-work-on-babylonjs/?p=19818

 

But glad to read that the other one is interesting for you too.

[Wingnut]

Hi friends...

 

I've been playing with the great hedra quest...

 

http://urbanproductions.com/wingy/babylon/hedra/hedra01.htm  (.zip is there too)

 

I didn't include-in polyhedra.js with a script element... I just pasted its goods into an object variable.

 

As you can see... mission successful... errr... no, not really... not at all.     

 

No wasd for cam controls... back to cursors/numpad for this one. Two cams choosable with 'c'.  There might even be a 'g'round onboard.  It might even go up and down with -/+ keys.  One just never knows what leftovers are still there from the skybox tour. 

 

Included also is Stemmy's hedron drawing routines... remmed-out of course.  It looks heavy.  I got a little tumor while looking at it.  I have a funny feeling that the Y coords and the Z coords in the vertex array... need swapping.  I'll test it someday... or somebody else can run with it.  PARTY ON!

 

PS: Don't go sneaking in there and turn on wireframe for the material.  THAT much wire would surely electricute something dear. heh

[Wingnut]

Yay, I was able to make a modified CreatePlane(name, size, [nz, pz, nx, px, nz, pz], scene, true) for my own use!  I think I'm starting to master this vertex plotting goofiness!  SO...  in theory... any particle emitters that use these plotted-already-oriented planes... will spray particles in the (baked?) orientation direction... without needing rotation!!!!  THERE'S HOPE!!!!  YAY!!!    (baby's first steps)

[Wingnut]

Hi gang!  Anyone want a challenge? (possibly JS scoping prob)  http://urbanproductions.com/wingy/babylon/misc/test_jig.htm  (.zip is there, too).  Problem area marked.  This test jig calls my now-famous CreatePlane2.js... http://urbanproductions.com/wingy/babylon/misc/js2/plane2_02.js .  The blue plane is a standard CreatePlane.  The white/no-material plane is a neg-z facing CreatePlane2.  Pardon my bad JS object-making, please... but DO advise/suggest improvements.

 

To try to be as brief as possible, when one of my 'plane2' comes back from its creation, it will not take a material.  It also will not .position with a vector3 anymore... but it WILL .position.x, .y, and .z fine.

 

    // var nz = new BABYLON.Mesh.CreatePlane2("nzp", psize, "nz", scale1, scale2, sm2, scene, true); // mat works
    var nz = new BABYLON.Mesh.CreatePlane2("nzp", psize, "nz", scale1, scale2, "", scene, true); // no mat - ok
 

CreatePlane2 (lets call it cp2)... allows a 6th arg that CAN be a material, or not.  If left empty quotes, cp2 puts a standardMaterial onto the created plane, but sets no other settings on that material.  When the plane returns to the caller, settings can be made to nz.material just fine (diffuseColor, etc).  But if a full standardMaterial is added by the caller after plane2 returns, it fails to take a new material... whether a standard material was installed during creation, or not.

 

So, to be brief, planes coming back from cp2... will not take a new material and will not allow positioning with a vector3.  But the planes coming back from the default BABYLON.Mesh.CreatePlane... which are oriented -z just like my plane2... will take a material fine, and allow a vec3 for positioning fine.  I want plane2's to do the same, of course.

 

I really tried to make a very complete object template for cp2... copying many settings from BABYLON.Mesh... trying to get my plane2 construction to be fully BABYLONized.    I'm not very good at it.  ANY help or advice would be MOST welcomed.  This is not a show-stopper situation for me... it can be worked-around.  But I am curious about what's happening and would like to learn about it... so I can avoid the problem next time I make a new BABYLON-ready JS object.  THANKS!!  No hurry at all.  Ask questions.  And no, no JsFiddle... that thing failed me and its annoying.   Zips are better.

[gwenael]

Anything in the javascript console of your browser?

[Wingnut]

Hi.  Nothing pertinent.  1 TypeError and 5 Reference Errors (warnings)... all from babylon.js... which is a suprisingly low count of warnings from BJS.  When I fire up the flyerframe, I get about 10 from BJS and another 10 from jQuery.  Its quite a challenge to find a pertinent error amongst the pile.  How about in yours?  I would have included any pertinent errors in my comments.

 

On another subject... I fired up the new CreateBox4 that uses the new CreatePlane2 to make the first box of the new flyer.  IT needed a handle (proxy) to parent all 6 sides of the box-to... so I have a custom box with a standard box inside... the parent.  Do you think I can get a .position to work?  NO.  I lift the handle box up the y-axis... I see it go up in the air... but the 6-planed box won't follow it.  It acts like the 6 planes aren't parented to the 'handle' box.  VERY frustrating. 

 

I got what... about 28 hours into making my first physics-ready box... and I need to use this physics-ready box-making method... to make every single piece of the flyerframe... if I expect its frame to bounce (recoil-impulse) off things it might run-into, laterally.  Certainly not "just one line" seen around here anywhere... in a long time.

 

I don't know what to do.  If/When impulse is eventually ready for all three axis and can do applyImpulse AND applyCentralImpulse() on all three axis... will all this workaround be wasted?  I got another 30-40 hours just to get the frame rebuilt with all outward-facing planes, and its fighting me all the way.  I guess it would be wise to make CreateBox4 and CreatePlane2 be standard funcs inside the flyerframe constructor... instead of making them each be constructors of their own.

 

Anyway, here's CreateBox4... http://urbanproductions.com/wingy/babylon/misc/js2/createbox4_01.js ... what a nightmare.  Needless to say I'm pretty discouraged.  In my opinion, the announcement of adding cannon.js to BJS... was much too premature.  I'd really like to help get the physics engine FULLY ready, where balls didn't go through walls, or boxes through floors... but its still over my head.

 

I guess I'll start with the most rudimentary question.  Once I make a box out of 6-outward-facing planes, is there a way to 'convert' it into a standard object... where I can use ITS .position instead of making a handle inside it and parenting all 6 planes to the handle?

 

Is the problem I'm having with positioning that handle and having the 6 planes follow it... caused by making my new CreatePlane2 and CreateBox4 as separate JS objects... as opposed to just making them functions inside flyerframe.js?  It seems... when I make them each be object constructors... they get stupid... returning without being able to take materials and/or be positioned.

 

I THOUGHT.... MAYBE... since parenting the 6 planes to 'handle' (proxy box) was appearingly failing, I thought MAYBE...  push the 6 planes into the new box.subMeshes... would make it so if I moved box, the planes would come along... and box would act like a single object.  Nope.  My new 6-plane box just does not want to position... whether I use its handle, or try to use the box object itself. 

 

DK/Team... any estimates available as to if/when the physics system will be fleshed-out?  (Where I can impulse flat translations or rotations on any axis of objects with any rotations).  Does anyone even understand what I'm saying?

 

Unfortunately, this is all very hard work.  We'll see how this all looks by the end of today... AFTER the snowblowing, though.  Sorry if I'm being a pain... but this is tough going.

 

Update:  Now that I think about it, restitution SHOULD work for when the flyer collides with something and needs a recoil/bounce-off.  I don't think I'll need to do those bounce-off impulses myself.  But I still need to re-model the entire frame with baked rotations, so that when I setPhysicsState on any flyerframe part... it doesn't rotate out of position.  YEE HA! 

[GameMonetize]

About physics, it will be probably next week

[Wingnut]

Hi dk, and thanks... that's plenty fast.  I hope I'm not being a pain, and I don't envy your task.  I put my CreateBox4 and CreatePlane2 inside my FlyerFrame.js... as functions on that object... and things started acting much better.  I think maybe "use strict" is the problem(s) with making cb4 and cp2 separate files/JS-objects.  It seems that 'use strict' tends to really isolate namespaces from each other (like I know anything about namespaces). 

 

cb4 now makes any-axis-oriented boxes with setable width, height, and depth... capped or not, with all outward-facing (oriented without rotation) planes. There's a proxy object inside each (a handle)... and moving it, moves the box just fine (all 6 planes are parented to it).  YAY!  WORKS GREAT... and only 150,000 lines of code!

 

PLUS... by making the flyerframe out of 6 separate planes per rail/bar... when it comes time to blow-up a space taxi (lunar lander)... it should blow-up REAL GOOOOOOOD.  Lots of pieces.    I like that.  DK/team, sorry if I'm pushing you/team on the physics fleshing. I hope I'm not messing up your life/lives.  Ignore my whining whenever necessary... I'll get over it.

 

Anyone want a brain tumor?  http://urbanproductions.com/wingy/babylon/misc/flyerframe10.js Lots of rem'd code in there... but all the tools are ready now... for the flyer rebuild.  Right now it just produces 3 custom boxes.  Okay, its time to snowblow AGAIN.  Hope everyone's well!

[Wingnut]

Well, here's the newest incarnation of the beast from hell.    http://urbanproductions.com/wingy/babylon/thruster/thruster16.htm . Flat translations turned-on nicely... but... hmm.

 

Let's say you use SHIFT NUMPAD 2/8 to Z translate.  THEN, if you want to Y trans or X trans after that (shift numpad +/- and shift numpad 4/6), gotta reload or else she spins.  I think it needs a constantly updating contact point vector, and I haven't determined how to do that yet. Control numpad 2,4,6,8,+/- are also wired-up... they are to eventually be used for rotating the craft.

 

I have been working with both impulsing the flyerframe's standard box handle/proxy (SHIFTED numpad keys)... and with impulsing the individual thrusters themselves (ctrl-numpad-6).  Thruster #1 is atop the -X plane (red) on ybar1.  I have tried my brains out... to setPhysicsLink thruster 1's port (its emitter plane) ... with ybar1's NX plane (red) (go.ybar1.nx).  As soon as that link is made, ybar1.nx red plane... disappears.  So, the link is still not made. 

 

Zoom a camera up to the top thruster on the red plane, and hit/hold control numpad 6.  You'll see the thruster port (emitter) start tumbling and fly-off down the PX axis.  "See ya!  Wish you had a link to your mounting surface!"  hehe.

 

Control Numpad 6 is the only impulse-the-thruster being tested at the moment.  Naturally, the flyer would be LOTS MORE FUN if we could impulse on any thruster... instead of all simple rotations and translations on the flyerframe's parent.  Impulsing at each thruster is much more realistic than impulsing on the flyerframe's center parent/proxy/handle (later invisible) (is now too, I think) (its a red 1 1 1 box at scene origin).

 

Oh well... progress made, learning attained... I hope it all turns out good in the end.  Feel free to use the flyer as a physics testing tool... ya know?    Get it working... esp for individual thruster impulsings... and win Wingy's heart FOREVER! 

 

Damned flyerframe controller is getting kind of fat and is a keypress nightmare, too, I tell ya. 

 

WASD on this one, kids.  No zip ready, but we all know how to suck it down using "save entire webpage" in the browser, eh?  Need textures... get them from any of the other thruster zips listed in previous posts.. nothing changed there.  (I'm feeling lazy, huh?)  Long hours on this puppy...  not much progress... but...  it feels like a miracle is on the horizon, so all is well. 

 

Take the flyer, DK.  Get her running for me... (ahem)... if ya want.  Its a team thing, ya know.  I think you know exactly what I would like it to do.  Its so close I can smell it.  Take a sniff.  Smell that?  Yummmm.  heh

[Wingnut]

Heya!  I just did a Google translation of http://www.catuhe.com/... good reading... you're an entertaining man, DK!  Need me to come rev my snowblower outside your bedroom window?    I enjoy the former bands called Asleep At The Wheel... and also Commander Cody And His Lost Planet Airmen.  It isn't quite Metallica... but it can still be played really loud.  hehe.  I see that YOU can be a bit of a talker, too, mister... so don't give me too much BS.  heh. 

 

So you like America's "be friendly OR ELSE" waiters and waitresses, huh?  We do as well, unless we have to BE one.  Then it sucks.  All of our 18 yr olds (except the rich kids) are under a "join the free marketeers and take orders.... OR STARVE, OR DIE, OR ELSE" felony extortion into a forced religion called the competer's church. (capitalism)  If anyone does a web search for "abolish economies"... you'll surely find more than 500 blog posts of Wingnut ranting about why capitalism... sucks.  (Actually, why using economies... sucks.)

 

Bessemer MI USA is unbearably quiet.  If a squirrel farts... everyone looks out their windows.  (I run a squirrel farm here... spending $50/mo keeping my beloved lawn rats fed in the winter.  All grays, with occassional black grays.)

 

Okay, back on subject now.  I don't want any blog warnings.  Hope everyone is well!

[GameMonetize]

eheh I would love to see your squirrel farm

 

I'm sad however because my keyboard does not have a numpad

 

BTW could you share a small piece of sample about your link problem? I will try to debug it:)

[Wingnut]

Hi DK (and others).  Ok, a new (much slimmer) version of the pig...

 

http://urbanproductions.com/wingy/babylon/thruster/t17/thruster17.htm

(.zip is there too)

 

This is for people without number pads.  This uses SHIFTED o,k, semicolon, period, pageup, and pagedown... for impulsing on the flyerframe parent.  (things around the L key).

 

BUT... if you use shift pageup/pagedown, then you have to reload before shift K and ; work right.  And then you need to reload before shift o and period work right.  Simply said... if the flyer starts tumbling... you needed to reload before you did what you did.    That's ONE problem... and I think its because the contact point vector needing to be continuously updated as the flyer drifts along.  In other words, translate the flyer back and forth on any axis... and after that... translating on any OTHER axis... sends the flyer tumbling.  Do a reload before you change to a different translation axis.  Experiment... its easy to see.

 

CONTROL o,k, semicolon, period, pageup, and pagedown... do the same thing EXCEPT for control semicolon.  Control semicolon is the 'impulse thruster #1 testing area'.  (the thruster at top of red plane)  Control semicolon does NOT impulse on the flyerframe's parent/handle.  Inside thruster17.htm...  in a function called physics_init()...

 

// THIS, DK. If this link works, red plane stays in scene... and thruster 1 won't fly away.

// link attempts...

// Below... makes go.ybar1.nx disappear

// go.flyfr.thrusters[1].port.setPhysicsLinkWith(go.ybar1.nx, new BABYLON.Vector3(0.5, 0, 0), new BABYLON.Vector3(-0.5, 0, 0));

 

un-remark that last line, and the red plane disappears.  Tightly link thruster 1... to go.ybar1.nx (the red plane)... and impulsing thruster 1 SHOULD take ybar1 and the entire flyerframe with it.  (in theory)

 

"small piece of sample"?  Nah.  You might as well get used to helping with the flyer... because IF we get it working, it will be the #1 coolest and most-reusable 'toy' ever made with BJS.  It will make us all superstars.    Please work on the actual flyer itself, if you would.  The impulsings happen in controller04.js...  in the CONTROL SEMICOLON keydown area (and in control numpad 6 keydown too).  Don't accidentally get confused and go to SHIFTED semicolon... or into the KEY UP areas.

 

Got all this?  I know, I know... small piece of sample is much nicer... but I need help getting this whole project to work... and it will be a blast for EVERYONE because its very reusable...  its for team!    Please?  Pretty please?  The flyer is very cool... especially if we get it working 100%.  Hell, just the highly-reusable PAPEST (physics-active, particle-emitting spacecraft thruster) BY ITSELF... is worth its weight in gold... for 10,000 future BJS projects... and we all know it.  The flyerframe is just as golden.  The GameFX kids should be drooling like hell over this. 

 

You can even take full credit for it.  I'm easy.  I just want to fly it.  THANKS DK and anyone else who works on it.

 

ALSO, if you're a Firefox user, this disables control-shift-k to open developer tools.  Use pulldown menu to open developer tools instead.

[Wingnut]

Continued thinking... I probably should parent the thruster port (its emitter plane)... to ybar1.nx plane, and not to ybar1 itself (the cube in the middle of ybar1).  But... createbox4 uses scaling done in createPlane2... to make the rails have 'depth' (length).  I could change that.  But currently, it uses scaling, and since children inherit the scaling of their parent... the thruster emitter/port becomes tall like the ybar... when it is parented to ybar1.nx.

 

Parenting... and setPhysicsLinkWith... have some relationships... I think.  Rotating and positioning a child... does not rotate and position a parent.  This might mean that even if thruster 1 DOES 'push'-on ybar1 because of the physics link, the whole flyerframe will not go with it. Only ybar1 would fly away. 

 

In a way... setPhysicsLinkWith...  should have a "linkAncestorsToo?" boolean flag parameter.  TRUE = impulse THIS object... and all of its ancestors (indirectly/offset-ly).  Maybe make it so that when impulsing a child... children CAN position and rotate ancestors (maybe).  Then the impulse on a child (ybar1.nx plane)... would push-on its ancestors as well (ybar1 and flyerframe.handle).  *shrug*

 

But if the thruster (its.port/plane/emitter)... was parented to the flyerframe's master parent... and IF thruster impulsings actually happened against corners of the flyerframe parent (at a contactPointVector commensurate with the thruster's position and rotation on the flyerframe)... then... hmm, maybe a better chance of moving the whole flyer with one thruster.  Currently, impulsing on children... will not transfer that impulse back up to ancestors... I suspect.  *scratch scratch*  This is harrrrrd. :/

 

[some yapping removed here  - Wingnut was being extremely stupid - not uncommon]

[Wingnut]

Hi kids.  I began some work on 'explosions' recently.  My hope is to use a modified particleSystem to spew standard mesh or boxes for a moment... each box having its physicsState set, and each having a particleSystem of its own... so that these pieces of debris have a smoke trail as they leave the explosion, then bounce along the ground for a distance... spewing smoke the whole time.  ParticleSystem gravity and physics gravity don't play well together, and/or boxes/planes don't 'emit' well out of a particleSystem.  My modified particleSystem is not yet operating well.

 

I'm not very good at modifying code... but I turned off the VBO's in my stolen copy of particleSystem, and replaced 'new Particle()' with createBox and createPlane.  Mixed results.  No demos to show.  I still need to turn off angular things and blending things in my modified particleSystem.  Its still mighty slow.  SetPhysicsState on the box particles really needs to be done in mid-flight so the boxes don't collide and react-against each other as they exit the emitter.

 

The particles need to be standard boxes (or spheres) so I can setPhysicsState on them and get them to tumble/bounce when they hit the ground (while leaving a cool smoke trail).  Hard goin'.  It takes a 'special' particleSystem to 'barf'-out 100 boxes RIGHT NOW and use the particleSystem's gravity settings while they fly... but use the physics engine's gravity settings for bounce restitutions.  My quest for flying, smoldering, bouncing explosion debris... might be a pipe dream.  Or would that be called a cylinder dream 'round these parts.    Hope everyone's well!

[GameMonetize]

Good luck, you're on the right way to become an expert of Babylon.js!

[Wingnut]

Thanks DK, that's nice of you to say.  Its easy to learn how BJS things work... when ya borrow a copy of a function from the package... and put a bunch of alerts/console.logs in it.  Its easy to forget that... its JS.  We are not required to operate using the rules of the framework.  We can sneak around and do our own strange demented experiments... and integrate as much or as little of the framework as we like. Anything goes.

 

I love particleSystems... they are one of the most beautiful things to be found in webGL, and the one in BJS... is sleek.  There's times I've had a gazillion (many) multicolored particles flying around... and speeds have stayed REAL NICE.  The BJS particleSystem works great and is feature-packed.  Nice work!  Its a blast!  Literally.

 

Last night... I was using my modified particle emitter to shoot physics-active spheres... straight up into the air (+y)... 250 of them.  I had a nice high restitution setting on the sphere imposters... and lots of emit-power going.  They shot straight up... vertical gaps in between them... way way up in the air.  They came perfectly straight back down... and bounced up and down the y-axis... gap-oscillations going up and down repeatedly through the 250-sphere-tall stack... took forever to stop bouncing.  I laughed my nuts off!! (squirrels showed up, of course)  I tilted the gravity on the physics engine... fired again... but they kept making that 250 sphere stack... over and over... they just would not fall over.    As the spheres bounced atop each other, you could see them compress and expand like rubber balls... amazing.  I think I lost about 2 hours of SERIOUS work...  while I played with the giant stack of rubber balls.  TOO FUN!

 

Another thing I always seek and drool-over... is glitter.  Sparkles.  Faery dust.  Last night... during one of my CPU-abusing spews of tiny boxes... I saw some pretty nice sparkles/glitter coming from flashes of light off the sides of the boxes as they bounced and tumbled around on the floor of the rubber room (your physics playground from the demo).  Pretty nice.  I'm thinking... put 2-3 spotlights BEHIND the camera... then running a standard particleSystem out in front... with some nice shiny material on the particles... and MAYBE get a glitter fountain going that way. 

 

The experimenting that can be done... is just amazing.  Its a HUGE play area.  And I see that our particle systems are effects-ready... which means custom shaders can be used on the particles, yeah?  OH MY GOD.  That's a solid YEAR worth of fun by itself.  Then there's animating lights.  Phew.  If a guy made just one spotlight behind the camera... and wiggled it all over hell (yet always aiming forward/+z) while spraying shiny particles out front... wow.  That should REALLY assist in the sparkling/faery dust. It just goes on and on and on.  I don't think I'm going to live long enough to try all the demented experiments that could be tried.   Party on!

[Wingnut]

Hi all!

 

http://urbanproductions.com/wingy/babylon/particlefun/splode/pharticles02.htm  (zip is there too)

 

Mighty strange.  Awfully slow.  Powerfully demented.    I got the restitution set much too high yet, but it looks cooler and lasts longer that way.  SetPhysicsState (on each box) just seems to take all the horsepower

out of the box sprayer.  Lots of collisions at the emit point, yet, too.  That's probably what slows down the emit.

 

If you look way up high, see the green plane?  That's the emitter for the boxes.  I put it up there.  The box sprayer doesn't seem to care. Its going to emit where-ever it damned well feels like emitting-from.  hehe.  Kids... DO NOT use any code in this maniacal experiment... to teach ANYONE to program.  You have been warned.  (snicker)

 

Be sure to fly the camera down into the actual mess for a nice  "Holy crap I'm in a war zone" experience.  Even though the ` key is disabled (unshifted ~)... its dark gray button on the gui still works (silently) to save current camera position.  That way you can stand three feet from the (actual) emitter... click that 3rd button (dark gray `)... and then hit control-r.  The camera SHOULD hold its position (ie11 and ff21).  That dark gray camera SAVE button is not COMPLETELY silent.  It does a console.log announcement.

 

Update: the demo and zip above have been updated to BabylonJS 1.9.0 on 21 Feb 2014

[Wingnut]

YAY... 8th slot in third party!  ( http://www.babylonjs.com )

 

Yeah, that's right.  I'm a hot commodity.  hehe.  (yikes)

 

I am trying a new(er) non-particleSystem method of exploding. I am producing a large pile of premade boxes, setting physicsState on them, and then I'm going to whack them from beneath with an impulsed sphere.  But, the old rubber_room problems are haunting me.  Often, box.setPhysicsState is making the box disappear, or at least SOME of them.  And, like the rubber_room demo (see earlier posts), they often fall through the floor.  Its strange that... when the boxes are emitted with a particleSystem, they hardly ever fall through the floor or fly through a wall.  And, they hardly ever disappear when their physicsState is set.  Yet, manually make a pile of them in mid-air, and there is trouble galore.  *shrug*  I also see things like...

 

scene.enablePhysics(new BABYLON.Vector3(0, 0, -2));

 

You would think that this would cause sideways gravity.  But no...  that's negative Y axis gravity.  *scratch scratch*

 

I get confused quite often, though... so take it all with a grain of salt. 

 

Nothing else to report.  Real life is sucking-up a bunch of my play time, lately.  I hope everyone is well, and keep on truckin', experimenters!

[Wingnut]

Ok, I'm going to announce this here, too, just in case i have any followers.  Over in another thread, DK fixed a bug and posted an interim new babylon.js at http://www.babylonjs.com/forumpics/babylon.zip .  This fixed a crapload of problems in my physics experiments... including the scene.enablePhysics(new BABYLON.Vector3(0, 0, -2)) being y-axis gravity... and including the disappearing boxes (NOT thru the floor, but when setPhysicsState is set on them) mentioned in my last post.  It also fixes things like the fall-thru-the-floor problems.  So, if anyone is experimenting with any of the physics demos mentioned in this thread... and struggling... then get the interim babylon.js mentioned just above, and use/install that... to fix quite a few problems.

 

I will also clean up the physics posts, demos, and zips in this thread... but be patient.  Its a big job and I don't know what I'm going to do about version managing. 

 

If anyone has stored any of my physics demos on their hard drives... please make an effort to replace the babylon.js in those demos... with the one in the zip link above.  Lets try not to spread around a babylon.js that has a less-than-optimal physics implementation.

 

I'll let thread followers know when I have time to test this on the flyerframe... and post a demo if/when I see any positive results.

 

Thanks DK, nice work.   Thread followers... thanks for your patience and home cleaning work.

[Wingnut]

Just for a quick test, I installed this interim BJS into http://urbanproductions.com/wingy/babylon/thruster/t17/thruster17.htm

 

(shifted numpad or shifted okl;, for thrustings)  (zip is there too)... and wow... changes.  Just load it, and fly up close to the thruster ports (little white planes).  They're drifting away!  Where are they going?  Did they forget who their parents are?  hehe (WASD cam controls here, kids)

 

The red -x plane of ybar1 is drifting away, too.  Did someone ring the recess bell?    Interesting.  Impulsing is...  acting different, too.  Not sure what's shakin'... but it will all be fixed when DK's version of the flyerframe arrives... fully IK-solved for thrusters mounted out on the children of the children of the children of spacecraft limbs.  (physics-impulsing thrusters mounted on the far reaching wingtips of spacecraft that are able to rotate/translate the entire ship).  Is that called IK?  Boneless IK?  *shrug*

[GameMonetize]

What was the preivous version number you were using?

[Wingnut]

Oh sure, like I can answer that. 

 

Umm, 1.8.0.

 

But now there's a 1.8.0.delta!=0 version, right? 

 

But the physics engine is still all screwed up, so none of it matters, right?  As long as setPhysicsState is resetting object rotations to zero... there's still more physics work to come, yes?  And now we have the drift-away problem to add to that.

 

You're the only one doing active dev, yes, DK?  And I'm the only one trying to make game dev base classes, cuz those kids over at GameFX who are supposed to be working on gamemaking tools... are asleep, huh?  You know them guys, yes?  The flyerframe is a super important gamemaking base class... and they haven't shown much interest.  I don't know.  Maybe that's not their intentions.  I wish I spoke French.  I wish their blog didn't type gray text on gray backdrop.

 

Sigh.  Where's it all going, gang?  BJS is the best framework around.  Its fast in multiple ways.  But when I seek to make a simple lunar lander game... I run into a hundred brick walls, one of which is a language barrier.  I'd much rather work on scene assembly than on fighting with physics engines... believe you me.  I hope nobody thinks I can do my own matrix transformations to get the flyerframe working properly.  Impulsing thrusters are one of the most basic gamedev needs... in my opinion.  If we do this right, we can give Kerbal a serious run for its rockets. 

[GameMonetize]

Almost the only one yes

 

Current version is 1.8.5 and for physics the only thing I added is support for quaternions meaning that if your object has an initial quaternion set to rotationQuaternion I take it in account