April 30, 2018 at 12:40 am #14534
BTW To test the damping, download the source in first post and comment-out Class Rocket -> New ->
body.AngularDamping = 0.75
Get some height, then hold left or right and note that, after you let go, it just keeps turning. Now enable damping and try again, and you should see it settles in its rotation.
It means you’re not constantly battling to correct by contra-rotating all the time.April 30, 2018 at 12:16 pm #14537
Looking good! But slow here aswell. Using Arch Linux on an i5 laptop, I get 10-13fps on Firefox (59.0.2), same on Chrome (66.0.3359.139) and also the same if I rebuild natively from the source. So it’s not a browser issue.
My gfx card isn’t the greatest (built-in Intel) but I get over 50fps when running toy-plane (with the window resized to 640×480 resolution). The CPU reports about 13% usage when running either of these.
If I run Toyplane and Bust in separate windows simultaneously I get 13fps for both. As soon as I close Bust, Toyplane jumps up to 50fps.
Does that help track down what is slowing things down? Happy to tinker with some code if it could be helpful – just point me to any likely culprits. It would be nice to see this running smoothly.April 30, 2018 at 12:39 pm #14538
Good troubleshooting, thanks, Arpie, but… over to Mark for that!
Just got the camera-relative movement working really easily (camera.Basis * vec3)! Camera currently ‘stuck’ to the rocket, but it’s really freaky, weird to control at first, but actually makes sense… only had it going 5 minutes:
Will tweak and post later, but it was so cool to get working!May 2, 2018 at 1:22 am #14540
WIP update… this is VERY hard to control, but it’s not due to the rocket itself, the control of which is now working as it should in 3D — the problem now is my quick work-in-progress camera!
I recommend small, slow movements near the terrain for best effect. The camera goes nuts if it gets too close to the rocket (eg. when you correct direction towards the camera) — hit R to reset when this happens — and there’s sometimes a weird camera judder that’s way more pronounced in the web version than on desktop. (Yet sometimes it’s fine.)
I need to try and get the camera to orient itself ‘behind’ the rocket in terms of the rocket’s heading, as it’s always at a fixed offset at the moment.
Best I could do for now in order to ‘see’ if the 3D directional control is working, which it is.
Source is a mess (same link as first post), definitely “WIP”! Needs latest MX2 ‘develop’ version.May 2, 2018 at 2:25 am #14541
Woah, yes, the camera needs some work! But it’s starting to remind me a lot of Zarch..
One quick question before I get too carried away with new stuff – should I rename ‘Constraint’ to ‘Joint’? And ‘PointToPointConstraint’ to something like ‘BallSocketJoint’? So far, I’ve just used the bullet names directly, but they’re kind of cumbersome…May 2, 2018 at 3:33 am #14542
Joint is probably friendlier, yeah, and BallSocketJoint does describe PointToPoint more understandably, so yeah on that too.
Still to try those axis restrictions, been a bit carried away with full 3D, sorry!May 2, 2018 at 7:24 pm #14543
Kinda getting there…
Still hard as hell, but the camera’s a bit better. One thing I still need to figure out is getting the camera to sit at a rearward offset from the rocket’s direction (like it does here), but not to always end up pointing “north”. (I think this is also something to do with why the camera occasionally does a wild arc around the mountains!)
A little linear damping makes landing more manageable now, as the rocket slows itself a little, rather than needing constant little back-and-forth corrections. Might try adding a little auto-levelling when near the ground too (or maybe just when going slow)…May 2, 2018 at 9:45 pm #14545
Constraints now renamed to joints in develop branch – joints also work in mojo3d scene files, see jointchain-scene.mojo3d!
How about a reset rotation key for when you’re on the ground?May 3, 2018 at 12:04 am #14546
Also, should I remove ConnectedPivot? I can actually calculate this by moving the local pivot into the connected body’s space.
This does assume that you’ve initialized the bodies so they are in the correct relative position though.May 3, 2018 at 12:23 am #14547
I’m not sure on that last one — I actually want to move the ball-pivot to the bottom of the rocket here, rather than the centre of the body.
By reset key, did you mean for resetting the rocket itself (rather than camera)? I can do that… still fighting my f***ing camera always wanting to point ‘north’ at the moment!
Will update all to latest develop probably tomorrow now.May 3, 2018 at 12:30 am #14548
Sorry, think I get what you mean by removing ConnectedPivot, as that would be the ‘fixed’ end (orb end in my case), so guess you can just work that from the ball (rocket-end) Pivot…May 3, 2018 at 12:47 am #14549
I actually want to move the ball-pivot to the bottom of the rocket here, rather than the centre of the body.
Assuming the orb starts out in the right position relative to the rocket, the orb relative pivot (ie: ConnectedPivot) can be automatically calculated from the rocket relative pivot.
For example, if the joint is attached to the rocket (not the orb) and the orb is positioned 10 units below the rocket and you’ve set the joint pivot to 0,-10,0, then the orb relative pivot must be 0,0,0. Ditto if you set the joint pivot to 0,-5,0 then the orb pivot must be 0,+5,0.
The only time this wont work is if you start the orb out in the ‘wrong’ place, ie: at a position where the 2 pivots are not touching in world space.
I mention this because I’ve had a quick look at other joint types and there’s a lot of redundancy where you have to specify the connected pivot/axis/matrix, but these can potentially be calculated from the joint pivot/axis/matrix.
Worse case is the FixedConstraint where you need to specify a LocalMatrix for both bodies. However, if we assume everything starts in the right position, this can be made totally automatic. It turns out fixed constraints are springy too which is kind of cool.May 3, 2018 at 1:01 am #14550
Yeah, I think it makes sense!
(Think I’ve done my pivots back-to-front anyway, should really have attached the ball-socket from the perspective of the rocket, rather than from the perspective of the orb, ie. with orb as ConnectedBody from the rocket, rather than rocket as ConnectedBody from the orb)… I know it works out the same, just makes more sense from a visualisation perspective to have the ball socket attached to the rocket and have orb as the ConnectedBody!)
Done with ****ing cameras for tonight, ****ing thing won’t ****ing do anything other than ****ing settle facing ****ing north! Must be 3 ****ing hours on this ****ing problem now! Off to ****ing bed!May 3, 2018 at 1:06 am #14551
It turns out fixed constraints are springy too which is kind of cool
Gah, was hoping they were actually FIXED! I guess I can use the force offset thingy anyway, still to try that.
But, yeah, might as well require that things are positioned correctly before connecting them, since their physics will have started anyway.May 4, 2018 at 1:54 am #14571
Woo-hoo! Basically got my camera working as intended!
You may notice a jolt if the rocket gets close to the camera and then moves away. I know what this is and believe I can resolve it easily enough — it’s part of how I position the camera position target (point towards which camera moves each frame) according to the rocket’s velocity vector. If this vector is zero (rocket stopped), then I need to use the last significant movement vector in order to have a valid offset for the camera to sit at.
Next step will be a massive clean-up, conversion to new develop version, add a few little objectives (collect the gems, steal the orb, etc) and that should be about it…
It’s still bloody hard, but… it’s Thrust, in 3D. What do you expect?!
You must be logged in to reply to this topic.