Mesh Animation

[klauss]

You want too much with minor effect.
Bone animation is useful only inside the animation program like blender(I think blender has not bone animation though)
no one wants to handle matrices for animation, that would be too much work for simple things.

You couldn't be any more wrong. FPS games animate their characters with skeletal animation (skinning), which is exactly that. Blender, 3DS-Max, Maya, all have extensive support for it, and modellers are well acquainted with the technique.

Also,you can hardly define wether you want to animate a steel arm for example or an human arm, where the vertices of the both submeshes are glued together.

That would be done with weighted skinning, read the papers about the technique, or this short explanation. It's rather easy and common. A simple vertex shader would do the trick, given the right vertex attributes, but ship animation needs none of that. Note, the limitations given in the link are not present today, that's a very old page.

And also check out the videos showing off the technique. You can't argue, it's a superior technique, and a common one at that.

Also shall only a part of the leg move or the whole leg? And what if you want a complicated move?

Leave that to animators, they know their stuff. That's why I said: support standard skeleton formats, that way you don't have to write any kind of animation software, blender or any other will do, you just parse the exported animations.

Bone animation has it's opportunities in editing.
The way one implements is animate it(maybe with bones for a better animation effect) visually and export the every single frame.

No no no... where do you get that? The game industry has been using skeletal animation for ages. Almost every FPS you've played uses it, and they haven't exported every frame as a separate mesh. Just ask any modder.

A switch between a frame to another is done in my animation system simply by switching the pointer to another mesh so it is the fastest way possible.

