Re: [Bf-committers] Google Summer of Code 2016 - Adding CAD functionality to Blender

[matmenu]

Hi Jaume,

Just looked at your new function for dimensions, it looks so awesome :D 
Please try to get some of your improvements merged with small patches.

On 04/03/2016 15:46, Jaume Bellet wrote:
> merging the code on bf master is not in my hands, should be accepted, and
> some efforts should be done to avoid problems with others parts of code.
> Some time ago I proposed to create branch in bf repo, but was no performed.
>
> Some years ago i started the creation of the new space (on blender 2.4x)
> for formal drawings, but i did not finished it.  I think that for that
> purpose could be re-used the Freestyle code to get the view.
>
>
> 2016-03-04 13:11 GMT+01:00 João Araújo <jarauj...@gmail.com>:
>
>> Your work is amazing Jaume! I guess that it kills a few points from my
>> initial list (assuming you are going to merge your code with the Blender
>> master).
>>
>> Still, I would like to ear some opinions on the first topic of my list
>> (editor that would allow the user to make ISO-compliant drawings of
>> individual parts), which I consider the most important. I can implement the
>> other points as a python add-on.
>>
>> Does anyone have some suggestion as to who I could contact personally that
>> could possibly be interested in being a mentor for this?
>>
>> I will avoid blenderartists for a while, at least until I have more solid
>> ideas.
>>
>> 2016-03-04 11:53 GMT+00:00 Jaume Bellet <ma...@bixo.org>:
>>
>>> https://vimeo.com/user2228784/videos
>>>
>>> Here are some videos of work done in a separate repo from bf official
>> one.
>>> Work there is still in progress, not for production.
>>>
>>> I tried the snap tools to be applied on blender, but the final decision
>> was
>>> to wait, as the code was on transform, which is a little messy, and
>>> affecting lots of areas, and was said to check if could be integrated in
>>> the new coming widgets.
>>>
>>> Any built-in cad features will be great ;)
>>>
>>> 2016-03-02 21:05 GMT+01:00 Daniel Salazar - patazstudio.com <
>>> zan...@gmail.com>:
>>>
>>>> Freecad could be imported in Blender as a python library. I say could
>>>> because there's a little problem with freecad using py2.7
>>>> Daniel Salazar
>>>> patazstudio.com
>>>>
>>>>
>>>> On Wed, Mar 2, 2016 at 11:50 AM, matmenu <matm...@live.fr> wrote:
>>>>> Hi João,
>>>>>
>>>>> Good to see some interest in improving Blender's CAD capabilities :)
>> I
>>>>> think it would be a good idea to speak about it on Blenderartists,
>>>>> giving some focus to avoid the Christmas list effect. From experience
>>>>> and what I read on the forums though, improving the snapping system
>>>>> would be very welcome.
>>>>>
>>>>> For dimensioning, there are already many addons, 2 of them are really
>>>>> good:
>>>>>
>> http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Curve/Dimension
>>>>> and
>>>>>
>> https://www.blender3darchitect.com/2012/10/dimension-lines-for-blender-with-the-caliper-add-on/
>>>>> and https://github.com/Antonioya/blender/tree/master/measureit.
>>>>>
>>>>> I find it interesting to have some work done in Python in this GSoC
>> as
>>>>> it will ensure users are able to use it in the end :)
>>>>>
>>>>> Regards
>>>>>
>>>>> On 02/03/2016 13:17, João Araújo wrote:
>>>>>> Good afternoon,
>>>>>>
>>>>>> I am a college student who has known Blender for a few years now,
>> and
>>>> would
>>>>>> like to contribute in GSoC 2016 by adding CAD functionality. I would
>>>> like
>>>>>> to ear your thoughts on my project idea.
>>>>>>
>>>>>> I have been checking on what has been done to implement CAD in
>>> Blender.
>>>> I
>>>>>> didn't find almost any software. Mostly there were forum discussions
>>>> about
>>>>>> how great it would be if Blender could have CAD features, while
>> others
>>>>>> stated that it would be impractical.
>>>>>>
>>>>>> The only actual add-on I found was this one
>>>>>>
>>>>>> http://www.cad4arch.com/cadtools/index.htm
>>>>>>
>>>>>

Re: [Bf-committers] Google Summer of Code 2016 - Adding CAD functionality to Blender

[matmenu]

Maybe contact Campbell, as he will work on custom editors for 2.8. But 
I'm not sure this is something the users and the BF wants in Blender.

What would be the advantage of such an editor over the normal quad 
3Dview or a normal orthogonal view? I may be wrong, but many users, even 
architects and engineer know that Blender isn't a CAD program. What we 
are looking for is not really to make a CAD program out of Blender (32 
bit precision will avoid it anyway), but more to make operations that 
are often required in the sketching (=concept phase) and rendering (= 
final phase) process easier. And many of those addition, like better 
snapping, benefit many users (people doing hard surface modelling, cars, 
etc...). An editor only for CAD user sounds a bit to specific?

Maybe you could explain with images better what would be the benefit of 
such a new editor over the 3D view? If your work goes in the direction 
of preparing for custom editors, then I guess it would awake much more 
interest from users and programmers :) Your ISO parts editor could hen 
be an example of such a custom editor, written in python on top of your 
new API?

On 04/03/2016 13:11, João Araújo wrote:
> Your work is amazing Jaume! I guess that it kills a few points from my
> initial list (assuming you are going to merge your code with the Blender
> master).
>
> Still, I would like to ear some opinions on the first topic of my list
> (editor that would allow the user to make ISO-compliant drawings of
> individual parts), which I consider the most important. I can implement the
> other points as a python add-on.
>
> Does anyone have some suggestion as to who I could contact personally that
> could possibly be interested in being a mentor for this?
>
> I will avoid blenderartists for a while, at least until I have more solid
> ideas.
>
> 2016-03-04 11:53 GMT+00:00 Jaume Bellet <ma...@bixo.org>:
>
>> https://vimeo.com/user2228784/videos
>>
>> Here are some videos of work done in a separate repo from bf official one.
>> Work there is still in progress, not for production.
>>
>> I tried the snap tools to be applied on blender, but the final decision was
>> to wait, as the code was on transform, which is a little messy, and
>> affecting lots of areas, and was said to check if could be integrated in
>> the new coming widgets.
>>
>> Any built-in cad features will be great ;)
>>
>> 2016-03-02 21:05 GMT+01:00 Daniel Salazar - patazstudio.com <
>> zan...@gmail.com>:
>>
>>> Freecad could be imported in Blender as a python library. I say could
>>> because there's a little problem with freecad using py2.7
>>> Daniel Salazar
>>> patazstudio.com
>>>
>>>
>>> On Wed, Mar 2, 2016 at 11:50 AM, matmenu <matm...@live.fr> wrote:
>>>> Hi João,
>>>>
>>>> Good to see some interest in improving Blender's CAD capabilities :) I
>>>> think it would be a good idea to speak about it on Blenderartists,
>>>> giving some focus to avoid the Christmas list effect. From experience
>>>> and what I read on the forums though, improving the snapping system
>>>> would be very welcome.
>>>>
>>>> For dimensioning, there are already many addons, 2 of them are really
>>>> good:
>>>>
>> http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Curve/Dimension
>>>> and
>>>>
>> https://www.blender3darchitect.com/2012/10/dimension-lines-for-blender-with-the-caliper-add-on/
>>>> and https://github.com/Antonioya/blender/tree/master/measureit.
>>>>
>>>> I find it interesting to have some work done in Python in this GSoC as
>>>> it will ensure users are able to use it in the end :)
>>>>
>>>> Regards
>>>>
>>>> On 02/03/2016 13:17, João Araújo wrote:
>>>>> Good afternoon,
>>>>>
>>>>> I am a college student who has known Blender for a few years now, and
>>> would
>>>>> like to contribute in GSoC 2016 by adding CAD functionality. I would
>>> like
>>>>> to ear your thoughts on my project idea.
>>>>>
>>>>> I have been checking on what has been done to implement CAD in
>> Blender.
>>> I
>>>>> didn't find almost any software. Mostly there were forum discussions
>>> about
>>>>> how great it would be if Blender could have CAD features, while others
>>>>> stated that it would be impractical.
>>>>>
>>>>> The only actual add-on I found was this one
>>>>>
>>>>> http://www.cad4

Re: [Bf-committers] Google Summer of Code 2016 - Adding CAD functionality to Blender

[matmenu]

Hi João,

Good to see some interest in improving Blender's CAD capabilities :) I 
think it would be a good idea to speak about it on Blenderartists, 
giving some focus to avoid the Christmas list effect. From experience 
and what I read on the forums though, improving the snapping system 
would be very welcome.

For dimensioning, there are already many addons, 2 of them are really 
good: 
http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Curve/Dimension 
and
https://www.blender3darchitect.com/2012/10/dimension-lines-for-blender-with-the-caliper-add-on/
 
and https://github.com/Antonioya/blender/tree/master/measureit.

I find it interesting to have some work done in Python in this GSoC as 
it will ensure users are able to use it in the end :)

Regards

