Jump to content

The Wingnut Chronicles


Wingnut
 Share

Recommended Posts

Thanks, I'll work on learning what that means.  I understand that you did not write cannon.js.  I'm not blaming anybody for anything.  I'm just saying that physics projects are tough-going from this framework-user's view (me).  If you ran my last version of the flyerframe, you see the thruster ports drifting away... even though they are parented to the y-bars.  I don't think that's right, and that changed since I grabbed the recent release of the framework. They were not drifting-away before that change.

 

http://urbanproductions.com/wingy/babylon/particlefun/splode/thump01.htm

 

Above is part of my explosion-class experiments... a quick demo that shows 25 boxes being placed in mid-scene... randomly rotated and positioned.  Then 3.5 seconds later... I setPhysicsState on them.  You'll see them all lose rotation.  But now I know what's causing that.  I need to rotate using quaternions... whatever those are.

 

It just feels like I'm having to plow heavy snow.  I guess that is understandable here in the early days of webGL.  Sometimes I expect too much... sorry about that.  Thanks for the replies and info on current version numbers.  And thanks for all the other things you do and don't get thanked-for, DK, and others.  I can start work on the next major base class for games... the gun/cannon.  It sort of pals-around with explosion.  :)  Lets see... thruster, flyer, explosion, gun, the basic pieces.  Still need ground vehicle.  See my vision?  You bet.  :)

 

Link to comment
Share on other sites

http://urbanproductions.com/wingy/babylon/particlefun/splode/thump02.htm  Workin' good, now.  Thanks DK.  I highly appreciate the assistance.  I've toured around a bit, and our physics is top notch in speed and smoothness.  Even the demos at the cannon.js website, using no framework at all... don't work as well as our physics demos.  And look at the size of cannon.js, compared to ammo.js.  Our physics system is maybe THE BEST webGL physics system so far.  Much of that speed and smoothness... comes from BJS itself.  its smokin' fast!  I like it.  CubicVR's vehicle physics demo is pretty nice, though. They did a nice job simulating vehicle mass... but oh... is their framework a pain in the butt.  If I wanted THAT much pain, I would have stayed with VRML 97 and the EAI.  :)

 

This quaternion option might also open up some new possibilities to get the flyerframe working, as well.  YAY!  Maybe not impulsings on the individual thrusters, but impulsings on the flyerframe's parent box (faking individual thruster impulsings).  YAY 2.0!

 

Just for kicks, I'll ask this likely-dumb question.  It is possible... to create a single bounding box around the whole flyerframe, and/or have it be treated like a single object?  I don't know if that would be useful to me, but I am curious.  I guess such a thing would be a kind of "group"?  Thanks for any leads/hints on that.

Link to comment
Share on other sites

Ok, yeah, that's flyerframe.handle... the master parent.  Impulse at the correct places on that parent box... and I should be able to get the flyerframe to act as if ANY combination of thrusters fired.  nod.

 

But... here's what I think is happening with the translations.  First... pretend I did the proper center-of-handle applyImpulse... to get the frame to fly -x (to the left)...

 

                var cntptvec = new BABYLON.Vector3(0,0,0);
                var forcevec = new BABYLON.Vector3(-.1,0,0);
                go.flyfr.handle.applyImpulse(forcevec, cntptvec);
(works)

 

Now I want to go forward (+z)...

 

                var cntptvec = new BABYLON.Vector3(0,0,0);
                var forcevec = new BABYLON.Vector3(0,0,.1);
                go.flyfr.handle.applyImpulse(forcevec, cntptvec);
 

This sends the flyer spinning wildly (unless you did a reload before trying it).  I THINK... its because contactPointVector (cntptvec) is pointing at 0,0,0 in WORLD space... and should be (re-)pointed at 0,0,0 of flyerframe.handle LOCAL space (or a copy of it).  When the flyer flew left (-x), it drifted away from 0,0,0 worldspace.  SO... the forward impulsing (+z) sends the craft spinning.... because its still vectoring on worldspace 0,0,0... which is far to the right of the vehicle (because we translated the flyer to the left earlier).

 

