I mentioned in another thread that I would prefer baked data. In fact I believe it is essenitial since it means my artists can use any features they want, IK, constraints, expressions, other special plugins. To do that I need to let the 3D package compute the info and then just pull out raw matrices.
So, my preference is for matrix related animation (nodes, joints) that collada include a complete baked matrix per frame. Others might prefer trans, rot, scale info but I’m just making the request that collada include the matrix as baked by the 3d package because you never know what is truly influencing those matrices.
On top of that there are a zillion questions about exporting animation that I’m not sure are going to be easy for collada to address across systems.
Animations that need to be covered:
node animation (moving an object)
skinned animation (weights on vertices)
morph targets (including the list of targets and how they are mixed)
vertex animations: pos, color, UV.
user parameter animations
standard parameter animations (for example changing the U wrap over time)
Of the top of my head I’m feeling like the only way to wrap my head around this issue would be to actually try to write the exporters for all the various packages and as I was doing it learn what’s possible and what’s not while at the same time making sure that in all cases I could achieve my goal.
I don’t envy you guys.
My goal might be summed up by saying I want to make an exporter where from a collada file I can build a 3D cutscene turning characters into skinned characters where need be. Handling morph targets, pulling out animated camera info like FOV, animated light info like umbras, colors; animated user data that I might be using for in game effects, etc. I have this already but it’s Maya only. In my current division the #1 used package is Lightwave.
sorry if this is a kind of ramble but I thought I’d just post something to start the ball rolling on animation issues and ideas
I don’t believe the Collada exporter should make decisions such as you mention here. You should definitely be able to export baked matrices if you like. You should also be able to export any float value, or any other attribute on any other object that you need. The problem with having the Collada exporter making these decisions (the ones that determine what is exported and how) is that it [obviously] impacts the structure and content of the exported data, and this has serious consequences. We are not all going to have identical pipelines. Even within our own pipelines, we will want to export data in one manner on a certain object, an in another manner for another object.
For this reason, I believe the exporter needs to be passed the data that should be exported. It should NOT collect it, unless it is collecting the data based on a callback supplied by the calling function, or some other related method, etc.
The nature of the Collada format is such that the data is not inherently flat. Making the exporter output flattened or baked data is a dangerous precedent to set this early in its development. Much of the baking will need to be done by a post processing tool, from tri-strips and visibility sets to texture conversion. I see no reason to treat animation any differently.
I’m not sure I understand what decisions you think Collada is or might make?
I guess my assumption is the goal should be to make it possible (in as much as is possible) to take any collada file no matter which 3D tool it was made in and use that in your pipeline. While I’m sure each pipeline will use the data in the file in different ways, as long as all the data is there your pipeline can ignore anything it doesn’t need. I should not have to write some new callback and target it at 5 different collada exporters (maya, max, xsi, lightwave, etc.) I should just be able to take any collada exported file as is and pass it to my conversion tools. (assuming my artist followed my naming conventions or other types of constraints).
Of course there will be issues like if I depend on some obscure data only available in one package then when I need that data I’ll have to use that package but as long as collada exports all of it then I at least won’t have to write my own exporter and for the more likely common case my artists will be able to use any 3D tool.
First off, I didn’t suggest that collada not have non-baked animation. I only suggested that it require baked.
The reason is that every 3D package out there has different ways of computing the final results of all its animation parameters. If all collada does is give access to those parameters my program that reads the collada file will have to know about every package. It will have to know if I’m reading a max based collada file that to compute a node’s final matrix I do M = A * B * C and if it reads a Maya based collada file I do M = D * F * C. Some people might need that. For me though I just want to be able to read any collada file and use it the same regardless of where it came from. That means I need baked data.
In fact, without baked data it’s unlikely collada (or any collada reader) could get even the majority of animations correctly out of any package into a game. Unless you tell all your artists to not use any constraints or expressions then either collada would have to export all those constraints and expressions (which of course will be different per package) and your reader will have to take them into account computing those expressions and contraints OR you’ll have to tell your artists not to use those features which will make it harder for them to make art which will mean your product will take more time or have worse art.
Do we need to consider the frame rate of the baked data under some standards?
Also should we specify the interpolation technique between the keyframes to be used?
Also, can the interpolation technique be different on different animation curves? Or even between keys?
This is actually something we want to achieve for animation as well yes.
For the COMMON technique we think that animation need not be fully baked (sampled) at regular intervals. I think allowing for irregular intervals with linear and spline interpolations is common enough to all animation packages. The most common splines being Bezier and Catmul-Rom I believe.
I agree with greggman here. I think the COMMON profile should requre animation data in a format that everyone can easily understand. Namely: linearly interpolated keyframes.
It would be up to the exporter to let you set the sampling rate.
I NEED BAKED MATRICES, ONE PER FRAME AND I NEED BAKED PARAMETERS ONE PER FRAME.
Anything else means that my artists can not use every feature of their animation package. How are can expressions be turned into keyframes? How are can joint constraints be turned into keyframes? The keyframe might go from 0 to 1 to 0 but the constraint keeps it between 0.2 and 0.8
Maybe my object is animated by riding it on a space warp. Maybe my object is following a NULL/Locator so that there is are no actual keyframes on the visible object but their are on the NULL. Maybe my light’s brightness is an expression based on the angle of the camera to the horizon. Maybe my artists are actually manipulating the matrix in strange ways to achieve cartoon like effects doing more than trans/rot/scale/skew. I could come up with thousands of situations where keyframes will not handle the animation my artists make.
All I’m asking is please don’t make collada unusable by those of us that would rather let our artists do their best work.
I’d prefer separate scaling, rotation and translation inputs from which animated matrices would be built. That way if any of these components is not present in the data it doesn’t have to be present in the Collada file either: with consequent reduction in file size.
On keyframing, I’d like the user to have two options:
Output data for every frame.
Keyframed. The exporter would be responsible for determining where keyframes are required. By default only those frames that are keyframed by the artist would be output (along with an indication of how to interpolate). If there are controllers present that invalidate this approach then the exporter would add keyframes where necessary.
Animation can consist of more then just scaling, rotation and translation which is why backed matrices are a must.
Again, I’m not suggesting collada shouldn’t store trans, rot and scale separately. I’m only trying to make it 100% clear the without the ability/option to export baked matrixes one per frame there will be cases where the animation in the 3D package will not match the animation reproducable in a collada file.
I generally aim to avoid that situation with my exporters. I want the artists to have 100% control over everytihing with no limits or as few as possible. Baked matrices come close to this ideal. Anything else and I can guarentee I can give you a scene collada will not be able to reproduce.
I accept that there are cases as you describe and that this needs to be handled using matrices.
But an animation file which outputs a matrix per bone per frame is going to be massive compared to one that outputs (possibly) only a translation and rotation for each keyframe. So if the data does not require the first approach (and none of the character animations in any of the projects we are currently doing require it) we should not be burdened in this manner.
The Collada exporter therefore needs to give the user the choice of using full matrix output, or translation/rotation/scaling inputs instead.
Aggred, if you are not using animations that need that info it would be a waste of data for you.
But, I’d like to make a point here. This point is not collada related:
I could be wrong but I’d be willing to bet that the reason your current projects are not using animation that requires matrices is specifically because your system doesn’t handle them and therefore your artists have learned to live with the limitations of your system. I suspect they probably ran into issues where they made something in their favorite 3D package, exported it and found out that what they got in the game didn’t match what they made in the package. They were most likely told “don’t do it that way” and being powerless (they aren’t programmers so they can’t fix it themselves) they are being forced to do less than their best work and / or being forced to be inefficient, doing things by hand that would be done procedurally or doing without features in their 3D package that would let them get work done faster. Of course I could be wrong but you might want to ask them.
We have no teamss here where we have not run into this problem. All the teams have learned to take baked matrices and compress into T,R,S and or curve fit or whatever else after it comes out of the 3D package. That way every single feature of the package can be used and we have far less complaints from the artist of the type “hey, why does that animation in the game not match what I made?”
Keyframe animation is not the only kind of animation that COLLADA will support. Rest assured we are considering dynamics, morphing, skinning, mocap, particles and so forth.
COLLADA design has been the result of collaboration and cooperation among the interested parties. Part of my job is to keep the designs moving and progressing until most everyone is happy with the schema. For COLLADA to succeed as a schema and as a project, we have to achieve consensus so that implementers will implement it because they helped design it. Users will use it because they helped specify it’s requirements. COLLADA will be useful to those who contribute because we are listening.
One issue with wanting any other export format for animation than the vendor would provide is keeping a collada file as source material…
For example, if you collapsed all the animation data to baked matrices per frame at whatever frequency, it might work the best for some. However, it would make it near impossible to reimport the file back into your content package of choice in an editable fassion. Factoring a prebaked matrix can be non-trivial if even feasible…
Now that I think about it. This type of conundrum can occur with almost any type of data. Ease of interacting with data might not play well with the source data stipulation.
Are exporters allowed to provide a separate export only format for things like this? Or are people expected to understand that they could lose information if they export and reimport using a custom format. The only way I can think of to solve this is to add the more helpful format as redundant data only for the user.