koobas.hobune.stream
Composite body physics
I have a spaceship that is supposed to have a total of 12 thrusters, which are intended to move the ship, each providing thrust in a specific direction.
Can I simply use a parent-child relationship, with the parent being a rigidbody - the ship - (the thrusters are not rigidbodies), so that the thrusters would control the parent ships movement? Or do I need to use fixed joints?
How would I go about setting up a configuration like this in Unity?
To clarify you can't use the parent child relationship with rigid bodies. Rigid bodies need to be constrained via joints. To see why simply try it.
I see. To make a joint - since I'm making my models in Blender, can I just make a single bone armature and then use that as an attachment point in Unity? Or do I have to attach the thruster to it in Blender?
It sounds like a "thruster" is an arbitrary point + direction in relation to the model. In that case, for "true" thruster physics, you'd simply AddForceAtPosition() given the thruster's relative position, direction, and scalar force.
Note this may not give the intended results. For an "intuitive" thruster system, you'll have to deterministically assign the appropriate force from each thruster based on input. Or, better yet, drive the rigidbody motion from a single calls to AddTorque() or AddForce(), and visually show the thrusters working through particle effects or what-have-you. Using the later method, you could still perform the deterministic calculations to control the intensity of the "active thruster" effect.
I think the first option sounds more like what I'm intending to achieve, although I'll need to experiment. I should also clarify what I want the thruster to be, exactly - initially I thought it should be a rigid body with their own mass, too, as the ship isn't causing the acceleration since the thrusters are, thereby getting around the "don't make parent-child rigid body relationships" I saw mentioned in another thread.
So if I were to use this system, I would have to look for key/mouse input, and then run the function in the Thruster class to get the thrust amount, and then use AddForceAtPosition() on the ships script?
That should work in principle, but it gets confusing pretty fast. Consider:
For lateral motion, the appropriate amount of force from each thruster can be found by comparing the dot product of the thruster direction and desired direction of lateral motion. Note that for this to "work right" - meaning it feels intuitive and doesn't create unwanted rotational acceleration - your thrusters must somehow incorporate their relative positions in their calculations (I'm not sure how to go about this myself without breaking out my physics textbooks).
Also consider, to use this same thruster system to drive rotational motion, the rotation input must be considered in a similar but separate way. Each thruster would need to compare its direction-of-force against the object's CoG, and find the appropriate force based on how well its participation would yield the correct rotational acceleration. (I'm not totally sure how to approach that, either).
Frankly, unless you're making a game for actual rocket scientists - or you have one on retainer to help build all your vehicles - the single-call system will save you a lot of headaches. To the untrained eye, the thrusters will appear to actually work and drive motion, when in fact they're merely decorative. You still have to do all the above calculations to ensure their visual effects fire with appropriate intensity, but the physics simulation itself will be separate, and therefore much more simple, stable, and intuitive to program and control.
Also consider - with the single-call system, you could eschew nearly ALL of these intensive physics calculations by simply using an "accumulation" effect, where the intensity of your thrusters' visual effects are simply driven by lateral and rotational velocity. This is how I'd approach the problem, if at all possible.
$$anonymous$$erball seems to be doing pretty well with rocket scientists :)
As pointed out faking it is definitely easier. Unless thrust control is a critical part of your gameplay I wouldn't bother doing it properly.
I see. The physics involved in that sound a bit above me currently, so the single call system looks to be my best bet, then. And in that situation I could have the "moving thrusters" actually just be a particle effect source rather than a fully modeled element on the ship...that does decrease the complexity of ship design, since the thrusters' locations don't need to be 100% mathematically correct either.
Thank you.
I've implemented a similar design both ways (children and joints), and both worked well for me.
In the case of the parent/child relationship, my thrusters had a script which had a configurable 'thrust normal' to determine which direction the thrust would act, along with a reference to the parent rigidbody (so I didn't have to find it each frame). Then, still in the thruster script, I calculated the amount of thrust I expected that engine to produce. This was based on things like throttle, fuel level, etc.
Finally, in the FixedUpdate for the thruster, I used:
this.parentRigidbody.AddForceAtPosition(this.thrustNormal * this.forceMagnitude, this.transform.position);
Using configurable joints was arguable easier for scripting, since you don't have to worry about the parent rigidbody, you can just use your own.
For large ships with lots of thrusters, it is/was a pain to set up all the joints properly.
If I had it all to do again... I think I would have stuck with the parent/child relationship (and in fact, may end up going back after all).
Then it looks like child/parent relationships will be the way to go, although I'll (as commented above) make my thrusters just particle effect sources; still, it's useful knowledge to have. Do you have a video demo of what you were working on, by the way? Just so I could see it in action.
I do not, currently. It is in such a 'quick and dirty' phase that any attempt at a demo would no doubt be plagued by any number of other demons currently haunting the project, and nobody wants to see that.