Yep, well... the thing is... VS already had that. A bit limited (you can't have submeshes if you have animation), but it had it.

The only thing could be the amount of mesh data.

Not a small issue. In fact, a huge issue.

But in today's harddisks wouldn't this be a problem.

What about today's CPU power? What about today's bandwidth?
It's just an inefficient way of doing animation.

Also, the support for new animations wasn't imlemented in unitconverter. There was no submesh support.

That's UnitConverter's limitation, not the engine's.

I found a way to load in easily submeshes and animate them.
All is packed up in a single class.
The wormhole effect is hard to understand and I didn't know wether it worked after inspecting the code...but there is no reason why we shouldn't use the submesh feature... In animating arms,legs, doors and other extensions of units.

Regardless of how elegant your new implementation might be, it's not a new feature. Worse, it's a redundant feature. That's a maintainance nightmare.

If you want a new feature, an useful new feature, get skeletal animation going. All you have to do is be able to load a skeleton, assign bones to submeshes, and pass in the right transformation matrices when rendering.

Computational cost remains minimal, and the animation potential is immense. Far better than non-interpolating morph animation (that's what you're doing and that's what the wormhole effect uses).

In fact, since noone uses morph animation in VS, and since it's so limited, I'd get rid of it if we had skeletal animation.

[travists]

Animation is one of my hobbies, so here are my thoughts on the discussion so far.

Mesh transformations:
If the engine can interpolate between two meshes so you can use true morph targets, then it would be great for small shifts and organic/liquid metal changes. An example of something like this is in an old movie, "Flight of the Navigator". The ship changes from a saucer shape to more of a teardrop for high speed. If one mesh per frame is required, it would seem to add more overhead than effect. Other uses for a morph target might be a docking boom that just extends or iris type docking ports. The underling mesh swapping could be used to stunning effects on cap ships, if after sustaining certain levels of damage small explosions occur and there are gapping holes in the hull afterward.

Bone based animation is great for gross movements, like arms. A Gundum type mech (fighter to robot conversion and moving limbs) cannot be effectively done without it. Any mesh that is similar enough in shape and purpose to use the same bones could use the same animations, cutting down on content development time. Also, mech based ships could have new animations quickly added without needing anything more than the new animation file.

To have people walking around inside, animated textures should suffice, unless it is a large observation deck, visible for a long time and/or from a wide range of angles.

The bottom line is all methods have their place in animation the question is what gives you the best bang for the overhead. Always remember the old adage: KISS.

[Gungnir]

I agree with Klauss and Travists.

Nearly every animation, game, and render engine uses bone/armature-based animation because it's incredibly easy to set up and use, and it's capable of almost everything an animator would ever need to do. Mesh transformations are a useful feature, but we need support for skeletal.

Also, if we ever add the ability to walk around in stations and ports, or if we simply add a convenient way to animate the existing base interface (like people walking around) we'll need skeletal animation.

[greenfreedom10]

The only thing could be the amount of mesh data.
But in today's harddisks wouldn't this be a problem.

VegaStrike would be available in Debian's official package repositories (where I first found VegaStrike) if not for size of the data package.
http://lists.debian.org/debian-devel-ga ... 00022.html
http://lists.debian.org/debian-devel-ga ... 00013.html

[pheonixstorm]

Well, if we can wait till september of next year we can use the rendering engine from Doom3 (id tech 4 engine) as it is suppose to go open source as soon as Rage is released.

[charlieg]

/me hopes phoenixstorm is being a bit sarcastic.

If strook can prove his addition is useful, and is willing to maintain it, then I can't see why there is universal opposition to his contribution. *shrugs*

[strook]

I have set up another branch .../vegastrike/branches/strook/
where I will maintain my additions.
@klauss: I have played mechcommander2 and quake2. And they worked well without skeletial animation. I don't want to reinvent the wheel anew. As I said before, we're just hobbyists and the community wasn't able to implement the seamless flight. Stop dreaming about something what the profis do, reuse work done by others and make realistic small steps of work.
So my animation system isn't really new, but it works and animations can easily be added.
Don't tell me "the code isn't clean etc,etc..." I think because of this reason no one is developing at vs cause it is very dirty.
Ok, ok if the day had 48 hours I would rethink of that...

[charlieg]

Although at the same time you don't want to make VS even messier; clean up is possibly more valuable than hacked additions... don't be too cavalier strook. Try and be constructive and clean with your contributions. They don't have to be perfect, but at the same time you must work with everybody else.

[strook]

I don't "hack" my additions!
You do the same error the freeorion guys did:
flaming, expecting too much, ordering what I have to do.
And the code doesn't grow...
Do I get paid for this?
No!
This addition is important to animating the ground units.
...
Ok I after rethinking about that there could be a way to use lumina and write a shader that uses bone animation.
But before I do this I need the agreement from you that the planetflight and the bone shader will be added. Or I'll change the project.

[travists]

I don't think planet-fall is the point of this discussion. That said, as it appears to be a sticking point, has anyone contacted the people at x-plane? A space shuttle landing is part of x-plane 9, at one point there was a spacecraft simulator by the same guy. I don't know if they would be willing, but that may be a resource to get that aspect going.

[Gungnir]

I don't "hack" my additions!
You do the same error the freeorion guys did:
flaming, expecting too much, ordering what I have to do.
And the code doesn't grow...
Do I get paid for this?
No!
...

...I don't think anyone was flaming, we were just saying that skeletal animation is, in our opinions, a better system, and a better use of time and talents.

[strook]

Ok then I calm down

[Deus Siddis]

I don't "hack" my additions!
You do the same error the freeorion guys did:
flaming, expecting too much, ordering what I have to do.
And the code doesn't grow...
Do I get paid for this?
No!
This addition is important to animating the ground units.

I think you and charlieg might be misunderstanding what each other was saying. Charlieg thought you were saying that the cleanliness of code additions weren't a priority. I don't think he was criticizing the actual code you have created.

I also don't think anyone means to insult you or try to order you to do anything. People here are generally passionate about what they feel is the best way to do things, but that doesn't mean they are ordering you to do something-- they are usually only trying to convince you.

With FreeOrion it seemed like the opposite situation; they have a strict design for their game and they simply don't allow much deviation from it. They also don't like to realistically simulate much of anything. VS on the other hand largely is a simulator.

Ok I after rethinking about that there could be a way to use lumina and write a shader that uses bone animation.
But before I do this I need the agreement from you that the planetflight and the bone shader will be added. Or I'll change the project.

I recall Klauss already implicitly approved your planetflight project, and a few posts ago suggested implementing bone animation; so you should have a green light on both methinks.

Also I'd like to make a personal plea that you don't stop working on this project. Because I'm really very excited about playing and working with your features in Vega Strike. Animations, ground units, planetary environments, lifeforms, etc. all very desirable stuff for content creators and players alike, and I'm both of those things.

[charlieg]

Ok then I calm down

+1

Also I'd like to make a personal plea that you don't stop working on this project. Because I'm really very excited about playing and working with your features in Vega Strike. Animations, ground units, planetary environments, lifeforms, etc. all very desirable stuff for content creators and players alike, and I'm both of those things.

+1

[strook]

Well I joked a bit in the hot battle, I won't leave so fast *slaps himself*

we could use the quake2 .md2 format besides the skeletial format, I suggest one of those blender can export, milkshape for example.
I could use the blender python import script for vs. And the rest will be up to me. I mean bringing up the matrices into the animation.

But this will be after planetflight and after adding fps engine movement.

[pheonixstorm]

/me hopes phoenixstorm is being a bit sarcastic.

If strook can prove his addition is useful, and is willing to maintain it, then I can't see why there is universal opposition to his contribution. *shrugs*

A little. I would rather strook get seamless planetary flight in and use have to pick out the render system of Q3 or Doom3 than rewrite it and not get the most work out of seamless planetary flight.

On the flip side I can see why VS doesn't use a lot of outside code. While VS may be GPL, outside libraries can sometimes be kinda funny about someone else using their work and charging for the end program. Not to mention that as a programmer reinventing the wheel is sometimes neccesary as a learning experience.

As for freeorion... They may be strict but they seem to get more work done than we do... Anyone wanna fork freeorion and create moo4? hehehe

[Deus Siddis]

A little. I would rather strook get seamless planetary flight in and use have to pick out the render system of Q3 or Doom3 than rewrite it and not get the most work out of seamless planetary flight.

On the flip side I can see why VS doesn't use a lot of outside code. While VS may be GPL, outside libraries can sometimes be kinda funny about someone else using their work and charging for the end program. Not to mention that as a programmer reinventing the wheel is sometimes neccesary as a learning experience.

But what does id tech 4 have that OGRE, Irrlicht and Crystalspace don't? Plus what if Zenimax ultimately says no to liberating it's code?

Anyway I totally agree that seamless planetary flight should be strook's first priority. That's the really big and long desired feature.

As for freeorion... They may be strict but they seem to get more work done than we do... Anyone wanna fork freeorion and create moo4? hehehe

Well their being strict about coding standards from the beginning is certainly a good thing and made them more efficient than VS (which now needs a major refactoring). But being strict about what features are allowed, even when people come in who are willing and able to take on the work of implementing these themselves. . .

. . .but I digress.

[pheonixstorm]

even id tech 3 which IS open source would be a huge leap foreward for VS development. Plus, we could always use it as a jumping point for our own code. Take the basics and rewrite it for VS.

As for Zenimax saying no... well, when the god of FPS games says we go open source (and every game ID has created went open source) then you don't want to upset your best dev team. Unlass Carmack and gang are under contract for a set number of years you dont want to alienate them by going against tradition or a promise made BEFORE you bought the company. I could see zenimax saying no AFTER id tech 4 but a promise made should be honored even if you don't like it.

[charlieg]

Open source is meritocracy. There has to be 1) a compelling reason and 2) somebody doing the work. "It'd be cool to use ID Tech 5!" That isn't either #1 or #2. I know I'm simplifying and stupifying your position, but you are thinking aloud rather than making a technical case for it.

