Goals

I finally got around to reading the entire 1.0 spec. Great job guys!

Lets go over the goals and see if just maybe a different set of goals would lead to more useful decisions.

The goals as stated in the spec are:

Goals and Guidelines Design goals for the COLLADA interchange format include the following:
• Enable validation of files against the XML Schema.
• Is designed and adopted by the major DCC vendors.
• Can be used as a source repository for interactive content.
• Will grow to incorporate additional features.
• Provide Extensibility and Modularity.
• Interoperates with industry standard authoring tools
• Eases content development and prototyping.
• Supports internationalized textual content.
• Supports content streaming.

A few other infered goals are there as well

First of all, this is an interchange format, not a game engine format. We assume that the format will be beneficial to authoring tool users and interactive application content creation pipelines.

Next we assume that content creation pipelines will include rapid prototyping of test content, therefore easy creation and editing of the COLLADA resource is important.

Noticably missing from those goals are anything about being a good format for actually making 3D assets, helping artists, being useful to the most number of projects and a few other things.

I’d like to suggest a different set of goals might help direct collada to something that would benefit more people and help it become more successful, something that I think we all want.

Here are another set of goals

[ul]Unspoken Goals:
[li] To help artists make the best art possible[/:m:ezzrwkbb][/li][li] To be useful to the most number of teams possible[/:m:ezzrwkbb][/li][li] To make it possible for most teams not to have to write their own exporter or modify collada’s[/:m:ezzrwkbb][/li][li] To make it possible for any team’s pipeline to use collada files exported from any collada conforming 3D tools in as many cases as possible[/:m:ezzrwkbb][/li][li] To be adopted by the major DCC vendors.[/:m:ezzrwkbb][/ul][/li][ul]Unspoken Lesser Goals:
[li] To be a basis for data exchange between 3D packages[/
:m:ezzrwkbb][/ul][/li]
I bring this up because the goals listed in the document can arguably work counter to the goals listed directly above and I feel like the goals listed directly above are the real goals for collada. I feel like they are assumed but as they are not written they are often forgotten and the written goals end up leading away from these unspoken goals.

Here’s some examples:

Unspoken Goal: To be useful to the most number of teams possible

This goal would suggest that collada should export every piece of data it possible can from all packages even if it has to export the majority of them as <extra> items. As the spec is now, if one team requires Maya’s Translucency Focus setting to be exported they can’t use collada. With the above goal in mind it would be clear that data needs to be exported and any other data found in the scenes. User Attributes, notes, blind data, etc.

This would allow the team to code their collada-to-game-engine-format converters to look for the extra attributes needed for their game until such time as a more generic non <extra> solution is added to the standard

Unspoken Goal: To make it possible for most teams not to have to write their own exporter or modify collada’s

This means collada is not just a format. It is a format, exporters and possibly a library (a reader). As just a format it’s not very useful to most teams. As a format AND set of exporters (and possibly a library) it’s of great use to many teams. Without this goal it’s apparent from both the spec and comments on this board that collada is considered just a format and if the exporters don’t meet your team’s needs you are expected to just write your own.

It has also been mentioned in other threads that modifying collada’s exporters is not a useful option. First, it would be a burden to have to re-modify the export each time a new version came out. Second, it would defeat the goal below of allowing multiple tools to be used since then a programmer would have to become fimilar with each of those tools and make custom mods to each and every exporter.

Unspoken Goal: To make it possible for any team’s pipeline to use collada files exported from any collada conforming 3D tool in as many cases as possible

This goal as well goes hand in hand with the previous two goals. The only real benefits of collada over any private format are (1) not having to write a custom exporter and (2) allowing the use of multiple 3D tools on the same project.

Unspoken Goal: To help artists make the best art possible

I put this last because the other 3 goals support it but it’s really the single most important goal. Art is clearly the largest most costly investment in game titles today and anything which makes it easier for artists to do their job is paramount. Conversely, anything which hinders them is bad. It’s good to keep this goal in mind when designing features.

For example, the goal of attempting to allow teams to use all 3D packages means artists can use what they are most comfortable with. It also means packages that have special features can be used only when they are needed while the rest of the team uses a tool more familiar or more useful for common tasks.

To be a basis for data exchange between 3D packages

I put this goal as a lesser goal because it is in conflict with some of the other goals above. While I think it’s a great idea, in practice there is no way to be 100% exchangable between 3D packages. For example above I mentioned Maya’s Translucency Focus setting. Max has no equivilent feature so including it in collada would not support the goal of data exchange yet the goal of usefulness to as many teams as possible is more important because as stated, if the team needs that info and the collada exporters don’t export it they are forced to write there own exporters and collada is then not useful.


