animation ideas

A good point.

In general, Collada needs to tread very carefully the line between being an export format and being an interchange format. The two are not the same.

I’ll be honest. I think it’s a huge mistake for collada to try to be an interchange format. I guess by interchange I assumed from 3D tool to game (or game tool) but not back into a 3d package. There is no possible way for collada to maintain 100% importability. For one even in the same package, between versions data gets added. Take a Maya 6.0 file, export as maya Ascii. Edit the version to 5.0 (this will allow you to load it in Maya 5.0). Load in Maya 5.0, save as maya ascii, compare the 2 files, see all the data that has been added.

On top of which, how are you going to “interchange” things like a Max Geosphere into Maya. Maya has no such thing. Max has no concept of clusters as far as I know, at least not in the sense that Maya does.

In other words, getting a perfect interchange format is impossible and I don’t believe collada should even waste time attempting it. If you need to interchange stuff go buy Deep Exploration or PolyTrans. Let’s solve problems that are actually solveable because a in the case of an interchange format, a non perfect solution is no solution at all. If my artists could no longer edit their stuff as they set it up (with all the constraints, expressions, construction history etc) then they will never use collada for importing anyway.

Please don’t consider collada as source material, it’s a mistake.

Why not doing this in the exporter ?
Maybe this way you would not have to do anything after it comes in COLLADA ?[/quote]

I don’t understand this comment. :frowning:

I don’t think it’s a mistake. There are other file formats out there that can be exported to from all toolsets. I think that it could make agreeing on new parts of the spec. a non-trivial and possibly drawn out process. Although from the look of the design, it needs to have some sort of interoperability to maintain a large part of the benefit.

I don’t think that it should be an overarching format that allows exporting every piece of information from one package to be sharable with another. As long as all the vendors are talking and can agree on a common format, it should give the best of both worlds.

That being said, I DO think exporters should allow for data to be exported in a non-source format, to allow for things like baked matrices and other stuff that is non-trivial to derive from other formats of information.

Yes, there is. It’s called multi-representation. This is what the Collada techniques and profiles are for.
You can think of the COMMON profile as the “interchange format”, because it should be understood by everyone.
If you absolutely can not express something modeler-specific in the COMMON profile, you can use the Maya5, Maya6 XSI4 etc. profiles.

Also, I agree with “adruab”. Maybe we could even have a “BAKED” profile for those things.

In general, Collada needs to tread very carefully the line between being an export format and being an interchange format. The two are not the same.

They could be. Let’s assume we’re working on an animation && the COLLADA file stores all the needed data to be a source file just like a Maya ASCII file or the equivalent in another package. Let’s also assume the Maya exporter can store (in addition to the above) baked data on a configurable-frequency frame basis because your game engine curve-fits baked animation data. Your data preparation utilities would handle the XML parsing && generation of an optimized binary format to represent just your baked data to be consumed efficiently by your game engine. Thus, the same COLLADA file could (&& should) be both export && interchange. If either part of source or baked data happens to (or intentionally does) fit into the COMMON profile, then it should be readily manipulated by any application.

It is true that adhering exclusively to COMMON would be a restriction (especially as it may be quite limited while it’s being grown) that maybe you can’t or would prefer not to burden your artists with. If that is the case, hopefully COLLADA can still serve the purpose of a sufficient export format where you just dump baked animation data && load the same into your engine. In this approach (as seems to be greggman’s need), you would store your source data in whatever native format your DCC application utilizes && COLLADA would be merely a convenient export format because you don’t need to write an exporter, you could leverage standard viewers, && you could benefit from the myriad mature, robust, && freely available XML parsers to prepare your data for use in your runtime executable.

On the other hand, if you are capable of, && willing to, restrict your artists to the COMMON profile… such as if you must ensure certain artists with Max && others with Maya can each ongoingly work on each others assets, then you have the benefit of interoperability, you have COLLADA files as source data, interchange format, && export format. You can perform any number of external manipulations on their contents with anything from command-line XML twiddling utilities to interactive tweaks in whatever DCC program && all results work together by design within the boundaries of the COMMON profile… then you can benefit from great flexibility there.

Additionally, you could diverge from COMMON yet still use COLLADA as your source format but not an interchange format. You could have Maya artists do Maya-specific stuff with certain assets && Max artists do Max-specific stuff with different assets. Each could use their respective export / import function on COLLADA source files that are specific to their own package. Maybe those files need to be brought into your game engine through different paths which respect their distinctions but COLLADA could still serve a valuable purpose as source && export format.

I think COLLADA can be made useful && it is not a waste of effort to work towards the stated goal of agreeing on it as a standard interchange format since it would not need to become this at the expense of being an export or source data format. I’m of the opinion that if we succeed in agreeing on COLLADA as an interchange format, it will necessarily be a capable source format && will be already quite close to being an export format. It need not be an optimized export format (for if it were that, it wouldn’t use XML at all). It just needs to be sufficient to convey all the pertinant data that your engine requires. Standard XML parsers should make it quite easy to filter out all the source data that your engine doesn’t need (or alternately to pass along any helpful amount of source data whenever you find it beneficial to do so).

Sorry if I didn’t relate all that clearly. I’m trying to grok the issues && would very much like to contribute meaningfully to COLLADA’s design && development process. I think it is a great idea && hope it succeeds at its goals.

Thanks for reading.