| 1 |
[quote]@Anarchid: What is the solution then (for ZK and Spring more generally)?[/quote]
|
1 |
[quote]@Anarchid: What is the solution then (for ZK and Spring more generally)?[/quote]
|
| 2 |
The approach i chose originally was based on some deliberation. I think it would go under "other: all of the above" here. It went like this:
|
2 |
The approach i chose originally was based on some deliberation. I think it would go under "other: all of the above" here. It went like this:
|
| 3 |
\n
|
3 |
\n
|
| 4 |
1)
Devise
a
way
to
describe
animations
as
data
rather
than
code.
This
is
necessary
for
any
i/o
and
to
separate
animation
from
code.
|
4 |
[quote]1)
Devise
a
way
to
describe
animations
as
data
rather
than
code.
This
is
necessary
for
any
i/o
and
to
separate
animation
from
code.
|
| 5 |
\n
|
5 |
\n
|
| 6 |
2) Provide a way to play this animation data from within spring animation script, allowing it to be arbitrarily flexible (e.g. some pieces always controlled by keyframes, others always by logic; or any mixture). This is necessary because logic is important in Spring games due to the synced nature of animations.
|
6 |
2) Provide a way to play this animation data from within spring animation script, allowing it to be arbitrarily flexible (e.g. some pieces always controlled by keyframes, others always by logic; or any mixture). This is necessary because logic is important in Spring games due to the synced nature of animations.
|
| 7 |
\n
|
7 |
\n
|
| 8 |
3) Now that you have a standardized animation format and a playback API, you can write import-export tools of any sort, including $EDITOR addons, ingame editors, or engine parsers for $ANIMATION_FORMAT.
|
8 |
3) Now that you have a standardized animation format and a playback API, you can write import-export tools of any sort, including $EDITOR addons, ingame editors, or engine parsers for $ANIMATION_FORMAT.
|
| 9 |
\n
|
9 |
\n
|
| 10 |
4) Iterate to improve this format to include lacking features such as bezier interpolation between keyframes (needs engine support in Turn etc).
|
10 |
4) Iterate to improve this format to include lacking features such as bezier interpolation between keyframes (needs engine support in Turn etc).
|
| 11 |
\n
|
11 |
\n
|
| 12 |
---
|
12 |
[/quote]
|
| 13 |
\n
|
13 |
\n
|
| 14 |
It worked for a while - and i guess it can still be made to work, especially seeing how most of this plan is actually done.
|
14 |
It worked for a while - and i guess it can still be made to work, especially seeing how most of this plan is actually done.
|
| 15 |
\n
|
15 |
\n
|
| 16 |
[spoiler]
|
16 |
[spoiler]
|
| 17 |
The issues outlined in the previous despair post are tedious but not complicated. Supporting ZK slow is just a question of hacking the PlayAnimation function in blender2lus output to support a time scale. Fixing the euler order limitation - and thus supporting [tooltip=even if this format is an ugly piece of NIH and its adherents idiots]s3o[/tooltip] - just needs some math. Explosion-causing bitrot is probably just an issue of Blender's crappy Collada exporter, and can be workarounded by using Godot's Collada exporter addon for Blender. Mesh deforms and non-linear keyframe interpolation can be easily bolted on top of engine Turn/Move functions and treating bones as pieces. Engine handling of Collada could be improved, and so on.
|
17 |
The issues outlined in the previous despair post are tedious but not complicated. Supporting ZK slow is just a question of hacking the PlayAnimation function in blender2lus output to support a time scale. Fixing the euler order limitation - and thus supporting [tooltip=even if this format is an ugly piece of NIH and its adherents idiots]s3o[/tooltip] - just needs some math. Explosion-causing bitrot is probably just an issue of Blender's crappy Collada exporter, and can be workarounded by using Godot's Collada exporter addon for Blender. Mesh deforms and non-linear keyframe interpolation can be easily bolted on top of engine Turn/Move functions and treating bones as pieces. Engine handling of Collada could be improved, and so on.
|
| 18 |
[/spoiler]
|
18 |
[/spoiler]
|
| 19 |
\n
|
19 |
\n
|
| 20 |
But it seems to me now that this is an extremely fragile approach that is prone, besides bitrot in a thousand places due to its reliance on engine bugs-as-features, to actual fragmentation with how each game trying to use this framework has to actively include it. I look at our gadget handlers as an example, and i despair. So my current thinking is that an engine parser and an API for Collada animations would be best. Just do what 0ad do.
|
20 |
But it seems to me now that this is an extremely fragile approach that is prone, besides bitrot in a thousand places due to its reliance on engine bugs-as-features, to actual fragmentation with how each game trying to use this framework has to actively include it. I look at our gadget handlers as an example, and i despair. So my current thinking is that an engine parser and an API for Collada animations would be best. Just do what 0ad do.
|
| 21 |
\n
|
21 |
\n
|
| 22 |
Either way, i doubt i'll find myself working on this anytime this year.
|
22 |
Either way, i doubt i'll find myself working on this anytime this year.
|
Walkers