Imcompatibility across different packages

It is allow using collada specification to write files that are syntactically 100% collada 1.4.x compliance, but that are a subset of the grammar?
Say for example changing the extension from xml, or dae to something else.

The reason I say this is because I had found that plugging makers for popular modeling packages violates Collada specifications.
It appears that Fcollada is more strict and compliance than Collada DOM, for what I can see collada Dom is a wrapper over XML with not type validations of any kind.

My primary concern is to have true data exchangeable functionality, but only on the type of data I am operating. Collada provides that but it provides a lot more.

It may sound a triviality, but for example if I export a cube from XSI, I can load it in Max but it comes with a whole set of other things, like camera, light, procedural model, etc.
If I experts a cube from Max then XSI collada do not understand the format.
And I give up on blender, blender exported files are not collada compliance at all.

So for me saying that my library supports Collada will be a cause for debates, each time some one try to load a file with a package that does not support the data. Since I am an underdog I do not want to go into debates and explanation. But if the file have a different extension I do not have to explain anything, It will be collada as long as the package plug-in is 100% collade compliance. And it will be upto the user to rename it to DAE.

So far all files I generates can be loaded and parsed by Fcollada library, the Max plugin, and Collada viewer from free soft where. But not by Blender, XSI, and I had not tested on Maya.

It is possible that I just do not understand Collada but I had some sample file that I had created and I can post a link, perhaps some body would like to test then with this packages and maybe tell me if I am doing something wrong.
They go from a simple a cube to medium complexity to fairly complex hierarchies.

It is allow using collada specification to write files that are syntactically 100% collada 1.4.x compliance, but that are a subset of the grammar?

I am not sure what you mean, but in order to test if a COLLADA file is compliant you have a two major tools available:

  • XML validator. You can use any XML validator (like XMLSpy, or embedded in libraries such as libXML2) to validate a COLLADA document. This will check for all that we could express in the Schema language.
  • Coherency test: this is a set of conditioners that will check for consistency/coherency of the document. This covers for the part of the specification that cannot be embedded in the schema. (for example, is the count parameter matches with the number of elements). We are adding conditioners to this test each time we find an implementation problem.

If you find out that some tools are violating any of the above tests, please immediately report bugs to the tool developer.

Say for example changing the extension from xml, or dae to something else.

.dae is the extension chosen for COLLADA documents. You can also use .xml, since COLLADA documents are XML documents, but it is always more convenient to use the dae extension to know upfront what the file may contain.

The reason I say this is because I had found that plugging makers for popular modeling packages violates Collada specifications.

As incredible as it may be, some do not read the specification at all ! I found out that some do reverse engineering on files exported by their favorite tool, not even checking that the document validates, propagating errors.
So it is really important to chase down all those implementations, and help them to fix the issues. This is why the coherency test is very important in my opinion, since this provides with an easy way for everybody to test, without any doubts.
Of course, the main way to get all those implementation and quality issues solved is to find and report bugs, and to follow up with vendors very regularly to make sure those are fixed. This is what SCE focus in on, and we will keep doing this until the level of quality is good.

It appears that Fcollada is more strict and compliance than Collada DOM, for what I can see collada Dom is a wrapper over XML with not type validations of any kind.

You can compile the DOM so that it will use libXML2 to validate the data against the schema every time it is loaded. I do not know the details but I was told it is easy.

Your point though, is that FCOLLADA and COLLADA-DOM are different. FCOLLADA has a higher level of abstractation, and make it easier for programming import/exports, but the COLLADA-DOM gives you more control, and is a lot closer to the schema, since its front-end is generated automatically from the XML Schema.

It may sound a triviality, but for example if I export a cube from XSI, I can load it in Max but it comes with a whole set of other things, like camera, light, procedural model, etc.
If I experts a cube from Max then XSI collada do not understand the format.

I am not sure I understand what the problem is ? You export a cube from Max in COLLADA and XSI cannot load it back ?
There are issues that we are getting fixed, but they concern advanced features, for most users, the interchange between MAX, Maya, and XSI works perfectly .

And I give up on blender, blender exported files are not collada compliance at all.