On 02/03/2016 13:17, João Araújo wrote:
> Good afternoon,
>
> I am a college student who has known Blender for a few years now, and would
> like to contribute in GSoC 2016 by adding CAD functionality. I would like
> to ear your thoughts on my project idea.
>
> I have been checking on what has been done to implement CAD in Blender. I
> didn't find almost any software. Mostly there were forum discussions about
> how great it would be if Blender could have CAD features, while others
> stated that it would be impractical.
>
> The only actual add-on I found was this one
>
> http://www.cad4arch.com/cadtools/index.htm
>
> but although it is still being developed, it is paid and only works with
> Blender 2.49b. The author states an intention of embedding it into Blender,
> though.
>
> >From what I read, and based on my experience working with CAD packages, I
> compiled a list of targets for what I would propose myself to achieve
> during GSoC:
>
> ordered from most important to less important
>
>- Add a new editor that would allow the user to make ISO-compliant
> drawings of individual parts.
>- This requires, from the top of my head, the ability of drawing the
> 6 isometric views, at a standard scale, on standard sized paper (A4, A3,
> etc.), adding dimensions (lengths and angles), centerlines, axes, being
> able to do section views (with crosshatch drawing) and detail views.
>- Add sketch tools (the ability to draw lines, circles, rectangles, etc.
> ; this serves the purpose of increasing the precision of drawing with
> Blender)
>- Add reference geometry (reference planes and axes)
>- Add a dimensioning tool (something that allows the user to edit the
> dimensions a posteriori the sketch being created)
>- Modify the array modifier in order to allow explicit circular arrays
> - This can already be achieved using a trick with empties, but I
> would like to clarify this workflow and simplify it (for example, instead
> of the user rotating the empty by 360/n degrees, where n is the number of
> objects, he would simply select n and the modifier would take care of the
> rest)
>- Add a fillet tool (a very simple addition; can be done with vertex
> groups and the bevel modifier currently; once again I simply want to
> simplify it)
>- Add a precise offset tool (currently, I can simply extrude and scale ;
> I want to make this work with the dimensioning tool mentioned above)
>
>
> I believe these are all feasible by me, with the first one being the most
> complex and one of the few requiring C programming. The others could be
> implemented as a Python Add-On.
>
> Best regards,
> Joao
> ___
> 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] Google Summer of Code 2016 - Adding CAD functionality to Blender

[matmenu]

Hi João,

Good to see some interest in improving Blender's CAD capabilities :) I 
think it would be a good idea to speak about it on Blenderartists, 
giving some focus to avoid the christmas list effect. From experience 
and what I read on the forums though, improving the snapping system 
would be very welcome.

For dimensioning, there are already many addons, 2 of them are really 
good: 
http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Curve/Dimension 
and
https://www.blender3darchitect.com/2012/10/dimension-lines-for-blender-with-the-caliper-add-on/
 
and https://github.com/Antonioya/blender/tree/master/measureit.

I find it interesting to have some work done in Python in this GSoC as 
it will allow users to use it even if it's not merged in master!

Regards

On 02/03/2016 13:17, João Araújo wrote:
> Good afternoon,
>
> I am a college student who has known Blender for a few years now, and would
> like to contribute in GSoC 2016 by adding CAD functionality. I would like
> to ear your thoughts on my project idea.
>
> I have been checking on what has been done to implement CAD in Blender. I
> didn't find almost any software. Mostly there were forum discussions about
> how great it would be if Blender could have CAD features, while others
> stated that it would be impractical.
>
> The only actual add-on I found was this one
>
> http://www.cad4arch.com/cadtools/index.htm
>
> but although it is still being developed, it is paid and only works with
> Blender 2.49b. The author states an intention of embedding it into Blender,
> though.
>
> >From what I read, and based on my experience working with CAD packages, I
> compiled a list of targets for what I would propose myself to achieve
> during GSoC:
>
> ordered from most important to less important
>
>- Add a new editor that would allow the user to make ISO-compliant
> drawings of individual parts.
>- This requires, from the top of my head, the ability of drawing the
> 6 isometric views, at a standard scale, on standard sized paper (A4, A3,
> etc.), adding dimensions (lengths and angles), centerlines, axes, being
> able to do section views (with crosshatch drawing) and detail views.
>- Add sketch tools (the ability to draw lines, circles, rectangles, etc.
> ; this serves the purpose of increasing the precision of drawing with
> Blender)
>- Add reference geometry (reference planes and axes)
>- Add a dimensioning tool (something that allows the user to edit the
> dimensions a posteriori the sketch being created)
>- Modify the array modifier in order to allow explicit circular arrays
> - This can already be achieved using a trick with empties, but I
> would like to clarify this workflow and simplify it (for example, instead
> of the user rotating the empty by 360/n degrees, where n is the number of
> objects, he would simply select n and the modifier would take care of the
> rest)
>- Add a fillet tool (a very simple addition; can be done with vertex
> groups and the bevel modifier currently; once again I simply want to
> simplify it)
>- Add a precise offset tool (currently, I can simply extrude and scale ;
> I want to make this work with the dimensioning tool mentioned above)
>
>
> I believe these are all feasible by me, with the first one being the most
> complex and one of the few requiring C programming. The others could be
> implemented as a Python Add-On.
>
> Best regards,
> Joao
> ___
> 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] Development fund grant for Lukas Toenne - 'everything nodes'

[matmenu]

Like that https://developer.blender.org/D113 ? Coded by a programmer 
working for Modo now. Campbell waid he will update it against latest 
master. I hope it will be soon :)

On 16/02/2016 08:50, Alexander Romanov wrote:
> Great news!
>
> I also have some proposal about custom nodes. It would be great if it
> would be taken into account.
> http://wiki.blender.org/index.php/Linking_Custom_Node_Tree_to_DataBlock
>
> On 15.02.2016 21:41, Ton Roosendaal wrote:
>> Hi,
>>
>> Lukas accepted a grant to work two months on a design proposal for the 
>> “everything nodes” 2.8 project in Blender – including for object transform, 
>> modifiers, particles, hair and simulation. He'll be working on this together 
>> with Sergey.
>>
>> Lukas will be presenting discussion material for everyone soon. Hopefully 
>> this will kickstart a crucial 2.8 project for us!
>>
>> I would also like to invite (python) coders who already worked on procedural 
>> modeling and animation nodes to connect or reach out. Your experience and 
>> feedback is important!
>>
>> Laters,
>>
>> -Ton-
>>
>> 
>> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
>> Chairman Blender Foundation - Producer Blender Institute
>> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>>
>>
>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Windows XP support

[matmenu]

Find me someone that used Blender on a linux distro one year long 
without solving several problems with the command line.

Still today, the Linux distro which is seen as the most user-friendly:
https://www.reddit.com/r/linuxmasterrace/comments/30c7ig/nvidia_drivers_not_working_with_linux_mint/
http://unix.stackexchange.com/questions/153040/amd-drivers-make-linux-mint-17-cinnamon-crash
https://nautilusmode.com/2015/08/09/how-to-install-krita-on-linux-mint-17-2/
http://www.webupd8.org/2015/11/install-gimp-2816-in-ubuntu-or-linux.html

Dataloss on the most stable Linux Distro:
https://access.redhat.com/solutions/369383
https://bugzilla.kernel.org/show_bug.cgi?id=29162

And this are just some quick googling results. You can find much better 
ones.

All the solutions proposed use the command line. I used Linux for more 
than 10 years. Not a single year I could get all my apps and drivers in 
their latest version without googling, posting on forum and using the 
command line. Not speaking about the fun due to conflicts in the 
libraries when you add to many repos, breaking other pass, etc.
You can of course still believe that the 8% of Blender user under Linux 
is due to people using the version 2.69 of Blender that is in their repo 
or that all graphic artists on Linux have the time and skills to 
compile  Blender themselves. On Windows, you download, double click the 
installer or just unpack the archive and it just works.
Note that I would be happy to see Linux as a serious alternative, but 
it's still reserved to a small passionate community due to the final 
polish not being done. 95% is there, but time is spend compiling the 
same program 100x times for the 100s of distros and making 10 
alternative of a video/music player/text editor/whatever, helping to 
post command line solutions on 20 different forums instead of fixing 
upstream once and for all. Creating new file systems with hash 
collisions leading to security risk and data loss (BtrFS). In 2015 not 
supporting NTFS completly (https://wimlib.net/forums/viewtopic.php?t=4).
And most people on earth can't afford a new PC every 10 years.

On 30/01/2016 15:25, Knapp wrote:
> If your computer is so old that it is running XP then you will have
> problems with most advanced features that expect you to have a powerful
> computer. If the XP users really must use his old computer and he wants new
> features that are not supported and he has internet then he can download a
> new and modern Linux lite distro and run the newest Blender. It is not like
> we are even locking out poor people by dropping XP support.
>
> On Sat, Jan 30, 2016 at 12:15 AM, Martijn Berger 
> wrote:
>
>> Hi Mike,
>>
>> I am pretty sure it either works or can be made to work pretty easy.
>>
>> Martijn
>>
>> On Fri, Jan 29, 2016 at 10:39 PM, Mike Erwin 
>> wrote:
>>
>>> On Fri, Jan 29, 2016 at 3:14 PM, Sebastian A. Brachi <
>>> sebastianbra...@gmail.com> wrote:
>>>
> What newer APIs do we want to use but are being held back by XP?
>
 What about Python 3.5, which doesn't support XP anymore?

 As specified in PEP 11, a Python release only supports a Windows
>> platform
> while Microsoft considers the platform under extended support. This
>>> means
> that Python 3.5 supports Windows Vista and newer. If you require
>>> Windows
 XP
> support then please install Python 3.4.
 https://docs.python.org/3/using/windows.html

>>> If Python stops working that's a BIG reason to move on. If unsupported
>>> means "works, but don't expect support"... it's not as urgent.
>>> ___
>>> 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] Windows XP support

