Uniting graphics libraries
Hi, I have nearly finished writing a Collada-output library to make 3d animation files. Before doing this I have looked at two libraries on hackage that parse Collada to display it. For my library I have copied the types from gpipe-collada and extended them. Now I am thinking that it would be nice if all 3d libraries would use the same data type. Currently gpipe-collada, graphics-formats-collada, obj, ... parse 3d-formats. FieldTrip, lambdacube-engine, ... (to mention examples) can generate and/or display 3d-objects. But they all cannot be combined without tedious type conversions. The obvious argument is that every application has its own needs. This is of course true but I think that the Collada format shows how to deal with this (you can do quite a lot with profile_common). I would be willing to write patches for some libraries and make a discussable 3d-types library based on Collada. Hope you agree, Tillmann
2010/9/18 Tillmann Vogt
Hi,
I have nearly finished writing a Collada-output library to make 3d animation files. Before doing this I have looked at two libraries on hackage that parse Collada to display it. For my library I have copied the types from gpipe-collada and extended them. Now I am thinking that it would be nice if all 3d libraries would use the same data type. Currently gpipe-collada, graphics-formats-collada, obj, ... parse 3d-formats. FieldTrip, lambdacube-engine, ... (to mention examples) can generate and/or display 3d-objects. But they all cannot be combined without tedious type conversions. The obvious argument is that every application has its own needs. This is of course true but I think that the Collada format shows how to deal with this (you can do quite a lot with profile_common). I would be willing to write patches for some libraries and make a discussable 3d-types library based on Collada.
Hi, This is a great goal! I've also been thinking in solidifying all things 3D on hackage lately and forming a game and graphics strike team. (The idea is that even if you're not interested in games, there are still a lot of common things.) Now it seems you see Collada as a good common starting point. I don't know much about Collada and I can't really say if it is a good idea or not. But by following the blender development mailing list, it seems people don't really 'trust' it, in the sense that in practice, it is still difficult to move things around between different programs through Collada... Also Collada is (I am not sure) just an interchange format and you talk about data types. Can you be a bit more specific about what you envision? Are they a direct representation of Collada? You talk about combining the different libraries on Hackage, would you like to do it through Collada? When I said I thought about solidifying things lately, I was thinking to the problem you describe but at a lower level: for instance there are many different representations for 3D vectors and transforms. Is it also a concern for you? Cheers, Thu
Am 18.09.2010 15:14, schrieb Vo Minh Thu:
Hi, This is a great goal! I've also been thinking in solidifying all things 3D on hackage lately and forming a game and graphics strike team. (The idea is that even if you're not interested in games, there are still a lot of common things.)
Now it seems you see Collada as a good common starting point. I don't know much about Collada and I can't really say if it is a good idea or not. But by following the blender development mailing list, it seems people don't really 'trust' it, in the sense that in practice, it is still difficult to move things around between different programs through Collada...
Maybe the format isn't properly implemented in some programs. I have also experienced examples-files that didn't load. But it think that collada is currently the best format and it's quite powerful (shaders, physics, ...).
Also Collada is (I am not sure) just an interchange format and you talk about data types. Can you be a bit more specific about what you envision? Are they a direct representation of Collada?
Yes, pretty much a direct representation. But some things can be made
simpler. I.e. I replace the
You talk about combining the different libraries on Hackage, would you like to do it through Collada? Yes, the types . I currently don't see a better way. When I said I thought about solidifying things lately, I was thinking to the problem you describe but at a lower level: for instance there are many different representations for 3D vectors and transforms. Is it also a concern for you? This is a problem. But I would accept a majority vote. At the moment I would use the same vector library as gpipe. Cheers, Thu
2010/9/18 Tillmann Vogt
Am 18.09.2010 15:14, schrieb Vo Minh Thu:
Hi, This is a great goal! I've also been thinking in solidifying all things 3D on hackage lately and forming a game and graphics strike team. (The idea is that even if you're not interested in games, there are still a lot of common things.)
Now it seems you see Collada as a good common starting point. I don't know much about Collada and I can't really say if it is a good idea or not. But by following the blender development mailing list, it seems people don't really 'trust' it, in the sense that in practice, it is still difficult to move things around between different programs through Collada...
Maybe the format isn't properly implemented in some programs. I have also experienced examples-files that didn't load. But it think that collada is currently the best format and it's quite powerful (shaders, physics, ...).
Also Collada is (I am not sure) just an interchange format and you talk about data types. Can you be a bit more specific about what you envision? Are they a direct representation of Collada?
Yes, pretty much a direct representation. But some things can be made simpler. I.e. I replace the
tags with their value and have a type garantee instead of trusting that a url referenced object exists. The Collada people stress the point that its only an interchange format. But Google is using it also for delivery (Google Earth). If one can live with some seconds longer loading it is no problem. By the way wonder why Collada isn't advocating binary XML? That would make things faster. You talk about combining the different libraries on Hackage, would you like to do it through Collada?
Yes, the types . I currently don't see a better way.
Ok. I'll learn more about Collada then. Is your code already available somewhere? Still, Collada seems to be on a far end of the spectrum of what could be unified. I mean, say your animation has to be rendered by some Haskell code, do you wish to go through Collada or that your animation code and the rendering code share some other data structures than Collada (Or maybe Collada is just a first step?) ? If the later, it would be useful to share what those other data structures should be.
When I said I thought about solidifying things lately, I was thinking to the problem you describe but at a lower level: for instance there are many different representations for 3D vectors and transforms. Is it also a concern for you?
This is a problem. But I would accept a majority vote. At the moment I would use the same vector library as gpipe.
Why a majority vote? Maybe we can do better: state some desired properties, benchmark the existing libraries and see if something fits? Are there other people interested in unifying the efforts here? Cheers, Thu
Am 18.09.2010 16:16, schrieb Vo Minh Thu:
Ok. I'll learn more about Collada then. Is your code already available somewhere?
I will upload it in a few days on hackage. It is not finished yet.
Still, Collada seems to be on a far end of the spectrum of what could be unified. I mean, say your animation has to be rendered by some Haskell code, do you wish to go through Collada or that your animation code and the rendering code share some other data structures than Collada (Or maybe Collada is just a first step?) ? If the later, it would be useful to share what those other data structures should be.
Animations in Collada are streams of interpolated floats that are interpreted as time or output (i.e. angle of a rotation). The output is then channeled to the tags of the nodes. One can do quite a lot with this. At the moment I can't image what else one could do.
When I said I thought about solidifying things lately, I was thinking to the problem you describe but at a lower level: for instance there are many different representations for 3D vectors and transforms. Is it also a concern for you? This is a problem. But I would accept a majority vote. At the moment I would use the same vector library as gpipe. Why a majority vote? Maybe we can do better: state some desired properties, benchmark the existing libraries and see if something fits?
Are there other people interested in unifying the efforts here?
Cheers, Thu
participants (2)
-
Tillmann Vogt -
Vo Minh Thu