Imcompatibility across different packages

Julio, you can still do unified indicies (i.e. all parts of each vertex use a single index) even if you move the normal and tex coord inputs out from <vertices> and into <triangles>. You just need to set each offset to be the same. It would look like this:

<vertices id="myVertices">
    <input semantic="POSITION" source="..."/>
</vertices>
<triangles count="2" material="...">
    <input offset="0" semantic="VERTEX" source="#myVertices">
    <input offset="0" semantic="NORMAL" source="#myNormals">
    <input offset="0" semantic="TEXCOORD" source="#myTexCoords">
    

0 1 2 3 4 5</p>
</triangles>

Each value in

is used as the index for the position, normal, and tex coord. When importing, you can quickly detect if you have unified indices by seeing if all the offset values are the same (as in the above case).

The problem the XSI importer is having is that you have the <input>s for normals and tex coords in <vertices> instead of <triangles>. The convention for Collada is that only the position input goes in <vertices>, and everything else goes directly in the <triangles> element. However I think what you’re doing is still technically legal according to the spec/schema, it’s just not conventional. Hopefully XSI fixes their importer to handle this case. But still, if you move the <input>s for normals and tex coords to the <triangles> element your Collada models will work better across more tools and modeling packages.

I will try your suggestion, It is my interest that I can load the file in as may tool as possible.
Can you please write a complete sample of geometry, say a simple quad that shares one edge with planar texture coordinate?

It is not clear to me where the values for the normal’s and the u and v ought to be placed (the triangle of the vertex) or maybe the vertex and a url in the triangles.

I’d rather convert my files in a batch process than loading then in direct X mode and edit them

also notice that in the mode I am using there is a vertex array and more than one triangle set pointing to teh same vertices. How can this be done of I have to place the normals and texture coordenade with the triangles.

Here’s a full example that should help:


<source id="positions">
    ...
</source>


<source id="normals">
    ...
</source>


<source id="texcoords">
    ...
</source>


<vertices id="verts">
    <input semantic="POSITION" source="#positions"/>
    
</vertices>


<triangles count="10" material="someMaterial">
    <input offset="0" semantic="VERTEX" source="#verts"/>
    <input offset="0" semantic="NORMAL" source="#normals"/>
    <input offset="0" semantic="TEXCOORD" source="#texcoords"/>
    

...</p>
</triangles>


<triangles count="50" material="someOtherMaterial">
    <input offset="0" semantic="VERTEX" source="#verts"/>
    <input offset="0" semantic="NORMAL" source="#normals"/>
    <input offset="0" semantic="TEXCOORD" source="#texcoords"/>
    

...</p>
</triangles>

[ul][]All the vertex data is shared between the two <triangles> elements.[/:m:3f46sogb][]Both <triangles> elements use unified indices for the position, normal, and tex coord (which you can verify by seeing that the offset values are all 0).[/:m:3f46sogb][]Since the <input> elements for the normals and tex coords are placed directly in the <triangles> elements, this data conforms to Collada conventions and will probably be loaded more easily in other tools, e.g. SoftImage.[/:m:3f46sogb][/ul]

COLLADA really doesn’t suggest one way of organizing inputs over the other. I am actually really upset to hear that some implementations still can’t read multiple inputs in the <vertices> tag.

What Julio is doing is completely legit. Its just by practice that most implementations arrange the file the other way around. Yes, putting inputs in the primitive group gives you more flexibility since you can have per primitive vertex attributes, but in Julio’s case he doesn’t need that. In his case putting inputs in the primitive groups actually just bloats the file (albeit not by an amount anyone cares about). But for every primitive group he has in a geometry after the first one he adds about 150 bytes of redundant data.

Julio, when is your prodect release window. I feel that often times people are developing and they are changing their implementations based on other implementations now. But if your product isn’t going to be released for another 3-6 months, by then the XSI bug will be fixed. And if it isn’t having another userbase to pressure XSI to getting it fixed would really help the community.

-Andy

To lbolduc, julio and sthomas…essentially you are ALL right.

First off it’s perfectly legal to have a <vertices> tag contain POSITION, NORMAL, TEXCOORD or whatever other input semantics you need. This is useful if you want to be able to load stuff directly into a GL vertex array where you only want to have one index per vertex to deal with. The disadvantage to this approach, like lbolduc mentioned, is that you can’t re-use the same position with different normals or different UV values. This can lead to the need to store the same POSITION, NORMAL or TEXCOORD more than once. Unshared vertices can also cause problems with some modeling tools…for example with the subaru model, if you want to deform the windshield and select one vertex and pull on it, it moves only one triangle because the vertex isn’t shared with the other adjacent triangles. The lack of sharing can cause problems with other modeling tools for fixing normals, smoothing…etc.

