Shrugger! Unity!

[Draco18s]

You're welcome.

I wouldn't worry about smaller objects, unless you wanted to abstract them.  Or you could use the same physics, but say that the objects are smaller and faster (F=ma, after all).

Oxygen gas in space probably isn't a real issue.  Fluorine on the other hand is one of the most reactive gasses around.
http://www.scienceforums.net/topic/11696-most-corrosive-liquidgas-come-one-come-all-to-share-your-opinions/?p=183658

FOOF is in that list (F2O2).  Do not play with FOOF.  Do not let friends play with FOOF.  Don't let anyone within 100 miles (200 upwind) play with FOOF.

http://pipeline.corante.com/archives/2010/02/23/things_i_wont_work_with_dioxygen_difluoride.php

[Shrugging Khan]

Doing impact calculations now.
So I have two bodies of different masses. They crash into each other at a certain relative velocity. How do I calculate the energy of the impact?

Code: [Select]

Energy = Velocity * MassObviously, but how do I factor the fact that there are two objects into it?
Or is there actually no way to calculate the 'overall energy' of an impact?

Yes, my last physics lessons are rather far in the past.

Thanks for any tips!

[keith.lamothe]

I may be confusing this with something else, but isn't it mass * velocity * velocity?

To account for the two different parties I think two principles should handle it:
- velocity is the sum of the two, accounting for angle (so if it's a head-on it's v1+v2, if it's a t-bone then it's just the speed of the one hitting the side of the other, and if it's at a 45-degree angle it's the aggressor + half of the other one, I think)
- for every action there is an equal and opposite reaction.  In other words, that 100kg shell going 0.5c (100,000 grams at 150,000,000 m/s = 2,250,000,000,000,000,000,000 somethings) is going to wreck that million-ton starship, but the shell is a goner.  Of course it may already be a goner pre-impact due to collision with particles, dunno.

If you're doing ship-vs-ship collision the initial energy is presumably computed the same way, but the consequences are more complex because the energy doesn't propagate instantly or uniformly through either hull.  The structure may bear and absorb some of the force, or break in some places and dissipate some of the force that way, etc.

[Shrugging Khan]

Of course it's

Code: [Select]

Mass * Velocity²Silly me.

I've got the relative velocity calculation working (I think), the missing link right now is how to handle the masses.

Right now I'm guessing the 'overall' energy of the impact is

Code: [Select]

(Mass1 + Mass2) * RelativeVelocity²...is it? I'm not at all sure about this, but my google-fu is weak today. Maybe It should be

Code: [Select]

(Mass1 * Mass2) * Velocity²?

I'm actually playing around with the idea of including structural deformation, rather than to just let structural stress build up until a component disintegrates. Since most spaceship components are simple rectangular prisms, it shouldn't be too hard to let them get squashed a little. Ideas, ideas...

Edit: Wait, wait, it's

Code: [Select]

0.5 * mass * velocity²for a single body's kinetic energy. What does this tell us?

[keith.lamothe]

I think the total available (the proper term might be "latent", I forget) kinetic energy in a collision would be (mass_1 * total_relative_velocity^2) + (mass_2 * total_relative_velocity^2).

Or maybe half that, if that bit with 0.5 you found is applicable.

But the question is how much of that available energy will actually be released in the collision?

Bear in mind that the incoming ship (or shell, or whatever) is actually colliding with stuff all the time on its course.  But those little dust particles don't provide enough resistance (counter-force) to release any significant portion of the main actor's available kinetic energy.

Similarly, if a really high-energy projectile were to punch through a starship and keep going, not all of its available energy is released in the collision.

On the flip side, unless the projectile and ship are going head-on against each other and the impact completely stops (or reverses) the ship's vector, then only a portion of the ship's kinetic energy was actually released in the collision.  In fact in that case I think it's probably sufficient to only consider the bullet's energy and the impact of that on the ship, rather than treating it as a two-way thing.  Unless the ship is going rather fast indeed.  I guess it depends on just how pedantic you want to be

But ship-vs-ship would definiitely be two-way.  My guess is, in cases where the collision will actually stop both ships (and thus involve all or nearly all of their kinetic energy) to apply mass1's force to mass2, and then apply mass2's (pre-collision) force to mass1.  And see if that does kind of what you want.

[Draco18s]

Are you trying to get the resulting velocities?  Or the energy (measured as...?)

Elastic or inelastic collision?  Or some hybrid?*

*Technically all collisions are a mix of both.

[Oralordos]

I don't remember the formulas off the top of my head but I think you can find them under elastic and inelastic collisions. Try looking up conservation of momentum laws. There should be some stuff about some of the energy is kept to keep the colliding items moving, and some is used for the damage.