I hope it is clear these would be a better set of stated goals as they would lead to decisions better in line with making games.

There are some issues with the currently stated goals as well I would like to bring up because they are in conflict with the unspoken goals.

Current Goal: Can be used as a source repository for interactive content.

A “Source” repository would suggest the artist can throw away their Maya, Max and XSI files since all you need is the “source”. Collada is clearly not up to this task and trying to achieve would be a giant burden for Collada. There are thousands of features Maya, Max, XSI and other 3D programs support for which there is no equivalent support in Collada. Constraints, particle settings, IK solutions, expressions, and other items that Collada could generally never hope to cover all yet our artists will use those feature while creating their art. That means the “source” to their art will never be collada files. The source will always be the original files in the 3D editor.

Current Goal: … easy creation and editing of the COLLADA resource is important

Easy creation is great. It’s “editing” of the COLLADA file is the problem. To me, Collada would be best used as a middle format. A format that is used between the artists source files (Maya, Max, XSI file) and the final game engine format. As such it should never ever EVER be edited. It should be considered like a .o or .obj file from a C++ compiler. You take the source file and the fact that it turns info a .obj file before it becomes a .exe file is not of a concern to anyone.

A developer would never consider hand editing a .obj since they know what they are going to need to edit the original source at some point and those edits to the .obj file would get lost. In the same way, editing a COLLADA file should be considered off limits because any editing will be done by artists in their 3D tool (Max, Maya, XSI, etc.)

I bring this up because putting the goal of easy editing directly in the stated goals of collada suggests that decisions will be made effecting the design and usability of collada that directly effect how useful it is as a true middle format. For example a solution that might support a middle format might be passed over thinking the asset will just be edited later by some other tool.


I hope it’s clear there are consequences from the current set of goals. Many of the other current goals do not seem to be directly related to the unspoken goals that I believe we all generally agree on.

I strongly believe that making the unspoken goals the stated and actual goals of collada will help direct collada to being a truely useful and lasting standard which would benefit everyone.

Yes, this is one of the main goals (I’m definitely pushing for it :slight_smile: ). We should add it to the spec.

Of course you can. Here’s how you do it:
Under shader or whatever entity has this attribute:

<technique profile="Maya-6">
...
    <program name="ProgramThatDoesTranslucency">
      <param name="TranslucencyFocus" type="float" flow="IN">3.0</param>
...

Of course you can. Here’s how you do it:
Under shader or whatever entity has this attribute:

<technique profile="Maya-6">
...
    <program name="ProgramThatDoesTranslucency">
      <param name="TranslucencyFocus" type="float" flow="IN">3.0</param>
...

[/quote]

I didn’t mean that there was no way to put the data in a collada file. I meant that using the current collada exporters with the current mandated rules in the spec the exporters don’t do this now and the collada spec does not mandate that they do.

In other words, you are telling me that in order to get that info I should write my own exporter or modify the provided one. If that’s that case than collada is of no use to anyone since everyone will be writing their own exporters. At that point, why even consider collada? What is the actual benefit?

No, what I’m telling you is that it is the responsibility of the modeler companies (Alias in this case) to export/import everything that’s useful.
That’s the only way to get the (imaginary) “100% Collada compliant” sticker…
It’s kind of like: if your graphics API doesn’t do glDrawElements, you can’t officially call it OpenGL…
:wink:

They are working with us and are doing a great job at it, but the exporters are not full-featured yet.
:wink:

Very cool :slight_smile:

Then, just to be clear, my point is it doesn’t say this

it is the responsibility of the modeler companies to export/import everything

In the spec

(including user attributes and user blind data ;-))

I’ve thankfully had some time to begin digesting these forums && am quite glad to see the discussions && progress which have already been made. Maybe this thread is too old to receive much further attention but it still seems poignant && I want to begin participating in dialog so maybe someone will respond or at least benefit from another opinion…

Hello greggman. I think you bring up some good points but maybe not all the differences in stated or implied goals need to be contentious as you suggest.

Let me say I think you’re absolutely right that we should be explicit in wanting COLLADA to become both a format as well as a set of supported exporters / importers from major vendors. That would clearly be most useful for developers && thankfully the major DCC vendors are already onboard. Additionally, as much data as is discernable should be exported within <extra/> or other appropriate elements until the format can be extended to encompass hopefully all of those values logically && descriptively.

The discrepancy comes from:

• Can be used as a source repository for interactive content