But this approach, IS CORRECT and the bug is in the XSI importer for not being able to read it.

sthomas is ALSO correct, you can do the exact same thing by putting the inputs in the <triangles> and giving them all the same offset. This has pretty much the same disadvantages as the above approach. But some importers might have an easier time reading this.

And finally lbolduc is ALSO correct, you can have normals, UVs and other stuff as seperate inputs and offsets in a <triangles>. This lets you share common normals, UVs and other info between vertices. This format is the best for use with modeling tools because it preserves sharing of vertex information which a lot of fancy modeling/sculpting tools need. It also cuts down the number of bytes in the file and in-memory needed to represent the model.

If you are writing tool intended to output models that will later be used in a modeling tool like XSI or Maya, I would recommend using the third approach above.

If you are writing a rendering tool, or a tool that is optimizing COLLADA files for easy/fast loading into a rendering tool, one of the other approaches might be preferable.

Note that in the COLLADA_DOM sourceforge, we have a “conditioner” example called “deindexer” that converts COLLADA data to a format where all the indexes for a vertex are the same. This was written to create documents that could be loaded into vertex arrays directly. This conditioner can be run on a file, or can be called against a DOM you have loaded in memory to convert it in place.

I believe the COLLADA RT viewer currently calls this conditioner internally to put data into vertex-array-friendly form.

I’m sorry you’ve had these problems, COLLADA is a realtively large spec and some implementers have failed to support some of the less common cases in their import/export software. This is something we’re working very hard to fix and your input has been very helpful. It’s already resulted in bugs being filed against a number of importers to get things fixed.

Hi.

Yes, the fact that XSI does not support the polynode attribute information specified under the <vertices> tag is a bug. I will log this issue.

Regarding your question Julio:

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

The latest update available on the www.softimage.com / XSINet download section address the following issue:

  • 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:///

so, the answer is no, it does not address the polynode attribute specified under the <vertices> tag issue.

I made the suggested modifications (vertex format defined in the polygon/triangle tag and removed the texture sampler indirection) and I was able to load a simple cube into xsi.
I have not done anymore test with more elaborated models yet, I will do it this weekend while practicing XSI interface more.

About the geometry format in Collada I did not mean to open a can of worms, I am sorry about that. But I still have one comment and one suggestion.

About the vertex format written with unified index. What you are saying is indeed true, but some time just because something is truth is does not mean that is the more convenience way for doing things. I can see how sharing normals and texture coordinate is a win with low detail geometry, (crates and low poly models) however as the geometry became more complex the level of sharing of normals and texture coord start to approach 1.0 efficiency asymptotically.
Take for example a simple box you have 8 vertices and 6 normal’s, an maybe lot of uvs,
If you take the same box and apply a subdivision, or a bevel command, the same model approached 1 normal per vertex and the also almost 1 uv per vertex because most texture unwrapping algorithm are designed to work that way.
So the saving claimed by reusing position, normal and UV is very marginal even for medium side geometry.
I believe this is one of the reason API like Direct X an OGL do not bother to implement that kind of support.

The suggestion is that maybe what is not sufficient it the format of the geometry tag. The format in the way it is specified cannot support both optimized for efficiency rendering and optimized for editing simultaneously.
However if the geometry tag also supported complete simplex, (edge list or graph) then any api can easily queries the data in the format that it desired, separate or unified index, triangle strips, triangle list optimized for locality, general polygon and even concave faces could be decomposed in linear time. Any one and more of this operation can be done in linear time for a well-designed data structure (something better than a wind edge).
As it is now it is very hard and time consuming to convert these vertex list index list to any other format, so if you are using collada you are stuck with inferior data format that will be used as the last alternative not as the preffer choice for data transfer. That in the long run will always make Collada file inferior to any native format used by any package.
When I came to Collada it was assuming that this was maybe a standard functionality on the format.
This is the format I used for years in my own stuff and never had problem with it.
This is just an idea in case any one wants to take it.

Ok I will continue my test and let you know if I encounter any more problems. But I believe that these were all of them.

Thank very much for the recommendations. I will add and option to the exported to have both modes.

