XSI 5.11 Collada Export Bug

I’m getting duplicate id attributes in my exports. One example of this problem is an image and a material sharing the same id.

The other example looks like:


<triangles count="14" material="DefaultLib1.Material5">
	<input semantic="VERTEX" source="#geometries_98-Vtx" offset="0"/>
	<input semantic="NORMAL" source="#geometries_98-ImplicitNormal" offset="1"/>
	<input semantic="NORMAL" source="#geometries_98-User_Normal" offset="2"/>
	<input semantic="TEXCOORD" source="#geometries_98-Texture_Projection" offset="3"/>
	<input semantic="COLOR" source="#geometries_98-Vertex_Color" offset="4"/>
	<input semantic="COLOR" source="#geometries_98-Vertex_Color" offset="5"/>
	<input semantic="COLOR" source="#geometries_98-Vertex_Color" offset="6"/>
	<input semantic="COLOR" source="#geometries_98-Vertex_Color" offset="7"/>
	<input semantic="COLOR" source="#geometries_98-Vertex_Color" offset="8"/>
	<input semantic="COLOR" source="#geometries_98-Vertex_Color" offset="9"/>
	<input semantic="COLOR" source="#geometries_98-Vertex_Color" offset="10"/>
	<input semantic="COLOR" source="#geometries_98-Vertex_Color" offset="11"/>

Note all the colour inputs. There are actually seperate <source> elements and data exported for each one of those colour references, and each has the same id. I’m not sure why there are so many (I haven’t talked to the artist yet), but I’m sure they should have unique ids.

Cheers,
Dave

The id attribute values need to be unique within the document. Sounds like a bug in the XSI exporter.

Does anyone know of somewhere I can report this?

Thanks,
Dave

Hi Dave,

please send me the repro steps to create the scenes with which you’re having the problem. I will enter the issue in our database at Softimage and will make sure that we look into it.

thanks a lot for this feedback!
LB

To reproduce, simply create and export a scene where a material and a clip share the same name. They will both be given that name as an id for the respective <image> and <material> elements. Keep in mind there are other situations where duplicate ids are generated, such as the vertex colour thing, but that is a bit more complicated so I’ll try to get a repro case when I have some time.

Other issues I have found:

There is really strange behaviour with the handling of CgFX parameters. If I create a parameter in a cgfx file like:


A: float1 Colour = 0.8f;
B: float2 Colour = {0.8f, 0.5f};
C: float3 Colour = {0.8f, 0.5f, 0.1f};
D: float4 Colour = {0.8f, 0.5f, 0.1f, 1.f};

I do these one at a time, and assign that cgfx file to a CgFX node in the render tree. The element it generates for those cases (without tweaking the values) looks like:


A:
<setparam ref="Colour">
	<1>0.800000</1>
</setparam>

B:
<setparam ref="Colour">
	<2></2>
</setparam>

C:
<setparam ref="Colour">
	<3></3>
</setparam>

D:
<setparam ref="Colour">
	<float4>0.800000 0.500000 0.100000 1.000000</float4>
</setparam>

Strangely, this seems to only happen in certain cases: if it is the last tweakable parameter in the file, or if it is followed by a string parameter (may be other cases as well).

You can work around this issue by placing a float4 after any troublesome parameters, but I would still consider it a major problem since it generates invalid XML.

One other issue/feature request is to support exporting writeable image sources. I use a rendertree with a writable image for a lightmap, and then link that same image to a CgFX node. I get good results in the OpenGL viewport (it uses the lightmap properly), but when I export to COLLADA, I just get <init_from>file://</init_from> for the lightmap <image>.

Sort of related to that, but not a COLLADA bug, is the fact that I can’t write lightmaps in DDS or HDR format, and the OpenGL viewport doesn’t seem to handle EXR or HDR images properly (the only formats that support HDR AFAIK). Because of this if I attach a readable source to the lightmap EXR (as a workaround), I get a valid export, but no OpenGL preview.

One more:

Relative paths shouldn’t have a URI scheme on them, I get things like:

“file://Pictures/surface_map.bmp”

which should be just:

