Re: [Bf-committers] 2.70/python/lib/site-packages/.svn
This it not necessery. Which platform exactly it is affected on? On Sat, Apr 26, 2014 at 11:35 AM, PerfectionCat < sindra1961reb...@yahoo.co.jp> wrote: > Hi, Devs. > > 2.70/python/lib/site-packages/.svn folder is included in a zip file of > 2.70a distributed in an official site, but is this necessary? > > > PerfectionCat > ___ > 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] Preview Icon alpha
We don't assume premultiplied images, we assume float buffers to be premultiplied and byte buffers to be straight. For as long original PNG wile is 8bit it should be stored with straight alpha. Now, if the icon display happens wrong, it's most likely a misconfigured glBlnedFunc. Anyway, if display happens wrong, it's not up to data_to_c conversion(), but up to how icons are handled. data_to_c conversion should preserve file as-is in the memory. On Sat, Apr 26, 2014 at 8:33 PM, Antony Riakiotakis wrote: > Hi, > > I am in the process of updating the paint brush icons [1] and I have been > looking at the icon preview code, file interface_icons.c, function > icon_draw_size. > > There are some caveats in the code: > > First, we assume premultiplied images, while the pngs used from our > data_to_c conversions use straight alpha. > > The second thing is that it looks as if we do not enable blending for icon > previews, which would be cool (new set of icons would work nice if used > with transparency, for instance, as would custom brush icons, I > understand). > > For the first issue I can convert the images to premultiplied space > externally but then other png's might bite us similarly. Maybe the best > would be to premultiply during data_to_c conversion? For the second issue, > I'm not sure if enabling blending could bite us in other icon rendering > cases. > > Thoughts? > > [1] https://developer.blender.org/T37960 > ___ > 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] Preview Icon alpha
I see, thanks for the correction! Given that most icon images are pngs with the exception of matcaps which are jpeg and are assumed to be alpha 1.0, and we use byte storage, then I guess the blend function is to change here. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender developer meeting notes, April 27, 2014
Hi all, Here are the notes from today's meeting in irc.freenode.net #blendercoders. 1) Blender 2.71 targets & planning - Planning and targets overview: http://wiki.blender.org/index.php/Dev:Doc/Projects - Campbell Barton: we move to Python 3.4 this week. The platform maintainers have been notified for it. (windows, osx) - The planning was to move to BCon3 today - but that means all branches and release targets should be applied to git master. Paint tools, Cycles Bake and Freestyle texture brush is still missing. After careful deliberations, meetng agreed on moving the release planning a week. 2) Google Summer of Code and other projects - Reminder for students and mentors to get their proposal in our wiki! - Overview page: http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2014 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] Importing Assets: FBX VS Collada
I'm compiling the key responses on the topic, thanks for the great feedback/comments. Here also some reality checks. Sorry this is long but i'm trying to wrap the topic up. >>Re: baking animation into meshes instead of using a rig: >>This might work for uses related*solely* to still picture & animated film >>development, but it does pretty much strand the game development folks trying >>to use Blender as an option in >>their pipelines. Animated armatures with >>skeletally attached meshes being imported and exported into/out of Blender is >>kind of essential for this area of Blender use. >>Benjamin Tolputt Benjamin well said. Game development CANNOT use baked mesh animation. Also for film it is extremely inefficient and a memory sink. The future is a cross compatible rigging system. And it is already there for FBX and Collada (every Autodesk software exports proper Collada!!) >>cool to hear that FBX maps to Blender well. If it's a sane format perhaps it >>is ok for it to become standard .. by Blender folks reverse engineering and >>documenting it :p . Even if it's >>not publicly specified by Autodesk I >>suppose they can't break it as then many apps with support for it would break >>.. unless they'd require always using updated versions of the SDK. Autodesk will NEVER release FBX SDK openly. I tried for years to convince them. They are a public company, so they cant do things that weaken their position in the industry. I talked to top management many times around this so make peace with it. Many apps DO NEED to upgrade FBX SDK every year or every couple of years as they are breaking the workflows at every release. Unity3d, Unreal, Maxxon, Mixamo, etc. we ALL UPGRADE FBX SDK every year of couple of years. The effort of reverse engineer FBX SDK in Blender every year is a waste of resources in my opinion when Autodesk already provides a FBX <-> Collada conversion. >> a lot of game makers use special engines with own formats and are quite happy to directly use Blender python for export. >> For game makers we should keep fbx to work too - but even better would be if they start directly supporting .blend files. I'd love to see efforts for that. Every decent game engine supports FBX import/export. The time of import/export plugins is GONE. Even for Maya and Max it is getting harder and harder to find them. With EVERY game engine importing FBX and with a FREE and maintained FBX <-> Collada converter out there it seems obvious to me that Collada is the way to go. Especially when you have a import/exporter that is already 90% there. >>Ton is asking why Mixamo does not create the new importer: >>Then why not do it for 2.7x? That import API is there since 2009. You are really welcome to pick up this development job and become a module owner for the Collada importer. It's the >>stakeholder principle. If you depend on a feature to work, you can also help it to be realized. If you - on the other hand - just seek for volunteering help, that's OK too. But I know Collada is >>incredbly impopular to work on. If you look for someone to be contracted for it... you could ask Gaia Clary. -Ton- A negligible fraction of our paying customers is using Blender. Why? Because you cannot reliably import assets from any other 3D package/service!! So we are not a "stakeholder" in the strict sense but would love to help the students/hobbyists/indie community that is using Blender. Since you changed Python version with 2.6x and later we would have to rewrite from scratch the plugin. We only have a small team engineers so we can't do it. The best option is to finish the job on the current one that is almost there. What I can offer is test cases and QA service for the last 10% of the Collada importer/exporter fix (support of multiple meshes/bind poses) and Mixamo stocks as payment. If anyone is interested please contact me directly stef...@mixamo.com I hope you appreciate the passion for solving the problem and the amount of real industry information on the topic. Establishing a standard is not an easy job. But we are almost there!! Long life to Blender and the Blender community!! Cheers Stefano ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Importing Assets: FBX VS Collada
On 27.04.2014 22:51, Stefano Corazza wrote: > A negligible fraction of our paying customers is using Blender. Why? > Because you cannot reliably import assets from any other 3D > package/service!! So we are not a "stakeholder" in the strict sense but > would love to help the students/hobbyists/indie community that is using > Blender. This is exactly my reasoning why i stepped into this topic in first place. I personally wanted to keep Blender useful for Second life users. And having an intact Collada Exporter is a key feature. And i am happy that i could reach this goal for Second Life. On the other side, having an intact Collada Importer was not such a big necessity (for us), so i originally did not plan to put effort into this section as well. However i actually DID put effort into the importer because i found it was only a half job to make the exporter work, but keep the importer behind. However, the major problem of Collada is that its too versatile. So all you can really try to achieve is to support the Collada exporter for a couple of selected 3D applications. I was attempting to do this for Maya. But i found the time that i need to put into this effort was just "too much". I mean, i do not need to have an Importer that works like a charm for every Collada file in the world... > The best option is to finish the job on the current one that is almost there. > What I can offer is test cases and QA service for the last 10% of the > Collada importer/exporter fix (support of multiple meshes/bind poses) > and Mixamo stocks as payment. A good friend told me once that "the last 10% of a software implementation takes about 90 % of the total implementation time"... I am not sure if this is just a saying, or more like a common rule and if that applies also to the Collada module. But what i know for sure is, that a Collada Importer is way more complicated than an exporter. But ... well... Now what is "Mixamo stocks as payment" exactly ? cheers, Gaia ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.70/python/lib/site-packages/.svn
I thank for an answer. It is included in blender-2.70a-windows32.zip/blender-2.70a-windows64.zip distributed in an official site. I do not understand it about the package of other OS's. Because there is it, some problem does not occur, but does not want to only leave an unnecessary thing. I think that the folder for unnecessary management did not come to be installed when it was managed before in SVN. I was interested in this respect because it did not come to look like it. If you consider it when Python3.4 is enclosed, I am glad. PerfectionCat - Original Message - >From: Sergey Sharybin >To: PerfectionCat ; bf-blender developers > >Date: 2014/4/27, Sun 21:38 >Subject: Re: [Bf-committers] 2.70/python/lib/site-packages/.svn > > >This it not necessery. Which platform exactly it is affected on? > > > >On Sat, Apr 26, 2014 at 11:35 AM, PerfectionCat >wrote: > >Hi, Devs. >> >>2.70/python/lib/site-packages/.svn folder is included in a zip file of 2.70a >>distributed in an official site, but is this necessary? >> >> >>PerfectionCat >>___ >>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] Importing Assets: FBX VS Collada
Just curious.. Would it not be possible to include a generic sub-process/pipe import/export feature in blender. This would allow an external utility to be run (transparent to the user, once install) which would be given the filename (and/or sent the data via the stdio pipe) and in return it would send a .blend formatted file (or sub-set of) back. Then it would be processed like a file append. Exporting would be similar, only with reversed data along the pipe. After that, create a separate add-on [sub-]project with code that uses the FBX SDK with a compatible license, which users could install if needed. It would also allow other formats to better supported if license incompatible native libraries exist for them. -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Importing Assets: FBX VS Collada
@Chad yes that is possible, it was discussed on IRC the other day and Ton dismissed (I think sanely) due to it being too difficult for people to install the separate converter (for FBX for example) due to the licenses preventing the distribution of the FBX SDK together with Blender. @Stefano seems to be making a strong case in my view. Also because the current Collada support has worked fine for us so far (game related exports, sometimes imports - we even once used it to bring Blender 2.4x scenes to 2.5 for some blends that otherwise just crashed on 2.5). I took a look at the Collada <-> FBX converter. Works fine as expected, installed it more to check the license. I think it talked about 'single install' etc. and am guessing it prevents distribution. Have no idea for real though, IANAL. But is it really that bad that someone who works professionally on game content has to install one app? If Blender converters can then automated calling it etc. Also with Ogre that has been the case: the Blender exporter just outputs Ogre XML and then the separate OgreXMLConverter (by Ogre folks) is called automatically by the blender2ogre add-on -- but the user has had to install the converter (a native cmdline app) manually. Is ofc not as nice as direct export but certainly has not blocked the use, I haven't heard complaints even. BTW does the FBX SDK license really prevent distribution? Ah apparently Ton has clarified this back in 2011 already: http://wiki.blender.org/index.php/User:Ton/Autodesk_FBX_EULA . If I understand that correctly, distributing the FBX SDK with Blender would mean that we'd have to deny people from redistributing Blender etc. which is just not possible (not compatible with any free software or open source license, impossible for linux distros where apps come from dist repos etc). I wonder if Autodesk could relax that single point, just allow the distribution of the closed SDK binary. Am not holding my breath :) BTW SecondLife uses this tech of piping with a separate process to distribute the whole of (L)GPL 3d app code (slviewer) + closed binary for the proprietary voice impl (SLVoice.exe using Vivox). That would be exactly like Blender shipping with and using FBX SDK. Folks have also written an open source SLVoice.exe replacement using Mumble then so the idea of free software indeed remains intact in those cases -- the inter-process protocol is open for anyone to implement how they wish. So technically and regarding the GPL it is all fine, only the Autodesk license prevents it (according to Ton's summary). Again, @Stefano's points seem strong to me and using FBX via Collada & the converter would probably be fine for me. And with some luck calling the converter can be automated like with Ogre's export. I think the converter is freeware, no limited time evaluation licenses or something like which Ton refers to regarding the FBX SDK. But my view doesn't weight anything in this, I don't even need FBX at the moment and am not familiar with the deep issues, will just go back to happily using three.js and Collada (import when get models from web collections as dae, export for glTF conversions) now.. I guess folks who use FBX can test this easily: if you bring your FBX to/from Blender via that converter & the current Collada support, do the things you need work? ~Toni On Mon, Apr 28, 2014 at 5:03 AM, Chad Fraleigh wrote: > Just curious.. > > Would it not be possible to include a generic sub-process/pipe > import/export feature in blender. This would allow an external utility to > be run (transparent to the user, once install) which would be given the > filename (and/or sent the data via the stdio pipe) and in return it would > send a .blend formatted file (or sub-set of) back. Then it would be > processed like a file append. Exporting would be similar, only with > reversed data along the pipe. > > After that, create a separate add-on [sub-]project with code that uses the > FBX SDK with a compatible license, which users could install if needed. It > would also allow other formats to better supported if license incompatible > native libraries exist for them. > > -Chad > ___ > 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
