i’m using collada (latest version) to load some models in a multi-threaded application. this works fine in debug mode. in release mode, however, the models sometimes don’t show up. this is because all vertex (normal/texcoord/…) coordinates are set to zero for some reason. if the error has appeared once, it stays and affects all models i try to load afterwards.
what could be the reason for this?
which API are you using to load your COLLADA documents?
COLLADA DOM, FCOLLADA, or did you do your own?
i’m using the collada dom.
//loop over all triangles
int v_id1 = trianglesArray[t]->getP()->getValue()[..];
m_input->getDatabase()->getElement((daeElement**)&sourceRef, 0, vtxArrayId, COLLADA_ELEMENT_SOURCE,NULL);
tri.positions[k] = sourceRef->getFloat_array().getValue()[..];
i tried to stick close to the examples, but i wrote my own class instead of using the integration templates. it does work most of the time, and i would rather not rewrite the whole thing.
just ran a short test,
the error seems to be gone with integration templates.
so we gonna start this sh… again
i switched from my homegrown code to integration templates, but after some model-loading, the error’s back! damnit!
so changed the code again, this time using the collada run-time libs (btw, these are completely free to use, right?), but… it’s still there…
- my application is qt-based and multi-threaded.
- debug always works fine
- in release-mode, the error shows up every now and then
- if it has occurred once, it stays
- models are loaded (“Done Loading xx.dae”), but nothing is rendered
- i’m using the crt:
the output of ->Render() is written into a display list, which sometimes contains only vertices with (0/0/0). other values, like the number of vertices, nodenames,… are still read out correct.
I am sorry I really have no clue what is going on. I can offer a few things to look into but I don’t know if it will actually help.
Multithreaded programs are always a pain to debug. Are you sure you have the thread synchronization done properly? The DOM loading should be completely finished before you try and access the data. The DOM is not threadsafe itself so if the client app isn’t careful there could be problems.
The fact that this happens no matter how you are using the DOM (straight up, integration classes, RT (and yes it has the same license as the DOM so its free to use)) makes me think it may be an issue with the underlying IOPlugin. Question: When you get this error does the rest of the data in the document stay correct? like the count for the array is correct but then all the values are just 0s?
You may want to look into libxml2. By default the DOM builds with a default build of libxml2. You may need build that differently and then relink with that.
I’m sorry. I wish I could be of more help. When I have a bug where it works in debug but not release I make an optimized debug build configuration to test with. It’s pretty much the release build with debug symbols. That way I can still use a debugger on it (although it might be confusing because the compiler optimizations changing code around). I would suggest looking into daeLIBXMLPlugin::readValue . Set a conditional checkpoint based on the type of the element, float_array. From there you can hopefully see if Libxml2 is reading the string incorrectly or if the DOM is interpreting the string incorrectly.
thanks a lot for your reply!
i will try out your tips and notify you if i find the bug.
greets from austria!
yes, all values, except the vertex coords are read out correct (i think). i tested it with the nodecount of the document, and it stays constant. would that mean it’s not the io-plugin’s fault?
some more thoughts:
- crt instancing, loading and rendering are all done in the same thread.
- the error also occurs when i load a single .dae document.
anyway, i’ll rebuild libxml2 today and see if it helps…