That is correct, but since Blender is an open-source project, the work in the export/import is done by donating time to this project. They are currently working on animation, but have basic issues with textures. The Physics part works great though, which is more advanced than what 3dsMAx provides at the moment. I guess my point is that it is up to the community to help with the development of the Blender plug-in

So for me saying that my library supports Collada will be a cause for debates, each time some one try to load a file with a package that does not support the data. Since I am an underdog I do not want to go into debates and explanation. But if the file have a different extension I do not have to explain anything, It will be collada as long as the package plug-in is 100% collade compliance. And it will be upto the user to rename it to DAE.

That is why we have made the coherency test available, which BTW now includes the XML validation. You now have a good way to test the data, and close debates.

It is possible that I just do not understand Collada but I had some sample file that I had created and I can post a link, perhaps some body would like to test then with this packages and maybe tell me if I am doing something wrong.
They go from a simple a cube to medium complexity to fairly complex hierarchies.

Samples are important, and we have neglected that part so far. We have just released 1.4.1 samples, and want to grow a database of sample data. I’ll get someone to contact you to see if you would accept to donate those samples to the community, provided they pass the coherency test !

Well I may be wrong but I believe I exported a simple triangulated cube from Max at work, and XSI 5.11 refuses to load it. I saved a cube from XSI and Max can load it without problems. Maybe the file was corrupted I will try again but I am very positive this was right since I can load the file as well and the file also loads with collada viewer from Feeling Software.

Beside this is pointless if the answer to my first question is no. So I ask again, It is not allowed to distribute files or a tool that generates files that are grammatically correct according to this document http://www.khronos.org/cgi-bin/fetch/fe … a_spec_1_4 but that have a different extension?

And for the record I see that you move forth and back between XML and DAE, and perhaps these is why there is so much anarchy with data exported from different packages with collada exporters.
The way I understand all DAE file are XML files but not all XML file are Collada files, and collada dom seems to accept a XMLs file as a valid DAE file.

I do not want to tell you what is right or what is wrong, I just want to come to a solution that is simple enough for me and my users, and be as standard as it can possible be.

I will do the cube test again and if post me finding.

Oh I see I can distribute file with XML extension. That answer my first question.

Ok I tried the test cube again. And her it is.
This is a cube created in 3dsmax 7, converted to triangle mesh.
It has a single targa texture applied to it.
XSI fails to load it with the error unspecified failure.
If I export the same file without texture, then XSI loads it correctly.

The image file is in the same directory that the dae file, and I know that XSI supports targa file because I can create a similar cube and texture using the same texture.
This file loads without any problems in Max and also with the Feeling Viewer tool.

I think the file is small enough to demonstrate what I say.
I hope that this is somethig I am doing wrong.