[matmenu]

HI Matijn,

It's ok to drop xp for 2.8. It would be good to keep everyone on board 
for 2.7x but if it's really to much hassle, I think everyone can 
understand. Bliblubli on BA did a xp compatible build of latest master 
with OpenVDB. Maybe you can join forces?

Mat

On 29/01/2016 09:50, Martijn Berger wrote:
> Hi Sergey,
>
> I think that we should drop window XP after 2.77. And switch to msvc 2015
> for 2.78 and 2.8 also.
>
> We should clearly advertise windows 7 SP1. As most issue are with FMA / AVX
> support and windwos 7 pre SP1 has some issues there.
>
> Martijn
>
> On Fri, Jan 29, 2016 at 9:31 AM, Sergey Sharybin 
> wrote:
>
>> Hey everyone,
>>
>> There are some difficulties in maintaining Windows XP and additionally
>> there are some glitches in the toolset needed to compile Windows XP
>> compatible binaries.
>>
>> So proposal is: make 2.77 a last release which officially supports Windows
>> XP and for the further releases switch to Windows 7+ platforms only. We'll
>> still be doing 64bit and 32bit builds, but just wouldn't waste time trying
>> to support new features on a platform which is no longer supported by
>> others.
>>
>> Thoughts?
>>
>> --
>> With best regards, Sergey Sharybin
>> ___
>> 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] SCons build system future

[matmenu]

The build is successfull. No errors like with the GUI solution. But some 
.lib and .manifest files are in the bin dir although they shouldn't 
(they are not in the buildbot nor scons builds)

Am 21/12/2015 um 20:21 schrieb matmenu:
> Thank you Antony, that was part of the problem. For some reason, I also
> had to completly delete everything in the "blender-build" folder,
> otherwise it would still look for the 32 bit version of the libs
> (despite the cmake cache being deleted by the .bat file).
>
> Ok, so you can put the .bat file I gave in the last email in the
> official Git repo. Only thing that would be nice would be to have a
> script that clone the git to ensure the path is the right one. Or write
> it in the wiki doc.
>
>
> Am 21/12/2015 um 14:53 schrieb Antony Riakiotakis:
>> Did you start your batch file from a visual studio 64 bit command line
>> (It's under visual studio folder in program launcher)? It's important, else
>> the system will think you're compiling for 32 bits and search for the 32bit
>> windows folder.
>>
>> On 21 December 2015 at 14:29, matmenu <matm...@live.fr> wrote:
>>
>>> Thanks Owen, but I compile Blender on Linux since years with cmake and
>>> on windows since some month with scons. The problem doesn't come from
>>> the dependencies, as they are all from latest svn in lib\win64_vc12 and
>>> blender compiles well when building from vs2013 UI. The problem is with
>>> the .bat file given by Antony. I post it again as requested by sergey
>>> (note that it completly fails to build, so it's not only a waring):
>>>
>>> --.bat file--
>>>
>>> cd %HOMEPATH%\blender_git\blender
>>> git checkout master
>>> git pull --rebase
>>> git submodule update --recursive --remote
>>>
>>> cd %HOMEPATH%\blender_git\blender-build
>>> del CMakeCache.txt
>>> cmake ..\blender -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release
>>> -DWITH_BUILDINFO=ON -DWITH_BULLET=ON -DWITH_CODEC_AVI=ON
>>> -DWITH_CODEC_FFMPEG=ON -DWITH_CODEC_SNDFILE=ON -DWITH_CYCLES=ON
>>> -DWITH_CYCLES_OSL=ON -DWITH_FFTW3=ON -DWITH_LIBMV=ON
>>> -DWITH_LIBMV_SCHUR_SPECIALIZATIONS=ON -DWITH_GAMEENGINE=ON
>>> -DWITH_COMPOSITOR=ON -DWITH_FREESTYLE=ON -DWITH_GHOST_XDND=ON
>>> -DWITH_IK_SOLVER=ON -DWITH_IK_ITASC=ON -DWITH_IMAGE_CINEON=ON
>>> -DWITH_IMAGE_DDS=ON -DWITH_IMAGE_FRAMESERVER=ON -DWITH_IMAGE_HDR=ON
>>> -DWITH_IMAGE_OPENEXR=ON -DWITH_IMAGE_OPENJPEG=ON -DWITH_IMAGE_REDCODE=ON
>>> -DWITH_IMAGE_TIFF=ON -DWITH_INPUT_NDOF=ON -DWITH_INTERNATIONAL=ON
>>> -DWITH_JACK=ON -DWITH_LZMA=ON -DWITH_LZO=ON -DWITH_MOD_BOOLEAN=ON
>>> -DWITH_MOD_FLUID=ON -DWITH_MOD_REMESH=ON -DWITH_MOD_SMOKE=ON
>>> -DWITH_MOD_OCEANSIM=ON -DWITH_AUDASPACE=ON -DWITH_OPENAL=ON
>>> -DWITH_OPENCOLLADA=ON -DWITH_OPENCOLORIO=ON -DWITH_OPENMP=ON
>>> -DWITH_PYTHON_INSTALL=ON -DWITH_RAYOPTIMIZATION=ON -DWITH_SDL=ON
>>> -DWITH_X11_XINPUT=ON -DWITH_X11_XF86VMODE=ON -DWITH_PLAYER=ON
>>> -DWITH_MEM_JEMALLOC=ON
>>>
>>> nmake install
>>> 
>>>
>>> and this is the output of this command:
>>>
>>>
>>> 
>>> -- Performing Test SUPPORT_SSE_BUILD
>>> -- Performing Test SUPPORT_SSE_BUILD - Success
>>> -- SSE Support: detected.
>>> -- Performing Test SUPPORT_SSE2_BUILD
>>> -- Performing Test SUPPORT_SSE2_BUILD - Success
>>> -- SSE2 Support: detected.
>>> -- Performing Test HAVE_STDBOOL_H
>>> -- Performing Test HAVE_STDBOOL_H - Success
>>> -- 32 bit compiler detected.
>>> -- Visual Studio 2013 detected.
>>> -- Found ZLIB:
>>> C:/Users/test/blender_git/blender/../lib/windows_vc12/zlib/lib/libz_st.lib
>>> -- Could NOT find PNG (missing:  PNG_LIBRARY PNG_PNG_INCLUDE_DIR)
>>> CMake Warning at CMakeLists.txt:1333 (message):
>>>  Using HARDCODED libpng locations
>>>
>>>
>>> -- Could NOT find JPEG (missing:  JPEG_LIBRARY JPEG_INCLUDE_DIR)
>>> -- Found Freetype:
>>>
>>> C:/Users/test/blender_git/blender/../lib/windows_vc12/freetype/lib/freetype2ST.lib
>>> CMake Warning at CMakeLists.txt:1401 (find_package):
>>>  By not providing "FindFFMPEG.cmake" in CMAKE_MODULE_PATH this project
>>> has
>>>  asked CMake to find a package configuration file provided by
>>> "FFMPEG", but
>>>  CMake did not find one.

Re: [Bf-committers] SCons build system future

[matmenu]

 the code from github?
>
> If your having trouble you can use the file located here:
> cd [blender git location]
> ./blender/build_files/build_environment/install_deps.sh
>
> that will do a lot of the heavy lifting for you.
>
> If you want to manually build and install the dependencies. You can use
> this command
>
> cd [blender git location]
> ./blender/build_files/build_environment/install_deps.sh --show-deps
>
> to get a print out of all the dependencies then manually install those to a
> sane location.
>
> Once you install those dependencies if you then have to point CMAKE to
> where you installed those so that it can find them.
>
> I had some trouble with the install_deps.sh file but after a while it all
> built successfully.
>
> I personally like the cmake approach better but if Blender requires
> external libraries I think it would be worth looking into setting up
> blender as an external_project structure since that would allow you to
> download anything and do really advanced builds:
> https://cmake.org/cmake/help/v3.0/module/ExternalProject.html
>
> The problem with that is that external projects and add_subdirectory don't
> play nicely with each other and require a lot of hacks. to get them
> working together.
>
> On Mon, Dec 21, 2015 at 3:30 PM, matmenu <matm...@live.fr> wrote:
>
>> As Sergey, Antony and you all agreed on making a batch file, would it be
>> possible to put it in the official git? It would maybe resolve some of
>> the issues that are specific to the GUI workflow? For the exact error
>> message, I'll post them tonight as soon as I'm back home.
>> Here is the version from Antony modified to have all the feature set of
>> the full cmake version:
>>
>> 
>>
>> cd %HOMEPATH%\blender_git\blender
>> git checkout master
>> git pull --rebase
>> git submodule update --recursive --remote
>>
>> cd %HOMEPATH%\blender_git\blender-build
>> del CMakeCache.txt
>> cmake ..\blender -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release
>> -DWITH_BUILDINFO=ON -DWITH_BULLET=ON -DWITH_CODEC_AVI=ON
>> -DWITH_CODEC_FFMPEG=ON -DWITH_CODEC_SNDFILE=ON -DWITH_CYCLES=ON
>> -DWITH_CYCLES_OSL=ON -DWITH_FFTW3=ON -DWITH_LIBMV=ON
>> -DWITH_LIBMV_SCHUR_SPECIALIZATIONS=ON -DWITH_GAMEENGINE=ON
>> -DWITH_COMPOSITOR=ON -DWITH_FREESTYLE=ON -DWITH_GHOST_XDND=ON
>> -DWITH_IK_SOLVER=ON -DWITH_IK_ITASC=ON -DWITH_IMAGE_CINEON=ON
>> -DWITH_IMAGE_DDS=ON -DWITH_IMAGE_FRAMESERVER=ON -DWITH_IMAGE_HDR=ON
>> -DWITH_IMAGE_OPENEXR=ON -DWITH_IMAGE_OPENJPEG=ON -DWITH_IMAGE_REDCODE=ON
>> -DWITH_IMAGE_TIFF=ON -DWITH_INPUT_NDOF=ON -DWITH_INTERNATIONAL=ON
>> -DWITH_JACK=ON -DWITH_LZMA=ON -DWITH_LZO=ON -DWITH_MOD_BOOLEAN=ON
>> -DWITH_MOD_FLUID=ON -DWITH_MOD_REMESH=ON -DWITH_MOD_SMOKE=ON
>> -DWITH_MOD_OCEANSIM=ON -DWITH_AUDASPACE=ON -DWITH_OPENAL=ON
>> -DWITH_OPENCOLLADA=ON -DWITH_OPENCOLORIO=ON -DWITH_OPENMP=ON
>> -DWITH_PYTHON_INSTALL=ON -DWITH_RAYOPTIMIZATION=ON -DWITH_SDL=ON
>> -DWITH_X11_XINPUT=ON -DWITH_X11_XF86VMODE=ON -DWITH_PLAYER=ON
>> -DWITH_MEM_JEMALLOC=ON
>>
>> nmake install
>> 
>> Note that on my computer, this batch file fails to find most librairies
>> and I have no idea why.
>>
>>
>> Am 21/12/2015 um 01:50 schrieb Campbell Barton:
>>> Some of the issues you've described seems quite strange and I've never
>>> encountered on MS-Windows+MSVC.
>>>
>>> On Mon, Dec 21, 2015 at 5:08 AM, matmenu <matm...@live.fr> wrote:
>>>> Exactly what Antony said. Nobody will care what the building system is,
>>>> if it works out of the box. At the moment, it works perfect on Linux,
>>>> but it's still not working flawlessly on windows for me and other
>>>> friends. We made a little list of things that don't work properly:
>>>> - When using the cmake_full script, 2 modules fail to build in VS2013
>>>> (blenderplayer-related).
>>> What fails? can you link to build error?
>>>
>>>> - "cmake_full" script is not default.
>>> This is also the case with CMake on Linux/OSX,
>>> though the reasoning for this on Linux is that linking errors with
>>> FFMPEG/Collada/LLVM are more common - and the libraries are not
>>> essential in many cases.
>>>
>>>> - With Scons it is a one-line cmd that compiles a release-like build in
>>>> one step. With cmake, following the wiki doc, we have to 1) Start the
>>>> GUI and choose the folders 2) configure, change some parameters m

