[QUOTE=Mick P.;42097]Recpas asked that I reply.
To be honest, my advice to anyone is to only use COLLADA if you think there is no alternative but to. And if you feel you have no alternative, it shouldn’t be on the grounds of technical capabilities-rather, it should be on the grounds that you cannot see your project using a more proprietary product instead of a nominally non-proprietary product like COLLADA. And if you think you are in that boat you need to think long and hard about it because you’re venturing into a no man’s land.
If you use C++ it’s probably worth your while to check out the code I developed last year. There’s a snippet here (https://www.khronos.org/collada/wiki/ColladaDOM_3#Deferred_dereferencing_of_const_operator-.3E.2A_values_.26_attributes) where you can see an example that looks something like this:
//Example. If any successive node does not exist, then use Y_UP.
RT::Main.UpAxis = COLLADA->asset->up_axis->value->*RT::Y_UP;
What you can see in this example is in C++ you’re almost working natively in the XML data structure’s representation. A line of code like this can replace 20 or more lines of old code that would use to access this relatively simple variable. If the COLLADA element in this example wasn’t a “const” object then the <asset> and <up_axis> variables will have been created automatically.
I think COLLADA doesn’t seem like a natural fit for what you are doing, but I cannot tell you what would be. I would only recommend it for very basic video game and robotics modeling applications, and only then if it works. In its present state I’d only recommend it to masochists and idealists and maybe then only if they want to see COLLADA’s situation improved. The path to improvement could not be less clear either.
Even under the best circumstances you’ll find yourself trying to piece together what the initial designers were thinking. There are not central tenets to COLLADA. Sometimes it seems like there is 20 different addressing modes and none of them are ever used more than once. It’s maddening to be perfectly honest. Khronos has absolutely dropped the ball this time, and I think I see a lot of interest in the idea of COLLADA right now, if not the implementation in practice. I really wish Khronos would make an effort to resurrect this black sheep in this decade.
(I’m working on a reference implementation right now that visualizes rich COLLADA documents to the greatest degree COLLADA allows. Most software implements about 2% of COLLADA and calls it a day. It’s really only meant as a dialect of a language for clients and subcontractors to make bespoke modules talk to each other. As a kind of archival storage medium or exchange format–as people imagine it is–it has a long way to go. There is no ecosystem.)[/QUOTE]
thanks for replying!
I admit I’m quite… frightened…! I am not masochist, and I cannot take the wrong way because I’d have no time to recover.
There are alternatives, one of them being CityGML with appropriate extensions (because CityGML does not consider, per se, LODs as detailed as I need: many people are working on this, but - again - there is no standard).
Perhaps at the moment I need a simpler graphic format containing some hierarchy and semantics metadata, later embedding my files in more complex and complete environment, so deferring the decision to the future.