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.

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.

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:

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:

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.

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.

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.

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.

BTW - My compiler is also set up for UNICODE

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.

Still returns 0

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

I have a file in l:\projects estmesh\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

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.

Here’s the 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
", geoLibCount);

unsigned int geoCount = input->getDatabase()->getElementCount(0, COLLADA_ELEMENT_GEOMETRY, 0);

printf("Geo %d
", geoCount);

domCOLLADA * dom = input->getDom("cube.dae"); 

printf("%d
", 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

So for you, the output is something like this?

Geo Lib 1
Geo 1
0

I get the correct results with any model I try. Better post your cube.dae, or email it to me if it’s large. I sent you my email address in a PM.

Correct, 0 for the DOM call

Sent you all the files

We were able to figure out the problem offline. He was linking against an older build of the DOM, and this was causing things to get screwy. This problem is described in the release notes.

  • [Guideline]
    The COLLADA_DOM, as of release 1.2.0, has changed the build output location of win32 static libraries. The DOM now contains project files for both MSVS2003 and MSVS2005. The output for MSVC2003 is lib/vc7 and for MSVS2005 is lib/vc8. Be careful if updating from previous DOM versions. If you don’t update your project files to use the new location you may inadvertently continue linking against old versions of the DOM libraries which will cause errors.
    The comment in the release notes has turned out to be a bad way of alerting people to the problem. If we ever bump into this same situation in the future we may want to consider intentionally introducing symbols in the headers that’ll cause the link to fail if linking against the old libraries.