Re: [Bf-committers] SCons build system future

[matmenu]

Exactly what Antony said. Nobody will care what the building system is, 
if it works out of the box. At the moment, it works perfect on Linux, 
but it's still not working flawlessly on windows for me and other 
friends. We made a little list of things that don't work properly:
- When using the cmake_full script, 2 modules fail to build in VS2013 
(blenderplayer-related).
- "cmake_full" script is not default.
- With Scons it is a one-line cmd that compiles a release-like build in 
one step. With cmake, following the wiki doc, we have to 1) Start the 
GUI and choose the folders 2) configure, change some parameters manually 
3)generate solutions, 4) open VS 5) switch from debug (default) to 
release 6) start the building process.
- Switching branches is a pain. Everytime we switch the branch, we have 
to 1)delete cache, 2)configure and add my cutom params manually agin 
(with scons, it was just added to the scons script) 3) generate solution 
etc... otherwise, not all files are taken into account (for example for 
object_nodes branch which has a lot of new files) and build fails. With 
scons, the git checkout was enough to have the branch-specific scons 
script and run the one-line again.
So I agree that the best experience on Linux is with Cmake, but on 
Windows, it's still far away from ideal. Maybe just because I don't know 
Cmake on windows well and the wiki doc is not adapted, but either it's 
in doc or scripts or both, there is still some things to do to make it a 
good switch. Fixing windows specific-bugs is already not funny, so it 
would be good to make the build process as easy as with scons.


Am 20/12/2015 um 16:37 schrieb Antony Riakiotakis:
> +1 to drop scons. It may be easy to setup for casual builders, but so
> is cmake, if we provide good defaults.
>
> On 20/12/2015, Thomas Dinges  wrote:
>> I use SCons too, but I also use CMake from time to time, so it's not a
>> big deal to switch over.
>>
>> Therefore, I fully support removing SCons. Not sure we really need to
>> wait for 2.8x to do it though, imho it's fine to drop it now, we still
>> need 1-2 months before a new 2.7x release I guess, should be time enough
>> to communicate the change.
>>
>> Thomas
>>
>> Am 20.12.15 um 15:22 schrieb Mike Erwin:
>>> I use SCons but support the idea of having only one build system. Never
>>> had
>>> much luck building Blender with CMake but am willing to learn!
>>>
>>> -- 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
>>
> ___
> 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] Get Cmake on-par with scons (docs, batch files and configuration scripts)

[matmenu]

Ok so I start a new thread then following discussion regarding cmake 
switch. I know they are not due to cmake, it's just the cmake wiki-docs 
and scripts needs some tweeks and/or a batch file to bring it on scons 
level. At the moment, following the docs here 
http://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Windows/msvc/CMake 
we have many steps to follow, it breaks when switching branches or 
adding new functionnality unlike scons and the final build is missing 
many parts compared to official builds. Here are things that I think 
should be fixed before making the final switch.

- Have a one line command for cmake just like for scons (python 
scons\scons.py -j 4) to build  a version of blender similar in 
functionality and build parameters to the official/buildbot ones. "make 
full" like on linux seems good.
I tried Antony .bat file, but it doesn't find many libs and fails . 
Using the Cmake GUI or scons works. Error message are like those one:
--
-- Could NOT find JPEG (missing:  JPEG_LIBRARY JPEG_INCLUDE_DIR)
-- Found Freetype: 
C:/Users/test/blender_git/blender/../lib/windows_vc12/freetype/lib/freetype2ST.lib
--
- It may be due to temporary errors in the code, but in our case with a 
full GUI build (only way working for us atm), 2 modules fails to compile 
with cmake since about 1 week. Buildbots however seems to be ok?