[Shrugging Khan]

Alright, thanks for the Physics tips. I ended up building yet another placeholder system, since neither armour nor materials are currently implemented, but eventually a more accurate abstraction incorporating deflection, penetration and deformation will take its place.

In other news, we've recently done

• Basic sensors/visibility
• Hit probability calculation and appropriate tactical considerations (Replacing "All the Dakka all the Time")
• First means of player input (AKA "outgrowing the snowglobe" or "we almost game nao")
• Basic bureaucratic AI for component and ship design
• Smarter target selection
• Interesting Terrain...it's not Terrain if it's in space, is it?
• Innumerable miscellaneous code improvements

And some others I can't remember. As always, everything is procedural.
Almost feels like it might grow up to be a game one day.

[keith.lamothe]

In other news, we've recently done

Congratulations on making so much progress

(Replacing "All the Dakka all the Time")

Hurh? (genuinely confused expression) ... Why replace optimal approach?

Interesting Terrain...it's not Terrain if it's in space, is it?

Slamming into a mountain is still slamming into a mountain, even if said mountain lacks the benefit of a supporting planet.

Almost feels like it might grow up to be a game one day.

Certainly sounds like it!

[Shrugging Khan]

I'm failing at maths and physics again.
In order to calculate the amount of time required to flip the ship around (relevant to getting the right time at which to switch from acceleration to deceleration), I need the angular acceleration potential of the ship, and that should be it. So...
(shipAngAcc in °/s², timeToFlip in seconds. 90° * 2 because we need to accelerate, then decelerate the rotation.)

Code: [Select]

Mathf.Sqrt((90° / shipAngAcc) * 2) = timeToFlipDoes this look about right?

------------------------------------------------------

Recent advances in glorious soviet engineering:

New shipbuilding procedure is resource-intensive but finished. Might have to make it a coroutine to stop the game from freezing for a few frames every time a new prototype is introduced (mass produced ships just use the component coordinates from the first one, which is a lot faster). Either way, we now have symmetrical ships with turrets and sensors on the outside, thrusters and spinal weapons in line with the Centre of Mass, and tougher parts being placed towards the front, all while keeping a minimal profile.

Guns have been balanced a great deal to no longer result in reload times exceeding the average ship lifetime by a factor of 30. 20,000 RPM guns have also been balanced out, since the safety equipment for them outweighed the rest of the ship and looked rather silly.

Made lots of little sanity checks (Isn't that an Arcen term?) elsewhere, too, such as keeping fleet bureaucracy from ordering ships to be build that couldn't be afforded, having blueprints re-prototyped if the first attempt failed. That said, insanity still prevails when it comes to turrets only firing every now and then, and then only in one short bursts (spinal guns are considerably more trigger happy) and to ships having no collision avoidance (and accidental ship collisions leading to more kills than gunfire or deliberate ramming).

[Draco18s]

(shipAngAcc in °/s², timeToFlip in seconds. 90° * 2 because we need to accelerate, then decelerate the rotation.)

Code: [Select]

Mathf.Sqrt((90° / shipAngAcc) * 2) = timeToFlipDoes this look about right?

Based on some fiddling in Excel, it's pretty darn close (I only tested with precise resolution of 1 second and mentally guessing at the tenths, but it looks fairly close).

I do get a calculated 13.4 seconds for an acceleration of 1 degree, and determining that at 13 seconds it's rotated 91 degrees....so I'm not sure what's up with that.

I'm going to say it's right and that my per-step calculation is off (that is, after 1 second it has accelerated up to 1 degree of rotation per second, but hasn't actually rotated a full degree yet, leading to the ~0.47 second discrepancy).

[keith.lamothe]

I'm failing at maths and physics again.
In order to calculate the amount of time required to flip the ship around (relevant to getting the right time at which to switch from acceleration to deceleration), I need the angular acceleration potential of the ship, and that should be it. So...
(shipAngAcc in °/s², timeToFlip in seconds. 90° * 2 because we need to accelerate, then decelerate the rotation.)

Code: [Select]

Mathf.Sqrt((90° / shipAngAcc) * 2) = timeToFlipDoes this look about right?

My brain isn't firing on all cylinders right now, but:

1) I need to turn 180 degrees.

2) My ship has (for example) an angular acceleration of (4 degrees-per-second) per-second

3) Using d = (1/2)*a*(t^2), I get:
180 = (1/2)*4*(t^2)
180 = 2(t^2)
90 = t^2
sqrt(90) = t
9.48 ~= t
So 9.48 seconds to flip without coming to rest.  Which isn't the answer we're looking for, but anyway.

