I am writing a 3d App that will be a test bed for some projects. My current “roll your own” 3D data format isn’t cutting it. I DLed the 1.41 spec and sample files for Collada, and I really like the format and its ideology. But there is one thing I don’t understand, which will probably expose my lack of understanding of Collada and/or, more generally, xml parsing.
Take for example the sample “Cube.dae” file. After the verticies and after the normals arrays, there is a “<techniques-common>” tag encompassing an “<accessor>” tag, containing information needing to correctly the interpret the data in the array that came before it. This seems counter intuitive to me. Why does this information not come before the arrays?
You’ll want to choose the style of parsing you want to implement based on the type of application you are writing.
For COLLADA, we mostly consider the DOM parsing approach because it provides the best capabilities for authoring applications that edit and modify the documents. In this style, sub element ordering is less critical because the entire document is resident in memory.What is important is memory allocation and caching strategies to manage the text data blocks efficiently. Using in memory compression and late binding techniques are becoming popular optimizations for this.
Yes, but, my opinion is that keeping the document in a way that it can be parsed sequentially, without late binding, would not hurt.
Actually, I think that sequential parsing would be a requirement of the specs.
I’m using my own collada parser because, for my needs, both Collada Dom and FCollada are too heavy weighted and have too many dependencies. I parse the DAE files sequentially, without having to load the whole document in memory, but still, I have to do late binding with the materials and effects, which, in my DAE loading code, look like a really nasty hack.
If, for some fun reason, in a future implementation of DAE, the Geometry library is placed after the Scenes library, I would almost have to send my loading library to the trash.
Please, keep in mind that not everybody is going to use the official DOM libraries, not everybody is going to need all the features of collada for their latest Playstation3 title, there’s people out there that only wants to load some geometry with as few lines of code as possible, to try their latest shader code, or learn how to rotate an object, etc, and the complexities of loading DAEs these days can take away a lot of people.
Well, the Collada Specification already states that the main objective that lead to Collada is to provide interoperability between various 3D DCC Tools and provide a higher layer for import and export to function seamlessly between these tools.
The Collada format is certainly not the one that you would use for the runtime. It already IS a text based format. The idea is to use it as an base Asset format and if required write your own parsers to export only the required data to a binary format. And it is always safer to use the Collada DOM Libraries as it not only provides all the functionalities for you but also ensures that all the standards of Collada are strictly followed.
I understand that… but, my opinion continues being the same: little changes (or no changes at all, just reordering the order in which some librearies appear in the file) would be easy to do, it would not hurt, and it would be completely transparent to everybody.
I’m not using my parser for reading the DAE files in my workflow tools, not in realtime applications.
I decided to make my own parser instead of using the official DOM were these:
For learning purposes, the best way to learn a format is to make a parser, Collada is not friendly in this aspect.
To be able to use a lightweight parser, using only what I need from DAE.
To be able to load, edit & save geometry easier than what both Collada Dom and FCollada allow right now, both require too many dereferencing, loops, api calls, etc, to do little work (extract raw geometry)
I understand that Collada, and the DOMs are still work in progress, and have done a great job right now, but I think the issue of keeping DAEs easier to read should take more attention.
As far as I understand your needs, there is nothing in the specification that prevent you from doing what you need.
What you should probably be doing, is to create a conditioner that will rearrange the sections in the order that your simplified parser want. In effect, it is no different than having your own format and creating a tool that convert COLLADA to what you need.
Maybe what you need will be very popular ? so you can be a hero and provide the code as an opensource contribution !
Of course not, Collada already provides everything I need, what I was saying is that there are ways, and ways of doing things, and sometimes, I think that Collada chooses the hard way, when there are easier ways available.
I can’t do that at all, my parser reads XML sequentially, in streaming mode, I was not storing the whole document in memory; the advantage of my parser was that I was able to load larger DAE files than anybody else, which was useful in my current job, where we commonly handle +2 millon polygon geometry.
The fact that Collada is not designed to be read sequentially is what makes my parser more complicated that it should be, and that’s what I was discussing.
Well, actually, you won, I decided to drop my own parser and adopt FCollada. Reading this, and other threads in the boards, it looks like this board not encourage independent parsers; I can deal with new features which are complex by nature, but , it is clear to me that Collada is not going to make it easy for independent parsers.
I understand your sentiment but I don’t believe it’s an unattainable goal. COLLADA has URI that can represent local and non-local resources. COLLADA has flexible instantiation features beyond what some DCC tools can currently leverage. Taken all together, COLLADA is not limited to acyclic structures that can be evaluated in a single pass. Therefore when parsing an instance document software should be prepared to handle forward references. Given that fact, we are interested in optimizing that use case with deferred evaluation, late binding, caching and such.
I believe that would severely limit the feature set of what COLLADA could respresent. Imagine programming in C without the ability to make forward declarations… it wouldn’t be nearly as good.
The libraries can be in any order amongst themselves right now. The number of passes required to fully resolve a representation is a function of the dependency graph between the libraries within any given instance document. This number is not a constant so your code needs to be flexible
Well, actually, you won, I decided to drop my own parser and adopt FCollada. Reading this, and other threads in the boards, it looks like this board not encourage independent parsers; I can deal with new features which are complex by nature, but , it is clear to me that Collada is not going to make it easy for independent parsers.[/quote]
I’m sorry you feel that way. I know that Remi was sincerely encouraging you to implement your own solution. He wasn’t being sarcastic.
In my previous post I answered some of your earlier questions. I hope you find the answers helpful.