This is only loosely graphics related, but I cannot find a better place to post it. Back in the past, I have used some collada files mostly for experimentation with mixed results, using an internal XML parser (obviously I cared for a small subset). Looking back, I see I've never really used it. Let me make clear that I am doing just another engine out there, so my general needs are rather minimal. Anyway, since I wanted to try mess up with Google Earth stuff a bit, I decided to take a stab a collada again. Since the old code was essentially experimental, a few years old, not fitting the current style and bothering VC2008 here and there, I've decided to start from scratch and to use Collada DOM this time. However, I am having a ton and half issues with collada DOM. It seems to be somehow unstable to say the least. I have spent almost two days in building/testing it and I don't understand what's going on. The program just fails with no apparent reason and the stack trace in the debugger looks corrupted. It is clear I've done something wrong in building the lib. Also, the library is very hefty in dependancies according to my standards. Since I have to parse XML anyway for other components, I start thinking maybe the original approach of parsing it myself wasn't too bad (no, I haven't a clear understanding of the issues involving schema validation and such, nor I plan to support wide arrays of char encoding conventions). Searching the forums I see Collada threads come out quite often with people generally expressing mildly positive impressions so maybe someone may have experienced some similar issues. Can you help me in tracking the issue I mention? By the way, have you ever been hurt by the /NODEFAULTLIB issue with msvcrt(d)?

Note: I don't really know what happened with the previous message, looks like my connection timed out and screwed everything.

Quote:Original post by vicviper
I suggest you to begin looking to OpenCollada, which is a new official try (the third, after collada DOM and FCollada) to develop a proper, usable SDK

Yes, I heard about it, but I am not well aware of what's even supposed to be. Let's look at its homepage, it's a bunch of simple web pages with links to DCC exporters. That's useful, but not what I need. SourceForge's file page is empty, not including even the files linked in the download section. Not to mention the FAQ page is empty, or that all the pages have the same title, although it's clear they shouldn't.

Everything is still going on SVN only, I suppose they think it's self-documenting. I don't know, I am very conservative in choosing my dependancies. I went for DOM as it was maintained by Sony itself but come on, is this the best they can do?

I ask myself if I really need a lib to work with collada. Looking back, the old collada filter hasn't repaid itself. At least two years later, I don't see many collada assets out there, but even the few I have found doesn't seem too complex to parse to justify the dependancy - my data format is very nitpicky (breaks easily, if you want to put it that way), I will have to run some checking anyway.

I think for now I will just resist my wish to play with it until more information is made available.

Quote:Original post by vicviper
About the /NODEFAULTLIB, this usually happens when mixing libs that are compiled using different options, it can be solved by making most critical project options to match, like:
...
CRT linking (single threaded, multithreaded, DLL)

Let me elaborate a bit - yes, I understand the origin of the problem. The point is that I have been hurt by conflicting libraries when using zlib. I suppose zlib ended calling the debug free (in its zfree function) with data allocated using the release malloc, which gave me an extremely interesting crash in a library that is de facto standard. So, when you read that /NODEFAULTLIB solves the problem and your program fails with no apparent reason in a library with countless hours of usage worldwide... remember of this message and recompile everything paying more attention.
Thank you anyway for your answer, I really didn't formulate my question correctly, it was essentially just a rant.
I wrote about it there as Collada-DOM happens to use zlib as well as libxml, which caused mixing the two runtimes. When I saw the warning, I felt a shiver of terror down my spine. After more than a day compiling, linking and stuff I managed to make it work somehow, but it still gave me issues.

It is easier to compile the decade old libjpeg than this stuff. The more I think about it, the more I feel confident it's simply not worth it for me.

Quote:Original post by vicviper
I'm currently using FCollada, which is less painful than Collada DOM, but from what I've seen, they replaced the projects at sourceforge by OpenCollada, so I suspect the conditions/status/legal terms/license of FCollada might change in the near future, so I'm planning to migrate to OpenCollada eventually.

Changing again? That's terrible.

Quote:Original post by vicviper
Anyway, I've been expecting these changes for a long time, and what I've done is to create a small library that loads just what I need from Collada through my own wrapper, and everything is placed inside a DLL just to avoid library conflicts with the rest of the solution projects, so in case the dependencies change, or I decide to completely replace the collada SDK in use, only that DLL will be affected.

I am not a big fan of dynamic linking (a scare still hurting from the time I tried to support N+1 different OS) but you know your business better than I do for sure and I feel the rationale very solid.

Thank you very much for the thoughts.