Am 20/12/2015 um 19:57 schrieb Sergey Sharybin:
> As for the issues with default config on msvc+cmake -- i never really ad
> issues, it always working "out-of-the-box" for me and likely for other
> active developers. However, we can't _always_ guarantee latest Git is
> always compilable, it's possible to have occasional compilation errors. If
> it's something bigger for you -- please do a fuller report here in the ML
> (in a separate thread tho!). Such issues are not something which is caused
> by the build system and should be reviewed anyway and separately.
>
> As for the release-like configuration -- here are the points:
>
> - Default configuration _must_ be identical on all platforms
> - Some of the features requires 3rd party libraries
> - We can only have pre-compiled libraries for WIndows and OSX, for Linux
> one is doomed to either use library from the repository or compile himself
> (which isn't always trivial)
>
> So for the default configuration we prefer to have configuration which does
> not require some obscure libraries.
>
> On another hand, however, in GNU-like environment it's simple to do full
> build:
>
>make full  # invoke from the sources root directory
>
> Perhaps we can have something similar on Windows? .bat script maybe?
>
> Switching branches is a weird thing. I've got both SCons and CMake failing
> at some points. This seems to be much better with latest versions of CMake
> tho. And yeah, you don't really need to force full-cmake regeneration after
> changing the branch. For the compilation you can simply invoke building
> command (msbuild or name, depending on the generator).
>
> So all in all mentioned issues seems something what we can address and not
> really caused by the building system on it's own. But that's for the
> feedback :)
>
>
>
>
> On Sun, Dec 20, 2015 at 11:22 PM, Antony Riakiotakis <kal...@gmail.com>
> wrote:
>
>> You don't need to open visual studio. You can just use nmake from
>> command line. What I personally do is have a nice batch file to do the
>> job for me. It only works from a developer command prompt for visual
>> studio. Here are its contents:
>>
>> cd c:\src\blender
>> git checkout master
>> git pull --rebase
>> git submodule update --recursive --remote
>>
>> cd c:\src\blender-build
>> del CMakeCache.txt
>> cmake ..\blender -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release
>> -DWITH_RAYOPTIMIZATION=ON -DWITH_CODEC_FFMPEG=OFF -DWITH_PLAYER=ON
>> -DWITH_IMAGE_OPENEXR=ON -DWITH_OPENCOLLADA=ON -DWITH_CYCLES=ON
>> -DWITH_OPENMP=ON -DWITH_CYCLES_CUDA_BINARIES=OFF
>> -DWITH_MOD_OCEANSIM=ON -DWITH_FFTW3=ON -DWITH_LIBMV=ON
>> -DCMAKE_VERBOSE_MAKEFILE=OFF -DWITH_CYCLES_OSL=ON
>> -DWITH_IMAGE_REDCODE=OFF -DWITH_OPENSUBDIV=ON
>> -DWITH_PYTHON_INSTALL_NUMPY=OFF
>>
>> nmake install
>>
>> On 20/12/2015, matmenu <matm...@live.fr> wrote:
>>> Exactly what Antony said. Nobody will care what the building system is,
>>> if it works out of the box. At the moment, it works perfect on Linux,
>>> but it's still not working flawlessly on windows for me and other
>>> friends. We made a little list of things that don't work properly:
>>> - When using the cmake_full script, 2 modules fail to build in VS2013
>>> (blenderplayer-rela

Re: [Bf-committers] Get Cmake on-par with scons (docs, batch files and configuration scripts)

[matmenu]

By the way, I give the cmake command to get the same build as with the 
full cmake script:
cmake ..\blender -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release 
-DWITH_BUILDINFO=ON -DWITH_BULLET=ON -DWITH_CODEC_AVI=ON 
-DWITH_CODEC_FFMPEG=ON -DWITH_CODEC_SNDFILE=ON -DWITH_CYCLES=ON 
-DWITH_CYCLES_OSL=ON -DWITH_FFTW3=ON -DWITH_LIBMV=ON 
-DWITH_LIBMV_SCHUR_SPECIALIZATIONS=ON -DWITH_GAMEENGINE=ON 
-DWITH_COMPOSITOR=ON -DWITH_FREESTYLE=ON -DWITH_GHOST_XDND=ON 
-DWITH_IK_SOLVER=ON -DWITH_IK_ITASC=ON -DWITH_IMAGE_CINEON=ON 
-DWITH_IMAGE_DDS=ON -DWITH_IMAGE_FRAMESERVER=ON -DWITH_IMAGE_HDR=ON 
-DWITH_IMAGE_OPENEXR=ON -DWITH_IMAGE_OPENJPEG=ON -DWITH_IMAGE_REDCODE=ON 
-DWITH_IMAGE_TIFF=ON -DWITH_INPUT_NDOF=ON -DWITH_INTERNATIONAL=ON 
-DWITH_JACK=ON -DWITH_LZMA=ON -DWITH_LZO=ON -DWITH_MOD_BOOLEAN=ON 
-DWITH_MOD_FLUID=ON -DWITH_MOD_REMESH=ON -DWITH_MOD_SMOKE=ON 
-DWITH_MOD_OCEANSIM=ON -DWITH_AUDASPACE=ON -DWITH_OPENAL=ON 
-DWITH_OPENCOLLADA=ON -DWITH_OPENCOLORIO=ON -DWITH_OPENMP=ON 
-DWITH_PYTHON_INSTALL=ON -DWITH_RAYOPTIMIZATION=ON -DWITH_SDL=ON 
-DWITH_X11_XINPUT=ON -DWITH_X11_XF86VMODE=ON -DWITH_PLAYER=ON 
-DWITH_MEM_JEMALLOC=ON

Am 20/12/2015 um 20:59 schrieb matmenu:
> Ok so I start a new thread then following discussion regarding cmake
> switch. I know they are not due to cmake, it's just the cmake wiki-docs
> and scripts needs some tweeks and/or a batch file to bring it on scons
> level. At the moment, following the docs here
> http://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Windows/msvc/CMake
> we have many steps to follow, it breaks when switching branches or
> adding new functionnality unlike scons and the final build is missing
> many parts compared to official builds. Here are things that I think
> should be fixed before making the final switch.
>
> - Have a one line command for cmake just like for scons (python
> scons\scons.py -j 4) to build  a version of blender similar in
> functionality and build parameters to the official/buildbot ones. "make
> full" like on linux seems good.
> I tried Antony .bat file, but it doesn't find many libs and fails .
> Using the Cmake GUI or scons works. Error message are like those one:
> --
> -- Could NOT find JPEG (missing:  JPEG_LIBRARY JPEG_INCLUDE_DIR)
> -- Found Freetype:
> C:/Users/test/blender_git/blender/../lib/windows_vc12/freetype/lib/freetype2ST.lib
> --
> - It may be due to temporary errors in the code, but in our case with a
> full GUI build (only way working for us atm), 2 modules fails to compile
> with cmake since about 1 week. Buildbots however seems to be ok?
>
> Am 20/12/2015 um 19:57 schrieb Sergey Sharybin:
>> As for the issues with default config on msvc+cmake -- i never really ad
>> issues, it always working "out-of-the-box" for me and likely for other
>> active developers. However, we can't _always_ guarantee latest Git is
>> always compilable, it's possible to have occasional compilation errors. If
>> it's something bigger for you -- please do a fuller report here in the ML
>> (in a separate thread tho!). Such issues are not something which is caused
>> by the build system and should be reviewed anyway and separately.
>>
>> As for the release-like configuration -- here are the points:
>>
>> - Default configuration _must_ be identical on all platforms
>> - Some of the features requires 3rd party libraries
>> - We can only have pre-compiled libraries for WIndows and OSX, for Linux
>> one is doomed to either use library from the repository or compile himself
>> (which isn't always trivial)
>>
>> So for the default configuration we prefer to have configuration which does
>> not require some obscure libraries.
>>
>> On another hand, however, in GNU-like environment it's simple to do full
>> build:
>>
>> make full  # invoke from the sources root directory
>>
>> Perhaps we can have something similar on Windows? .bat script maybe?
>>
>> Switching branches is a weird thing. I've got both SCons and CMake failing
>> at some points. This seems to be much better with latest versions of CMake
>> tho. And yeah, you don't really need to force full-cmake regeneration after
>> changing the branch. For the compilation you can simply invoke building
>> command (msbuild or name, depending on the generator).
>>
>> So all in all mentioned issues seems something what we can address and not
>> really caused by the building system on it's own. But that's for the
>> feedback :)
>>
>>
>>
>>
>> On Sun, Dec 20, 2015 at 11:22 PM, Antony Riakiotakis <kal...@gmail.com>
>> wrote:
>>
>>> You don't need to open visual studio. You can just use nmake from
&

Re: [Bf-committers] Building with OpenVDB and OSL: a Boost case

[matmenu]

Hi Martijn and Kevin,
What heppened to this boost update? Python was updated, OpenGL 
requirements too, Windows XP is dropped, lets use 2.77 to move 
everything up for the upcoming development. OpenVDB is a really much 
needed addition for the simulation and volumetrics parts.
Regards,
Mat

Am 15/06/2015 um 09:43 schrieb Martijn Berger:
> Hi Kevin,
>
> I want to do a coordinated effort to upgrade the windows and OS X libraries
> after 2.75 is out the door.
> In addition to openvdb, Alembic might need to be included, also updates to
> llvm, boost, osl, oiio, and maybe other might be in order.
> (OpenSubDiv and PTex I am now sure about (for ptex we use OIIO i think ?))
>
> I am fine with bumping boost to 1.57 for windows / OS X but I am not sure
> about linux.
> For Linux It seems to me that it is to new and that we should try to keep
> boost 1.48 minimal requirement if we can.
> If that is unfeasible we should bump no higher then 1.54 for linux as then
> we have debian and ubuntu stable to consider.
>
> Martijn
>
>
>
>
>
> On Mon, Jun 15, 2015 at 4:09 AM, Kévin Dietrich 
> wrote:
>
>>
>> Hi all,
>>
>> I mail here because it can affect anyone who builds Blender, not just
>> the Cycles freaks ;)
>>
>> As a reminder, OpenVDB is making use of, and relies on libraries making
>> use of, C++ built-in run-time type information (RTTI). On the other
>> hand, LLVM (used by OSL) has a home brew version and does not want to
>> hear about the built-in one by default.
>>
>> The most straightforward way to address this is by building LLVM with
>> RTTI enabled, and build OSL accordingly.
>>
>> But that's maybe not a possibility (because of a lot of reasons), so
>> RTTI usage in VDB will need to be taken care of. By compiling Cycles
>> with both VDB and OSL it appears that most RTTI symbols that give issues
>> are in everyone's favorite library: Boost (I have version 1.54 here).
>> There's also one in TBB, but it can be avoided by disabling the use
>> exceptions there.
>>
>> Although patching OpenVDB so it compiles fine with RTTI disabled is a
>> no-brainer (~10 changes), we will need to upgrade boost to at least
>> version 1.57. Which should also comprise the fix for the Windows compile
>> issue raised by Antony.
>>
>> I've just installed it, and as far as I can tell, it seems to work fine
>> (_YMMV_). I've forked the openvdb repository, so to test things out you
>> can get my changes from there (https://github.com/diekev/openvdb [1]) in
>> the 'cycles_fixes' branch (it will also contain fixes for implicit float
>> conversions happening in the library, which make Cycles grumpy). So if
>> we go with boost 1.57, or above, and everything goes fine on all
>> platforms, I'll make a pull request.
>>
>> That's it from me for the moment,
>> Cheers,
>> Kévin.
>>
>>
>> Links:
>> --
>> [1] https://github.com/diekev/openvdb
>> ___
>> 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] Weekly Blender developer minutes - 13 December 2015

