See:

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

(7 animations encoded using the DivX 5.0.2 codec)

A while back, Slime posted a series of very swish automated space
battle animations. The animations at the page above are test renders of a
similar concept. In this system, the ships are subject to Newtonian
mechanics,conservation of momentum etc, and change their orientation using
"thrusters". Weapons fire is recorded and tracked by #reading and #writing
a list of in-flight bolts every frame. Hits on ships are also recorded in
this way, although at the moment nothing spectacular is done with the
information.

Frames in the "slow bullets" animation took 5 seconds each to render
(averaged over 300 frames) most of which was probably spent reading in the
weapons fire tracking file. Frames in the other animations took only a
second each, typically (beam weapons are not saved from frame to frame).

This is still work-in-progress at the moment. Only two rudimentary rules are
used to decide what a ship will do:

* If a ship takes more than 50% damage, it will flee from the nearest enemy
* A ship will target the nearest enemy and attempt to fly towards it

The camera control is currently experimental. Some animations take the
dot-product averaged sum of spacecraft positions and use that to decide
where to aim the camera. Some of the others use a fixed look_at position.

Post a reply to this message

Hm, not many comments around, so I thought I'd give it a go.
Before I read the text, I was somewhat stumped. What are those green boxes,
those white lines, what are they for? Then I read the text and understood.
The problem with these animations is that I can't see why and how a ship
turns, and the shooting-lines don't help much either. Aside of that, the
movement looks very fluid and soft, I like that. You should model some
preliminary ships and bullets, add some bullet-hit-effects (even if its just
a little partice-explosion or -sparks), take care that the thrusters are
visible, and then you've got something really fancy for us to look at.
Its always complicated to show off some code using place-holders, cause all
*we* see are the place-holders, the only one with knowledge of the
complicated script behind that is *you*. Making the script visually pleasing
is what I've found is best for displaying some script. What I do is prepare
and experiment with placeholders, but when I want to post it, I use actual
objects, or at least some crude ones. After all, people can only comment on
looks, not on the script itself.

So, to wrap it up: nice and soft movement, but the objects lack some detail.
;-)

Regards,
Tim

PS: I hope you make some nifty Include, so that we all can create our own
battles and such. Would be even better if you'd make it that Users might set
the initial positions and orientations for a given amount of ships, and then
they can compete. That would be awesome! (Especially if Users might modify
the looks of their spacecraft)

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: no_lights (@) digitaltwilight.de

> See:
>
> http://www.compsoc.man.ac.uk/~tomy/tbstest/tbstest.html
>
> (7 animations encoded using the DivX 5.0.2 codec)
>
> A while back, Slime posted a series of very swish automated space
> battle animations. The animations at the page above are test renders of a
> similar concept. In this system, the ships are subject to Newtonian
> mechanics,conservation of momentum etc, and change their orientation using
> "thrusters". Weapons fire is recorded and tracked by #reading and #writing
> a list of in-flight bolts every frame. Hits on ships are also recorded in
> this way, although at the moment nothing spectacular is done with the
> information.
>
> Frames in the "slow bullets" animation took 5 seconds each to render
> (averaged over 300 frames) most of which was probably spent reading in the
> weapons fire tracking file. Frames in the other animations took only a
> second each, typically (beam weapons are not saved from frame to frame).
>
> This is still work-in-progress at the moment. Only two rudimentary rules
are
> used to decide what a ship will do:
>
> * If a ship takes more than 50% damage, it will flee from the nearest
enemy
> * A ship will target the nearest enemy and attempt to fly towards it
>
> The camera control is currently experimental. Some animations take the
> dot-product averaged sum of spacecraft positions and use that to decide
> where to aim the camera. Some of the others use a fixed look_at position.
>
>
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.520 / Virus Database: 318 - Release Date: 18.09.2003

Post a reply to this message

Tim Nikias v2.0 wrote:
>Hm, not many comments around, so I thought I'd give it a go.
>Before I read the text, I was somewhat stumped. What are those green boxes,
>those white lines, what are they for? Then I read the text and understood.
>The problem with these animations is that I can't see why and how a ship
>turns, and the shooting-lines don't help much either.

The thruster firings are indicated by small white sticks, but I don't think
they survived the encoding process because of poorly chosen codec settings.

>Aside of that, the
>movement looks very fluid and soft, I like that. You should model some
>preliminary ships and bullets, add some bullet-hit-effects (even if its just
>a little partice-explosion or -sparks), take care that the thrusters are
>visible, and then you've got something really fancy for us to look at.

I'm glad you like it. The fluid motion is a result of the dynamics
simulation - I like the results I get from this much more than those from
splined paths (I'm inept with splines and can never visualise how the
velocity of an object following the path changes without rendering it all
through).

The appearance of the thrusters is specified by the ship model, and since
this model is intended for test renders I used sticks instead of something
flashy. The hit/damage effects and so on will soon be completely
user-specified, requiring no changes to the script, but first I've got to
make the script allow this...


>Its always complicated to show off some code using place-holders, cause all
>*we* see are the place-holders, the only one with knowledge of the
>complicated script behind that is *you*. Making the script visually pleasing
>is what I've found is best for displaying some script. What I do is prepare
>and experiment with placeholders, but when I want to post it, I use actual
>objects, or at least some crude ones. After all, people can only comment on
>looks, not on the script itself.

All very true. I'll re-render soon with some more appropriate models
(although they'll still be place-holders before I get some decent ones
finished) - I think a battle consisting of the POV logo vs. the lightwave,
XSI and 3D studio Max logos will be my first choice.

>PS: I hope you make some nifty Include, so that we all can create our own
>battles and such. Would be even better if you'd make it that Users might set
>the initial positions and orientations for a given amount of ships, and then
>they can compete. That would be awesome! (Especially if Users might modify
>the looks of their spacecraft)

As you rightly point out, it can't be apparent from these animations but the
system is designed to support such a goal. The ships are completely
user-designable - all that you need beyond just an include file for your
ship's object is to specify where thrusters and weapons are placed.  The
visual effects like weapons fire, damage and explosions will be
user-designable soon. The AI is going to be user-designable, although with
a reasonable default. The current test file looks something like

// Begin

#include "gundrone.inc"  <-- The test ship
#include "battle.inc"    <-- The work

AddShip(GunDrone, ...starting orientation, position and velocity...,
whose_side)
...
.....3 more of them...
...

UpdateBattle() <-- Do the work for this frame

// Camera and lights ...

......
// End


That's it - minor variations on that file were used to render all of the
animations. You just specify what you want and where you want it and it'll
carry on from there. The biggest problem at the moment is collision
detection between ships. Although none of the ships in the posted
animations collide because their thrusters are quite weak and they all
start off moving at different speeds, if they did collide they'd pass
through each other without interacting. That needs some work - I'm not
really sure how to handle it at the moment.

Post a reply to this message