[Freeciv-Dev] Re: unit animation

["Lukas Tönne" <lukas.toenne@xxxxxx>]

I just found out that my mail system wasn't configured properly, so this   
message is a little late, sorry for that :) .  
  
Am Mittwoch, 5. November 2003 20:06 schrieben Sie:  
> > Suppose each unit has a .png file like yours, and a spec file with:  
> >  
> > + The number of frames for each action. So you don't feel compelled to  
> >   create a specific number of frames to achieve what you want to do.  
> >  
> > + An optional number that specifies a pause (in frames, or ticks,  
> >   where one tick will probably be 1/60 second). So that you don't need  
> >   many redundant frames when little motion actually happens. Can save  
> >   disk space and memory.  
  
I have attached two different spec files. One is an extension of the current   
"units.spec" ("new_units.spec") and the other one uses an additional file   
("new_warrior.spec").  
The first approach has the advantage that there is only one spec file to load   
and maintain. OTOH it contains lots of redundant information, like the   
animation file names for every single animation sequence (storing all unit   
animations together in one file would simply be to big).  
In the second approach there's one file for each unit. On startup, the client   
would have to scan the tileset directory for available spec files (naming   
conventions would be helpful) and assign the animations that were found to   
the respective units (if animation is enabled, of course).   
I'm not sure how those tag things works, so the developers should choose the   
best. The ones i've used in the files probably aren't useful. The "tile   
center in the anim images" is the point in the animation images that should   
be centered on the midpoint of the terrain tiles. "row" means the _starting_   
row of a specific action. "directions" is the number of different animation   
sequences displaying the same action (normally 8). "frames" is the number of   
images in one row (frames of a sequence). "delay" is the desired delay   
between two frames in milliseconds (this could be altered by the client to   
allow faster / slower gameplay).  
  
> Won't the gif format achieve this?  
  
hrrrrmmpppffff ....  
The gif format can only be used to store uncompressed images since the   
compression algorithm is software patented (the files would be unacceptably   
huge). There's a similar format called mng that is GPL'd. Unfortunately mng   
is not yet implemented in freeciv, so we'll stick to png for now.  
  
> > There could also be random animations for selected terrain tiles;  
> > Occasional fireworks over a celebrating city, a small shining glimmer  
> > on the gold in gold-mountains. Whales and Fish. If you want to animate  
> > some of that, I think the code could be easily added after unit  
> > animation is set up.  
  
Fireworks indicating celebrating cities is a very idea. That's also quite   
useful, since you cannot tell whether a city is celebrating or not by simply   
looking on the map by now. Perhaps someone should work out a general spec   
file concept that allows more flexible implementation of animations, etc.  
  
> > > Apart from that i more and more like the idea of writing an OpenGL  
> > > client for freeciv. I personally prefer C++ instead of C,   
> > > [...]  
> > Before you put too much work in it, be sure to read reviews for  
> > Panzer General II and Panzer General III, and compare them.  
  
The point about 3D graphics in PGIII seems to be the "eye candy" thing: in   
fact the graphics are uglier than in 2D, and the 3D environment doesn't seem   
to help gameplay. For Freeciv, i think 3D can be a great advantage, since   
there are many features that IMO can be greatly improved by using 3D   
mathematics, e.g. map overview. I've attached a html file that covers my 
concept of such a client.   
If you mean the use of C++, well, that was an idea i had some time ago because  
 
there's hardly any good GUI available in C (apart from Gtk). I've exchanged   
views with Rafal recently and i think it's best to write a new client and GUI   
in C.  
  
______________________________________________________________________________
WEB.DE FreeMail wird 5 Jahre jung! Feiern Sie mit uns und
nutzen Sie die neuen Funktionen http://f.web.de/features/?mc=021130

[spec]

; Format and options of this spec file:
options = "+spec2"

[info]

[file]
gfx = "warrior"

[animations]

; width and height of the anim images
anim_dx = 80
anim_dy = 80
; tile center in the anim images
anim_cen_x = 40
anim_cen_y = 56

anims = { "row", "directions", "frames", "delay", "tag"

  0, 8, 16, 30, "anim.die"
  8, 8, 16, 30, "anim.fight"
  16, 8, 16, 30, "anim.fortify"
  24, 8, 16, 30, "anim.move"
  32, 8, 16, 30, "anim.none"

}

[spec]

; Format and options of this spec file:
options = "+spec2"

[info]

artists = "
    womoks <s-ren@xxxxxxxxxx>
    sorin <soroprisan@xxxxxxxxx>
    erwan <ervanc@xxxxxxxxxxxxxxxx>
    + awacs creator
"

[file]
gfx = "deluxe/units"

[grid_main]

