[done] Animated projectile models

[will]

Would allow you to animate the projectile used.

^{Also, speculation from looking at existing code that if your projectile shared a model which animated with something else that used the animation, then you'd have got random frames of it instead of strictly the first frame.  Doubt this bit anyone in practice though.}

Patch here: https://github.com/williame/megaglest/commit/0505d680e8ce3fc34d56fd157e413670ca9c6eb7

[wciow]

Nice work Will I can't test this because I don't know about compiling or patches but it sounds like a nice addition.

As you are looking at this area of code, how difficult would it be to add models to unit/effect particles rather than projectiles? I've noticed that the <model> tag doesn't work for anything other than projectiles. Adding models to particles opens up a HUGE amount of possibilities for modders and the ability to melt your cpu as it tries to render them  

[will]

Adding models to particles opens up a HUGE amount of possibilities for modders

Can you elaborate on how unit particle systems might use models and what the position of the models would be?  And how is this different from animation baked into the G3D of the unit?

Only attack-particle-systems (projectile and splash) support models.  I haven't worked out the best way to animate the splash model too, but I can see that that would be useful so it's quite near the top of my list.  http://williame.github.com/glest-sci-fi-pack/martians/status.html

[titi]

Your patch contains also uneeded files (especially)  glest.ini which is a bad idea   . Can you change that? At least for the next patch :-D . This one is really small and can be done manually.

About models in particles in general, I think you must use them carefully because you quickly get many models to render.

[will]

and here's a patch for splash particle models animating too: https://github.com/williame/megaglest/tree/animated_particle_models

A splash particle has a time whilst it is still emitting, and then a time while it fades.  The splash model does not fade.  Therefore, I made it so the first half of the splash model animation plays as the particle is still emitting and the second half plays thereafter for the same duration of time as the emitting phase; it could be that all particles fade before or after then - the artist will just have to make sure they are happy with the result.

Some ideas for people:

• you could now have a parachute bomb that blows up when it lands.
• or a very neat ghost affect where faint forms of the attack seems to be walking to the attack and then doing some grotesque kung-fu to the opponent

[Ishmaru]

This stuff seems really interesting! Hope it gets implemented as a part of megaglest as I could use this! Im thinking of cluster missiles (missiles breaking into smaller missles)

[softcoder]

The patch has been applied to mg trunk (very simple yet useful patch, thanks Will)

[will]

Important fixes and tidy ups:

The splash model was being drawn before the projectile had landed!  Shows nobody was really using splash models in anger before

The default behavior of a projectile model is to animate once over the entire journey of the projectile.  If the enemy is close, the animation will play quicker.

You can now add a <cycle value="..."/> child tag to the <model> tag in the projectile XML and mean distance to over which the animation will play.  It will loop as necessary.  This allows you to have projectiles that are walking or such that animate at a constant rate regardless on distance to target.

https://github.com/williame/megaglest/commit/04d95520a3a8be6fb235951e118e4af90e007451

[Ishmaru]

Dang! You beat me to the cluster bomb idea!   These are great patches! Any chance of adding an stop particle timer for unit particles? Like when a certain time (or quantity limit) is reached to stop displaying particles? This would be great for death explosions for vehicles!

[Mr War]

I think this animated projectiles thing is a MIRValous idea!

[softcoder]

I had to make a fix for this in svn, but here is how it works:

Code: [Select]

<?xml version="1.0" standalone="yes"?>
<projectile-particle-system>
    <texture value="true" luminance="true" path="images/archer_particle.bmp"/>
    <model value="true" path="models/wasprocket.g3d">
                <cycles value="0.5"/>
        </model>
<primitive value="quad"/>
<offset x="0.0" y=".2" z="0.3"/>
<color red="0.3" green="0.3" blue="0.3" alpha=".8" />
<color-no-energy red="0.0" green="0.0" blue="0.0" alpha="0.3" />
    <size value="2" />
    <size-no-energy value="3.2" />
    <speed value="10.0" />
<gravity value="0"/>
    <emission-rate value="1" />
    <energy-max value="10" />
    <energy-var value="2" />

<trajectory type="linear">
<speed value="10"/>
                <scale value="1.5"/>
</trajectory>
</projectile-particle-system>
The # of full times to animate the model are set by:

Code: [Select]

    <model value="true" path="models/wasprocket.g3d">
                <cycles value="0.5"/>
        </model>

a cycle value of 1.0 would mean 1 full animation, 0.5 means 2 full animations

The speed is set the usual way:

   

Code: [Select]

<trajectory type="linear">
<speed value="10"/>
</trajectory>
Where this is how fast it will animate and move the particle.

[Omega]

I would have preferred the cycles to be more literal. As in, having a cycle value of 2 would mean it would cycle twice, not half a cycle. Simply dividing 1 by the value of cycles could have been used to flip the value.