Sounds good to me; or if people prefer, I could write a new physics; --been itching to do so since I found that link I posted in regards to RK4.klauss wrote:I agree. In fact it was my point when I wrote that it wasn't a trivial matter.safemode wrote:ps. moving to a new physics subsystem that can handle nifty effects like explosions and such isn't a bad idea, but not one that would happen soon. Replacing the collider with bullet or the like though, is a waste of time at the moment. The only thing that would require it would be needing to deal with colliding with dynamic meshes (meshes that bend and warp)...which we dont have and wont have anytime soon.
But it's not only to handle nifty effects... it's also to offload development. Which is good when we're short on time and/or developers.
In that sense, maybe ODE's development is a little slow... bullet seems more actively developed. But if you've found compatibility issues...
I know ODE works well in all our supported platforms. And it integrates well with opcode, BTW. In fact there's an example of how to use opcode as collision library with ODE as dynamics solver.
Or I could work on improving ODE. I found no references to RK4, but I'd be surprised if it doesn't use it. However, I also found no references to SIMD or SSE, and if it doesn't use SSE I'd be happy to work on that.
Opcode could use some refactoring, for sure; --ugly code--; and speeding up the critical routines with SSE would be an opportunity to refactor it as a side-line.
Good points all, and this in particular. Even friction at the point of contact could be hacked at the global object level by modulating torque force; so there's no need to "spawn" springs or the like.log0 wrote:2. Collisions
You don't need to use a spring-mass model.
The most simple model is an elastic collision of two point masses m0, m1 imho.
(ui, vi velocities along collision normal)
v0 = (u0 * (m0 - m1) + 2 * m1 * u1) / (m0 + m1)
v1 = (u1 * (m1 - m0) + 2 * m0 * u0) / (m0 + m1)
Then you may want to add some plasticity(coefficient of restitution cr).
v0 = (u0 * (m0 - cr * m1) + (cr + 1) * m1 * u1) / (m0 + m1)
v1 = (u1 * (m1 - cr * m0) + (cr + 1) * m0 * u0) / (m0 + m1)
The cool thing here is that you could use the loss of kinetic energy to describe the amount of damage.
This way it would automatically depend on the masses, velocities, restitutions of the colliding objects.
Still, from a design decisions point of view I would include springs as declarations of classes and functions, for the sake of completeness and scalability, even if they are left unimplemented.
Regarding point 4, what klauss means is that the code is already in place to use thrusters in all 6 directions; but the ship models don't show the thrusters (even though they have been a requirement repeated ad nauseum for the past 5 years or so)... ((If you think programmers are unmanageable, try artists...))
EDIT:
One thing that needs to change about ANY physics library we may decide upon is using doubles for the distance accumulators.
I'm not sure if we'd need doubles for speed.
At first thought, I'd say no.
On second thought, yes.
This second thought is that if a station is orbiting a planet, and its speed is, say, 30 kilometers per second, and you have a battle raging around the station, all speed precisions will suffer from the high "absolute speed" (oxymoron notwithstanding) of the station's surrounding space, as a whole.
So, unless we bite the bullet and decide to implement moving frames of reference, we're prbably better off keeping velocity vectors in double precision.