[matmenu]

Hi Martin,

Thank you, but I had to problems with CMake:

1) Visual Studio fails to build 2 things with cmake.full (see attached 
log). Blender starts anyway, so it's not so bad, but I would prefer 
everything to build without error. The default cmake config works 
without problem. I added this cmake script in cmakelists.txt:


# Load some macros.
include(build_files/cmake/macros.cmake)
include(build_files/cmake/blender_full.cmake)

Then I followed the instructions over there 
:http://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Windows/msvc/CMake 
. Is it wrong?


2) I couldn't either find where to put some custom CXX and CFlags, I put 
them manually in CMakeGUI everytime, but it's not optimal. With Scons, 
there is a part in the py script where I could put those parameters, 
which where then applied after each git pull --rebase automatically.
Maybe we can continue this on a forum or QA website to make the solution 
availaible to everyone?


Mat

Am 14/12/2015 um 08:16 schrieb Martijn Berger:

Hi Mat,

The official build is build using cmake with the settings as set in
build_files/cmake/config/blender_full.cmake

Martijn

On Sun, Dec 13, 2015 at 7:50 PM, matmenu <matm...@live.fr> wrote:


Hi Ton,

Thank you for keeping Scons for one release more. At the moment, on
windows, the home-made cmake build give very different results from the
buildbot/official ones. No Ocean modifier, etc... while the Scons builds
give a build with the exact same functionality and build parameters as
the official ones. Please make sure the windows cmake configuration is
the exact same as the official/buildbot ones to help us switch.

Regards,
Mat


Am 13/12/2015 um 16:28 schrieb Ton Roosendaal:

Hi all,

Again a short meeting today in irc.freenode.net #blendercoders!

1) Blender 2.77 targets

- Project page did not change much:
http://wiki.blender.org/index.php/Dev:Doc/Projects

- Brecht van Lommel posted OpenGL 2.1 recode tasks for volunteers to

pick up:

http://lists.blender.org/pipermail/bf-viewport/2015-December/75.html

- Kevin Dietrich picked up Smoke Volume GLSL code.

- Joshua Leung committed his GPencil work for 2.77
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.77/GPencil


2) Other projects

- Proposal: drop Scons for when we move to 2.8 (branches) but keep it

for the 2.7x series.

Thanks,

-Ton-


Ton Roosendaal  -  t...@blender.org   -   www.blender.org
Chairman Blender Foundation - Producer Blender Institute
Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands



___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

___
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


7>-- Build started: Project: blender, Configuration: Release x64 --
6>  buildinfo.c
7>  buildinfo.c
6>  buildinfoobj.vcxproj -> 
C:\Users\test\blender_git\bin\source\creator\buildinfoobj.dir\Release\buildinfoobj.lib
4> Creating library 
C:/Users/test/blender_git/bin/bin/Release/blenderplayer.lib and object 
C:/Users/test/blender_git/bin/bin/Release/blenderplayer.exp
4>ge_player_ghost.lib(GPG_ghost.obj) : error LNK2019: unresolved external 
symbol BVM_init referenced in function main
4>ge_player_ghost.lib(GPG_ghost.obj) : error LNK2019: unresolved external 
symbol BVM_free referenced in function main
4>bf_blenkernel.lib(blender.obj) : error LNK2001: unresolved external symbol 
BVM_free
4>bf_rna.lib(rna_texture_gen.obj) : error LNK2019: unresolved external symbol 
BVM_function_free referenced in function Texture_debug_nodes_graphviz_call
4>bf_rna.lib(rna_object_gen.obj) : error LNK2001: unresolved external symbol 
BVM_function_free
4>bf_blenkernel.lib(effect.obj) : error LNK2001: unresolved external symbol 
BVM_function_free
4>bf_blenkernel.lib(DerivedMesh.obj) : error LNK2001: unresolved external 
symbol BVM_function_free
4>bf_rna.lib(rna_texture_gen.obj) : error LNK2019: unresolved external symbol 
BVM_gen_texture_function referenced in function 
Texture_debug_nodes_graphviz_call
4>bf_rna.lib(rna_object_gen.obj) : error LNK2019: unresolved external symbol 
BVM_gen_modifier_function referenced in function rna_Object_debug_nodes_graphviz
4>bf_blenkernel.lib(DerivedMesh.obj) : error LNK2001: unresolved external 
symbol BVM_gen_modifier_function
4>bf_rna.lib(rna_blenvm_gen.obj) : error LNK2019: unresolved external symbol 
BVM_nodegraph_add_node referenced in function BVMNodeGraph_add_node_call
4>bf_rna.lib(rna_blenvm_gen.obj) : error LNK2019: unresolved external symbol 
BVM_nodegraph_get_input referenced in function BVMNodeGraph_get

Re: [Bf-committers] Weekly Blender developer minutes - 13 December 2015

[matmenu]

Hi Ton,

Thank you for keeping Scons for one release more. At the moment, on 
windows, the home-made cmake build give very different results from the 
buildbot/official ones. No Ocean modifier, etc... while the Scons builds 
give a build with the exact same functionality and build parameters as 
the official ones. Please make sure the windows cmake configuration is 
the exact same as the official/buildbot ones to help us switch.

Regards,
Mat


Am 13/12/2015 um 16:28 schrieb Ton Roosendaal:
> Hi all,
>
> Again a short meeting today in irc.freenode.net #blendercoders!
>
> 1) Blender 2.77 targets
>
> - Project page did not change much:
> http://wiki.blender.org/index.php/Dev:Doc/Projects
>
> - Brecht van Lommel posted OpenGL 2.1 recode tasks for volunteers to pick up:
> http://lists.blender.org/pipermail/bf-viewport/2015-December/75.html
>
> - Kevin Dietrich picked up Smoke Volume GLSL code.
>
> - Joshua Leung committed his GPencil work for 2.77
> http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.77/GPencil
>
>
> 2) Other projects
>
> - Proposal: drop Scons for when we move to 2.8 (branches) but keep it for the 
> 2.7x series.
>
> Thanks,
>
> -Ton-
>
> 
> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> Chairman Blender Foundation - Producer Blender Institute
> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>
>
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] proposal: OpenGL cleanup in master

[matmenu]

Very good idea but some questions:
The point to write in a master branch is to get a pretty sure 
integration and good testing. Couldn't this happen in the 2.8 branch if 
this one get's also a buildbot entry? 2.77 will most certainly be a long 
term release, I think it's better to let the whole current community 
profit from it. I for example program in the train on my way to work 
with an old eeePC with atom processor. Can't do any 3D work on it, but 
it's more than enough to program python addons.
If we are going to move to another OpenGL Version, why not take 4.4? All 
7 years (in 2016 for 2.77) old graphic card support it (AMD and Nvidia 
at least) https://de.wikipedia.org/wiki/ATI-Radeon-HD-5000-Serie and 
https://de.wikipedia.org/wiki/Nvidia-Geforce-400-Serie. I think 7 years 
old is good enough as it will most certainly stay like that for the 
whole 2.8 cycle so in the end, it will support 9 years old cards. 4 
years old Intel integrated cards all support 4.0 on windows, 4.1 on OS X 
https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units. 
3.3 on Linux but maybe ask the community how many people will have a 
more than 4 years old integrated Intel GPU on exclusively Linux (no dual 
boot) in 2016? It would be sad to loose potential for 10 casual users 
who will most certainly be able to do everything they want with 2.77.
Regards
Mat

Am 22/11/2015 um 03:11 schrieb Thomas Dinges:
> I fully support this proposal, it's time to get work done and stop
> worrying about ancient hardware.
>
> Am 22.11.2015 um 01:40 schrieb Mike Erwin:
>> Cool, glad for the enthusiasm!
>>
>> It might affect a few users on Windows or Linux, but all Mac OS 10.5 and
>> newer systems have GL 2.1 built in. Old low-end Macs might fall back to
>> software rendering for certain features but won't throw an error or catch
>> on fire.
>>
>> That set of Radeons Brecht listed support up to GL 3.3 so should all work
>> in Blender 2.8 too! I'm not as familiar with nVidia's stuff.
>>
>> Mike Erwin
>> musician, naturalist, pixel pusher, hacker extraordinaire
>>
>> On Sat, Nov 21, 2015 at 4:55 PM, Antony Riakiotakis 
>> wrote:
>>
>>> Yes, let's do it for 2.77. We are supposed to be able to break
>>> compatibility now since we are transitioning to 2.8. I know people are
>>> reluctant to drop compatibility because of the flak from a few users
>>> with old hardware but we won't be able to do anything if we keep
>>> postponing changes here.
>>>
>>> I suggest we make official final decision tomorrow in meeting. I hope
>>> there is no more time needed to consider things here, this has been
>>> discussed again and again during the last year and most people agree
>>> with the change.
>>>
>>> Then it's GHOST patch time and finally everyone can start refactoring
>>> code with shaders for fancy UI and display stuff :).
> ___
> 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] Some Ideas for a Blender Plugin System