“Pictures/surface_map.bmp”

Also absolute local paths should be prefixed with a /, right now it’s:

“file://C:/blah”

should be:

“file:///C:/blah”

Cheers,

Dave

<accessor source="geometries_0-Pos-array" count="81" stride="3">

‘source’ attributes are URI format, the value should be prefixed with #.

Yep, but not all of them are messed up, so it looks like the programmer just forgot to update some of them when the changeover from version 1.3 to version 1.4 was made.

Specifically, the Skin, Position, Normal and UV Texture source accessors are all malformed:

accessor source="geometries_0-Pos-array"

should be:

accessor source="#geometries_0-Pos-array"

And:

accessor source="geometries_0-Texture_Projection-array"

should be:

accessor source="#geometries_0-Texture_Projection-array"

Also:

accessor source="geometries_0-ImplicitNormal-array"

should be:

accessor source="#geometries_0-ImplicitNormal-array"

And finally:

skin source="geometries_0"

should be:

skin source="#geometries_0"

One other bug - the elements that are bones are supposed to have an attribute:

type="JOINT"

It appears that some of these bugs have been reported on various forums for many weeks (if not months), and no update has been released. Is someone at Softimage actively working on fixing bugs in the Collada 1.4 export feature?

As it stands now, the Collada 1.4 exporter in XSI 5.11 is seriously broken, and it is not usable in a production environment.

I also posted these bugs on the Softimage XSI Foundation General Discussion forum:

http://forum.softimage.com/topic.asp?TOPIC_ID=7463
http://forum.softimage.com/topic.asp?TOPIC_ID=7465

I’ve come to the same conclusion. At first I was impressed that they had built-in collada support, but now it’s looking like a drawback. At least with with the open source tools (max/maya) I can fix any problems I come across.

Native support will be good in the long run, but all the tools are so immature right now that having the source has been critical for me.

I’ve come to the same conclusion. At first I was impressed that they had built-in collada support, but now it’s looking like a drawback. At least with with the open source tools (max/maya) I can fix any problems I come across.

Native support will be good in the long run, but all the tools are so immature right now that having the source has been critical for me.[/quote]

Yep. For me this is all very annoying, because I have a fair amount of experience writing Collada 1.4 exporters for my other modelers (Hexagon/Carrara and Modo 201), so if I had the source code for XSI 5’s Collada 1.4 exporter, I could fix these fatal errors myself. But now that the XSI 5 Collada 1.4 exporter is built-in (and closed source) we’re stuck waiting for an update that may or may not come anytime soon. (I would prefer not to start implementing my own Collada 1.4 exporter for XSI 5, given that I already paid USD $495 for one from Softimage.)

[Edit: Thanks for responding, Softimage.]

Cheers.

Hello, sorry for the silence, we’ve been pretty busy with Siggraph. We are aware of these problems and we are looking into releasing a solution for all XSI 5.1x users.

Best regards

Well, I’ve received several responses from Softimage here and elsewhere, all indicating that there are no concrete plans to release an update to fix any of these issues.

Plus, working with two other game developers, I discovered today, that even if I manually “fix” the output from XSI 5 by hand-editing the XML file, the animation itself is unusable in both Max and Maya 7, as well as the game engine I am using.

Here’s a constructive suggestion.

If Softimage would have kept the Collada 1.4 exporter as a plugin with the source code available, I would have been busy adding the missing features and fixing the bugs I’ve found myself, instead of posting on this forum. (This is what I did with all of the other 3D products I am using Collada with.)

Softimage should reconsider their decision, and once again open the source code for their Collada exporter, so that third-party developers can quickly resolve bugs and other issues on their own.

I don’t understand what competitive advantage it gives Softimage to have a closed-source Collada plugin, while just about everyone else who is supporting Collada, big and small (Max, Maya, Carrara/Hexagon, modo, and more to come) is freely sharing the source code for their implementations, to make sure that any issues can be quickly addressed outside of the normal update cycle schedules.

What do you say Softimage? Open the source code for your Collada 1.4 plugin, and let your customers work out the issues for themselves.

Cheers.

Hi, we understand your issues and your concerns. Here are some answers