x_top_left = 1
y_top_left = 1
dx = 64
dy = 48
is_pixel_border = 1

tiles = { "row", "column", "tag"

  0,  0, "u.settlers"
  0,  1, "u.engineers"
  0,  2, "u.warriors"
  0,  3, "u.phalanx"
  0,  4, "u.archers"
  0,  5, "u.legion"
  0,  6, "u.pikemen"
  0,  7, "u.musketeers"
  0,  8, "u.fanatics"
;  0,  9,
  1, 0, "u.partisan"
  1, 1, "u.alpine_troops"
  1, 2, "u.riflemen"
  1, 3, "u.marines"
  1, 4, "u.paratroopers"
  1, 5, "u.mech_inf"
  1, 6, "u.horsemen"
  1, 7, "u.chariot"
  1, 8, "u.elephants"

  2,  0, "u.crusaders"
  2,  1, "u.knights"
  2,  2, "u.dragoons"
  2,  3, "u.cavalry"
  2,  4, "u.armor";sorin
  2,  5, "u.catapult"
  2,  6, "u.cannon";sorin
  2,  7, "u.artillery"
  2,  8, "u.howitzer"

  3, 0, "u.fighter";sorin
  3, 1, "u.bomber";sorin
  3, 2, "u.helicopter"
  3, 3, "u.stealth_fighter"
  3, 4, "u.stealth_bomber"
  3, 5, "u.trireme";ervan
  3, 6, "u.caravel";ervan
  3, 7, "u.galleon"
  3, 8, "u.frigate"
; 3,  9,

  4, 0, "u.ironclad"
  4,  1, "u.destroyer"
  4,  2, "u.cruiser"
  4,  3, "u.aegis_cruiser"
  4,  4, "u.battleship"
  4,  5, "u.submarine"
  4,  6, "u.carrier"
  4,  7, "u.transport"
  4,  8, "u.cruise_missile"
;  4,  9,
  5, 0, "u.nuclear"
  5, 1, "u.diplomat"
  5, 2, "u.spy"
  5, 3, "u.caravan"
  5, 4, "u.freight";sorin
  5, 5, "u.explorer"
  5, 6, "u.awacs"

  6, 8, "u.barbarian_leader"

}

[animations]

; width and height of the anim images
anim_dx = 80
anim_dy = 80
; tile center in the anim images
anim_cen_x = 40
anim_cen_y = 56

anims = { "gfx", "row", "directions", "frames", "delay", "tag"

  "warrior", 0, 8, 16, 30, "u.warriors.die"
  "warrior", 8, 8, 16, 30, "u.warriors.fight"
  "warrior", 16, 8, 16, 30, "u.warriors.fortify"
  "warrior", 24, 8, 16, 30, "u.warriors.move"
  "warrior", 32, 8, 16, 30, "u.warriors.none"
;  "settler", 0, 8, 16, 30, "u.settlers.die"
;  "settler", 8, 8, 16, 30, "u.settlers.fight"
;  "settler", 16, 8, 16, 30, "u.settlers.fortify"
;  "settler", 24, 8, 16, 30, "u.settlers.move"
;  "settler", 32, 8, 16, 30, "u.settlers.none"
}

Freeciv OpenGl client concept proposal

The Map View

Differences to 2D clients

The main difference to a 2D client will be the usage of real 3D math. This means that the map is no longer just a set of 2D images blitted to the screen, but a set of polygons, which are given in 3D coordinates and rendered in 3D space. This allows much greater flexibility for the look of the map, but may also cause trouble, because the existing common client code is completely written for 2D clients and contains some features (e.g. map canvas code) that is either abundant or even hindering in a 3D client. This might make some change or at least extension of the client common code necessary to allow the use of 3D features.

Viewpoint and Camera