<?xml version="1.0" encoding="utf-8" ?>
<COLLADA xmlns="http://www.collada.org/2005/11/COLLADASchema" version="1.4.0">
   <asset>
      <contributor>
         <author>Jon smith</author>
         <authoring_tool>3dsmax COLLADA exporter v2.10</authoring_tool>
      </contributor>
      <created>2006-09-22T03:52:45Z</created>
      <modified>2006-09-22T03:52:45Z</modified>
      <revision>1.0</revision>
      <unit name="inch" meter="1"></unit>
      <up_axis>Z_UP</up_axis>
   </asset>
   <library_images>
      <image id="Map__1" name="Map__1">
         <init_from>./camo.tga</init_from>
      </image>
   </library_images>
   <library_materials>
      <material id="_01_-_Default" name="_01_-_Default">
         <instance_effect url="#_01_-_Default-fx"></instance_effect>
      </material>
   </library_materials>
   <library_effects>
      <effect id="_01_-_Default-fx" name="_01_-_Default">
         <profile_COMMON>
            <technique id="_01_-_Default-fx-COMMON" sid="COMMON">
               <phong>
                  <ambient>
                     <color>0.588235 0.588235 0.588235 1</color>
                  </ambient>
                  <diffuse>
                     <texture texture="Map__1" texcoord="CHANNEL1">
                        <extra>
                           <technique profile="MAX3D">
                              <amount>1</amount>
                           </technique>
                        </extra>
                     </texture>
                  </diffuse>
                  <specular>
                     <color>0.9 0.9 0.9 1</color>
                  </specular>
                  <shininess>
                     <float>10</float>
                  </shininess>
                  <reflective>
                     <color>0 0 0 1</color>
                  </reflective>
                  <transparent>
                     <color>1 1 1 1</color>
                  </transparent>
                  <transparency>
                     <float>0</float>
                  </transparency>
               </phong>
               <extra>
                  <technique profile="MAX3D">
                     <spec_level>
                        <float>0</float>
                     </spec_level>
                     <emission_level>
                        <float>0</float>
                     </emission_level>
                     <faceted>false</faceted>
                     <double_sided>false</double_sided>
                     <wireframe>false</wireframe>
                     <face_map>false</face_map>
                  </technique>
               </extra>
            </technique>
         </profile_COMMON>
      </effect>
   </library_effects>
   <library_lights>
      <light id="global-ambient-light">
         <technique_common>
            <ambient>
               <color>0.360784 0.360784 0.360784</color>
            </ambient>
         </technique_common>
      </light>
   </library_lights>
   <library_geometries>
      <geometry id="Box01-obj" name="Box01">
         <mesh>
            <source id="Box01-obj-position">
               <float_array id="Box01-obj-position-array" count="24">-0.500000 -0.500000 0 0.500000 -0.500000 0 -0.500000 0.500000 0 0.500000 0.500000 0 -0.500000 -0.500000 1.000000 0.500000 -0.500000 1.000000 -0.500000 0.500000 1.000000 0.500000 0.500000 1.000000</float_array>
               <technique_common>
                  <accessor source="#Box01-obj-position-array" count="8" stride="3">
                     <param name="X" type="float"></param>
                     <param name="Y" type="float"></param>
                     <param name="Z" type="float"></param>
                  </accessor>
               </technique_common>
            </source>
            <source id="Box01-obj-normal">
               <float_array id="Box01-obj-normal-array" count="108">0 0 -1.000000 0 0 -1.000000 0 0 -1.000000 0 0 -1.000000 0 0 1.000000 0 0 1.000000 0 0 1.000000 0 0 1.000000 0 -1.000000 0 0 -1.000000 0 0 -1.000000 0 0 -1.000000 0 1.000000 0 0 1.000000 0 0 1.000000 0 0 1.000000 0 0 0 1.000000 0 0 1.000000 0 0 1.000000 0 0 1.000000 0 -1.000000 0 0 -1.000000 0 0 -1.000000 0 0 -1.000000 0 0</float_array>
               <technique_common>
                  <accessor source="#Box01-obj-normal-array" count="36" stride="3">
                     <param name="X" type="float"></param>
                     <param name="Y" type="float"></param>
                     <param name="Z" type="float"></param>
                  </accessor>
               </technique_common>
            </source>
            <source id="Box01-obj-mapchan-1">
               <float_array id="Box01-obj-mapchan-1-array" count="36">0 0 0 1.000000 0 0 0 1.000000 0 1.000000 1.000000 0 0 0 0 1.000000 0 0 0 1.000000 0 1.000000 1.000000 0 0 0 0 1.000000 0 0 0 1.000000 0 1.000000 1.000000 0</float_array>
               <technique_common>
                  <accessor source="#Box01-obj-mapchan-1-array" count="12" stride="3">
                     <param name="S" type="float"></param>
                     <param name="T" type="float"></param>
                     <param name="R" type="float"></param>
                  </accessor>
               </technique_common>
            </source>
            <vertices id="Box01-obj-vertex">
               <input semantic="POSITION" source="#Box01-obj-position"></input>
            </vertices>
            <polylist material="_01_-_Default" count="6">
               <input semantic="VERTEX" source="#Box01-obj-vertex" offset="0"></input>
               <input semantic="NORMAL" source="#Box01-obj-normal" offset="1"></input>
               <input semantic="TEXCOORD" source="#Box01-obj-mapchan-1" offset="2" set="1"></input>
               <vcount>4 4 4 4 4 4 </vcount>
               

