I have recently been looking at Collada and I really like the format. I am curious about the Maya Exporter though as it seems to be really simplistic at this stage.
The following features do not seem to be supported at all:
[ul] Instancing Referencing - how would this work? Could the exporter automatically check if a collada file exists for each referenced file in Maya? Extra attributes on nodes (including notes) History and Tweaks - obviously this is important if this file format were to be the source format for files. However, to us, it is more important that the exporter has the option to collapse history and tweaks for loading/converting into the game format hard/soft edges
[/ul]
What is the roadmap for the above features? Is there an estimated time to implement these features? Is it possible to help/contribute to the Maya exporter?
Can I add a list of features we’d like to see implemented:
Correct interpretation of other axes schemes.
e.g. Max to Maya
There is a problem if we export a scene from Max then import it into Maya. The objects are not oriented the same.
recognises scale measurement (e.g. metres) defined in collada file
Export of shader networks involving file(s)->layered texture->material
Export of blendShape target shapes and animated blend weights
importer should understand TEXCOORD in addition to UV to specify texture coordinate streams.
Exporter will write TEXCOORD (or UV) depending on which the spec says is correct to allow interoperability with other Collada importers.
export/import some attributes of the nodes
(e.g. visibility)
standardise on using .dae or .xml as the default file extension, and filter for this in the import/export file dialogs.
But allow file spec of . to allow importing from other Collada files which may not use the correct extension.
when importing detects the file type appropriately by looking at the contents of the file.
initialise time range to fit range of frames imported if a collada file contains animation.
(maybe this could be a user option)
export of keyframed animation where the animCurve is not connected directly to the joint node.
e.g. where ‘character’ and ‘clips’ are used. In this case animCurve is connected to character/clips which are then connected to the joint.
Differences between scaling applied to joint/transform hierarchy and parent transform of shape.
e.g. joint/transform hierarchy has a uniform scale on the top-most joint/transform which is not 1, but parent transform of shape has a uniform scale of 1.
In this case the importer doesn’t re-create the scene properly; the skin and joint hierarchy are not positioned and scaled the same as at export time.
Also scale doesn’t seem to work.
Tests here show that scaling a cube and exporting it results in the collada file having a scale of <scale>1 1 1</scale>
This worked early on, though I think I pulled it out while I got some other things working. Shouldn’t be too hard to add this back in.
Referencing is certainly a bit tricky. There’s two parts to this - one is adding support for external (i.e. outside the document) elements in the COLLADA import and export code, and the second is working out how to map Maya’s file referencing onto it. If we restrict this to just whole surfaces/transform heirarchies, it shouldn’t be too bad.
Do you mean blind data? Or do you mean adding Maya attributes that maybe aren’t reflected in COLLADA?
Just to clarify - do you mean that right now it collapses all history/tweaks, but that you’d like the option to store the history in the COLLADA file? Or are there some scenarios where the COLLADA output is not correctly collapsing the history/tweaks?
Either way - I will say that trying to include Maya’s editing history is a large task (and perhaps the best solution would be working out a generic mapping of Maya’s node and attribute structure into COLLADA user data, then just dumping parallel structures for everything).
Our initial focus will be getting the collapsed geometry out - but I’d certainly be happy for any offers of help adding the generic DG mapping =)
Hmmm … perhaps I pulled the wrong normal out as I would have hoped this would have been reflected in the normal data. Need to investigate this.
[/ul]
So right now, we’re just tidying up COLLADA 1.1 core features, and are looking for input exactly like this on how many people are looking for which features. The best news (at least for me =) is that I’m very happy to have you contribute! Feel free to take a look through the source code and see if there are any features you’d like to add. It’s probably worth dropping me a line to let me know what you’re planning on working on (and possibly even how you’re planning to do it) to minimise the chance of duplicated effort or changes I can’t merge back in.
So, I just posted a small update to the exporter. This fixes the instancing on shapes, allows the importer to consume either “UV” or “TEXCOORD” and fixes export of scale values.
Stuart, I looked into the hard/soft edge thing - and in my (admittedly trivial) test case, I exported two cubes, one with hard edges and one with soft, and the exported data does contain smoothed normals for one, and hard for the other. They also import back in ok. Do you have an example where this is not working? Or is your concern more that COLLADA itself doesn’t explicitly describe edges as hard vs soft?
Now, to some of your points Andy (skipping the one Remi is following up on) …
Do you mean you want automagic conversion between Maya’s default cm and COLLADA’s default metres, so that loading in a vertex at 1.0, 1.0, 1.0 will move it to 100.0, 100.0, 100.0? Or has an explicit unit parameter been added to COLLADA while I wasn’t looking?
Most of our customers choose to stay in Maya’s default units, so I wanted to avoid having all the values change by a factor of 100 going in and out.
There is no COLLADA standard element for representing a layered texture (at least, not that I’m aware of), and my focus to date is on supporting the standard elements. Does this mean you want COLLADA to define this element? Or that you want the Maya import/export to bury some Maya specific data in there that no other apps will understand? Or something else?
Perhaps Marcus can correct me if I’m wrong - but I don’t think we’ve gotten around to defining blend shapes/targets yet. Suspect that will be coming soon. Be sure to pass you priorities on extensions to COLLADA back to Marcus and co!
Done.
Not sure what you mean here - there should only be one right answer and that’s the one I should export. I know it moved around a bit - so did I end up picking the wrong one? It’s easy to change (just look in the syntax file for all the tags if you want to update it yourself).
Is this something supported by COLLADA that I haven’t implemented? Or is this something you’d like added to COLLADA?
The problem here is that Maya translators can only register one file extension. Unfortunately, COLLADA has two. My personal vote was for .dae (as there are loads of XML documents out there that are not COLLADA, so I feel using .xml will lead to ambiguity). If you look at the top of the DaeTranslator.cpp file, you can comment in whichever extension you would lik to use. Unfortunately, probability says that 50% of the people will not like the default I use.
Is this for working around the .xml ambiguity?
As stated above, there are lots of extensions we can make to the exporter and you are most welcome to contribute, so if you’d like to add this code just send it my way =)
Agree that would be a nice touch. Again, contributions are welcome =)
I thought I handled this - so can I get the scene you’re using?
I’ve fixed the export of scaling value in the latest drop - can you test it out now as this might fix this problem too.
The later. If I add a dynamic attribute to a node (float, bool, string etc) I would hope it would be exported in some form to COLLADA.
Currently the exporter collapses all history/tweaks. For me I do NOT want history in the COLLADA file so at the moment things are good. This comment was mainly regarding the ‘design goal’ for COLLADA. If you were to add history and tweaks to the COLLADA exporter, it would be important to have the option to collapse as well.
Exactly. You are pulling the right normal values out but for our purposes, we require a way to know if an edge is hard or soft based on an extra attribute for example. I am not quite sure how this would work.
Yes the <asset> element has supported units of measure and orientation since 1.0 release. For Maya default to be expressed correctly Gordon, you need to handle this explicitely at least at the instance document level. For example:
I have a scene where the exporter exports two UV input tags but only one UV ‘stream’ in the collada file.
The mesh has a total of 6 verts - 2 quad faces but each
tag doesn’t seem to have enough data.
Can you verify if this is correct or if this is a bug. You can download the .ma and .dae files from here:
Just to let you know if you haven’t found an answer yet - Collada supports reducing the number of required indices in p elements for inputs with the same indices.
Since you have 2 inputs on the polygons element that are from the same source (testShape-map1), they can re-use the same index. This means that you have 4 inputs but technically only 3 unique inputs and therefore triples of indices.
There’s also an attribute on the input element that also can indicate separate indices for inputs from the same source. I believe if is called ‘sid’ or ‘idx’ - it changed at some point. I think the specification clarifies the procedure for defining the unique inputs from the list of inputs.
I didn’t realise you could do that. My assumption was each input I find is the next number in the
tag and that the number of inputs = the ‘stride’ in the
tag. Obviously this is incorrect.
It also seems that you can reuse the indices accross different input types and sources. If you refer to page 3-38 of the spec it shows verts, normals and textcoords all using idx 0.
So it would seem then that the only way to know how to read the
tag correctly is to have the idx attributes for each input. If they don’t exist then you can’t be sure what the
tag is indexing!
If this is the case, Gordon - we need to get the idx attributes into the exporter. In fact on page 3-54 it says the idx attribtue is a required attribute of the input tag.
Right. As of COLLADA v1.1, the idx attribute is required on <input> elements within <polygons> elements. “idx” (index) values identify the set of unique inputs within the scope of the current parent element. Origiinally in 1.0, we thought it was okay to leave it implicit and to determine uniqueness heuristically, but users wanted it to be explicit and so the idx attribute is now required.