==========================================
We have two levels of source code availability for the COLLADA integration.

The first level which is available to all XSI users via the SDK, is the dotXSIConverter source code which is also used for converting to/from COLLADA. This is essentially the plugin stub that connects XSI with the FTK (described below). This source code ships with all flavors of XSI including the Foundation licenses.

The second level is only available to maintenance customers who require the full source code of the FTK, which is the low level layer we use to read/write COLLADA and dotXSI files. This is available only on a case by case basis and with additional charges. The reason for this is that we have more IP to protect in that source code than the dotXSIConverter itself. It is therefore a lot more legal work to get it in the hands of customers. This is a policy that is not exclusive to our company, others like Autodesk for example, do not distribute the source code for the FBX library which is the equivalent.

Even if you don’t have access to the FTK library and you want to patch the output of the COLLADA file, it would be possible to recompile the dotXSIConverter and add code there that would inspect the nodes and fix them. You have full access to the elements, attributes and content of the XML file prior to writing it. The dotXSIConverter works as follows

  1. create UI/contexts/FTK scene
  2. populate the FTK scene from the XSI scene
  3. write

You can easily add code in any of these stages to match up with your pipeline.

If you want to go that route, and you need some advice, drop us a line and we will try to find some time to help you.

==========================================
On the issues of Max and Maya interoperability, we have indeed experienced issues and problems on our side. Some of it are bugs in our software, and some of it are bugs in other people’s software. We are putting a lot of resources to ensure a better user experience, but because COLLADA is a very flexible format, incompatibilities will occur. That being said, the Khronos group is creating a Conformance Test that COLLADA implementations can use to ensure compatibility with each other. Hopefully, this will increase the quality of the tools.

On the animation side, we have experienced some “interpretation” problems that could explain your bug. These have to do with the way spline tangent data is represented.

==========================================
Lastly, but not least, we would like to reiterate that we are going to release a solution to fix the most urgent issues in our COLLADA implementation for all 5.1x users.

Best regards.

I am certainly willing to write some code to fix up the appropriate elements and attributes in the Collada XML, to the extent that it is possible, so an SDK that will help to implement such code sounds good.

However, I tried to download the XSI SDK from your site at www.softimage.com, under the Softimage|XSI SDK tab, but your site does not permit me to download the SDK, even though I have an account. It simply returns me to the login page, even though I am already logged in (the top of the page has a “Welcome” message with my account name, indicating that I am logged in).

Are you able to authorize me to download the SDK? Or is there another distribution channel for Foundation customers?

Thanks for following up so quickly.

There is no separate SDK download for XSI. It’s included with the Foundation, Essential and Advanced packages. You can access the help via the start menu. The libs, includes and examples are under a directory called XSISDK in your installation path. Everything you need to recompile the dotXSIConverter is there.

Best regards.

Thanks. The SDK looks like it has everything I need to get started on my own plugin.

By the way, do the licensing terms for the SDK permit me to distribute any plugins I develop to other Softimage customers?

A number of game developers would appreciate it if I could share a post-processing plugin that fixes up XSI’s Collada files enough to work with a game engine I’m working with.

Hopefully the SDK makes it possible for me to work out a solution before you have an update available.

Good luck working on your update.

You can read the EULA provided with XSI and the SDK. You can redistribute modified examples as long as it’s not for profit. I believe you need to maintain all the copyright information, please double check the EULA.

Hope that helps!

We have put an unsupported patch for COLLADA support in XSI 5.1x. You can download it from here

http://www.softimage.com/downloads/default.aspx

It fixes the following issues

  • fixed: duplicate ID when material and a clip share the same name
  • add missing “#” prefix to the accessor source for vertex attributes (Position, Normal, UV Texture, etc.)
  • add missing “#” prefix to the skin source element
  • fixed: CgFX parameters <setparam> not filled properly at export
  • handle URI relative and absolute path. Output file:/// when path are absolute, output without the “file:///” when the file is relative and reads both file:/// and file:// or relative path without file:///

Enjoy!

PS: we will check back if there are any other issues on the 28th (Vacation). :slight_smile: