Have you considered building in basic key-frame animation support. I realize that this can be a complex problem when you try to optimize it for size, but it would be nice if a basic system was in place to store this information instead of having to create a file per frame.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One issue with using multiple independent OpenCTM files for animation is that OpenCTM does per-file triangle & vertex reordering, which makes it virtually impossible to do inter-frame interpolation. Hence, an extension to the OpenCTM file format would be required in order to support key frame animations.
On the other hand, it would complicate the format quite a bit, and also I have not really seen a proper use for it (other than replacing MD2 files for instance - but would that give you much of an advantage?).
In order to not just do good compression, but really great compression (utilize temporal coherence), you probably would have to decompress all the key frames sequentially into memory at once - I don't know if that would be a limitation or not…
Personally, I think that bones animations feel more valid, and easier to support with OpenCTM - but then again, I'm not an artist, and I don't have much experience with 3D animation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It depends on what you are doing. I'm not doing character based animation, and bones based animations don't make sense for this work. There are free form deformers that work, and we often construct them that using those, but they are less efficient than key frame based for some of our tasks at runtime.
We would definitely be decompressing each frame entirely in memory, but that isn't really a problem for us (we do that now). However, if we can't be certain that when you export two frames, that the indexes of the two files won't match, that would make using this format impossible for these tasks. So, while I can write free-form deformers and even bone systems against the format as it stands today (as external definitions), it sounds like key-frame animation isn't possible without adding it to the format. Is that right?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
IF we add key frame animation support to OpenCTM, I guess that it would only present the indices (triangle connectivity) in the first frame, and then all vertex data (coordinates, normals, UV, attributes, etc) would be stored for each frame (preserving the vertex order from the first frame).
Since OpenCTM focuses on compression, I would like to do inter-frame compression (like MPEG), meaning that you would have to decompress the frames sequentially (or all at once) from the file into RAM, meaning that you can not have random frame accesses from the file.
I guess that for most applications, you would have to have access to all frames all the time for doing skinning etc, so that would probably not be a problem, right?
Do you have a showcase of a key frame animation and its application (what format do you use now?), so that I can get a better understanding of what you want to do?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would hope you could get a significant amount of compression across frames. Especially for animations where certain frames contain significant duplication. Our engine currently maintains all frames in RAM for any animation we are using.
We are currently using several x files for each key frame. This is less than desirable for many reasons. I don't have an example for you at the moment, but I could get you one if you ned it. There should be some online already, but if you need something, I could have one of our artists create something simple.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
…regarding the example cases, I was mostly trying to get a feel for what the mesh looks like (polycount, number of frames, the nature of geometrical deformations, etc). All I have seen myself, so far, are some fairly simple/old MD2 models.
It would help when making decisions for the API, and also, of course, it would be good to have some example to work with when it comes to actual algorithm design and implementation (for static meshes I relied heavily on the Stanford bunny and similar models).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Have you considered building in basic key-frame animation support. I realize that this can be a complex problem when you try to optimize it for size, but it would be nice if a basic system was in place to store this information instead of having to create a file per frame.
Yes, I have thought about it.
One issue with using multiple independent OpenCTM files for animation is that OpenCTM does per-file triangle & vertex reordering, which makes it virtually impossible to do inter-frame interpolation. Hence, an extension to the OpenCTM file format would be required in order to support key frame animations.
On the other hand, it would complicate the format quite a bit, and also I have not really seen a proper use for it (other than replacing MD2 files for instance - but would that give you much of an advantage?).
In order to not just do good compression, but really great compression (utilize temporal coherence), you probably would have to decompress all the key frames sequentially into memory at once - I don't know if that would be a limitation or not…
Personally, I think that bones animations feel more valid, and easier to support with OpenCTM - but then again, I'm not an artist, and I don't have much experience with 3D animation.
It depends on what you are doing. I'm not doing character based animation, and bones based animations don't make sense for this work. There are free form deformers that work, and we often construct them that using those, but they are less efficient than key frame based for some of our tasks at runtime.
We would definitely be decompressing each frame entirely in memory, but that isn't really a problem for us (we do that now). However, if we can't be certain that when you export two frames, that the indexes of the two files won't match, that would make using this format impossible for these tasks. So, while I can write free-form deformers and even bone systems against the format as it stands today (as external definitions), it sounds like key-frame animation isn't possible without adding it to the format. Is that right?
IF we add key frame animation support to OpenCTM, I guess that it would only present the indices (triangle connectivity) in the first frame, and then all vertex data (coordinates, normals, UV, attributes, etc) would be stored for each frame (preserving the vertex order from the first frame).
Since OpenCTM focuses on compression, I would like to do inter-frame compression (like MPEG), meaning that you would have to decompress the frames sequentially (or all at once) from the file into RAM, meaning that you can not have random frame accesses from the file.
I guess that for most applications, you would have to have access to all frames all the time for doing skinning etc, so that would probably not be a problem, right?
Do you have a showcase of a key frame animation and its application (what format do you use now?), so that I can get a better understanding of what you want to do?
I would hope you could get a significant amount of compression across frames. Especially for animations where certain frames contain significant duplication. Our engine currently maintains all frames in RAM for any animation we are using.
We are currently using several x files for each key frame. This is less than desirable for many reasons. I don't have an example for you at the moment, but I could get you one if you ned it. There should be some online already, but if you need something, I could have one of our artists create something simple.
Since key frame animation is a major change to both the file format and the API, I included it in the <a href="http://docs.google.com/Doc?docid=0AWt0yiQ57DHFZGQ5NDUzdzJfMWRkN2o4NWM1&hl=en">OpenCTM 2.x roadmap</a>.
…meaning that I will not start to work on it right away. Hope you don't mind - this is a spare time project for me, after all.
…regarding the example cases, I was mostly trying to get a feel for what the mesh looks like (polycount, number of frames, the nature of geometrical deformations, etc). All I have seen myself, so far, are some fairly simple/old MD2 models.
It would help when making decisions for the API, and also, of course, it would be good to have some example to work with when it comes to actual algorithm design and implementation (for static meshes I relied heavily on the Stanford bunny and similar models).
I'm not sure that my animated models are similar enough to the common case, but we can certainly send you something.
Right now, something is much better than nothing…