Re: [Bf-committers] OS X update to XCode 4 breaks compiling
Hi Ton, It seems we'll need to move to XCode 4, but XCode 3.x is still available. (I even use an external HS to boot on 10.5 to build libs, with XCode 3.0). I'll soon get XCode 4, but I'm never in a rush to get a x.0 release, I always prefer to wait for the x.1 with its bug fixes... But I do have currently an issue with 10.4 libs, namely Python 3.2. Python needs to be compiled on the target platform (cross compiling, even when succeeding to get a build, gives errors in the python modules at runtime). So to be able to make the next release with 10.4 builds, we need to get builders who still have 10.4. Unfortunately my contacts who made the Python 3.1 10.4 builds have upgraded to 10.5... Damien Le 19 mars 2011 à 15:30, Ton Roosendaal a écrit : Hi Damien, I had the impression that an upgrade to XCode4 replaces XCode3 entirely? That would make it a complex issue, it seems xcode4 is especially needed for ipad/phone devs. With 10.7 announced for this summer we can wait for this release first, check what's needed to keep it all work and then make a final 10.4 decision. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 19 Mar, 2011, at 13:36, Damien Plisson wrote: BTW, why rushing to XCode 4? I mean Blender is not a native Cocoa application with heavy Interface Builder use, and other fancy stuff that'll take advantage of the new XCode 4 ? Personally, I'm staying with XCode 3 for Blender build debug for now. But the 10.4 support question remains: do we still want to support 10.4 for Blender now that 10.7 is announced ? Leaving 10.4 support will help also for library (including Python) support. Building only 1 version (the 10.5 universal) instead of 3. Damien Le 14 mars 2011 à 17:04, Ton Roosendaal a écrit : Hi OSX devs, Apple's new development update XCode 4 now is available (only when you pay FIVE dollars!). Someone in irc mentioned blender doesn't compile (at all) for it. Further, this XCode revision drops compiling for older OSX versions (10.4 and 10.5) and the install removes all libs/headers for it. Here's a report: http://www.blender.org/forum/viewtopic.php?t=19500 -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ 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] OS X update to XCode 4 breaks compiling
BTW, why rushing to XCode 4? I mean Blender is not a native Cocoa application with heavy Interface Builder use, and other fancy stuff that'll take advantage of the new XCode 4 ? Personally, I'm staying with XCode 3 for Blender build debug for now. But the 10.4 support question remains: do we still want to support 10.4 for Blender now that 10.7 is announced ? Leaving 10.4 support will help also for library (including Python) support. Building only 1 version (the 10.5 universal) instead of 3. Damien Le 14 mars 2011 à 17:04, Ton Roosendaal a écrit : Hi OSX devs, Apple's new development update XCode 4 now is available (only when you pay FIVE dollars!). Someone in irc mentioned blender doesn't compile (at all) for it. Further, this XCode revision drops compiling for older OSX versions (10.4 and 10.5) and the install removes all libs/headers for it. Here's a report: http://www.blender.org/forum/viewtopic.php?t=19500 -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ 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] Fwd: Copyright violation distributing faac binaries together with GPL software
FYI, the OSX ffmpeg libs are build with version 0.6.1 and are not linked against libfaac. Damien Le 6 janv. 2011 à 18:42, Sergey Kurdakov a écrit : Hi Ton, I checked ffmpeg code (0.6.1 - it should be there for some time though since version 0.5 I think)- if it is possible to link against ffmpeg 6.1 why not to use it?) and it contains native ( for ffmpeg) aac encoder it is there as a replacement for libfaac. It is of lower quality thought. as an alternative VP8/WebM+ Vorbis is preferred now - it is of comparable quality ( video ) and good sound quality. But then again - ffmpeg contains acc encoder even without libfaac, just not of high quality Regards Sergey ___ 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] Release 2.56a AHOY
The 3 OSX builds are on the ftp /incoming Damien Le 4 janv. 2011 à 18:54, Ton Roosendaal a écrit : Hi all, Let's go for an update on 2.56 now. A tag will be done still, make sure you get revision 34074 at least. Binaries can be provided as usual. Ensure it has 2.56a in the name, but further no changes needed. :) Thanks! -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ 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] 2.56-beta release AHOY!
Hi Ton, Using cmake on 33942 and building with xcode gave me the 2.56 directory in the app bundle fine. And the 2.56 directory is also created at runtime in the Application Support/Blender folder. Maybe it is an issue with cmake/makefiles ? Damien Le 29 déc. 2010 à 20:10, Ton Roosendaal a écrit : Hi all, Let's freeze svn for a day to prevent confusing situations, and have release builders work on what they need to get a good binary! Only do commits related to making the builds please. SVN needs to be tagged still; but last commit from me was 33942. Tag will be announced here too. Send out binaries via the usual channels, or ask me for where to put them! Note: cmake for my Mac failed to make a 2.56 directory in the app bundle... needs to be checked on. Thanks! -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ 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] Blender developer meeting minutes 26 dec 2010
Sure, my scripts are ready to build the OSX versions! BTW, are there any external libs must update to perform for this release ? Damien Le 26 déc. 2010 à 16:48, Ton Roosendaal a écrit : Hi all, 1) Blender 2.56-beta - All seems to be ready for a new beta test build, more stable than ever! - Proposal is to call for a release AHOY on wednesday - euro time. We then can prepare for the release on thursday or friday. - Yes, we need urgent update on regression test files, is on Ton's todo! - Splash: a bit late for a contest, we can pick one last cool shot from Sintel! For next release we can announce a contest again. Need to revise or reconfirm how to define contests and judging well. Are the platform maintainers standy this week? Platform maintainers: - Linux: Ken Hughes (confirmed) - Mac OS X: Damien Plisson - Windows: Nathan Letwory Roadmap: after 2.56 more efforts will go to the pending 2.5 todos. And then in 1-2 months maybe a first real almost-finished-no-beta :) 2) Other projects, branches - Janne Karhu: he approved on Stephen Whitehorn viscoelastic fluid particle springs code, is almost ready for merge to trunk. Not real new, but completes functionality for fluid particle system. Will be submitted after 2.56. Thanks, -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ 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] 2.55 beta AHOY!
Mike, It is when building blender with the game engine enabled. Damien Le 30 oct. 2010 à 04:29, Mike S a écrit : On 29/10/10 5:26 AM, Damien Plisson wrote: Done for the three OSX releases. Just note that they still include Python 3.1.1 as the lib builder has encountered issues with building the 3.1.2 (it mainly caused problems with the BGE). Damien Hi Damien, OK confused now Nathan has said on IRC that he uses python 3.12 source tarball for python build (windows I think). I have compiled 3.12 from source for OSX with the one patch for the xmlrpc fix:: Oh, and if you bundle Python on your platform, please apply patch found in http://bugs.python.org/issue9991, that'll save us some bug reports on XMLRPC HTTPS support. And this compiles ok as a lib (all 4 arch) and with blender. I dont use the game engine...so is the problem with game engine after build (playing games) or during the build process? Mike. Le 27 oct. 2010 à 13:53, Nathan Letwory a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi release builders! Over 340 bugfixes and more than 760 commits to trunk/ since 2.54 beta. I've committed new splash, bumped versions and danced the tagging dance. Please checkout tags/blender-2.55-release at r32738 and start your building engines. Notify me when you have your builds ready. Note: make sure you build against Python 3.1.2 and for OpenCOLLADA use r771 or later from their SVN. Note2: see Note /Nathan ___ 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] 2.55 beta AHOY!
Hi Dalai, The bug is still present with Python 3.1.1. Anyway, for Python 3.1.2, Jens has found a fix to enable BGE to compile again. I'll commit it with 3.1.2. BTW, for the other bug ([#23871] OSX panel button bug) it'll need a fix introduced only in 3.2 Diff for BGE to compile with 3.1.2: Index: source/gameengine/Expressions/KX_Python.h === --- source/gameengine/Expressions/KX_Python.h (revision 32756) +++ source/gameengine/Expressions/KX_Python.h (working copy) @@ -66,5 +66,22 @@ #endif #endif +#ifdef __APPLE__ +#undef isalnum +#undef isalpha +#undef iscntrl +#undef isdigit +#undef isgraph +#undef islower +#undef isprint +#undef ispunct +#undef isspace +#undef isupper +#undef isxdigit +#undef tolower +#undef toupper +#endif + + #endif // KX_PYTHON_H Le 29 oct. 2010 à 02:09, Dalai Felinto a écrit : Hi Damien, can you test if this bug happens with your builds: https://projects.blender.org/tracker/?func=detailatid=498aid=23346group_id=9 https://projects.blender.org/tracker/?func=detailatid=498aid=23346group_id=9It's supposed to be related with Python 3.1.1 and fixed in Python 3.1.2. Also, what was the problems you had with 3.1.2 and the gameengine? Thanks, Dalai 2010/10/28 Damien Plisson damien.plis...@yahoo.fr Done for the three OSX releases. Just note that they still include Python 3.1.1 as the lib builder has encountered issues with building the 3.1.2 (it mainly caused problems with the BGE). Damien ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.55 beta AHOY!
Done for the three OSX releases. Just note that they still include Python 3.1.1 as the lib builder has encountered issues with building the 3.1.2 (it mainly caused problems with the BGE). Damien Le 27 oct. 2010 à 13:53, Nathan Letwory a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi release builders! Over 340 bugfixes and more than 760 commits to trunk/ since 2.54 beta. I've committed new splash, bumped versions and danced the tagging dance. Please checkout tags/blender-2.55-release at r32738 and start your building engines. Notify me when you have your builds ready. Note: make sure you build against Python 3.1.2 and for OpenCOLLADA use r771 or later from their SVN. Note2: see Note /Nathan - -- Nathan Letwory Blender Foundation | Letwory Interactive http://www.blender.org | http://www.letworyinteractive.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMyBLIAAoJEKtfN7KsE0TthnYIAKU1D/NAmTIA+EC1wQXr3r4Y x2Tnx2GGCrh7yZu0TRLOcpk/PNteA2sHVc9xJOa+cpZMtxDEljYoC6vt0zuicbN1 iAljxuY4hM/TmVCdCfiwB8oMBFWmxwbydHg5wg8lGFmzpwEVjUJxJAj1geVwiQA1 6kN74URGgkVea6lKNtbdDYasa9NeVkaUsJQDKWNu6i2XSnp/JfccmpTntycrJCJP cEV5lyuQCxVa4uyYJc91VomxnOTK/zBlqZaV/20FS0NBtCA321a4vDmH0wbSn9f9 6zJ07c4aehzFw/sU6PHOWnIGZfKWMuTYmfk6hpuGzmkLS2Ptzk6ivw7zrIH+8dM= =mBcl -END PGP SIGNATURE- ___ 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] 2.55 beta AHOY!
Peter, You upload only the release build it to the ftp download.blender.org/incoming. Name it blender-2.55-beta-FreeBSD Cheers, Damien Le 28 oct. 2010 à 21:50, pete larabell a écrit : Hi Damien, I've built the FreeBSD build on behalf of Miss Jaevixa McNomera while she's incapacitated, but as this is my first time building an official build, I'm not sure what to DO with the build after I built it... I've uploaded the debug + release both to graphicall.org as I've posted earlier in the email. Is that all I have to do, or was I supposed to upload to a specific location Thanks! Peter On Thu, Oct 28, 2010 at 1:56 PM, Damien Plisson damien.plis...@yahoo.frwrote: Done for the three OSX releases. Just note that they still include Python 3.1.1 as the lib builder has encountered issues with building the 3.1.2 (it mainly caused problems with the BGE). Damien Le 27 oct. 2010 à 13:53, Nathan Letwory a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi release builders! Over 340 bugfixes and more than 760 commits to trunk/ since 2.54 beta. I've committed new splash, bumped versions and danced the tagging dance. Please checkout tags/blender-2.55-release at r32738 and start your building engines. Notify me when you have your builds ready. Note: make sure you build against Python 3.1.2 and for OpenCOLLADA use r771 or later from their SVN. Note2: see Note /Nathan - -- Nathan Letwory Blender Foundation | Letwory Interactive http://www.blender.org | http://www.letworyinteractive.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMyBLIAAoJEKtfN7KsE0TthnYIAKU1D/NAmTIA+EC1wQXr3r4Y x2Tnx2GGCrh7yZu0TRLOcpk/PNteA2sHVc9xJOa+cpZMtxDEljYoC6vt0zuicbN1 iAljxuY4hM/TmVCdCfiwB8oMBFWmxwbydHg5wg8lGFmzpwEVjUJxJAj1geVwiQA1 6kN74URGgkVea6lKNtbdDYasa9NeVkaUsJQDKWNu6i2XSnp/JfccmpTntycrJCJP cEV5lyuQCxVa4uyYJc91VomxnOTK/zBlqZaV/20FS0NBtCA321a4vDmH0wbSn9f9 6zJ07c4aehzFw/sU6PHOWnIGZfKWMuTYmfk6hpuGzmkLS2Ptzk6ivw7zrIH+8dM= =mBcl -END PGP SIGNATURE- ___ 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] 2.55 beta AHOY!
blender-2.55-beta-FreeBSD-amd64 Le 28 oct. 2010 à 22:07, pete larabell a écrit : Damien, Thanks so much for clarifying that! That is what I needed to know!!! xD Build has been uploaded as blender-2.55-beta-FreeBSD.tbz Could you please tell me what I should name the amd64 build once I try to upload THAT? Thanks again! Peter On Thu, Oct 28, 2010 at 2:57 PM, Damien Plisson damien.plis...@yahoo.frwrote: Peter, You upload only the release build it to the ftp download.blender.org/incoming. Name it blender-2.55-beta-FreeBSD Cheers, Damien Le 28 oct. 2010 à 21:50, pete larabell a écrit : Hi Damien, I've built the FreeBSD build on behalf of Miss Jaevixa McNomera while she's incapacitated, but as this is my first time building an official build, I'm not sure what to DO with the build after I built it... I've uploaded the debug + release both to graphicall.org as I've posted earlier in the email. Is that all I have to do, or was I supposed to upload to a specific location Thanks! Peter ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] OpenCollada SVN
I'll have my MBP run this night on the so long Collada build. But this 6-10 hours build time is the main reason I'm not updating it for each release... For OSX build, you normally don't have to build any external lib by yourself. You just need to checkout the lib folder corresponding to your architecture (e.g. darwin-9.x-universal) for 10.5+ builds. And it contains all the needed external libs. Cheers, Damien Le 23 oct. 2010 à 10:00, Mike Sloman a écrit : On 23/10/10 5:43 PM, Mike Sloman wrote: On 23/10/10 4:55 PM, Benjamin Tolputt wrote: I've been trying to compile the SVN release of Blender on OSX without success. There are errors in the darwin-9.xuniversal version of OpenCollada (as checked out of SVN) that prevent compilation. Is this because the library is out of date in SVN or the fact that CMake is not supported (the build directions on the website do not indicate this though). Hi Benajmin, yes the current SVN for opencollada is out of date. I have compiled and used r733 from opencollada after changing the scons file as instructed int he build instructyions and found that all is well after that. However I dont have write access to blender svn to upload it, so you have to build your own until whomever is responible for building for darwin uploads. Mike. Oops make that r773 opencollada. Have fun..it takes a long long time to build :( Last commit log entry::: r32280 | damien78 | 2010-10-04 03:53:39 +1030 (Mon, 04 Oct 2010) | 1 line OSX/Cocoa 10.5 libs: update OpenCollada libs to rev. 769 + jesterKing patch Happy to upload my build (darwin9) if someone gives me write access to the repository. A few questions I have too: 1. Perhaps I have missed it... is there a wiki page that lists all the current third party lib versions required to build both the development head and stable releases?? 2. For MAC builds this page http://wiki.blender.org/index.php/Dev:2.5/Doc/Building_Blender/Mac states that we need to build and use FFMPEG on the system, but the libs still have FFMPEG builds (which I am currently using). Which is correct to do?? Cheers, Mike. ___ 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] 2.54 beta AHOY!
ok, I just started to upload the OSX build. But I can't delete the file. Can someone with the delete access rights remove the file from the ftp incoming? I'll upload the new versions in a few hours. Thanks, Damien Le 11 sept. 2010 à 12:26, Nathan Letwory a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10.9.2010 19:41, Ton Roosendaal wrote: Hi, Yet another beta official test build, but much better than previous one! :) Let them compile systems running, and provide the builds as usual. Notify me or Nathan where we can find them. There were some last-minute fixes and changes. I have retagged both bf-blender trunk and bf-extensions addons. Builders, please svn up in your blender-2.54-release checkout and rebuild. Thanks! /Nathan - -- Nathan Letwory Letwory Interactive http://www.letworyinteractive.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMi1lfAAoJEKtfN7KsE0TtftcIAKkfCP/8HCGRtAJ95fBngY3X SGTtct2At7yZM54woBvPy12gcwcJlVCKQKC+aSxvZL3xAjHWH+15LVyh8Hui0mBA 3N/gVk2YiMq99wrMyfe3spvprH8jaOXnYv/F8M+M/EnzPOYREf2+rZG8rSq1Bvgm ihevArZLJ7P4x211KkTqsxrYFVbjHL6TKmE6r2/56uJGWitOfPFNUMl9oBp6pIxk hDQNQIcZow1nduPIc0L4sgv8ocQbgX3xA1wmSrkhW0Hupho6LH4SBF1piRviX77z bzcEFZYT821Wka7B24ZkBRyliYfZzpnL05ZkQp7mExp94PC1nDKJWqHp2FcZeWk= =s2NZ -END PGP SIGNATURE- ___ 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] 2.54 beta AHOY!
Done uploading the 3 OSX versions in a dedicated OSX-2.54 subdir. Damien Le 11 sept. 2010 à 13:32, Damien Plisson a écrit : ok, I just started to upload the OSX build. But I can't delete the file. Can someone with the delete access rights remove the file from the ftp incoming? I'll upload the new versions in a few hours. Thanks, Damien Le 11 sept. 2010 à 12:26, Nathan Letwory a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10.9.2010 19:41, Ton Roosendaal wrote: Hi, Yet another beta official test build, but much better than previous one! :) Let them compile systems running, and provide the builds as usual. Notify me or Nathan where we can find them. There were some last-minute fixes and changes. I have retagged both bf-blender trunk and bf-extensions addons. Builders, please svn up in your blender-2.54-release checkout and rebuild. Thanks! /Nathan - -- Nathan Letwory Letwory Interactive http://www.letworyinteractive.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMi1lfAAoJEKtfN7KsE0TtftcIAKkfCP/8HCGRtAJ95fBngY3X SGTtct2At7yZM54woBvPy12gcwcJlVCKQKC+aSxvZL3xAjHWH+15LVyh8Hui0mBA 3N/gVk2YiMq99wrMyfe3spvprH8jaOXnYv/F8M+M/EnzPOYREf2+rZG8rSq1Bvgm ihevArZLJ7P4x211KkTqsxrYFVbjHL6TKmE6r2/56uJGWitOfPFNUMl9oBp6pIxk hDQNQIcZow1nduPIc0L4sgv8ocQbgX3xA1wmSrkhW0Hupho6LH4SBF1piRviX77z bzcEFZYT821Wka7B24ZkBRyliYfZzpnL05ZkQp7mExp94PC1nDKJWqHp2FcZeWk= =s2NZ -END PGP SIGNATURE- ___ 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] Blender IRC meeting minutes, sept 5 2010
I definitely agree for the bad bug, and place a call for GL coders with OSX ATI system, as ATI drivers on OSX have real issues the nVidia ones don't have. It is the latest update of the ATI drivers (the one Apple is supposed to have made following Valve requests to reach decent GL perfs) that revealed this incompatibility. That is previous releases were not having this crash at the time they were released. But the GL call causing the crash may have been introduced anytime during 2.5 dev. Cheers, Damien Le 5 sept. 2010 à 23:45, Dalai Felinto a écrit : I'm not sure what is considered a showstopper for a beta, but this is a really bad bug: Blender 2.5 Crashes on Window Resize on OSX: http://projects.blender.org/tracker/index.php?func=detailaid=23561group_id=9atid=498 Current status: Damien needs a GL guru who has access to a Mac running 10.6.4 with ATI. It happens with Alpha and Beta2,3 so may not be qualify as a showstoper. release blenderplayer +1, but then it's important to move the addon to export as blenderplayer into the built-in addons (instead of contribs). Cheers, Dalai 2010/9/5 Mitchell Stokes moguri...@gmail.com: - This wednesday I like to call for release-builds, unless someone finds serious showstoppers. Please notify it on the bf-committers list! I have one request for the beta: could we please also release the Blenderplayer? If there are issues with building the player, I can help people on IRC with resolving them. The player still has some bugs, but it would be nice to get more users to test it so we can make sure it's actually stable by the time Blender itself is stable. Thank you, Mitchell Stokes (Moguri) ___ 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] Blender 2.53 beta AHOY!
All three OSX builds are on the ftp server. Builds were made with svn # 30554 Damien Le 20 juil. 2010 à 20:19, Ton Roosendaal a écrit : Hi all, Svn is updated, the release code has been upped to 253. So we can get the compile machines running! I'd like to ask everyone to stop committing in trunk until we have confirmation from the release builders that things are OK for them. Only crucial fixes should go to svn now. Please use #blendercoders IRC for urgent feedback. While writing this, I already get two amendments in. Daniel Salazar found sculpt issues, Andrea Weikert likes to fix two small but important path issues. Updates will be following here... -Ton- BTW: The filenames for the builds can be like blender-2.53-beta-OS- blah.zip. Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ 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] Blender 2.5x beta status
My build shell scripts are warming up for the 3 mac builds :) BTW, do we keep .zip files or do we go with standard mac .dmg ? .dmg are roughly 10% bigger but enable nice features such as background image, and explicit installation (copy to Application folder). Damien Le 13 juil. 2010 à 20:53, Ton Roosendaal a écrit : Hi devs, Any showstoppers in sight for a new official build? Joshua: can you check bug 22816? http://projects.blender.org/tracker/index.php?func=detailaid=22816group_id=9atid=498 Update on the sculpt patch: Brecht and Nicholas don't have time for extensive reviews, but user reports from the fields are so positive (more stable than trunk) that Tom Musgrave accepts the responsibility to apply patch now. If there's serious issues he'll rewind it tomorrow. Thursday we can do a final check and possibly call for the release Ahoy! Release builders are available end this week too? Please check in :) -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 10 Jul, 2010, at 17:37, Ton Roosendaal wrote: Hi all, According to the commits, the last of the missing beta targets is now in svn (install paths). That means we can get ready for an official beta release. With beta as in feature complete, not yet stable. :) We will need to do some documentation efforts on precisely defining what 'feature complete' is though, some 2.5 targets have been postponed, some are still limited. Nevertheless, we've made great progress, and having a reference build out for bug reports and feedback is only important now. This will be a topic on tomorrow's sunday meeting, also to check if there's showstoppers. For planning I'd propose to svn tag wednesday, do the traditional last commit(s), and we'll release it friday or saturday. In the meantime we need to work on: - nice release log - splash (durian team) - docs about where 2.5 bottlenecks are still, what works and what's in development... - update doc on roadmap, what will happen 2nd half of this year I need have to keep a bit space in our planning because of Durian (last week of work here, pre-premiere in 8 days), because of the horrible heat (30 degrees outside, 30 computers inside), and of course the football match final tomorrow evening! :) Laters, -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ 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] International Input
Unfortunately it's more complicated on OSX than on Win32 for these dead keys handling. The low level Unicode translation function that handles dead keys and int'l keyboards breaks the symmetry of keyDown/keyUp, that is the returned character string changes: null for the dead key = ok accented char when the correct key is pressed afterward = ok non accented char when that key is released = breaks the symmetry ! And also pressing ^ + t will display ^t, but giving ^ upon t keydown, and t upon t keyup ! You may get the same issue under Win32, don't you ? So there is a need for changing the ascii value attached to the ghost key event further, to become a character insert value (upon keydown AND keyup), and nothing else (not a way to identify keypressed). But that may be partially the case already, the keyCode being the one to identify the key pressed. Damien Le 23 avr. 2010 à 08:25, Ignacio Fernandez Moreno a écrit : Hi Damien, Those are good news, Can you add that to the patch i put before? The two character issue has to do with the so called dead keys (keys that act as modifiers to the next key pressed). For windows i made a one line patch to prevent filling the key event with ascii data in those cases. Maybe the same could be done in other systems. The patch: https://projects.blender.org/tracker/index.php?func=detailaid=22106group_id=9atid=127 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] libtiff linking
Quicktime provides support for tiff only for reading. Libtiff dyn lib is thus still needed to be installed on OSX for getting tiff write support. FYI, I added the write support a while ago, but following a discussion with Matt, I reverted it. The main issue was that all platforms need to provide 100% exactly same rendering (i.e. colorimetry, ...), and so all platforms has to use libtiff and no other tiff interpreter. Especially important on a multiplatform production environment. Damien Le 19 avr. 2010 à 15:19, Campbell Barton a écrit : quicktime/tiff wouldn't support tiff mipmap's and tiling so we could include on all OS's now. Wait until Brecht merges his mipmap commit into trunk before attempting. On Mon, Apr 19, 2010 at 2:23 PM, Jonathan Merritt merr...@unimelb.edu.au wrote: On Mon, 2010-04-19 at 19:30 +1000, Matt Ebb wrote: On Mon, Apr 19, 2010 at 7:20 PM, Campbell Barton ideasma...@gmail.com wrote: Is there any reason we still dynamically load libtiff?, Why don't we static link like OpenEXR, or link normally as we do with libjpeg. I could be wrong, but from memory there were concerns about the size of the library when it was first introduced.. But it seems to be linked statically here on osx anyway, with no big problem really. Spot on - at the time, libtiff was mainly required for Linux, since QuickTime was handling TIFF under OSX and Windows. I wrote the dynamic load and stub methods, and needed a lot of help for the platform-specific library detection. I would love to see all that disappear in favour of normal linking (static or dynamic). :-) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Tesbuild ahoy: alpha2
Hi, The three OSX builds are now on the ftp! BTW, contrary to what is said on the blender.org download page, all osx versions have ffmpeg (even the ppc one), and the 32bit intel version is needed only by the CoreDuo/CoreSolo Macs that can't run the 64bit version (the Core2 or later ones are shipped with 10.5 or later and thus can always run the 64bit version). Damien Le 2 mars 2010 à 20:24, Ton Roosendaal a écrit : Hi, Forgot the splash... :) Revision 27226 -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 2 Mar, 2010, at 19:53, Ton Roosendaal wrote: Hi, Can the release team build with revision of 27224, and post it on ftp or give me the urls? Tomorrow will then replace this with the old alpha, which had a very bad bug. Thanks! -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ 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] OpenCollada issues (was Re: Meeting minutes, feb 14, 2010)
Oups, sorry, I posted on the ML the patch as an attachment. Here is the pasteall link: http://www.pasteall.org/11157 Damien Le 20 févr. 2010 à 15:35, Damien Plisson a écrit : Hi Arystan, Looking at the float-to-string function, it appears it does bitwise operations on long type vars. And this particular 'long' type size changes when going from 32 to 64bit ! Here is a patch that replaces the long type with fixed length int32_t. It makes the cube export work well : If you confirm this fixes the issue, I'll commit the updated darwin9 lib. Cheers, Damien Le 20 févr. 2010 à 14:41, Arystan Dyussenov a écrit : Damien, Ken, Zero-sized cube problem is fixed. This problem was caused by OpenCollada's own float-to-string conversion functions which don't work correctly on 64-bit systems. The fix was to use sprintf. The disadvantage of using sprintf is that precision has to be limited to N digits in fractional part. This patch modifies conversion functions to use sprintf with 6 digits after the decimal point stripping off trailing zeros. The patch is on the wiki: http://wiki.blender.org/index.php/File:Opencollada_ftoa_patch.diff Tested on 64-bit Mac OSX 10.6. The original float-to-string function looks like this: http://www.pasteall.org/11155/c It only works on 32-bit. On 64-bit, it at minimum ignores the sign. If anyone knows how to make it work on 64-bit, that'd be a real fix! Arystan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] OpenCollada issues (was Re: Meeting minutes, feb 14, 2010)
You can then forward it to the opencollada team ;) Le 20 févr. 2010 à 16:21, Arystan Dyussenov a écrit : Your patch fixes the issue. Tested on 64-bit Mac. Cool! Arystan On Sat, Feb 20, 2010 at 8:44 PM, Damien Plisson damien.plis...@yahoo.frwrote: Oups, sorry, I posted on the ML the patch as an attachment. Here is the pasteall link: http://www.pasteall.org/11157 Damien Le 20 févr. 2010 à 15:35, Damien Plisson a écrit : Hi Arystan, Looking at the float-to-string function, it appears it does bitwise operations on long type vars. And this particular 'long' type size changes when going from 32 to 64bit ! Here is a patch that replaces the long type with fixed length int32_t. It makes the cube export work well : If you confirm this fixes the issue, I'll commit the updated darwin9 lib. Cheers, Damien Le 20 févr. 2010 à 14:41, Arystan Dyussenov a écrit : Damien, Ken, Zero-sized cube problem is fixed. This problem was caused by OpenCollada's own float-to-string conversion functions which don't work correctly on 64-bit systems. The fix was to use sprintf. The disadvantage of using sprintf is that precision has to be limited to N digits in fractional part. This patch modifies conversion functions to use sprintf with 6 digits after the decimal point stripping off trailing zeros. The patch is on the wiki: http://wiki.blender.org/index.php/File:Opencollada_ftoa_patch.diff Tested on 64-bit Mac OSX 10.6. The original float-to-string function looks like this: http://www.pasteall.org/11155/c It only works on 32-bit. On 64-bit, it at minimum ignores the sign. If anyone knows how to make it work on 64-bit, that'd be a real fix! Arystan ___ 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] OpenCollada issues (was Re: Meeting minutes, feb 14, 2010)
I have exactly the same issue on OSX. (Zero size cube) Damien Le 17 févr. 2010 à 01:45, Ken Hughes a écrit : Let me give more details. Removed ~/.blender, ran blender build with collada Deleted everything from basic scene except cube Export -- COLLADA (.dae) set filename to cube.dae, press Export COLLADA button. Messages are displayed in terminal window: RNA_string_set: WM_OT_collada_export.filename not found. RNA_string_set: WM_OT_collada_export.directory not found. Delete cube from scene. Import -- COLLADA (.dae) selectcube.dae, press Import COLLADA button. Messages are displayed in terminal window: RNA_string_set: WM_OT_collada_import.filename not found. RNA_string_set: WM_OT_collada_import.directory not found. Cannot find texture array by texture index. A zero size cube is created: all vertices/edges/faces, but vertices seem to have the same coordinate (1,1,0). The cube.dae file is attached. Ken Ok, that would be no, it doesn't work. Ken Tom M wrote: Simple test, export cube via collada, delete cube from scene, import the cube.dae you created and see if you now have cube in your scene, LetterRip On Mon, Feb 15, 2010 at 5:44 PM, Ken Hughes khug...@pacific.edu wrote: Thanks to tips from Martin, looks like I'm on board. Will include FFMPEG and Collada, although would be good if someone can test some builds first to verify collada functionality. That is, assuming there's something more than just seeing if it comes up in the Import and Export menus. Ken ___ 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] Meeting minutes, feb 14, 2010
Hi, I can make the Mac builds. Collada can be included. FFMPEG will be included. As for alpha 0, all OSX needs can be covered with the 3 releases: 10.4/ppc, 10.4/i386, 10.5/x86_64. Damien Le 14 févr. 2010 à 17:50, Ton Roosendaal a écrit : Hi all, 1) Current projects - Campbell proposes way to have a proper default/install path for extension scripts. This invoked too much confusing discussions; conclusions will follow. 2) Blender 2.5 - Installer issues have to be solved... Ton, Campbell + Brecht will review a proposal and put online for discussions. - Andrea volunteers to check on proper install procedure for Windows. - Proposal got accepted to make a testbuild available this week. It will be named 2.5 alpha 1. The real (stable, documentation ready) release is going to be there soon, but not within a few weeks... the amount of fixes and bugreports (100+ per week) indicate we have to give it time. - Blender alpha 1 topics for release builders: - Collada included? Linux no, Windows yes. Mac? - Ffmpg include preferably - Ton arranges a splash and does the ritual release # commit. - Most likely building can start tuesday end of day. - Release builders will be: - win32: Andrea - win64: ... - Linux 32/64: Ken Hughes - OSX 10.4/5 (and 6?) intel: ... - OSX 10.4/5 (and 6?) ppc: ... - Tom Musgrove volunteers to check on import/export 'regression files' -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ 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] scons/install stale files problem.
Hi, These resource files and directories update is part of the update GSR is coding (using env vars too for tweaking the paths defs). As described here : http://wiki.blender.org/index.php/BlenderDev/Blender2.5/EnvironmentVariables BTW, there is the same issue of ~/.blender not being natural on OSX too. I made a patch to change this, but it will be merged by GSR with his work eventually. Damien Le 11 févr. 2010 à 13:51, Brecht Van Lommel a écrit : Loading from the user directory seems to be suboptimal on Windows right now, the expected directory is this. C:\Documents and Settings\User\.blender\scripts That can be changed to this, and the folder can be created automatically on startup to make things easier. C:\Documents and Settings\User\Blender Foundation\Blender\scripts Brecht. ___ 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] SVN commit: /data/svn/bf-blender [26656] trunk/blender/source/blender/ editors/interface/view2d.c: Fix jumping panels when opening a new properties area or area co
Hi Brecht, This fix broke the user preferences display whose controls are now displayed too much to the left. The leftmost ones are even truncated. The issue is still present with rev 26775. Damien Le 7 févr. 2010 à 02:11, Brecht Van Lommel a écrit : Revision: 26656 http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=revroot=bf-blenderrevision=26656 Author: blendix Date: 2010-02-07 02:11:02 +0100 (Sun, 07 Feb 2010) Log Message: --- Fix jumping panels when opening a new properties area or area containing a region with panels (e.g. file browser). Modified Paths: -- trunk/blender/source/blender/editors/interface/view2d.c Modified: trunk/blender/source/blender/editors/interface/view2d.c === --- trunk/blender/source/blender/editors/interface/view2d.c 2010-02-07 01:09:12 UTC (rev 26655) +++ trunk/blender/source/blender/editors/interface/view2d.c 2010-02-07 01:11:02 UTC (rev 26656) @@ -275,7 +275,9 @@ v2d-keeptot= V2D_KEEPTOT_BOUNDS; v2d-scroll |= (V2D_SCROLL_RIGHT|V2D_SCROLL_BOTTOM); - + v2d-scroll |= V2D_SCROLL_HORIZONTAL_HIDE; + v2d-scroll = ~V2D_SCROLL_VERTICAL_HIDE; + v2d-tot.xmin= 0.0f; v2d-tot.xmax= winx; ___ Bf-blender-cvs mailing list bf-blender-...@blender.org http://lists.blender.org/mailman/listinfo/bf-blender-cvs ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Bringing anti-aliasing back by fixing selection method
Unfortunately, even with glDisable(GL_MULTISAMPLE_ARB), there are still artifacts (at least n nvidia) that break the color coding method. And thus weird things happen, like orphan out of the selection area vertices being selected. Occlusion query is part of openGL standard from rev. 1.5. So it should work well with other cards, but I'm interested to get feedback from ati/intel cards owners... Damien Le 14 janv. 2010 à 06:19, joe a écrit : Though of course rewriting it more properly is good too. I've not looked into occlusion query since the original nvidia extension; how well does it work across disparate video cards? Joe On Wed, Jan 13, 2010 at 9:15 PM, joe joe...@gmail.com wrote: Explicitly disabling it in the selection draw functions seemed to work well enough before, via glDisable(GL_ARB_MULTISELECT). Joe On Wed, Jan 13, 2010 at 8:32 AM, Damien Plisson damien.plis...@yahoo.fr wrote: Hi all, FSAA was breaking border/lasso select operations (e.g. orphan vertices were selected). FYI, The root cause for this issue is that as soon as FSAA is enabled at pixelformat level, even if not enabled afterwards, some color artifacts may appear in draw operations. This breaks the color coding selection method that is currently used in Blender for various selection tools like border, lasso, circle... when occlude geometry is enabled. To fix it, the color coding selection method has to be replaced, and this is what this patch does by implementing the occlusion query method for the border/lasso/circle selection tools: http://projects.blender.org/tracker/index.php?func=detailaid=20660group_id=9atid=127 I'm looking forward for your feedback / comments / suggestions... Damien ___ 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] Bringing anti-aliasing back by fixing selection method
Hi all, FSAA was breaking border/lasso select operations (e.g. orphan vertices were selected). FYI, The root cause for this issue is that as soon as FSAA is enabled at pixelformat level, even if not enabled afterwards, some color artifacts may appear in draw operations. This breaks the color coding selection method that is currently used in Blender for various selection tools like border, lasso, circle... when occlude geometry is enabled. To fix it, the color coding selection method has to be replaced, and this is what this patch does by implementing the occlusion query method for the border/lasso/circle selection tools: http://projects.blender.org/tracker/index.php?func=detailaid=20660group_id=9atid=127 I'm looking forward for your feedback / comments / suggestions... Damien ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New Developer Meeting minutes
Committed in svn 25921.
CMake build worked on Mac before after the patch :)
Damien
Le 12 janv. 2010 à 03:48, lguillaume a écrit :
Just to say that I successfully made a 64 bits compilation of blender with
vc2010 beta 2010 and cmake 2.8.
Can anyone put the patch for correcting quicktime dir in cmake (anyone who
can test if it does not break on mac) :
Index: source/blender/makesrna/intern/CMakeLists.txt
===
--- source/blender/makesrna/intern/CMakeLists.txt(revision 25905)
+++ source/blender/makesrna/intern/CMakeLists.txt(working copy)
@@ -63,7 +63,7 @@
ENDIF(WITH_DDS)
IF(WITH_QUICKTIME)
-SET(INC ${INC} ../../quicktime)
+SET(INC ${INC} ../../quicktime)
ADD_DEFINITIONS(-DWITH_QUICKTIME)
ENDIF(WITH_QUICKTIME)
___
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] Trackpad multi-touch gestures (scroll/pinch/rotate) handling patch
Hi William, All two fingers API return float incremental values that can be quite precise. That's why you can zoom in tiny increments. Following Shaul feedback, I've decrease by a factor of 4 the zoom speed. The issue is with panning which has an idle threshold that may be too high, and that explains the jerkiness you observed. To try to lessen this effect, I've implemented (in the updated patch) a quadratic acceleration. Tell me what you think of it ! I don't get exactly suggestion for rotation, as orbital rotation is available through Alt+panning when in turntable mode. BTW, a funny thing is that thx to obj-C runtime binding, even if Blender is compiled for ppc 10.4 (systems way before multitouch trackpads), multitouch works fine on a recent mbp ! I've updated the patch, but if it seems ok, I'll commit it soon... Cheers, Damien Le 4 janv. 2010 à 16:56, William Reynish a écrit : Hi Damien, I've tested your patch today - works really nicely. I was even surprised to see how the zooming is butter smooth - either it's implemented in a different way, or it moves in very tiny, unnoticable increments. Regular panning and orbiting is more jerky though. I agree with others that the zooming is a bit too sensitive, and there seems to be a tiny amount of lag before the pinch gesture starts to react, after which it's perfectly smooth and responsive. The controls are quite nice, though you seldom want to rotate around the view plane. I'd prefer if it rotated around the y axis when using the rotate gesture. Either that or the two finger scrolling should default to orbiting, which is after all the most common movement you'll want to do in 3d. Yes, I think it should be kept as auto, detecting whether the user is using a mouse, or trackpad. Laptop users attach or detach mice frequently and it would be a hassle to manually set it up each time. Thanks a bunch for this work. I'll definitely propose that we include this. William On 3 Jan, 2010, at 6:59 PM, Damien Plisson wrote: Hi all, During the vacation time, I was stuck in an Internet-free place (an issue), but without a mouse (more serious issue), so to keep my Blender experience as good as possible, I needed to get these shiny trackpad multitouch features operational ! So, based on trackpad pan work initiated by James Deery [his mail of Nov 5th 2009], I've implemented the handling of the trackpad 2-fingers gestures : - 2 fingers scroll (MOUSEPAN / GHOST_kTrackpadEventScroll event) pans the view - 2 fingers pinch (MOUSEZOOM / GHOST_kTrackpadEventMagnify event) zooms the view And in 3D view: - alt + 2 fingers scroll rotates the view - 2 fingers rotation (MOUSEROTATE / GHOST_kTrackpadEventRotate) rotates the view around the axis orthogonal to the screen (the 3rd axis !) This is currently fully implemented for OSX (GHOST Cocoa fires the new events), but there must be some PC laptops with similar features that'll take advantage of this... PC users, can you confirm ? (I remember using a laptop with the 2D scroll features on its trackpad). FYI, OSX implementation compiles from 10.4, though the In Ghost, I've currently implemented an auto-detection of the source peripheral, so that a regular mouse still sends MOUSEWHEEL events. Apple special mice behave like trackpad (not configurable from documented API), so the mighty mouse trackball sends 2D scroll events. And the magic mouse touch gestures must be like trackpad's. Do you think it should be kept in auto mode (wheel events for regular mouse, scroll/zoom/rotate events for trackpad/special mouse), or be an option user configurable ? I've posted this as patch #20555 in the patch tracker : https://projects.blender.org/tracker/index.php?func=detailaid=20555group_id=9atid=127 for your reviews, comments suggestions. Damien ___ 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] Trackpad multi-touch gestures (scroll/pinch/rotate) handling patch
Hi, Le 4 janv. 2010 à 02:22, Shaul Kedem a écrit : Hi, I've patched and compiled on mac OSX 10.6, it works great! Can we have other axis to rotate the view when doing the circle gesture? it's really weird in default cam view because it is rotating against what seems to be the camera normal (?). but again, it's an excellent progress :) Currently, the rotation is against the screen normal. Which axis would you prefer ? This 3rd axis selection can depend upon the trackball/turntable choice in user prefs. But for this, I may need help from a math expert to make the right rotation matrix. another comment is that when pinching it zooms way too fast for me :) The sensitivity is currently hardcoded in the GHOST_SystemCocoa::handleMouseEvent function. You can try other values. I don't think it'll call for a sensitivity setting in user prefs, as an acceptable for all value should be found. Thanks for the new years gift :-) Shaul p.s. do you have commit rights? Yes, but as this impacts files beyond cocoa, I want to have some feedback (including from other OSes users) before committing it. On Sun, Jan 3, 2010 at 12:59 PM, Damien Plisson damien.plis...@yahoo.fr wrote: Hi all, During the vacation time, I was stuck in an Internet-free place (an issue), but without a mouse (more serious issue), so to keep my Blender experience as good as possible, I needed to get these shiny trackpad multitouch features operational ! So, based on trackpad pan work initiated by James Deery [his mail of Nov 5th 2009], I've implemented the handling of the trackpad 2-fingers gestures : - 2 fingers scroll (MOUSEPAN / GHOST_kTrackpadEventScroll event) pans the view - 2 fingers pinch (MOUSEZOOM / GHOST_kTrackpadEventMagnify event) zooms the view And in 3D view: - alt + 2 fingers scroll rotates the view - 2 fingers rotation (MOUSEROTATE / GHOST_kTrackpadEventRotate) rotates the view around the axis orthogonal to the screen (the 3rd axis !) This is currently fully implemented for OSX (GHOST Cocoa fires the new events), but there must be some PC laptops with similar features that'll take advantage of this... PC users, can you confirm ? (I remember using a laptop with the 2D scroll features on its trackpad). FYI, OSX implementation compiles from 10.4, though the In Ghost, I've currently implemented an auto-detection of the source peripheral, so that a regular mouse still sends MOUSEWHEEL events. Apple special mice behave like trackpad (not configurable from documented API), so the mighty mouse trackball sends 2D scroll events. And the magic mouse touch gestures must be like trackpad's. Do you think it should be kept in auto mode (wheel events for regular mouse, scroll/zoom/rotate events for trackpad/special mouse), or be an option user configurable ? I've posted this as patch #20555 in the patch tracker : https://projects.blender.org/tracker/index.php?func=detailaid=20555group_id=9atid=127 for your reviews, comments suggestions. Damien ___ 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] Trackpad multi-touch gestures (scroll/pinch/rotate) handling patch
Hi all, During the vacation time, I was stuck in an Internet-free place (an issue), but without a mouse (more serious issue), so to keep my Blender experience as good as possible, I needed to get these shiny trackpad multitouch features operational ! So, based on trackpad pan work initiated by James Deery [his mail of Nov 5th 2009], I've implemented the handling of the trackpad 2-fingers gestures : - 2 fingers scroll (MOUSEPAN / GHOST_kTrackpadEventScroll event) pans the view - 2 fingers pinch (MOUSEZOOM / GHOST_kTrackpadEventMagnify event) zooms the view And in 3D view: - alt + 2 fingers scroll rotates the view - 2 fingers rotation (MOUSEROTATE / GHOST_kTrackpadEventRotate) rotates the view around the axis orthogonal to the screen (the 3rd axis !) This is currently fully implemented for OSX (GHOST Cocoa fires the new events), but there must be some PC laptops with similar features that'll take advantage of this... PC users, can you confirm ? (I remember using a laptop with the 2D scroll features on its trackpad). FYI, OSX implementation compiles from 10.4, though the In Ghost, I've currently implemented an auto-detection of the source peripheral, so that a regular mouse still sends MOUSEWHEEL events. Apple special mice behave like trackpad (not configurable from documented API), so the mighty mouse trackball sends 2D scroll events. And the magic mouse touch gestures must be like trackpad's. Do you think it should be kept in auto mode (wheel events for regular mouse, scroll/zoom/rotate events for trackpad/special mouse), or be an option user configurable ? I've posted this as patch #20555 in the patch tracker : https://projects.blender.org/tracker/index.php?func=detailaid=20555group_id=9atid=127 for your reviews, comments suggestions. Damien ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Patch [20303] to implement updated config files names paths
Hi, I've added a patch (# 20303) to the tracker https://projects.blender.org/tracker/index.php?func=detailaid=20303group_id=9atid=127 to implement the updated config files names paths as stated in the Resource file paths proposal : http://wiki.blender.org/index.php/BlenderDev/Blender2.5/ResourceFilePaths It makes the config files reside in the OS standard path (given by the function BLI_getconfig_folder()): OSX: ~/Library/Application Support/Blender Linux: ~/.blender Windows: ...\Application Data\Blender Foundation\Blender The config files are renamed as stated in the proposal to more readable names: .B25.blend, .Bfs, .Blog = startup.blend, bookmarks, file-history The .thumbnails cache that was stored in the home dir is also stored in this standard folder, with the thumbnails name. It should work on all platforms, but I've been able to test it only on OSX. So review from coders using linux windows is welcome! Cheers, Damien ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