Just to be clear, all of the approaches I talked about are correct COLLADA including the <vertex> with a unified index like you originally used. Which one is best for your application is your choice, none of the approaches are “more correct” than any other and importers (particularly ones for general purpose modeling tools) should really support them all.

As far as the complexity this implies, keep in mind that COLLADA is intended to be a format for exchanging data, it’s not ment to be the kind of high-performance fast-loading format that would be used by a game engine like Unreal at runtime.

The point of COLLADA is to be able to represent any kind of information a toolchain might need exchange…that’s why there are so many options and different ways to represent data.

Ok I run some more experiments and things seem to be better. :slight_smile:
I made the following modification to my importer/exporter

1- I am naming the Texture sampler on the effect tag the same way as the Texture Image name, this trick will make it work fine for collada 1.41.1 and 1.4.0 since the sampler is just one more level of indirection that tell the loader what properties apply to the texture. This does not created any clash because even if an effect have more than one sampler parameter, each sampler have to point to a unique texture, and textures can not be duplicated.
2-I made the geometry like you guys said, by defining the vertex format in the polygon. And setting the offsets to zero. To determine if the vertex is unified I added an extra tag to the geometry that tell my loader if the mesh can be render in one bash.

Here are tfour samples I am using for testing, if you want to check it out.

http://rapidshare.de/files/35047536/col … t.zip.html

a)the cube used as my control model
b)a simple formula one model in a simple hierarchy (to replace the Subaru)
c)a dirt tractor is much more complex hierarchy.
d)A giant robot (I model after a plastic model for XSI practice, still do not know wow to texture very well)

All the models load correctly in XSI, in my viewer, in MAX, and in Feeling Collada Viewer. The collada feeling viewer they do not show the textures, but I think it is because I do not know how to make it show in the program.

I think that you are right and it is not really important to support complex vertex formats in the vertices tag of teh mesh, but I think there are still few problems that if fixed or improved will make it more compatible.
These happen with Files exported from XSI.

The first one is that XSI write the vertex format in the polygon and that is fine, however it does not write the format completely. So when you try to load the file with other packages the models come out incomplete.
This is what the documentation say abut the input tag

“ 4-32 COLLADA – Digital Asset Schema Release 1.4.1
set =
Which inputs should be grouped together as a single set. This is helpful
when multiple inputs share the same semantics. Optional if <input> is
a child of a Group B parent; not valid for Group A parents.”

To me that means that if you have more that one set of fields in a vertex you must identify then with the set member of the input tag, SXI leave dos not even write the field value.

Here is what SXI writes for a simple cube

<triangles count="12" material="Library.Material_2">
  <input semantic="VERTEX" source="#geometries_0-Vtx" offset="0"/>
  <input semantic="NORMAL" source="#geometries_0-ImplicitNormal" offset="1"/>
  <input semantic="NORMAL" source="#geometries_0-NORMAL" offset="2"/>
  <input semantic="TEXCOORD" source="#geometries_0-TEXCOORD" offset="3"/>

This is how I am writing it

<triangles material="Material_2" count="12">
   <input semantic="VERTEX" source="#Box01-vertices" offset="0"/>
   <input semantic="NORMAL" source="#Box01_normal" offset="0"/>
   <input semantic="TEXCOORD" source="#Box01_UV" offset="0" set="1"/>

If I edit the file exported by SXI by adding the set = “1” then they load fine in Max and Feeling Collada

The other problem is that I do not think XSI obey the up axis Tag,
If I export my file with the z axis up when I load it in XSI it should come upright, but is does not, In my opinion the axis tag is there to tell the loader how to orient the data.
The feeling viewer I think it does that properly, mine does too, but Max and XSI totally ignore that coordinates system just like XSI.
It would be nice if at lease one of the mayor package did it right, it is not that complex.

In the samples I saved the f1 model with the Z axis up like it is done in Maya and Max by default, it you load that model in XSI you will see that it comes with the front pointing up. If you load it in Maya or MAX it is right.
If you save the model from SXI and you load it in Maya or Max it will come incorrect (that a problem in both those packages, I think)
The feeling viewer load all kind of orientation correctly.
I think that all exporter should abide by the rules if you people want to have truly file sharing standard.

Finally I think XSI is very good, and the Collada plug in is not as bad I first thought. :smiley:

Blender is the only package that does not loads any of the files correctly in any way. :cry: :?

Actually… thank you for highlighting the issues! :slight_smile: