Re: [Bf-committers] Collada importer/exporter kickout
Removing Collada is a bad idea, better poor support than none. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada importer/exporter kickout
Hi, I realize the proposal was harsh, but it was meant as a public statement as well (to khronos, opencollada team, etc). I don't want to blame it on the hard working devs here. We do have collada IO work at some level, and that has been proven useful in several cases. The job is just incredible hard to achieve. To move forward: - userts who successfully applied .dae could also check whether another exchange format would have done the job as good. Tried FBX? - note that for basic mesh (+uv) export, a quite simple script could do the job already. It is probably a few days job for a py scripter. - we are currently including about 100 MB of opencollada libs to make a feature work that's meant to be able to exchange (I+O) full shots or game environments, with character animation and so on. That's what Collada was designed for, and that's a target we can't support. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 6 Jan, 2012, at 21:21, Morten Mikkelsen wrote: 1) Official announcement that Blender drops Collada support 2) Move Collada support into a branch, out of trunk 3) Create a tracker orphanage or branches or so, where we put all reports that are not in support (anymore). I just want to say though I am not up for the challenge of taking over on this sub project I would be sad to see Collada support taken out of trunk. I use it often also with skinning export. I know many users do and eventhough I understand everyone's frustration I prefer the implementation that is there now (which I use often) to no built-in version at all. I am not disagreeing with any of the frustrating aspects of Collada which you and others have mentioned. Just saying personally I do use it and would very much like to keep it in. With bugs and all :) I have seen many other commercial tools with awful crappy .3ds importers and exporters but bad as they were they didn't take them out because people were still relying on them and using them. Despite the bugs in them. Cheers, Morten. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada importer/exporter kickout
I know Collada importer / exporter is problematic (I wrote an importer for my engine and I know that everything in the Collada can be stored in N different ways). - If you want to use the model in Second Life / Google Earth, you have to use Collada, if you want to use models in engines WebGL/Flash3D practically have to use Collada (is there any web engine with FBX importer?), Most game engines use Collada for importing data (support for FBX a few). FBX exporter also has bugs. Well, that FBX is in a blender, but it is not usually an option for people using Collada. - If someone uses Collada it not for the base mesh + uv (then using *. obj) and for skeletal animation, lights, cameras and their animation (motion, color, light and their intensity), multiUV (uv for color, normalmap ... + uv for lightmap). And all this in current Collada exporter works well. - No other exporter does not work here as well as Collada - ofc has bugs, but it has nothing what could replace the Collada in this task. In the future, Alembic can replace Collada, but not for several years. IMO, better to leave Collada, until you will be able to replace it with success to other formats like Alembic (FBX is not popular in the software and you can not replace him Collada in most tasks). On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote: Hi, I realize the proposal was harsh, but it was meant as a public statement as well (to khronos, opencollada team, etc). I don't want to blame it on the hard working devs here. We do have collada IO work at some level, and that has been proven useful in several cases. The job is just incredible hard to achieve. To move forward: - userts who successfully applied .dae could also check whether another exchange format would have done the job as good. Tried FBX? - note that for basic mesh (+uv) export, a quite simple script could do the job already. It is probably a few days job for a py scripter. - we are currently including about 100 MB of opencollada libs to make a feature work that's meant to be able to exchange (I+O) full shots or game environments, with character animation and so on. That's what Collada was designed for, and that's a target we can't support. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 6 Jan, 2012, at 21:21, Morten Mikkelsen wrote: 1) Official announcement that Blender drops Collada support 2) Move Collada support into a branch, out of trunk 3) Create a tracker orphanage or branches or so, where we put all reports that are not in support (anymore). I just want to say though I am not up for the challenge of taking over on this sub project I would be sad to see Collada support taken out of trunk. I use it often also with skinning export. I know many users do and eventhough I understand everyone's frustration I prefer the implementation that is there now (which I use often) to no built-in version at all. I am not disagreeing with any of the frustrating aspects of Collada which you and others have mentioned. Just saying personally I do use it and would very much like to keep it in. With bugs and all :) I have seen many other commercial tools with awful crappy .3ds importers and exporters but bad as they were they didn't take them out because people were still relying on them and using them. Despite the bugs in them. Cheers, Morten. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada importer/exporter kickout
Yes that's a very relevant point. A collada solution with just positions, UVs and normals is not a solution. In that case you might as well use obj format. I went through the hard work of writing a collada importer specifically to get skinning and animation into my tech frame-work. On Sat, Jan 7, 2012 at 5:03 AM, skoti skot...@o2.pl wrote: I know Collada importer / exporter is problematic (I wrote an importer for my engine and I know that everything in the Collada can be stored in N different ways). - If you want to use the model in Second Life / Google Earth, you have to use Collada, if you want to use models in engines WebGL/Flash3D practically have to use Collada (is there any web engine with FBX importer?), Most game engines use Collada for importing data (support for FBX a few). FBX exporter also has bugs. Well, that FBX is in a blender, but it is not usually an option for people using Collada. - If someone uses Collada it not for the base mesh + uv (then using *. obj) and for skeletal animation, lights, cameras and their animation (motion, color, light and their intensity), multiUV (uv for color, normalmap ... + uv for lightmap). And all this in current Collada exporter works well. - No other exporter does not work here as well as Collada - ofc has bugs, but it has nothing what could replace the Collada in this task. In the future, Alembic can replace Collada, but not for several years. IMO, better to leave Collada, until you will be able to replace it with success to other formats like Alembic (FBX is not popular in the software and you can not replace him Collada in most tasks). On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote: Hi, I realize the proposal was harsh, but it was meant as a public statement as well (to khronos, opencollada team, etc). I don't want to blame it on the hard working devs here. We do have collada IO work at some level, and that has been proven useful in several cases. The job is just incredible hard to achieve. To move forward: - userts who successfully applied .dae could also check whether another exchange format would have done the job as good. Tried FBX? - note that for basic mesh (+uv) export, a quite simple script could do the job already. It is probably a few days job for a py scripter. - we are currently including about 100 MB of opencollada libs to make a feature work that's meant to be able to exchange (I+O) full shots or game environments, with character animation and so on. That's what Collada was designed for, and that's a target we can't support. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 6 Jan, 2012, at 21:21, Morten Mikkelsen wrote: 1) Official announcement that Blender drops Collada support 2) Move Collada support into a branch, out of trunk 3) Create a tracker orphanage or branches or so, where we put all reports that are not in support (anymore). I just want to say though I am not up for the challenge of taking over on this sub project I would be sad to see Collada support taken out of trunk. I use it often also with skinning export. I know many users do and eventhough I understand everyone's frustration I prefer the implementation that is there now (which I use often) to no built-in version at all. I am not disagreeing with any of the frustrating aspects of Collada which you and others have mentioned. Just saying personally I do use it and would very much like to keep it in. With bugs and all :) I have seen many other commercial tools with awful crappy .3ds importers and exporters but bad as they were they didn't take them out because people were still relying on them and using them. Despite the bugs in them. Cheers, Morten. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada importer/exporter kickout
Hi guys, I made my own Collada exporter in Python and that's what I've been using. It's less than 1k lines of code and does not depend upon any library or anything, but it exports everything except morphs. I don't have much time to work on it at the moment, but it's so simple and complete that if anyone else want's to work on it, it should be really easy. I'm also not an expert at Python or Blender API so someone more experience can probably shape it up better. It's also much more stable than the official one (due to it being so small). Feel free to do anything with it or integrate it into Blender, just credit me on the file. I would love to work more on it, or even make a proper importer since I have a high level of expertise in Collada, but I have very little time and must work to earn my meals. Cheers! Juan Linietsky On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen mikkels...@gmail.comwrote: Yes that's a very relevant point. A collada solution with just positions, UVs and normals is not a solution. In that case you might as well use obj format. I went through the hard work of writing a collada importer specifically to get skinning and animation into my tech frame-work. On Sat, Jan 7, 2012 at 5:03 AM, skoti skot...@o2.pl wrote: I know Collada importer / exporter is problematic (I wrote an importer for my engine and I know that everything in the Collada can be stored in N different ways). - If you want to use the model in Second Life / Google Earth, you have to use Collada, if you want to use models in engines WebGL/Flash3D practically have to use Collada (is there any web engine with FBX importer?), Most game engines use Collada for importing data (support for FBX a few). FBX exporter also has bugs. Well, that FBX is in a blender, but it is not usually an option for people using Collada. - If someone uses Collada it not for the base mesh + uv (then using *. obj) and for skeletal animation, lights, cameras and their animation (motion, color, light and their intensity), multiUV (uv for color, normalmap ... + uv for lightmap). And all this in current Collada exporter works well. - No other exporter does not work here as well as Collada - ofc has bugs, but it has nothing what could replace the Collada in this task. In the future, Alembic can replace Collada, but not for several years. IMO, better to leave Collada, until you will be able to replace it with success to other formats like Alembic (FBX is not popular in the software and you can not replace him Collada in most tasks). On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote: Hi, I realize the proposal was harsh, but it was meant as a public statement as well (to khronos, opencollada team, etc). I don't want to blame it on the hard working devs here. We do have collada IO work at some level, and that has been proven useful in several cases. The job is just incredible hard to achieve. To move forward: - userts who successfully applied .dae could also check whether another exchange format would have done the job as good. Tried FBX? - note that for basic mesh (+uv) export, a quite simple script could do the job already. It is probably a few days job for a py scripter. - we are currently including about 100 MB of opencollada libs to make a feature work that's meant to be able to exchange (I+O) full shots or game environments, with character animation and so on. That's what Collada was designed for, and that's a target we can't support. -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 6 Jan, 2012, at 21:21, Morten Mikkelsen wrote: 1) Official announcement that Blender drops Collada support 2) Move Collada support into a branch, out of trunk 3) Create a tracker orphanage or branches or so, where we put all reports that are not in support (anymore). I just want to say though I am not up for the challenge of taking over on this sub project I would be sad to see Collada support taken out of trunk. I use it often also with skinning export. I know many users do and eventhough I understand everyone's frustration I prefer the implementation that is there now (which I use often) to no built-in version at all. I am not disagreeing with any of the frustrating aspects of Collada which you and others have mentioned. Just saying personally I do use it and would very much like to keep it in. With bugs and all :) I have seen many other commercial tools with awful crappy .3ds importers and exporters but bad as they were they didn't take them out because people were still relying on them and using them. Despite the bugs in them. Cheers, Morten.
Re: [Bf-committers] Collada importer/exporter kickout
In my case I do not need morphs. I do need animation and skinning though. And obviously also geometries and materials. And it sounds like you have this covered? I have no sense of loyalty toward OpenCollada so if this is a viable solution I am for it. Can you make it available somewhere with instructions on how to install it so people can test it? Cheers and thanks, Morten On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky redu...@gmail.com wrote: Hi guys, I made my own Collada exporter in Python and that's what I've been using. It's less than 1k lines of code and does not depend upon any library or anything, but it exports everything except morphs. I don't have much time to work on it at the moment, but it's so simple and complete that if anyone else want's to work on it, it should be really easy. I'm also not an expert at Python or Blender API so someone more experience can probably shape it up better. It's also much more stable than the official one (due to it being so small). Feel free to do anything with it or integrate it into Blender, just credit me on the file. I would love to work more on it, or even make a proper importer since I have a high level of expertise in Collada, but I have very little time and must work to earn my meals. Cheers! Juan Linietsky On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen mikkels...@gmail.com wrote: Yes that's a very relevant point. A collada solution with just positions, UVs and normals is not a solution. In that case you might as well use obj format. I went through the hard work of writing a collada importer specifically to get skinning and animation into my tech frame-work. On Sat, Jan 7, 2012 at 5:03 AM, skoti skot...@o2.pl wrote: I know Collada importer / exporter is problematic (I wrote an importer for my engine and I know that everything in the Collada can be stored in N different ways). - If you want to use the model in Second Life / Google Earth, you have to use Collada, if you want to use models in engines WebGL/Flash3D practically have to use Collada (is there any web engine with FBX importer?), Most game engines use Collada for importing data (support for FBX a few). FBX exporter also has bugs. Well, that FBX is in a blender, but it is not usually an option for people using Collada. - If someone uses Collada it not for the base mesh + uv (then using *. obj) and for skeletal animation, lights, cameras and their animation (motion, color, light and their intensity), multiUV (uv for color, normalmap ... + uv for lightmap). And all this in current Collada exporter works well. - No other exporter does not work here as well as Collada - ofc has bugs, but it has nothing what could replace the Collada in this task. In the future, Alembic can replace Collada, but not for several years. IMO, better to leave Collada, until you will be able to replace it with success to other formats like Alembic (FBX is not popular in the software and you can not replace him Collada in most tasks). On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote: Hi, I realize the proposal was harsh, but it was meant as a public statement as well (to khronos, opencollada team, etc). I don't want to blame it on the hard working devs here. We do have collada IO work at some level, and that has been proven useful in several cases. The job is just incredible hard to achieve. To move forward: - userts who successfully applied .dae could also check whether another exchange format would have done the job as good. Tried FBX? - note that for basic mesh (+uv) export, a quite simple script could do the job already. It is probably a few days job for a py scripter. - we are currently including about 100 MB of opencollada libs to make a feature work that's meant to be able to exchange (I+O) full shots or game environments, with character animation and so on. That's what Collada was designed for, and that's a target we can't support. -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 6 Jan, 2012, at 21:21, Morten Mikkelsen wrote: 1) Official announcement that Blender drops Collada support 2) Move Collada support into a branch, out of trunk 3) Create a tracker orphanage or branches or so, where we put all reports that are not in support (anymore). I just want to say though I am not up for the challenge of taking over on this sub project I would be sad to see Collada support taken out of trunk. I use it often also with skinning export. I know many users do and eventhough I understand everyone's frustration I prefer the implementation that is
Re: [Bf-committers] Collada importer/exporter kickout
Ah, I tried to attach it to the e-mail, guess the mailing list does not accept attachments? Here's a dropbox link: http://dl.dropbox.com/u/53086520/io_scene_dae.zip Cheers Juan Linietsky On Sat, Jan 7, 2012 at 12:38 PM, Morten Mikkelsen mikkels...@gmail.comwrote: In my case I do not need morphs. I do need animation and skinning though. And obviously also geometries and materials. And it sounds like you have this covered? I have no sense of loyalty toward OpenCollada so if this is a viable solution I am for it. Can you make it available somewhere with instructions on how to install it so people can test it? Cheers and thanks, Morten On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky redu...@gmail.com wrote: Hi guys, I made my own Collada exporter in Python and that's what I've been using. It's less than 1k lines of code and does not depend upon any library or anything, but it exports everything except morphs. I don't have much time to work on it at the moment, but it's so simple and complete that if anyone else want's to work on it, it should be really easy. I'm also not an expert at Python or Blender API so someone more experience can probably shape it up better. It's also much more stable than the official one (due to it being so small). Feel free to do anything with it or integrate it into Blender, just credit me on the file. I would love to work more on it, or even make a proper importer since I have a high level of expertise in Collada, but I have very little time and must work to earn my meals. Cheers! Juan Linietsky On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen mikkels...@gmail.com wrote: Yes that's a very relevant point. A collada solution with just positions, UVs and normals is not a solution. In that case you might as well use obj format. I went through the hard work of writing a collada importer specifically to get skinning and animation into my tech frame-work. On Sat, Jan 7, 2012 at 5:03 AM, skoti skot...@o2.pl wrote: I know Collada importer / exporter is problematic (I wrote an importer for my engine and I know that everything in the Collada can be stored in N different ways). - If you want to use the model in Second Life / Google Earth, you have to use Collada, if you want to use models in engines WebGL/Flash3D practically have to use Collada (is there any web engine with FBX importer?), Most game engines use Collada for importing data (support for FBX a few). FBX exporter also has bugs. Well, that FBX is in a blender, but it is not usually an option for people using Collada. - If someone uses Collada it not for the base mesh + uv (then using *. obj) and for skeletal animation, lights, cameras and their animation (motion, color, light and their intensity), multiUV (uv for color, normalmap ... + uv for lightmap). And all this in current Collada exporter works well. - No other exporter does not work here as well as Collada - ofc has bugs, but it has nothing what could replace the Collada in this task. In the future, Alembic can replace Collada, but not for several years. IMO, better to leave Collada, until you will be able to replace it with success to other formats like Alembic (FBX is not popular in the software and you can not replace him Collada in most tasks). On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote: Hi, I realize the proposal was harsh, but it was meant as a public statement as well (to khronos, opencollada team, etc). I don't want to blame it on the hard working devs here. We do have collada IO work at some level, and that has been proven useful in several cases. The job is just incredible hard to achieve. To move forward: - userts who successfully applied .dae could also check whether another exchange format would have done the job as good. Tried FBX? - note that for basic mesh (+uv) export, a quite simple script could do the job already. It is probably a few days job for a py scripter. - we are currently including about 100 MB of opencollada libs to make a feature work that's meant to be able to exchange (I+O) full shots or game environments, with character animation and so on. That's what Collada was designed for, and that's a target we can't support. -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 6 Jan, 2012, at 21:21, Morten Mikkelsen wrote: 1) Official announcement that Blender drops Collada support 2) Move Collada support into a branch, out of trunk 3) Create a tracker orphanage or branches or so,
Re: [Bf-committers] Collada importer/exporter kickout
Ah also, I think I wrote it for Blender 2.58 so I hope no API has changed since then and stil works. Cheers Juan Liniesky On Sat, Jan 7, 2012 at 12:49 PM, Juan Linietsky redu...@gmail.com wrote: Ah, I tried to attach it to the e-mail, guess the mailing list does not accept attachments? Here's a dropbox link: http://dl.dropbox.com/u/53086520/io_scene_dae.zip Cheers Juan Linietsky On Sat, Jan 7, 2012 at 12:38 PM, Morten Mikkelsen mikkels...@gmail.comwrote: In my case I do not need morphs. I do need animation and skinning though. And obviously also geometries and materials. And it sounds like you have this covered? I have no sense of loyalty toward OpenCollada so if this is a viable solution I am for it. Can you make it available somewhere with instructions on how to install it so people can test it? Cheers and thanks, Morten On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky redu...@gmail.com wrote: Hi guys, I made my own Collada exporter in Python and that's what I've been using. It's less than 1k lines of code and does not depend upon any library or anything, but it exports everything except morphs. I don't have much time to work on it at the moment, but it's so simple and complete that if anyone else want's to work on it, it should be really easy. I'm also not an expert at Python or Blender API so someone more experience can probably shape it up better. It's also much more stable than the official one (due to it being so small). Feel free to do anything with it or integrate it into Blender, just credit me on the file. I would love to work more on it, or even make a proper importer since I have a high level of expertise in Collada, but I have very little time and must work to earn my meals. Cheers! Juan Linietsky On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen mikkels...@gmail.com wrote: Yes that's a very relevant point. A collada solution with just positions, UVs and normals is not a solution. In that case you might as well use obj format. I went through the hard work of writing a collada importer specifically to get skinning and animation into my tech frame-work. On Sat, Jan 7, 2012 at 5:03 AM, skoti skot...@o2.pl wrote: I know Collada importer / exporter is problematic (I wrote an importer for my engine and I know that everything in the Collada can be stored in N different ways). - If you want to use the model in Second Life / Google Earth, you have to use Collada, if you want to use models in engines WebGL/Flash3D practically have to use Collada (is there any web engine with FBX importer?), Most game engines use Collada for importing data (support for FBX a few). FBX exporter also has bugs. Well, that FBX is in a blender, but it is not usually an option for people using Collada. - If someone uses Collada it not for the base mesh + uv (then using *. obj) and for skeletal animation, lights, cameras and their animation (motion, color, light and their intensity), multiUV (uv for color, normalmap ... + uv for lightmap). And all this in current Collada exporter works well. - No other exporter does not work here as well as Collada - ofc has bugs, but it has nothing what could replace the Collada in this task. In the future, Alembic can replace Collada, but not for several years. IMO, better to leave Collada, until you will be able to replace it with success to other formats like Alembic (FBX is not popular in the software and you can not replace him Collada in most tasks). On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote: Hi, I realize the proposal was harsh, but it was meant as a public statement as well (to khronos, opencollada team, etc). I don't want to blame it on the hard working devs here. We do have collada IO work at some level, and that has been proven useful in several cases. The job is just incredible hard to achieve. To move forward: - userts who successfully applied .dae could also check whether another exchange format would have done the job as good. Tried FBX? - note that for basic mesh (+uv) export, a quite simple script could do the job already. It is probably a few days job for a py scripter. - we are currently including about 100 MB of opencollada libs to make a feature work that's meant to be able to exchange (I+O) full shots or game environments, with character animation and so on. That's what Collada was designed for, and that's a target we can't support. -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 6 Jan, 2012, at
Re: [Bf-committers] Collada importer/exporter kickout
As an example of people having problems with its complexity OpenCollada doesn't drain collada sources correctly at all. They make many assumptions such as data being non interleaved. On Sat, Jan 7, 2012 at 8:23 AM, Juan Linietsky redu...@gmail.com wrote: On Fri, Jan 6, 2012 at 9:04 PM, Francesco Zoffoli maker...@gmail.com wrote: I'm just curious: why can't an external library be used? I think the biggest problem with Collada is that the specification seems like something huge and complex, so most people resorts to a library, which in turn ends up in something even more bigger and complex with several layers of complexiity that is a nightmare to maintain. In reality, Collada is a very simple format that is very easy to parse, but it definitely takes some work to really grasp and understand all of it, because it's very flexible (way too much more than needed I think). I also wish it was more mantained and better documented at this point, too because most official examples are either broken or incompatible with the specification. Cheers Juan Linietsky ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada importer/exporter kickout
On Sat, 2012-01-07 at 12:06 -0300, Juan Linietsky wrote: Feel free to do anything with it or integrate it into Blender, just credit me on the file. I would love to work more on it, or even make a proper importer since I have a high level of expertise in Collada, but I have very little time and must work to earn my meals. One thing that would need changing is the handling of libraries. Empty ones should not be included in the .dae - having them there causes compliance errors. Schema validation error: Error: ERROR_VALIDATION_MIN_OCCURS_UNMATCHED Element: library_images, Line: 14, Additional: child: image Best Wishes, Domino ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada importer/exporter kickout
You are right that in some cases an exporter is better, but in many cases a C/C++ .blend importer is a better to go. I just wanted to remind anyone reading this thread that there is an easy way to extract any data from Blender in C++, including animation curves, skinning info, textures etc, without the issues of COLLADA and FBX. I'm not familiar with baking, but you might be able to store the baked data in the .blend file. Thanks, Erwin On 7 January 2012 09:10, Juan Linietsky redu...@gmail.com wrote: Erwin, That looks awesome and really useful, however the main advantage of an importer is the ability to bake everything (IK and other constraints) just like it's displayed in Blender. Cheers Juan Linietsky On Sat, Jan 7, 2012 at 2:07 PM, Erwin Coumans erwin.coum...@gmail.com wrote: Instead of going through the COLLADA or other intermediate format you can directly extract any data from a .blend using this C++ .blend parser: http://tinyurl.com/6s7k9zw AnimKit with the .blend loader includes a small sample that loads a .blend file, extracts textures, meshes, animations, skinning and physics info. It shows a skinned skeletal animated character using AnimKit and GLUT (keeping dependencies to a minimum) Cheers, Erwin On 7 January 2012 07:38, Morten Mikkelsen mikkels...@gmail.com wrote: In my case I do not need morphs. I do need animation and skinning though. And obviously also geometries and materials. And it sounds like you have this covered? I have no sense of loyalty toward OpenCollada so if this is a viable solution I am for it. Can you make it available somewhere with instructions on how to install it so people can test it? Cheers and thanks, Morten On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky redu...@gmail.com wrote: Hi guys, I made my own Collada exporter in Python and that's what I've been using. It's less than 1k lines of code and does not depend upon any library or anything, but it exports everything except morphs. I don't have much time to work on it at the moment, but it's so simple and complete that if anyone else want's to work on it, it should be really easy. I'm also not an expert at Python or Blender API so someone more experience can probably shape it up better. It's also much more stable than the official one (due to it being so small). Feel free to do anything with it or integrate it into Blender, just credit me on the file. I would love to work more on it, or even make a proper importer since I have a high level of expertise in Collada, but I have very little time and must work to earn my meals. Cheers! Juan Linietsky On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen mikkels...@gmail.com wrote: Yes that's a very relevant point. A collada solution with just positions, UVs and normals is not a solution. In that case you might as well use obj format. I went through the hard work of writing a collada importer specifically to get skinning and animation into my tech frame-work. On Sat, Jan 7, 2012 at 5:03 AM, skoti skot...@o2.pl wrote: I know Collada importer / exporter is problematic (I wrote an importer for my engine and I know that everything in the Collada can be stored in N different ways). - If you want to use the model in Second Life / Google Earth, you have to use Collada, if you want to use models in engines WebGL/Flash3D practically have to use Collada (is there any web engine with FBX importer?), Most game engines use Collada for importing data (support for FBX a few). FBX exporter also has bugs. Well, that FBX is in a blender, but it is not usually an option for people using Collada. - If someone uses Collada it not for the base mesh + uv (then using *. obj) and for skeletal animation, lights, cameras and their animation (motion, color, light and their intensity), multiUV (uv for color, normalmap ... + uv for lightmap). And all this in current Collada exporter works well. - No other exporter does not work here as well as Collada - ofc has bugs, but it has nothing what could replace the Collada in this task. In the future, Alembic can replace Collada, but not for several years. IMO, better to leave Collada, until you will be able to replace it with success to other formats like Alembic (FBX is not popular in the software and you can not replace him Collada in most tasks). On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote: Hi, I realize the proposal was harsh, but it was meant as a public statement as well (to khronos, opencollada team, etc). I don't want to blame it on
Re: [Bf-committers] Collada importer/exporter kickout
Erwin I consider this irrelevant in the current discussion. Programmers should they choose to can write .blend importers but the current discussion is what to do about collada for blender. Telling everyone to write .blend importers (incl artists) is not a viable alternative. That being said it sounds like Juan has a good start here. On Sat, Jan 7, 2012 at 9:23 AM, Erwin Coumans erwin.coum...@gmail.comwrote: You are right that in some cases an exporter is better, but in many cases a C/C++ .blend importer is a better to go. I just wanted to remind anyone reading this thread that there is an easy way to extract any data from Blender in C++, including animation curves, skinning info, textures etc, without the issues of COLLADA and FBX. I'm not familiar with baking, but you might be able to store the baked data in the .blend file. Thanks, Erwin On 7 January 2012 09:10, Juan Linietsky redu...@gmail.com wrote: Erwin, That looks awesome and really useful, however the main advantage of an importer is the ability to bake everything (IK and other constraints) just like it's displayed in Blender. Cheers Juan Linietsky On Sat, Jan 7, 2012 at 2:07 PM, Erwin Coumans erwin.coum...@gmail.com wrote: Instead of going through the COLLADA or other intermediate format you can directly extract any data from a .blend using this C++ .blend parser: http://tinyurl.com/6s7k9zw AnimKit with the .blend loader includes a small sample that loads a .blend file, extracts textures, meshes, animations, skinning and physics info. It shows a skinned skeletal animated character using AnimKit and GLUT (keeping dependencies to a minimum) Cheers, Erwin On 7 January 2012 07:38, Morten Mikkelsen mikkels...@gmail.com wrote: In my case I do not need morphs. I do need animation and skinning though. And obviously also geometries and materials. And it sounds like you have this covered? I have no sense of loyalty toward OpenCollada so if this is a viable solution I am for it. Can you make it available somewhere with instructions on how to install it so people can test it? Cheers and thanks, Morten On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky redu...@gmail.com wrote: Hi guys, I made my own Collada exporter in Python and that's what I've been using. It's less than 1k lines of code and does not depend upon any library or anything, but it exports everything except morphs. I don't have much time to work on it at the moment, but it's so simple and complete that if anyone else want's to work on it, it should be really easy. I'm also not an expert at Python or Blender API so someone more experience can probably shape it up better. It's also much more stable than the official one (due to it being so small). Feel free to do anything with it or integrate it into Blender, just credit me on the file. I would love to work more on it, or even make a proper importer since I have a high level of expertise in Collada, but I have very little time and must work to earn my meals. Cheers! Juan Linietsky On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen mikkels...@gmail.com wrote: Yes that's a very relevant point. A collada solution with just positions, UVs and normals is not a solution. In that case you might as well use obj format. I went through the hard work of writing a collada importer specifically to get skinning and animation into my tech frame-work. On Sat, Jan 7, 2012 at 5:03 AM, skoti skot...@o2.pl wrote: I know Collada importer / exporter is problematic (I wrote an importer for my engine and I know that everything in the Collada can be stored in N different ways). - If you want to use the model in Second Life / Google Earth, you have to use Collada, if you want to use models in engines WebGL/Flash3D practically have to use Collada (is there any web engine with FBX importer?), Most game engines use Collada for importing data (support for FBX a few). FBX exporter also has bugs. Well, that FBX is in a blender, but it is not usually an option for people using Collada. - If someone uses Collada it not for the base mesh + uv (then using *. obj) and for skeletal animation, lights, cameras and their animation (motion, color, light and their intensity), multiUV (uv for color, normalmap ... + uv for lightmap). And all this in current Collada exporter works well. - No other exporter does not work here as well as Collada - ofc has bugs, but it has nothing what could replace the Collada in this
Re: [Bf-committers] Collada importer/exporter kickout
I wanted to test your exporter on my example scene, but there are errors and the files are not compatible with the specification - for example in light you have a child optics ... in the specification have clarified that the optics may be only child of camera. On Sat, Jan 7, 2012 at 16:49, Juan Linietsky wrote: Ah, I tried to attach it to the e-mail, guess the mailing list does not accept attachments? Here's a dropbox link: http://dl.dropbox.com/u/53086520/io_scene_dae.zip Cheers Juan Linietsky On Sat, Jan 7, 2012 at 12:38 PM, Morten Mikkelsenmikkels...@gmail.comwrote: In my case I do not need morphs. I do need animation and skinning though. And obviously also geometries and materials. And it sounds like you have this covered? I have no sense of loyalty toward OpenCollada so if this is a viable solution I am for it. Can you make it available somewhere with instructions on how to install it so people can test it? Cheers and thanks, Morten On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietskyredu...@gmail.com wrote: Hi guys, I made my own Collada exporter in Python and that's what I've been using. It's less than 1k lines of code and does not depend upon any library or anything, but it exports everything except morphs. I don't have much time to work on it at the moment, but it's so simple and complete that if anyone else want's to work on it, it should be really easy. I'm also not an expert at Python or Blender API so someone more experience can probably shape it up better. It's also much more stable than the official one (due to it being so small). Feel free to do anything with it or integrate it into Blender, just credit me on the file. I would love to work more on it, or even make a proper importer since I have a high level of expertise in Collada, but I have very little time and must work to earn my meals. Cheers! Juan Linietsky On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsenmikkels...@gmail.com wrote: Yes that's a very relevant point. A collada solution with just positions, UVs and normals is not a solution. In that case you might as well use obj format. I went through the hard work of writing a collada importer specifically to get skinning and animation into my tech frame-work. On Sat, Jan 7, 2012 at 5:03 AM, skotiskot...@o2.pl wrote: I know Collada importer / exporter is problematic (I wrote an importer for my engine and I know that everything in the Collada can be stored in N different ways). - If you want to use the model in Second Life / Google Earth, you have to use Collada, if you want to use models in engines WebGL/Flash3D practically have to use Collada (is there any web engine with FBX importer?), Most game engines use Collada for importing data (support for FBX a few). FBX exporter also has bugs. Well, that FBX is in a blender, but it is not usually an option for people using Collada. - If someone uses Collada it not for the base mesh + uv (then using *. obj) and for skeletal animation, lights, cameras and their animation (motion, color, light and their intensity), multiUV (uv for color, normalmap ... + uv for lightmap). And all this in current Collada exporter works well. - No other exporter does not work here as well as Collada - ofc has bugs, but it has nothing what could replace the Collada in this task. In the future, Alembic can replace Collada, but not for several years. IMO, better to leave Collada, until you will be able to replace it with success to other formats like Alembic (FBX is not popular in the software and you can not replace him Collada in most tasks). On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote: Hi, I realize the proposal was harsh, but it was meant as a public statement as well (to khronos, opencollada team, etc). I don't want to blame it on the hard working devs here. We do have collada IO work at some level, and that has been proven useful in several cases. The job is just incredible hard to achieve. To move forward: - userts who successfully applied .dae could also check whether another exchange format would have done the job as good. Tried FBX? - note that for basic mesh (+uv) export, a quite simple script could do the job already. It is probably a few days job for a py scripter. - we are currently including about 100 MB of opencollada libs to make a feature work that's meant to be able to exchange (I+O) full shots or game environments, with character animation and so on. That's what Collada was designed for, and that's a target we can't support. -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 6 Jan, 2012, at 21:21, Morten Mikkelsen wrote: 1) Official announcement that Blender drops Collada support 2) Move Collada support into a branch, out of trunk
Re: [Bf-committers] Collada importer/exporter kickout
On Sat, Jan 7, 2012 at 5:30 PM, Morten Mikkelsen mikkels...@gmail.com wrote: As an example of people having problems with its complexity OpenCollada doesn't drain collada sources correctly at all. They make many assumptions such as data being non interleaved. Surely, if blender is having these problems then all the other open source programs that work with collada are too. Perhaps blender could come together with all the others and form a Collada team that can solve these problems. Just an idea. -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada importer/exporter kickout
I have done a couple of tests with Blender 2.61 to check if it exports correct for Second Life. For some reason it takes a long time to export an animatin which actually does not exist. Yes i have unchecked export animation :) The import to Second Life yields import errors. I havent tested in more depth. Maybe the script behaves wrong because it was made for 2.58 ? cheers, Gaia Am 07.01.2012 19:16, schrieb skoti: I wanted to test your exporter on my example scene, but there are errors and the files are not compatible with the specification - for example in light you have a childoptics ... in the specification have clarified that the optics may be only child ofcamera. On Sat, Jan 7, 2012 at 16:49, Juan Linietsky wrote: Ah, I tried to attach it to the e-mail, guess the mailing list does not accept attachments? Here's a dropbox link: http://dl.dropbox.com/u/53086520/io_scene_dae.zip Cheers Juan Linietsky On Sat, Jan 7, 2012 at 12:38 PM, Morten Mikkelsenmikkels...@gmail.comwrote: In my case I do not need morphs. I do need animation and skinning though. And obviously also geometries and materials. And it sounds like you have this covered? I have no sense of loyalty toward OpenCollada so if this is a viable solution I am for it. Can you make it available somewhere with instructions on how to install it so people can test it? Cheers and thanks, Morten On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietskyredu...@gmail.com wrote: Hi guys, I made my own Collada exporter in Python and that's what I've been using. It's less than 1k lines of code and does not depend upon any library or anything, but it exports everything except morphs. I don't have much time to work on it at the moment, but it's so simple and complete that if anyone else want's to work on it, it should be really easy. I'm also not an expert at Python or Blender API so someone more experience can probably shape it up better. It's also much more stable than the official one (due to it being so small). Feel free to do anything with it or integrate it into Blender, just credit me on the file. I would love to work more on it, or even make a proper importer since I have a high level of expertise in Collada, but I have very little time and must work to earn my meals. Cheers! Juan Linietsky On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsenmikkels...@gmail.com wrote: Yes that's a very relevant point. A collada solution with just positions, UVs and normals is not a solution. In that case you might as well use obj format. I went through the hard work of writing a collada importer specifically to get skinning and animation into my tech frame-work. On Sat, Jan 7, 2012 at 5:03 AM, skotiskot...@o2.pl wrote: I know Collada importer / exporter is problematic (I wrote an importer for my engine and I know that everything in the Collada can be stored in N different ways). - If you want to use the model in Second Life / Google Earth, you have to use Collada, if you want to use models in engines WebGL/Flash3D practically have to use Collada (is there any web engine with FBX importer?), Most game engines use Collada for importing data (support for FBX a few). FBX exporter also has bugs. Well, that FBX is in a blender, but it is not usually an option for people using Collada. - If someone uses Collada it not for the base mesh + uv (then using *. obj) and for skeletal animation, lights, cameras and their animation (motion, color, light and their intensity), multiUV (uv for color, normalmap ... + uv for lightmap). And all this in current Collada exporter works well. - No other exporter does not work here as well as Collada - ofc has bugs, but it has nothing what could replace the Collada in this task. In the future, Alembic can replace Collada, but not for several years. IMO, better to leave Collada, until you will be able to replace it with success to other formats like Alembic (FBX is not popular in the software and you can not replace him Collada in most tasks). On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote: Hi, I realize the proposal was harsh, but it was meant as a public statement as well (to khronos, opencollada team, etc). I don't want to blame it on the hard working devs here. We do have collada IO work at some level, and that has been proven useful in several cases. The job is just incredible hard to achieve. To move forward: - userts who successfully applied .dae could also check whether another exchange format would have done the job as good. Tried FBX? - note that for basic mesh (+uv) export, a quite simple script could do the job already. It is probably a few days job for a py scripter. - we are currently including about 100 MB of opencollada libs to make a feature work that's meant to be able to exchange (I+O) full shots or game environments, with character animation and so on. That's what Collada was designed for, and
Re: [Bf-committers] Collada importer/exporter kickout
@Morton A C++ .blend importer may not be a viable alternative for some people (artists) but using an existing open source C++ .blend importer can be a viable alternative for programmers. It would be great to have well maintained COLLADA export/import for Blender of course, so good luck if someone can create and maintain a Python implementation. Peter Amstutz wrote When I looked last looked at OpenCollada, one critical issue preventing someone else from taking over maintenance is the fact that it relied heavily on autogenerated code, but the code generator and the input file are not included in the online repository. That is a serious issue. Did someone try to make those code generation files available? There would also needs to be a set of test cases, Khronos/COLLADA workgroup has an extensive conformance tests, unfortunately they are only available to members. If someone starts maintaining OpenCollada, they probably can get access to those conformance tests. Thanks, Erwin On 7 January 2012 09:47, Morten Mikkelsen mikkels...@gmail.com wrote: Erwin I consider this irrelevant in the current discussion. Programmers should they choose to can write .blend importers but the current discussion is what to do about collada for blender. Telling everyone to write .blend importers (incl artists) is not a viable alternative. That being said it sounds like Juan has a good start here. On Sat, Jan 7, 2012 at 9:23 AM, Erwin Coumans erwin.coum...@gmail.com wrote: You are right that in some cases an exporter is better, but in many cases a C/C++ .blend importer is a better to go. I just wanted to remind anyone reading this thread that there is an easy way to extract any data from Blender in C++, including animation curves, skinning info, textures etc, without the issues of COLLADA and FBX. I'm not familiar with baking, but you might be able to store the baked data in the .blend file. Thanks, Erwin On 7 January 2012 09:10, Juan Linietsky redu...@gmail.com wrote: Erwin, That looks awesome and really useful, however the main advantage of an importer is the ability to bake everything (IK and other constraints) just like it's displayed in Blender. Cheers Juan Linietsky On Sat, Jan 7, 2012 at 2:07 PM, Erwin Coumans erwin.coum...@gmail.com wrote: Instead of going through the COLLADA or other intermediate format you can directly extract any data from a .blend using this C++ .blend parser: http://tinyurl.com/6s7k9zw AnimKit with the .blend loader includes a small sample that loads a .blend file, extracts textures, meshes, animations, skinning and physics info. It shows a skinned skeletal animated character using AnimKit and GLUT (keeping dependencies to a minimum) Cheers, Erwin On 7 January 2012 07:38, Morten Mikkelsen mikkels...@gmail.com wrote: In my case I do not need morphs. I do need animation and skinning though. And obviously also geometries and materials. And it sounds like you have this covered? I have no sense of loyalty toward OpenCollada so if this is a viable solution I am for it. Can you make it available somewhere with instructions on how to install it so people can test it? Cheers and thanks, Morten On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky redu...@gmail.com wrote: Hi guys, I made my own Collada exporter in Python and that's what I've been using. It's less than 1k lines of code and does not depend upon any library or anything, but it exports everything except morphs. I don't have much time to work on it at the moment, but it's so simple and complete that if anyone else want's to work on it, it should be really easy. I'm also not an expert at Python or Blender API so someone more experience can probably shape it up better. It's also much more stable than the official one (due to it being so small). Feel free to do anything with it or integrate it into Blender, just credit me on the file. I would love to work more on it, or even make a proper importer since I have a high level of expertise in Collada, but I have very little time and must work to earn my meals. Cheers! Juan Linietsky On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen mikkels...@gmail.com wrote: Yes that's a very relevant point. A collada solution with just positions, UVs and normals is not a solution. In that case you might as well use obj format. I went through the hard work of writing a collada importer specifically to get skinning and animation into my tech frame-work. On Sat, Jan 7, 2012 at 5:03
Re: [Bf-committers] Collada importer/exporter kickout
Hi Erwin. I don't think .blend importer is very good idea. We need a 3D format like .png for images because it makes easier to share projects between programs. There is probably 10-20 major programs which people use with Blender. So, writing for each of them an extension for .blend importer is not realistic. In addition, the implentation will be very basic due to their quantity. Another problem is .blend format. .blend is essentially a dump of blender's program memory. It has useless data like different preferences and other internal data which intended for blender use only. Moreover, there is no standard for .blend file. File format is constantly evolving. Therefore C importer must constantly reflect changes and so the plugins. It is better to have a very solid importer/exporter for universal 3d format. If there is no good opensource library, it is better to write it ourselves, rather then to support 20 importers/exporters different quality. Best Regards, Alex On Sat, Jan 7, 2012 at 2:16 PM, Erwin Coumans erwin.coum...@gmail.comwrote: @Morton A C++ .blend importer may not be a viable alternative for some people (artists) but using an existing open source C++ .blend importer can be a viable alternative for programmers. It would be great to have well maintained COLLADA export/import for Blender of course, so good luck if someone can create and maintain a Python implementation. Peter Amstutz wrote When I looked last looked at OpenCollada, one critical issue preventing someone else from taking over maintenance is the fact that it relied heavily on autogenerated code, but the code generator and the input file are not included in the online repository. That is a serious issue. Did someone try to make those code generation files available? There would also needs to be a set of test cases, Khronos/COLLADA workgroup has an extensive conformance tests, unfortunately they are only available to members. If someone starts maintaining OpenCollada, they probably can get access to those conformance tests. Thanks, Erwin On 7 January 2012 09:47, Morten Mikkelsen mikkels...@gmail.com wrote: Erwin I consider this irrelevant in the current discussion. Programmers should they choose to can write .blend importers but the current discussion is what to do about collada for blender. Telling everyone to write .blend importers (incl artists) is not a viable alternative. That being said it sounds like Juan has a good start here. On Sat, Jan 7, 2012 at 9:23 AM, Erwin Coumans erwin.coum...@gmail.com wrote: You are right that in some cases an exporter is better, but in many cases a C/C++ .blend importer is a better to go. I just wanted to remind anyone reading this thread that there is an easy way to extract any data from Blender in C++, including animation curves, skinning info, textures etc, without the issues of COLLADA and FBX. I'm not familiar with baking, but you might be able to store the baked data in the .blend file. Thanks, Erwin On 7 January 2012 09:10, Juan Linietsky redu...@gmail.com wrote: Erwin, That looks awesome and really useful, however the main advantage of an importer is the ability to bake everything (IK and other constraints) just like it's displayed in Blender. Cheers Juan Linietsky On Sat, Jan 7, 2012 at 2:07 PM, Erwin Coumans erwin.coum...@gmail.com wrote: Instead of going through the COLLADA or other intermediate format you can directly extract any data from a .blend using this C++ .blend parser: http://tinyurl.com/6s7k9zw AnimKit with the .blend loader includes a small sample that loads a .blend file, extracts textures, meshes, animations, skinning and physics info. It shows a skinned skeletal animated character using AnimKit and GLUT (keeping dependencies to a minimum) Cheers, Erwin On 7 January 2012 07:38, Morten Mikkelsen mikkels...@gmail.com wrote: In my case I do not need morphs. I do need animation and skinning though. And obviously also geometries and materials. And it sounds like you have this covered? I have no sense of loyalty toward OpenCollada so if this is a viable solution I am for it. Can you make it available somewhere with instructions on how to install it so people can test it? Cheers and thanks, Morten On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky redu...@gmail.com wrote: Hi guys, I made my own Collada exporter in Python and that's what I've been using. It's less than 1k lines of code and does not depend upon any library or anything, but it exports everything except morphs. I don't have much time to work on it at the moment, but it's so
Re: [Bf-committers] Collada importer/exporter kickout
Before writing my Collada Exporter I actually checked Erwin's work on Bullet's Blender importer, but back then it was a little outdated and also had that problem of efficiently baking stuff (like for example, IK or curve follow constraint for a rollercoaster or some camera animations). I'm sure if baking support was added for it, it would be really useful for us game developers. BTW, and also irrelevant to the current discussion, Erwin is my hero so please be nice to him :D Juan On Sat, Jan 7, 2012 at 2:47 PM, Morten Mikkelsen mikkels...@gmail.comwrote: Erwin I consider this irrelevant in the current discussion. Programmers should they choose to can write .blend importers but the current discussion is what to do about collada for blender. Telling everyone to write .blend importers (incl artists) is not a viable alternative. That being said it sounds like Juan has a good start here. On Sat, Jan 7, 2012 at 9:23 AM, Erwin Coumans erwin.coum...@gmail.com wrote: You are right that in some cases an exporter is better, but in many cases a C/C++ .blend importer is a better to go. I just wanted to remind anyone reading this thread that there is an easy way to extract any data from Blender in C++, including animation curves, skinning info, textures etc, without the issues of COLLADA and FBX. I'm not familiar with baking, but you might be able to store the baked data in the .blend file. Thanks, Erwin On 7 January 2012 09:10, Juan Linietsky redu...@gmail.com wrote: Erwin, That looks awesome and really useful, however the main advantage of an importer is the ability to bake everything (IK and other constraints) just like it's displayed in Blender. Cheers Juan Linietsky On Sat, Jan 7, 2012 at 2:07 PM, Erwin Coumans erwin.coum...@gmail.com wrote: Instead of going through the COLLADA or other intermediate format you can directly extract any data from a .blend using this C++ .blend parser: http://tinyurl.com/6s7k9zw AnimKit with the .blend loader includes a small sample that loads a .blend file, extracts textures, meshes, animations, skinning and physics info. It shows a skinned skeletal animated character using AnimKit and GLUT (keeping dependencies to a minimum) Cheers, Erwin On 7 January 2012 07:38, Morten Mikkelsen mikkels...@gmail.com wrote: In my case I do not need morphs. I do need animation and skinning though. And obviously also geometries and materials. And it sounds like you have this covered? I have no sense of loyalty toward OpenCollada so if this is a viable solution I am for it. Can you make it available somewhere with instructions on how to install it so people can test it? Cheers and thanks, Morten On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky redu...@gmail.com wrote: Hi guys, I made my own Collada exporter in Python and that's what I've been using. It's less than 1k lines of code and does not depend upon any library or anything, but it exports everything except morphs. I don't have much time to work on it at the moment, but it's so simple and complete that if anyone else want's to work on it, it should be really easy. I'm also not an expert at Python or Blender API so someone more experience can probably shape it up better. It's also much more stable than the official one (due to it being so small). Feel free to do anything with it or integrate it into Blender, just credit me on the file. I would love to work more on it, or even make a proper importer since I have a high level of expertise in Collada, but I have very little time and must work to earn my meals. Cheers! Juan Linietsky On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen mikkels...@gmail.com wrote: Yes that's a very relevant point. A collada solution with just positions, UVs and normals is not a solution. In that case you might as well use obj format. I went through the hard work of writing a collada importer specifically to get skinning and animation into my tech frame-work. On Sat, Jan 7, 2012 at 5:03 AM, skoti skot...@o2.pl wrote: I know Collada importer / exporter is problematic (I wrote an importer for my engine and I know that everything in the Collada can be stored in N different ways). - If you want to use the model in Second Life / Google Earth, you have to use Collada, if you want to use models in engines WebGL/Flash3D practically have to use Collada (is there any web engine with FBX importer?),
Re: [Bf-committers] Collada importer/exporter kickout
Yeah I'm not sure it's 100% bug-free, but if you look at the source code, it's so simple that such issues are very easy to fix. On Sat, Jan 7, 2012 at 3:16 PM, skoti skot...@o2.pl wrote: I wanted to test your exporter on my example scene, but there are errors and the files are not compatible with the specification - for example in light you have a child optics ... in the specification have clarified that the optics may be only child of camera. On Sat, Jan 7, 2012 at 16:49, Juan Linietsky wrote: Ah, I tried to attach it to the e-mail, guess the mailing list does not accept attachments? Here's a dropbox link: http://dl.dropbox.com/u/53086520/io_scene_dae.zip Cheers Juan Linietsky On Sat, Jan 7, 2012 at 12:38 PM, Morten Mikkelsenmikkels...@gmail.com wrote: In my case I do not need morphs. I do need animation and skinning though. And obviously also geometries and materials. And it sounds like you have this covered? I have no sense of loyalty toward OpenCollada so if this is a viable solution I am for it. Can you make it available somewhere with instructions on how to install it so people can test it? Cheers and thanks, Morten On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietskyredu...@gmail.com wrote: Hi guys, I made my own Collada exporter in Python and that's what I've been using. It's less than 1k lines of code and does not depend upon any library or anything, but it exports everything except morphs. I don't have much time to work on it at the moment, but it's so simple and complete that if anyone else want's to work on it, it should be really easy. I'm also not an expert at Python or Blender API so someone more experience can probably shape it up better. It's also much more stable than the official one (due to it being so small). Feel free to do anything with it or integrate it into Blender, just credit me on the file. I would love to work more on it, or even make a proper importer since I have a high level of expertise in Collada, but I have very little time and must work to earn my meals. Cheers! Juan Linietsky On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsenmikkels...@gmail.com wrote: Yes that's a very relevant point. A collada solution with just positions, UVs and normals is not a solution. In that case you might as well use obj format. I went through the hard work of writing a collada importer specifically to get skinning and animation into my tech frame-work. On Sat, Jan 7, 2012 at 5:03 AM, skotiskot...@o2.pl wrote: I know Collada importer / exporter is problematic (I wrote an importer for my engine and I know that everything in the Collada can be stored in N different ways). - If you want to use the model in Second Life / Google Earth, you have to use Collada, if you want to use models in engines WebGL/Flash3D practically have to use Collada (is there any web engine with FBX importer?), Most game engines use Collada for importing data (support for FBX a few). FBX exporter also has bugs. Well, that FBX is in a blender, but it is not usually an option for people using Collada. - If someone uses Collada it not for the base mesh + uv (then using *. obj) and for skeletal animation, lights, cameras and their animation (motion, color, light and their intensity), multiUV (uv for color, normalmap ... + uv for lightmap). And all this in current Collada exporter works well. - No other exporter does not work here as well as Collada - ofc has bugs, but it has nothing what could replace the Collada in this task. In the future, Alembic can replace Collada, but not for several years. IMO, better to leave Collada, until you will be able to replace it with success to other formats like Alembic (FBX is not popular in the software and you can not replace him Collada in most tasks). On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote: Hi, I realize the proposal was harsh, but it was meant as a public statement as well (to khronos, opencollada team, etc). I don't want to blame it on the hard working devs here. We do have collada IO work at some level, and that has been proven useful in several cases. The job is just incredible hard to achieve. To move forward: - userts who successfully applied .dae could also check whether another exchange format would have done the job as good. Tried FBX? - note that for basic mesh (+uv) export, a quite simple script could do the job already. It is probably a few days job for a py scripter. - we are currently including about 100 MB of opencollada libs to make a feature work that's meant to be able to exchange (I+O) full shots or game environments, with character animation and so on. That's what Collada was designed for, and that's a target we can't support. -Ton-
Re: [Bf-committers] Collada importer/exporter kickout
I think unless there is a skeleton, it samples animation of anything that has curves. As said, while it exprors everything, it needs some little tweaking, but the source code is so simple that it should be easy to fix. On Sat, Jan 7, 2012 at 3:34 PM, Gaia Clary gaia.cl...@machinimatrix.orgwrote: I have done a couple of tests with Blender 2.61 to check if it exports correct for Second Life. For some reason it takes a long time to export an animatin which actually does not exist. Yes i have unchecked export animation :) The import to Second Life yields import errors. I havent tested in more depth. Maybe the script behaves wrong because it was made for 2.58 ? cheers, Gaia Am 07.01.2012 19:16, schrieb skoti: I wanted to test your exporter on my example scene, but there are errors and the files are not compatible with the specification - for example in light you have a childoptics ... in the specification have clarified that the optics may be only child ofcamera. On Sat, Jan 7, 2012 at 16:49, Juan Linietsky wrote: Ah, I tried to attach it to the e-mail, guess the mailing list does not accept attachments? Here's a dropbox link: http://dl.dropbox.com/u/53086520/io_scene_dae.zip Cheers Juan Linietsky On Sat, Jan 7, 2012 at 12:38 PM, Morten Mikkelsenmikkels...@gmail.com wrote: In my case I do not need morphs. I do need animation and skinning though. And obviously also geometries and materials. And it sounds like you have this covered? I have no sense of loyalty toward OpenCollada so if this is a viable solution I am for it. Can you make it available somewhere with instructions on how to install it so people can test it? Cheers and thanks, Morten On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietskyredu...@gmail.com wrote: Hi guys, I made my own Collada exporter in Python and that's what I've been using. It's less than 1k lines of code and does not depend upon any library or anything, but it exports everything except morphs. I don't have much time to work on it at the moment, but it's so simple and complete that if anyone else want's to work on it, it should be really easy. I'm also not an expert at Python or Blender API so someone more experience can probably shape it up better. It's also much more stable than the official one (due to it being so small). Feel free to do anything with it or integrate it into Blender, just credit me on the file. I would love to work more on it, or even make a proper importer since I have a high level of expertise in Collada, but I have very little time and must work to earn my meals. Cheers! Juan Linietsky On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen mikkels...@gmail.com wrote: Yes that's a very relevant point. A collada solution with just positions, UVs and normals is not a solution. In that case you might as well use obj format. I went through the hard work of writing a collada importer specifically to get skinning and animation into my tech frame-work. On Sat, Jan 7, 2012 at 5:03 AM, skotiskot...@o2.pl wrote: I know Collada importer / exporter is problematic (I wrote an importer for my engine and I know that everything in the Collada can be stored in N different ways). - If you want to use the model in Second Life / Google Earth, you have to use Collada, if you want to use models in engines WebGL/Flash3D practically have to use Collada (is there any web engine with FBX importer?), Most game engines use Collada for importing data (support for FBX a few). FBX exporter also has bugs. Well, that FBX is in a blender, but it is not usually an option for people using Collada. - If someone uses Collada it not for the base mesh + uv (then using *. obj) and for skeletal animation, lights, cameras and their animation (motion, color, light and their intensity), multiUV (uv for color, normalmap ... + uv for lightmap). And all this in current Collada exporter works well. - No other exporter does not work here as well as Collada - ofc has bugs, but it has nothing what could replace the Collada in this task. In the future, Alembic can replace Collada, but not for several years. IMO, better to leave Collada, until you will be able to replace it with success to other formats like Alembic (FBX is not popular in the software and you can not replace him Collada in most tasks). On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote: Hi, I realize the proposal was harsh, but it was meant as a public statement as well (to khronos, opencollada team, etc). I don't want to blame it on the hard working devs here. We do have collada IO work at some level, and that has been proven useful in several cases. The job is just incredible hard to achieve. To move forward: - userts who successfully applied .dae could also check whether another
Re: [Bf-committers] Collada importer/exporter kickout
I agree that a well maintained open source library for a stable 3D format is best. I just spoke to Sebastian from OpenCollada and asked him to open source the code generation files, so here you go: http://code.google.com/p/opencollada/source/detail?r=867 I think improving the OpenCollada project is better than promoting FBX in the long run. Until that happens, we need to have some pragmatic solutions to get rich data out of Blender. Juan's Python .dae exporter is one solution, a .blend reader another. The Blender .blend format is suprisingly stable, and we keep our .blend importer up-to-date (we can handle old-style animations and new style, and once bmesh is available we will support it too) Thanks, Erwin On 7 January 2012 12:04, Juan Linietsky redu...@gmail.com wrote: Before writing my Collada Exporter I actually checked Erwin's work on Bullet's Blender importer, but back then it was a little outdated and also had that problem of efficiently baking stuff (like for example, IK or curve follow constraint for a rollercoaster or some camera animations). I'm sure if baking support was added for it, it would be really useful for us game developers. BTW, and also irrelevant to the current discussion, Erwin is my hero so please be nice to him :D Juan On Sat, Jan 7, 2012 at 2:47 PM, Morten Mikkelsen mikkels...@gmail.com wrote: Erwin I consider this irrelevant in the current discussion. Programmers should they choose to can write .blend importers but the current discussion is what to do about collada for blender. Telling everyone to write .blend importers (incl artists) is not a viable alternative. That being said it sounds like Juan has a good start here. On Sat, Jan 7, 2012 at 9:23 AM, Erwin Coumans erwin.coum...@gmail.com wrote: You are right that in some cases an exporter is better, but in many cases a C/C++ .blend importer is a better to go. I just wanted to remind anyone reading this thread that there is an easy way to extract any data from Blender in C++, including animation curves, skinning info, textures etc, without the issues of COLLADA and FBX. I'm not familiar with baking, but you might be able to store the baked data in the .blend file. Thanks, Erwin On 7 January 2012 09:10, Juan Linietsky redu...@gmail.com wrote: Erwin, That looks awesome and really useful, however the main advantage of an importer is the ability to bake everything (IK and other constraints) just like it's displayed in Blender. Cheers Juan Linietsky On Sat, Jan 7, 2012 at 2:07 PM, Erwin Coumans erwin.coum...@gmail.com wrote: Instead of going through the COLLADA or other intermediate format you can directly extract any data from a .blend using this C++ .blend parser: http://tinyurl.com/6s7k9zw AnimKit with the .blend loader includes a small sample that loads a .blend file, extracts textures, meshes, animations, skinning and physics info. It shows a skinned skeletal animated character using AnimKit and GLUT (keeping dependencies to a minimum) Cheers, Erwin On 7 January 2012 07:38, Morten Mikkelsen mikkels...@gmail.com wrote: In my case I do not need morphs. I do need animation and skinning though. And obviously also geometries and materials. And it sounds like you have this covered? I have no sense of loyalty toward OpenCollada so if this is a viable solution I am for it. Can you make it available somewhere with instructions on how to install it so people can test it? Cheers and thanks, Morten On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky redu...@gmail.com wrote: Hi guys, I made my own Collada exporter in Python and that's what I've been using. It's less than 1k lines of code and does not depend upon any library or anything, but it exports everything except morphs. I don't have much time to work on it at the moment, but it's so simple and complete that if anyone else want's to work on it, it should be really easy. I'm also not an expert at Python or Blender API so someone more experience can probably shape it up better. It's also much more stable than the official one (due to it being so small). Feel free to do anything with it or integrate it into Blender, just credit me on the file. I would love to work more on it, or even make a proper importer since I have a high level of expertise in Collada, but I have very little time and must work to earn my meals. Cheers! Juan Linietsky On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen
[Bf-committers] Collada importer/exporter kickout
Hi All, just noticed commit http://code.google.com/p/opencollada/source/detail?r=867 to OpenCOLLADA rep which resolves the mentioned problem with OpenCOLLADA, that library to generate code from XSD schema is absent. the issue, at least, starts to be adressed. Regards Sergey ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] collada
hey i am hearing that your planning on removing collada!! i know there is a lot of issues with it but, at-least as it is right now it can be made to work. a lot of people depend on this as their intermediate file format, now i know no one likes the idea of what i am doing (cryblend) but someone had to, blender is so much more awesome than the other 3(no... seriously) and to be able to use it to create assets for a MAJOR game engine( blender game engine rocks too) and i am not just talking about static meshes, you guys need to check out the stats : http://www.crydev.net/viewtopic.php?f=315t=80167 look at the downloads on sourceforge look at the video views on youtube look at the page views for the above link (its even been stickified), the more i get working the more people are interested. AND YES i do want to contribute back to the blender community, i dont have clean code to do so yet( its ugly and hacked ,but works) with good collada suport (decide on udp howto, and give access through python so someone can make a proper addon) blender would most definitely become a top choice for game devs indie or not. in conclusion a half hearted implementation is so much more valuable than none at all, at-least people who rely on it have something to work with. thankyou for reading, angjminer. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada importer/exporter kickout
I reply as a middleware and tool developer, not as blender developer. This may not be the place, but I believe my concerns also cover what Blender is doing. My problem with OpenCollada: 1) It's way too big, and most apps don't need to either import or export most of the format. Take a look at my Python exporter, which does most of the job and it takes much fewer lines than even an interface with OpenCollada. It's a lot of code to add to a project/repo and enlarges the binary unnecesarily. 2) A strong point for using a library such as OpenCollada is proper validation of the incoming DAE files. However, in the real world, it's easy to find sightly broken files that you would rather import anyway than being format nazi and refuse the import. Being honest, not even OpenCollada plugins for MAX and Maya open their own DAEs most of the time. 3) It's been a lot of years and I still can't understand why there is such a good support for MAX and Maya, and zero Blender support. Aren't Khronos and ithe companies it represents supposed to fund and/or encourage adoption of their format, yet the most open of the 3D modellers does not support the most open 3D format? 4) Collada is an open format, but most apps that support it export their data in different but valid ways. An example of this is the export of skeletons, the usage of the inverse bind transform, how named/vs unnamed bones are used, etc. Most apps that wish to import Collada don't work internally like Collada and already have to do an important effort to guess what the DAE layout looks like. OpenCollada is just too general purpose and does not help this situation. Back then, other implementations such as FCollada provided several tools that aided in the guesswork or provided data the way it was meant to, so at least you could save writing some code or doing some guessing. 5) I don't think blender should have yet another DAE importer/exporter, but something custom tailored to it's needs. I already wrote several Collada importers for middleware or propertary game engines and can attest that most of the work is not really importing Collada itself (what OpenCollada does), but guessing how the Collada file is laid out and how to translate that to the way Blender works. Using a large library such as OC only adds an unnecesary layer of complexity at the simpler part of a problem. 6) Collada is a very outdated format at this point. There is no support for constraints, material support is still really poor (still no official support for normal mapping or displacement mapping, let alone any sort of node-based materials), multiple texcoord support is broken because each app exports it any way it wants, and many other issues. This could be solved simply by going the FBX way and exporting blender-only extensions (besides the standard stuff) in a DAE, describing the full blender material or something, so importers can do the best at guessing, and save artist time from having to reimplement materials all over again when importing. I'm not sure how well can OC do this. Exporting custom properties is also really useful. Cheers Juan Linietsky ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada importer/exporter kickout
I acknowledge that the amount of work you guys have put into OpenCollada is significant and I am definitely pleased with this as an option. That being said I am beginning to warm up to what sergei is suggesting more and I am actually a collada user myself. Correct me if I am wrong but the way it works for autodesk these products by default ship with some crappy collada exporter that someone within the castle of autodesk has authored. Then as an alternative option you guys made OpenCollada plugins available for Maya and 3dsmax from your website correct? So when you think about it is there really any harm in Blender shipping with a crappy collada exporter of its own, like autodesk, and then having the option of downloading an OpenCollada blugin for Blender from an off-site location as well (Possibly even your site)? And Juan no offense intended here I am just making a comparison. I am not saying your code is literally crappy! Cheers, Morten. On Sat, Jan 7, 2012 at 1:22 PM, Sebastian sebast...@opencollada.org wrote: Erwin already announced it: I've contributed the code generation libraries under the MIT license and committed it to our Subversion repository. You should see this as our commitment to the future of OpenCOLLADA. OpenCOLLADA is and was a lot of work, it's far away from being perfect or even error free but I would not suggest to develop yet another DAE importer/exporter specifically for Blender or even drop support for it. For the COLLADA community Blender is definitely one of the most important stakeholders to stop supporting COLLADA would make things in DCC exchange even worse. We are currently discussing further financing of OpenCOLLADA and will spend more time the next months on bugfixing and conformance tests. Sebastian ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada importer/exporter kickout
And Juan no offense intended here I am just making a comparison. I am not saying your code is literally crappy! The word crappy is completely subjective. In this case, what matters is: 1) Whether something works or not. It may have bugs and need a little more work in the export options area, but it definitely does work (or is very close). 2) How easy it is to maintain. I think we can agree that a ~1k loc python codebase is much easier to maintain than a huge library and wrapper code. Cheers Juan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada importer/exporter kickout
Okay I guess you did misunderstand my misuse of the word crappy. What I meant was more like less likely to work with existing OpenCollada importers. Those which are already used in other apps. Clearly an OpenCollada exporter is more likely to work with an OpenCollada importer across apps. This was all I meant really. And implicitly this was also what Sebastian was saying in regards to the dangers of introducing yet another one. It's really a reflection of the Collada format being ridiculously broad. I am not calling anyone's code literally crap so sorry I misused this work. On Sat, Jan 7, 2012 at 3:24 PM, Juan Linietsky redu...@gmail.com wrote: And Juan no offense intended here I am just making a comparison. I am not saying your code is literally crappy! The word crappy is completely subjective. In this case, what matters is: 1) Whether something works or not. It may have bugs and need a little more work in the export options area, but it definitely does work (or is very close). 2) How easy it is to maintain. I think we can agree that a ~1k loc python codebase is much easier to maintain than a huge library and wrapper code. Cheers Juan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] collada
I agree Marty. It's awesome. Give my best to the doc! :) On Sat, Jan 7, 2012 at 2:29 PM, Michael Fox mfoxd...@gmail.com wrote: On 08/01/12 08:28, angjmi...@gulftel.com wrote: hey i am hearing that your planning on removing collada!! i know there is a lot of issues with it but, at-least as it is right now it can be made to work. a lot of people depend on this as their intermediate file format, now i know no one likes the idea of what i am doing (cryblend) but someone had to, sorry to go a bit off here, but why would no one like what you have done with cryblend, i think its absolutely awesome what you have done (even posted about it on G+) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada importer/exporter kickout
On Sun, Jan 8, 2012 at 12:03 AM, skoti skot...@o2.pl wrote: I know Collada importer / exporter is problematic (I wrote an importer for my engine and I know that everything in the Collada can be stored in N different ways). - If you want to use the model in Second Life / Google Earth, you have to use Collada, if you want to use models in engines WebGL/Flash3D practically have to use Collada (is there any web engine with FBX importer?), Most game engines use Collada for importing data (support for FBX a few). FBX exporter also has bugs. Well, that FBX is in a blender, but it is not usually an option for people using Collada. Can you report these bugs please? I'm no great fan of FBX/Autodesk with their idiotic EULA, but as maintainer of FBX export I rather not have it be buggy. Note that FBX has similar issues as collada, which is that different applications support different parts of the FBX spec - so Lightwave and Maya for example complain when importing non uniform scaled bones from blender for EG because they don't support it. So you cant assume just because a single application chokes on a blender FBX model that it is a blender bug for sure. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Dynamic subdivision sculpting (Unlimited Clay) paper
Hi Raul, skimming through your paper right now. It seems straightforward enough but one question I have remaining is what happens to extraordinary vertices after all in the subdivision phase. Do they get simplified somehow? (how?). Do they get excluded from further subdivision? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