0 0 9 2 1 11 3 2 10 1 3 8 4 4 8 5 5 9 7 6 11 6 7 10 0 8 4 1 9 5 5 10 7 4 11 6 1 12 0 3 13 1 7 14 3 5 15 2 3 16 4 2 17 5 6 18 7 7 19 6 2 20 0 0 21 1 4 22 3 6 23 2 </p>
            </polylist>
         </mesh>
      </geometry>
   </library_geometries>
   <library_visual_scenes>
      <visual_scene id="unnamed_scene" name="unnamed_scene">
         <node id="Box01" sid="Box01" name="Box01">
            <translate>0 0 0 </translate>
            <node id="Box01_PIVOT" name="Box01_PIVOT">
               <translate>0 0 -0.5 </translate>
               <instance_geometry url="#Box01-obj">
                  <bind_material>
                     <technique_common>
                        <instance_material symbol="_01_-_Default" target="#_01_-_Default">
                           <bind semantic="CHANNEL1" target="#Box01-obj-mapchan-1"></bind>
                        </instance_material>
                     </technique_common>
                  </bind_material>
               </instance_geometry>
            </node>
         </node>
         <node id="global-ambient-light_scene-node" name="global-ambient-light_scene-node">
            <instance_light url="#global-ambient-light"></instance_light>
         </node>
      </visual_scene>
   </library_visual_scenes>
   <scene>
      <instance_visual_scene url="#unnamed_scene"></instance_visual_scene>
   </scene>
</COLLADA>

edit:
I also want to say that I realize that this is an XSI issue, but it seems that the XSI Collada support is a Collada intuitive more than a XSI imitative.

In addition is spent a considerable amount of time looking for some options or something to solve the problem, but if there is one it is not trivial.

was that the file exported from 3DSMax?
It isn’t correct. There are two things I noticed about it. One might be causing the problems.
First, Thats not triangles. You said that you exported it as triangles but I see a <polylist> where each polygon is a quad.
Second, The texturing is incorrect. I don’t know if that is why XSI doesn’t load the file, but it might be.

Actually I just tested that in XSI by hand editing the file to be correct and it still doesn’t work.

I don’t know what’s up with it. Best bet is to file the bug against XSI.

The corrected <effect> looks like this

<effect id="_01_-_Default-fx" name="_01_-_Default">
  <profile_COMMON>
    <newparam sid="surface">
      <surface type="2D">
        <init_from>Map__1</init_from>
      </surface>
    </newparam>
    <newparam sid="sampler">
      <sampler_2D>
        <source>surface</source>
      </sampler_2D>
    </newparam>
    <technique id="_01_-_Default-fx-COMMON" sid="COMMON">
      <phong>
        <ambient>
          <color>0.588235 0.588235 0.588235 1</color>
        </ambient>
        <diffuse>
          <texture texture="sampler" texcoord="CHANNEL1">
            <extra>
              <technique profile="MAX3D">
                <amount>1</amount>
              </technique>
            </extra>
          </texture>
        </diffuse>
        <specular>
          <color>0.9 0.9 0.9 1</color>
        </specular>
        <shininess>
          <float>10</float>
        </shininess>
        <reflective>
          <color>0 0 0 1</color>
        </reflective>
        <transparent>
          <color>1 1 1 1</color>
        </transparent>
        <transparency>
          <float>0</float>
        </transparency>
      </phong>
      <extra>
        <technique profile="MAX3D">
          <spec_level>
            <float>0</float>
          </spec_level>
          <emission_level>
            <float>0</float>
          </emission_level>
          <faceted>false</faceted>
          <double_sided>false</double_sided>
          <wireframe>false</wireframe>
          <face_map>false</face_map>
        </technique>
      </extra>
    </technique>
  </profile_COMMON>
</effect>

-Andy

The problem is in the normal array. The count is 108 and the accessor is 37, it should be 72 and the count in the accessor 24.

If you correct the count manually, it loads correctly.

The Collada coherency checker caught this.

What exported this file? If it was Max, can you describe how to get it to do it again?