Phew.  Does ANY of that make sense?.  I think the contactPointVector needs to translate (and rotate) WITH the flyer (its parent) at all times.  I think it gets left behind when the flyer translates away, currently. 

 

Thoughts? (thanks!)  I have reading to do.  There is quite a bit of talking on the web... about applyImpulse.  Its a common command across many physics engines.

 

UPDATE:  Yep, I was right for once.  var cntptvec = go.flyfr.handle.position; fixed me right up.  All translatings are working.  YAY!!  Took me long enough.  :)  Quick look... http://urbanproductions.com/wingy/babylon/thruster/t18/thruster18.htm (zip too).  It has an excellent spacecraft drift 'feel', I think.  TOO COOL!

 

Fire thrusters with SHIFTED things around the "L" key and shifted pageup/pagedown...  OR... SHIFTED number pad things (8 4 6 2) and shifted numpad + and -.  Translations are 100%  YAY!!!  MAJOR YAY!!!  WASD cam controls.  PARTY!!!!!  No rotations yet... but I smell them on the horizon!  Smell that?  YUM!

Link to comment
Share on other sites

Hi gang!

 

I have been moving forward on the flyerframe.  Its pretty fun work.  I am learning much about quaternions.  I am getting good rotations by adjusting the force vector for the applyImpulse... but I found a problem.  When the flyer is inverted, its thruster actions are inverted.  Thrusters 'suck' the spacecraft instead of pushing it.  :)

 

So... I think I need to add the current rotation of the flyer... to the force vector... before thrusting (impulsing).  Thank goodness we have all the tools we need to do that... built-into BJS vector3 class (and with help from BJS quaternion class).

 

The flyerframe parent (gizmo) is rotated with a quaternion... initially set to 0,0,0,1... and that's called the identity quaternion.  A nice tutorial is at http://www.sacredsoftware.net/tutorials/Quaternions/Quaternions.xhtml and a decent 'playground' app is linked at the bottom of that page.  Its all very interesting... but plenty foggy as well.

 

I don't need my force vector as a quaternion, but I do need to get the current rotation of the flyer in vec3 (Euler?) format... in order to add that to my force vector before impulsing.  In simpler terms, I need to find out how the flyer is currently rotated.... and then rotate my force vector to match that, and THEN impulse.  This is for translating correctly... AFTER a rotation has happened.

 

I need to cast a BJS vec3... from the flyer parent quaternian rotation.

 

The way I'm trying (for a flyer-inverted +z translate)... is like so...

 

                var cntptvec = go.flyfr.handle.position;
                var vec3rot = go.flyfr.handle.rotationQuaternion.toEulerAngles();
                var forcevec = new BABYLON.Vector3(0,0,.1).add(vec3rot);

                go.flyfr.handle.applyImpulse(forcevec, cntptvec);
 

Its likely wrong, as I'm essentially feeling-around in the dark... but I'm having lots of fun learning.

 

I'm not sure that .toEulerAngles() is working correctly.  Does this seem correct?  ...

 

eval:  BABYLON.Quaternion.RotationYawPitchRoll(0, Math.PI, 0).toEulerAngles()

-->      ({x:0, y:0, z:3.141592653589793})

 

I'm still learning... but... is the z value supposed to be over in the x slot?  I think maybe so.

 

(Reminder to newbies... RotationYawPitchRoll(Y, X, Z) is the format per what DK said in earlier posts.  The PI setting was put in the X slot).

 

DK or anyone else... when you have a moment, could you try to verify that quat.toEulerAngles() is working correctly?  Thanks!  I hope everyone is well!

 

PS: http://doc.babylonjs.com/page.php?p=24728... the constructor params are somehow messed up there... if anyone cares.  ;)

Link to comment
Share on other sites

FUN WITH ROTATIONS

 

flyerrot01.jpg

 

