Many people might remember Slime's spectacular Space Fight animations from
2002, and a rather smaller number may remember the early stages of the
Newtonian space flight simulator I started on last year. The initial
version wasn't too sophisticated, but some improvements have taken place.

http://www.compsoc.man.ac.uk/~tomy/graphics/graphics_anim.html

The two animations use the DivX 5.05 codec, and are 10MB and 6MB in size.
They were created using POV-Ray 3.5. Rendering times were typically less
than 10 seconds per frame on a 2.6GHz P4, although see later about the CSG
damage effects under "Things wrong".

As before, Newton's laws of motion are in full effect. Ships turn themselves
using thrusters and can travel in one direction whilst facing in a
different direction. Power supplies are now modelled so weapons charge up
correctly, and engines consume power when used (although in these
animations none of the ships had to dip into their reserves of energy).

Damage modelling is a little bit more sophisticated than before. Weapon
strikes remove bits of hull (although glancing/weak hits just cause a
scorch mark). Critical "locations" like power supplies, control centres etc
are not modelled, but this would be a minor addition. Ships can use weapons
on independently targetting turrets, but the turrets track instantly and
perfectly at the moment. Turrets carry their scorch marks/damage with them
as they rotate, which was tricky to do but opened the door for
location-specific damage. If a ship takes enough structural damage it will
flee from the nearest attacker.

Things wrong:

The CSG damage looks bad. Scorch marks are simple textured discs aligned
with the hull surface, which is obvious on strongly curved surfaces. CSG
differences are used to cut out damaged areas, but lead to a huge slowdown
in rendering, since I'm essentially subtracting small objects from a large
union. I plan to tackle the first with higher order surfaces. For the
second problem one solution might be to require ship models to have all
their
component objects available through an array, but it's not something I'd
enjoy. This CSG difference issue is the only problem that particularly vexes
me at the moment.

The AI is simplistic, which combined with the fixed view in these animations
makes "rubber-banding" painfully obvious. Since the AI is customizable on a
per-ship basis by the user, this is not a fixed limitation.

Things missing:

There is no collision detection, although the default AI can predict
collisions and will attempt to avoid them. I have tried using voxel-based
collision detection but it is very slow and I didn't achieve a very good
solution.

Explosions. The damage system, like the AI, is user customisable so this is
my own fault, I just haven't got around to pyrotechnics yet.

Post a reply to this message

Very nice project, and I couldn't help but notice the starship WIP on your
homepage - which is VERY impressive! It looks like it's built with POV-Ray
primitives, and yet it looks very very cool. I mean, typically it's not
enough to use primitives for starships due to the lack of bevelled edges and
smooth surfaces. But you've managed to do without. I'm sure that, with
clever texturing (and lighting) it's going to look really professional. :o)
Is it your own design?

Best Regards,
Hugo

Post a reply to this message

It looks good, however I think you need to make your ship motions more
fluid, perhaps if you included some pilots that in turn imposed G-force
limitations on the motion changes of the ships (and give the pilots a
tendency to keep their foot on the gas)

-- 
Rick

Kitty5 NewMedia http://Kitty5.com
POV-Ray News & Resources http://Povray.co.uk
TEL : (+44) 0845 1083740 - ICQ : 15776037

PGP Public Key : http://pgp.kitty5.com

Post a reply to this message

"Rick [Kitty5]" <ric### [at] kitty5com> wrote:
> It looks good, however I think you need to make your ship motions more
> fluid, perhaps if you included some pilots that in turn imposed G-force
> limitations on the motion changes of the ships

The maximum acceleration that the ships in these animations can produce is
about 9g, and only then with all main engines firing. The problem is more
that ships have a tiny attention span. They always engage the ship nearest
to them and try to turn towards it, which leads to jerky movement. If you
set up a duel between only two craft, the motion is very smooth indeed. I
think I need to give the controlling macros some frame-to-frame memory.

> (and give the pilots a tendency to keep their foot on the gas)

The problem with that is that the ship will be uncontrollable - it will
overshoot the target by increasing distances on each pass. You can see a
less severe version of this problem in the animations - a ship burns
towards a target, passes it at high speed and then has to swing around and
burn for up to twice as long to set up for another pass on the target. If
the engines are burned continuously the only flightpath that will keep the
ship in the battle is a circular motion about the target. As it is, the
amplitude of the overshoot actually decreases on each pass, and since these
animations were made I've improved the AI substantially, to the point where
it will execute some very tight turns by making fuller use of thrusters.

Post a reply to this message