Well thank you for taking the time analyzing my problem.
You are right the sample cube file is wrong. I do not own a copy of 3d studio max, I am using samples exported form Max with the collada 1.4 plug in.

The last cube was a model I asked a friend of mind to export so I can test again. I asked to make it triangle mesh but they do not like work with triangulated meshes, so he just exported the file without checking the triangle button in the plug in. I am sorry about that error. I did with more care again if you still want to take a look here is the file.
http://rapidshare.de/files/34180669/col … t.zip.html

This is a brief description:

There are two folders ColladaFromMax and ColladaFromMyTool with the exact same information:

In each one you will find a cube.dae and a Subaru.dae with the textures. Ther are triangulated meshes with a single texture, and single vertex
The vertex semantic is (postion, normal, texture coordenade)

These are my results on all files:

[ul]Result from ColladaFromMax (file expored from 3dsMax Collada plguin 1.4)
File------Myloader-coherency-FViewer-3dsMax-XSI—Blender
cube-----load------fail--------load-----load----load?–load
subaru—load------fail*-------load?----load----fail*–load?

Result from ColladaFromMyTool (files experted with the tool I am developing)
File------Myloader-coherency-FViewer-3dsMax-XSI—Blender
cube-----load------pass-------load-----load----fail*–load
subaru—load------pass-------load-----load----fail*–load?
[/ul]

  • = catastrofic failure
    ? = load geometry incorrectly

As you can see, if I am not mistaken or I am confused, in interpreting the
output of the coherencytest tool, the files I am producing comply more with collada scheme than any of the files generated from these plugins, but that does not thanslates to any gain since they cannot be transfered to other packages.
It is not my place to policy or judge these tools, but my finding
do not confirm what collada advertices. Not even at the lowest common denominator.

There is not way data can be transfered from package to package using collada tool provided with those packages. The only way this can be done is if you write a set of plugins yurself for each package, which is expensive, unpractical and sometime imposible (in the case of blender license). and if a comapany can do that then why does it needs collada for?
In my mind Collada was suppossed to standarize the prolifaration of file formats. but as it stand now it actually makes it worse since now you have file that are diffrent intenally but have the same format.
Not exacly what I would call “industry standard initialive”.

Thanks

Result from ColladaFromMax (file expored from 3dsMax Collada plguin 1.4)
File------Myloader-coherency-FViewer-3dsMax-XSI—Blender
cube-----load------fail--------load-----load----load?–load
subaru—load------fail*-------load?----load----fail*–load?

Looks like the current 3dsMax exporter has some issues, that the more and more restrictive coherency test is reporting. At least 3dsMax can load its file back! and I bet Maya has no problem with it at all.

Blender importer, even though currently still in alpha/development can load the file. XSI seems to have some problems. We are already aware of some issues with the XSI plug-in, and XSI has fixes for all of the issues that we know about, but for some reason they have not delivered those fixes to their customers yet.

So, this is quite good, the coherency test is really doing its job catching implementation issues, Even though the document is wrong the tools are still able to load the document (except in one case)

Result from ColladaFromMyTool (files experted with the tool I am developing)
File------Myloader-coherency-FViewer-3dsMax-XSI—Blender
cube-----load------pass-------load-----load----fail*–load
subaru—load------pass-------load-----load----fail*–load?

So all the tools, except XSI, can load the documents you created by your own method, simply following the specification.

This is really good, it works !

Testing Maya would really be interesting, it should work fine. Blender is interesting to add in the list, but not really fair since their exporter is not done yet.

You may have run into a new bug from the XSI importer, or hit one that has already been fixed. I suggest you contact them regarding this.

In summary, those results are really good,

  • One can write a import/export from scratch reading the specification and using the tool provided
  • The coherency and valiation tolls work, are tighter and tighter, and can detect problems with exporters/importers.
  • Even the Blender plug-in, that is work in progress seems to work quite well

Yes, it is not perfect, there are still some issues, but thanks to those reporting their problems with plug-ins and specification, COLLADA, although a very challenging proposal, is certainly the best “industry standard initialive” available.

Hi Julio,

I was just going over the files you uploaded and noticed something strange. In the <authoring_tool> section of your MAX files you have

