Results 1 to 10 of 10

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

  1. #1
    Junior Member
    Join Date
    Aug 2005
    Location
    Melbourne, Australia
    Posts
    11

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

    Hi,

    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 http://sketchup.google.com/3dwarehouse/ ... 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.
    Code :
    FCDTexture* texture = effect->GetTexture(FUDaeTextureChannel::DIFFUSE, 0);
    if(texture)
    {
    	Image* newTexture = new Image;
    	Url url;
    	FCDImage* image = texture->GetImage();
    	if(image)
    	{
    		url.set((char *)image->GetFilename().c_str());
    		newTexture->url = url;
    		appearance->texture = newTexture;
    	}
    	else
    		delete newTexture;
    }

    On the line
    Code :
    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:
    http://sketchup.google.com/3dwarehouse/ ... 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

  2. #2
    Senior Member
    Join Date
    Apr 2005
    Location
    Feeling Software, Montreal, Quebec
    Posts
    111
    Please open an issue on our public Bugzilla and we'll look at it before the next release of FCollada.

    http://www.feelingsoftware.com/bugzilla

    Sincerely,
    Guillaume Laforte
    Feeling Software Inc
    http://www.feelingsoftware.com

  3. #3
    lliu
    Guest
    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.

    Thanks.
    Ling

  4. #4
    Junior Member
    Join Date
    Aug 2005
    Location
    Melbourne, Australia
    Posts
    11
    Bah I hoped kmz was compliant with the specification. I thought it might have just been my bad programming :P 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

  5. #5
    Senior Member
    Join Date
    Apr 2005
    Location
    Feeling Software, Montreal, Quebec
    Posts
    111
    Quote Originally Posted by hartror
    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.
    Guillaume Laforte
    Feeling Software Inc
    http://www.feelingsoftware.com

  6. #6
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771
    Quote Originally Posted by hartror
    Bah I hoped kmz was compliant with the specification.
    Unfortunately they are not.
    Quote Originally Posted by hartror
    Unfortunately conditioning the kmz isn't really an option as I am loading the originals straight from the 3d warehouse on google's website.
    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.

  7. #7
    Junior Member
    Join Date
    Aug 2005
    Location
    Melbourne, Australia
    Posts
    11
    Quote Originally Posted by glaforte
    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.
    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!

  8. #8
    Senior Member
    Join Date
    Jul 2004
    Location
    Santa Clara
    Posts
    356
    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.

  9. #9
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771
    Quote Originally Posted by hartror
    I added numbers to the allowable first characters in FUDaeWriter::CleanId and this fixed the problem.
    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.

  10. #10
    Junior Member
    Join Date
    Aug 2005
    Location
    Melbourne, Australia
    Posts
    11
    Quote Originally Posted by marcus
    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

    Quote Originally Posted by remi
    The permanent solution is for SketchUp to fix this problem. They are aware of all the compliance problems, and are working on it.
    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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •