Re: [Bf-committers] Blender RC1 build!
I use the libraries from the blender svn trunk, prior to us removing them sometime around 2.52. I was never able to successfully build static ffmpeg libraries from elsewhere. Ken On 03/30/2011 07:38 AM, Juan Pablo Bouza wrote: Ken, is there anything special that you do with ffmpeg when compiling for linux? Cause me and some friends here have troubles with ffmpeg display in our own compilations, everything looks pixalated. Your compilations don't have this issue... If you do anything strange regarding this, Sergey should know :) and I want to know too :p From: t...@blender.org To: bf-committers@blender.org Date: Wed, 30 Mar 2011 15:53:48 +0200 Subject: [Bf-committers] Blender RC1 build! Hi platform team, Let's do another official test build! This one should have fixed openAL for linux, and for Windows the installer too. - Try to stick to r35899 - Put in the regular locations, I'll find/copy them and can align names too. - Names used will be like blender-2.57-RC1-r35899-platform.etc Platform builders: - Sergey Sharybin offered to do Linux builds, Ken has little time... and openAL and Collada are giving issues. - Damien: can you do OSX again? - Nathan L: Windows zip and exe - Pete Larabell: got a FreeBSD test for us? 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer IRC minutes, 27 March 2011
On 03/27/2011 08:55 AM, Ton Roosendaal wrote: Hi all, 1) 2.5x project, 2.57 release - Linux RC0 64 bits has bad openAL (crashes on ALT+A). Might need an updated chroot? Campbell and Sergey offered help to check. I get the crash also, however the chroot has the latest version of OpenAL available with debian lenny. - Linux script to run software Opengl is currently broken. Campbell or one of the release builds could check. I am able to run blender-softwaregl without problems. Is that the broken script? Ken ___ 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 [35727] trunk/blender/source/blender/ collada: COLLADA: supporting barebone class for extra support (incomplete ).
I know the commit says this is incomplete, but it breaks compiling on Linux for me: In file included from /home/blender/opencollada/COLLADASaxFrameworkLoader/include/COLLADASaxFWLIExtraDataCallbackHandler.h:15, from source/blender/collada/ExtraHandler.h:34, from source/blender/collada/ExtraHandler.cpp:31 /home/blender/opencollada/COLLADASaxFrameworkLoader/include/COLLADASaxFWLXmlTypes.h:17:32: error: GeneratedSaxParser.h: No such file or directory I have GeneratedSaxParser.h on the system, but not in the search paths being supplied for the compilation. I'm using opencollada r827 (the last one I saw commits related to). Campbell says he thinks we're supposed to be using r836, the latest svn. I'll try building against that (opencollada is a pain to build), but is there some official version number we're supposed to use? Who decides that, and how is that information disseminated? Ken On 03/23/2011 07:25 AM, Nathan Letwory wrote: Revision: 35727 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=35727 Author: jesterking Date: 2011-03-23 14:25:35 + (Wed, 23 Mar 2011) Log Message: --- COLLADA: supporting barebone class forextra support (incomplete). Modified Paths: -- trunk/blender/source/blender/collada/CMakeLists.txt trunk/blender/source/blender/collada/DocumentImporter.cpp trunk/blender/source/blender/collada/SConscript Added Paths: --- trunk/blender/source/blender/collada/ExtraHandler.cpp trunk/blender/source/blender/collada/ExtraHandler.h ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Release 2.56a AHOY
Linux tarballs uploading to download.blender.org/incoming -- Ken On 01/04/2011 09:54 AM, Ton Roosendaal wrote: 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! ** Collada crash on linux32 **
Crap: 32-bit was not build with r788 but r733. I'm rebuilding and will upload a new copy to download.blender.org/incoming in about 30 minutes. Ken On 01/03/2011 08:12 AM, Jeroen Bakker wrote: Ken, There is an issue with the 32 bit version of 2.56. I was wondering if you could help me with it. The bug is http://projects.blender.org/tracker/?func=detailaid=25463group_id=9atid=498 I have succesfully reproduced it on linux32, but am not able to reproduce it on linux64 or windows32. To reproduce the issue you need to start blender with the default blend file and use export COLLADA from the space menu. When confirm selecting a file blender crashes with a segfault. perhaps you could make build with debug symbols just for a better stack trace. Just to be sure could you check what revision of collada the libraries are linked with? It should be revision 788. Greetings, Jeroen Bakker On 12/30/2010 01:42 AM, Ken Hughes wrote: Linux 32-bit and 64-bit tarballs uploaded to download.blender.org/incoming. 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
Re: [Bf-committers] 2.56-beta release AHOY! ** Collada crash on linux32 **
I know; this was just in case we wanted a correct 2.56 build for linux 32-bit. Ken On 01/03/2011 09:35 AM, Ton Roosendaal wrote: Hi, Reminder: Pending final pointcache tests, we'll call tomorrow for a 2.56a too. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 3 Jan, 2011, at 18:24, Ken Hughes wrote: Crap: 32-bit was not build with r788 but r733. I'm rebuilding and will upload a new copy to download.blender.org/incoming in about 30 minutes. Ken On 01/03/2011 08:12 AM, Jeroen Bakker wrote: Ken, There is an issue with the 32 bit version of 2.56. I was wondering if you could help me with it. The bug is http://projects.blender.org/tracker/?func=detailaid=25463group_id=9atid=498 I have succesfully reproduced it on linux32, but am not able to reproduce it on linux64 or windows32. To reproduce the issue you need to start blender with the default blend file and use export COLLADA from the space menu. When confirm selecting a file blender crashes with a segfault. perhaps you could make build with debug symbols just for a better stack trace. Just to be sure could you check what revision of collada the libraries are linked with? It should be revision 788. Greetings, Jeroen Bakker On 12/30/2010 01:42 AM, Ken Hughes wrote: Linux 32-bit and 64-bit tarballs uploaded to download.blender.org/incoming. 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] 2.56-beta release AHOY!
Linux tarballs on download.blender.org. Ken On 12/30/2010 12:50 AM, Nathan Letwory wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30.12.2010 9:48, Nathan Letwory wrote: On 29.12.2010 21:10, Ton Roosendaal wrote: SVN needs to be tagged still; but last commit from me was 33942. Tag will be announced here too. Appologies for the slow tagging speed, but builders can now use: svn co -r 33947 https://svn.blender.org/svnroot/bf-blender/tags/blender-2.56-release Hi builders, Please update your tag checkout to revision r33949. I needed to update some links we have hardcoded in our readme.html, splash and help menu. I appologize for the inconvenience. /Nathan ps. I'll restart my builds right now too :) - -- 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/ iQEcBAEBAgAGBQJNHEe7AAoJEKtfN7KsE0TtXWcH/jE5atBuiDEiAPb+cccQ/ytq TXiFcShrIvdpjlP7juAGaMnhLxJI3/7a4AojSYmV06fIuHXhz5uA63z5XjQ9n5xy U1wxgj/ekMtPp8dJEW3YKn4rg+Gr45T9SdPx0JFwgZ/OdAMJ/CFwCgU9y10N9/AX XhBu3TmqfkS3SOzLEmTXpW7o2qm9bKuFy6r6aV8L12w0dXAw9nzlZGEum5Y+B0Fh nYDoV66kx/iRS4OOwZ4xacK740d2vWXtU/vjRcZ8swTnXv3HV3InMfM4D9c8Pw2d tibZcgLGHzEYB3dfhVDoBNFoT70u2MXs+XTJ4+R2EjJLKuAeVf9oJSXFH8UJfJ8= =psYK -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!
Sorry for the delays (hell week here at work). Think I have the blenderplayer builds for Linux sorted out, just need to get them packaged. Will upload later today or sometime tomorrow. Ken ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.55 beta AHOY!
Yeah, I found the correspond lines and patched by hand. Ken On 10/27/2010 11:20 AM, Nathan Letwory wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27.10.2010 19:46, Ken Hughes wrote: Just downloaded the 3.1.2 source tarball and the patch doesn't apply. Should I be building 3.1.2 from svn or something? The only part of the patch needed is the one for Lib/xmlrpc/client.py. This could be done manually, but you have to do this only if you bundle python libs. No building for this should be required - assuming that Python 3.1.2 on target machine has SSL-support enabled. But I wouldn't worry too much about that. It'd be nice to have this patch bundled, but not a showstopper (only very few parts use XMLRPC over HTTPS anyway). /Nathan Ken On 10/27/2010 05:00 AM, Nathan Letwory wrote: 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. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers - -- 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/ iQEcBAEBAgAGBQJMyG2CAAoJEKtfN7KsE0TtEs8H/Rbz7IxlFgdSdjZVAdz00jCS FoAy9HmbBmhaVuZpNtwXi5OPwOsbAAMmFB0j6rkBuoFXquSFHeRkM93rpSZTNfE3 QOxehRdifDpk/rl6psKunT4kJ9L72aH6t58hsnt8cjAa0Odkus7XDFXtxLimJhmM 4H0Tj0hHzOV0GjzKCrx7TZdzfXWHGgBohvR5O6K4yxvFYfvolYX4FbyU8YFNJ+w/ 5tdvWaf14Dz0KgNkTG77xJohh8znVmg8nk83Cncb6hHk2s27n4bsl9ILzbO/NOMu g0jnJSVXeW+ShsLKRTiMImmJ9KknHia9HHxwjYMwixROq9Lxq41uswwdUv8s0iQ= =bfNG -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!
Which is a shame, since I use scons for the official builds. And you're right, it's breaks in source/blender/makesrna/intern/rna_scene.c looking for ffmpeg include files. Ken On 10/27/2010 11:19 AM, blendenzo wrote: On 10/27/2010 12:34 PM, Mitchell Stokes wrote: I have a request for the builders: Could you please build the Blenderplayer too? It would be good to get the player in a few betas so that it's working by the time we get to a stable release. Thank you, Mitchell Stokes (Moguri) +1 to this. A note for Linux builders: From my experience, the blenderplayer is not building properly on Linux with Scons. It builds fine with CMake, though. ___ 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] Typo breaks build in Mac OSX
Thanks -- update from svn and try it now. Ken On 09/26/2010 04:50 PM, Mr. Jack Inc wrote: Hi all. I was building with SVN code revision 32134 and the build broke due to a typo on wm_window.c wm_window.c: In function ‘wm_window_add_ghostwindow’: wm_window.c:310: error: ‘inital_state’ undeclared (first use in this function) wm_window.c:310: error: (Each undeclared identifier is reported only once wm_window.c:310: error: for each function it appears in.) make[4]: *** [/Users/mrjackinc/Proyectos/Blender/blender/obj/darwin-10.3.0-i386/blender/windowmanager/wm_window.o] Error 1 make[3]: *** [all] Error 1 make[2]: *** [all] Error 1 make[1]: *** [all] Error 1 make: *** [all] Error 1 It's a 1 letter typo (inital_state vs initial_state) and that solves it. A bug seemed as too much for this. Thanks ___ 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!
Can someone remove the linux tarballs from the ftp incoming directory. Uploaded before I tested them... shoot. On 09/10/2010 09:41 AM, 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. 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 IRC meeting minutes, sept 5 2010
On 09/05/2010 08:22 AM, Ton Roosendaal wrote: 2) Blender 2.5, todos, next test build release - Linux release: there are issues linking with libgz and libtiff now (fedora/opensuse). Ken Hughes looks into it, and reports here if there's issues to review. It might become static linked. No issues building with libtiff.a, but Debian's shared PNG and freetype libraries depends on libz.so, so until I can rebuild those libs by hand without the dependencies I have to also link them statically. Good news is the binary is so bloated you hardly notice the 1% increase in size. Ken ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Release AHOY, rev 30579 - lazy bum warning
Linux 32-bit and 64-bit uploaded to download.blender.org/incoming. Ken ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Installation/file paths
Before I comment, let me be sure I understand what's being proposed: On Unix, the blender executable would most likely be /usr/bin/blender. So the proposal is to have a /usr/bin/datafiles folder for the system data files? If so, I don't think that's a good idea, for Unix anyway. You don't expect to find any data in /usr/bin. Ken On 05/11/2010 02:37 AM, Brecht Van Lommel wrote: Hi, On Tue, May 11, 2010 at 10:40 AM, Rob Mrob.nos...@4mation.co.uk wrote: I agree with most of this but why can't the default location for the system data files be in the datafiles sub directory of the directory where the blender executable resides? Proposal looks fine to me, but I agree with this. We can avoid a wrapper script, making it use the folder in the same directory doesn't conflict, so it could just look for a datafiles in the same folder first. 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] Installation/file paths
Using gcc as an example (since it's possible to have multiple versions installed): On Ubuntu at least, they are called /usr/bin/gcc-4.1, /usr/bin/gcc-4.2, etc., with a symbolic link /usr/bin/gcc to one of the versions. I assume other Unix variants do something similar? Ken On 05/11/2010 08:10 AM, Roger Wickes wrote: i would hope the blender executable is in usr/bin/blender/2.52 so that we can have multiple versions of blender installed (2.49, 2.52, svn) --Roger Check out my website at www.rogerwickes.com for a good deal on my book and training course, as well as information about my latest activities. Use coupon Papasmurf for $15 off! From: Ken Hugheskhug...@pacific.edu To: bf-blender developersbf-committers@blender.org Sent: Tue, May 11, 2010 11:07:02 AM Subject: Re: [Bf-committers] Installation/file paths Before I comment, let me be sure I understand what's being proposed: On Unix, the blender executable would most likely be /usr/bin/blender. So the proposal is to have a /usr/bin/datafiles folder for the system data files? If so, I don't think that's a good idea, for Unix anyway. You don't expect to find any data in /usr/bin. Ken On 05/11/2010 02:37 AM, Brecht Van Lommel wrote: Hi, On Tue, May 11, 2010 at 10:40 AM, Rob Mrob.nos...@4mation.co.uk wrote: I agree with most of this but why can't the default location for the system data files be in the datafiles sub directory of the directory where the blender executable resides? Proposal looks fine to me, but I agree with this. We can avoid a wrapper script, making it use the folder in the same directory doesn't conflict, so it could just look for a datafiles in the same folder first. 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 ___ 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] Installation/file paths
Ok, thanks for the clarification. Ken On 05/11/2010 09:08 AM, Brecht Van Lommel wrote: Hi, I'm proposing to look for the folder in the same directory as the executable first, and if that doesn't exist, in the system location (/usr/share/blender). This means that /usr/bin/datafiles would be used if it was there, but that's an unintentional side effect and the folder should be installed in /usr/share/blender when blender is installed in /usr/bin/blender. This just also covers the case of running blender from an unpacked archive, without using a wrapper script to find the right folder. Brecht. On Tue, May 11, 2010 at 5:07 PM, Ken Hugheskhug...@pacific.edu wrote: Before I comment, let me be sure I understand what's being proposed: On Unix, the blender executable would most likely be /usr/bin/blender. So the proposal is to have a /usr/bin/datafiles folder for the system data files? If so, I don't think that's a good idea, for Unix anyway. You don't expect to find any data in /usr/bin. Ken On 05/11/2010 02:37 AM, Brecht Van Lommel wrote: Hi, On Tue, May 11, 2010 at 10:40 AM, Rob Mrob.nos...@4mation.co.ukwrote: I agree with most of this but why can't the default location for the system data files be in the datafiles sub directory of the directory where the blender executable resides? Proposal looks fine to me, but I agree with this. We can avoid a wrapper script, making it use the folder in the same directory doesn't conflict, so it could just look for a datafiles in the same folder first. 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 ___ 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] Security gets in the way
Apathy can also result in people giving up trying to convince others of the wrong solutions. It's a double-edge sword. Benjamin Tolputt wrote: Martin Poirier wrote: There's still very little doubt that this will be the solution that is going to be adopted (in the short to mid term at least). That doesn't mean I shouldn't disagree with it ;) Apathy results in poor solutions because people give up trying to convince people of the right ones. ___ 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] Security gets in the way
Of course the this is impossible with python can be wrong in the long term; who know what direction python will evolve in the next 2-3 years. But trying to find a python solution right now, with what we have, is impossible. I have to agree with what someone posted earlier: if someone is convinced this (a secure solution) can be done with the existing Python 3.1, they need to code up a proof-of-concept to shut up everyone who says it can't be done. Otherwise everyone is just filling up a useful mailing list with spam. horace grant wrote: http://www.philhassey.com/blog/tinypy-ideas/ Embed tinypy * Objective: sandbox tinypy and then (as in lunatic python) build a python module that uses tinypy for safe execution of “unknown” code it's just an idea at the moment and not implemented but this sounds interesting. :) tinypy could be used for drivers in the long term. in the short to mid term there doesn't seem to be an easy and secure solution but in the long term all the this is impossible with python seems to be wrong to me. to me it looks like in 2-3 years the whole situation will look different (pypy, tinypy,...) and there will be feasible solutions. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Security gets in the way
I didn't mean that to come across as a personal attack, Benjamin. I'm just pointing out that just because someone has an idea, that doesn't mean it's the right idea. Ken Hughes wrote: Apathy can also result in people giving up trying to convince others of the wrong solutions. It's a double-edge sword. Benjamin Tolputt wrote: Martin Poirier wrote: There's still very little doubt that this will be the solution that is going to be adopted (in the short to mid term at least). That doesn't mean I shouldn't disagree with it ;) Apathy results in poor solutions because people give up trying to convince people of the right ones. ___ 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] carve boolean blender
I've talked with Joseph and made some clean-up commits. I'll be unavailable this weekend but hope to do more starting next week. Ken Tom M wrote: Ken if you could help bmesh to proceed that would be excellent, although fixing bugs in the main branch would be nice too :) LetterRip On Wed, Mar 10, 2010 at 4:33 AM, Ken Hughes khug...@pacific.edu wrote: I've started looking at the bmesh branch and seeing what it takes to add carve to it. Good news is the same old code is still there so it can just plug in; bad news is the old boolean modifier doesn't work anyway. So my plain is to look at getting boolean working again, unless someone else is doing it. ___ 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] carve boolean blender
I've started looking at the bmesh branch and seeing what it takes to add carve to it. Good news is the same old code is still there so it can just plug in; bad news is the old boolean modifier doesn't work anyway. So my plain is to look at getting boolean working again, unless someone else is doing it. BTW, I assume the bmesh branch right now is a work-in-progress. It took a bit of work to get it to compile under linux; some complaints about wrong procedure prototypes due to missing includes, some flat-out complaints about missing bmesh.h (the include path not added to SConstruct files), and some wrong prototypes or other typos. If that's not the case, I can let someone (Joseph?) know what I had to do to fix it; otherwise I can also help out with some commits to that branch to help move the integration/merge. I have free time now :-) Ken Jaevixa McNomera wrote: Hey, Sorry I didn't update you on this :( I asked around and felt the general thought was that the mesh reducer I'm working on was wanted first by more people, so I decided to finish that before tackling CarveCSG. Progress on the mesh reducer was stalled for at least a few weeks due to an injury. I broke my poor little hands :( :( :( I'm starting to pick back up on the mesh reducer, which at this point is almost completed. If you want and/or have time to do the Carve work, I didn't even touch it yet, so no work lost if you pick it back up. Ken, to clarify it for you, I'm a girl :) On Sun, Mar 7, 2010 at 7:19 AM, Tom M letter...@gmail.com wrote: ken, whatever happened with the carve boolean work you did? LetterRip _ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] carve boolean blender
Jaevixa McNomera contacted me in January about picking this up and continuing the development. At that time I was working on another project and gave him/her my blessing (plus my patches), but haven't heard anything since. I could pick this back up now (my project is done), but should coordinate with Joe since it should be integrated with BMesh. I haven't looked at his branch in a while, but my modifications basically plugged in on top of the current boolean interface, so it might be possible to integrate for now without any major modifications. The one obvious advantage of BMesh would be using ngons. However, from what I've seen discussed, I believe one problem we will have to deal with is that BMesh may not support meshes with holes. Ken Tom M wrote: ken, whatever happened with the carve boolean work you did? LetterRip ___ 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] Tesbuild ahoy: alpha2
Linux 32-bit and 64-bit builds uploading to ftp site. Includes ffmpeg and opencollada also. Ken Damien Plisson wrote: 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.5 alpha 1 test build AHOY
32-bit and 64-bit linux builds on download.blender.org Ton Roosendaal wrote: Hi all, I've done a splash commit and upped the release number to 251.0. Release builders can do checkouts now and build. Revision is 26970. If all's OK, Martin will tag this too. Builds you can provide me as usual, or put online in ftp/incoming/ Blender2.51/ I will then make it all available (also via mirrors) tomorrow. 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
[Bf-committers] OpenCollada issues (was Re: Meeting minutes, feb 14, 2010)
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
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [26894] trunk/blender/config/linux2-config .py: == FFMPEG ==
Well, this has broken building on a number of linux distros for which an
older ffmpeg is the standard (unfortunately, one of them is debian
lenny, which is what we've used for the chroot releases). And as near
as I can tell so far (never having delved into building ffmpeg myself),
it's not just downloading and building ffmpeg from svn, because it
relies on a host of other libraries (x264, swscale, etc). Each which
also have to be downloaded and built first.
Ken
Martin Poirier wrote:
I would assume static for release, yes.
Removal was discussed in last week's meeting.
Martin
--- On Sun, 2/14/10, Ken Hughes khug...@pacific.edu wrote:
From: Ken Hughes khug...@pacific.edu
Subject: Re: [Bf-committers] [Bf-blender-cvs] SVN commit:
/data/svn/bf-blender [26894] trunk/blender/config/linux2-config .py: ==
FFMPEG ==
To: bf-committers@blender.org
Received: Sunday, February 14, 2010, 2:12 PM
Did I miss something? We're
relying on the system's ffmpeg now? For
release we are still planning to use the static libs on
linux I assume?
Ken
Peter Schlaile wrote:
Revision: 26894
http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=revroot=bf-blenderrevision=26894
Author: schlaile
Date: 2010-02-14 19:52:27
+0100 (Sun, 14 Feb 2010)
Log Message:
---
== FFMPEG ==
Made using system's ffmpeg the default now. (First
step in removing
ffmpeg from extern)
Modified Paths:
--
trunk/blender/config/linux2-config.py
Modified: trunk/blender/config/linux2-config.py
===
---
trunk/blender/config/linux2-config.py
2010-02-14 18:05:58 UTC (rev 26893)
+++
trunk/blender/config/linux2-config.py
2010-02-14 18:52:27 UTC (rev 26894)
@@ -110,11 +110,11 @@
# enable ffmpeg support
WITH_BF_FFMPEG = True # -DWITH_FFMPEG
-BF_FFMPEG = '#extern/ffmpeg'
-BF_FFMPEG_LIB = ''
+# BF_FFMPEG = '#extern/ffmpeg'
+# BF_FFMPEG_LIB = ''
# Uncomment the following two lines to use
system's ffmpeg
-# BF_FFMPEG = '/usr'
-# BF_FFMPEG_LIB = 'avformat avcodec swscale avutil
avdevice'
+BF_FFMPEG = '/usr'
+BF_FFMPEG_LIB = 'avformat avcodec swscale avutil
avdevice'
BF_FFMPEG_INC = '${BF_FFMPEG}'
BF_FFMPEG_LIBPATH='${BF_FFMPEG}/lib'
___
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
__
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your
favourite sites. Download it now
http://ca.toolbar.yahoo.com.
___
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
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 Ton Roosendaal wrote: 2) Blender 2.5 - 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: ... ___ 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 [26310] trunk/blender: Drag and drop 2. 5 integration! Finally, slashdot regulars can use
I read this and laughed so hard coffee came out my nose :-) Ken Ton Roosendaal wrote: Log Message: --- Drag and drop 2.5 integration! Finally, slashdot regulars can use Blender too now! :) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New Developer Meeting minutes
Since this thread is now about build systems, can we please change the subject line? Ken Campbell Barton wrote: Not sure what dependency updates are exactly - if files are added you need to run cmake . in the build dir but aside from that I never had any dep propblems. I'm tempted to install Windows just to get rid of the MSVC Project files and have CMake create propper debug builds... it cant be that hard can it? @Martin, my experience with using scons and eclipse isnt so good, it works OK but a bit annoying to setup, I recall I needed to have eclipse call a shell script that called scons. Eclipse + Cmake is nicer, and takes the work out of setting up the project each time. especially if you want to switch to developing in branches for a bit. On Thu, Jan 7, 2010 at 3:52 PM, Martin Poirier the...@yahoo.com wrote: --- On Thu, 1/7/10, Erwin Coumans erwin.coum...@gmail.com wrote: New developers (and myself) can browse and debug code much easier in an IDE such as msvc, Xcode or K develop, in my opinion. And manual updating projectfiles is a waste of time. It's very easy to use Eclipse (with CDT) with scons. K Develop was pretty easy to setup too the last time I tried. There was no project files to update or anything. Martin __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. ___ 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] new 2.5 alpha 0 tarballs for linux
Since no one responded to my last post, I've uploaded the new 32-bit and 64-bit linux tarballs to ftp.blender.org/incoming, if someone wants to move to the download servers. Ken ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] new 2.5 alpha 0 tarballs for linux
Right; these replace the original tarballs. The only differences are how they were built. Ken Diego B wrote: overwrite the old files ? sorry I want to move but the 2.50alpha already have this two files, so I assume this is and update ? right ? overwrite it ? On Sun, Dec 6, 2009 at 1:10 PM, Ken Hughes khug...@pacific.edu wrote: Since no one responded to my last post, I've uploaded the new 32-bit and 64-bit linux tarballs to ftp.blender.org/incoming, if someone wants to move to the download servers. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Problems with linux 2.5-alpha0 tarballs
Two bugs were reported with the 2.5-alpha0 release, one involving Python relying on a shared library version which is different on a number of releases, and a second related to a problem with libz not being linked statically and so causing run-time problems on some distros (neither problem cropped up in my tests, since the chroot is debian-based and I'm using ubuntu). Both problems from building the tarball packages, not from bugs in the blender source tree. Should I just upload new tarballs and have someone put those out on the download servers, or should this wait? Ken ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] build issues with Debian etch
I decided I'd better try building 2.50 in my chroot environment and ran into some issue with compatibility. In file included from source/blender/blenkernel/intern/colortools.c:56: source/blender/blenlib/BLI_threads.h:81: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ThreadRWMutex’ source/blender/blenlib/BLI_threads.h:83: error: expected ‘)’ before ‘*’ token source/blender/blenlib/BLI_threads.h:84: error: expected ‘)’ before ‘*’ token source/blender/blenlib/BLI_threads.h:85: error: expected ‘)’ before ‘*’ token source/blender/blenlib/BLI_threads.h:86: error: expected ‘)’ before ‘*’ token pthread_rwlock_t is not being defined from /usr/include/bits/pthreadtypes.h for some reason using gcc 4.2. Now I can dig into this, but it occurs to me this might just be because etch is fairly old. I could create a newer chroot based on lenny, but it's based on a much newer version of glibc. Any suggestions? Ken ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
