KMZ are not yet compliant (was:FCollada Image url issues)


I’ve been implementing Collada loading in our engine and so far haven’t had any problems, and have found it very easy to use.

I have found that some models seem to break FCollada however, I have been testing loading using models off of Google’s 3D warehouse. A good number been fine but some refuse to work properly.

When I attempt to load the DAE from this file … 34ab70b971
(the google earth 4 file, a kmz file is simply a zip file, the dae is in the models directory) the geometry loads fine however when I request any of the images from the FCDTexture’s it returns a null pointer.

FCDTexture* texture = effect->GetTexture(FUDaeTextureChannel::DIFFUSE, 0);
	Image* newTexture = new Image;
	Url url;
	FCDImage* image = texture->GetImage();
		url.set((char *)image->GetFilename().c_str());
		newTexture->url = url;
		appearance->texture = newTexture;
		delete newTexture;

On the line

FCDImage* image = texture->GetImage();

I get returned a NULL instead of a url to the image. This doesn’t happen with all files and in some it only partially happens such as this one: … 1cc3602a85

I’m really scratching my head on this one, as these files load in Google Earth i know that they should work. But something about them kills FCollada :cry:

Please open an issue on our public Bugzilla and we’ll look at it before the next release of FCollada.


There is a kmz clean-up conditioner released in the COLLADA DOM source forge web site. It tries to make the dae document in KMZ package compliant with COLLADA specification 1.4.1. If you are interested, you can download it and see whether it helps to solve your problem. The instruction is in the readme file. If you have any questions or feedbacks, please let me know.


Bah I hoped kmz was compliant with the specification. I thought it might have just been my bad programming :stuck_out_tongue: Unfortunately conditioning the kmz isn’t really an option as I am loading the originals straight from the 3d warehouse on google’s website.

Is there a way to get FCollada to work around this issue addressed in the conditioner as it seems to be the major problem:

Change the ids/names of image/material/effect which start with a numeric number to not start with it

In FCDObjectWithId, we pre-process the IDs, before accepting them. So we’re most likely already removing the numeric numbers and that could be what’s causing the issue: I don’t believe we process the ids before attempting to resolve them.

Instead, you could modify the code that checks the ids for conformance and allow more characters: “FUDaeWriter::CleanId”. Another quick fix would be to take out the call to FUDaeWriter::CleanId in FCDObjectWithID::SetId.

Unfortunately they are not.

Well the files on the 3D warehouse are technically broken. The ID datatype is defined by the XML Schema Language and so this error is a fundamental one going beyond COLLADA itself.

Since it is very early in Google’s release of the SketchUp beta, I think that everyone should demand that Google fix their tools and their content as quickly as they can.

I added numbers to the allowable first characters in FUDaeWriter::CleanId and this fixed the problem. I’m going to have to ponder on what a permanent solution will be, perhaps instead of replacing the first character of an id with an underscore it could be inserted at the front of the offending ids?

I’ve yet to encounter problems with any of the other issues with non conforming kmzs but i expect I shall!

I’m going to have to ponder on what a permanent solution will be

The permanent solution is for SketchUp to fix this problem. They are aware of all the compliance problems, and are working on it.

Please realize that this change violates the COLLADA schema. I understand it is a work around for broken files. I ask that your software issue a warning message as a debugging aid to your users.

Sure do and sure have :slight_smile:

Yeah, though unfortunetly there is going to a LOT of files in the 3D warehouse that aren’t going to be compliant, which is a pain as I have to be compatible with all of them!

I was thinking that instead of getting FCollada to replace the offending first character with a _ it could instead add the _ to the front instead. The sid would stay unique and would become compliant. Is this a more acceptable?