3dsmax COLLADA exporter v2.10

Something is very wrong here, the Feeling Software COLLADA exporter for Max is currently at V1.05. As far as I know, there has never been a version 2.10.

This is what you should see in the authoring tool tag.

Feeling ColladaMax v1.05 with FCollada v1.13

It looks like you either have a very old script based COLLADA exporter installed, or maybe the Feeling ColladaMax wasn’t installed correctly. I’d suggest you get the latest ColladaMax V1.05 from www.feelingsoftware.com and try your tests again.

In the meantime, I’ll have a look at the files you exported from your tool and see why they wern’t loading into XSI

Greg

P.S. If you want to upload the .MAX binaries that you exported these from, I could try exporting them again here with the 1.05 plugin.

I do not own Max, people using me tools produced this file for me. I can ask them to send me the original files if you want.
However what I am interest it is in the files I am generating. The max files where just to verify that my files where not the only one failing to load in XSI, and Blender. Had I posted only my files I would not have any laborage on my claim.
I do own the budget version of XSI (which do not give me right to customer supports)

@remi
I respect what said but I not necessarily agree.
When I decided to use Collada it was because I though that the format was adopted by everybody. To make an analogy, jpg file can be loaded by any tool that loads jpg file, so you can generate images in that format and be sure that no one will have problems reading it, it is the same for file like 3ds, obj and other.
The problem with those formats is that they are limited, so it makes sense to have something more complete. For what I can see that is not the case with collada at least not yet.

I exported a cube from xsi in collada format, and to my surprise Max can load it, and I can load it, albeit incorrectly oriented.
When I looked at the text of the file I see what is going on, apparently XSI programmers decided that the collada commands are not good enough and they decided to make their own using the extra command over the entire file. Other packages do this too, but I do not think they expect that the information written inside extra command to be essential for reading the files back, XSI does.

For example XSI omit the statement up_axis, and instead they write their own command to specify the coordinate system, so if you load a file exported from XSI, the orientation of the file will be wrong because it is unlikely a plug it will know how to parse information extra blocks. Why not write the coordinate system according with collada guidance, and if you want you can write it in the extra as well?

An the reason I post about the XSI problems here is because it appear that the people making the plug-in are the same Collada contributor, and beside it is really depressing to post anything in the XSI forum, it is full of compiling about malfunction and false advertisement.
http://forum.softimage.com/topic.asp?TOPIC_ID=7493
since you are the person announcing the XSI plugging here, I thought that is was in the best interest of Collada and XSI that this things work as they are advertised.

Anyway I see that this discussion will not take me anywhere. For what I can see in the XSI forum they seem to have much bigger problems that this, so I decided I will write my own plug-in.
I did learn a lot from this, for example I can always check that my files are conformance by using the compatibility tool, instead of asking some one if they can be load it in Max, Blender or XSI. So as long as the files pass the test, then it is not my problems and I can say it is a Collida legitimate file.

Finally, I would like to suggest that for following Collada review the command extra should be removed altogether or at the very least it should enforce that the information written in the extra command should not affect the correct interpretation of the data in any way.
The command is been abused by almost everyone. It is possible to write an entire file inside of an extra command, and to me that is not standard.

Hi Julio,

I’m continuing to investigate this problem.

The main problem with XSI and Blender is that they aren’t supporting the texture->sampler->surface->image setup yet. They are still expecting texture to point directly to image as it did in older versions of COLLADA. You are doing things CORRECTLY and this causes their loader to fail. They are aware of this problem and working on fixing it.

After I fix this problem manually, the subaru loads ok in XSI but some geometry (the wheels) is missing. In blender the car loads ok but the materials do not come through. I’m not sure why but am trying to figure it out.

Looking at the subaru model in Maya and Max, there appears to be some odd geometry in it. On both sides of the car there appear to be several large triangles covering up a number of smaller and more detailed triangles that make up the doors. These large triangles appear to have normals that face inward, so when the car is drawn by a renderer that does backface culling you don’t see them. If you look closely from directly above the car, you can just barely see these triangles . The car also looks different when backface culling is switched on and off.

