GAE 0.3 planning

[daniel.santos]

The models are perfect weedkiller, thanks!!

When I load the skill type in gae, I will check to see if there is an <animations> node before loading from <animation>.  Much like <sounds>, <animations> will be a collection of animation sequences.  I can't remember who, but somebody had previously asked for the ability to have random animation sequences for attacks and such (so they don't do the same attack over and over) and this mechanism will satisfy that.  The attribute "prob" is short for "probability" and is the naming convention used in the tileset.xml, so I figured I would keep to that.

So this will allow multiple animation sequences and each sequence can have items that get toss about, specifying their initial coordinates (relative to the unit model), rotation, velocity and angular velocity, velocity will be effected by the last hit that killed them and angular velocity will probably stay the same until it hits something, which we'll let the physics stuff take care of. (BTW, the probability values are floating point, don't actually have to add up to 100 and are optional defaulting to 1).

I don't need it on the swordman death animation, but this is how the advanced animation playback will work

Code: [Select]

<animations>
<animation>
<play path="models/swordman_dying_unit.g3d">
<frames start="0" end="3.2"/>
<frames start="5" end="4"/>
</play>
<animation>
<animations>
What happens here is that the animation will play from frame zero (the the 1st frame, we're using zero-indexing) through to frame 3 and then 20% of the way from there to frame 4.  Then, the animation will morph from that point to frame 5 (ideally this will be very similar to 3.2, otherwise it will look jumpy), and play backwards to frame 4.  If not specified, the animation will just play from the 1st to the last frame like it always does, but this should extend the usability of animations quite a bit.

I haven't gotten to flushing out the tileset.xml just yet, but I pretty much know what I want.  Basically, each <model> tag will optionally have a "blowable" animation or something (that sounds bad ).  The 1st frame will be interpreted as normal position, the 2nd will be full tilt 0 degrees and the remaining frames will be interpreted as fully extended in their respective directions.  These "animations" must have at least 4 frames or it dies upon loading.

[wciow]

WOW! This is awesome!  

You've hugely expanded the possibilities for Glest animations. I can't wait to start tinkering with the xml values to see what can be done with this.

[weedkiller]

not really somethink i can add Awesome!!!
Well, multiple attackanis is now possible i think, thats so great, and the animationsystem is "programmable" via xml, so you could perhaps use the tossing-objects as "particles" or something (ok, i have no concret example, perhaps the beehe-cage of indians or fire... ).

In order to convert the existing units to this death-style, is the current release of GAWE already with this features? I think i wont be able to set the parameters corectly without try and error, only position perhaps.
Ok, when this is in the release i can head towards converting all the units, there are some preparations i can already make, like importing every model and undoing the error this brings with it...

One question, i might find this out myself, but you dont really mean "morph" with thisf framejump or? (the jump from 3,+20%(4) to 5) It cant interpolate as thert is not really time for it or? Even if it is so thers no problem with it as it wont make sense if this morph is necessary (why should you join animations which dont fit together).

Once again, big thanks to you daniel.

[orion]

Daniel, I emailed you concerning the key for your server so I could put the website up. I emailed you on Saturday. Please reply with instructions on how to make the key.

[daniel.santos]

wciow & weedkiller,

hehe, this isn't done yet, I'm just working out the specifications 0.3.  

weedkiller, your comments make me consider putting "tossable items" into a separate xml file like particles. Also, a tossed object should be able to be optionally associated with a particle system, but perhaps the very approach of calling them tossable objects is constraining the true scope of how this functionality is supposed to play out.  Each of these "items" will inherit from Shared::Graphics::Entity (new class as of 0.2.26), but at some point we may want to reuse a model and stick a different weapon on them and this may solve such a need.  It may also solve the need to have an item or weapon on a unit or building that emits particles (i.e., is tied to a particle system) like a torch.  For the longest time, I've been annoyed by the way light suddenly appears at  light.  I would rather see torches come out and be lit, with smoke and perhaps an occasional spark flying out.

But anyway, back to frame management in animation playback, I realize that this needs to be much more sophisticated than illustrated.  For splicing and such, we need to be able to describe the morphing process, something like this....

Code: [Select]

<animations>
   <animation prob="1" type="loop">
      <source name="die" path="models/swordman_dying_unit.g3d">
      <source name="fight" path="models/swordman_fight.g3d">
      <frames source="die" start="0" end="3.2" splice-time="0.5"/>
      <frames source="fight" start="5" end="4" splice-time="0"/>
      <frames source="fight" start="4" end="5" splice-time="0"/>
      <frames source="fight" start="5" end="4" splice-time="0.45"/>
      <frames source="die" start="3.2" end="0"/>
   <animation>
<animations>This snippet would hypothetically cause the unit to do a bit of a fall down on the ground, get up and kick around, go back to the ground and get up again type of dance using existing animations, if those animations would actually facilitate it, which, I"m sure we would get it to ... well, except that I took my sleep meds so I might not remember it tomorrow.  Feedback and scrutiny here greatly appreciated!

Anyway, the lines of text are starting to get wavey, please think of features that it needs, should have and tell me what I'm missing.

Here's my 1st rendition of a whatsit definition.  We may put whatsits in a separate xml file or we may just let the suckers get really big.  This is VERY preliminary.

Basic bird whatsit in forest tileset

Code: [Select]

<whatsits>
<whatsit>
<name value="bird"/>
<actions>

<!-- definition of movement between hangouts and between other actions -->
<action name="fly" type="move">
<animiation path="models/bird1_flying.g3d"/>
<speed value="550"/>
<sounds enabled="true">
<sound path="sounds/bird_flying.wav"/>
</sounds>
</action>

<!-- wondering around on the ground -->
<action name="peck_ground" type="mosey" prob="1">
<speed value="5"/>
<time-of-day start="0" end="0"/>
<animiation path="models/bird1_pecking.g3d"/>
<sounds enabled="false"/>
<min-altitude value="-0.1"/>
<max-altitude value="100"/>
<locations name="ground_areas"/>
</action>

<!-- sitting in a static location, possibly off the ground -->
<action name="sing" type="hang_out" prob="1">
<time-of-day start="0" end="0"/>
<animiation path="models/bird1_singing.g3d"/>
<sounds enabled="true">
<sound path="sounds/bird1_song1.wav" prob="1"/>
<sound path="sounds/bird1_song2.wav" prob="1"/>
</sounds>

<min-altitude value="-0.1"/>
<max-altitude value="100"/>
<locations name="hang_outs"/>
</action>

</actions>

<locations name="ground_areas">
<location surface="0"/>
<location surface="1"/>
<location object="0"/>
<location object="1"/>
<location object="3"/>
<location object="4"/>
<location object="5"/>
</locations>

<locations name="hang_outs">
<location prob="1" object="0" model="0" x="0" y="0" z="0"/>
<location prob="1" object="0" model="0" x="0.2" y="0" z="0"/>
<location prob="1" object="0" model="1" x="0" y="0" z="0"/>
</locations>

</whatsit>
</whatsits>

First off, actions are analogous to skills, only significantly less sophisticated.  At this point, I'm only recognizing 3 or 4 actions, the 4th (not listed) being "run away from players".  These entities do not have hit points, they can't be hurt, they are just cute (or ugly as the case may be).  The "move" action simply defines how the whatsit moves from one location to another.  The "mosey" is where the whatsit wonders around a small area doing what it's interested in.  This may be making mating calls, pecking for seeds, digging holes, whatever.  mosey actions occur on the ground and can optionally (will usually) be constrained to a set of surface tiles or the tiles beneath certain tileset objects like trees, bushes, riverside objects, etc.  You'll notice that altitude is specified.  Some whatsits can be water creatures, and their altitude may never go above 0.0 or 0.1 or if they don't like shallow water, maybe even -2.  Birds can have another action for "taking a bath" that occurs in -0.1 to -0.2 ish altitudes.

Hang outs are static locations where a unit will travel to and stay there for some time performing some action.  For the bird, this is singing.  For another creature, it may be sleeping, waiting for prey calling for a mate, etc.  The above example specifies a few trees and locations in those trees.  This will be a long list in the end and will unfortunately take a bit of time to work out, but I have a plan for making it easier.

After careful thought, I decided that the location definitions should be kept separate from the actions that use them since there can be more than one action that uses the same set of locations and this data can become rather long (thus, the "once and only once" design principle).  Both mosey and hang_out actions need a lot more parameters in order to create a believable facsimile of wildlife behavior.  Birds will need to sit in the same place and randomly sing their songs with delays in between songs. Squirrels while moseying may need to alternate between fiddling with the ground to eating stuff, so I'll be replacing the <animation> tags above with the <animations> structure described at the beginning of this post.

But again, please remember that this is a specification in progress.  I'm planning on keeping the 0.2 branch around for a bit because I expect to have 0.3 broken for a good long time while overhauling a lot of this core functionality.  In the end, I need to come out of it with enough cool features to justify breaking a lot of Martino's paradigms (we programmers are very picky about these kinds of things) so I want to make sure this is done right

[wciow]

Feedback and scrutiny here greatly appreciated!  What do you as the 3d & artistic talent need to make a really an awesome game into a really awesome game, thereby rendering the release of Starcraft 2 a joke?  I want to see gae/glest become the new halflife, unreal or quake engine that's reused in game after game.

From a 3D point of veiw no-one has really tested the limits Glest. I would say that you could comfortably double the polygon count and texture resolution for all the models in the game without a huge performance hit on an mid range pc. Most of the models for the FPM use slightly more polygons and already have twice the texture resolution (512 instead of 256).

IMO the biggest thing that needs overhauling is the Tileset/Terrain system. The plans for animated foliage is a good start. Also adding a good wildlife system with some simple AI could be a feature that really makes people sit up and take notice of GAE.

I don't really know how the tile system works in Glest but it needs some improvements to be on par with a commercial RTS engine.

Also, if you are planning on making the FPM as the showpiece for GAE. Then we are going to need an animator. My animation skills are nowhere near commercial standards as evidenced by the poor animations currently in the FPM.

[ZaggyDad]

*raises hands eagerly*

~Zaggy

[daniel.santos]

ZaggyDad,
What specifically are you raising your hand for?  If it's the animations, all of the .blend files are in subversion https://glest.codemonger.org/svn/repos/ ... h_magitech.

wciow,
It just occurred to me that I haven't integrated the crypt yet, sorry!  I'm going to look at Duke's suggestions and figure out a good place to put it in the tech tree.

But back to the topic, I agree on the terrain/tileset schema although I don't have a clear solution in mind.  A lot of this is because I don't understand enough yet about how the tileset is rendered and there's still a lot of this stuff that's new to me (OpenGL, 3d math, etc.).  I've done some of this several years ago in Quake 2 mods, but nothing this intense, so I'm still going through a big learning curve (like everybody else).  I'm afraid that as soon as I reach a point where I'm not learning, I tend to loose interest.  Luckily, I have a LOT to learn here

[ZaggyDad]

Yeah, I was raising them for animations (and icons, too...).

Btw, it says I don't have permission to access the repository.

What you could do for the wind stuff in the trees is add vertex groups (the things that tell bones what to modify)and make the stuff in the vertex groups be rotated in the direction the wind is moving.

~Zaggy

[weedkiller]

Something to the pushable limits of glest;
I think the best way to give glest more detail is via the way daniel is already working on: Giving more deep-feeling by detailed and unrepeating ]details?![ (i mean; all that squirrels and birds and snakes, waveing trees, maybe new particel-systems, more animation-features like multiattack-animations, little death physiks for weapons...).

GRAFICS-ENHANCEMENT
I think in the way most commercial games are "deepenered" thats no choice for glest because: Higher texture-needings will significantly decrease the number of machines it runs on (atm even a EEE-Pc can rock glest although with many restrictions). So i think, you could put in bumpmaps but thats it. Different lightning-techniques should be optional, perhaps per pixel lightning (so bumpmapping would work :lol:. And i think the additional features gae brings into glest will take some horsepower, so we can save that on the grafics-side... (ok, that calculation is nor really fitting as we talk of CPU and GPU as one thing but i mean we should keep the limitations only depending on one part(cpu) and hope that every state-of-the-art gpu is willing to play our game).

So back to the logic-details:
I dont know if i overread something but:

ANIMAL-ANIMATION
Your idea sounds great so far, theres only one problem i see when a bird should land on a brunch or a squirrel jumps up a trunk: It may occure that the push through the wall

ANIMATION-SPECS
According to your animation-specs: that looks really nice
I only read all this news and wanted to push out myself thinking about it  

[daniel.santos]

ZaggyDad, send me an email and I'll get you set up

[orion]

speaking of email, when you have the time, can you get me set up on your server please? (the website)

[ZaggyDad]

Have you finished the htmls yet?

Btw, I emailed you. Do you need anything more than an email? (Like my IP?)

~Zaggy

[daniel.santos]

Ok, I didn't get a chance to respond to weedkiller yet!!  Also, I didn't get to comment on a few things wciow said a few days ago, so here goes.

Texture sizes & polygon counts
I agree that we should be able to use much higher resolution textures and models (polygon counts).  However, I want GAE to still run find on a 700MHz Celleron and also be able to view much more landscape at a time (maybe less on lower end machines).  My idea at the moment is to have a single set of high resolution textures & detailed models, but have the engine create multiple scaled down versions of models & textures at load time and then only display the resolution (poly count & texture size) that's actually going matter at the viewing distance.  I'm still not 100% sure on the feasibility of this from an artistic standpoint (not letting it screw up the model when it scales down), but I believe it can be done in a reasonable amount of load time.  Possibly, the results can be optionally cached to speed up loading (after the 1st load at least).

First, I think that this is needed to facilitate a greater viewing distance.  I would like for the camera to see as far as the army of units can and zoom out to where the entire map is on screen at once.  Also, the configuration should be able to tell the engine to use lower resolution models and/or textures to help frame rates on slower machines.  As weedkiller mentioned, maybe even per-pixel lighting and bump maps!!  I've noticed that different parts of the tree tend to sway differently at different times.  Thus, I thought that breaking the tree up into multiple pieces (is meshes the word for this?) could facilitate better simulation of this.  I've learned that we definitely don't want to have the objects sway based soley upon the wind speed, because they tend to bend down, where they get less wind so they bounce back up, catch more wind and bend down again, etc.

Animal Animations
weedkiller brings up some very good points, some of which I've considered, some I haven't.  So it looks like objects (like trees) that wave in the wind will have to have meta data that we can use to align the "hang out" locations.  So for a tree, the meta-data should include the axis of rotation which will probably be somewhere in the trunk or for saplings or smaller plants, will be where it meets the ground or even very slightly below that.  This is the part of the model that doesn't move.  Then, at the top of the model, we define the "top" location of each "bend" frame (for lack of a better word).  So we can use the "axis" and "top" locations to calculate the hang-out locations (where the birds are perching) so that they sway with the tree.  If we break the trees up into multiple pieces (as mentioned above) then the "top" location would have to be set for each piece.

But this doesn't solve the problem with "fly in lines" or "approach paths" (we'll have to find a good name for this too!  Here's the 1st idea I don't like:

Once upon a time there was a pretty tree with lots of polygons.  But as pretty as the tree was, children used to laugh and tease the tree about it's polygons.  "Hehe, those are SO triangular," one would say.  "They aren't even bump mapped!" another teased.  But none of this seemed to bring the tree down.  Little did those children realize just how special those polygons were!

It's not because they had a texture associated with them.  It's not even because they had normal vectors.  They were walkable polygons!  What are "walkable" polygons you might ask?  Why they are the most special kind, they are polygons with meta data!  It's walkable meta data that lets squirrels know that a polygon is part of a trunk that they can climb up to get to their favorite branches and lets birds know that it's part of a branch they can sit on them and build their nests!  There's even polygon meta data that lets deer know that it's their favorite type of leaf to eat!

So no matter how much the children teased, the tree knew how special it's polygons were, so nobody could ever get tree down.. well, until that worker came by with an axe....

Ok, see why I don't like that idea much?  First off, I'm not too big on faerie tales, second, it has a sucky ending and thirdly, it would mean altering the model format, yuck!  The other idea I don't like is the tedious work of manually creating all of these lines for travel.  I think that the g3d model viewer should be hacked, err, enhanced so that we can play with the model to find all of these lines and points and have them recorded in the proper xml format for us, but it's still a lot of work by hand.

Either way, one of these solutions will be needed and the data can then be easily referenced from the corresponding cells so that pathing wont take a lot of calculations (like it would if we were trying to look at this data globally).  It also occurred to me that whatsits will have often have more than one "travel" action -- for squirrels, they can jump from branch to branch and birds can also walk, but each of these has constraints.  I'm going to figure out a good way to organize these data structures in the xml files.

Animations

Since the full playbackspeed should really influence the whole animation the morphtime should be relative to the animation, so perhaps X-frames, this should be possible as the animations should be so similar that its not the game forcing something but only saveing the diskspace which another g3d would require that atm.

Yea, that's exactly it.  Largely, this whole animation cut & paste stuff is for reducing the amount of required disk space, but it's mostly for allowing the modder to do the most possible with the minimal animations.  OK, I admit it, it's also cause I haven't learned out to animate or even make models yet, but that's beisde the point!

So let me modify my last animation example

Code: [Select]

<animations playback="loop">
   <animation prob="1" type="simple" path="models/swordman_fight.g3d"/>
   <animation prob="1" type="compound">
      <source name="die" path="models/swordman_dying_unit.g3d">
      <source name="fight" path="models/swordman_fight.g3d">
      <frames source="die" start="0" end="3.2" splice-time="0.5"/>
      <frames source="fight" start="5" end="4" splice-time="0"/>
      <frames source="fight" start="4" end="5" splice-time="0"/>
      <frames source="fight" start="5" end="4" splice-time="0.45"/>
      <frames source="die" start="3.2" end="0"/>
   </animation>
<animations>The "prob" attribute (probability) is always optional and defaults to 1.  To keep things cleaner, we'll have a type on the animation, which is simple or compound.  A simple animation looks exactly like it would have before, except that we have a "type" attribute and an optional "prob."  The compound type will be the new cut & paste, hack-'em-up style animation.  Note that splice-time is a floating point number.  Normally, there are 39 interpolated frame between each actual frame in a g3d animation file (somebody please correct me if I'm wrong).  The splice-time attribute specifies, in relative terms, the number of interpolated frames there will be from the end of the <frames> collection and the beginning of the next <fames> collection.  splice-time is ignored if it's in the last collection of <frames>.

But we haven't gotten rid of the <anim-speed> tag!  The speed at which the animation is played still is determined by this, example: <anim-speed value="100"/>.

[wciow]

Theres alot of stuff to comment on here so I'll try to address it point by point.

While I agree that the viewing distance for the camera should be increased this is going to cause problems for slower machines. Currently the engine seems to load and unload models on-the-fly within a certain distance of the camera. Increasing the viewable distance means more memory is nessicary since more objects will be viewable at once.

Having mipmapping and LOD models will significantly lessen the load on the engine but from an artistic point of view the amount of work essentially doubles for each mesh, since 3 or more LOD models must be made. Adding bump maps will increase the time per model even more since a high resolution model must be created for each low-res one!

On the animal animations, I think this could pose some problems in terms of getting the animals to align correctly with world model (trees,etc). Also there is obviously a need for some simple AI to move these guys about randomly (anyone know AI programming ? ). However I think if you can pull this off it will be really pushing the boundries in terms of RTS.

The metadata stuff might be possible by updating the blender export script to read some additional info from blender. I'm not sure exactly what needs to be done here but in principle in would be easier than hand editing the xml files. Then the G3D format would have to be upgraded to cope with the new data.

Also, the best thing that can be done to increase scalability for old machines is to make as many of the new features optional in the configurator.

[weedkiller]

AnimalWaveTreeIdea


hi, thats my current idea on how to implement the Animalmovement,
but it only is about how finding a moving tree and still have positions where birds could sit.

I think globally, animals should walk from cell to cell like normal units (with pathfinding). As they are heavilly smaller than a cell, they will not walk straightly though the cell heading to their aim (as units do?) but will wolk in circles or something. They will stop from time to time, but this are question of arts. Just technically i see no better way than splitting the movement in regard to the cells.
//EDIT:
perhaps we can decrease the area for the meta-walk-lines so that the animal wont folow them from the borders of the cell but only in its middle, because theres the tree. Walking on the tree without this lines maybe hard but everything else may be possible.
so we are not necesarily limited by the cells.
//Edit out

Ah and daniel, your way of expressing is kindof confusing me sometimes  <img src="{SMILIES_PATH}/icon_eek.gif" alt=":shock:" title="Shocked" /> but this may be because i am no native english speaker... I think the same, that this additional metadata should be simple as it can be but without it i see no way how to implement this animal thing. If the animal shell climb on that tree you need heavy algoriths which let it not plop though the surface or save some data for it how to do.
I think the part i describe in the top picture is not to much work. If we talk about that or bumpmapping i would prefer that, ok we just need a new exporter but i can do that. There is no hacking in the g3d-viewer necessary.

To aimation-specs: sounds good, i dindnt know much about this in the engine. So the morphfloat between frames only tell glest, if its good to interpolate here or save the work right? Thats very good.

To your new ideas of high poly and textures and viewangle, thats a good idea too. Only i must tell that i think its more possible to reduce data and calculation if you limit the interpolation rate than the model. Especially the UV-layout soon limits the possibility to reduce the model for a algorith.
Textures can easily be made fit to your machine, that can be easily done with a algorithm.
The higher viewingangle: thats too a very nice thing to improve quality and it can be regulated by the game itself, if your framerate drops too much, it just zooms slowly in and wont let you out much unless it works better.
There are only some aspects of ogengl that limits the way how much you can zoom in or out, i think we have to play around with near/far-clipping plane to get nice results. Perhaps this can be on the fly by the game?

EDIT (by daniel.santos 2009-09-18): Inserted image in-line

[Ishmaru]

Hi well I really like the Idea of animals, and yes it would help show glest power as an engine. HOWEVER adding these would rob the system of reources that could be better spent on other things that would improve gameplay such as multi animations for attacking standing etc. These are much more noticeable than the animals since most players would be concentrating on building and fighting.


What would be much more simple is to create a stationary object with a longer looping animation with an animals such as a school of fish. Much like what is done in Warcraft 3. It requires much less resources than any that involves an ai. This is just my opinion though.


PS sorry about bad spelling.

[Ishmaru]

Oh I forgot to say that my mod uses units that range from 710 - 1600 polygons with most around 1000. With trees at 160 polys. I noticed a bit more lag during rain and in the first 30 seconds of game play but rest is normal.

[weedkiller]

Oh I forgot to say that my mod uses units that range from 710 - 1600 polygons with most around 1000. With trees at 160 polys. I noticed a bit more lag during rain and in the first 30 seconds of game play but rest is normal.

Hi Ishmaru, sounds like you are a skilled artist . They bring much improvements like healingorders, guarding, patrol and so on.

[daniel.santos]

While I agree that the viewing distance for the camera should be increased this is going to cause problems for slower machines. Currently the engine seems to load and unload models on-the-fly within a certain distance of the camera. Increasing the viewable distance means more memory is nessicary since more objects will be viewable at once.

I don't think that increasing the viewing distance will use any more memory, but it will use much more CPU & GPU cycles.  This will be controlled with the CameraMaxDistance parameter in the the .ini file so that slower machines will not be effected.  I have also considered (and a few others have suggested) a dynamic max view distance setting that adjusts is based upon your frame rate (or at least adjusts it to a degree).

Having mipmapping and LOD models will significantly lessen the load on the engine but from an artistic point of view the amount of work essentially doubles for each mesh, since 3 or more LOD models must be made. Adding bump maps will increase the time per model even more since a high resolution model must be created for each low-res one!

Actually, the artists will only create a single high resolution, high polygon version.  When the engine loads these animations & textures, it will create the scaled down versions on it's own.  There are many tricks for doing this well and I'm sure that I only know a few of them at this point.  My current ideas on this are to iterate through each point in the mesh and find out what angles it creates with it's neighboring points and remove the points with the smallest angles (i.e., that are making the least difference).  I will be studying more about the most effective ways to reduce polygons before actually implementing this part.  There are a lot of other complications, like making sure I don't end up with any concave polygons (OpenGL doesn't do them), etc.  I'm sure to learn an lot by the time I'm done!!

Furthermore, once these are generated once, they can actually be written to disk so that the next load wont require all of those operations (maybe in a "cache" directory).  I wouldn't want to do this if the disk I/O ends up taking longer than the calculations themselves though!

I've done a lot of AI on various things in the past, so I'm not worried about this.  The whatsits AI is exceedingly simple.

The higher viewingangle: thats too a very nice thing to improve quality and it can be regulated by the game itself, if your framerate drops too much, it just zooms slowly in and wont let you out much unless it works better.

We should never have to worry about the camera angle and/or distance effecting framerate, this is a matter of the clipping plane.

It requires much less resources than any that involves an ai.

Well, forgive me but I have to say that this is just silly nonsense.  Even the existing Glest AI for computer players (excluding path finding) takes a nearly non-existent amount of CPU time and memory, especially when compared to something like rendering.  Most of the performance problems we're having in Glest & GAE right now are path finding, which is essentially broken in that it takes far too many cycles.

As far as multi-animations, this doesn't use *any* more CPU to implement than the current single-animation per skill system.  It does use more CPU at load time (because it's more animations to load) and it uses more memory, but that's about it.  For perspective, one of your 1600 polygon models takes about 70k for the 1st frame and 38k for each additional frame, so if you're animation has 16 frames, you aren't even using 1MB of memory.

I personally agree that animated textures of some sort should be added to the game because, it can add a lot to the game with very little resources.  This can probably also be done fairly feasibly with model textures as well, although I don't think we're going to be looking at that first.

Also, I discovered that I was wrong about Glest pre-interpolating frames (as I thought it did), it does it in real time.  So let's not slap the performance panic button too quickly without understanding the true performance costs.

[ZaggyDad]

I don't see why it even needs high quality models. It's completely useless. You should just make it subsurf them if you tell it to have high quality models. In my opinion, the models look absolutely fine the way they are.

~Zaggy

[weedkiller]

It would be usefull if you want to zoom at the level of the units, so you look like standing between them.

the viewing-angle.. i expressed wrong I think farclip is right. I ment that if you zoom out then you would have more landscape/units in the viewingfield and then you have more polygons.
If you look like a unit on the battlefield it depends really on clippingframe because you would be able to see whole side of the map at any time (unless you clip it off).

[weedkiller]

I finished the splitting for 8 units each tech/magic 4.
I think the other units can only be splitted with too much effort and no good results (for example the hut of battle_mage could be seperated but that would nearly require new animating that head... so technical problem).

I made these files for each unit:
- the blend from which you can easily recreate the g3ds
- unit_body.g3d    thats the animated part that wont move
- unit_stuff.g3d    here i have the weapons animated so you con merge with body and have the original ani
- unit_stuff2.g3d    the weapons static in original position
- unit_ weapon.g3d    the weapons centered at origin

GlestSplit.zip

dont fiddle around with position and rotation for the weapons for the xml, i can do this much easier in blender than in the g3d viewer i think (just moving it right and reading the values from panel).

[daniel.santos]

w00t!!  Thanks man!  I haven't worked on the 0.3 stuff in a week or so now cause I've been busy and was also trying to get 0.2.7 finished, this is going to be cool!  

[wciow]

@ Weedkiller
Nice work,

@Daniel.Santos

I just reread the beginning of this topic and remembered the stuff about animating trees. Would it be possible to create breakable trees with the new death code? Example: when a cell with a tree is hit by a catapult the tree model is replaced with a broken tree model and then the top piece is set to automatically move away based on impact direction.

Also would it be possible to have particles on environmental objects. If so then when a dragon breaths on a tree (for example) then it can be set to eject fire particles. After a certain time the fire will become smoke particles and then the tree is replaced by a burnt tree model.