[Deus Siddis]

Open source is meritocracy. There has to be 1) a compelling reason and 2) somebody doing the work. "It'd be cool to use ID Tech 5!" That isn't either #1 or #2. I know I'm simplifying and stupifying your position, but you are thinking aloud rather than making a technical case for it.

Please note however #1 is not so much a question of whether to do this at all (at some point) has merit, but which engine to use. The original choice was OGRE, though this project never completed. But just the same, id Tech 4 would have to have a compelling overall advantage versus OGRE, as well as Irrlicht and Crystalspace and any others (open scene graph? delta3D?).

There'd be many questions to ask, like how well does idT4 handle rendering large outdoor environments? Will MegaTexture be released GPL along with it? Will this engine be released in the first place? (Zenimax is still a variable here).

[klauss]

I have set up another branch .../vegastrike/branches/strook/
where I will maintain my additions.
@klauss: I have played mechcommander2 and quake2. And they worked well without skeletial animation. I don't want to reinvent the wheel anew.

You're reinventing the wheel by implementing animations the way you do, since it's a kind of animation VS already supports.

If you believe your code is better, the sensible next step would be to remove the old animation code so that only your method remains. Having two implementations for the same feature in the same engine is, almost by definition, messy.

I didn't review your implementation yet, so I can't tell if it's better or worse. I did read your description of it, and from your description, it's not a new feature. In fact, I'm convinced you implemented it convinced VS didn't have any kind of animation - but so happens, VS has exactly what you added, only accessible in a different way you didn't discover.

