Re: [Bf-committers] Annoucement: Better Collada Exporter for Blender!
> > Juan, i don't expect a silver bullet and i don't even believe in this. But > 3 days ago you claimed "This plugin is very battle-tested, and files > written by it can be read by most DCCs and engine", now you say "You can't > write an exporter thinking that you will please every importer out there". > This two things i can't really link together. So the questions so far: > > Why not? they are not mutually exclusive. The problem is that, again, you are expecting a silver bullet. When I claim it works, it means they can import the files, the problem is that Collada support in most engines and DCCs is very incomplete in general. If you export exactly that is supported by the importer, it works. If you export more, it generally doesn't, and the engine/DCC will crash and burn. My Collada exporter basically tries to mimic the same exporter format that OpenCollada Maya uses, which is why it's so compatible (as that is the most popular plugin used). So, if you want me to explain it in a different way, it should work as well as the best collada exporter it exists as the moment, but at the same time that's not necessarily good. > - Is current blender's importer capable of importing the exported by the > addon scene? > Yes, but it crashes in some scenes that use complex stuff such as morphs+skeletons. This is a problem of Blender's importer, not the exporter, as it exhibits the same behavior with other exporters (such as Maya Opencollada). Animations work fine, but animation clips do not work (which I believe are not supported anyway by the importer). > - Which engines/software are supported with the current state of the addon? > Tested Unity, works with most stuff but does not support clips, materials, etc. Unity should fix this. I know people used it with the Amnesia engine, and with Crytek and it worked pretty well. > - What are the plans about extending supported 3d party apps? > As I said before, the collada format exported is based in OpenCollada Maya, which is the best Collada exporter. It does not do anything weird nor imposes another way of exporting the format. If a 3rd party app does not work it's most likely the fault of that app, not because my exporter needs to be more compatible. > - What are the plans about importer? > None. > - Who's gonna to maintain the code? > I develop and maintain the code. > - Does someone from blender users tested the addon? > > Plenty of users to export to Godot, a few other users to export to other engines, but they have no way to know it exists unless it's integrated as core. I already explained this well enough. > But maybe the biggest one to be answered first: what are the benefits for > blender from the current state of the addon? > > -My exporter works, period. If you think it doesn't then I leave the burden of proof to you, and I take responsibility to fix anything that might not. -It supports the full Collada feature set (except physics, but no one uses that). -Has better export filters. -Can export multiple actions as clips, and bakes constraints on export. Without this exporting characters or interactive scenes is a pain in the ass. -It's only 1400 lines of python code. -Developer did not abandon it, nor does plan to abandon it. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Annoucement: Better Collada Exporter for Blender!
Another user here Leaving aside the new collada exporter.. but talking more about exporting for game engines in general I think that the collada spec may be ambiguous, but if blender developers and other game engine developers (ue4 and godot for example) work together, a more consistent spec can be made of it, maybe we could get to a open source official importer-exporter (like ogg opus, xiph made the open standard, the encoder and decoder are open source and maintained by them, so people are not interested in making their own encoder-decoder, but in getting the official one better). If collada is a hard beast to deal with, it may be a better idea to create a new more strict spec, maybe based in collada (or maybe not, if collada is a bad example to follow, i dont know), collaborating with game engine developers, and creating and maintaining an open importer-exporter that blender and game engines implement and contribute to... also, with a common official imp/exporter, the community would have something to test against when creating new importers/exporters (like in other languages) and it would be easier to achieve compatibility... Epic has announced his interest in making indie games easier to make with UE, and I feel they would be very receptive to talk about this and get the team to work in this with blender developers, and i'm pretty sure that many other game engine developers would be pleased to collaborate too. Sorry for my bad english if you see any mistakes ;) - BoteRock On Sun, Oct 12, 2014 at 5:25 PM, Sergey Sharybin wrote: > Juan, i don't expect a silver bullet and i don't even believe in this. But > 3 days ago you claimed "This plugin is very battle-tested, and files > written by it can be read by most DCCs and engine", now you say "You can't > write an exporter thinking that you will please every importer out there". > This two things i can't really link together. So the questions so far: > > - Is current blender's importer capable of importing the exported by the > addon scene? > - Which engines/software are supported with the current state of the addon? > - What are the plans about extending supported 3d party apps? > - What are the plans about importer? > - Who's gonna to maintain the code? > - Does someone from blender users tested the addon? > > But maybe the biggest one to be answered first: what are the benefits for > blender from the current state of the addon? > > Timur, speed is kind of separated topic. It exists for sure, but can it be > discussed as a separate topic perhaps? > > On Mon, Oct 13, 2014 at 2:27 AM, Timur Ariman > wrote: > > > > > Hello Ton,Sergey,Juan, > > > > from a pure user standpoint ; > > > > one big hurdle regardless of file format(s) within Blender is that the > > python based import/exporter scripts are really slow, it takes in the > worst > > cases a couple minutes to do a I/O of a "huge" file. > > It would be good to optimize first the speed of loading and writing files > > when it comes to interchanging files between different 3d programs. > > for a start it would be great tom optimize obj.. > > this alone would tremendously help a lot of users and suercases while > the > > discussion over the game engine related fileformat(s) keeps ongoing. > > > > > > for game engine related stuff; > > > > the interest for > > the collada exporter is for UE4+Blender users at the moment is rather > > slim due to the fact that collada isn´t inlcuded (yet?*) into Unreal... > > > > > > * Epic proposed to include the collada fileformat back a few month for > > Blender users if there is interest. > > > > it seems that there is a new maintainer - Juan available for an I/O > > Collada script in Blender available... > > give it a try and also inform Epic of a possible collada solution so the > > users can test it in their engine. > > > > > > > > maybe for "security" take the same route as the fbx fileformat got and > add > > it as an "experimental Addon " so interested Blender users can easily > > activate it and switch between the already existing nowadays unmaintained > > collada code inside Blender and the new code which is maintained by > Juan?! > > > > I think this is a first possible start for a solution because then the > > users can more easily start battle testing the new collada code. > > > > > > > > > > > > > > > > > > Juan Linietsky schrieb am 21:48 Sonntag, 12.Oktober > > 2014: > > > > > > > > > > > > > > > > >Sergey: > > > > > >You seem to be somehow expecting a magic bullet. You can't write an > > >exporter thinking that you will please every importer out there, > specially > > >for a format as ambiguous as Collada. The best you can do is to export a > > >correct file and then work with those who have importers to make sure > they > > >are reading it properly. If users report an issue with an exported file > > not > > >working with a specific DCC, first you make sure that the file is being > > >exported correcty. If not, then the exporter is fixed
Re: [Bf-committers] Annoucement: Better Collada Exporter for Blender!
Juan, i don't expect a silver bullet and i don't even believe in this. But 3 days ago you claimed "This plugin is very battle-tested, and files written by it can be read by most DCCs and engine", now you say "You can't write an exporter thinking that you will please every importer out there". This two things i can't really link together. So the questions so far: - Is current blender's importer capable of importing the exported by the addon scene? - Which engines/software are supported with the current state of the addon? - What are the plans about extending supported 3d party apps? - What are the plans about importer? - Who's gonna to maintain the code? - Does someone from blender users tested the addon? But maybe the biggest one to be answered first: what are the benefits for blender from the current state of the addon? Timur, speed is kind of separated topic. It exists for sure, but can it be discussed as a separate topic perhaps? On Mon, Oct 13, 2014 at 2:27 AM, Timur Ariman wrote: > > Hello Ton,Sergey,Juan, > > from a pure user standpoint ; > > one big hurdle regardless of file format(s) within Blender is that the > python based import/exporter scripts are really slow, it takes in the worst > cases a couple minutes to do a I/O of a "huge" file. > It would be good to optimize first the speed of loading and writing files > when it comes to interchanging files between different 3d programs. > for a start it would be great tom optimize obj.. > this alone would tremendously help a lot of users and suercases while the > discussion over the game engine related fileformat(s) keeps ongoing. > > > for game engine related stuff; > > the interest for > the collada exporter is for UE4+Blender users at the moment is rather > slim due to the fact that collada isn´t inlcuded (yet?*) into Unreal... > > > * Epic proposed to include the collada fileformat back a few month for > Blender users if there is interest. > > it seems that there is a new maintainer - Juan available for an I/O > Collada script in Blender available... > give it a try and also inform Epic of a possible collada solution so the > users can test it in their engine. > > > > maybe for "security" take the same route as the fbx fileformat got and add > it as an "experimental Addon " so interested Blender users can easily > activate it and switch between the already existing nowadays unmaintained > collada code inside Blender and the new code which is maintained by Juan?! > > I think this is a first possible start for a solution because then the > users can more easily start battle testing the new collada code. > > > > > > > > > Juan Linietsky schrieb am 21:48 Sonntag, 12.Oktober > 2014: > > > > > > > > > >Sergey: > > > >You seem to be somehow expecting a magic bullet. You can't write an > >exporter thinking that you will please every importer out there, specially > >for a format as ambiguous as Collada. The best you can do is to export a > >correct file and then work with those who have importers to make sure they > >are reading it properly. If users report an issue with an exported file > not > >working with a specific DCC, first you make sure that the file is being > >exported correcty. If not, then the exporter is fixed (I take > >responsibility for that), but if the file is OK, then you instruct the > user > >to talk with whoever is developing that software to properly support his > >file, offering coopeation (I also take responsibility for that). This is > >the only way something like this can work, and as far as I will get > >involved. > >___ > >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 > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Muscle Rigging MVP implementation
Hey Zack I'm glad to see somebody working on a real muscle system for blender. Other 3D apps have already shown, what a good muscle system can do, so it's really time to get one into Blender. From your mail, I wasn't sure, what you tried to achieve. Did you try to find people to work on it (with or without you), or did you really only wanted to furnish your previous work for someone who may want to implement muscles in future? Actually, I already thought about implementing a muscle system, some time ago, but postponed it, as my personal playground became the UI code and I never did something in this area, before. Nevertheless, I would still be glad to work on this, so even if I'm currently weighed down with work and outstanding todos, you can count me in! It seems to me that you've already done most of the work, but before we continue, we should check if there are other methods/papers which might be better or fit better into blender (just to be sure). We should also make sure, the code is written in a way that makes it easy to change the algorithm later on (I just really quickly skimmed over the paper and the diff, but I'll have a deeper look, later). Thanks and keep up the good work! Severin Gesendet: Sonntag, 12. Oktober 2014 um 07:49 Uhr Von: "Zack Drach" An: bf-committers@blender.org Betreff: [Bf-committers] Muscle Rigging MVP implementation Hello Blender developers, About 6 months ago, I implemented native muscle rigging in Blender for a class project at my university. Although it's not production ready, I figured that my code and design could help guide the decision to add muscle rigging to Blender. At a high level, used the algorithm described here: http://cg.skeelogy.com/research/simplified-muscle-dynamics.php . I found the link to the paper in the GSOC 2013 ideas document. In terms of code modifications, I created a new DNA data structure called Muscle, and created some operators for creating muscles and attaching them to Bones. Integration with WeightPaint/Pose mode was also implemented. My final report (for the class) can be found here: http://zdrach.com/New%20Projects/01%20Muscle%20Rigging/files/report.pdf[http://zdrach.com/New%20Projects/01%20Muscle%20Rigging/files/report.pdf][http://zdrach.com/New%20Projects/01%20Muscle%20Rigging/files/report.pdf[http://zdrach.com/New%20Projects/01%20Muscle%20Rigging/files/report.pdf]][http://zdrach.com/New%20Projects/01%20Muscle%20Rigging/files/report.pdf[http://zdrach.com/New%20Projects/01%20Muscle%20Rigging/files/report.pdf][http://zdrach.com/New%20Projects/01%20Muscle%20Rigging/files/report.pdf[http://zdrach.com/New%20Projects/01%20Muscle%20Rigging/files/report.pdf]]] And the diff can be found here: http://zdrach.com/New%20Projects/01%20Muscle%20Rigging/files/diff.txt[http://zdrach.com/New%20Projects/01%20Muscle%20Rigging/files/diff.txt][http://zdrach.com/New%20Projects/01%20Muscle%20Rigging/files/diff.txt[http://zdrach.com/New%20Projects/01%20Muscle%20Rigging/files/diff.txt]][http://zdrach.com/New%20Projects/01%20Muscle%20Rigging/files/diff.txt[http://zdrach.com/New%20Projects/01%20Muscle%20Rigging/files/diff.txt][http://zdrach.com/New%20Projects/01%20Muscle%20Rigging/files/diff.txt[http://zdrach.com/New%20Projects/01%20Muscle%20Rigging/files/diff.txt]]] The design looks like it should work. The main blockers for implementation are 1) development resources (probably a couple hundred man hours) and 2) code complexity (eg. maybe it's worth cleaning up some of the armature code before adding muscles). If muscle rigging becomes a development priority, hopefully these resources should help out. (Maybe these files can be put on the ideas wiki page?) Thanks, Zack Drach ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers[http://lists.blender.org/mailman/listinfo/bf-committers][http://lists.blender.org/mailman/listinfo/bf-committers[http://lists.blender.org/mailman/listinfo/bf-committers]][http://lists.blender.org/mailman/listinfo/bf-committers[http://lists.blender.org/mailman/listinfo/bf-committers][http://lists.blender.org/mailman/listinfo/bf-committers[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] Annoucement: Better Collada Exporter for Blender!
Hello Ton,Sergey,Juan, from a pure user standpoint ; one big hurdle regardless of file format(s) within Blender is that the python based import/exporter scripts are really slow, it takes in the worst cases a couple minutes to do a I/O of a "huge" file. It would be good to optimize first the speed of loading and writing files when it comes to interchanging files between different 3d programs. for a start it would be great tom optimize obj.. this alone would tremendously help a lot of users and suercases while the discussion over the game engine related fileformat(s) keeps ongoing. for game engine related stuff; the interest for the collada exporter is for UE4+Blender users at the moment is rather slim due to the fact that collada isn´t inlcuded (yet?*) into Unreal... * Epic proposed to include the collada fileformat back a few month for Blender users if there is interest. it seems that there is a new maintainer - Juan available for an I/O Collada script in Blender available... give it a try and also inform Epic of a possible collada solution so the users can test it in their engine. maybe for "security" take the same route as the fbx fileformat got and add it as an "experimental Addon " so interested Blender users can easily activate it and switch between the already existing nowadays unmaintained collada code inside Blender and the new code which is maintained by Juan?! I think this is a first possible start for a solution because then the users can more easily start battle testing the new collada code. Juan Linietsky schrieb am 21:48 Sonntag, 12.Oktober 2014: > > >Sergey: > >You seem to be somehow expecting a magic bullet. You can't write an >exporter thinking that you will please every importer out there, specially >for a format as ambiguous as Collada. The best you can do is to export a >correct file and then work with those who have importers to make sure they >are reading it properly. If users report an issue with an exported file not >working with a specific DCC, first you make sure that the file is being >exported correcty. If not, then the exporter is fixed (I take >responsibility for that), but if the file is OK, then you instruct the user >to talk with whoever is developing that software to properly support his >file, offering coopeation (I also take responsibility for that). This is >the only way something like this can work, and as far as I will get >involved. >___ >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] Annoucement: Better Collada Exporter for Blender!
Sergey: You seem to be somehow expecting a magic bullet. You can't write an exporter thinking that you will please every importer out there, specially for a format as ambiguous as Collada. The best you can do is to export a correct file and then work with those who have importers to make sure they are reading it properly. If users report an issue with an exported file not working with a specific DCC, first you make sure that the file is being exported correcty. If not, then the exporter is fixed (I take responsibility for that), but if the file is OK, then you instruct the user to talk with whoever is developing that software to properly support his file, offering coopeation (I also take responsibility for that). This is the only way something like this can work, and as far as I will get involved. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Annoucement: Better Collada Exporter for Blender!
It's not a priority, it's just what Gaia (who used to be a collada maintainer in blender) was interested in. I know downsides of fbx. I just want to have confirmation from users that exporting from blender to GE like unity indeed works as users expects it to. On Sun, Oct 12, 2014 at 9:21 PM, Juan Linietsky wrote: > Sergey Sharybin: > >Glad to know the top priority of Blender in regards to Collada is to > export correctly to Second Life. You are starting to make me think if I'm > not really wasting my time here. >The point of supporting Collada, in my view, is not about competing > against other formats such as FBX (which is the industry standard), but > simply being able to output as much information as possible to game engines > in a format that is open. It doesn't matter if there is no gold standard. > As long as the format exported is correct and the exporter outputs the > necessary information, then it's the responsibility of those who produce > the importers to ensure the data is read. Aiming for "compatibility" as > priority should not be a goal. >This is especially useful for open source game engines and applications > that can't use FBX due to license restrictions, or implementers who don't > want to deal with such a complex format. > > Juan > > > On Sun, Oct 12, 2014 at 4:10 PM, Sergey Sharybin > wrote: > > > Current state of collada in blender mainly ensures the exported file is > > readable by SecondLife. Hence: > > > > - We're not really interested in screenshots, .blend file which is not > > being exported correctly is needed instead. > > - Can you provide .blend which doesn't export correctly to SL with the > > current exporter and works with your exporter (and don't blame the wrong > > collada implementation on their side, because there's basically no > > gold-standard collada implementation and calling one implementation wrong > > and another one correct is kinda pointless imo). > > > > Also, since you've mentioned unity in here it'll make total sense to get > a > > feedback from those who're currently uses fbx to export data from blender > > to unity before claiming this is the best exporter. > > > > On Sun, Oct 12, 2014 at 8:49 PM, Juan Linietsky > wrote: > > > > > Ton. > > > > > >If it makes you feel happier, I can manage to get screenshots of > data > > > exported with the plugin (with as many features as possible) being > > imported > > > in different applications by mid next week. > > > > > > Juan > > > > > > > > > On Sun, Oct 12, 2014 at 3:13 PM, Juan Linietsky > > wrote: > > > > > > > Ton, > > > > > > > > It does work, and has been tested with those DCCs, but the most > > you > > > > can get is geometry. Animation will mostly not work because it's > > exported > > > > as baked transforms and clips (which are game engine targeted > > features). > > > > It has been used with Unity and got reports of users that got it > > to > > > > work with Cryengine and Amnesia engine. I do not have licenses for > any > > of > > > > those engines myself and I'm a Linux user. However, I'm willing to > > work > > > > with anyone from those companies to ensure they are importing the > > format > > > > correctly. > > > > > > > > Juan > > > > > > > > > > > > On Sun, Oct 12, 2014 at 2:52 PM, Ton Roosendaal > > wrote: > > > > > > > >> Hi, > > > >> > > > >> To quote you: > > > >> > > > >> "This plugin is very battle-tested, and files written by it can be > > read > > > >> by most DCCs and engines. It's the most efficient, complete, > mature, > > > and > > > >> featured Collada exporter ever written for Blender." > > > >> > > > >> I would like to know how you tested this statement. I would be > really > > > >> happy to see this to be true. > > > >> > > > >> -Ton- > > > >> > > > >> > > > >> Ton Roosendaal - t...@blender.org - www.blender.org > > > >> Chairman Blender Foundation - Producer Blender Institute > > > >> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > > >> > > > >> > > > >> > > > >> On 12 Oct, 2014, at 19:27, Juan Linietsky wrote: > > > >> > > > >> > Ton, > > > >> > > > > >> > I really don't understand this reasoning at all. > > > >> > > > > >> > Collada is completely useless as an exchange format between > > DCCs. > > > >> > Neither Blender nor Max, Maya or pretty much any other of those > apps > > > >> has a > > > >> > properly working Collada importer. All are severely broken because > > > It's > > > >> not > > > >> > a common use case. If the Blender community is worried about > better > > > >> > exchange of data with Max or Maya, then the proper way to go would > > be > > > to > > > >> > write plugins for those DCCs that read and write Blender files and > > > >> tries to > > > >> > guess the best way to map data, not use crappy and ambiguous > > > >> intermediate > > > >> > formats like Collada or FBX. > > > >> > > > > >> > This Collada exporter is meant to export for gam
Re: [Bf-committers] Annoucement: Better Collada Exporter for Blender!
Sergey Sharybin: Glad to know the top priority of Blender in regards to Collada is to export correctly to Second Life. You are starting to make me think if I'm not really wasting my time here. The point of supporting Collada, in my view, is not about competing against other formats such as FBX (which is the industry standard), but simply being able to output as much information as possible to game engines in a format that is open. It doesn't matter if there is no gold standard. As long as the format exported is correct and the exporter outputs the necessary information, then it's the responsibility of those who produce the importers to ensure the data is read. Aiming for "compatibility" as priority should not be a goal. This is especially useful for open source game engines and applications that can't use FBX due to license restrictions, or implementers who don't want to deal with such a complex format. Juan On Sun, Oct 12, 2014 at 4:10 PM, Sergey Sharybin wrote: > Current state of collada in blender mainly ensures the exported file is > readable by SecondLife. Hence: > > - We're not really interested in screenshots, .blend file which is not > being exported correctly is needed instead. > - Can you provide .blend which doesn't export correctly to SL with the > current exporter and works with your exporter (and don't blame the wrong > collada implementation on their side, because there's basically no > gold-standard collada implementation and calling one implementation wrong > and another one correct is kinda pointless imo). > > Also, since you've mentioned unity in here it'll make total sense to get a > feedback from those who're currently uses fbx to export data from blender > to unity before claiming this is the best exporter. > > On Sun, Oct 12, 2014 at 8:49 PM, Juan Linietsky wrote: > > > Ton. > > > >If it makes you feel happier, I can manage to get screenshots of data > > exported with the plugin (with as many features as possible) being > imported > > in different applications by mid next week. > > > > Juan > > > > > > On Sun, Oct 12, 2014 at 3:13 PM, Juan Linietsky > wrote: > > > > > Ton, > > > > > > It does work, and has been tested with those DCCs, but the most > you > > > can get is geometry. Animation will mostly not work because it's > exported > > > as baked transforms and clips (which are game engine targeted > features). > > > It has been used with Unity and got reports of users that got it > to > > > work with Cryengine and Amnesia engine. I do not have licenses for any > of > > > those engines myself and I'm a Linux user. However, I'm willing to > work > > > with anyone from those companies to ensure they are importing the > format > > > correctly. > > > > > > Juan > > > > > > > > > On Sun, Oct 12, 2014 at 2:52 PM, Ton Roosendaal > wrote: > > > > > >> Hi, > > >> > > >> To quote you: > > >> > > >> "This plugin is very battle-tested, and files written by it can be > read > > >> by most DCCs and engines. It's the most efficient, complete, mature, > > and > > >> featured Collada exporter ever written for Blender." > > >> > > >> I would like to know how you tested this statement. I would be really > > >> happy to see this to be true. > > >> > > >> -Ton- > > >> > > >> > > >> Ton Roosendaal - t...@blender.org - www.blender.org > > >> Chairman Blender Foundation - Producer Blender Institute > > >> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > >> > > >> > > >> > > >> On 12 Oct, 2014, at 19:27, Juan Linietsky wrote: > > >> > > >> > Ton, > > >> > > > >> > I really don't understand this reasoning at all. > > >> > > > >> > Collada is completely useless as an exchange format between > DCCs. > > >> > Neither Blender nor Max, Maya or pretty much any other of those apps > > >> has a > > >> > properly working Collada importer. All are severely broken because > > It's > > >> not > > >> > a common use case. If the Blender community is worried about better > > >> > exchange of data with Max or Maya, then the proper way to go would > be > > to > > >> > write plugins for those DCCs that read and write Blender files and > > >> tries to > > >> > guess the best way to map data, not use crappy and ambiguous > > >> intermediate > > >> > formats like Collada or FBX. > > >> > > > >> > This Collada exporter is meant to export for game engines. It > was > > >> > tested with many (including my own) and it works. If it doesn't > work, > > >> (and > > >> > as long as the exported format is correct) then it's the > > responsibility > > >> of > > >> > that game engine to read the format properly. It's wrong to expect > an > > >> > exporter to accommodate to bugs or implementation errors in third > > party > > >> > software. A bug must be reported to them if that is the case. > > >> > > > >> > Also, your argument about user interest is wrong and It's easy > for > > >> me > > >> > to prove it. *NO ONE*
Re: [Bf-committers] Annoucement: Better Collada Exporter for Blender!
Current state of collada in blender mainly ensures the exported file is readable by SecondLife. Hence: - We're not really interested in screenshots, .blend file which is not being exported correctly is needed instead. - Can you provide .blend which doesn't export correctly to SL with the current exporter and works with your exporter (and don't blame the wrong collada implementation on their side, because there's basically no gold-standard collada implementation and calling one implementation wrong and another one correct is kinda pointless imo). Also, since you've mentioned unity in here it'll make total sense to get a feedback from those who're currently uses fbx to export data from blender to unity before claiming this is the best exporter. On Sun, Oct 12, 2014 at 8:49 PM, Juan Linietsky wrote: > Ton. > >If it makes you feel happier, I can manage to get screenshots of data > exported with the plugin (with as many features as possible) being imported > in different applications by mid next week. > > Juan > > > On Sun, Oct 12, 2014 at 3:13 PM, Juan Linietsky wrote: > > > Ton, > > > > It does work, and has been tested with those DCCs, but the most you > > can get is geometry. Animation will mostly not work because it's exported > > as baked transforms and clips (which are game engine targeted features). > > It has been used with Unity and got reports of users that got it to > > work with Cryengine and Amnesia engine. I do not have licenses for any of > > those engines myself and I'm a Linux user. However, I'm willing to work > > with anyone from those companies to ensure they are importing the format > > correctly. > > > > Juan > > > > > > On Sun, Oct 12, 2014 at 2:52 PM, Ton Roosendaal wrote: > > > >> Hi, > >> > >> To quote you: > >> > >> "This plugin is very battle-tested, and files written by it can be read > >> by most DCCs and engines. It's the most efficient, complete, mature, > and > >> featured Collada exporter ever written for Blender." > >> > >> I would like to know how you tested this statement. I would be really > >> happy to see this to be true. > >> > >> -Ton- > >> > >> > >> Ton Roosendaal - t...@blender.org - www.blender.org > >> Chairman Blender Foundation - Producer Blender Institute > >> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > >> > >> > >> > >> On 12 Oct, 2014, at 19:27, Juan Linietsky wrote: > >> > >> > Ton, > >> > > >> > I really don't understand this reasoning at all. > >> > > >> > Collada is completely useless as an exchange format between DCCs. > >> > Neither Blender nor Max, Maya or pretty much any other of those apps > >> has a > >> > properly working Collada importer. All are severely broken because > It's > >> not > >> > a common use case. If the Blender community is worried about better > >> > exchange of data with Max or Maya, then the proper way to go would be > to > >> > write plugins for those DCCs that read and write Blender files and > >> tries to > >> > guess the best way to map data, not use crappy and ambiguous > >> intermediate > >> > formats like Collada or FBX. > >> > > >> > This Collada exporter is meant to export for game engines. It was > >> > tested with many (including my own) and it works. If it doesn't work, > >> (and > >> > as long as the exported format is correct) then it's the > responsibility > >> of > >> > that game engine to read the format properly. It's wrong to expect an > >> > exporter to accommodate to bugs or implementation errors in third > party > >> > software. A bug must be reported to them if that is the case. > >> > > >> > Also, your argument about user interest is wrong and It's easy for > >> me > >> > to prove it. *NO ONE* that uses blender to export to game engines even > >> > knows the plugin I contributed exists. I know this because I get > reports > >> > from Godot users all the time that exported Collada from Blender is > >> broken > >> > or lacks features, then I point them to my exporter and problem > solved. > >> Now > >> > the community became experts in pointing new users to not use Blender > >> > exporter and instead use mine, it's like a ritual. This does not > happen > >> > with users that come from other DCCs with proper collada exporters > such > >> as > >> > Max, Softimage, Maya, etc. > >> > > >> > So, keep blaming others on the poor Collada support in Blender. > You > >> > are all fed up with it because you placed your trust int the wrong > hands > >> > (specially the choice of using OpenCollada, which I criticized back > then > >> > and Insisted it was extreme an unnecessary bloat, given my exporter > does > >> > the same and more in 0.01% the amount of code). It's not my fault you > >> all > >> > keep taking the wrong decisions. I bring you a perfectly working and > >> > feature complete Collada exporter, which I keep up to date and am > >> > compromised to fix any bug that might arise. All I ask i
Re: [Bf-committers] Annoucement: Better Collada Exporter for Blender!
Ton. If it makes you feel happier, I can manage to get screenshots of data exported with the plugin (with as many features as possible) being imported in different applications by mid next week. Juan On Sun, Oct 12, 2014 at 3:13 PM, Juan Linietsky wrote: > Ton, > > It does work, and has been tested with those DCCs, but the most you > can get is geometry. Animation will mostly not work because it's exported > as baked transforms and clips (which are game engine targeted features). > It has been used with Unity and got reports of users that got it to > work with Cryengine and Amnesia engine. I do not have licenses for any of > those engines myself and I'm a Linux user. However, I'm willing to work > with anyone from those companies to ensure they are importing the format > correctly. > > Juan > > > On Sun, Oct 12, 2014 at 2:52 PM, Ton Roosendaal wrote: > >> Hi, >> >> To quote you: >> >> "This plugin is very battle-tested, and files written by it can be read >> by most DCCs and engines. It's the most efficient, complete, mature, and >> featured Collada exporter ever written for Blender." >> >> I would like to know how you tested this statement. I would be really >> happy to see this to be true. >> >> -Ton- >> >> >> Ton Roosendaal - t...@blender.org - www.blender.org >> Chairman Blender Foundation - Producer Blender Institute >> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands >> >> >> >> On 12 Oct, 2014, at 19:27, Juan Linietsky wrote: >> >> > Ton, >> > >> > I really don't understand this reasoning at all. >> > >> > Collada is completely useless as an exchange format between DCCs. >> > Neither Blender nor Max, Maya or pretty much any other of those apps >> has a >> > properly working Collada importer. All are severely broken because It's >> not >> > a common use case. If the Blender community is worried about better >> > exchange of data with Max or Maya, then the proper way to go would be to >> > write plugins for those DCCs that read and write Blender files and >> tries to >> > guess the best way to map data, not use crappy and ambiguous >> intermediate >> > formats like Collada or FBX. >> > >> > This Collada exporter is meant to export for game engines. It was >> > tested with many (including my own) and it works. If it doesn't work, >> (and >> > as long as the exported format is correct) then it's the responsibility >> of >> > that game engine to read the format properly. It's wrong to expect an >> > exporter to accommodate to bugs or implementation errors in third party >> > software. A bug must be reported to them if that is the case. >> > >> > Also, your argument about user interest is wrong and It's easy for >> me >> > to prove it. *NO ONE* that uses blender to export to game engines even >> > knows the plugin I contributed exists. I know this because I get reports >> > from Godot users all the time that exported Collada from Blender is >> broken >> > or lacks features, then I point them to my exporter and problem solved. >> Now >> > the community became experts in pointing new users to not use Blender >> > exporter and instead use mine, it's like a ritual. This does not happen >> > with users that come from other DCCs with proper collada exporters such >> as >> > Max, Softimage, Maya, etc. >> > >> > So, keep blaming others on the poor Collada support in Blender. You >> > are all fed up with it because you placed your trust int the wrong hands >> > (specially the choice of using OpenCollada, which I criticized back then >> > and Insisted it was extreme an unnecessary bloat, given my exporter does >> > the same and more in 0.01% the amount of code). It's not my fault you >> all >> > keep taking the wrong decisions. I bring you a perfectly working and >> > feature complete Collada exporter, which I keep up to date and am >> > compromised to fix any bug that might arise. All I ask is help to >> integrate >> > it properly to Blender and I get shooed. Way to go! >> > >> > Now the trend is to support OpenGEX, which looks really promising >> and >> > I will love to implement it, but that format has the big drawback that >> if >> > you want to test the correctness of an implementation, you have to pay >> the >> > author of the format for a license of the C4 Engine. >> > >> >This is not serious at all. >> > >> > Juan >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > On Sun, Oct 12, 2014 at 11:02 AM, Ton Roosendaal >> wrote: >> > >> >> Hi Juan, >> >> >> >> The lack of interest is quite typical indeed. Collada might be not so >> >> popular, but no user reported sofar any success with your code either, >> so >> >> it's not so strange it did not get a lot of attention from coders >> either. >> >> >> >> For me it then comes down to your presentation. Why not providing >> >> reference files (like game characters in Blender) that went 1:1 to >> Maya or >> >> Max? Write docs, a
Re: [Bf-committers] Annoucement: Better Collada Exporter for Blender!
Ton, It does work, and has been tested with those DCCs, but the most you can get is geometry. Animation will mostly not work because it's exported as baked transforms and clips (which are game engine targeted features). It has been used with Unity and got reports of users that got it to work with Cryengine and Amnesia engine. I do not have licenses for any of those engines myself and I'm a Linux user. However, I'm willing to work with anyone from those companies to ensure they are importing the format correctly. Juan On Sun, Oct 12, 2014 at 2:52 PM, Ton Roosendaal wrote: > Hi, > > To quote you: > > "This plugin is very battle-tested, and files written by it can be read by > most DCCs and engines. It's the most efficient, complete, mature, and > featured Collada exporter ever written for Blender." > > I would like to know how you tested this statement. I would be really > happy to see this to be true. > > -Ton- > > > Ton Roosendaal - t...@blender.org - www.blender.org > Chairman Blender Foundation - Producer Blender Institute > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > > > On 12 Oct, 2014, at 19:27, Juan Linietsky wrote: > > > Ton, > > > > I really don't understand this reasoning at all. > > > > Collada is completely useless as an exchange format between DCCs. > > Neither Blender nor Max, Maya or pretty much any other of those apps has > a > > properly working Collada importer. All are severely broken because It's > not > > a common use case. If the Blender community is worried about better > > exchange of data with Max or Maya, then the proper way to go would be to > > write plugins for those DCCs that read and write Blender files and tries > to > > guess the best way to map data, not use crappy and ambiguous intermediate > > formats like Collada or FBX. > > > > This Collada exporter is meant to export for game engines. It was > > tested with many (including my own) and it works. If it doesn't work, > (and > > as long as the exported format is correct) then it's the responsibility > of > > that game engine to read the format properly. It's wrong to expect an > > exporter to accommodate to bugs or implementation errors in third party > > software. A bug must be reported to them if that is the case. > > > > Also, your argument about user interest is wrong and It's easy for me > > to prove it. *NO ONE* that uses blender to export to game engines even > > knows the plugin I contributed exists. I know this because I get reports > > from Godot users all the time that exported Collada from Blender is > broken > > or lacks features, then I point them to my exporter and problem solved. > Now > > the community became experts in pointing new users to not use Blender > > exporter and instead use mine, it's like a ritual. This does not happen > > with users that come from other DCCs with proper collada exporters such > as > > Max, Softimage, Maya, etc. > > > > So, keep blaming others on the poor Collada support in Blender. You > > are all fed up with it because you placed your trust int the wrong hands > > (specially the choice of using OpenCollada, which I criticized back then > > and Insisted it was extreme an unnecessary bloat, given my exporter does > > the same and more in 0.01% the amount of code). It's not my fault you all > > keep taking the wrong decisions. I bring you a perfectly working and > > feature complete Collada exporter, which I keep up to date and am > > compromised to fix any bug that might arise. All I ask is help to > integrate > > it properly to Blender and I get shooed. Way to go! > > > > Now the trend is to support OpenGEX, which looks really promising and > > I will love to implement it, but that format has the big drawback that if > > you want to test the correctness of an implementation, you have to pay > the > > author of the format for a license of the C4 Engine. > > > >This is not serious at all. > > > > Juan > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Oct 12, 2014 at 11:02 AM, Ton Roosendaal > wrote: > > > >> Hi Juan, > >> > >> The lack of interest is quite typical indeed. Collada might be not so > >> popular, but no user reported sofar any success with your code either, > so > >> it's not so strange it did not get a lot of attention from coders > either. > >> > >> For me it then comes down to your presentation. Why not providing > >> reference files (like game characters in Blender) that went 1:1 to Maya > or > >> Max? Write docs, add examples? > >> > >> If you claim you have a great Collada exporter, then where are your test > >> files, which cases did you test with Maya or Max? Who else uses it, and > >> where can see examples of this working? > >> > >> Would help a lot, > >> > >> -Ton- > >> > >> > >> Ton Roosendaal - t...@blender.org - www.blender.org > >> Chairman Blender
Re: [Bf-committers] Annoucement: Better Collada Exporter for Blender!
Hi, To quote you: "This plugin is very battle-tested, and files written by it can be read by most DCCs and engines. It's the most efficient, complete, mature, and featured Collada exporter ever written for Blender." I would like to know how you tested this statement. I would be really happy to see this to be true. -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands On 12 Oct, 2014, at 19:27, Juan Linietsky wrote: > Ton, > > I really don't understand this reasoning at all. > > Collada is completely useless as an exchange format between DCCs. > Neither Blender nor Max, Maya or pretty much any other of those apps has a > properly working Collada importer. All are severely broken because It's not > a common use case. If the Blender community is worried about better > exchange of data with Max or Maya, then the proper way to go would be to > write plugins for those DCCs that read and write Blender files and tries to > guess the best way to map data, not use crappy and ambiguous intermediate > formats like Collada or FBX. > > This Collada exporter is meant to export for game engines. It was > tested with many (including my own) and it works. If it doesn't work, (and > as long as the exported format is correct) then it's the responsibility of > that game engine to read the format properly. It's wrong to expect an > exporter to accommodate to bugs or implementation errors in third party > software. A bug must be reported to them if that is the case. > > Also, your argument about user interest is wrong and It's easy for me > to prove it. *NO ONE* that uses blender to export to game engines even > knows the plugin I contributed exists. I know this because I get reports > from Godot users all the time that exported Collada from Blender is broken > or lacks features, then I point them to my exporter and problem solved. Now > the community became experts in pointing new users to not use Blender > exporter and instead use mine, it's like a ritual. This does not happen > with users that come from other DCCs with proper collada exporters such as > Max, Softimage, Maya, etc. > > So, keep blaming others on the poor Collada support in Blender. You > are all fed up with it because you placed your trust int the wrong hands > (specially the choice of using OpenCollada, which I criticized back then > and Insisted it was extreme an unnecessary bloat, given my exporter does > the same and more in 0.01% the amount of code). It's not my fault you all > keep taking the wrong decisions. I bring you a perfectly working and > feature complete Collada exporter, which I keep up to date and am > compromised to fix any bug that might arise. All I ask is help to integrate > it properly to Blender and I get shooed. Way to go! > > Now the trend is to support OpenGEX, which looks really promising and > I will love to implement it, but that format has the big drawback that if > you want to test the correctness of an implementation, you have to pay the > author of the format for a license of the C4 Engine. > >This is not serious at all. > > Juan > > > > > > > > > > > > > > On Sun, Oct 12, 2014 at 11:02 AM, Ton Roosendaal wrote: > >> Hi Juan, >> >> The lack of interest is quite typical indeed. Collada might be not so >> popular, but no user reported sofar any success with your code either, so >> it's not so strange it did not get a lot of attention from coders either. >> >> For me it then comes down to your presentation. Why not providing >> reference files (like game characters in Blender) that went 1:1 to Maya or >> Max? Write docs, add examples? >> >> If you claim you have a great Collada exporter, then where are your test >> files, which cases did you test with Maya or Max? Who else uses it, and >> where can see examples of this working? >> >> Would help a lot, >> >> -Ton- >> >> >> Ton Roosendaal - t...@blender.org - www.blender.org >> Chairman Blender Foundation - Producer Blender Institute >> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands >> >> >> >> On 12 Oct, 2014, at 15:33, Juan Linietsky wrote: >> >>> It's been in there since some months, and there seems to be no interest >> at >>> all in integrating it into Blender. (That version is also pretty outdated >>> by now.), so i'm maintaining it / hosting it on my own. >>> >>> https://developer.blender.org/T41071 >>> >>> On Sun, Oct 12, 2014 at 4:49 AM, Daniel Salazar - patazstudio.com < >>> zan...@gmail.com> wrote: >>> Sounds fantastic, why don't you put it in >> https://developer.blender.org/ Thank you for sharing! Daniel Salazar patazstudio.com On Fri, Oct 10, 2014 at 6:12 AM, Juan Linietsky >> wrote: > Godot site
Re: [Bf-committers] Annoucement: Better Collada Exporter for Blender!
Ton, I really don't understand this reasoning at all. Collada is completely useless as an exchange format between DCCs. Neither Blender nor Max, Maya or pretty much any other of those apps has a properly working Collada importer. All are severely broken because It's not a common use case. If the Blender community is worried about better exchange of data with Max or Maya, then the proper way to go would be to write plugins for those DCCs that read and write Blender files and tries to guess the best way to map data, not use crappy and ambiguous intermediate formats like Collada or FBX. This Collada exporter is meant to export for game engines. It was tested with many (including my own) and it works. If it doesn't work, (and as long as the exported format is correct) then it's the responsibility of that game engine to read the format properly. It's wrong to expect an exporter to accommodate to bugs or implementation errors in third party software. A bug must be reported to them if that is the case. Also, your argument about user interest is wrong and It's easy for me to prove it. *NO ONE* that uses blender to export to game engines even knows the plugin I contributed exists. I know this because I get reports from Godot users all the time that exported Collada from Blender is broken or lacks features, then I point them to my exporter and problem solved. Now the community became experts in pointing new users to not use Blender exporter and instead use mine, it's like a ritual. This does not happen with users that come from other DCCs with proper collada exporters such as Max, Softimage, Maya, etc. So, keep blaming others on the poor Collada support in Blender. You are all fed up with it because you placed your trust int the wrong hands (specially the choice of using OpenCollada, which I criticized back then and Insisted it was extreme an unnecessary bloat, given my exporter does the same and more in 0.01% the amount of code). It's not my fault you all keep taking the wrong decisions. I bring you a perfectly working and feature complete Collada exporter, which I keep up to date and am compromised to fix any bug that might arise. All I ask is help to integrate it properly to Blender and I get shooed. Way to go! Now the trend is to support OpenGEX, which looks really promising and I will love to implement it, but that format has the big drawback that if you want to test the correctness of an implementation, you have to pay the author of the format for a license of the C4 Engine. This is not serious at all. Juan On Sun, Oct 12, 2014 at 11:02 AM, Ton Roosendaal wrote: > Hi Juan, > > The lack of interest is quite typical indeed. Collada might be not so > popular, but no user reported sofar any success with your code either, so > it's not so strange it did not get a lot of attention from coders either. > > For me it then comes down to your presentation. Why not providing > reference files (like game characters in Blender) that went 1:1 to Maya or > Max? Write docs, add examples? > > If you claim you have a great Collada exporter, then where are your test > files, which cases did you test with Maya or Max? Who else uses it, and > where can see examples of this working? > > Would help a lot, > > -Ton- > > > Ton Roosendaal - t...@blender.org - www.blender.org > Chairman Blender Foundation - Producer Blender Institute > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > > > On 12 Oct, 2014, at 15:33, Juan Linietsky wrote: > > > It's been in there since some months, and there seems to be no interest > at > > all in integrating it into Blender. (That version is also pretty outdated > > by now.), so i'm maintaining it / hosting it on my own. > > > > https://developer.blender.org/T41071 > > > > On Sun, Oct 12, 2014 at 4:49 AM, Daniel Salazar - patazstudio.com < > > zan...@gmail.com> wrote: > > > >> Sounds fantastic, why don't you put it in > https://developer.blender.org/ > >> > >> Thank you for sharing! > >> Daniel Salazar > >> patazstudio.com > >> > >> > >> On Fri, Oct 10, 2014 at 6:12 AM, Juan Linietsky > wrote: > >>> Godot site is still under construction, but I've decided to publish my > >>> Collada exporter by myself, given the lack of will to include it in > >> Blender. > >>> > >>> This plugin is very battle-tested, and files written by it can be read > by > >>> most DCCs and engines. > >>> It's the most efficient, complete, mature, and featured Collada > exporter > >>> ever written for Blender. > >>> It supports almost every Collada feature and several more than the > >> built-in > >>> one. Best of all, it's only 1400 lines of python code. No dependencies. > >>> > >>> Feature list: > >>> > >>> > >>> - Export all supported nodes in the format: > >>> - Meshes > >>> - Lights (Omni, Directional, Spot and Ambient) > >>> - Cameras > >>> - Spline Curves (paths) > >>> -
[Bf-committers] Weekly Blender developer meeting minutes - 12 October 2014
Hi all, Here are the notes from today's meeting in irc.freenode.net #blendercoders. 1) Will there be a 2.72a update? - There have been a couple of fixes that deserve to be released, just to make it rock solid. The team will check on what to merge in the next days, wednesday we could call for a build. 2) Targets for next release - The planning proposal: http://wiki.blender.org/index.php/Dev:Doc/Projects - Defining the final release targets next week might be too soon, several developers prefer more time. This then will be two more week, because of Blender Conference. - Please don't forget to help Martin Felke! http://lists.blender.org/pipermail/bf-committers/2014-October/044330.html - Antony Ryakiotakis and Jason Wilkins will review if it's possible to apply the Viewport project for 2.73 still. viewport possible - Request for review, adaptive sampling for Cycles: https://developer.blender.org/D808 3) other projects - Lukas Toenne's hair simulation and editing work might make it for the next release. - Sergey Sharybin is recoding Texture Nodes, simpler and thread safe. - Buildbot was exposing binary testbuild (branch) downloads from unclear origins, these get hidden now. Thanks, -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Annoucement: Better Collada Exporter for Blender!
Hi Juan, The lack of interest is quite typical indeed. Collada might be not so popular, but no user reported sofar any success with your code either, so it's not so strange it did not get a lot of attention from coders either. For me it then comes down to your presentation. Why not providing reference files (like game characters in Blender) that went 1:1 to Maya or Max? Write docs, add examples? If you claim you have a great Collada exporter, then where are your test files, which cases did you test with Maya or Max? Who else uses it, and where can see examples of this working? Would help a lot, -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands On 12 Oct, 2014, at 15:33, Juan Linietsky wrote: > It's been in there since some months, and there seems to be no interest at > all in integrating it into Blender. (That version is also pretty outdated > by now.), so i'm maintaining it / hosting it on my own. > > https://developer.blender.org/T41071 > > On Sun, Oct 12, 2014 at 4:49 AM, Daniel Salazar - patazstudio.com < > zan...@gmail.com> wrote: > >> Sounds fantastic, why don't you put it in https://developer.blender.org/ >> >> Thank you for sharing! >> Daniel Salazar >> patazstudio.com >> >> >> On Fri, Oct 10, 2014 at 6:12 AM, Juan Linietsky wrote: >>> Godot site is still under construction, but I've decided to publish my >>> Collada exporter by myself, given the lack of will to include it in >> Blender. >>> >>> This plugin is very battle-tested, and files written by it can be read by >>> most DCCs and engines. >>> It's the most efficient, complete, mature, and featured Collada exporter >>> ever written for Blender. >>> It supports almost every Collada feature and several more than the >> built-in >>> one. Best of all, it's only 1400 lines of python code. No dependencies. >>> >>> Feature list: >>> >>> >>> - Export all supported nodes in the format: >>> - Meshes >>> - Lights (Omni, Directional, Spot and Ambient) >>> - Cameras >>> - Spline Curves (paths) >>> - Armatures (mesh objects must be children of them). >>> - Empty Objects >>> - Bones with proper rest information. >>> - Shape Keys >>> - Combined Shape Keys + Armature deform. >>> - Materials and Textures >>> - Automatic handling of texture paths (conversion to relative). >>> - Optional copying of textures on export. >>> - Standard Extensions for double-sided geometry. >>> - Standard Extensions for normal maps. >>> - Geometry Optimization (creation of indices and triangulation). >>> - Export Masks (By Selection, Layer or Object Type). >>> - Full animation support for objects, bones and shape keys. >>> - Support for exporting all clips in the scene, including shape keys >> via >>> set-driven keys. >>> - Baking of curves and constraints during animation export. >>> >>> Screenshots: >>> >>> [image: bc1] >>> >>> [image: bc2] >>> >>> Home: >>> >>> http://www.godotengine.org/wp/better-collada-exporter/ >>> >>> 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 >> > ___ > 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] Annoucement: Better Collada Exporter for Blender!
It's been in there since some months, and there seems to be no interest at all in integrating it into Blender. (That version is also pretty outdated by now.), so i'm maintaining it / hosting it on my own. https://developer.blender.org/T41071 On Sun, Oct 12, 2014 at 4:49 AM, Daniel Salazar - patazstudio.com < zan...@gmail.com> wrote: > Sounds fantastic, why don't you put it in https://developer.blender.org/ > > Thank you for sharing! > Daniel Salazar > patazstudio.com > > > On Fri, Oct 10, 2014 at 6:12 AM, Juan Linietsky wrote: > > Godot site is still under construction, but I've decided to publish my > > Collada exporter by myself, given the lack of will to include it in > Blender. > > > > This plugin is very battle-tested, and files written by it can be read by > > most DCCs and engines. > > It's the most efficient, complete, mature, and featured Collada exporter > > ever written for Blender. > > It supports almost every Collada feature and several more than the > built-in > > one. Best of all, it's only 1400 lines of python code. No dependencies. > > > > Feature list: > > > > > >- Export all supported nodes in the format: > > - Meshes > > - Lights (Omni, Directional, Spot and Ambient) > > - Cameras > > - Spline Curves (paths) > > - Armatures (mesh objects must be children of them). > > - Empty Objects > >- Bones with proper rest information. > >- Shape Keys > >- Combined Shape Keys + Armature deform. > >- Materials and Textures > >- Automatic handling of texture paths (conversion to relative). > >- Optional copying of textures on export. > >- Standard Extensions for double-sided geometry. > >- Standard Extensions for normal maps. > >- Geometry Optimization (creation of indices and triangulation). > >- Export Masks (By Selection, Layer or Object Type). > >- Full animation support for objects, bones and shape keys. > >- Support for exporting all clips in the scene, including shape keys > via > >set-driven keys. > >- Baking of curves and constraints during animation export. > > > > Screenshots: > > > > [image: bc1] > > > > [image: bc2] > > > > Home: > > > > http://www.godotengine.org/wp/better-collada-exporter/ > > > > 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 > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] [f94c969] GPencil_EditStrokes: GPencil Toolshelf Panels - Split into two panels
Joshua, I'm not sure if this fits in your project, but I started working on a script that would allow for creating grease based text. In python, I created a text object and set its text to whatever the user entered, then used the curves in the text object to define the curve points. Its is pretty rudimentary, but it worked. Would be better if it was native code. Johnny Matthews johnny.matth...@gmail.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Muscle Rigging MVP implementation
Hi Zack, Interesting stuff. The paper you wrote shows some good design ideas. Do you have test videos of the muscles at work in Blender? -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands On 12 Oct, 2014, at 7:49, Zack Drach wrote: > Hello Blender developers, > > About 6 months ago, I implemented native muscle rigging in Blender for a > class project at my university. Although it's not production ready, I > figured that my code and design could help guide the decision to add muscle > rigging to Blender. > > At a high level, used the algorithm described here: > http://cg.skeelogy.com/research/simplified-muscle-dynamics.php . I found > the link to the paper in the GSOC 2013 ideas document. > > In terms of code modifications, I created a new DNA data structure called > Muscle, and created some operators for creating muscles and attaching them > to Bones. Integration with WeightPaint/Pose mode was also implemented. > > My final report (for the class) can be found here: > http://zdrach.com/New%20Projects/01%20Muscle%20Rigging/files/report.pdf > > And the diff can be found here: > http://zdrach.com/New%20Projects/01%20Muscle%20Rigging/files/diff.txt > > The design looks like it should work. The main blockers for implementation > are 1) development resources (probably a couple hundred man hours) and 2) > code complexity (eg. maybe it's worth cleaning up some of the armature code > before adding muscles). > > If muscle rigging becomes a development priority, hopefully these resources > should help out. (Maybe these files can be put on the ideas wiki page?) > > Thanks, > Zack Drach > ___ > 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] Revising the testbuild branch
Think we should agree on some better name then and deploy? On Sun, Oct 12, 2014 at 9:19 AM, Bastien Montagne wrote: > Good catch, this seems to work fine! :) > > Le 12/10/2014 08:26, Sergey Sharybin a écrit : > > Did you try using public_html/testbuilds instead? There's also a code in > > the template which lusts the dirs, could comment that out. > > On Oct 11, 2014 11:27 PM, "Bastien Montagne" > wrote: > > > >> Following Sergey's suggestion (put testbuilds in a separate dir) I > >> fought a bit with my local version of buildbot to get it running again. > >> > >> In the end, looks like a very simple change is enough, in > >> master_unpack.py, something like: > >> > >> diff --git a/build_files/buildbot/master_unpack.py > >> b/build_files/buildbot/master_unpack.py > >> index ecacf3b..f5c8493 100644 > >> --- a/build_files/buildbot/master_unpack.py > >> +++ b/build_files/buildbot/master_unpack.py > >> @@ -116,7 +116,7 @@ if platform == '': > >>sys.exit(1) > >> > >># extract > >> -directory = 'public_html/download' > >> +directory = 'public_html/download' if branch == 'master' else > >> 'public_html/download/testbuilds' > >> > >>try: > >>zf = z.open(package) > >> > >> public_html/download/testbuilds must be created beforehand of course. > >> > >> On my local web buildbot UI, that dir is automatically listed under the > >> download page… Not sure whether we consider that as safe enough for > >> users not to mess with it? Guess we can find a way to hide it, > otherwise. > >> > >> As a side note, do not think listing those builds publically is needed > >> at all, they are replaced by next one so dev has to 'backup' them > anyway. > >> > >> And yes, probably renaming could be nice too… 'experimental' sounds good > >> to me. > >> > >> Bastien > >> > >> Le 11/10/2014 20:26, Sergey Sharybin a écrit : > >>> It _had been_ discussed several times at least. Starting from > discussion > >> in > >>> #lbendercoders between me, Dan, Bastien and even Ton. Then once it was > >> all > >>> set up (and i believe some discussion happened in the ML as well). Once > >> all > >>> the changes to the infrastructure were done it was announced in the ML: > >>> http://lists.blender.org/pipermail/bf-committers/2014-July/043948.html > >> In > >>> such a situation it's real weird to have a post-factum "it should have > >>> never been done this way". > >>> > >>> As an addition to the previous suggestion: > >>> - We can as well just put a REAL HUGE BANNER on top of the experimental > >>> builds just to stress once again that they're experimental if it'll be > >>> considered useful to have those builds listed to public. > >>> - We can rename "testbuild" to something like "devbuild" (as > >>> developer-build) or "experimental" to prevent possible confusion with > the > >>> testbuilds being done as a part of the release build. > >>> > >>> On Sun, Oct 12, 2014 at 12:07 AM, Ton Roosendaal > >> wrote: > Hi Bastien, > > Sorry, I've asked around and had the impression Sergey added the > feature > on builder.blender.org. > > The fact that building branches on buildbot is useful is not disputed. > It's just not acceptable to offer an official build for download on a > popular page on blender.org, with unknown patches or branches > applied. > > Let's just keep the lines short and discuss decisions like this > together > well? > > Laters, > > -Ton- > > > Ton Roosendaal - t...@blender.org - www.blender.org > Chairman Blender Foundation - Producer Blender Institute > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > > > On 11 Oct, 2014, at 18:24, Bastien Montagne wrote: > > > I’m not happy at all with both the decision and the way it was taken. > > Fyi, I was the one who spent a fair amount of time some months agon > > setting this up, and I think it has proven to be really really useful > > for all wip projects around. > > > > Further more, I do not see any reason to just cut this out out of the > > blue, there was no urgency at all here. And I do not even really > > understand the root of the issue, imho people who are not able to > make > >> a > > distinction between builds tagged as 'official' and builds tagged as > > 'testbuild' have nothing to do on builder.b.o. > > > > But even though, imho it would have been much nicer to ask to add > some > > way to delete testbuilds from the server, again see no urgency at all > > here that could justify this discontinuation. > > > > Adding back build of all branches will just create much much more > mess, > > we won’t gain anything. Oh, and people that cannot understand what > > 'testbuild' means won’t be able either to distinguish from master and > > branches builds - even less I’d say. > > > > Very disapo
Re: [Bf-committers] Annoucement: Better Collada Exporter for Blender!
Sounds fantastic, why don't you put it in https://developer.blender.org/ Thank you for sharing! Daniel Salazar patazstudio.com On Fri, Oct 10, 2014 at 6:12 AM, Juan Linietsky wrote: > Godot site is still under construction, but I've decided to publish my > Collada exporter by myself, given the lack of will to include it in Blender. > > This plugin is very battle-tested, and files written by it can be read by > most DCCs and engines. > It's the most efficient, complete, mature, and featured Collada exporter > ever written for Blender. > It supports almost every Collada feature and several more than the built-in > one. Best of all, it's only 1400 lines of python code. No dependencies. > > Feature list: > > >- Export all supported nodes in the format: > - Meshes > - Lights (Omni, Directional, Spot and Ambient) > - Cameras > - Spline Curves (paths) > - Armatures (mesh objects must be children of them). > - Empty Objects >- Bones with proper rest information. >- Shape Keys >- Combined Shape Keys + Armature deform. >- Materials and Textures >- Automatic handling of texture paths (conversion to relative). >- Optional copying of textures on export. >- Standard Extensions for double-sided geometry. >- Standard Extensions for normal maps. >- Geometry Optimization (creation of indices and triangulation). >- Export Masks (By Selection, Layer or Object Type). >- Full animation support for objects, bones and shape keys. >- Support for exporting all clips in the scene, including shape keys via >set-driven keys. >- Baking of curves and constraints during animation export. > > Screenshots: > > [image: bc1] > > [image: bc2] > > Home: > > http://www.godotengine.org/wp/better-collada-exporter/ > > 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] Revising the testbuild branch
Good catch, this seems to work fine! :) Le 12/10/2014 08:26, Sergey Sharybin a écrit : > Did you try using public_html/testbuilds instead? There's also a code in > the template which lusts the dirs, could comment that out. > On Oct 11, 2014 11:27 PM, "Bastien Montagne" wrote: > >> Following Sergey's suggestion (put testbuilds in a separate dir) I >> fought a bit with my local version of buildbot to get it running again. >> >> In the end, looks like a very simple change is enough, in >> master_unpack.py, something like: >> >> diff --git a/build_files/buildbot/master_unpack.py >> b/build_files/buildbot/master_unpack.py >> index ecacf3b..f5c8493 100644 >> --- a/build_files/buildbot/master_unpack.py >> +++ b/build_files/buildbot/master_unpack.py >> @@ -116,7 +116,7 @@ if platform == '': >>sys.exit(1) >> >># extract >> -directory = 'public_html/download' >> +directory = 'public_html/download' if branch == 'master' else >> 'public_html/download/testbuilds' >> >>try: >>zf = z.open(package) >> >> public_html/download/testbuilds must be created beforehand of course. >> >> On my local web buildbot UI, that dir is automatically listed under the >> download page… Not sure whether we consider that as safe enough for >> users not to mess with it? Guess we can find a way to hide it, otherwise. >> >> As a side note, do not think listing those builds publically is needed >> at all, they are replaced by next one so dev has to 'backup' them anyway. >> >> And yes, probably renaming could be nice too… 'experimental' sounds good >> to me. >> >> Bastien >> >> Le 11/10/2014 20:26, Sergey Sharybin a écrit : >>> It _had been_ discussed several times at least. Starting from discussion >> in >>> #lbendercoders between me, Dan, Bastien and even Ton. Then once it was >> all >>> set up (and i believe some discussion happened in the ML as well). Once >> all >>> the changes to the infrastructure were done it was announced in the ML: >>> http://lists.blender.org/pipermail/bf-committers/2014-July/043948.html >> In >>> such a situation it's real weird to have a post-factum "it should have >>> never been done this way". >>> >>> As an addition to the previous suggestion: >>> - We can as well just put a REAL HUGE BANNER on top of the experimental >>> builds just to stress once again that they're experimental if it'll be >>> considered useful to have those builds listed to public. >>> - We can rename "testbuild" to something like "devbuild" (as >>> developer-build) or "experimental" to prevent possible confusion with the >>> testbuilds being done as a part of the release build. >>> >>> On Sun, Oct 12, 2014 at 12:07 AM, Ton Roosendaal >> wrote: Hi Bastien, Sorry, I've asked around and had the impression Sergey added the feature on builder.blender.org. The fact that building branches on buildbot is useful is not disputed. It's just not acceptable to offer an official build for download on a popular page on blender.org, with unknown patches or branches applied. Let's just keep the lines short and discuss decisions like this together well? Laters, -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands On 11 Oct, 2014, at 18:24, Bastien Montagne wrote: > I’m not happy at all with both the decision and the way it was taken. > Fyi, I was the one who spent a fair amount of time some months agon > setting this up, and I think it has proven to be really really useful > for all wip projects around. > > Further more, I do not see any reason to just cut this out out of the > blue, there was no urgency at all here. And I do not even really > understand the root of the issue, imho people who are not able to make >> a > distinction between builds tagged as 'official' and builds tagged as > 'testbuild' have nothing to do on builder.b.o. > > But even though, imho it would have been much nicer to ask to add some > way to delete testbuilds from the server, again see no urgency at all > here that could justify this discontinuation. > > Adding back build of all branches will just create much much more mess, > we won’t gain anything. Oh, and people that cannot understand what > 'testbuild' means won’t be able either to distinguish from master and > branches builds - even less I’d say. > > Very disapointed here! > Bastien > > Le 11/10/2014 15:59, Ton Roosendaal a écrit : >> Hi, >> >> I've asked Sergey to disable the testbuild branch from automatic building. >> This is currently leading to a confusing situation. People have no >> idea what's the code that is in it. It's even being used to apply patches >> from the trac