Hi gang!  Here's an update on current work... rotating the flyer (pitching the nose down +x).  One thing I just recently learned was that I was forward-impulsing the -z side of the parent at a contact point just above center, and to keep the flyer from translating because of that, I was backward-impulsing the +z side of the parent at a contact point just below center.

 

            case 38: // control numpad 8 (+x pitch-nose-down)
                e.preventDefault();
                e.stopPropagation();
                go.flyfr.thrusters[3].start();
                go.flyfr.thrusters[9].start();
                go.flyfr.thrusters[18].start();
                go.flyfr.thrusters[24].start();
                var cntptvec = go.flyfr.handle.position;

                // move contact point ABOVE center point on gizmo/parent and thrust it +z
                cntptvec.y = .2;
                var forcevec = new BABYLON.Vector3(0,0,.1);
                go.flyfr.handle.applyImpulse(forcevec, cntptvec);

                // To keep the flyer from translating +z...  inverse thrust.
                // Move contact point BELOW center point on gizmo/parent and thrust it -z
                cntptvec.y = -.2;
                var forcevec = new BABYLON.Vector3(0,0,-.1);
                go.flyfr.handle.applyImpulse(forcevec, cntptvec);

                break;
 

This works fine... but it is incorrect... per the actual particle-emittings.  Actually, I should be downward-impulsing on the +y side of the parent with a contact point just forward (+z) of center, and upward-impulsing on the -y side of the parent with a contact point just behind center (-z).  That would be true and accurate to the actual positions of the firing thrusters.  THEY are firing on the Y axis... but I am impulsing on the Z axis.  Both cause correct rotation, but an aerospace engineer (and DK) would see my mistake in a flash.

 

Interesting, eh?  I think so.  Notice the -.2 position drift while thrusting this rotation?  Nod.  It goes back to zero as soon as I release the thruster button.  I think this is because one impulsing happens moments before the inverse impulsing.  When the button is released, the last impulsing is the inverse impulsing, which corrects the position upon thruster shutdown.

 

Later, the physics-active flyerframe handle will be the same size as the entire flyer (and invisible), so that when we bounce it into the walls of the rubber room (DK's physics 'playground' room)... it reacts correctly.  In theory, it should react correctly when bounced off-of ANY other physics-active checkCollisions=true mesh.  And if you hit something with too much force... you get to experience one of my explosion-class routines.  :)

 

Its all just TOO fascinating, but I'm a simpleton, so EVERYTHING is fascinating to me.  :)  Be good!

 

PS: More correct...

 

                // move contact point FORWARD of center point on gizmo/parent and thrust it -y
                cntptvec.z = .2;
                var forcevec = new BABYLON.Vector3(0, -.1, 0);
                go.flyfr.handle.applyImpulse(forcevec, cntptvec);

                // To keep the flyer from translating -y...  inverse thrust.
                // Move contact point IN BACK OF center point on gizmo/parent and thrust it +y
                cntptvec.z = -.2;
                var forcevec = new BABYLON.Vector3(0, .1, 0);
                go.flyfr.handle.applyImpulse(forcevec, cntptvec);
 

      (Same good rotation action.  This time, a -0.2 position drift on the Z axis. Formerly, it was Y axis)

Link to comment
Share on other sites

Hi dad72, good to hear from you again.  The title of this thread should be changed to "The Wingnut Chronicles".  In many ways, its a giant English tutorial... for English-speaking new-to-babylonJS people.  I over-explain... because I am trying to get people to not be scared of trying webGL.  I also over-explain... so that DK and others... understand "where I am at".  By watching me, developers can MAYBE see WHERE I got confused, and what actions I took when.  This helps them make better user-layers for their framework. 

 

I have essentially ALREADY written the English tutorial for the BJS physics system, yes?  (with demos/zips with not-rotten links.)  Writing English tutorials is likely a hassle for French speakers, so I write detailed... and maybe the framework authors will point new ENGLISH users to read this thread... and thus maybe the users won't ask the same old questions over and over.

 

Yes, I'm long-winded... for several important reasons.  I'm sorry that its difficult to read.  Maybe try Google translate?  I wish I had a solution for you, but there's important reasons for my long-winded comments.  BJS is the best framework around, and far too few people know about it.  I hope there is a blog in France that is teachy for French speakers... and I would love to read an english translation of THAT.  Conversely, I hope THIS thread can be translated to French someday, and be useful for French-speaking youngsters. 

 

Again, sorry, Dad72... but I won't be changing my ways at this time.  You are very correct in what you say, though.  :)

Link to comment
Share on other sites

Hi gang!  Yet another version of the flyer... http://urbanproductions.com/wingy/babylon/flyer/flyer20/flyer20.htm  (zip is there too)

 

A little GUI this time.  And, generally speaking, translating (positioning) the flyer after doing any rotations... is not yet working correctly.  I have lots of experimenting and learning to do in THAT area, yet.  Hope everyone is well.

Link to comment
Share on other sites

What a nice thing to say!  Thanks Temechon!  Anyone is free to use this in any way that they please, with no need to credit anything but BabylonJS.  But, I still need to figure out how to get it to translate (position) correctly after its been rotated (like when the flyer is upside down).  Its something math, I just know it.  (help?)  :)

 

