Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: DOM vs DAE (1.4)

  1. #1
    Junior Member
    Join Date
    May 2007
    Posts
    9

    DOM vs DAE (1.4)

    I have the following code that return's two different vaules

    input->getDatabase()->getElementCount(0, COLLADA_ELEMENT_GEOMETRY, 0)

    Correctly returns 1

    dom->getLibrary_geometries_array().getCount()

    Incorrectly return 0. Stepping into the code the geomtry array clearly has a _value of 1.

    The DOM version returns size_t which I think might be causing the problem?

    In addition why is there two ways to get the geometry count and which one should I use? The collade book uses the first way but the RT uses the second.

    Thanks

    David.

  2. #2
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    Hi, actually in those two function calls you're asking about different elements. In the first call you're asking how many <geometry> elements there are, and in the second case you're asking how many <library_geometries> there are. So they may returns different values.

    A <geometry> element can only show up in a <library_geometries>, so it probably doesn't make sense to have a <geometry> but no <library_geometries>. I'm wondering what you did to get into that state. I can't reproduce that on my end.
    Quote Originally Posted by dbroadhurst
    In addition why is there two ways to get the geometry count and which one should I use?
    Anything that can be done with the database can also be done with the object model. There are a few things that the database is particularly good at though. For example, if I have an ID and I want to get the corresponding daeElement, I can do that very quickly using the database. Without the database you'd have to do a slow search through the entire element tree.

    The database can also be used to iterate over all elements of a specific type. For example if I want to iterate over all <geometry> elements, I can do that as follows:
    Code :
    unsigned int count = database.getElementCount(0, COLLADA_ELEMENT_GEOMETRY);
    for (unsigned int i = 0; i < count; i++) {
      daeElement* element = 0;
      database.getElement(&element, i, 0, COLLADA_ELEMENT_GEOMETRY);
      domGeometry* geometry = daeSafeCast<domGeometry>(element);
    }
    If you already have a domLibrary_geometries and you just want to iterate through that, then it's simpler to write code like this:
    Code :
    for (size_t i = 0; i < geometryLibrary->getGeometry_array().getCount(); i++) {
      domGeometry* geometry = geometryLibrary->getGeometry_array()[i].cast();
    }
    Sometimes though you don't have the domLibrary_geometries element, or you want to search through all the <geometry> elements in the document, regardless of which <library_geometries> they're in. The database makes that easy.

  3. #3
    Junior Member
    Join Date
    May 2007
    Posts
    9
    Thanks for the clearing up the difference. If I can do everthing through the database then the DOM becomes more of a util library that can be useful in certain situations?

    Still no luck on the <library_geomerties> call though. I can see in the debugger _value is 1 and I can see the element in the dae file.

    Is there some voodoo I might need to change in the compiler? Maybe there's a different definition of size_t in the libs? I am using VS2005 and start off with a win32 console application that I setup as a static library.

  4. #4
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    If I can do everthing through the database then the DOM becomes more of a util library that can be useful in certain situations?
    The opposite actually. The database can help you find a specific daeElement by ID or type, then once you have that you use the DOM to retrieve values from or modify the element.
    Still no luck on the <library_geomerties> call though. I can see in the debugger _value is 1 and I can see the element in the dae file.
    Just so I understand perfectly, the problem is that database.getElementCount(0, COLLADA_ELEMENT_LIBRARY_GEOMETRIES) returns 1 but dom.getLibrary_geometries_array().getCount() returns 0?
    Is there some voodoo I might need to change in the compiler? Maybe there's a different definition of size_t in the libs? I am using VS2005 and start off with a win32 console application that I setup as a static library.
    size_t is a standard C type so I doubt there's a problem there. What "_value" are you referring to? The only Visual Studio setting I'm aware of that might be a problem is the runtime library setting. Go to the properties for your .vcproj, Configuration Properties --> C/C++ --> Code Generation --> Runtime Library. Make sure it's set to "Multi-threaded Debug DLL" for the debug build and "Multi-threaded DLL" for the release build.

  5. #5
    Junior Member
    Join Date
    May 2007
    Posts
    9
    Correct on the difference

    If I debug the following

    domLibrary_geometries_array geo = dom->getLibrary_geometry_array()

    I see the following in the debugger

    geo.daeArray { _count=0, _capacity =4

    but

    dom.elemLibrary_geometries_array.daeArray { _count=1, capacity = 4

    Hope this make sense. The computer with the code is not online so excuse any typos.

  6. #6
    Junior Member
    Join Date
    May 2007
    Posts
    9
    BTW - My compiler is also set up for UNICODE

  7. #7
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    Ok, I see the problem. getLibrary_geometries_array returns a reference to the array. Store it in a variable like this:

    domLibrary_geometries_Array& geo = dom->getLibrary_geometries_array();

    In your code a copy of the array is being made. Apparently there's some bug where array copying doesn't work perfectly, which is probably why the count was 0, but regardless you don't want to copy the array.

  8. #8
    Junior Member
    Join Date
    May 2007
    Posts
    9
    Still returns 0

    Maybe I am getting confused over what needs to be passed into getDom

    I have a file in l:\projects\testmesh\cube.dae

    I load with collada->load("cube.dae");

    I then do collada->getDom("cube.dae") which seems to return a valid number but insists there is no geometry

    collada->getElementCount for library and library_geometries both return 1

    The version on cube.dae is 1.4.1. The readme in the collada folder says I am using collada 1.4.1 and DOM 1.2

  9. #9
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    Ah, bummer. Your collada->load and collada->getDom code there looks ok to me. Can you reduce your code to as small a test case as possible and post it here? I assume the Collada model you're using doesn't have any impact on the problem so that I should be able to reproduce it with any random model I try.

  10. #10
    Junior Member
    Join Date
    May 2007
    Posts
    9
    Here's the code

    Code :
    // testApp.cpp : Defines the entry point for the console application.
     
    //
     
    #include "stdafx.h"
     
    #pragma once
     
    #define WIN32_LEAN_AND_MEAN // Exclude rarely-used stuff from Windows headers
     
    #include <stdio.h>
     
    #include <tchar.h>
     
    // TODO: reference additional headers your program requires here
     
    #include <dae.h>
     
    #include <dom.h>
     
    #include <dom/domCollada.h>
     
    #include <dom/domConstants.h>
     
     
     
    int _tmain(int argc, _TCHAR* argv[])
     
    {
     
    DAE *input = new DAE;
     
    input->load("cube.dae");
     
     
    unsigned int geoLibCount = input->getDatabase()->getElementCount(0, COLLADA_ELEMENT_LIBRARY_GEOMETRIES, 0);
     
    printf("Geo Lib %d\n", geoLibCount);
     
    unsigned int geoCount = input->getDatabase()->getElementCount(0, COLLADA_ELEMENT_GEOMETRY, 0);
     
    printf("Geo %d\n", geoCount);
     
    domCOLLADA * dom = input->getDom("cube.dae"); 
     
    printf("%d\n", dom->getLibrary_geometries_array().getCount() );
     
    return 0;
     
    }

    I am using the 1.4 debug configuration to build the collada libraries.

    I can send the cude.dae file if required along the the VS2005 project

Page 1 of 2 12 LastLast

Posting Permissions

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