This extra geometry looks like it might be part of a simplified version of the car body, possibly a low level-of-detail model or a collision volume that may have gotten into the file by accident. Can you please check this and tell me if this extra geometry is supposed to be there?

Please try to be patient with COLLADA, we just went through some upgrades to the format and some people’s exporters haven’t caught up yet with the changes. People are working to fix this, but it is sometimes difficult to release updates as often as we would like because of the size of the tools.

The <extra> element is the standard mechanism to extend COLLADA with additional information. It’s certainly valid for Softimage to use it. Your point that <extra> data should not be essential information is a good one. Softimage should not require its <extra> data in order to interoperate with other tools when exchanging data that has common or core element representations.

The <up_axis> element is optional but it does have default values. So it is never undefined and its default value is Y_UP. If XSI is exporting <extra> data that contradicts the explicit or default value of <up_axis> then it is a bug for the XSI exporter, not the other importers.

I agree with that sentiment and it would be a bug if the two pieces of information did not agree with each other since the <up_axis> value is definitive.

COLLADA needs to be extensible to address a wide domain of users and so the <extra> element (and the <technique> elements) are important features of the schema. For some users it’s a vitally important feature. Yes it’s true that the information within the <extra> is not standard at least in the sense that every implementation needs to parse it. Some users don’t want all of their data to be exchangable and they are entitled to do that.

COLLADA supports common (and core) techniques for data representation as well as custom extensions so that everyone can adopt COLLADA for their needs. I hope you can understand our position on that topic and help users gain quality implementations of COLLADA for interchange of common and custom data by all users.

You are right in the coordinate system, in XSI match the default of collada. I was in error but setting my conversion matrix to identity, and do considering that default is equivalent to y up, x to the right and z to the front.
About the black polygons, I do not know why they look like that is soft image; the file is a public domain in 3ds format. When I loader it with my crapy parcel is looks fine, it is also looks fine if it is loaded in Max.

Any way I did not want to offend you about the extra command in collada, I was emitting my ignorance opinion, I am sure there must be powerful reasons for that functionality and I just to not understand the bigger picture. I guess hat the rest of the problems are on my side.

The main problem with XSI and Blender is that they aren’t supporting the texture->sampler->surface->image setup yet. They are still expecting texture to point directly to image as it did in older versions of COLLADA. You are doing things CORRECTLY and this causes their loader to fail. They are aware of this problem and working on fixing it.

Thank you for let me know that part for problem is in the way the texture sampler is suppose to be written for blender and xsi. I hate to have to go thought file samples to write my exporter, but I suppose I could do that temporarily so I can load all my files the to XSI and save them in native SXI format.

Thank you for the help.

I brought up this same topic of compatibility between tools recently, especially when using them for COLLADA Physics. Although similar, don’t confuse this with formal conformance tests: this practical compatibility includes tools that might not be tested for conformance by Khronos, like CreateDynamics. Such tools are too useful to ignore.

As a result, I am trying to fill a COLLADA Physics Compatibility Matrix, which includes tools like ColladaMaya, ColladaMax, XSI, Blender, CreateDynamics, FeelingViewer and Bullet physics viewer.

Unfortunatley ColladaMax and XSI don’t seem to include any COLLADA Physics information, but they can still provide static geometry.

Julio: will your tool be available?

Just to make sure it’s clear, the texture->sampler->surface->image method (the way you are doing it now) is CORRECT.

The texture->image method is INCORRECT in COLLADA 1.4.1. The Blender and XSI importers only know how to read textures this way, but eventually they will fix this.

I am still trying to figure out why the wheels don’t load correctly in XSI. I’ve forwarded your sample to the XSI developers and am waiting for their feedback.

Julio,

There do seem to be a few things in the subaru model that are strange. None of these things explain the problems we are seeing in XSI or Blender, I am still trying to find those.

There seems to be a lot of geometry with inward facing normals. It’s like a second, but simplified version of the car body.

In most places polygons don’t seem to be sharing vertices. This should not cause problems but it does make editing the model more difficult because the polygons don’t form a continuous surface. This also wastes space in the file. For example the first two vertex in your “chassis_position-array” are repeated 5 times.