[matmenu]

Hi all,
Am 03/11/2015 um 15:14 schrieb Sybren A. Stüvel:
> All in all I can see a few cons: 1) Blender will become more complex, 
> as not only its functionality needs to be maintained, but also the 
> "plumbing" required for the plugin system.2)  Development will become 
> more complex, as different permutations of loaded/unloaded plugins 
> have to be tested. 3) Mistakes in a C/C++ plugin can cause all kinds 
> of crashes of Blender itself. In contrast, an exception in a Python 
> script is relatively easy to catch & handle without sacrificing 
> Blender's stability. 4) Compilation of the code into libraries is 
> difficult, as it is very unlikely that all plugin developers will have 
> access to all OSses that Blender runs on. Sorry for this depressing 
> post, but I think we should discuss whether we want such a plugin 
> system at all, before diving into the specifics. Cheers, 
1) The point is to have a better use of the community ecosystem to get a 
faster and wider (for all the diferent publics Blender now has with 
animators, sculptors, 3D Games devs, architects, science, etc...) 
development. So I think everybody will be happy if functionnality 
integration is done better the old way (more reviews leading to more 
integration of community work). The core devs are here the best to 
decide what is the best for them (code and maintain a C API or review, 
commit and maintain master code)
2) Do you have a proof for this claim? I mean, modifier/operator 
combinations already lead to bugs, I don't see why having them as 
plugins/modules would make those problems arise more often?
3) That's true, but then the user decide to install this module, so he 
will report the bug to the original dev, making less work for the core 
ones. Only the problems coming from the core will be transfered, but 
that's already the case with the Python API, so it doesn't lead to more 
workload here, maybe even less or it will compensate for the overhead of 
maintaining the new API.
4) Also true, but we now have a buildbot that can make builds on demand 
for all supported OS. It could be used further by module/plugin devs and 
avoid having to ship a compiler with Blender.
Cheers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Some Ideas for a Blender Plugin System

[matmenu]

Hi,
What he said. Ask the Luxcore devs doing the integration with Blender. 
Of course, if you manage to create a proog like a very basic array 
modifier (only make duplicates of selected mesh every 1 BU on the x axis 
with the number given by the user, should be easy to program) that work 
as efficiently memory-wise and as fast as the one shipped with Blender 
and with the methode you discribed would be a great proof that C/C++ API 
is not needed.
Cheers,
Mat

Am 03/11/2015 um 14:50 schrieb Yury Baranov:
> Dalai, I think addon system has pretty much limited functionality.
> 1. No modifiers
> 2. No procedural objects
> 3. No animation controllers
> Every place where addon can't be used and where plugin needs to be used
> have a lot of calculations and a lot of "data sending/recieving/sending
> back" as a task. I think that's the main reason.
> For example, Sapling will be better as a interactive procedural object. But
> it's an addon, with all limitations and problems on the board.
> And of course need to mention that every plugin basically need 4 versions
> (because of its binary nature) - Linux, FreeBSD, Windows(32/64), MacOS X.
>
> 2015-11-03 16:14 GMT+03:00 Dalai Felinto :
>
>> Hi,
>>
>> I'm missing the main point here which would be, what is the advantage
>> of a C/C++ plugin system over the current Python addon interface?
>>
>> I'm currently developing an addon which relies on an external C++ SDK.
>> I got things working with ctypes and C API. It works pretty fine.
>>
>> Cheers,
>> Dalai
>> --
>> blendernetwork.org/dalai-felinto
>> www.dalaifelinto.com
>>
>>
>> 2015-11-03 10:59 GMT-02:00 Martin Felke :
>>> Hi, today i wrote down a couple of more thoughts regarding a plugin
>>> system. As said earlier, those serve only as discussion starting points
>>> and are not meant yet as design principles made out of cement. :)
>>>
>>> Fat VS Slim Core
>>> 
>>> - currently we have a fat core which contains all functionality
>>>as monolith
>>> - hard to extend and to maintain because it might be everything depends
>>>on everything else
>>> - idea: a slim, "bootloader like" core, which handles modules and
>>>plugins registration and deregistration and serves as API Hub (of
>>>existing modules)
>>> - modules are not standalone, they communicate via a central core API
>>>Hub so they need the core as well
>>> - this way the core can track module APIs and provide a fallback (as
>>>in exception handler) for missing code / functions (if module or
>>>plugin is not present)
>>>
>>> Modules VS Plugins
>>> --
>>> - need to distinguish between logical code separation (module) and
>>>"physical" separation (plugin, as in shared library or dll)
>>> - group existing core functionality to modules (like, an editor could
>>>be a module, or even a modifier)
>>> - base modules can be provided by "base" plugins, and extension modules
>>>by external plugins
>>> - plugins can provide parts of modules, entire modules or multiple
>>>modules (like nodes maybe, modifiers, new editors, or extensions to
>>>editors)
>>>
>>> Dependencies
>>> 
>>> - do we want to have inter-plugin dependencies ? For a slim core
>>>approach this might be necessary, if plugin A provides a module or
>>>part where plugin B 's code depends on
>>> - else base modules should be moved / kept in the core, so everyone has
>>>a minimum set of functionality without needing to use plugins
>>> - but in general, should plugin code only use Core API (the Hub ?)
>>>would be better than "directly" accessing other plugins code, because
>>>the core might provide the error fallback in case a plugin isnt
>>>present
>>>
>>> Plugin properties
>>> -
>>> - should be "hotpluggable", addable, removable during runtime
>>> - core needs to take care of disabling all related functionality when
>>>module is unloaded (closing editor, saving for example)
>>> - each plugin needs an unique identifier of some kind, and versioning
>>>info
>>> - if basis modules are in a plugin, this plugin needs to be flagged as
>>>important or official or so
>>> - plugins could be classified by their purpose, like provides Module X,
>>>extends Module Y, replaces Module Z, removes Module W
>>>
>>>
>>> ___
>>> 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

Re: [Bf-committers] Some Ideas for a Blender Plugin System

[matmenu]

Hi Martin,

Sounds really good and needed as reality showed that being GPL is not 
enough to make adding functionality easy. Looks also like all devs loose 
to much time reviewing, so c/c++ plugins are a really good solution to 
avoid so many modifiers die in the patch tracker or be limited to some 
custom builds like in past year. I hope you get some help to make it a 
reality!

Regards,
Mat

Am 01/11/2015 um 16:11 schrieb Martin Felke:
> Hi, today i was thinking a bit about possible approaches on how to
> add a C / C++ Plugin system to blender.
> This is a short (a bit unsorted) list of my thoughts and might serve as
> discussion start point perhaps.
>
> Blender Plugin System
> -
>   
> - Idea: Have a modularized approach, add C/C++ to core without
>modifying it later
> - track presence of modules and status (OK, Not Functional, Changed)
> - store Plugin Data separately from Blend (e.g. FM simulation /
>shard data), so core can start with basic blend only if plugin is
>absent can try to load plugin while loading data
>  
> - dynamic compilation of module sources via Python / CFFI or LLVM,
>as in OSL Nodes
> - access core api thru bpy or directly thru RNA or even DNA
> - source distribution of plugins is C / C++  + some py Wrapper
>for autocompile or binary distribution in case no compiler is present
> - plugins have certain structure and versions for all OS;
>Hash, Version, source, binaries
> - should be installable and activatable like addons
>   
> - pack CFFI and distutils to python distro of blender
> - windows fix: declspec, symbol export so linking will work
>   
> - plugin development addon: provide DNA / RNA headers
>(and C sources or precompiled stuff) + project generators
>for standard IDEs, to give a starting point for plugin devs
>   
> - core support: - Plugin Management system which handles plugins
>  - modify ID and Non-ID base structures to include
> info about plugin origin
>  - save,load data per plugin / chunked
> (and bundle differently together)
>  - plugin crash handler
> (so not the entire core goes down with a
> failing plugin)
>
> - plugins should expose py api too, so addons can build upon them too
> - plugin repos and updating / automatic compilation system
>(after update) ?
>
> ___
> 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] Data Structure Changes

[matmenu]

Hey,

Not sure as I'm not a c programmer, but string.c in 
blender/source/blender/blenlib/intern should be a good start? If not, 
maybe try to duplicate an object in Blender and look at the functions 
that are called there with a debug build?
A Core dev will answer much better than me.

Regards,
Mat