Either use the animation support already there (it isn't different from yours), or remove the old method (that is only used for the wormhole effect after all) and leave only yours.

What I'm opposed to is not your contribution, I'm opposed to leaving both methods in place.

[strook]

@klauss: I could do this, but we will come to the same discussion when using the planetflight and the quake(?) engine or other opensource add ons. My opinion is to this that we have a large ammount of engine functions, but we mustn't use them to get things working. Ok , there might be parts of code that are in there more than one time, but the advancement is the locality of the code(if someone steps in he doesn't need to know the code in a whole) and that the code is already tested and works.
If you save the code all into a subfolder like I did with the planetflight, gluing and removing the parts that are odd, you have a compact segment of code that can again be reused.
I don't focus on messy code and in fact didn't knew about the other animation code, but I think we have to spot the time - usability factor. We can always make a first version of code, argue about what should be better and improve it when the time comes. You know, I don't do this for money so you shouldn't say me what I have to do, but if the time comes and I'll go to beta testing of my code, then I'll look wether there can be something optimized-I mean removed or replaced by vs functions.

[pheonixstorm]

If you believe your code is better, the sensible next step would be to remove the old animation code so that only your method remains. Having two implementations for the same feature in the same engine is, almost by definition, messy.

I didn't review your implementation yet, so I can't tell if it's better or worse. I did read your description of it, and from your description, it's not a new feature. In fact, I'm convinced you implemented it convinced VS didn't have any kind of animation - but so happens, VS has exactly what you added, only accessible in a different way you didn't discover.

Either use the animation support already there (it isn't different from yours), or remove the old method (that is only used for the wormhole effect after all) and leave only yours.

What I'm opposed to is not your contribution, I'm opposed to leaving both methods in place.

klauss, if you are familiar with the old vs animation code can you review both and see which works better so we can remove the other? The new code from what I saw LOOKS clean but you have had a lot spent a lot more time dealing with all the under the hood stuff for VS.

@strook
If you have time and know where to look check out the older code and see if there is anything that the old code does that your code doesn't so we don't have to change anything for the wormhole animations. Making any *new* changes to the animation code (old or new) is a low priority for the moment though when compared to seamless planetary flight or adding in any type or skeletal animation (or w/e animation ).

[strook]

My actual mesh animation system is only a step in between. There is a quake2 format importer missing for the morph animations as well as the bone system. Although it is easier to use and it is non-monolithic, rather modular implemented.
A clean up could happen through merging the both implementations together.
The old one has no load in mechanism and is difficult to use, but is well implemented in vs.
The new one brings new possibilities with it.

[klauss]

The old one has no load in mechanism and is difficult to use, but is well implemented in vs.
The new one brings new possibilities with it.

What difficulty is there?

Suppose you have each frame as frame<n>.xmesh, then, root.xmesh must have an empty mesh, with the animation definition like so:

Code: Select all

<Frame FrameMeshName="frame0.xmesh"/>
<Frame FrameMeshName="frame1.xmesh"/>
...
<Frame FrameMeshName="frame<n>.xmesh"/>
<AnimationDefinition AnimationName="" FPS="15.0">
    <AnimationFrameIndex AnimationMeshIndex="0"/>
    <AnimationFrameIndex AnimationMeshIndex="0"/>
    <AnimationFrameIndex AnimationMeshIndex="1"/>
    <AnimationFrameIndex AnimationMeshIndex="2"/>
    <AnimationFrameIndex AnimationMeshIndex="3"/>
    <AnimationFrameIndex AnimationMeshIndex="4"/>
    ...
</AnimationDefinition>

And then build the composite animated bfxm like so:

Code: Select all

mesh_tool root.xmesh bla.bfxm xbc

In essence, you can sequence n meshes any way you like. What other possibilities does your method introduce? (I'll try to read your branch and find out, but feel free to save me the effort and explain )