The .tga files have an alpha channel but it’s blank (shouldn’t cause problems).

Hi Julio,

I’ve took a look at the Subaru model and as Greg pointed out to me, the fact that the :

  <input semantic="NORMAL" source="#tire05_normal"/>
  <input semantic="TEXCOORD" source="#tire05_UV"/>

are under the and not under the is what causes our importer to crash. It crash when it tries to import the car normal and UV so that’s why only the car triangles get imported (no wheels).

The normal value and texture coordinate values are assumed to be per triangle values so that’s why they should be found under and not under . In other words, for the same vertex being part of two different triangles you can have two different normal or UV value, one for each triangle.

Our importer detects the position, normal and UV array elements and, from them, it expects to find a match of source id as an input under the tag. We could be more robust and just skip the array for which we don’t find a match but unfortunately we don’t test for NULL in that occasion and it crashes. If you remove the normal and UV + their corresponding currently under the file will load fine.

To make the XSI COLLADA more robust you can fix the dotXSIConverter plugin that you can find in your XSI SDK installation:

XSISDK\examples\workgroup\Addons\dotXSIConverter\src\cnv_mesh_clusterprop.cpp

Replace the line 340:

int* l_pFTKTriangleListIndices = l_pFTKTriangleList->GetAttributeByName(l_pAttribute->GetName())->ArrayPtr();

with this:

CSLArrayProxy<SI_Int, SI_Int,1>* l_pAttrib = l_pFTKTriangleList->GetAttributeByName (l_pAttribute->GetName());

if ( l_pAttrib == NULL )
break;

int* l_pFTKTriangleListIndices = l_pAttrib->ArrayPtr();

and recompile the plugin.

Also, as Greg and you figured out, regarding the texture > sampler > source > image issue, this is due to the fact that we currently support COLLADA 1.4.0 only. So, as a general note, make sure you either use other application 1.4.0 version of exporters or export 1.4.0 format with your tool if you want to import those file in XSI right now.

Thanks a lot for helping making our tool more robust by submitting the issues you’re having with them.

LB

Would not that be a bug in the XSI collada importer?
If you read the specification, the geometry commands allows for building any type of vertex format. Not assumption should be made of the expected vertex format, everything must be specified with the Vertex and polygon semantics.
The vertex format in the Subaru and the entire model I am saving is not an accident they are delivered made like that.
There are optimized for rending in a single batch per material type with libraries like OpenGL or DirectX. The vertices are flattened in such way that each vertex can be addressed with one index. There is no redundant vertex, each one has at least one value that is different, be a texture value, a normal value, or a position value.

I understand that a vertx format where each stream has a set of indices is better for editing geometry, but it is not better for rendering, and since my tool is not a modeling package instead it is a simplified viewer this format is better for me. However My tool still can read other combinations of vertex formats.

There is nothing wrong with my selection in fact it is conceivable to make for example. Position with independent indices and pack together the normal and textures with a single set of indices, which is another format I was considering.

Would the change to the SXINet converters fix the problem with the Collada importer?

About the Subaru model, I would not put too much thought into it since it is a free model and even in the original 3ds model you can see estrange faces, however that does nto explain the crashing.

I was loading (and also leaning how to use SXI) one of my own models to use as control for my test instead of the Subaru. I loaded in SXI in direct X format, and after some editing to make look like it is suppose to, now I can exported and ready it with my tool in collada format.

It can be read it with FreeCollada viewer and my tool properly oriented and without errors, but I cannot load any of the collada files I produce into XSI. I have not tried with other packages. I can post that file if you want to test (it is much simple and cleaner)

Anyway it is not that important anyway, I was frustrated because I had some files in a collada format that I could not load in XSI. So I had to convert then to some other format (directX) load them and do a considerably amount of editing that considered unnecessary.
After playing with XSI and exporing some files I see that they are not what I was expecting, XSI adds lots of extra information to the file (extra null, nodes, light, scene setting and other things that I do not know what they are)
So I decided that the best option for me if to take on of the converters demos and adapted to my own mini collada expert/importer.