The most important feature is the use of a "camera". In a 2D client a single set of integer map coordinates is sufficient to describe the way a given map is rendered to the screen. In a 3D client more variables are needed, but there's also a greater amount of flexibility. 
Mathematically, the map view is completely described by a 4x4 floating point matrix. However, there are different ways to describe camera position, rotation, etc. which result in the same matrix and i will use the way that fits the needs best. I will assume, that the map is lying in the x-y plane with the z coodinate describing the height above the map. The length of a maptile side in 3D space should be 1, since this simplifies lots of calculations. 
First there is the camera viewpoint (aka "look-at" point) given as a 2D vector on the map plane (i.e. in the form [x, y, 0]). If x and y were integers this would result in the map coordinates used by 2D clients, but floating point numbers should be used in order to allow smooth camera movement and scrolling effects. 
The actual position of the camera would normally be given as a vector relative to it's viewpoint at some point above the map. In a "classical" top-view style this vector would be orthogonal the x-y plane (i.e. in the form [0, 0, z]), thus rendering map tiles as squares. In an isometric style it would have an angle of 30 degrees to the x-y plane and would be rotated about 45 degrees about the z axis. The distance to the viewpoint (i.e. the length of the position vector) is determined by the required near clipping plane distance as well as by the third variable, the viewing angle (aka field-of-view, FOV; the term "focal length" used for real photographic or video cameras is inverse proportional to this). 
In a classical camera style (which could be used to "simulate" a 2D client) an orthogonal projection matrix would be used, which means that every map tile has the same shape and size, no matter if it's near or far from the camera. In this case the FOV is 0 and the corresponding focal lenth is infinite. 
But one of the main reasons for using a 3D client is the possibility of using perspective projections with a FOV > 0. Typical values lie between 30 and 90 degrees. Lower values will approach the orthogonal view while higher ones will result in some sort of "fisheye" projection. 
The last variable needed is the so called roll angle, which describes the rotation of the camera about to it's position vector. Normally this would simply be 0, but interesting effects can be achived, e.g. when "flying" the camera over the map like a plane. 

Many other zoom/movement effects are possibly, but at least one could be helpful, which is zooming in on a maptile when the city dialog or the terrain info dialog is called. This could be done either by moving the camera (reducing the distance to the viewpoint) or by changing the FOV.

Maptile concept

The way map tiles are drawn differs in a 3D client. Instead of simply blitting an image, one would render a set of textured polygons. The client will have to load or calculate one predefined polygon structure for every type of terrain at startup, similar to loading the different terrain type images in a 2D client. The best (easiest) way to render basic terrain tiles is a height map, which is a square array of regularly arranged points ("vertices" in 3D graphics terms) with a defined height. Every vertex has a height value (and a constant x-y-position that results directly from the vertex's logical position in the array) and a normal vector, which is a 3D vector with a length of 1 used for lighting calculations. 
The more polygons a height map contains, the more polygons will have to be drawn per second. To many polygons can lead to jerky map rendering especially on computers without 3D hardware acceleration, so the height map arrays must not be too big. The number of vertices on one side of the height map must be of course at least 2 and should not exceed perhaps about 5, but that should be an adjustable client option. Also the height maps for all terrain types should have the same amount of polygons for simplicity reasons! 
Similar to the dithering done in 2D clients to smoothly connect neighboured map tiles, the height maps of neighboured map tiles must be adapted in realtime to prevent gaps in the map. The fastest way to do this is probably to linearly mix the height values of neighboured map tiles. There are some different conceivable methods that have to be implemented and tested 
Apart from the basic terrain texture there are several other tile features that have to be displayed on one map tile. Some of these can be displayed using small 3D models (e.g. mines, specials, trees?), but the others are surface features that should be rendered on the surface polygons (e.g. irrigation, rivers, ...). Rendering the same polygon mutilple times using different textures is a bad idea, since this would cause Z-Buffer problems (resulting in a flickering appearance) and is probably slow. It is possible to render a polygon using a set of layered textures, but afaik the number of textures used with this is limited and this is also quite slow. I think the best way to go is to render the required textures onto one empty offscreen-texture one after the other (yes, that's possible) and then draw the actual polygons using this combined texture. I suppose this is the fastest and still easiest and most elegant way. 
Lots of other "eye candy" features are imaginable, like e.g. dirty smoke indicating pollution, particle systems or animated specials. However it should be the primary goal to implement the features that are really needed or at least useful in terms of gameplay and user interface and leave the unnecessary stuff behind !

Units

As one can imagine, an important goal of a 3D client is using (animated) 3D unit models. However the modeling and animating units is time consuming and not really necessary for playability. Also there might be modpacks and changes that invent new unit types, which would require new models and could not be used until someone created them. Therfore i think i would be best to have different types of "complextity" for units. The lowest stage would be a single textured quadrangle that uses the unit image for 2D clients as texture. The 3D models could be animated or not or could be used with partially finished animations (useful for testing). The user could set a requested detail level as a client option and if that stage is not yet available for a particular model, the highest available stage is used. This is also important for users who have slower computers and/or no hardware acceleration - less polygons means better performance 
One problem turning up with this extended unit/terrain/etc. type features is the need for different spec files. They will have to be extended for 3D models, texture coordinates, etc.

Cities

Like the units can be displayed using a single polygon, so should be cities. But since we use 3D, it would be a really cool feature to use 3D models for cities. I imagine rendering cities with low-poly buildings, arranged in an array of about 4 to 8 squares on a side. There would be a different set of small and large buildings for every city style (european, asian, modern, ...) and size. 
Like the general maptiles, the cities have some special attributes, that can/should/must be displayed, like city walls, turmoil and "We love the *** " day. So there's much more space for good ideas  ;-)  !