Am 01/11/2015 um 04:28 schrieb David Lewis:
> Hey Matt,
>
> Thanks for the advice a while back on what to edit within the code. I like
> the idea of making the name generation algorithm more efficient. We are
> doing a lot of things in class based on what is more efficient (consume
> less memory and less time). Where would I find the name generation
> algorithm?
>
> Thank you,
> David
>
> On Tue, Oct 13, 2015 at 4:34 PM, matmenu <matm...@live.fr> wrote:
>
>> Hey,
>>
>> To start small, maybe the name generation algorithm? When you (or a
>> script) create a new object in a scene containing thousands of them, it
>> start to become exponentially slow (object.0001 to object.1999 takes
>> 10sec but to object.3000 it takes 3 minutes for example) . If you can
>> come up with a better solution for this, it would be great. A bigger
>> step would be a solution to Blender slow downs in scene with many
>> objects. Modern hardware made it theoretically possible to manage such
>> scenes. But we are bound to workarounds at the moment (split in many
>> files and link, use particle instantiation up to blender's 10 000 000
>> limit which is far from hardware limitation, etc...). Especially in a
>> node based Blender, it can become an even bigger issue really fast.
>>
>> Regards,
>> Mat
>>
>> Am 13/10/2015 um 16:38 schrieb David Lewis:
>>> Hello all,
>>>
>>> I've been looking through some of the problems on the work board that
>> could
>>> be fixed or things that could be improved. While most look like problems
>>> that could be solved, off the top of anyone's head, is there a problem
>> that
>>> could be fixed or improved using a data structures, different sorting
>>> method, different searching method, etc...? Preferably using C/C++
>>>
>>> -David
>>> ___
>>> 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] Data Structure Changes

[matmenu]

Hey,

To start small, maybe the name generation algorithm? When you (or a 
script) create a new object in a scene containing thousands of them, it 
start to become exponentially slow (object.0001 to object.1999 takes 
10sec but to object.3000 it takes 3 minutes for example) . If you can 
come up with a better solution for this, it would be great. A bigger 
step would be a solution to Blender slow downs in scene with many 
objects. Modern hardware made it theoretically possible to manage such 
scenes. But we are bound to workarounds at the moment (split in many 
files and link, use particle instantiation up to blender's 10 000 000 
limit which is far from hardware limitation, etc...). Especially in a 
node based Blender, it can become an even bigger issue really fast.

Regards,
Mat

Am 13/10/2015 um 16:38 schrieb David Lewis:
> Hello all,
>
> I've been looking through some of the problems on the work board that could
> be fixed or things that could be improved. While most look like problems
> that could be solved, off the top of anyone's head, is there a problem that
> could be fixed or improved using a data structures, different sorting
> method, different searching method, etc...? Preferably using C/C++
>
> -David
> ___
> 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.8 - the Workflow release

[matmenu]

Hi Ton,
It sounds really good. It's good proof that you actually know what your 
community needs :) Just a small question about the year break: will it 
be done on the official GIT so that we can still follow and help with 
feedbacks on the branches we are interested in?
Regards,
Mat

Am 20/07/2015 um 15:49 schrieb Ton Roosendaal:
 Hi all,

 (also posted on http://code.blender.org)
 This is a proposal for work focus on blender.org for the coming year.

 I've written this because we keep missing bigger development targets - we 
 don't have enough time for larger projects. Instead too much time goes to 
 releases, bug fixing, reviews, maintenance and support topics. The bug and 
 patch tracker duties are keeping the best of our developers away from their 
 own targets.  As a result we then don't have time for design docs, for 
 planning, logs and in-depth sessions with the module teams, and have no time 
 for the artists who are involved to make sure we're well aligned and know 
 what to do. I think everyone has noticed that we're floating too much, things 
 are not clear. Where are we heading? Who does what, and how do we decide on 
 things?

 So - it's time to act and gather the troops to refocus and get back energy, 
 to maximize involvement from everyone who's active in blender.org and make 
 sure Blender can survive for many more years.

 - Blender 2.8 - Workflow release -

 Just like for 2.5, the proposal would be to take a bigger leap to a bigger 
 release by not releasing for a year. The 2.76 release then would be the last 
 'real' version we do until 2.80 somewhere in 2016.

 Obviously, for the crucial fixes and smaller (stable) features we can do 
 update releases 2.77, 2.78 and 2.79.

 Topics to finish for 2.8 could be:

 - UI work: wrap up Python configurability project, make Workflow based 
 configuring possible
Proof of concept: the stripped Blender 101 for high school kids.
 - Viewport project, including a PBR quality engine/editor that could replace 
 BI and GE render.
 - A better designed integration of physics simulation in Blender
 - Invite the GE team to rethink game logic editing, to use viewport and new 
 physics
 - Don't add the half finished Gooseberry targets but take the time needed to 
 code it well:
  Particle nodes, hair nodes, simulation nodes, modifier nodes...
 - Asset managing and browsing, linking, references, external files in general.
 - Integration in non Blender pipelines.

 Practical considerations:

 - Move development to special 2.8 branch(es)
 - Module teams are empowered to cleanup quite radically and get rid of legacy 
 code.
 - The 2.8 series is allowed to be not 100% compatible with 2.7x. (Physics, 
 particles, games).
 - Spend time on organizing ourselves better, agreed designs should lead to 
 more empowerment.

 And some core principles to agree on:

 - We reconfirm and where needed update the 2.5 spec docs.
 - Stick to existing Blender data structures and code design for as much as 
 possible.
 - Make Blender ready to survive until 2020, but...
  ... start collecting the list of bigger redesign issues we need to for a 
 3.0 project
 - Bring back the fun in Blender coding! :)

 The code.blender.org article for the roadmap of 2014-2015 is still valid in 
 my opinion. We just need to take a break of 9-12 months now, to make it work 
 for real.
 Blender 2.8 Workflow Sprint

 In the coming months we can discuss and review the plans and make sure we're 
 100% aligned on the 2.8 targets and for other work during the coming years. 
 We should also meet and have good feedback sessions on it. So I propose to 
 use the Blender Conference in October as a deadline, and organize a workshop 
 in the week before.

 - Four days of workshops and design sessions, in the week before Blender 
 Conference.
 - Travel and hotel covered for by BF (and Dev Fund, or a new fund raiser?)
 - We should try to get someone from every (active, involved) module team on 
 board. Also key user/contributors have to be on board. But it's also more 
 efficient to keep it compact.
 - Proposal: we do this invitation-only: First we invite the 5 most active 
 contributors of past years. Together they then invite persons more, until we 
 have 12 (?) people.
 - Sprint sessions can be in parallel too - UI, Viewport, Physics, etc. Let's 
 make it public as good as possible.
 - The Sprint results get presented and reviewed during further on sessions 
 during the Blender Conference.

 Seven years ago, back in 2008, we also took a break of over a year, to get 
 the 2.5 project started up. It was a very exciting period where a lot of new 
 things were possible and could happen, even though we didn't finish 
 everything... it gave us quite a solid foundation to build on, attracting a 
 lot of new developers and great features.
 I realize we have to realistic now, not everything will possible. But we also 
 shouldn't stop dreaming up a good future for Blender. Let's take a break from 
 our 

Re: [Bf-committers] boost update for OpenVDB on Windows

[matmenu]

Hi Antony,

Thanks a lot for working toward OpenVDB on Windows. From a user POV, 
OpenVDB is really helpfull as a mesher, as a memory optimiser (cache for 
smoke, water simulation, 3D scan visualisation, etc...). It also speedup 
Cycles rendering for smoke as Kevin showed and will certainly help 
Sergey toward it's goal of reducing memory footprint.
The community is working on it since pretty long (see this 2 years ago 
https://developer.blender.org/T35565 , was already working good). I 
think the community would be really happy if you don't use this nice 
work only for Gooseberry and then grab it again for some more years, but 
instead make it available to the users. I can assure you you will make 
many people happy.

Regards

on 12/06/2015 11:25, Antony Riakiotakis wrote :
 Hi, yesterday I was trying to build OpenVDB for windows but stumbled
 on an issue during compilation that is relevant to this bug in boost:

 https://svn.boost.org/trac/boost/ticket/9332

 Looks like issue is fixed in newer versions. Is it possible to upgrade
 to new boost at some point for windows? I know that it will be a
 hassle so I'd say only do this if we are going to support OpenVDB for
 sure in the future.
 ___
 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] General purpose icons for Blender Addons?

[matmenu]

Good Idea, but better would be custom icons. As you said, every addon 
has it's own need. Using one icon for different purpose is really 
disturbing for the user. I can't believe we have volumetrics and SSS and 
can't load an external png file for custom icons in 2015.

Le 08/05/2015 17:00, Ines Almeida a écrit :
 I believe this is totally worth discussion too :)

 My comments:
 - WARN (in addition to INFO and ERROR)  - seems good, though I would
 associate the yellow triangle we already have with 'WARN' and something
 more red with 'ERROR'
 - RESET (Reset to defaults)  - is FILE_REFRESH not good for this?
 - DOCUMENT (manual/wiki/online doc...) - what about URL ? there are also
 multiple icons for file types (eg text)
 - DOWNLOAD and UPLOAD seem important to me as well
 - all the others I don't have a strong opinion pro or against

 ---
 Inês Almeida / brita_
 ___
 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