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.
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)
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.
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.
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.Originally Posted by Julio Jerez
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.Originally Posted by Julio Jerez
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.Originally Posted by Julio Jerez
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.Originally Posted by Julio Jerez
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.
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.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 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.Originally Posted by Julio Jerez
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.
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).
I've took a look at the Subaru model and as Greg pointed out to me, the fact that the :
Code :<input semantic="NORMAL" source="#tire05_normal"/> <input semantic="TEXCOORD" source="#tire05_UV"/>
are under the <vertices> and not under the <triangles> 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 <triangles> and not under <vertices>. 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 <source> array elements and, from them, it expects to find a match of source id as an input under the <triangles> 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 <source> + their corresponding <input> currently under <vertecies> 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:
Replace the line 340:
Code :int* l_pFTKTriangleListIndices = l_pFTKTriangleList->GetAttributeByName(l_pAttribute->GetName())->ArrayPtr();
Code :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.
Would not that be a bug in the XSI collada importer?Originally Posted by lbolduc
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.