Collada Models in Google Earth

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).

Try running the COLLADA Coherency Checker on your file?

What produced the “1.5.1” message? There is no such version.

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

How would I go about correcting these errors?

Can you provide more details about the OSG version you are using?

Can you attach a .dae file exported from your OSG program that you are trying to validate?

Unfortunately the extension .dae is not allowed to be posted on here for some reason. But I posted it here:

http://rapidshare.com/files/244289716/smp_schafer6.dae

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

array in the <triangles>

Good luck

Fixed permissions.

Well. I already have a question.
When you say “removing all the …texcoord_0 sources <source> … </source>” you mean remove all of:

<source id=“p19_58-texcoord_0”>
<float_array id=“p19_58-texcoord_0-array” count=“0”/>
<technique_common>
<accessor count=“0” source="#p19_58-texcoord_0-array" stride=“0”>
<param name=“S” type=“float”/>
<param name=“T” type=“float”/>
</accessor>
</technique_common>
</source>

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.

Ok. Everytime I try and modify the xml document…i.e. remove every instance of the:

<source id=“p451_7-texcoord_0”>
<float_array id=“p451_7-texcoord_0-array” count=“0”/>
<technique_common>
<accessor count=“0” source="#p451_7-texcoord_0-array" stride=“0”>
<param name=“S” type=“float”/>
<param name=“T” type=“float”/>
</accessor>
</technique_common>
</source>

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…

-Adam

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

Marcus,
File attachement does not work for me, it says file does not exist when I click on the link.

– Remi

Works for me. I see the file has been downloaded 3 times now.

I think I may have found something interesting in terms of solving my problem. I’ve yet to try it…but it seems interesting.

http://www.openscenegraph.org/projects/ … se/Collada

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).

I also posted the bug on the OSG forums.

http://forum.openscenegraph.org/viewtopic.php?t=2932

The OSG tools can pass options to plug-ins. See the “-O” option documentation for usage.

http://www.openscenegraph.org/projects/ … /osgviewer
http://www.openscenegraph.org/projects/ … es/osgconv

<bind_vertex_input semantic=“texcoord0”
input_semantic=“TEXCOORD” input_set=“0”/>

is this an example of the texcoord0 not having any data?

That piece of COLLADA XML says to bind a certain set of texture coordinates from the geometry to the effect/shader semantic.

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.

Roger

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?