I admit that this is an ambitious goal but this seems to be the crux of the issue. If all data is exported then that means that Translucency Focus && user attributes && blind data should be too. The idea that the file can be an interchange format means it can be imported as well as exported. This also means it should be editable. It should be able to be modified in different applications. It should be a source repository. Maybe this highlights a broader discussion of whether this is feasible but I think because so many developers && relevant companies have already made a great deal of progress towards these ends, it suggests there is sufficient commitment && benefit to be gained from pursuing it.

Unspoken Goal: To make it possible for any team’s pipeline to use collada files exported from any collada conforming 3D tool in as many cases as possible

This goal as well goes hand in hand with the previous two goals. The only real benefits of collada over any private format are (1) not having to write a custom exporter and (2) allowing the use of multiple 3D tools on the same project.

To allow use of multiple 3D tools… not just on the same project but on the same art assets, the exported data should be the source.

Unspoken Goal: To help artists make the best art possible

I put this last because the other 3 goals support it but it’s really the single most important goal. Art is clearly the largest most costly investment in game titles today and anything which makes it easier for artists to do their job is paramount. Conversely, anything which hinders them is bad. It’s good to keep this goal in mind when designing features.

For example, the goal of attempting to allow teams to use all 3D packages means artists can use what they are most comfortable with. It also means packages that have special features can be used only when they are needed while the rest of the team uses a tool more familiar or more useful for common tasks.

I think yours is a fine goal but maybe subtly && critically different than what I’d guess most others want / need. Here’s what is more appropriate to me but still in the same vein as your helping artists make the best art possible…

Unspoken Goal: To help get the best art possible from DCC applications into games

You seem to be of the opinion that artists’ comfort is most important because what they create “is clearly the largest most costly investment in game titles today”. I feel that programming is a more costly investment (even though it is typically not as large upfront) because success hinges upon it to an immensely greater degree (where you could read “success” as either shipping a product or commercial success in the marketplace… both of which outweigh any delta between paychecks cut to an art department && a coding department). I agree that a great deal of art is created for modern games but if the results of that work (all the art asset data) are not easy to manipulate, track, process, && manage, then those assets will not be leveraged well within a game title.

You say that COLLADA files “should never ever EVER be edited”. If they were to store constraints && particle settings && IK solutions etc., then why not? I think COLLADA files should be edited && the stated goals towards those ends are already very good (albeit ambitious).

Thanks for reading my opinion.

-Pip

For our game engine, we currently use a 3DS MAX exporter which writes to a custom format, does some preprocessing etc. The engine however features an in-game editor allowing among other things to edit scenes, materials, lights etc. so we can edit game-specific properties in-game at run-time (WYSIWYG).

The problem that implies is any scene or material exported from 3DS MAX is marked “non editable” in our editor since any changes made in the editor would be lost the next time the file is exported from 3DS MAX.

COLLADA might bring a solution to this problem, since perhaps our editor can write back properties to the xml file which will be kept by any other application?

Will all COLLADA importers/exporters keep any custom data written to the file by external applications or should tags (like <extra>) be used?

Custom data and user data ARE stored in <extra> elements that are well specified containers for lists of arbitrarily-typed parameters.
The EQUINOX-3D COLLADA plugin already makes extensive use of <extra> elements (on nodes, geometries etc.) as well as the global, <application> element (user-interface setup, window layout, renderer settings etc.) and they’ve been both proven very powerful.

Custom data and user data ARE stored in <extra> elements that are well specified containers for lists of arbitrarily-typed parameters.
The EQUINOX-3D COLLADA plugin already makes extensive use of <extra> elements (on nodes, geometries etc.) as well as the global, <application> element (user-interface setup, window layout, renderer settings etc.) and they’ve been both proven very powerful.[/quote]

Very cool, now I am officially a COLLADA believer. :slight_smile:

Thanks!

To answer your question: No.

Like Gabor said you can add custom data but to your question, other tools (except your own) will not generally read that data and keep it around by default.

Now, some 3d editors support user attributes per object, material, light etc and it’s expected to be part of the next version of collada that those editors that do support that feature will be required to both import and export those attributes. If possible it will be in a common way, if not possible it will be in a tools specific profile. But, if you are using a 3d editor that supports user attributes and they tool provider has updated their importers/exporters then you could possibly use the same format for your in-game editing and in that case the data would stay around.

That would be great. Do you have an estimation on when the next version will be available?

offtopic: I noticed you work for Sony (CEJ) in Tokyo; I once did a half year internship at Sony (R&D) over there of which I have good memories. So greetings from the Netherlands from an ex-colleague. :wink: