I have an array of 3D models originally created using Openflight (.flt). Using Open Scene Graph I changed the format of these models to Collada (.dae). The models followed the Collada 1.4.1 format (as far as I know). After changing their format they were then dragged and dropped into Google Earth.
I’ve tried to upload these models to the 3D warehouse, but i receive the error: “Invalid Collada file. The uploaded file must follow either the Collada 1.4.1 or Collada 1.5.1 schema specified at http://www.khronos.org/collada/”
I’ve tried looking at the Collada 1.4.1 Schema, and the Schema of the models I have. To be honest, I cannot tell heads or tails of it all. What language it’s in…etc. Is there an easy fix to this? I’ve tried saving it (the scene as far as I know) into a KMZ file, but I receive a different error: “(Shaefer.kmz) KMZ contains an unrecognized file type” (Shaefer is the name of the model).
The 1.5.1 is something google tossed at me. I think there might be something wrong with their submission process…but i’ve yet to determine that. I’ll need a collada model that passes the coherency test first.
I’ve tried running the collada coherency test on my model…and I got nothing but massive failures.
CHECK_count Failed (type=source,id=p1137_4-texcoord_0)stride count != number of param elementsCHECK_count
Failed (type=source,id=p195_4-texcoord_0)stride count != number of param elementsCHECK_count
Failed (type=source,id=p19_58-texcoord_0)stride count != number of param elementsCHECK_count
Failed (type=source,id=p21_24-texcoord_0)stride count != number of param elementsCHECK_count
Failed (type=source,id=p21_27-texcoord_0)stride count != number of param elementsCHECK_count
Failed (type=source,id=p23_10-texcoord_0)stride count != number of param elementsCHECK_count
Failed (type=source,id=p27_4-texcoord_0)stride count != number of param elementsCHECK_count
Failed (type=source,id=p381_4-texcoord_0)stride count != number of param elementsCHECK_count
Failed (type=source,id=p41_4-texcoord_0)stride count != number of param elementsCHECK_count
Failed (type=source,id=p429_9-texcoord_0)stride count != number of param elementsCHECK_count
Failed (type=source,id=p42_4-texcoord_0)stride count != number of param elementsCHECK_count
Failed (type=source,id=p451_7-texcoord_0)stride count != number of param elementsCHECK_count
Failed (type=source,id=p46_4-texcoord_0)stride count != number of param elementsCHECK_count
Failed (type=source,id=p52_4-texcoord_0)stride count != number of param elementsCHECK_count
Failed (type=source,id=p57_8-texcoord_0)stride count != number of param elementsCHECK_count
Failed (type=source,id=p65_4-texcoord_0)stride count != number of param elementsCHECK_count
Failed (type=source,id=p74_26-texcoord_0)stride count != number of param elementsCHECK_count
Failed (type=source,id=p74_30-texcoord_0)stride count !=number of param elements
All the arrays names …texcoord_0 are boggus. They all contain Zero elements.
All the geometry seem to want to have 2 texcoord per vertex (texcoord_0 and texcoord_1) but only the texcoord_1 is valid.
Materials all reference the texcoord_0, I did not see any reference to texcoord_1 in the file.
Looks like a bug in the exporter for sure.
You can fix manually those files by:
removing all the …texcoord_0 sources <source> … </source>
removing reference to this array <input offset=“3” …/>
changing the instance material to use the 2nd texcoords instead of the boggus one
<bind_vertex_input semantic=“texcoord0” input_semantic=“TEXCOORD” input_set=“0”/>
replace with
<bind_vertex_input semantic=“texcoord0” input_semantic=“TEXCOORD” input_set=“1”/>
Would be better to fix OSG, which is obviously confused when only one texcoord is valid.
Note: If the google earth loader is correctly written it will ignore all the indices for offset=“3”
If the loader is boggus, then you have to:
rename <input offset=“4”> into <input offset=“3”>
Remove every 5th element of the
And when you say - removing reference to this array <input offset=“3” …/> You mean remove all of: <input offset=“3” semantic=“TEXCOORD” source="#p21_27-texcoord_0" set=“0”/>
The last step isn’t that big of a concern. It would be much better to fix OSG…but i’m trying to see what step would be better? I mean…just getting rid of certain things…doesn’t seem all that bad if it’s all the same.
The model turns white. As in removie all of these source id’s, removes the refernces to all of the sides of the model. I don’t think these are all bogus…
yes, if you remove the accessor for textcoord the model would have no material.
What I suggested is to look for the <source> in the document that contains no data and get rid of those sources, and remap the accessor to use the sources to the ones that have the UV coordinate.
Additionaly, you can get rid of all the ‘set=’ since there is only one set of texcoord per vertex
Regards
BTW, you defiintly have to open a bug to the OSG community if you want this fixed. Please add a link to the bug you are opening into this thread for reference
Under option strings for collada, there appears to be a “GoogleMode” for the collada writer. It apparently makes objects suitable for use in Google. Thing is, I don’t exactly know how to access that option. I’m not terribly skilled at programming, but I’m assuming that to use this option, I would have to use Eclipse (the compiler I used to build osg).
Unless someone has changed it recently the GoogleMode flag for the OSG Collada exporter only effects the handling of transparency, so it will have no effect on your problem.
I’m pretty hopeless when it comes to coding in Collada. I’ve tried using the coherency test, and at times, it would just return no results. I have no idea how to use it. Is there any documentation (besides the read me) out there that could help?
I also have a problem with coding: I’m bad at it. Just to say…i’m outright lost when it comes to interacting with XML. Can someone find/recommend a crash course? As any one can read from before, I don’t exactly have the best understanding of my models, and the errors they carry. I thank everyone for the help and suggestions they’ve given thus far…but i’m hoping for maybe an explanation for a programming idiot.
As it turns out, the problem lies with the textures referenced. After I got someone else to look at the models with the coherency test, there was only a simple issue with the rgb textures produced/referenced by the openflight models. When converted over into collada, they still retain the rgb reference…so the solution is simple: change the format of the texture, and in the collada file change the rgb to jpg. An example can be:
<init_from>monty_back_inside.rgb</init_from>
changes to
<init_from>monty_back_inside.jpg</init_from>
After that, my models are accepted by google’s submission process.
However…there has been a new issue. Is there a modelling software out there that allows me to successfully import/modify collada/kmz models?