4) Just targeting 90 degrees, with the deceleration from there being a mirror of that:
90 = (1/2)*4*(t^2)
sqrt(45) = t
6.71 ~= t
So 6.71 seconds to reach 90 degrees, and then 6.71 to come to rest at 180.  So in the neighborhood of 13.4 seconds for the full maneuver.

To sanity check:
1st second - start at 0 degress-per-second, end at 4 degrees-per-second, so 2 degrees travelled
2nd second - start at 4 degrees per second, end at 8 degrees-per-second, so 6 degrees travelled this second, 8 total
3rd second - from 8 to 12, so 10 this second, 18 total
4th second - from 12 to 16, so 14 this second, 32 total
5th second - from 16 to 20, so 18 this second, 50 total
6th second - from 20 to 24, so 22 this second, 72 total
7th second - accelerate for 0.71 seconds, from 24 from 26.84, avg 25.42, so 18 for this interval, 90 total
7th second part 2 - decelerate for 0.29 seconds, from 26.84 to 25.68, avg 26.26, so 7.6 for this interval, 97.6 total
8th second - from 25.68 to 21.68, avg 23.68, 121.28 total
9th second - from 21.68 to 17.68, avg 19.68, 140.96 total
10th second - from 17.68 to 13.68, avg 15.68, 156.64 total
11th second - from 13.68 to 9.68, avg 11.68, 168.32 total
12th second - from 9.68 to 5.68, avg 7.68, 176 total
13th second - from 5.68 to 1.68, avg 3.68, 179.68 total
14th second - from 1.68 to 0 in 0.42 seconds, avg 0.84, so 0.35 this second, 180.03 total (the extra because I rounded pretty loosely earlier)

So 13.42 seconds via a rough approximation model.


So looks like your:

"Mathf.Sqrt((90° / shipAngAcc) * 2) = timeToFlip"

would work better as:

"Mathf.Sqrt(90° / (shipAngAcc / 2) ) * 2 = timeToFlip"

If I'm to be trusted with math, that is.  And I'm not.

Recent advances in glorious soviet engineering:

New shipbuilding procedure is resource-intensive but finished. Might have to make it a coroutine to stop the game from freezing for a few frames every time a new prototype is introduced (mass produced ships just use the component coordinates from the first one, which is a lot faster). Either way, we now have symmetrical ships with turrets and sensors on the outside, thrusters and spinal weapons in line with the Centre of Mass, and tougher parts being placed towards the front, all while keeping a minimal profile.

Glorious indeed!

Though a coroutine still runs on the main thread, it would just be something you could spread over multiple frames.   You could multithread to really offload it from the main work, but that gets into a whole other can of worms where you'd need to send that other thread a copy of all the relevant data that was even theoretically capable of changing during its execution, or else have a lot of locking on "shared" mutable data.  So I hope coroutining fits your case (and you don't need to use Unity's coroutining for that, you can just write it to be done in multiple pieces, and do one piece each frame or whatever), or you find some other way of optimizing it

Guns have been balanced a great deal to no longer result in reload times exceeding the average ship lifetime by a factor of 30.

Sounds like you could have gone the other way and saved a lot on ammunition stowage!  "Um, comrade, why does gun have only one bullet?"  "Relax, comrade! We only get one shot."

20,000 RPM guns have also been balanced out, since the safety equipment for them outweighed the rest of the ship and looked rather silly.

What is this "safety equipment" you speak of?

