[Bf-committers] vrbuilder - valuable critique on Blender as a tool for architectural visualization
Hi, just found it and would like to share with you: this is a recently started blog with in-depth critique on Blender as a tool for architectural visualization: http://vrbuilder.wordpress.com The most valuable thing is that he speaks about it in wide context. I think the ideas listed there are worth to be discussed. best regards, migius ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] VS 2013 + Blender = ???
Hi there, Out of curiosity I downloaded the VS 2013 Pro preview yesterday. And while playing with it I had the idea to try blender compilation with it ;) I needed to tweak the sources a bit because MSVC 12 seems to break se things as M$ implements more C++11 features. It took me 30 Minutes to put a patch together. But all the libs I compiled with VC11 need to be recompiled :( So I stopped this insanity ... But what I am curious about, what do you guys think? Shall we adapt new versions if MSVC early (even if we don't use it for production) or not? Pro: when we decide to switch to another version (let's assume MSVC 2016, just for an example) the workload of porting might be huge. Con: we have to recompile libs and port blender every year (in case MS keeps this release schedule) /Jürgen ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] VS 2013 + Blender = ???
Logic error corrected inline ;) Hi there, Out of curiosity I downloaded the VS 2013 Pro preview yesterday. And while playing with it I had the idea to try blender compilation with it ;) I needed to tweak the sources a bit because MSVC 12 seems to break se things as M$ implements more C++11 features. It took me 30 Minutes to put a patch together. But all the libs I compiled with VC11 need to be recompiled :( So I stopped this insanity ... But what I am curious about, what do you guys think? Shall we adapt new versions if MSVC early (even if we don't use it for production) or not? Pro: when we decide to switch to another version (let's assume MSVC 2016, just for an example) the workload of porting might Not be that huge. Con: we have to recompile libs and port blender every year (in case MS keeps this release schedule) /Jürgen ___ 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] VS 2013 + Blender = ???
From USER: As always speed tests must be performed for such a decision. Are there any new VS features that are worth mention? And as always i will promote mingw-w64 :] just read that you can compile windows build under linux - nice /kopias On Fri, 28 Jun 2013 20:08:30 +0200, Jürgen Herrmann shadow...@me.com wrote: Logic error corrected inline ;) Hi there, Out of curiosity I downloaded the VS 2013 Pro preview yesterday. And while playing with it I had the idea to try blender compilation with it ;) I needed to tweak the sources a bit because MSVC 12 seems to break se things as M$ implements more C++11 features. It took me 30 Minutes to put a patch together. But all the libs I compiled with VC11 need to be recompiled :( So I stopped this insanity ... But what I am curious about, what do you guys think? Shall we adapt new versions if MSVC early (even if we don't use it for production) or not? Pro: when we decide to switch to another version (let's assume MSVC 2016, just for an example) the workload of porting might Not be that huge. Con: we have to recompile libs and port blender every year (in case MS keeps this release schedule) /Jürgen ___ 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 -- Using Opera's mail client: http://www.opera.com/mail/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] vrbuilder - valuable critique on Blender as a tool for architectural visualization
On Fri, Jun 28, 2013 at 1:08 AM, Remigiusz Fiedler mig...@gmx.net wrote: this is a recently started blog with in-depth critique on Blender as a tool for architectural visualization: I suspect you are referencing this specific post... http://vrbuilder.wordpress.com/2013/06/26/1-month-self-exam-what-did-i-learn-until-now-ii/ I think some of his new user onboarding points are interesting opportunities for improvements, though I'm not so on board with his improvement ideas. I think most of this may be better discussed somewhere else, though I'm really surprised by one thing that seems relevant here... Rendering Speed and GPU rendering speed... In particular, his assumption that GPU rendering (particularly laptop GPU) would so obviously give him faster rendering speed. I see users expect this alot, and I'm surprised by it. For a simple test, GPU rendering on my Macbook Pro Retina (which is a pretty beefy GPU for a laptop), is more than 2x slower than CPU rendering. Are there really laptop combos where GPU rendering is notably faster? Even my desktop GTX670 is only about 1.8x faster than my 2.9ghz quad i7. I know the 6xx have worse double-precision CUDA than the 5xx cores. From what I've read, the real CUDA performance doesn't come until the expensive workstation class Quadro cards. Are there economical GPU choices out there which really blow away CPU rendering? Or is this just marketing driving user interest? Seems possibly worth making a blender wiki page with a combined GPU --AND-- CPU Cycles rendering benchmark table. Does something like that exist? This is all I could find, and it's comparing only GPU-to-GPU performance. http://benchmark.cd3dtech.com/Benchmark/benchmark.html Of course this changes once you get into Quadro cards, but those are expensive In the infamous words of a random blenderartist user... so your gpu has a roughly 10x speed increase over my cpu, which isn't bad at all, although it's also about 10x the price ___ 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 [57857] trunk/blender/intern/ghost/intern/ GHOST_WindowWin32.cpp: Fix #35904: on Windows force NVidia Optimus, which does automati
It's still possible to override the choice in the NVidia graphics settings, this will only change the default, see the linked pdf for details. On Fri, Jun 28, 2013 at 8:50 PM, Antony Riakiotakis kal...@gmail.com wrote: Maybe this will disallow using the dedicated card for rendering only while using the integrated for display. I haven't actually tried this though. ___ 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] Blender roadmap article on code blog
On Fri, Jun 28, 2013 at 7:13 AM, Jed Frechette jedfreche...@gmail.com wrote: On Thu, 27 Jun 2013 12:33 Campbell Barton ideasma...@gmail.com wrote On Thu, Jun 27, 2013 at 10:58 AM, Jed jedfreche...@gmail.com wrote: I agree about the existing Python code being hard to read. Am happy to take criticism for python code, but curious which parts you found problematic to follow. One particularly crufty bit I was looking at recently is the Smart UV Project module (http://preview.tinyurl.com/ldujq8r). None of the functions have doc strings, large portions of the code are commented out and presumably obsolete, unusual naming conventions, etc. The Lightmap UV unwrapping module is much better but also doesn't have any doc strings. Both these scripts suffer from 2.4x - 2.5x-rna - 2.6x-rna-ngons. 2.5x+ api's for mesh manipulations use RNA and are very limited, 2.4x was more flexible and had more useful functionality built-in. However it was always my intention with 2.5x to use bmesh-python whenever mesh editing needed to be done from Python, it just played out that by the time we got this BMesh-API available, the scripts you mention were working with RNA-API and theres not much incentive to rewrite - only for the sake of cleaner code. If I needed to make any significant changes to these script's Id rewrite them for sure. To see the the difference between a script written using RNA-API's and BMesh-API, check these 2 scripts (both do a vertex dirt-map effect and are fairly similar) rna: https://svn.blender.org/svnroot/bf-blender/trunk/blender/release/scripts/startup/bl_operators/vertexpaint_dirt.py bmesh: https://svn.blender.org/svnroot/bf-extensions/contrib/py/scripts/addons/oscurart_worn_edges_map.py I've tried to include examples in the text editors templates to help give users some samples of working scripts, is there some area you think should be added to here that would help? The examples are very helpful, however most of the time my questions are more Why than How and inevitably about some corner case that isn't quite covered by one of the cookbook recipes. I don't know that this is necessarily a documentation issue as much as I simply haven't committed enough time to fully understanding how Blender's internals work. This certainly goes to David's point about the difficulty of diving in for casual users, unfortunately I don't know how to bypass the learning curve. Fortunately, the last time I spent much time on scripting Blender was ~3 months ago and I remember thinking at the time that the more conceptual API documentation had improved since the last time I looked at it. Afraid every time I try do something non-trivial in someone else's open-source project (non-blender), its pretty steep learning curve too, getting from some template/example code to something useful is just tricky and theres so much assumed knowledge about how components work together, what kind of patterns your expected to use etc... Not to be dismissive and put this in the `too hard` basked, but if new devs want to contribute to an advanced graphics app, they can expect to have to get their hands dirty a bit... (unless we attempt to hide details and expose simple API's - 2.4x attempted this with its Python API and it didn't work so well, of course we could try again). Nevertheless, your point is well taken. That our existing code is not always so readable and it makes it harder to learn by example. I had a quick look over google's standards and while we don't follow all, a lot of them are aligned with pep8 (and common sense), if you think there are some we could benefit from, I'd be interested to know which ones specifically. I like that Google's standard is explicit about how to document things like function arguments and return values, whereas PEP 257 doesn't really give any guidance other than do it. Numpy's docstring style guide is also quite good about this. Currently we use sphinx style comments, but this is only used for API functions in modules intended to be re-used by other scripts, eg: http://www.blender.org/documentation/blender_python_api_2_67_release/bpy.utils.html For functions local to a file they often aren't commented much. I can see why you might like comments here but I would leave this up to the author of each script to choose how much to comment internal functions, classes etc - rather then defining a policy (for the moment at least). I might quibble with some of Google's choices but the main things I like about it for my own projects are that: it is in one place, is pretty comprehensive, I can point someone else to it and expect a reasonable result, and I didn't have to write it. I know Blender has a style guide for C code and it would probably be good to have one for Python, even if it is just a paragraph saying Follow PEP 8 257. Yep, this should be set out more clearly in our wiki docs (added to my todo list) Integrating ipython is fairly straightforward I
Re: [Bf-committers] Blender roadmap article on code blog
Yes, there is a performance cost for Mono/V8 relative to C, but for many types of code that gap is quite small, about 1-3x Speaking only as an artist: LOL I dare you to go to BlenderArtist and tell them you have decided to include 2 Microsoft programs in Blender that will slow down there render times by 300%! They are dancing in the streets there because of a 20% speedup in cycles that might be coming!! Need I even talk about the hate of Mono correct or not? -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] vrbuilder - valuable critique on Blender as a tool for architectural visualization
I suspect you are referencing this specific post... http://vrbuilder.wordpress.com/2013/06/26/1-month-self-exam-what-did-i-learn-until-now-ii/ No, I am referencing the whole blog, there are thoughts and ideas spread all over. I think some of his new user onboarding points are interesting opportunities for improvements, though I'm not so on board with his improvement ideas. I think most of this may be better discussed somewhere I think the first place to discuss his ideas is his blog, not this mailing list. Later, for summary I can add a new section to http://wiki.blender.org/index.php/Dev:Source/Development/Proposals/ArchiProject or an extra page dedicated to Blender 2.6x exclusively. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] VS 2013 + Blender = ???
Sure! Switch to MinGw, but please do some good testing ;) I am the last not to support this ;) Am 28.06.2013 um 20:13 schrieb Cezary Kopias cezary.kop...@gmail.com: From USER: As always speed tests must be performed for such a decision. Are there any new VS features that are worth mention? And as always i will promote mingw-w64 :] just read that you can compile windows build under linux - nice /kopias On Fri, 28 Jun 2013 20:08:30 +0200, Jürgen Herrmann shadow...@me.com wrote: Logic error corrected inline ;) Hi there, Out of curiosity I downloaded the VS 2013 Pro preview yesterday. And while playing with it I had the idea to try blender compilation with it ;) I needed to tweak the sources a bit because MSVC 12 seems to break se things as M$ implements more C++11 features. It took me 30 Minutes to put a patch together. But all the libs I compiled with VC11 need to be recompiled :( So I stopped this insanity ... But what I am curious about, what do you guys think? Shall we adapt new versions if MSVC early (even if we don't use it for production) or not? Pro: when we decide to switch to another version (let's assume MSVC 2016, just for an example) the workload of porting might Not be that huge. Con: we have to recompile libs and port blender every year (in case MS keeps this release schedule) /Jürgen ___ 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 -- Using Opera's mail client: http://www.opera.com/mail/ ___ 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 roadmap article on code blog
On Fri, Jun 28, 2013 at 1:35 PM, Knapp magick.c...@gmail.com wrote: Yes, there is a performance cost for Mono/V8 relative to C, but for many types of code that gap is quite small, about 1-3x Speaking only as an artist: LOL I dare you to go to BlenderArtist and tell them you have decided to include 2 Microsoft programs in Blender that will slow down there render times by 300%! A language used for UI extension and tools does not affect render-times. OSL is already the way to user-extend cycles and that is not part of the discussion. Python is allowed for 2d compositing nodes now. Using C# or TypeScript/V8 for these nodes would speed them up 3-10x. However, don't get too excited, because a single composite node, even in Python, is probably only 2-20% of the total composite time and only 0.1-0.5% of total render time if there is a 3d scene. ..so I think your concern about how this would somehow slow down rendering is mis-placed. It wouldn't. That said, there are many good points in this discussion about extension languages. I think it would be nice to see a typed scripting option, but I also agree that getting some of the benefits I hope for would take lots more than adding the language option. I'm going to have to think on this some more, and for now I'm removing/replacing this item in my personal roadmap wishlist with a different one... 4) Make Blender UI, launch-state, splash more friendly to users who wish to use only a subset of functionality (without compromising the power users). The first case-in-point, 2d-compositor-only users. -- Why? -- Blender is arguably one of the most powerful open-source 2d compositors. However, the UI doesn't make this apparent or easy to do without understanding 3d rendering. Making blender more friendly to these users will mean more blender users, more potential developers, and more goodness. Easier said than done, but I think it's worthy. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] VS 2013 + Blender = ???
Hi Thomas, I don't want to update right now, but as ms changed their pace to yearly updates with significant new features and changed compatibilities (e.g more c++11 features) we will have to do a lot of work if we wait 5 years again. As I said I've got a patch for VS 2013 ready and working in my local repo. We could update instantly but I don't want to due to the reasons you stated. I just want to avoid the messy update work we had because we skipped one version. If we skip 5 versions of MSVC (provided that ms keeps this pace) the updating mess will be huge :( So doing a little testing once and a small patch in a while wont hurt, I think. Am 28.06.2013 um 23:27 schrieb Thomas Dinges blen...@dingto.org: Hi Jürgen, We used vc2008 now for like 5 years? or so, and this worked out quite good. Probably we should update more frequently, but I see no reason to rush things either. It will still take some weeks or months to test vc2012 with Blender thoroughly, to use this as a vc2008 replacement for official builds. So let's finish the vc2012 update first, use it for official builds and then worry about when and if we should update the next time. ;) Thomas Am 28.06.2013 23:14, schrieb Jürgen Herrmann: Sure! Switch to MinGw, but please do some good testing ;) I am the last not to support this ;) Am 28.06.2013 um 20:13 schrieb Cezary Kopias cezary.kop...@gmail.com: From USER: As always speed tests must be performed for such a decision. Are there any new VS features that are worth mention? And as always i will promote mingw-w64 :] just read that you can compile windows build under linux - nice /kopias On Fri, 28 Jun 2013 20:08:30 +0200, Jürgen Herrmann shadow...@me.com wrote: Logic error corrected inline ;) Hi there, Out of curiosity I downloaded the VS 2013 Pro preview yesterday. And while playing with it I had the idea to try blender compilation with it ;) I needed to tweak the sources a bit because MSVC 12 seems to break se things as M$ implements more C++11 features. It took me 30 Minutes to put a patch together. But all the libs I compiled with VC11 need to be recompiled :( So I stopped this insanity ... But what I am curious about, what do you guys think? Shall we adapt new versions if MSVC early (even if we don't use it for production) or not? Pro: when we decide to switch to another version (let's assume MSVC 2016, just for an example) the workload of porting might Not be that huge. Con: we have to recompile libs and port blender every year (in case MS keeps this release schedule) /Jürgen ___ 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 -- Using Opera's mail client: http://www.opera.com/mail/ ___ 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 -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ 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] VS 2013 + Blender = ???
Hi Jürgen and Thomas: From what I understand, they just release the *preview* version of vs 2013. I would advise to wait for the final release due to possible incompatibility between this and final versions (libs wise). I don't see a reason to move to 2013 preview right now. We don't use C++ much and to the full extend (except possibly Cycles) and I'm not aware of that2013 brings C11 support. Also, if you have previous toolkit installed (vs 2012), the 2012 libs should still be compatible with 2013. When 2013 is released, we can drop 2012 as we did with 2010. And still have 2008 as official! As for the patch to the code to make it compliant with c++11, it would be great addition (although gcc doesn't have issues). Best, Alex On 6/28/2013 6:46 PM, Jürgen Herrmann wrote: Hi Thomas, I don't want to update right now, but as ms changed their pace to yearly updates with significant new features and changed compatibilities (e.g more c++11 features) we will have to do a lot of work if we wait 5 years again. As I said I've got a patch for VS 2013 ready and working in my local repo. We could update instantly but I don't want to due to the reasons you stated. I just want to avoid the messy update work we had because we skipped one version. If we skip 5 versions of MSVC (provided that ms keeps this pace) the updating mess will be huge :( So doing a little testing once and a small patch in a while wont hurt, I think. Am 28.06.2013 um 23:27 schrieb Thomas Dinges blen...@dingto.org: Hi Jürgen, We used vc2008 now for like 5 years? or so, and this worked out quite good. Probably we should update more frequently, but I see no reason to rush things either. It will still take some weeks or months to test vc2012 with Blender thoroughly, to use this as a vc2008 replacement for official builds. So let's finish the vc2012 update first, use it for official builds and then worry about when and if we should update the next time. ;) Thomas Am 28.06.2013 23:14, schrieb Jürgen Herrmann: Sure! Switch to MinGw, but please do some good testing ;) I am the last not to support this ;) Am 28.06.2013 um 20:13 schrieb Cezary Kopias cezary.kop...@gmail.com: From USER: As always speed tests must be performed for such a decision. Are there any new VS features that are worth mention? And as always i will promote mingw-w64 :] just read that you can compile windows build under linux - nice /kopias On Fri, 28 Jun 2013 20:08:30 +0200, Jürgen Herrmann shadow...@me.com wrote: Logic error corrected inline ;) Hi there, Out of curiosity I downloaded the VS 2013 Pro preview yesterday. And while playing with it I had the idea to try blender compilation with it ;) I needed to tweak the sources a bit because MSVC 12 seems to break se things as M$ implements more C++11 features. It took me 30 Minutes to put a patch together. But all the libs I compiled with VC11 need to be recompiled :( So I stopped this insanity ... But what I am curious about, what do you guys think? Shall we adapt new versions if MSVC early (even if we don't use it for production) or not? Pro: when we decide to switch to another version (let's assume MSVC 2016, just for an example) the workload of porting might Not be that huge. Con: we have to recompile libs and port blender every year (in case MS keeps this release schedule) /Jürgen ___ 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 -- Using Opera's mail client: http://www.opera.com/mail/ ___ 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 -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ 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 roadmap article on code blog
eeh, there is some misinformation here... On Sat, Jun 29, 2013 at 7:54 AM, David Jeske dav...@gmail.com wrote: On Fri, Jun 28, 2013 at 1:35 PM, Knapp magick.c...@gmail.com wrote: Yes, there is a performance cost for Mono/V8 relative to C, but for many types of code that gap is quite small, about 1-3x Speaking only as an artist: LOL I dare you to go to BlenderArtist and tell them you have decided to include 2 Microsoft programs in Blender that will slow down there render times by 300%! Mono follows an MS spec for the language runtime (CLR), not sure what the second program you refer to is. At least the technology isn't owned by MS and its open-source. People may be wary of using MS derived technology but from what I can tell Mono wouldn't tie us to MS any more then Java would to Oracle. A language used for UI extension and tools does not affect render-times. OSL is already the way to user-extend cycles and that is not part of the discussion. Python is allowed for 2d compositing nodes now. Using C# or TypeScript/V8 for these nodes would speed them up 3-10x. However, don't get too excited, because a single composite node, even in Python, is probably only 2-20% of the total composite time and only 0.1-0.5% of total render time if there is a 3d scene. PyNodes don't allow python to be used for blenders existing C++ compositor, See: http://blender.stackexchange.com/questions/553/is-it-possible-to-create-a-compositor-node-with-pynodes-that-outputs-camera-clip However there has been some talk of using OSL for compositor nodes, apparently it could be supported but I dont know details here. ..so I think your concern about how this would somehow slow down rendering is mis-placed. It wouldn't. That said, there are many good points in this discussion about extension languages. I think it would be nice to see a typed scripting option, but I also agree that getting some of the benefits I hope for would take lots more than adding the language option. I'm going to have to think on this some more, and for now I'm removing/replacing this item in my personal roadmap wishlist with a different one... 4) Make Blender UI, launch-state, splash more friendly to users who wish to use only a subset of functionality (without compromising the power users). The first case-in-point, 2d-compositor-only users. -- Why? -- Blender is arguably one of the most powerful open-source 2d compositors. However, the UI doesn't make this apparent or easy to do without understanding 3d rendering. Making blender more friendly to these users will mean more blender users, more potential developers, and more goodness. Easier said than done, but I think it's worthy. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