Its made to be a base-class and to allow attachment of other models... by everyone.  Hopefully, MANY BJS games will be made using the flyer (or similar)... including some from you, Temechon.  ;)  Thanks again for the nice words.  The credit really goes to the excellent framework and its authors and contributors.  PARTY ON!

Link to comment
Share on other sites

Hi again, girls! 

 

Thanks DK!  Nice words!  I like it, too.  Do you or anyone want to help with the final math nightmare?

 

The white box in the middle is the master parent.  All impulsings happen against that box.  Later it will be as large as the entire flyer, and invisible.  It uses a rotation quaternion, so that later, the flyer will bounce off the walls of the physics playground room correctly.  Cannon.js needs quaternion rotation as stated earlier.  The flyer's parent rotation must stay a quaternion.

 

My 'position +x' impulse force-vector is currently (.4, 0, 0).  You can pretend it is .4 foot-pounds of +x thrust.

 

I think everyone sees the problem. Imagine rotating +y (yaw right) to 45 degrees.  Now I press 'position +x'.  The ADJUSTED impulse force-vector for 'position +x' needs to be about (.2, 0, -.2) so the flyer will move toward Florida (+x and -z) (southeast) instead of toward Virginia (+x only) (east).  :)

 

I could use some help with that math.  Briefly, once the flyer is rotated to any attitude (angle), how would I derive/calculate the new force-vectors for the position +x, -x, +y, -y, and +z, -z buttons? 

 

I show a .toEulerAngles of about (0, .707, 0) after yawing right 45 degrees.

 

So, after any rotation of the flyer (and immediately-before new position impulsings), I need 1-6 new (derived) force-vectors so that the position buttons aim correctly.  I need to 'take into account' the rotation of the flyer... before using the positioning buttons.  Any ideas? 

 

Its a formula.  I know it can be done.  But ouch, my brain is about to explode.  :)

 

THANKS to anyone who works on this.  I need SIMPLE answers... already in javascript, ideally.  I am not a math wizard at all.  :/  I hope everyone is well!  Thanks again for any help!

Link to comment
Share on other sites

Oh man, I just realized that I have more problems than what I first thought.  When I yaw the flyer to the right 45 degrees (+y) and then try a roll left (-z), I no longer get a flat roll.  The back left leg goes down, the front right leg goes up.  Both left legs should go down, and both right legs up.  World space, local space, sigh.  Why did I ever start this monster?  :/

 

In other words, I need to take into account the flyer's rotation... before I do any positioning OR more rotations.

 

(Wingy begins pulling his hair out)

Link to comment
Share on other sites

rods.jpg

 

Hi everyone!

 

    IF I wanted to obtain/get a vector3 of worldspace rotation... of those 3 white rods, how could I do that?

 

The rods are named spinex, spiney, and spinez.  Does anyone know-of something functionally-equivalent-to (similar-to)...

 