Made lots of little sanity checks (Isn't that an Arcen term?)

What have we to do with sanity?

such as keeping fleet bureaucracy from ordering ships to be build that couldn't be afforded

Alas, sometimes realism must give way to game design considerations.

(and accidental ship collisions leading to more kills than gunfire or deliberate ramming).

It is as it should be!  It isn't so much crews taking ships into battle as it is terrified skaters going onto the ice with intermittent rocket boosters attached to each skate.

[Shrugging Khan]

I'll test the two formulas for time-to-flip and see which one gets better results. Thanks for helping, you two   

Though a coroutine still runs on the main thread, it would just be something you could spread over multiple frames.   You could multithread to really offload it from the main work, but that gets into a whole other can of worms where you'd need to send that other thread a copy of all the relevant data that was even theoretically capable of changing during its execution, or else have a lot of locking on "shared" mutable data.  So I hope coroutining fits your case (and you don't need to use Unity's coroutining for that, you can just write it to be done in multiple pieces, and do one piece each frame or whatever), or you find some other way of optimizing it

My plan was to deliberately spread it over multiple frames, and to my limited knowledge Unity's Coroutines would offer the most elegant way of doing it. Just handle the initial planning method as a coroutine, the subsequent specialised methods should also be able to use Yield - which I would then insert at the end of all those massive for loops.

To illustrate: Sticking together parts linearily and attaching spinal components (guns and thruster mostly) is fairly performance-friendly. Building a low-profile core in three dimensions happens via random trial and error, so it gets better the longer it's left to itself. Attaching turrets or sensors is the main issue - these are attached as rings, and as such have to test a variety of z-axis positions and angles of rotation to get a low profile. And unlike linear or core parts, which are mostly just axis-aligned cubes, these external devices can also be spherical or rotated. So it has to run a lot of tests to get usable results - and spreading those out over time would be both a boon to performance and a much more tangible prototyping experience; especially because you could watch the process

Sounds like you could have gone the other way and saved a lot on ammunition stowage!  "Um, comrade, why does gun have only one bullet?"  "Relax, comrade! We only get one shot."

Single-shot guns actually are a thing, as are ammunition shortages (although I've commented them out for testing...long ago), as are ideological differences concerning the value of the individual soldier.

What is this "safety equipment" you speak of?

Mostly just a large cylinder made of several thousand tons of iron, wrapped around the gun.

What have we to do with sanity?

Your games actually have to use sanity checks. 'Nuff said, eh?

Alas, sometimes realism must give way to game design considerations.

Bureaucratic failure is supposed to be part of the game, not its default state

It is as it should be!  It isn't so much crews taking ships into battle as it is terrified skaters going onto the ice with intermittent rocket boosters attached to each skate.

'Battle'. Heh. Right now it's mostly just single pilots finding themselves alone in giant capital ships, flailing wildly with the turrets while having other ships, debris and the terrain itself explode into fragments all around them as they overshoot their navigational targets by several kilometers, only to laser their own Rotation Control Systems off. I think one pilot even managed to shoot himself with a turret. And one gun shot itself.

...I like to think that those events do not actually reflect upon the state of the project.

[keith.lamothe]

My plan was to deliberately spread it over multiple frames, and to my limited knowledge Unity's Coroutines would offer the most elegant way of doing it. Just handle the initial planning method as a coroutine, the subsequent specialised methods should also be able to use Yield - which I would then insert at the end of all those massive for loops.

Yea, it's probably good enough to prove the concept with.  I'm just pathologically suspicious of engine features like coroutines: I'd rather do the breaking-into-bits myself, rather than wonder what's going on inside the black box.  But there's a lot to be said for rapid prototyping, and something to be said for giving the engine a chance and changing to a different approach later if it proves necessary (the striking regularity with which it does, in fact, prove necessary is a large source of said pathological suspicion).

especially because you could watch the process

The engraving shows a dwarf and a prototype capital ship.  The prototype menaces with masterwork adamantine spinal-mount grasers.  And a point defense cluster that somehow blocks both the main viewport and the main thrusters.

Mostly just a large cylinder made of several thousand tons of iron, wrapped around the gun.

Ah, yes, that kind of safety equipment.  Make ship safe, by launching safety equipment at high velocity at enemy ship! ... no?

I think one pilot even managed to shoot himself with a turret.

Given what you've told me of this universe, I am not at all sure said shot was unintentional.

...I like to think that those events do not actually reflect upon the state of the project.

Sounds like it's coming along quite nicely, actually (for once, I intend no comedic sarcasm).

[Shrugging Khan]

Getting back to Orbital Mechanics, I've started taking the hard route and doing it the KSP way - writing a separate physics system for them. The problem comes in the interactions between the Orbital Physics and the Rigidbody Physics.

1. How can I make Rigidbody interactions have proper effects on the Orbit? Difficulty: Adjusting the orbit to small collisions and thrust. I have a theory that I should just track the changes in velocity from one frame to the next and consider that kinetic energy, but I'd also have to subtract the orbital motion from that, and oyoyoy...

2. How can I let Orbital changes and Gravity have the right effects on the Rigidbodies? Difficulty: I somehow suspect that rigidbodies don't take kindly to being constantly pushed around by non-unity-physics forces, since I've already seen some strange behaviour when a rigidibody in motion was translated between two frames and it ended up somewhere it didn't expect to be.

3. Orbits require large, massive bodies, which greatly increases the distances in play. Even if it's just an earthlike 15,000 km or so, I'm guessing that the physics simulation will get pretty wonky that far away from the origin...

A separate issue is that I have no idea on how to actually calculate orbital mechanics. If anyone knows a good page to read - this non-mathematician would be quite grateful.
I don't want to open the can of worms that is writing an all-new physics engine, unless you really think that's the best way ;P

And obviously none of this is anyone's speciality here, so miscellaneous input is just as appreciated as qualified knowledge