Vector thrust physics
-
- Hunter
- Posts: 94
- Joined: Tue Oct 30, 2012 10:39 pm
Vector thrust physics
I suppose one day, VS is going to have support for actual thruster localization and orientation on ships. when this day comes, all acceleerations will be redefined by the change. So why make a work that is going to be overwritten anyway?
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Acceleration, physics, and other ship enhancements/rebal
I don't think it's going to take the form you think it's going to take.maze wrote:I suppose one day, VS is going to have support for actual thruster localization and orientation on ships. when this day comes, all acceleerations will be redefined by the change. So why make a work that is going to be overwritten anyway?
I already have support for graphical representation of attitude thrusters, in the pipleine, but it's just a graphical representation of the forces at work. The physics engine works on maximum torque and maximum angular velocity.
The max torque represents the maximum angular acceleration thrusters, as a group, can create, and max velocity represents governor limits. So it summarizes what "position and direction" would encode, in a much more engine-manageable (and human-understandable) way.
The net effect is almost the same, if you consider ships as perfect spheres. Which they're not. But it's a reasonable simplification given that more complex mechanics really don't necessarily translate to better gameplay.
Graphical representation of thruster firing will also quite necessarily be approximate. But I believe it will be good enough.
-
- Elite
- Posts: 1363
- Joined: Sat Aug 04, 2007 3:42 pm
Re: Acceleration, physics, and other ship enhancements/rebal
If you assume the torque values represent the output of completely internal control moment gyroscopes, then you don't need any RCS representation for turning.klauss wrote: The max torque represents the maximum angular acceleration thrusters, as a group, can create, and max velocity represents governor limits. So it summarizes what "position and direction" would encode, in a much more engine-manageable (and human-understandable) way.
You only need thruster graphics for linear acceleration. Unfortunately while ships have the thrusters to move in six directions in the physics simulation, the game only shows the ones firing that move you forward. The rest are unrepresented.
As Chris Roberts said though, there is the gameplay value of a craft's flight mechanics changing dynamically as the individual thrusters get destroyed in battle. It might make it so you don't just see the damage to your ship, you feel it.The net effect is almost the same, if you consider ships as perfect spheres. Which they're not. But it's a reasonable simplification given that more complex mechanics really don't necessarily translate to better gameplay.
Re: Acceleration, physics, and other ship enhancements/rebal
I also think it would be cool if thrusters would be simply subunits which can be bought/upgraded/damaged. The flight controller would decide which ones to fire to fit pilot inputs and enforce g limits.
-
- Hunter
- Posts: 94
- Joined: Tue Oct 30, 2012 10:39 pm
Re: Acceleration, physics, and other ship enhancements/rebal
Gyroscopes I hadn't thought of... Well, that's very interesting, opens a lot of possibilities, and makes it even more desirable for gameplay to have thrusters described as sub-units (and gyroscopes as upgrades).
So, even with gyroscopes you do need sets of thrusters pushing far away from center of mass. This being said, these might very well be low-performance ones.
Strictly spekaing, gyroscopes alone don't work. They can't reach infinite speed because of friction. In the end you'll slowly build momentum for various reasons: major sources I guess are weapon fire and industrial tolerances in thruster positioning and alignment; there's many others minor sources of momentum. Maybe this is what happened to the Agesipolis I was hunting the other day (I guess some of you will catch what I mean because I saw it mentioned here; a funny sight indeed).Deus Siddis wrote:If you assume the torque values represent the output of completely internal control moment gyroscopes, then you don't need any RCS representation for turning.
So, even with gyroscopes you do need sets of thrusters pushing far away from center of mass. This being said, these might very well be low-performance ones.
10G I believe is what my Dosto accelerates forward after being fully loaded with upgrades. I even restrained from picking some of the extremely dense stuff, because I don't want SPEC to turn itself off away from stations (25 km is the limit I don't want to exceed; currently I'm at 23-24km). I'll check the exact figures tonight. What this means is I really hope those figures are conserved after upgrading ships. It will be unfair that going heavier won't reduce your performance, but if that's what everyone wants...Deus Siddis wrote:No craft can ever go beyond 10Gs acceleration as a hard limit, and performance approaching that is only reached for short periods by special-purpose aerospace craft ("kamikaze" or "interceptor" fighters and "messenger" or "VIP" shuttles for examples). The bottom limit for sustainable acceleration on aerospace craft is equal to the gravity of a world with the highest gravity that is healthy for the human body in the long term, since these craft are meant to safely land and launch from them. This is somewhere between 1 and 2 Gs I would guess?
The space only ships have accelerations between 0.1G and 1G.
...So how's that?
You must be kidding, it's not the same at all, for many reasons. Even forgetting about thruster damage:The net effect is almost the same, if you consider ships as perfect spheres. Which they're not. But it's a reasonable simplification given that more complex mechanics really don't necessarily translate to better gameplay.
- Upgrading your ship is part of gameplay, and being able to upgrade your thrusters would make a lot of sense.
- Gyroscopes and thrusters don't lead to the same behavior. With gyroscopes, friction creates a rotational speed limit for the gyroscope, which translates into a limit to their contribution to the rotational speed limit of the ship. Because of this friction, the more you get close to your gyro's rotational speed limit, the more your rotational acceleration decreases, and the more your rotational deceleration increases. Thrusters provide constant rotational acceleration, whatever your current rotational speed is. With them, the rotational speed limit is either a governor limit or a structural limit (pilots should be able to override either, with different possible consequences).
- Most importantly, you seem to assume that all ships would have the same thruster topology, which I guess is what I would describe as 12 thrusters, 2 per facing direction. In fact, endless variations are possible.
- This morning I came up with a design using 6 thrusters, which can accelerate translationally and rotationally in every direction of space, and independantly from each other. One characteristic of such design, at least in the way I envisioned it, is that its rotational acceleration is greatly reduced if it rotates under a zero translational acceleration constraint. Quite the opposite of the classical 12-thruster design whose fastest rotational accelerations are typically obtained in states of zero translational accelerations.
- Imagine a tetrahedron-shaped ship, with thrusters perpendicular to the sides of the tetrahedron. I'm nearly sure that can work. And that would have combat benefits if you put a turrent on each side of the tetrahedron: if it points a corner at an enemy, it can fire 3 of its 4 turrets at that enemy.
- Then, you could have different kinds of thrusters.
- One type would rely on its own fusion reactor independent from the other systems of the ship.
- Another type would rely on a stream of accelerated particles being provided by the ship's main reactor. Such type would probably have a lower energetic efficiency than the previous one. Depending on whether the reactor is powerful enough to constantly power at max thrust 2, or 3, or 4 of your thrusters, you'd get a different flight behavior. And, as long as your reactor is not overdimensioned, you'd feel the loss of punch when your capacitors and/or SPEC drives are recharging.
- A third type would provide acceleration by discrete pulses, like the ship concept which was at the base of the Orion project (not really a thruster per se, but that's not a problem)
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Acceleration, physics, and other ship enhancements/rebal
You seem to have seriously misunderstood.
...only to be ignored, because nobody likes running out of fuel and being stuck in space with no hope of salvation. Even a fuel-less ship in VS can turn and thrust (slowly).
Nobody said limits wouldn't be upgradeable...maze wrote:Upgrading your ship is part of gameplay, and being able to upgrade your thrusters would make a lot of sense.
Nor that there would be no independently-derived rotational speed limit...maze wrote:Gyroscopes and thrusters don't lead to the same behavior. With gyroscopes, friction creates a rotational speed limit for the gyroscope, which translates into a limit to their contribution to the rotational speed limit of the ship.
Nor that all ships would be equal...maze wrote:Most importantly, you seem to assume that all ships would have the same thruster topology, which I guess is what I would describe as 12 thrusters, 2 per facing direction. In fact, endless variations are possible.
I was indeed saying these minute differences really don't provide any value...maze wrote:Because of this friction, the more you get close to your gyro's rotational speed limit, the more your rotational acceleration decreases, and the more your rotational deceleration increases. Thrusters provide constant rotational acceleration, whatever your current rotational speed is. With them, the rotational speed limit is either a governor limit or a structural limit (pilots should be able to override either, with different possible consequences).
...and be a lot of work just to consume rather abundant fuel at a different rate...maze wrote:One type would rely on its own fusion reactor independent from the other systems of the ship.
* Another type would rely on a stream of accelerated particles being provided by the ship's main reactor. Such type would probably have a lower energetic efficiency than the previous one.
...only to be ignored, because nobody likes running out of fuel and being stuck in space with no hope of salvation. Even a fuel-less ship in VS can turn and thrust (slowly).
Numbered stats provide the overall effect efficiently and accurately enough. Anything further is over-engineered for a game.maze wrote:With numbered stats you get quantitative differences between ships. With sub-unit thrusters you get qualititative differences between them. I'm not saying it's easy and can be done by snapping fingers, though.
-
- Elite
- Posts: 1363
- Joined: Sat Aug 04, 2007 3:42 pm
Re: Acceleration, physics, and other ship enhancements/rebal
External sources of angular momentum are extremely rare and small and are completely and easily eliminated whenever you land or dock or enter an atmosphere (i.e. every 10 minutes). The CMGs could handle 99.9% of your rotational needs. You would still have limited RCS but they would be for situations so rare as to be not worth simulating.maze wrote: Strictly spekaing, gyroscopes alone don't work. They can't reach infinite speed because of friction. In the end you'll slowly build momentum for various reasons: major sources I guess are weapon fire and industrial tolerances in thruster positioning and alignment; there's many others minor sources of momentum.
-
- Hunter
- Posts: 94
- Joined: Tue Oct 30, 2012 10:39 pm
Re: Acceleration, physics, and other ship enhancements/rebal
Ah? Severely misunderstood what? I never said or implied that all ships would be equal. I was just pointing that there's quantititative and qualititative differences, and that they're not the same. Which you seem to be minimizing but not contradicting directly.klauss wrote:You seem to have seriously misunderstood.
Nobody said limits wouldn't be upgradeable...maze wrote:Upgrading your ship is part of gameplay, and being able to upgrade your thrusters would make a lot of sense.
Nor that there would be no independently-derived rotational speed limit...maze wrote:Gyroscopes and thrusters don't lead to the same behavior. With gyroscopes, friction creates a rotational speed limit for the gyroscope, which translates into a limit to their contribution to the rotational speed limit of the ship.
Nor that all ships would be equal...maze wrote:Most importantly, you seem to assume that all ships would have the same thruster topology, which I guess is what I would describe as 12 thrusters, 2 per facing direction. In fact, endless variations are possible.
Not any value, no, it's just a difference in the way the ship reacts when a player moves his joystick. If there's a minute difference, as you say, between accelerating in a frictionless media and accelerating in a media with friction, it shouldn't be that hard to implement atmospheric flight, either.klauss wrote:I was indeed saying these minute differences really don't provide any value...maze wrote:Because of this friction, the more you get close to your gyro's rotational speed limit, the more your rotational acceleration decreases, and the more your rotational deceleration increases. Thrusters provide constant rotational acceleration, whatever your current rotational speed is. With them, the rotational speed limit is either a governor limit or a structural limit (pilots should be able to override either, with different possible consequences).
Speaking of serious misunderstandings, there seems to be another one here. We're not speaking only fuel consumption, in fact we're mostly speaking performance and flexibility/controllability of a ship.For example, you'd have a ship which can go full thrust forward and bottom at the same time, and you'd have another ship which can't, but which would get higher thrust values for the same upgrade volume. In common use conditions and with classical thruster locations, second ship is faster, but also less controllable. The difference between both ships might not be worded that simply under all possible conditions/piloting styles however. To be totally accurate in the general case, the latter ship is more capable than the former at accelerating in the directions pointed by its thrusters, or at a low angle with said directions, the former ship is more capable at accelerating in the directions which are in-between those directions.klauss wrote:...and be a lot of work just to consume rather abundant fuel at a different rate...maze wrote:One type would rely on its own fusion reactor independent from the other systems of the ship.
* Another type would rely on a stream of accelerated particles being provided by the ship's main reactor. Such type would probably have a lower energetic efficiency than the previous one.
That wouldn't have to be changed in any way with either type.klauss wrote:...only to be ignored, because nobody likes running out of fuel and being stuck in space with no hope of salvation. Even a fuel-less ship in VS can turn and thrust (slowly).
Frankly I'm going to leave you the benefit of doubt here, and not assume that you meant this in a general sense, but rather strictly in context.klauss wrote:Numbered stats provide the overall effect efficiently and accurately enough. Anything further is over-engineered for a game.maze wrote:With numbered stats you get quantitative differences between ships. With sub-unit thrusters you get qualititative differences between them. I'm not saying it's easy and can be done by snapping fingers, though.
Where I meet you is that this "thruster as sub-units" thing is not the most urgent change to be made to your game, even if one considers only features to be added. In the long run though, it would definitely have to be there.
Think of a car-racing game. I don't know for you, but myself I would very much want piloting a propulsion car to feel different from piloting a traction car. Where does the difference lie? Most importantly, In the points where the road applies a force to the car, and secondarily, in the position of the car's center of mass.
This analogy for what it's worth makes me more convinced that no, we are not speaking of minute differences right now. Translated into a game like VS, at least for a player like me (and I'm not the only one, thanks log0), such considerations are even more exciting because we can't even predict what exactly those differences would amount to. There's a whole new world to explore by trying various ship designs. And the possibilities can't even be humanly exhausted.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Acceleration, physics, and other ship enhancements/rebal
Lets think of it like this.maze wrote: Think of a car-racing game. I don't know for you, but myself I would very much want piloting a propulsion car to feel different from piloting a traction car. Where does the difference lie? Most importantly, In the points where the road applies a force to the car, and secondarily, in the position of the car's center of mass.
Numeric stats would give a car a pair of friction coefficients (static and dynamic) and maximum linear force applicable by the car's engine. That's the car-analogy equivalent of VS max angular momentum stats. Think of it like X pounds force at each tire, given their friction coefficients, gives you acceleration and grip.
Now, "thrusters as subunits" as you call it, would use a dynamic engine like ODE to simulate the engine as a rotating motor, connected with joints to the wheels, which connect to the road with the tires, tires made of a material with a specific pair of friction coefficients computed at contact points. For this, the dynamics engine needs to solve a series of huge inequation systems, compute contact points by colliding meshes, and iteratively to weed out simulation step errors.
However, thrusters as subunits works significantly more to get the same net effect: acceleration and grip.
Sure, there are minute differences. ODE may be able to simulate failure conditions better (ie: your cam shaft vs wankel at high speeds, or the precise effect of bumps on the road). But those are differences that only matter for simulators in the stricter sense, not games.
While I could agree if it was a more visible part of the engine, say the damage model or the sensors, simulating how exactly thrusters fire isn't such a case. Because nobody will notice the difference without being intimately familiar with thruster placement, and the intuitive feel can be simulated just fine with numbers.maze wrote:This analogy for what it's worth makes me more convinced that no, we are not speaking of minute differences right now. Translated into a game like VS, at least for a player like me (and I'm not the only one, thanks log0), such considerations are even more exciting because we can't even predict what exactly those differences would amount to. There's a whole new world to explore by trying various ship designs. And the possibilities can't even be humanly exhausted.
-
- Hunter
- Posts: 94
- Joined: Tue Oct 30, 2012 10:39 pm
Re: Acceleration, physics, and other ship enhancements/rebal
That's where your description goes way over the top. I'm proposing to describe thrusters with a set of 2 or 3 parameters (parameters in the set would have different meanings depending on the type of thruster). I'm certainly not thinking of going down inside each thruster to model the flow of fused fuel inside the thruster through some kind of fea analysis.klauss wrote:Now, "thrusters as subunits" as you call it, would use a dynamic engine like ODE to simulate the engine as a rotating motor, connected with joints to the wheels, which connect to the road with the tires, tires made of a material with a specific pair of friction coefficients computed at contact points. For this, the dynamics engine needs to solve a series of huge inequation systems, compute contact points by colliding meshes, and iteratively to weed out simulation step errors.
(that's about gyroscopes). Well there's internal sources of momentum, some of which are pretty ubiquitous. For example, there's industrial tolerances on the position and orientation of your thrusters. As for the second part of your claim, I tend to agree. You could have very small, low power thrusters whose sole purpose is to counter the build-up of momentum. Their net contribution to your performance being so small that you can adequately neglect them. So you'd have a ship which for all intents and purposes is treated as having "only" gyroscopes (for rotation) and is immune to momentum buildup. That makes sense.External sources of angular momentum are extremely rare and small and are completely and easily eliminated whenever you land or dock or enter an atmosphere (i.e. every 10 minutes). The CMGs could handle 99.9% of your rotational needs. You would still have limited RCS but they would be for situations so rare as to be not worth simulating.
On the other hand, I wonder if it would be possible to describe a ship which uses both gyroscopes and some (non-negligble) thrusters for turning (without having to solve systems of equations, I mean).
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Acceleration, physics, and other ship enhancements/rebal
You forget that after modeling each thruster subunit, you have to model its push against the ship and how it makes it turn. And on top of that, you have to have a fly-by-wire algorithm that will compute the inverse of that "push function" to let you move your joystick left and have the ship turn left. Effectively inverse functions meaning you cancel out all of the sophistication unless you go manual.maze wrote:That's where your description goes way over the top. I'm proposing to describe thrusters with a set of 2 or 3 parameters (parameters in the set would have different meanings depending on the type of thruster). I'm certainly not thinking of going down inside each thruster to model the flow of fused fuel inside the thruster through some kind of fea analysis.klauss wrote:Now, "thrusters as subunits" as you call it, would use a dynamic engine like ODE to simulate the engine as a rotating motor, connected with joints to the wheels, which connect to the road with the tires, tires made of a material with a specific pair of friction coefficients computed at contact points. For this, the dynamics engine needs to solve a series of huge inequation systems, compute contact points by colliding meshes, and iteratively to weed out simulation step errors.
-
- Elite
- Posts: 1363
- Joined: Sat Aug 04, 2007 3:42 pm
Re: Acceleration, physics, and other ship enhancements/rebal
The one exception is when the individual thrusters start taking damage. The unevenness that creates increasingly defeats your fly-by-wire. But damage modeling in the physics simulation is the only advantage of having thrusters apply positional forces to the ship rigid body.klauss wrote: You forget that after modeling each thruster subunit, you have to model its push against the ship and how it makes it turn. And on top of that, you have to have a fly-by-wire algorithm that will compute the inverse of that "push function" to let you move your joystick left and have the ship turn left. Effectively inverse functions meaning you cancel out all of the sophistication unless you go manual.
Also, I would not recommend modeling each thruster as a separate rigid body connected to the ship body by a joint. It creates some difficult stability issues and all you really need is per thruster collision detection, not mass.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Acceleration, physics, and other ship enhancements/rebal
But that can also be simulated by stats, especially since one expects the fly-by-wire to compensate any odd behavior in favor of decreased performance.Deus Siddis wrote:The one exception is when the individual thrusters start taking damage. The unevenness that creates increasingly defeats your fly-by-wire. But damage modeling in the physics simulation is the only advantage of having thrusters apply positional forces to the ship rigid body.
But that's what "thrusters as subunits" means.Deus Siddis wrote:Also, I would not recommend modeling each thruster as a separate rigid body connected to the ship body by a joint. It creates some difficult stability issues and all you really need is per thruster collision detection, not mass.
-
- Hunter
- Posts: 94
- Joined: Tue Oct 30, 2012 10:39 pm
Re: Acceleration, physics, and other ship enhancements/rebal
I don't know, wouldn't "thrusters on mount points" work also?
By this I don't mean you would have mount points on which you could mount either thrusters or weapons at your convenience. That would be a special kind of mount points with a defined position and thrust direction that the program can access.
The way I understand it currently, if thrusters were individually described, either they would not be sub-units, in which case they could still be damaged but that would be the result of some sort of randomization following any hit on the ship, either they would indeed be sub-units, in which case they could be selected and/or specifically shot at, including with autotracking weapons...
On the other hand, while one might wish thrusters to be subjected to localized hits on a ship, one might also wish for it to be exclusively the result of some lucky or particularly skilled hit, and restrict thrusters from being selected. I don't know where I stand personally on that one.
Thrusters as sub-units also opens the door to pretty interesting items like a thrusters with the ability to move around its thrust direction...
By this I don't mean you would have mount points on which you could mount either thrusters or weapons at your convenience. That would be a special kind of mount points with a defined position and thrust direction that the program can access.
The way I understand it currently, if thrusters were individually described, either they would not be sub-units, in which case they could still be damaged but that would be the result of some sort of randomization following any hit on the ship, either they would indeed be sub-units, in which case they could be selected and/or specifically shot at, including with autotracking weapons...
On the other hand, while one might wish thrusters to be subjected to localized hits on a ship, one might also wish for it to be exclusively the result of some lucky or particularly skilled hit, and restrict thrusters from being selected. I don't know where I stand personally on that one.
Thrusters as sub-units also opens the door to pretty interesting items like a thrusters with the ability to move around its thrust direction...
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Acceleration, physics, and other ship enhancements/rebal
I see...maze wrote:The way I understand it currently, if thrusters were individually described, either they would not be sub-units, in which case they could still be damaged but that would be the result of some sort of randomization following any hit on the ship, either they would indeed be sub-units, in which case they could be selected and/or specifically shot at, including with autotracking weapons...
On the other hand, while one might wish thrusters to be subjected to localized hits on a ship, one might also wish for it to be exclusively the result of some lucky or particularly skilled hit, and restrict thrusters from being selected. I don't know where I stand personally on that one.
Thrusters as sub-units also opens the door to pretty interesting items like a thrusters with the ability to move around its thrust direction...
You're not talking really about the physics of maneuvering things, but about the damage model.
The way things have been made to work in Privateer mods is probably the best, with stock ships having no thrust, and thrusters being a mandatory (ie you can't launch without one) upgrade.
Add locatable and targettable upgrades to the mix, which are on the FRT already, and you've got pretty much everything you (and I may I add) want.
-
- Hunter
- Posts: 94
- Joined: Tue Oct 30, 2012 10:39 pm
Re: Acceleration, physics, and other ship enhancements/rebal
I was really speaking of the physics model before my last post.
But I see people focus a lot on the damage.
By the way I think you made a comment, let me try to answer it as well as I can.
If I ever try to implement the feature we're discussing, the goal will be to make sure that as little as possible of the calculations are done live. I'd store thrust strategy tables for the units in the data files. The way I see it, there's 3 modes, each divided into 2 sub-modes. .
The 3 modes would be (i) rotational acceleration under zero translational acceleration constraint (ii) translational acceleration under zero rotational acceleration constraint and (iii) rotational acceleration under no constraint.
The 2 sub-modes are more difficult to explain. For translational or rotational speed, there's a target (set by the player). This leads to a target direction for acceleration. This target acceleration direction is the direction of the vector obtained by substracting current speed from target speed. In one sub-mode, the chosen thrust coefficients are those which optimize acceleration in the target direction, without any constraint on accelerations in directions perpendicular to the target direction. The other sub-mode optimizes acceleration in the target direction, unde the constraint of zero acceleration in directions perpendicular to the target direction. If given enough time, both sub-modes converge towards the target speed. The first should be quicker, but that's not guaranteed, and there may be some weirdness along the way (of convergence towards the target speed).
Each of these mode/sub-mode combination require a 2D table to be computed prior to flight. Those tables are in spherical coordinates (without radius) and probably require something like 20x10 elements to work well. The tables describe thrust coefficients in terms of the target acceleration direction as defined in the previous paragraph.
In-flight, I linearly interpolate from a table every time a ship updates its instantaneous thrust coefficients. That probably amounts to the inversion you refer to above. Then I have other, more simple tables, also pre-calculated from which I derive translational and rotational acceleration (momentum) generated by each thruster.
When a thruster is damaged, or out of fuel, the computer detects it and falls into a failsafe mode in which all the calculations are done live, but are designed to be more simple with robust though severely sub-optimal outcomes.
If you have been reading until here, sorry for the headache, but I kind of find this sort of things fun. If a ship uses 12 thrusters, 2 per facing directions, all those calculations are useless. If a ship is from another design, they are necessary.
But I see people focus a lot on the damage.
By the way I think you made a comment, let me try to answer it as well as I can.
I certainly wouldn't want to cancel all the sophistication in computer-assisted flight, in fact I think I'd rather add some, like being able to set a target speed vector not facing towards front...You forget that after modeling each thruster subunit, you have to model its push against the ship and how it makes it turn. And on top of that, you have to have a fly-by-wire algorithm that will compute the inverse of that "push function" to let you move your joystick left and have the ship turn left. Effectively inverse functions meaning you cancel out all of the sophistication unless you go manual.
If I ever try to implement the feature we're discussing, the goal will be to make sure that as little as possible of the calculations are done live. I'd store thrust strategy tables for the units in the data files. The way I see it, there's 3 modes, each divided into 2 sub-modes. .
The 3 modes would be (i) rotational acceleration under zero translational acceleration constraint (ii) translational acceleration under zero rotational acceleration constraint and (iii) rotational acceleration under no constraint.
The 2 sub-modes are more difficult to explain. For translational or rotational speed, there's a target (set by the player). This leads to a target direction for acceleration. This target acceleration direction is the direction of the vector obtained by substracting current speed from target speed. In one sub-mode, the chosen thrust coefficients are those which optimize acceleration in the target direction, without any constraint on accelerations in directions perpendicular to the target direction. The other sub-mode optimizes acceleration in the target direction, unde the constraint of zero acceleration in directions perpendicular to the target direction. If given enough time, both sub-modes converge towards the target speed. The first should be quicker, but that's not guaranteed, and there may be some weirdness along the way (of convergence towards the target speed).
Each of these mode/sub-mode combination require a 2D table to be computed prior to flight. Those tables are in spherical coordinates (without radius) and probably require something like 20x10 elements to work well. The tables describe thrust coefficients in terms of the target acceleration direction as defined in the previous paragraph.
In-flight, I linearly interpolate from a table every time a ship updates its instantaneous thrust coefficients. That probably amounts to the inversion you refer to above. Then I have other, more simple tables, also pre-calculated from which I derive translational and rotational acceleration (momentum) generated by each thruster.
When a thruster is damaged, or out of fuel, the computer detects it and falls into a failsafe mode in which all the calculations are done live, but are designed to be more simple with robust though severely sub-optimal outcomes.
If you have been reading until here, sorry for the headache, but I kind of find this sort of things fun. If a ship uses 12 thrusters, 2 per facing directions, all those calculations are useless. If a ship is from another design, they are necessary.
-
- Elite
- Posts: 1363
- Joined: Sat Aug 04, 2007 3:42 pm
Re: Acceleration, physics, and other ship enhancements/rebal
It might be a good idea to split this whole "modeling individual thrusters" discussion into another topic.
-
- Hunter
- Posts: 94
- Joined: Tue Oct 30, 2012 10:39 pm
Re: Acceleration, physics, and other ship enhancements/rebal
Agreed. Sorry for the diversion by the way.Deus Siddis wrote:It might be a good idea to split this whole "modeling individual thrusters" discussion into another topic.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Vector thrust physics
Split here
-
- Elite
- Posts: 1363
- Joined: Sat Aug 04, 2007 3:42 pm
Re: Acceleration, physics, and other ship enhancements/rebal
No need to apologize, some of the best topics are discovered inside of and then split off from other topics.maze wrote: Agreed. Sorry for the diversion by the way.
Wow, so then turrets must be rigid bodies, isn't that overkill?klauss wrote: But that's what "thrusters as subunits" means.
And you do not have any stability issues with the joints connecting turrets with a ship? Like if the ship is spinning around at over one rotation per second, the joints still maintain their correct relative orientation and position?
-
- Bounty Hunter
- Posts: 174
- Joined: Mon Aug 13, 2012 8:49 am
Re: Vector thrust physics
These things would be fun though the ships should come with engines unless one buys the build it yourself kit with just the hull and electronics. I much like the targetable upgrades idea because more destroyable subsystems could be made to have interesting consequences. In the proposed new controls I posted there are lots buttons for wing men orders and some of them are to target subsystems and take them out one by one systematically.klauss wrote:...The way things have been made to work in Privateer mods is probably the best, with stock ships having no thrust, and thrusters being a mandatory (ie you can't launch without one) upgrade.maze wrote:Thrusters as sub-units also opens the door to pretty interesting items like a thrusters with the ability to move around its thrust direction...
Add locatable and targettable upgrades to the mix, which are on the FRT already, and you've got pretty much everything you (and I may I add) want.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Acceleration, physics, and other ship enhancements/rebal
Not really, if they need cockpits, separate mounts and sometimes reactors, and AI.Deus Siddis wrote:Wow, so then turrets must be rigid bodies, isn't that overkill?klauss wrote: But that's what "thrusters as subunits" means.
We don't use ODE or anything that complex. Mount points are anchored with 2 degrees of freedom usually, which keeps the turret neatly attached. There's no force propagation either, anything hitting the turret just damages it, so no opporunities for destabilization.Deus Siddis wrote:And you do not have any stability issues with the joints connecting turrets with a ship?
As I said, they're forced in place without any further dynamic simulation. That wouldn't work for thrusters, hence the increased effort that would entail simulating thrusters like that - we'd have to implement force transfer across joints. A really really really complex proposition.Deus Siddis wrote:Like if the ship is spinning around at over one rotation per second, the joints still maintain their correct relative orientation and position?
-
- Bounty Hunter
- Posts: 174
- Joined: Mon Aug 13, 2012 8:49 am
Re: Acceleration, physics, and other ship enhancements/rebal
Interesting! What I would like to see sooner than this would be simply making a difference between subunits and subsystems then making them targetable. I'm playing with the controls right now and I find it odd that cycling wingmen is the same button as cycling turrets. It is a bit odd cycling all of the turrets and missiles in an area. I would much rather target subunits by current target, friendlies, or hostiles when I choose to. Then choose saved groups of either turrents or wingmen to attack the subunit which could also be saved.
These are the proposed controls I am refering to. Wingmen would be subunits on the same flight group. Turrets and thrusters would be destroyable, and targetable subsystems and turrets would have separate controls. This would avoid some targeting clutter that would develop from implementing targetable subsystems and would allow a person to implement quite a few without the extra ones getting in the way at all.
These are the proposed controls I am refering to. Wingmen would be subunits on the same flight group. Turrets and thrusters would be destroyable, and targetable subsystems and turrets would have separate controls. This would avoid some targeting clutter that would develop from implementing targetable subsystems and would allow a person to implement quite a few without the extra ones getting in the way at all.
-
- Elite Venturer
- Posts: 753
- Joined: Sat Apr 15, 2006 2:40 am
- Location: chthonic safety
Re: Vector thrust physics
Basically, what's needed for proper physics is inertia tensor, which data-wise requires 3 MoI values (for each axis) to not be a sphere anymore.maze wrote:You must be kidding, it's not the same at all, for many reasons. Even forgetting about thruster damage:The net effect is almost the same, if you consider ships as perfect spheres. Which they're not. But it's a reasonable simplification given that more complex mechanics really don't necessarily translate to better gameplay.
What's needed for existing VS data, though, is MoI that at least corresponds to the given ship size. Or a config variable forcing engine to drop MoI data and calculate spherical MoI from each ship's mass and "radial size" (which is still better than all units treated as balls of radius less than meter and half) or try to "weight" mesh faces for proper MoI.
"Two Eyes Good, Eleven Eyes Better." -Michele Carter
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Vector thrust physics
We had pondered the idea of giving mesher the ability to compute mesh-based MoI, based on the assumption that mass would be somewhat (ie partially) concentrated on the ship's surface (armor).