Warzone 2100 Forums

Jorzi wrote:The reason for the scale being off is that I like working in 1/10 scale in blender, then upscaling by 10 in WMIT before exporting
When it comes to scaling I think the perfect workflow is not yet achieved, but good to know you got it to work.
The bug with the number of objects could be fixed by doing another for loop over all the objects and counting only meshes, or alternatively removing all non-mesh objects from the list before writing to the file.

I was using the blender PIE import/export plugin, so it was natural for me to use that scale.
if you upscale by 10 you loose presision in the last digit. It is small i admint, but still usable.
I think , it is easy enough to explain and understand that you should remove other objects prior to exporting.
The script is doing its job and that is important.
Astorian

Actually, with floats you should be able to scale to any power of 10 and back without any loss, since it just changes the exponent.
How does pie export work for blender nowadays? Does it use the PIE2 or PIE3 specification?
I agree that the script currently does its job, but I'd like it to be as user friendly as possible. Maybe I'll still update it a bit today.
As much as I like WMIT, it would probably be interesting to integrate this with the blender scripts...

I updated the script so it now properly filters the object list from non-mesh objects before writing and made a new topic in the Mapping/Modding tools section.
I also added a scale setting in the export dialog.

Awesome happy ending of one thread.
great work Jorzi

@MaNGusT:

Looks like it is a bit worse than I remembered. For droids, only super-cyborgs can do animations at the moment. For structures, it should be possible to animate all of them.

I am cleaning up the animation code a bit now, let's see how far I get...

Per wrote:I am cleaning up the animation code a bit now, let's see how far I get...

Could you fix a level limit for model? Imho, it's a 1st thing that should be fixed, in theory it's possible to have more than one mesh per model, but in real only 1st mesh is visible in game.

Per wrote: Looks like it is a bit worse than I remembered. For droids, only super-cyborgs can do animations at the moment. For structures, it should be possible to animate all of them.

I am cleaning up the animation code a bit now, let's see how far I get...

Hi Per Great to see that someone is investigating the source. Enabling the animation for buildings and other object would be great. I was imagining quad legged propulsion back in the days
And as MaNGusT is pointing out - animating the structures would be great.

best regards,
Astorian

I think I understand the animation code now, and I would like to move all of the logic into PIE files.

Adding the following directives after TEXTURE:
In ANIM3DTRANS <number> <cycles>, the <number> gives the total animation time, so frame time is that divided by the number of animation frames for the level. (The idea is that each level may have a different number of animation frames. Which is not possible currently.) The <cycles> says how many times to cycle the animation before it is stopped, or zero for infinity (a non-zero number does not make sense for normal models, at least not for now).

The EVENT <type> directive tells the code that this model supports the given event <type>, and so when that kind of event happens to a game object with this model, switch to the given model for the duration of that model's animation time times its number of cycles.

Then in each level, after POLYGONS, new optional segment:
This is basically a copy and paste of the animation setup in a .ani file.

This should remove much of the hard-coded mess and all of the anim data directory files.

Looks feasible to implement, but could hit interesting challenges on the way.

Not sure how easy it would be to make our tools support this structure, though. Opinions / ideas?

as for WMIT, there could be added an ani importer(just a loader of data) and new options to pie exporter. I mean, we could use wmit as a combiner, to combine old pie and ani files by Jorzie's script for blender into a new pie with your animation params. I'll probably ask I-NoD for help.

Per wrote:In ANIM3DTRANS <number> <cycles>, the <number> gives the total animation time, so frame time is that divided by the number of animation frames for the level. (The idea is that each level may have a different number of animation frames. Which is not possible currently.)

I am sorry, but i don't understand what you mean. Can you please rephrase that?

Per wrote:The <cycles> says how many times to cycle the animation before it is stopped, or zero for infinity (a non-zero number does not make sense for normal models, at least not for now).

If i understand correctly, a non-zero value could be used for blderik_explosion.pie for example, to run it only once so you don't see the explosion animation all over again?

Per wrote:Then in each level, after POLYGONS, new optional segment:

Code: Select all

ANIMOBJECT 25
                  0           0       0       0       0       0       0     999    1000    1000
                  1           0       0     544       0       0       0     999    1000    1000
            ...........

This is basically a copy and paste of the animation setup in a .ani file.

This should remove much of the hard-coded mess and all of the anim data directory files.

Looks feasible to implement, but could hit interesting challenges on the way.

Personally i don't like the idea of Inserting the animation data into the PIE file. I like the separated animation files, also the separate directory. It will be easier to worki with the animation without possible mess up of the PIE. On the other hand to be able to import the mesh and the animation in one go is also tempting.
BR,
Astorian

astorian wrote:Personally i don't like the idea of Inserting the animation data into the PIE file. I like the separated animation files, also the separate directory. It will be easier to worki with the animation without possible mess up of the PIE.

+1.
we don't have any plugins to export pies but now we have the script for blender to export animations.

astorian wrote:

Per wrote:In ANIM3DTRANS <number> <cycles>, the <number> gives the total animation time, so frame time is that divided by the number of animation frames for the level. (The idea is that each level may have a different number of animation frames. Which is not possible currently.)

I am sorry, but i don't understand what you mean. Can you please rephrase that?

<number> is the total time the animation sequence takes. Currently you need to specify a frame time which must be the same for each level, and each level must have the same number of frames. I don't see any good reason for this restriction.

astorian wrote:

Per wrote:The <cycles> says how many times to cycle the animation before it is stopped, or zero for infinity (a non-zero number does not make sense for normal models, at least not for now).

If i understand correctly, a non-zero value could be used for blderik_explosion.pie for example, to run it only once so you don't see the explosion animation all over again?

Correct.

astorian wrote:Personally i don't like the idea of Inserting the animation data into the PIE file. I like the separated animation files, also the separate directory. It will be easier to worki with the animation without possible mess up of the PIE.

I understand that concern. I will experiment a bit, and see where it goes.

Per wrote:<number> is the total time the animation sequence takes. Currently you need to specify a frame time which must be the same for each level, and each level must have the same number of frames. I don't see any good reason for this restriction.

Well, i made only few animations, so i am not expert, but i think:
- Frame-rate is a constant, that i can rely on when working with multiple meshes or multiple objects. Since frame-rate is the same for all objects/meshes, time is flowing the same for all of them allowing time events correct. I have no idea how to implement or work with different time for each level object in the PIE.
Even i can imagine, that you can use a two level structure for example where one object stay still and only animate the second object. For example rotating radar on top of a still structure.
However i am not able to imagine how to bind the current animation type with a no-time-sync. Make separate animation type? Or make a new type to mix the two?
Personally, i am for keeping the frame-rate based animation, but i am open for any improvement

I was thinking about storing the animation data in the PIE and i have to say i like it more and more. To be able to load the mesh and object animation together from one file (in Blender for example) and storing it accordingly would be great.

my best regards,
Astorian

I was thinking about storing the animation data in the PIE and i have to say i like it more and more

If I were me, I would keep the .ani data and .pie in separate files.

It is another I/O operation to get/save the anim data, but you are only doing it once when an application or script starts.

Separate ANI and PIE means:
* the parsers and other programs are simpler.
no need to complicate one with the other. reading animation data is just a matter of calling another script.
* there are existing programs to play with ANI data
embedding the data in a PIE file hides it or requires another step to get at.
* there are opportunities to share and cache ANI data
modern CPUs love caching.

tl;dr; it is simpler

I like the Idea of being able to reuse animations, although I admit that the degree of reusing will probably be fairly low. It does, however, allow less advanced artists to do reskinning or remodeling of assets without changing the animation.