scene.getRotationalVector("spinex")  --> vec3

 

or maybe...

 

scene.getRotationalVector(scene.getMeshByName("spinex"))  --> vec3

 

??  Currently, I CANNOT derive the rod's rotation from the white box in the middle (not with MY math skills).  Thanks!!!

Link to comment
Share on other sites

oooh, BJS 1.9 has some new quaternion toys!  YAY!  hmmm.  Just maybe...  hmmm.  Thanks for the new BJS, DK (and contributors)!  At least I have some new things to look foolish-with.  :)  The flyer has been stalled for some time.  Help ALWAYS welcome.

Link to comment
Share on other sites

Thanks for asking!  Yes, I think that is correct.  I think you know more about what I want... than I do.  :)

 

You have flown the flyer.  I think you know how it should act.  I think I just confuse people when I try to explain it. 

 

When the flyer is sitting-at (rotated-to) ANY odd angle, the position x/y/z buttons should impulse it along the white 'rods', and the rotation x/y/z buttons should rotate it around the white rods.  It should happen that way, no matter how the flyer is currently rotated (its current attitude).

 

If I can "peek" (get) the current rotation of any white rod, no matter what attitude the flyer is currently at...  then I think I can make it work correctly.

 

To see the problem, just run http://urbanproductions.com/wingy/babylon/flyer/flyer20/flyer20.htm ...  rotate the flyer to some strange angle... and press position +x.  The flyer should move in the direction of the spinex white rod... and not +x in world space.  It needs to move (and rotate) per the active thrusters.

 

Here I am over-explaining again.  Sorry.  Thanks for your interest... it means the world to me.  I cannot start game development until the flyer is working correctly.  These numbers are needed for the force vector (first parameter) of applyImpulse.  The 'thrusting angle'.

 

I am very willing to make more graphics and explain more... just say so.  Thanks again.  I THINK... maybe... the new BJS has the tools I need.  Thanks again for your excellent work on the framework.  You're my hero!  I also have SOME cash if that would help somehow, somewhere.  Don't be afraid to ask... I'd be glad to buy you some dinners.

Link to comment
Share on other sites

Hi

I don't need a mesh rotate.  The applyImpulse does the rotating for me.  ApplyImpulse puts rotation on the quaternion of the flyerframe.parent.  I never need to set a rotation on the flyer.  I need gets, not sets.

 

I need a getCurrentRotation().  Maybe getAbsoluteRotation().  Something like that.  We still have a communications problem.  I'll make some more graphics... try to explain more.  Thanks for the try, though.

Link to comment
Share on other sites

Here's a start...

 

info01.jpg

http://urbanproductions.com/wingy/babylon/flyer/flyer20/js/controller06.js

 

Function...  BABYLON.FlyerFrameController.prototype.rotPositiveX

 

Line... var forcevec = new BABYLON.Vector3(0, -this.rotforce, 0); (aim force down - ready for impulse #1)

 

and later... var forcevec = new BABYLON.Vector3(0, this.rotforce, 0); (aim force up - ready for impulse #2)

 

Far above, this.rotforce is set to .05 ... enough to turn the vector in a simple direction.

 

Then...  go.flyfr.handle.applyImpulse(forcevec, cntptvec);  FIRE!  :)

 

BUT... IF the flyer is already rotated to some angle, then 'forcevec' needs adjusting BEFORE applying the impulse... or else the flyer will rotate incorrectly.  Forcevec must be adjusted to account-for the flyer's CURRENT attitude (rotations).

 

In that function, you will see cntptvec.z = this.rotleverage;  (.rotleverage is the offset-distance from box center)

 

That is the 'contactPoint offset' in the picture.  It moves (positions) the force vector OFF-CENTER in a certain direction... so that the parent rotates.  Without moving the force-point off-center, the flyer would translate instead of rotate.

 

Anyone with me?  Gosh I hope so.  :)

 

Please read the previous 7-8 posts in this thread, too.  They talk about the impulsings.  THANKS!!!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...