Re: [Bf-committers] Making C++11 required for blender2.8 branch

[Antony Riakiotakis]

Hi Sergey,

I wrote what I (and others, judging from Howard's link) honestly thought
would be good practice. I do not count myself as C++feature-happy but these
features I found extremely helpful in my work and I use them quite often. I
can give workarounds for the issues you mentioned but it doesn't matter: I
am not contributing to the project anymore, others do, so feel free to
adopt whatever makes you feel safer and more comfortable.


On 4 October 2016 at 18:24, Howard Trickey  wrote:

> I agree with pretty much everything Sergey says. Where I work there is a
> coding style guide that restricts usage of some C++ languages features.
> As its preamble states, "As every C++ programmer knows, the language
> has many powerful features, but this power brings with it complexity,
> which in turn can make code more bug-prone and harder to read and
> maintain."
>
> Not suggesting we follow this guide, but reproducing it here so that others
> might read (if interested) some arguments pro and con various restrictions:
>
> https://google.github.io/styleguide/cppguide.html
>
>
>
> On Tue, Oct 4, 2016 at 10:44 AM Sergey Sharybin 
> wrote:
>
> > let's state the obvious: Blender's core is and will be a pure C.
> >
> > That being said, i'm not buying all this discussions about "a reason to
> > prefer C++ over C". Choise over C as a core is something you should just
> > leave with.
> >
> > I'm also not buying statements like "standard way of doing FOO in C++".
> > Shall we then drop our hash tables in favor of STLs even tho we know STL
> > implementation isn't really great?
> >
> > If we go deeper inside technical aspects of data ownership, it's all
> owned
> > by a Blender's core side, meaning it's all C. This should close all the
> > discussion of proper resource management in C++.
> >
> > I'm not sure what pollution of global scope here is. Static function is
> not
> > living in the global scope.
> >
> > Benefit of NOT using lambdas is that you (a) have a proper meaningful
> name
> > (b) can write proper documentation of what's happening (c) makes diffs
> more
> > clear.
> >
> > Surely if it's one single case of lambda things aren't getting that
> messy,
> > but this things goes out of control real quick and all of a sudden you
> have
> > function where you pass 4 lambdas 10 LOC each. And then all a sudden you
> > end up adding an explicit comment what that lambda is doing instead of
> just
> > using function with a descriptive name. As a side effect, your function
> > call becomes 3 displays long.
> >
> > Going into such situation is something we MUST to forbid.
> >
> > As for limiting the amount of features. Not all of the new stuff from new
> > language standards helps readability, some of them even defeats overall
> > Blender design. We have to come to a reasonable subset of things which
> > lives seamlessly within the Blender design.
> >
> > On Tue, Oct 4, 2016 at 4:12 PM, Jörg Müller  wrote:
> >
> > > Hello everyone,
> > >
> > > I'm a bit startled about the whole discussion about which features to
> > > allow and not allow. To me it's strange to have those restrictions in
> > > the first place and some of the comments sound like: yeah, let's allow
> > > the while loop, but not for loops, you can do the same thing with a
> > > while loop anyway. We also don't strictly allow/disallow features of
> > > Python, C or older C++ versions. There are always arguments for and
> > > against features, but even goto has some valid use cases (eg. error
> > > handling where else you would have horribly nested if/else
> combinations)
> > > and after all the designers of C++11 had good reasons for the
> > > changes/additions. Therefore I think everything should be allowed
> except
> > > for reasons such as compilers/platforms we support, but that don't
> > > support specific features, or similar limitations. Everything else can
> > > go into coding guidelines (like: don't use goto and globals) and be
> > > taked care of with code reviews, otherwise this might be another reason
> > > to scare away contributors.
> > >
> > > Cheers,
> > > Jörg
> > >
> > > On 2016-10-04 11:15, Sergey Sharybin wrote:
> > > > Hi,
> > > >
> > > > = Summary =
> > > >
> > > > I would like to propose to switch to C++11 in blender2.8 branch.
> > > >
> > > > Such a bump was already discussed in the past, but i want to give it
> a
> > > real
> > > > pus forward now.
> > > >
> > > > = Why do we need C++11 =
> > > >
> > > > There are various aspects why we want C++11. Here is just couple of
> > > > examples from own areas i meaintain.
> > > >
> > > > == Dependency graph ==
> > > >
> > > > I would like to kick old depednency graph out from 2.8 branch, so we
> > > > wouldn't need to worry about whether particular feature is compatible
> > > with
> > > > old depsgraph design or not. This would help laying down design and
> > > > implementation for all the node-based and local-overrides features we

Re: [Bf-committers] search specific commit on developer.blender.org

[Antony Riakiotakis]

Why not download the git repository locally and use

git show ?

On 23 June 2016 at 14:14, hewi jupama  wrote:

> Hey all,
>
>
> Is there a way to find a specific commit, e.g.
>
>
> "dccf5afbe"
>
>
> on the developer.blender.org site (without having to scroll through
> hundreds of commit messages to find that specific one again)
>
>
> I can't seem to figure this out
>
>
> thanks for your time :)
>
>
> 
> From: bf-committers-boun...@blender.org 
> on behalf of bf-committers-requ...@blender.org <
> bf-committers-requ...@blender.org>
> Sent: 22 June 2016 10:00
> To: bf-committers@blender.org
> Subject: Bf-committers Digest, Vol 143, Issue 15
>
> Send Bf-committers mailing list submissions to
> bf-committers@blender.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.blender.org/mailman/listinfo/bf-committers
> Bf-committers Info Page - Blender<
> https://lists.blender.org/mailman/listinfo/bf-committers>
> lists.blender.org
> Your email address: Your name (optional): You may enter a privacy password
> below. This provides only mild security, but should prevent others from
> messing with ...
>
>
>
> or, via email, send a message with subject or body 'help' to
> bf-committers-requ...@blender.org
>
> You can reach the person managing the list at
> bf-committers-ow...@blender.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bf-committers digest..."
>
>
> Today's Topics:
>
>1. Blender can't do hair because of this bug
>   (Daniel Salazar - patazstudio.com)
>2. Re: Blender can't do hair because of this bug (Campbell Barton)
>3. Re: Blender can't do hair because of this bug
>   (Daniel Salazar - patazstudio.com)
>
>
> --
>
> Message: 1
> Date: Tue, 21 Jun 2016 18:11:44 -0600
> From: "Daniel Salazar - patazstudio.com" 
> Subject: [Bf-committers] Blender can't do hair because of this bug
> To: bf-blender developers 
> Message-ID:
> <
> cabddwp9ypuqtrgq-_ry-szbkfq2qn2p_yxselqgf-xkxxhc...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi all, this bug has been going on for quite a while apparently and it
> prevents hair combing to work at all since it gets corrupted on
> render.
>
> https://developer.blender.org/T48658
>
> For me this bug has delayed my deadline for 2 weeks now and it's hard
> to believe the same bug is not giving problems to many others.
>
> If someone could urgently fix it please.
>
> desperately yours,
>
> Daniel Salazar
>
>
> --
>
> Message: 2
> Date: Wed, 22 Jun 2016 12:39:45 +1000
> From: Campbell Barton 
> Subject: Re: [Bf-committers] Blender can't do hair because of this bug
> To: bf-blender developers 
> Message-ID:
> <
> caecf3nxi93gkkg8lpbt9apcn5qp00o+ko-n1wbvvdarq0u2...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> It looks like Cycles fails to set the particle system back to its
> 'preview' state because G.is_rendering is being checked in particle
> system internals.
> Uploaded a diff that fixes the issue, though it may be better to keep
> the patch smaller & more localized.
> https://developer.blender.org/D2065
>
> On Wed, Jun 22, 2016 at 10:11 AM, Daniel Salazar - patazstudio.com
>  wrote:
> > Hi all, this bug has been going on for quite a while apparently and it
> > prevents hair combing to work at all since it gets corrupted on
> > render.
> >
> > https://developer.blender.org/T48658
> >
> > For me this bug has delayed my deadline for 2 weeks now and it's hard
> > to believe the same bug is not giving problems to many others.
> >
> > If someone could urgently fix it please.
> >
> > desperately yours,
> >
> > Daniel Salazar
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
>
>
>
> --
> - Campbell
>
>
> --
>
> Message: 3
> Date: Tue, 21 Jun 2016 22:04:32 -0600
> From: "Daniel Salazar - patazstudio.com" 
> Subject: Re: [Bf-committers] Blender can't do hair because of this bug
> To: bf-blender developers 
> Message-ID:
> 

[Bf-committers] Virtual Environments and Advanced Interfaces

[Antony Riakiotakis]

A friend of mine sent this my way, it's a VR interface-oriented conference
on university of Westminster. Maybe some people might want to participate
with papers or attend, so posting the link here.

https://sites.google.com/a/my.westminster.ac.uk/veai-2016/

It's a bit too close to submission deadline unfortunately (that's Greeks
for you), but probably someone might have something they want to present
ready.

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

Re: [Bf-committers] missing scripts in addon folder

[Antony Riakiotakis]

In a sub-repository. So you also need "git submodule foreach git pull" or
so to get them. I am assuming you have initialized sub-repositories
properly when you cloned blender. If not you need to do that. Check the
wiki for the full build procedure.
On 6 May 2016 02:42, "blubee blubeeme"  wrote:

> Building blender from git I get missing scripts file, see this image:
> http://i.imgur.com/ndITp10.png
>
> I use the git pull output:
> Resolving deltas: 100% (20301/20301), completed with 563 local objects.
> >From http://git.blender.org/blender
>4e4ff72..3045011  master -> origin/master
>fa1559e..6bb1879  alembic_basic_io -> origin/alembic_basic_io
>6c47849..fa21019  asset-engine -> origin/asset-engine
>266d99e..f4e4575  asset-experiments -> origin/asset-experiments
>  * [new branch]  blender2.8 -> origin/blender2.8
>770f74e..da2a8cd  cycles_hair_bvh -> origin/cycles_hair_bvh
>c2a5f95..a6a8ff1  id-remap   -> origin/id-remap
>6fddcc0..3cbb9c0  temp_widgets_update_tagging ->
> origin/temp_widgets_update_tagging
>255fa35..f9f34b5  wiggly-widgets -> origin/wiggly-widgets
> First, rewinding head to replay your work on top of it...
> Fast-forwarded master to 304501193be6fe1bedd19e819841a3a5363a79ef.
>
> Where are the default scripts?
>
> Best,
> Owen
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] missing scripts in addon folder

[Antony Riakiotakis]

Also make sure you make install to install the scripts too when building.
On 6 May 2016 08:48, kal...@gmail.com wrote:

In a sub-repository. So you also need "git submodule foreach git pull" or
so to get them. I am assuming you have initialized sub-repositories
properly when you cloned blender. If not you need to do that. Check the
wiki for the full build procedure.
On 6 May 2016 02:42, "blubee blubeeme"  wrote:

Building blender from git I get missing scripts file, see this image:
http://i.imgur.com/ndITp10.png

I use the git pull output:
Resolving deltas: 100% (20301/20301), completed with 563 local objects.
>From http://git.blender.org/blender
   4e4ff72..3045011  master -> origin/master
   fa1559e..6bb1879  alembic_basic_io -> origin/alembic_basic_io
   6c47849..fa21019  asset-engine -> origin/asset-engine
   266d99e..f4e4575  asset-experiments -> origin/asset-experiments
 * [new branch]  blender2.8 -> origin/blender2.8
   770f74e..da2a8cd  cycles_hair_bvh -> origin/cycles_hair_bvh
   c2a5f95..a6a8ff1  id-remap   -> origin/id-remap
   6fddcc0..3cbb9c0  temp_widgets_update_tagging ->
origin/temp_widgets_update_tagging
   255fa35..f9f34b5  wiggly-widgets -> origin/wiggly-widgets
First, rewinding head to replay your work on top of it...
Fast-forwarded master to 304501193be6fe1bedd19e819841a3a5363a79ef.

Where are the default scripts?

Best,
Owen
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] [Bf-Committers] [GSoC] Project P-BVH enhanced vertex painting

[Antony Riakiotakis]

Jacob, since you are not mentoring any students, and in fact not coding for
our C codebase, I would strongly suggest you refrain from giving feedback
and asking questions in the GSOC threads. In fact your attitude is -very-
close to spamming. Please stop.

Nathan, I would be glad to review any proposals you make. Note that we do
have a PBVH system in blender sculpting already and ideally we would like
to reuse some code and even allow vertex painting and/or sculpting at the
same time. There are some complications since our vertex painting code is
polygon based and sculpting is vertex based, but hopefully we can adapt the
code to handle both.


On 16 March 2016 at 07:39, Jacob Merrill  wrote:

> here is the mouse over magic to get the correct projection to cast the ray
>
>
> https://github.com/jesterKing/blender/blob/master/blender/release/scripts/templates_py/operator_modal_view3d_raycast.py
>
> Note* this is not the BVH flavored ray - it's just a example of the math to
> cast the ray youll need to cast inside the BVHTree
> instead *
>
> On Tue, Mar 15, 2016 at 10:25 PM, Jacob Merrill <
> blueprintrand...@gmail.com>
> wrote:
>
> > https://www.youtube.com/watch?v=K-MLpEmVgT8
> >
> > I build the tree on init -> then I use a hitpoint provided by the game
> > engine physics, but I think you will want to use the camera projection
> and
> > the mouse x,y to build the raycast, from there you can get all units in a
> > radius, you can then get the distance from the hitpoint to do the color
> > based on a multiplier
> >
> > https://www.youtube.com/watch?v=K-MLpEmVgT8
> >
> >
> > On Tue, Mar 15, 2016 at 10:20 PM, Jacob Merrill <
> > blueprintrand...@gmail.com> wrote:
> >
> >> I have used bvh accelerated raycast via Python to do fx in game in the
> >> game engine, and I have also used kdtree,
> >>
> >> It's fairly simple, and a great idea, would it be in Python, or C etc?
> If
> >> it is python I can help with that.
> >> On Mar 15, 2016 10:16 PM, "Nathan Vollmer"  wrote:
> >>
> >>> Hi everyone!
> >>>
> >>> My name's Nate Vollmer, and I'm a student at Idaho State University
> >>> interested in computer graphics. (One of my projects last semester:
> >>> http://www2.cose.isu.edu/~bitinat2/RayTracer/)
> >>>
> >>> I've written a draft for Blender's GSoC realizing the BVH vertex/weight
> >>> suggested idea, and was wondering if I could get some feedback/tips on
> my
> >>> proposal. Vertex painting is a very important feature for character
> >>> riggers, and I'd like to make it as convenient and efficient as
> possible.
> >>>
> >>> I appreciate all the help!
> >>> -NateVB
> >>> ___
> >>> 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] Bring multiple objects to edit mode

[Antony Riakiotakis]

Hey guys, just hopping by to drop my 2c.

I would be very interested to know how this works in other applications. In
my current work I already see some issues with the multi-editing such as:

* It's not apparent where new geometry gets added to (especially new
geometry, not attached to any existing mesh island). What happens when
geometry from two meshes is joined? This often leads to the following
approach:
* Treat all separate mesh islands as separate objects on edit mode exit.
This is quite different from the way blender works.  Most code written
assumes one object is being edited. It would be probably trivial to just
add a loop over all objects if there were clear boundaries between objects.
As discussed above this is not the issue, which means quite a lot of
refactoring.
* Treating all mesh islands separately can mess up with a lot of
assumptions about notification and dependency granularity. Those issues are
not unsolvable but they are not trivial to deal with either.

It's not impossible (nothing is), but I guess some answers would be needed
before such an approach is even explored by anyone (not me :p).

On 21 February 2016 at 19:03, David Fenner  wrote:

> For the moment I don't think we need advanced features for multi edit mode.
> Maybe support could start only for transform operations (with soft
> selection too). That would be quite a nice upgrade for the moment.
>
> El domingo, 21 de febrero de 2016, Joshua Leung 
> escribió:
>
> > IIRC, there are quite a few technical hurdles in many cases.
> >
> > * Pose Mode - ALL the tools assume that they can fetch the pose and/or
> > selected + editable bones off the active object
> > * All Edit Modes - Again, these assume a direct correspondence between
> > "active object" (specifically, ob->data) and the geometry they are
> editing.
> >
> >
> > In a way, that's also why for a long time we didn't even have any sort of
> > multi-edit for properties...
> >
> > On Sun, Feb 21, 2016 at 4:25 PM, Bassam Kurdali  > > wrote:
> >
> > > Multi Edit (and multi pose) would be amazing. Is there a real technical
> > > reason it can't be done currently? Or is it a matter of design,or
> > > risking new bugs, etc.?
> > > There's so many reasons a user would want this.
> > >
> > > On Sat, 2016-02-20 at 13:11 +0100, Doeke Wartena wrote:
> > > > yeah I mentioned MultiEdit in the OP. But if you have animations on
> > > > multiple objects and you multi edit them then the animations break.
> > > > Also it
> > > > duplicates the objects, which can be very heavy in large complex
> > > > scenes.
> > > > MultiEdit is created with a nice goal in mind but it's clearly not
> > > > the
> > > > proper way for a multi edit implementation.
> > > >
> > > > 2016-02-18 21:01 GMT+01:00 Yury Baranov  > >:
> > > >
> > > > > Actually, there is MultiEdit addon for that. Check it out. You can
> > > > > participate in development if you want.
> > > > >
> > > > >
> http://www.blenderartists.org/forum/showthread.php?339369-MultiEdit
> > > > > -version-5-Multiple-Objects-Editing
> > > > >
> > > > > 2016-02-18 22:15 GMT+03:00 Doeke Wartena  > >:
> > > > >
> > > > > > >
> > > > > > > I think blender could definitely benefit from allowing multiple
> > > > > > > objects
> > > > > > > in edit mode, but it should only
> > > > > > > work on selected objects, not on the whole scene.
> > > > > >
> > > > > >
> > > > > > true
> > > > > >
> > > > > > 2016-02-18 20:04 GMT+01:00 Jeffrey  > >:
> > > > > >
> > > > > > > I have experience modeling in Maya as well as blender, and I
> > > > > > > prefer the
> > > > > > > blender way because of Maya's obnoxious automatic mode
> > > > > > > switching when
> > > > > > > you accidentally select another object. I think blender could
> > > > > definitely
> > > > > > > benefit from allowing multiple objects in edit mode, but it
> > > > > > > should only
> > > > > > > work on selected objects, not on the whole scene. If it acts on
> > > > > > > the
> > > > > > > whole scene, it opens up armature edit mode, curves, metaballs,
> > > > > > > etc. It
> > > > > > > should only act on selected objects of the same type as the
> > > > > > > active
> > > > > > > object. If a couple meshes and a metaball are selected, the
> > > > > > > metaball
> > > > > > > will not go into edit mode if a mesh is active.
> > > > > > >
> > > > > > > I do not think you should be allowed to add an object to edit
> > > > > > > mode if
> > > > > > > you are already in edit mode; you would switch back to object,
> > > > > > > select
> > > > > > > the other, then switch back to edit. This avoids automatic mode
> > > > > > switching.
> > > > > > >
> > > > > > > Because edit mode ultimately modifies only the base mesh,
> > > > > > > modifiers are
> > > > > > > not an issue here. Likewise, shapekeys store vertex 

Re: [Bf-committers] GLSL for Mac

[Antony Riakiotakis]

Hi,

It's hard to say without seeing the exact error, but keep in mind that
blender also injects its own version and defines in the source when
autogenerating the shaders. This can lead to errors since the version
directive needs to be first in the source file. You might have to tweak the
default version in blender's C source itself, check for
gpu_shader_standard_defines in file gpu_shader.c

On 19 January 2016 at 20:14, CGLabs  wrote:

> Hello,
>
> I am trying to use a modified “gpu_shader_material.glsl” which has
> variables defined as uint types.
> The GLSL version that Blender is picking up is 120:
>
> #version 120
> #extension GL_ARB_draw_instanced: enable
> #extension GL_EXT_gpu_shader4: enable
> #define GPU_NVIDIA
> …
> …
> …
>
> I am getting syntax error for uint when the OpenGL runtime complies the
> dynamic source code.
> I am assuming that 120 correlates to OpenGL 1.20 and it seams that uint is
> not supported.
>
> Even more odd is that is I replace all uint by unsigned int it GLGS
> compiler is “happy” and works (despite the fact that OpenGL 1.20 states
> unsigned as reserved word).
>
> Does anyone know what is going on with GLSL’s  uint ?
>
> My machine: MacBook PRO with NVIDIA GeForce GT 750M 2048 MB
>
> Regards,
> Marcelo Varanda
>
>
> ___
> 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] Leftover todos, derivedmesh refactoring + ideas on viewport, pie menus

[Antony Riakiotakis]

Hi all,

I will not be coding anymore for the near and mid-term for blender so I
will post the status for a few work in progress things that I had been
doing and post a few ideas I had on the viewport in case others might want
to take them up. You can see it as a proposal if you like.
To avoid polluting everyone's emails with a wall of text, I've added a wiki
page:

http://wiki.blender.org/index.php/User:Psy-Fi/TODO

That's all, have fun everyone!
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Antony Riakiotakis]

sounds like WITH_INSTALL_PORTABLE might be OFF for some reason. Can you
check your CMakeCache to see the value?

On 27 December 2015 at 00:18, Yousef Harfoush  wrote:

> > Default installation directory is already bin folder from the root
> building
> > directory. It is possible you did some changes in your settings for which
> > you might want to remove CMake cache file and configure the build again
> > using default installation directory.
> >
> strange, i already delete the full folder each time!
>
> here is what i use for compilation:
> set
> PATH=E:\Code\compiler\mingw64\bin;E:\Code\compiler\mingw64\lib;C:\Program
> Files (x86)\CMake\bin;%PATH%
> cd E:\code\blender\build\mingw64_cmake
>
> del CMakeCache.txt
> cmake ..\..\blender -C../../userconfigs/x64.cmake -G "MinGW Makefiles"
>
> mingw32-make -j4 install
>
> and my x64.cmake is here:
> http://jpst.it/Ed9X
>
> > As for python35.dll, this is weird and itworked jut fine for me. It could
> > be caused by some other errors, so please pay more attention to the logs
> > and check if there's something else wrong there.
> >
>
> i try to compile and post the log
>
> thank you.
>
> Regards
> Yousef Harfoush
> ba...@msn.com
>
>
>
> > Date: Sat, 26 Dec 2015 23:45:37 +0500
> > From: sergey@gmail.com
> > To: bf-committers@blender.org
> > Subject: Re: [Bf-committers] Get Cmake on-par with scons (docs, batch
> files and configuration scripts)
> >
>
>
> > On Sat, Dec 26, 2015 at 11:38 PM, Yousef Harfoush  wrote:
> >
> > > it now builds OK, but CMake installs blender after compiling in
> > > "C:/Program Files/Blender"which requires elevated cmd and fails to
> install
> > > by default, i have to run the cmd with run as as admin, it would be
> nice if
> > > the default installation dir. is bin as in vc12.
> > >
> > > also python35.dll doesn't get copied by default, i did it manually and
> > > everything is okay.
> > > thank you.
> > >
> > >
> > > Regards
> > > Yousef Harfoush
> > > ba...@msn.com
> > >
> > >
> > >
> > > > Date: Sat, 26 Dec 2015 20:08:59 +0500
> > > > From: sergey@gmail.com
> > > > To: bf-committers@blender.org
> > > > Subject: Re: [Bf-committers] Get Cmake on-par with scons (docs, batch
> > > files and configuration scripts)
> > > >
> > > > Please remove all local changes ou did (especially with OpenAL and
> > > wrap_oal
> > > > libraries), update the sources to latets upstream and try compiling
> with
> > > > CMake again. It should now work all fine and smooth now.
> > > >
> > > > On Tue, Dec 22, 2015 at 8:45 PM, Yousef Harfoush 
> wrote:
> > > >
> > > > > > Seems a bit weird. Mind re-building in the debug mode and get the
> > > > > backtrace
> > > > > > again?
> > > > > i tried but it failed to compile on llvm i'll try to disable it and
> > > > > rebuild.
> > > > >
> > > > > > - Is the SCons build with the same exact mingw works fine?
> > > > > yes, and used in production.
> > > > >
> > > > > > - What's the OS you're using?
> > > > > windows 8.1, tried 10 too
> > > > >
> > > > > > - What's the mingw version you're using?
> > > > > > >> rubenvb-4.7.2-release
> > > > >
> > > > > Regards
> > > > > Yousef Harfoush
> > > > > ba...@msn.com
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ___
> > > > > Bf-committers mailing list
> > > > > Bf-committers@blender.org
> > > > > http://lists.blender.org/mailman/listinfo/bf-committers
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > With best regards, Sergey Sharybin
> > > > ___
> > > > Bf-committers mailing list
> > > > Bf-committers@blender.org
> > > > http://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> > >
> >
> >
> >
> > --
> > With best regards, Sergey Sharybin
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>
> ___
> 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] Get Cmake on-par with scons (docs, batch files and configuration scripts)

[Antony Riakiotakis]

Just commited fix for prefix - it should never install to program files for
MinGW now.

On 27 December 2015 at 11:45, Antony Riakiotakis <kal...@gmail.com> wrote:

> sounds like WITH_INSTALL_PORTABLE might be OFF for some reason. Can you
> check your CMakeCache to see the value?
>
> On 27 December 2015 at 00:18, Yousef Harfoush <ba...@msn.com> wrote:
>
>> > Default installation directory is already bin folder from the root
>> building
>> > directory. It is possible you did some changes in your settings for
>> which
>> > you might want to remove CMake cache file and configure the build again
>> > using default installation directory.
>> >
>> strange, i already delete the full folder each time!
>>
>> here is what i use for compilation:
>> set
>> PATH=E:\Code\compiler\mingw64\bin;E:\Code\compiler\mingw64\lib;C:\Program
>> Files (x86)\CMake\bin;%PATH%
>> cd E:\code\blender\build\mingw64_cmake
>>
>> del CMakeCache.txt
>> cmake ..\..\blender -C../../userconfigs/x64.cmake -G "MinGW Makefiles"
>>
>> mingw32-make -j4 install
>>
>> and my x64.cmake is here:
>> http://jpst.it/Ed9X
>>
>> > As for python35.dll, this is weird and itworked jut fine for me. It
>> could
>> > be caused by some other errors, so please pay more attention to the logs
>> > and check if there's something else wrong there.
>> >
>>
>> i try to compile and post the log
>>
>> thank you.
>>
>> Regards
>> Yousef Harfoush
>> ba...@msn.com
>>
>>
>>
>> > Date: Sat, 26 Dec 2015 23:45:37 +0500
>> > From: sergey@gmail.com
>> > To: bf-committers@blender.org
>> > Subject: Re: [Bf-committers] Get Cmake on-par with scons (docs, batch
>> files and configuration scripts)
>> >
>>
>>
>> > On Sat, Dec 26, 2015 at 11:38 PM, Yousef Harfoush <ba...@msn.com>
>> wrote:
>> >
>> > > it now builds OK, but CMake installs blender after compiling in
>> > > "C:/Program Files/Blender"which requires elevated cmd and fails to
>> install
>> > > by default, i have to run the cmd with run as as admin, it would be
>> nice if
>> > > the default installation dir. is bin as in vc12.
>> > >
>> > > also python35.dll doesn't get copied by default, i did it manually and
>> > > everything is okay.
>> > > thank you.
>> > >
>> > >
>> > > Regards
>> > > Yousef Harfoush
>> > > ba...@msn.com
>> > >
>> > >
>> > >
>> > > > Date: Sat, 26 Dec 2015 20:08:59 +0500
>> > > > From: sergey@gmail.com
>> > > > To: bf-committers@blender.org
>> > > > Subject: Re: [Bf-committers] Get Cmake on-par with scons (docs,
>> batch
>> > > files and configuration scripts)
>> > > >
>> > > > Please remove all local changes ou did (especially with OpenAL and
>> > > wrap_oal
>> > > > libraries), update the sources to latets upstream and try compiling
>> with
>> > > > CMake again. It should now work all fine and smooth now.
>> > > >
>> > > > On Tue, Dec 22, 2015 at 8:45 PM, Yousef Harfoush <ba...@msn.com>
>> wrote:
>> > > >
>> > > > > > Seems a bit weird. Mind re-building in the debug mode and get
>> the
>> > > > > backtrace
>> > > > > > again?
>> > > > > i tried but it failed to compile on llvm i'll try to disable it
>> and
>> > > > > rebuild.
>> > > > >
>> > > > > > - Is the SCons build with the same exact mingw works fine?
>> > > > > yes, and used in production.
>> > > > >
>> > > > > > - What's the OS you're using?
>> > > > > windows 8.1, tried 10 too
>> > > > >
>> > > > > > - What's the mingw version you're using?
>> > > > > > >> rubenvb-4.7.2-release
>> > > > >
>> > > > > Regards
>> > > > > Yousef Harfoush
>> > > > > ba...@msn.com
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > ___
>> > > > > Bf-committers mailing list
>> > > > > Bf-committers@blender.org
>> > > > > http://lists.blender.org/mailman/listinfo/bf-committers
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > With best regards, Sergey Sharybin
>> > > > ___
>> > > > Bf-committers mailing list
>> > > > Bf-committers@blender.org
>> > > > http://lists.blender.org/mailman/listinfo/bf-committers
>> > >
>> > > ___
>> > > Bf-committers mailing list
>> > > Bf-committers@blender.org
>> > > http://lists.blender.org/mailman/listinfo/bf-committers
>> > >
>> >
>> >
>> >
>> > --
>> > With best regards, Sergey Sharybin
>> > ___
>> > Bf-committers mailing list
>> > Bf-committers@blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-committers
>>
>> ___
>> 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] MinGW support

[Antony Riakiotakis]

Hi,

Status with openmp as far as I know is fine. The problem with MinGW is that
supporting a proper development environment requires installing visual
studio/Windows SDK anyway, so it sort of defeats the purpose of having an
"independent" compiler.

* MSVC is needed to compile CUDA binaries
* MSVC is needed to run a debug build, since python is lined against the
debug libraries of microsoft, not MinGW.
* Debugging threads is not so well/natively supported (since pthread
library of MinGW is built on top of win32 library)

Only positive thing from MinGW side as far as I know is faster cycles, but
it's been a while since I tested this. It may be better now with 2013
compiler?
I wouldn't want to spend any more time maintaining this, so if anyone wants
to take over (supposing we decide it is even worth it) be my guest.

On 26 December 2015 at 19:47, Sergey Sharybin  wrote:

> We can not advertise some sort of franken-compiler as an officially
> supported. Either the issues are solved in upstream or we don't consider
> compiler officially supported.
>
> On Sat, Dec 26, 2015 at 11:44 PM, Yousef Harfoush  wrote:
>
> > > Date: Sat, 26 Dec 2015 23:08:42 +0500
> > > From: sergey@gmail.com
> > > To: bf-committers@blender.org
> > > Subject: Re: [Bf-committers] MinGW support
> > >
> > > If we're going to keep supporting MinGW it should be latest official
> > > version. I remember we were having major issues with some system
> > libraries
> > > (mainly threading and OpenMP), so it makes sense to re-evaluate if
> those
> > > issues are solved form MinGW side before trying to support all the
> > > libraries we need.
> >
> > i use mingw 4.72 with added openmp libs from here:
> > http://tdm-gcc.tdragon.net/download
> > and threading works properly no crashes, at least in my workflow.
> >
> >
> > Regards
> > Yousef Harfoush
> > ba...@msn.com
> >
> >
> >
> >
> > >
> > > On Sat, Dec 26, 2015 at 10:38 PM, alekulyn  wrote:
> > >
> > > > I talked to psyfi over IRC around half a year ago and told him I'd
> like
> > > > to help with this.  There have been several complications along the
> > way,
> > > > such as which MinGW version we should use, rumors that clang was
> coming
> > > > into the picture, and general inactivity regarding anything MinGW.
> > > >
> > > > As for which MinGW version to use, my conversation with psyfi was
> > mainly
> > > > about adding libraries to the mingw64_gcc49 branch he started.  To
> that
> > > > end, I did compile some libraries with MinGW-W64 GCC 4.9, but I must
> > > > have deleted them some time ago.
> > > >
> > > > Anyway, like I told psyfi, I'm willing to help with this.  Just need
> to
> > > > know which MinGW version to use.
> > > >
> > > > On 12/26/2015 5:12 PM, Sergey Sharybin wrote:
> > > > > Hey everyone,
> > > > >
> > > > > There are some missing precompiled libraries (sndfile, opensubdiv,
> > OSL)
> > > > and
> > > > > some misng libraries update (python, SDL, OpenAL)  for MinGW.
> > > > >
> > > > > This makes MinGW builds quite diverged from the official builds
> > > > feature-set
> > > > > and lib-version wise, moving MinGW builds to the boundary where we
> > can't
> > > > > call it officially supported anymore.
> > > > >
> > > > > Additioanlly, svn:externals for mingw folders seems to be
> > misconfigured
> > > > now
> > > > > and needs clean up.
> > > > >
> > > > > Anyone to have a look and fix all those issues?
> > > > >
> > > >
> > > > ___
> > > > Bf-committers mailing list
> > > > Bf-committers@blender.org
> > > > http://lists.blender.org/mailman/listinfo/bf-committers
> > > >
> > >
> > >
> > >
> > > --
> > > With best regards, Sergey Sharybin
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
>
> --
> With best regards, Sergey Sharybin
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] SCons build system future

[Antony Riakiotakis]

ome 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
> manually
> >>>> 3)generate solutions, 4) open VS 5) switch from debug (default) to
> >>>> release 6) start the building process.
> >>> On Unix systems we have a convenience makefile that handles this
> >>> ('make' in the source dir to configure+build+install).
> >>> We could have a BAT file for Windows to do the equivalent steps.
> >>>
> >>>> - 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.
> >>> I've never heard of switching branches needing to delete cache,
> >>> What custom params are you having to set each time?
> >>>
> >>>> 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.
> >>> With the issues you run into, its best if we can try to redo and fix
> >> them.
> >>>> 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 <blen...@dingto.org> 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 mailing list
> >> Bf-committers@blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender Feature request for game artist

[Antony Riakiotakis]

Hi,

It's not hard to understand why island selection is only available in
face selection mode. In any other mode, the selection state would be
broken since if we select just one island's vertices edges, then
linked vertice/edges won't be selected.

What we could do is force face selection when invoking the operator,
which is not so nice though. Other alternative would be to introduce
island select mode in sync mode, which should use face selection in 3D
viewport.

Looks like what users might want is for selection in 3D viewport to
influence UV editor selection but not the inverse. So one should be
able to select stuff in UV editor independently, with the only
requirement that the corresponding vertex/face/edge is selected in 3D
editor.

Another approach is to have two sync modes, a soft one, working as
explained above, and a hard one, working as it works now.

On 20/12/2015, Dan  wrote:
> Hello,
>
> Sorry for emailing again. Not sure if my previous email got through or not.
> I just want to help support the development of blender by giving my
> feedback.
> I think currently Blenders UV unwrap and editor is lacking alot of features
> that i am used to using in Maya or Max.
>
> For example in blender sync mode you cant select UV islands. Instead you
> have to press a shortcut key , in my case.. i have first select a face then
> press Ctrl L .. every time i want to select a UV island. I feel if UV
> island select option was there in sync mode.. a lot of time can be saved.
> It should be a one click process.
>
> Looking forward to future updates in blender.
>
> On Sat, Dec 19, 2015 at 3:16 AM, Dan  wrote:
>
>> Hi there,
>>
>>
>> I posted questions about this on the blender artist technical help forum
>> but none were able to answer my question which led me to believe that the
>> feature doesn't exist in Blender. These features are commonly used in
>> Maya
>> and Max. Which i believe would help with the workflow.
>>
>> These are the feature i wish blender would have.
>>
>> Feature request 1
>>
>> http://blenderartists.org/forum/showthread.php?388054-How-to-Show-Tri-count-only-for-the-Objects-selected
>>
>> Showing Tri count for individual objects selected in Blender. For
>> example,
>> in the scene there are 3 objects in total. So blender shows Tri count for
>> all 3 objects.
>> I only want to see the Tri count for the two objects selected.
>>
>> Feature request 2
>>  To be able to turn off  sticky mode while in sync mode inside UV editor.
>> It seems silly to turn sync on and off .. just to select some vertex and
>> tweak it in UV editor. In maya i could tweak my UVs without affecting
>> other
>> uv parts and there is no need to turn sync on and off ... which saves a
>> lot
>> of time.
>>
>>
>> http://blenderartists.org/forum/showthread.php?388422-About-UV-editor-etc=2982899=#post2982899
>>
> ___
> 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

[Antony Riakiotakis]

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-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 <blen...@dingto.org> 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 mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] SCons build system future

[Antony Riakiotakis]

I haven't built with MinGW for a long time, but it used to work.
cmake/MinGW was how I was doing development on windows at some point.

On 20/12/2015, Yousef Harfoush  wrote:
> is there a way to build blender using cmake and mingw?
>
> i read
> http://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Windows/MinGW/CMake
> but no instruction on how to build, only how to deal wih repos.
>
>
>
> Regards
> Yousef Harfoush
> ba...@msn.com
>
>
>
>> Date: Sun, 20 Dec 2015 16:37:20 +0100
>> From: kal...@gmail.com
>> To: bf-committers@blender.org
>> Subject: Re: [Bf-committers] SCons build system future
>>
>> +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 mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes, November 29, 2015

[Antony Riakiotakis]

When we switch to core profile, legacy GL calls will not be supported
at all from the driver. To solve this, Martijn proposed to have a
deprecation mode for a few versions that would prohibit use of
deprecated functions from python (probably error out when accessing
them with a warning).


On 29/11/2015, Dalai Felinto  wrote:
> Hi,
> A small question regarding the OpenGL project:
>
>  > "Work now progresses on removing 'immediate mode' calls (glBegin,
> glEnd), and on defining how to use shaders everywhere"
>
> How does that affect Python addons? Can immediate mode still be used via
> bgl? Or it's not recommended (not guaranteed to work in all OSs)?
>
> Thanks,
> Dalai
> On Nov 29, 2015 14:02, "Ton Roosendaal"  wrote:
>
>> Hi all,
>>
>> Here are the (short) notes of today's meeting in irc.freenode.net
>> #blendercoders
>>
>> 1) Work on 2.77
>>
>> - Project page with planning:
>>   http://wiki.blender.org/index.php/Dev:Doc/Projects
>> (As agreed on, 2.77 has not been scheduled yet)
>>
>> - Bastien Montagne reports good progress on library referencing
>> improvements:
>>
>> http://code.blender.org/2015/11/test-build-live-reloading-relocating-of-libraries/
>> (Might go to 2.77 if testing goes well)
>>
>> 2) Other projects and 2.8 preparations
>>
>> - Migrating to OpenGL 2.1 has started.
>>
>> - We're now officially on 2.1 minimal! Meaning that the old 'extension'
>> (compatibility) API calls
>> are gone. Work now progresses on removing 'immediate mode' calls
>> (glBegin,
>> glEnd), and on defining
>> how to use shaders everywhere.
>>
>> - Mike Erwin will write (today!) a wiki page - to log and report on
>> OpenGL
>> work, also as dashboard to
>> give people insight what they can do to help. Code upgrading is fun work
>> for which a lot of people
>> can contribute. Check the wiki project page later today for the correct
>> page link.
>>
>> - If you want to get involved: join the coders IRC channel, or the
>> viewport list:
>> http://lists.blender.org/mailman/listinfo/bf-viewport
>>
>> - After the meeting, a group discussed key aspects of the work ahead...
>> viewport team members so-far:
>> Mike Erwin, Antony Ryakiotakis, Brecht van Lommel, Inez Almeida, Martijn
>> Berger. Thomas Dinges is
>> available to help. Jason Wilkins is inactive currently but welcome to
>> join!
>>
>> 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
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] essential information hiding -> +10 for Blender

[Antony Riakiotakis]

Hi,

Welcome to the world of software development. While we can indeed
improve our code documentation, there is no substitute for searching
if you plan to code, and searching for information takes a big chunk
of a programmers time in any case.

About static function use it's not meant for functions that no one can
see, but functions that are only visible in the same file. This is
useful to avoid name conflicts. For instance, with static functions,
you can have two different static "computeDerivedMesh" functions with
the same name on different modifier files without the compiler/linker
getting confused and throwing an error when you compile blender. I can
understand C can be confusing for beginners and while we can improve
our code quality in a few places, static vs non-static use is not one
of those places. So keep learning and you'll see that static use is
not so bad in blender.

For latest development news there are various ways to keep in touch:

* Subscribe to the bf-blender-cvs mailing list (for hardcore -
don't-want-to-miss-a-commit type of people)
* Check commits on https://developer.blender.org/diffusion/B/ or on
external sites such as https://www.miikahweb.com/en/blender/git-logs/
* If you have a git blender source checkout, use git log from your
blender source folder. You might have to git pull first to get the
latest version from the main repository. If you do use git pull, make
sure there are no edits to your source tree first.
* Check weekly development meeting news on this list

The migration is happening on master branch right now as posted on
this list. The commits have already started a week ago already.

And that's all...

On 26/11/2015, hewi jupama  wrote:
> All,
>
> I would be honoured to be able to follow the development and change from
> openGL 1 -> 2, but again I fail to find info on the developer page.  There
> is no branch, no project, no repository, is it actually happening?
>
> If there is anything at all that bugs me about Blender and it's evolution is
> that you alwasy have to dig and look and search and again and again have to
> look and look harder and investigate and search and ... pf ...
> repeat
>
> Anyway, so now, guess what, looking into the array modifier to try and make
> it a plugin, so I see all functions are static h, I thought static meant
> Seret Tfunction Athat Tnoone Icanever Csee?  anyway.  More research and
> digging and ...
>
> Never giving in
>
> KR
>
> Hewi
>
>
>
> 
> From: bf-committers-boun...@blender.org 
> on behalf of bf-committers-requ...@blender.org
> 
> Sent: 25 November 2015 11:00
> To: bf-committers@blender.org
> Subject: Bf-committers Digest, Vol 136, Issue 23
>
> Send Bf-committers mailing list submissions to
> bf-committers@blender.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.blender.org/mailman/listinfo/bf-committers
> or, via email, send a message with subject or body 'help' to
> bf-committers-requ...@blender.org
>
> You can reach the person managing the list at
> bf-committers-ow...@blender.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bf-committers digest..."
>
>
> Today's Topics:
>
>1. Locating and extracting UV-mapping (Rasmus Siljedahl)
>2. UDIM workflow for 2.8 (Kanishk Chouhan)
>3. Commit e6c58df74e1fe8e7921048bc145b6318322541f2 breaks debug
>   builds on windows-64 (Gaia Clary)
>4. Re: Commit e6c58df74e1fe8e7921048bc145b6318322541f2 breaks
>   debug builds on windows-64 (Gaia Clary)
>5. Re: fixed: Commit e6c58d... breaks debug builds on windows-64
>   (Gaia Clary)
>
>
> --
>
> Message: 1
> Date: Tue, 24 Nov 2015 16:46:07 +0100
> From: Rasmus Siljedahl 
> Subject: [Bf-committers] Locating and extracting UV-mapping
> To: bf-blender developers 
> Message-ID:
>
> 

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

[Antony Riakiotakis]

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 :).

On 21/11/2015, Brecht Van Lommel <brechtvanlom...@pandora.be> wrote:
> As I understand it, with OpenGL 2.1  the minimum requirements would be
> effectively:
>
> * NVidia Geforce FX, Gerforce 6 and newer (released in 2003)
> * AMD Radeon R600+, Radeon HD, and newer (released in 2006)
> * Intel HD graphics or newer (released in 2010), some older cards
> might still work on OS X and Linux
>
> Mainly users with older Intel GMA graphics would be affected. That
> sounds reasonable to me but we are raising the hardware bar for
> Blender 2.77 then, right?
>
> I totally support doing this in master. Doing OpenGL refactoring in
> big branches hasn't worked well in the past, better to do it
> incrementally. I can help with some refactoring and code review.
>
> On Sat, Nov 21, 2015 at 8:44 AM, Antony Riakiotakis <kal...@gmail.com>
> wrote:
>> You have my sword. And my axe. And my bow.
>> I could trickle some free time on this, though not terribly much
>> unfortunately.
>>
>> I definitely vote to do this on master/or current full dev branch (2.8
>> branch?) when that changes. The previous approach of dumping chunks of
>> code in a big branch that will code-rot as soon as time or energy
>> dries out just does not work for such a big project in my opinion. We
>> need an approach that will let us work on this incrementally.
>>
>> We should communicate well, with screams, on the street to
>> unsuspecting pedestrians and on the net to unsuspecting surfers, posts
>> on blender.org, in the manual and with ugly message boxes with bright
>> flashing red letters (OK, I admit that might be pushing it a little
>> bit), especially for the windows and mac people, that system
>> requirements are now raised to 2.1, and add the relevant checks and
>> warnings in GHOST to ensure that people who try to use blender without
>> it, cannot do so anymore. Current approach on Windows is just spawning
>> a warning messagebox. We can leave that in but also quit blender in
>> case it does not meet our requirements, and also expand to a similar
>> approach for other OSs.
>>
>> On 21/11/2015, Mike Erwin <significant@gmail.com> wrote:
>>> Hi devs,
>>>
>>> I was responding to something in bf-viewport but could use a wider set
>>> of
>>> people to either agree or put a stop to this madness before it's too
>>> late.
>>> :)
>>>
>>> I'd like to start basic GL cleanup in master ASAP. By this I mean set GL
>>> 2.1 as a baseline and convert all code that uses obsolete extensions to
>>> the
>>> functions/enums provided by GL itself. Much of this is simply deleting
>>> ARB
>>> or EXT, and removing checks for GL features that are guaranteed in 2.1.
>>> No
>>> new features, no major rewriting, just get the code up to spec and ready
>>> to
>>> branch for the bigger GL 3.2 upgrade.
>>>
>>> Staged migration of OpenGL:
>>> now --> GL 2.1 (all platforms, soon)
>>> --> 3.2 compatibility profile (Windows & Linux)
>>> --> 3.2 core profile (all platforms, in time for Blender 2.8)
>>>
>>> That final transition will be the most work. The first transition can be
>>> done NOW and doesn't involve any design really -- just a plan of what to
>>> remove/convert. Dropping support for GL 1.4, 1.5 and 2.0 in one swoop
>>> will
>>> let us clean up a lot of legacy crap without raising the hardware bar.
>>>
>>> Is anyone opposed to this? Anyone eager to help?
>>>
>>> Mike Erwin
>>> musician, naturalist, pixel pusher, hacker extraordinaire
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Antony Riakiotakis]

You have my sword. And my axe. And my bow.
I could trickle some free time on this, though not terribly much unfortunately.

I definitely vote to do this on master/or current full dev branch (2.8
branch?) when that changes. The previous approach of dumping chunks of
code in a big branch that will code-rot as soon as time or energy
dries out just does not work for such a big project in my opinion. We
need an approach that will let us work on this incrementally.

We should communicate well, with screams, on the street to
unsuspecting pedestrians and on the net to unsuspecting surfers, posts
on blender.org, in the manual and with ugly message boxes with bright
flashing red letters (OK, I admit that might be pushing it a little
bit), especially for the windows and mac people, that system
requirements are now raised to 2.1, and add the relevant checks and
warnings in GHOST to ensure that people who try to use blender without
it, cannot do so anymore. Current approach on Windows is just spawning
a warning messagebox. We can leave that in but also quit blender in
case it does not meet our requirements, and also expand to a similar
approach for other OSs.

On 21/11/2015, Mike Erwin  wrote:
> Hi devs,
>
> I was responding to something in bf-viewport but could use a wider set of
> people to either agree or put a stop to this madness before it's too late.
> :)
>
> I'd like to start basic GL cleanup in master ASAP. By this I mean set GL
> 2.1 as a baseline and convert all code that uses obsolete extensions to the
> functions/enums provided by GL itself. Much of this is simply deleting ARB
> or EXT, and removing checks for GL features that are guaranteed in 2.1. No
> new features, no major rewriting, just get the code up to spec and ready to
> branch for the bigger GL 3.2 upgrade.
>
> Staged migration of OpenGL:
> now --> GL 2.1 (all platforms, soon)
> --> 3.2 compatibility profile (Windows & Linux)
> --> 3.2 core profile (all platforms, in time for Blender 2.8)
>
> That final transition will be the most work. The first transition can be
> done NOW and doesn't involve any design really -- just a plan of what to
> remove/convert. Dropping support for GL 1.4, 1.5 and 2.0 in one swoop will
> let us clean up a lot of legacy crap without raising the hardware bar.
>
> Is anyone opposed to this? Anyone eager to help?
>
> Mike Erwin
> musician, naturalist, pixel pusher, hacker extraordinaire
> ___
> 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] Requirements list for the Fracture Modifier in Blender

[Antony Riakiotakis]

Because in OpenGL one vertex can only correspond to one unique set of
vertex attributes while in blender one vertex can have many different
data values per loop. Having data islands, allows OpenGL to detect and
reuse those vertices whose vertex attributes are shared across many
triangles.

On 26 September 2015 at 21:34, Jacob Merrill  wrote:
> I remember PsiFi stating the only reason the new viewport render code would
> not make a good game render had to do with these islands, but I never
> understood the why, can someone enlighten me as to what this means? what
> are data islands for?
> On Sep 26, 2015 11:26 AM, "Brecht Van Lommel" 
> wrote:
>
>> Could the mesh islands be implemented as a data layer, like an integer
>> island ID per vertex or face? Is there a reason they must be a core
>> part of the mesh like vertices, edges or faces?
>>
>> Making islands a fundamental part of a mesh like it would complicate
>> all mesh operators and modifiers, while a custom data layer would
>> ideally only require changes to the fracture modifier and the rigid
>> body system. It seems like that would simplify 1) a lot, though either
>> way you'll need significant changes to the rigid body system to
>> support such islands.
>>
>>
>> On Sat, Sep 26, 2015 at 7:32 PM, Kai Kostack  wrote:
>> > Hello folks,
>> >
>> > A few weeks ago I have announced that we would provide a requirements
>> list for the Fracture Modifier (FM) and here is it now. Please feel free to
>> comment or share your thoughts on it.
>> >
>> > http://kostackstudio.de/dl/docs/Requirements_List_FM.pdf
>> >
>> > -- Kai
>> >
>> >
>> > 1. Subgeometry system:
>> >
>> > Object shard management in the FM happens currently in form of shards
>> for fracturing, and mesh islands for simulation. Desirable would be an
>> integration of a mesh island concept (as fourth element in addition to
>> vertices, edges, faces) into Mesh, DerivedMesh and Bmesh / BMEditMesh, so
>> no special DNA structures like shard and mesh island would be necessary any
>> more. This would be a better integration into existing data structures.
>> >
>> > Shards should all be part of one single object, so that the depsgraph
>> doesn't need to manage thousands of individual objects. This would lead to
>> higher performance at cache playback and easier to handle by the user. Also
>> it wouldn't clutter the Blender database with ID blocks and would keep the
>> outliner clean.
>> >
>> > Mesh islands would have direct references to the vertices which build up
>> the shape of their rigid body. This is necessary for fast access when the
>> vertices need to be transformed after the simulation step has occurred to
>> update the visual render mesh.
>> >
>> >
>> > 2. Multi rigid body system:
>> >
>> > When we have multiple independent rigid bodies per object, each rigid
>> body shape can be constructed by the individual shard / mesh island it is
>> assigned to. “Multi rigid body” could become a new rigid body type and
>> should be the default. Single rigid bodies would be covered by just having
>> only one mesh island.
>> >
>> > However having two rigid body systems is not optimal. There would be a
>> mapping step necessary between regular rigid bodies and shard rigid bodies
>> across the simulation object group.
>> >
>> >
>> > 3. Caching:
>> >
>> > For prefracturing there is a shard / mesh island cache necessary, so you
>> don't need to refracture the object in each modifier evaluation step, even
>> if no changes are being made to the mesh. This is currently implemented as
>> special DNA structs and stored within the .blend file.
>> >
>> > For dynamic fracturing either a dynamic cache which supports a growing
>> count of elements and changes in mesh topology would be necessary, or a
>> sequence of shard / mesh island lists, which would denote the mesh state at
>> keyframes where fracturing events happen.
>> >
>> > For simulation data currently a fixed point cache is used, which stores
>> motion data (loc, rot) on per frame basis. However this is only sufficient
>> for prefracture.
>> >
>> > On a dynamic fracture simulation the cache needs to be dynamically
>> extensible as well, to be able to store more and more elements as the
>> simulation goes on. One idea for the FM was to distribute the cache among
>> all participating objects (so each object has its own cache).
>> >
>> >
>> > 4. Storage:
>> >
>> > Both mesh and simulation cache should be storable in the .blend file, or
>> alternatively in an external file so the simulation is ready to start after
>> loading the file. No additional fracture step or first uncached (slow)
>> simulation step should be mandatory in case the cache is valid.
>> >
>> >
>> > ___
>> > Bf-committers mailing list
>> > Bf-committers@blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-committers
>> ___
>> 

Re: [Bf-committers] building with opensubdiv using mingw

[Antony Riakiotakis]

Initially I wanted to introduce support for gcc 4.9 even but it
requires a few days of full time building which I am a bit reluctant
to devote currently. Admittedly I don't have too much time with
family/travelling/job hunting obligations either.
For coding I've switched to MSVC since there were compatibility issues
with MinGW that made it hard to only rely on it exclusively for our
builds. For instance, debug builds require MSVC compiler installed,
also CUDA binary building requires the same.
In any case, if someone wants to take the MinGW support mantle on for
the time being he would be welcome to do so.

On 24 September 2015 at 08:16, Campbell Barton  wrote:
> On Thu, Sep 24, 2015 at 10:04 AM, Yousef Harfoush  wrote:
>> i do understand the developers reason not to support mingw, but still there 
>> is good reasons to support it, have anyone tried the new mingw 4.9 or 5.x 
>> builds, it resolves many issues.
>
> Since MinGW isn't used for official builds, it's only supported by
> developers who use it. Keeping Blender's code compiling isn't such a
> problem since we use GCC on other platforms,
> However in this case of Windows this means having to build 3rd party
> libraries as well.
>
> So this isn't so much a case of dropping support,
> Its just nobody using MinGW has taking the time to update the libraries.
>
>> a separate question, why mingw lib folder is under 1 GB while i'm at more 
>> than 6 GB for vc12 and still downloading!
>
> "win64_vc12" is currently 4.2G, mingw64 misses llvm (2.7G).
>
>
>> thank you.
>>
>> Regards
>> Yousef Harfoush
>> ba...@msn.com
>>
>>
>>
>>> Date: Wed, 23 Sep 2015 19:18:18 -0400
>>> From: significant@gmail.com
>>> To: bf-committers@blender.org
>>> Subject: Re: [Bf-committers] building with opensubdiv using mingw
>>>
>>> Ok Sergey and Cezary, you've given good reasons to keep MinGW as a working
>>> alternative on Windows. GCC vs Clang produce similar performance on Linux
>>> (with GCC a little bit better). That's the only platform I've used that
>>> supports both compilers out of the box, so haven't compared on other
>>> platforms. Has anyone tried Clang on Windows?
>>>
>>> Also good point about Microsoft being slower at language standards.
>>> Switched to VS 2015 for that very reason.
>>>
>>> Mike Erwin
>>> musician, naturalist, pixel pusher, hacker extraordinaire
>>>
>>> On Wed, Sep 23, 2015 at 6:07 PM, Cezary Kopias 
>>> wrote:
>>>
>>> > I`m using mingw on a daily basis in my amateur 'production'
>>> > (some things don't work but its nothing that I am using) ...
>>> >
>>> > ...its the same story every time:
>>> > 1. its faster (cycles cpu render, booleans = linux speed)
>>> > 2. its compact and portable.
>>> >
>>> > We have now OpenSubD... next is OpenVDB, Ptex...
>>> > and after that i will consider a good comeback of mingw.
>>> >
>>> > P.S. I know nothing of clang but maybe could be a good substitute
>>> >
>>> > On 23 September 2015 at 21:15, Sergey Sharybin 
>>> > wrote:
>>> > > This is true, but it's not all truth :)
>>> > >
>>> > > For a long time gcc even from mingw was producing much better assembly
>>> > than
>>> > > msvc. Even today msvc requires some annoying poking around with all sort
>>> > of
>>> > > weird and wonderful workarounds forbetter performance. Plus it's a bit
>>> > slow
>>> > > about all the language extensions and such. From this point of view 
>>> > > clang
>>> > > seems interesting to test.
>>> > >
>>> > > On Wed, Sep 23, 2015 at 11:36 PM, Mike Erwin 
>>> > > wrote:
>>> > >
>>> > >> With Visual Studio now free (as in beer) for small teams and open 
>>> > >> source
>>> > >> projects, that takes away one major reason to keep using MinGW. Yes
>>> > Visual
>>> > >> Studio is a much larger beast than any command-line compiler, but it's
>>> > >> pretty nice to use.
>>> > >>
>>> > >> Mike Erwin
>>> > >> musician, naturalist, pixel pusher, hacker extraordinaire
>>> > >>
>>> > >> On Wed, Sep 23, 2015 at 4:07 AM, Campbell Barton 
>>> > >> wrote:
>>> > >>
>>> > >> > MinGW has been in (semi) broken state for some months now, since some
>>> > >> > libraries are missing.
>>> > >> >
>>> > >> > This is noted on the build page:
>>> > >> >
>>> > >> >
>>> > >>
>>> > http://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Windows/MinGW/CMake
>>> > >> >
>>> > >> > On Wed, Sep 23, 2015 at 4:24 PM, Sergey Sharybin <
>>> > sergey@gmail.com>
>>> > >> > wrote:
>>> > >> > > There's currently no precompiled OpenSubdiv libraries for mingw.
>>> > >> > >
>>> > >> > > As for the future -- i don't really think we'll keep maintaining
>>> > mingw
>>> > >> > > libraries. This is because mingw was proven to have obscure issues
>>> > >> which
>>> > >> > > makes blender builds unstable. Think we'd be moving to clang rather
>>> > >> than
>>> > >> > > keeping trying to use mingw.
>>> > >> > >
>>> > >> > > But that's my vision of the 

Re: [Bf-committers] Repeat current operator - Patch

[Antony Riakiotakis]

Hi, please don't mail the whole mailing list every time you update a
patch. Phabricator is quite convenient to track progress of a patch
already and not everyone is interested in every patch update.

On 5 September 2015 at 02:06, Jaume Bellet  wrote:
> I uploaded a new patch
>
> https://developer.blender.org/D1505
>
> The patch is related to the task https://developer.blender.org/T45734 and
> allows to create / place elements faster, and precisely if combined with
> the patch https://developer.blender.org/D1501 as shown in this video
>
> https://vimeo.com/138325421
>
> Any suggestions and comments around it will be welcome!
> ___
> 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] Grab, rotate, scale with basepoint

[Antony Riakiotakis]

I have to take that back, it's not like cursor based pivot. I think
it's a really nice patch, though it will need some improvements for
sure before masterification - will leave more feedback in phabricator
later.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] New Committer: Lukas Stockner (lukasstockner97)

[Antony Riakiotakis]

Welcome Lukas, well deserved!

On 27 August 2015 at 19:59, Bastien Montagne montagn...@wanadoo.fr wrote:
 Welcome aboard Lukas! :)

 Le 27/08/2015 18:31, Jacob Merrill a écrit :
 Welcome, I hope to be as cool as you some day!!!
 On Aug 27, 2015 9:13 AM, Jonathan Williamson jonat...@cgcookie.com
 wrote:

 Welcome Lukas! I was thrilled to see your work with portals.

 Jonathan Williamson
 http://cgcookie.com

 On Thu, Aug 27, 2015 at 9:56 AM, Sergey Sharybin sergey@gmail.com
 wrote:

 Hi,

 I would like to introduce new committer -- Lukas Stockner. He was working
 in Cycles area doing fixes and implementing new features like portals.

 He'll keep working in Cycles area and already has some promising patches
 in
 the dev.b.o (which still needs review).

 Welcome aboard, Lukas!

 P.S. Now you know who to poke for awesome new features ;)

 --
 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


 ___
 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] Lack of coordination and communication in Blender development

[Antony Riakiotakis]

I will also adopt Martin's position here. The design of the
interaction model with physics, node driven mesh construction and
dependency graph is still in it's infancy.

Making generic comments on design of blender is not helpful either.
Most people on this list have no idea of the context in which you are
referring (myself included).
Please be more specific:
How does blender's design block your progress and what would you like to see.
Is any of the current redesigns of blender internals blocking your
progress and how?

Only big recent internal redesign I can think of currently is the
looptriangle refactor, but I don't see how this could be hindering
physics in any way.

On 15 August 2015 at 20:36, Martijn Berger martijn.ber...@gmail.com wrote:
 Hi Kai,

 As far as I am aware nothing has happened behind closed doors so far.
 Everyone is trying to give input of wildly varying levels of quality.
 It would be good if you could put together a (partial) proposal or at least
 a list of things you think you need (based on current limitations?) in
 order to successfully integrate the fracture modifier.

 The 2.8 process has only just begun and it seems early to be wanting
 guarantees to be heard or making assertions that the core team is not
 listening.
 I would suggest to any and all people wanting to influence what happens
 next, make a good (partial) proposal or at least try and describe the
 current limitation you feel should be addressed.

 Martijn

 On Sat, Aug 15, 2015 at 8:20 PM, Kai Kostack kaikost...@gmx.net wrote:

 Hello Marc,

 I appreciate your answer but we're aware of what you're explaining. We
 have a more fundamental problem.

 Currently there is a redesign of various Blender internals ongoing. Design
 decisions will be made that are crucial for our modifier to meet all
 required coding conventions. Our workarounds have been criticized as bad
 by core developers earlier. However, those hacks have been necessary until
 now because it couldn't be solved otherwise due to bad Blender design.

 So, now that there is the chance to fix those issues in depth we would
 like to monitor that design decision making process and comment early on on
 it to make sure, they don't oversee some requirements that will be
 important for us in the future.

 At the moment it looks like everything important happens behind closed
 doors.

 -- Kai
 ___
 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 developers meeting notes - August 2, 2015

[Antony Riakiotakis]

What might work is detecting if the final derived mesh has any users
outside the draw code, and if it does not then it may be possible to
use some sort of shader and do the calculation there. If it does, then
we will be needing the full result anyway, so we can just upload that
and skip the vertex shader cost. Some modifiers, such as the array
modifier can also benefit from similar code (+ instancing) but they
also need a way to detect cornercases (such as the object used as a
duplicated mesh for instance).

I must say though, I am not sure if using vertex shaders is the best
way to go, because it makes material shaders depend on modifiers which
means more shader bind calls plus materials would need a more
elaborate shader storing scheme for every material/modifier
combination. Maybe the way OpenSubdiv handles this can be generalized,
but we'll see if that's possible when/if we have full support in the
future.

Probably the depsgraph might support these kinds of queries, though
Sergey, Lukas or Joshua would know best.
The DAG should also be used to detect what mesh data need to be
reuploaded to the GPU due to some underlying mesh change
as well. Currently though, I'm still porting all mesh code to use
vertex buffer objects properly and haven't checked the depsgraph at
all.

On 2 August 2015 at 19:07, joe joe...@gmail.com wrote:
 Who's doing the viewport optimization work?  I have some experience here.
 The key thing is to limit OpenGL commands, and also the data sent per-frame
 to the GPU.  It might also be a good idea to move the simpler deform
 modifiers into vertex shaders (and make sure to use a node system--it's
 actually easier to use a DAG system than to try and code all the edge cases
 by hand).



 On Sun, Aug 2, 2015 at 9:16 AM, Ton Roosendaal t...@blender.org wrote:

 Hi all,

 Here are the notes from today's meeting in irc.freenode.net
 #blendercoders.

 1) Upcoming 2.76 release

 - OpenSubdiv: an essential fix was made by the Pixar team, we we can move
 on. (3.0.1 will be out soon).
 Unfortunately 3.0 has no UV texture support yet, will be in 3.1 later this
 year.

 For that reason Sergey will add it as optional choice, mainly for
 animation editing and playback
 in viewport.

 - Still waiting for a short document outlining the viewport Mesh
 performance work.

 - Reminder: anyone who wants to add something that affects users or other
 developers (APIs):
 always make a nice doc! *Before the commit* Even when you think it's not
 interesting (like optimizing).
 Blender work is interesting to share by default! :)

 - Due to holidays (2+ weeks absence of several core devs) we also extend
 the 2.76 with two weeks.

 - Current projects and planning:
 http://wiki.blender.org/index.php/Dev:Doc/Projects

 - Splash: suggested is to do a public contest in BA forums again. Still
 need a proposal for
 who will do the judging... and would we do a theme again? Tradition is to
 have the previous
 team/panel who selected a splash appoint the next. I'll ask the artists
 here to propose something.

 - Kevin Dietrich: OpenVDB patch is still waiting for review. There are
 also two (small) Cycles
 features using OpenVDB ready. The platform maintainers have to check on
 inclusion of new libs though.

 Check this:
 http://wiki.blender.org/index.php/User:Kevindietrich/OpenVDBRendering
 And this:
 http://wiki.blender.org/index.php/User:Kevindietrich/OpenVDBSmokeExport

 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
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] boost update for OpenVDB on Windows

[Antony Riakiotakis]

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

Re: [Bf-committers] Blender performance measuring instrumentation improvement proposal

[Antony Riakiotakis]

It would be nice to be able to separate this total performance time to
sub-costs, otherwise it would indeed difficult to make out something
out of that number apart from performance changed - which indeed
says little, performance changes with every change.

On 10 June 2015 at 13:38, Sergey Sharybin sergey@gmail.com wrote:
 I didn't say it's difficult, i only mentioned that it is to be thought much
 more careful defining which exact information is useful for us and how to
 gather it.

 On Wed, Jun 10, 2015 at 1:25 PM, Campbell Barton ideasma...@gmail.com
 wrote:

 Hi Martijn, think its fine to have more comprehensive performance tests
 (which can include extending, bpy.ops.wm.redraw_timer or add related
 operators to give more comprehensive info).

 This seems like 2 separate projects,

 - ability to perform tests and collect feedback.
 - extend existing performance tests.

 Second needs review of each kind of test added, but that can be done
 on case-by-case basis, to see whats really useful to measure.


 Ability to execute operators directly from command line is handy,
 uploaded patch.
 https://developer.blender.org/D1347
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers




 --
 With best regards, Sergey Sharybin
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] F-Stop

[Antony Riakiotakis]

Hi,

Indeed there is redundancy there. There's just one reason it hasn't
been merged: cycles has its own f-stop number. Ideally we would import
the camera f-stop from blender during rendering but that would require
us to do a version patch -from- cycles camera data to blender to keep
old files working. I am not sure if this is possible..

Personally I don't have any preference over keeping or dropping one of
the two. I can see merits in both ways. Agree it should totally be up
to the users.

On 11 May 2015 at 23:06, Jeroen Bakker j.bak...@atmind.nl wrote:
 Hi all,

 just noticed that there are currently 2 places where you can/need to set
 the F-Stop.

 1. In the camera settings (was first only visible in cycles, but since
 viewport project it is also visible for blender renderer)
 2. In the compositor defocus node.

 The compositor defocus node does not work without having a camera setup
 as it reads the Distance from the camera. But still we need to set the
 F-Stop in the defocus node.

 Is there a reason why these values have not been merged?

 If not I would suggest to remove the F-stop field from the defocus node
 and read the value from the camera itself. But maybe we should ask the
 users.

 Regards,
 Jeroen  Monique.
 ___
 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] Building CUDA in blenkernel

[Antony Riakiotakis]

This error is realy weird, blenkernel has nothing to do at all with
the cycles kernel. This file is sequencer related and we don't really
use CUDA. Is this a custom branch or is this master?

On 4 May 2015 at 10:11, Sergey Sharybin sergey@gmail.com wrote:
 Hi.

 It's either path to seqeffects is wrong (missing intern/ ?) or file is
 missing. In any case for such kind of help it's usually much more helpful
 to provide patch instead of describing the changes.

 On Sun, May 3, 2015 at 10:16 PM, John Peter Yamauchi jpyamau...@gmail.com
 wrote:

 Hi,

 I'm trying to build a CUDA file in the blenkernel directory.  So far when I
 execute make it will print No rule to make target
 'blender-git/blender/source/blender/blenkernel/seqeffects.cu', needed by
 'source/blender/blenkernel/kernel_sm_20.cubin'. Stop.

 I copied the cmake code from blender/intern/cycles/kernel/CMakeFiles.txt,
 stuck it at the end of the
 blender/source/blender/blenkernel/CMakeFiles.txt, and made some
 adjustments:


 find_package(CUDA)

 # 32 bit or 64 bit
 if(${CMAKE_SIZEOF_VOID_P} EQUAL 8)
 set(CUDA_BITS 64)
 else()
 set(CUDA_BITS 32)
 endif()

 # CUDA version
 execute_process (COMMAND ${CUDA_NVCC_EXECUTABLE} --version
 OUTPUT_VARIABLE NVCC_OUT)
 string(REGEX REPLACE .*release ([0-9]+)\\.([0-9]+).* \\1
 CUDA_VERSION_MAJOR ${NVCC_OUT})
 string(REGEX REPLACE .*release ([0-9]+)\\.([0-9]+).* \\2
 CUDA_VERSION_MINOR ${NVCC_OUT})
 set(CUDA_VERSION ${CUDA_VERSION_MAJOR}${CUDA_VERSION_MINOR})

 # warn for other versions
 if(CUDA_VERSION MATCHES 65)
 else()
 message(WARNING
 CUDA version ${CUDA_VERSION_MAJOR}.${CUDA_VERSION_MINOR} detected,
 
 build may succeed but only CUDA 6.5 is officially supported)
 endif()

 # build for each arch
 set(cuda_sources seqeffects.cu ${SRC_HEADERS})
 set(cuda_cubins)


 set(cuda_extra_flags )
 set(cuda_cubin kernel_${arch}.cubin)

 set(cuda_debug_flags )

 set(cuda_version_flags -D__KERNEL_CUDA_VERSION__=${CUDA_VERSION})
 set(cuda_math_flags --use_fast_math)

 add_custom_command(
 OUTPUT ${cuda_cubin}
 COMMAND ${CUDA_NVCC_EXECUTABLE}
 -arch=${arch}
 -m${CUDA_BITS}
 --cubin ${CMAKE_CURRENT_SOURCE_DIR}/seqeffects.cu
 -o ${CMAKE_CURRENT_BINARY_DIR}/${cuda_cubin}
 --ptxas-options=-v
 ${cuda_arch_flags}
 ${cuda_version_flags}
 ${cuda_math_flags}
 ${cuda_extra_flags}
 ${cuda_debug_flags}
 -I${CMAKE_CURRENT_SOURCE_DIR}/../util
 -I${CMAKE_CURRENT_SOURCE_DIR}/svm
 -DCCL_NAMESPACE_BEGIN=
 -DCCL_NAMESPACE_END=
 -DNVCC

 DEPENDS ${cuda_sources})

 list(APPEND cuda_cubins ${cuda_cubin})

 add_custom_target(vse_acceleration ALL DEPENDS ${cuda_cubins})


 ## Warnings as errors, this is too strict!
 #if(MSVC)
 #set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} /WX)
 #endif()

 blender_add_lib(bf_blenkernel ${SRC} ${INC} ${INC_SYS})

 add_dependencies(bf_blenkernel vse_acceleration)


 What am I doing wrong?



 Thanks!

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




 --
 With best regards, Sergey Sharybin
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Attention: Backtrace on Windows is not correct on 2.74 release

[Antony Riakiotakis]

I wouldn't say that debug builds are unusable for bugs like this
https://developer.blender.org/T44367 and it would give us a pretty
good idea what's happening.
Agree though that release with debug symbols will be more useful here.
Will need to try if we have stacktrace correctly available there but I
expect we will.
Debug builds are also how mozilla handles this, see
https://developer.mozilla.org/en-US/docs/How_to_get_a_stacktrace_with_WinDbg

On 16 April 2015 at 20:12, Sergey Sharybin sergey@gmail.com wrote:
 I\ve got doubts debug builds will be really useful -- they're really slow
 and unusable for investigating th issue. If we do this, it's better to do
 something like RelWithDebInfo, but we don't have it in scons.

 So if debug builds are really needed then we'd better to either add such
 type of build to scons or use cmake for it. Not sure if cmake is ready for
 this, but Martijn knows better.

 There was also some work done related on improving debug backtrace on
 windows (afair Alex was working on this). Maybe that'd be more convenient
 than requiring to download debug builds for bug reporting?

 On Thu, Apr 16, 2015 at 11:01 PM, Antony Riakiotakis kal...@gmail.com
 wrote:

 Hi all,

 Recently I committed some code that prints a backtrace when Windows
 builds of blender crash.

 I've mentioned this countless times already on the tracker, but not
 sure how many people watch the tracker, so I will report it here as
 well:

 The windows backtrace does -not- work on release builds. It does work
 on debug builds though.

 People have been overeager to include this backtrace in their reports
 so I have promptly disabled
 it on master.

 The handler is not useless and it might be nice to make a debug build
 available on our buildbot.
 This will allow us to quickly direct users to a debug build for a
 proper backtrace.

 But for now, please dismiss any information in the backtrace as
 garbage (In recent builds it even includes an explicit message so
 people are not confused any more)
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers




 --
 With best regards, Sergey Sharybin
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Attention: Backtrace on Windows is not correct on 2.74 release

[Antony Riakiotakis]

Hi all,

Recently I committed some code that prints a backtrace when Windows
builds of blender crash.

I've mentioned this countless times already on the tracker, but not
sure how many people watch the tracker, so I will report it here as
well:

The windows backtrace does -not- work on release builds. It does work
on debug builds though.

People have been overeager to include this backtrace in their reports
so I have promptly disabled
it on master.

The handler is not useless and it might be nice to make a debug build
available on our buildbot.
This will allow us to quickly direct users to a debug build for a
proper backtrace.

But for now, please dismiss any information in the backtrace as
garbage (In recent builds it even includes an explicit message so
people are not confused any more)
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Weekly Blender developer meeting minutes, April 12, 2015

[Antony Riakiotakis]

There's an issue which is quite serious and hasn't been mentioned so
far, so I will mention it here, even lately.

Blender 2.74 suffers from an issue where opening a file by double
clicking when Load UI is off in user preferences will crash.

I wouldn't mention this but it's getting reported quite often and it
might warrant an a release at some point.

See:
https://developer.blender.org/T44217

On 13 April 2015 at 00:12, Campbell Barton ideasma...@gmail.com wrote:
 On Mon, Apr 13, 2015 at 12:29 AM, Ton Roosendaal t...@blender.org wrote:
 Hi all,

 Here are the notes of today's (1400 UTC) meeting in irc.freenode.net 
 #blendercoders.

 1) Release targets for 2.75

 - Udated:
 http://wiki.blender.org/index.php/Dev:Doc/Projects

 - Nicholas Bishop mailed that he prefers more time to rework some Ptex code, 
 this will go to a next version.

 - Thomas Beck: doc or log page for the font preview feature is coming!

 Not sure what the issue is here?
 The feature was noted in release logs right after committing.

 Adding previews doesn't really need user docs (users don't need to
 know how to _use_ previews, they just show up).
 We don't have docs about blend file previews or movie previews either.
 ___
 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] Viewport GL background

[Antony Riakiotakis]

There were some fixes there recently, can you try the latest buildbot
and see if it works for you?

Note: Blender internal's transparency setting will influence both
cycles and blender internal.

On 25 March 2015 at 09:49, gandalf3 zzyx...@gmail.com wrote:
 Works fine for me.. Perhaps you accidentally enabled *Transparent* in
 *Info panel (top bar)  Render  OpenGL render options  Alpha Mode*?
 Try setting to *Sky* instead.

 On 03/24/15 17:36, Jeffrey wrote:
 Hey devs. It occurred to me today that while in Cycles mode, it is
 impossible to render a viewport playblast using the world background
 (even with World Background and Only Rendered enabled in the display
 properties). This is possible in BI, as shown in [1]. Currently, the
 viewport only renders as transparent, which is then rendered black in
 any standard video format. I also disabled transparency in the Cycles
 film settings, but that also does not show the world color.

 My use case is when I do animatics in grease pencil, where I have a
 solid world background and draw in line. I then do a viewport playblast
 into quicktime h.264 with audio and everything works like I need to,
 with the exception of the viewport background.

 It would be great to include this option in Cycles mode, too, for the
 sake of continuity and completeness. Thanks!

 [1] http://www.pasteall.org/pic/show.php?id=85782



 --
 -gandalf3

 ___
 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] Workflow shaders proposal

[Antony Riakiotakis]

There is a work in progress proposal on the new workflow shaders,
the new data-request-driven design of the new viewport here:

http://wiki.blender.org/index.php/User:Psy-Fi/Workflow_Shaders

I would welcome any feedback here to make it as clear as possible, thanks!

We can also open a task if it would help people with feedback.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] VSE caching

[Antony Riakiotakis]

Hmmm...it sounds like it's just way more expensive to process the
files in this case since they are floats. Generally there are some
non-obvious tricks to make the sequencer play back better such as
disabling anti aliasing and making sure the target resolution is close
to the footage resolution.


On 23 March 2015 at 11:13, Thomas Volkmann li...@thomasvolkmann.com wrote:
 Hi,

 I just wanted to ask if something is wrong with the way the seqence-editor 
 uses
 its cache.
 Basically I have a 1920*1080 exr seqence that I can't get to playback at 25fps
 although I have more than sufficient memory and I have set it in the prefs.
 Playing back the same sequence as jpg is no problem at all.
 Does Blenders VSE have a problem with caching exr files?

 Here is the thread on StackExchange:
 http://blender.stackexchange.com/questions/27402/vse-not-playing-in-realtime-not-caching

 thx!
 ___
 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] OpenEXR issue ubuntu

[Antony Riakiotakis]

I had an idea, it's most probably leftover links from ldconfig, I'll
try that at home.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] OpenEXR issue ubuntu

[Antony Riakiotakis]

Nope, still not working. Has anyone actually tried to reproduce this yet?

On 23 March 2015 at 15:58, Antony Riakiotakis kal...@gmail.com wrote:
 I had an idea, it's most probably leftover links from ldconfig, I'll
 try that at home.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] OpenEXR issue ubuntu

[Antony Riakiotakis]

Own stupidity was the main reason, apparently I disabled non-portable
build on my build script recently and calling blender was just using
an obsolete version which needed the deleted library. Sorry for the
noise. OSL still fails at cmake config though.

On 24 March 2015 at 00:27, Antony Riakiotakis kal...@gmail.com wrote:
 Nope, still not working. Has anyone actually tried to reproduce this yet?

 On 23 March 2015 at 15:58, Antony Riakiotakis kal...@gmail.com wrote:
 I had an idea, it's most probably leftover links from ldconfig, I'll
 try that at home.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] OpenEXR issue ubuntu

[Antony Riakiotakis]

I have a strange issue with OpenEXR in blender. Apparently, it tries
to link both 2.2 and 2.1 versions somehow and blender does not startup
after that. Can someone with ubuntu try rebuilding the dependencies
from scratch with the recent install_deps script and try build blender
with them?

Also there's an OSL compilation issue but I can live without that too.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Why must sync selection be disabled to select UV islands?

[Antony Riakiotakis]

because selecting an island will also select its vertices, and those
vertices can belong to other uv islands, and if you select those
vertices you'll have to select uv vertices on other islands as well.
Ergo, you either select more islands - which makes the tool useless,
or you leave your selection state invalid.

On 18 March 2015 at 08:02, gandalf3 zzyx...@gmail.com wrote:
 I would be surprised if this hasn't been asked before, but finding old
 stuff on the mailing list isn't easy..

 Anyway, trying to select UV islands with L while sync selection is
 enabled gives the error Cannot select linked when sync selection is
 enabled.
 Why must sync selection be disabled? I can't think of any obvious reason
 why there would be a conflict of some sort.. As a matter of fact this
 seems like it would be a really useful ability.

 Is there some technical limitation which prevents this?

 --
 -gandalf3

 ___
 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] Why must sync selection be disabled to select UV islands?

[Antony Riakiotakis]

Rubber band tool?

On 18 March 2015 at 10:40, Gaia gaia.cl...@machinimatrix.org wrote:
 I made a simple experiment:

 - i select keep UV selection in sync
 - then use the rubber band tool to select an UV island

 As a result i get the related vertices selected on the 3D View,
 just as expected. AND i also get all UV vertices selected
 which belong to other UV islands, which i also expect because
 i have actually chosen to keep UV in Sync with 3dView...

 Now here is my problem with your argumentation:
 If you say, the selection by UV Island is wrong and unusable,
 what makes it ok to have the rubber band selector available,
 which actually suffers from the same issues?

 -gaia-

 On 18.03.2015 10:16, Antony Riakiotakis wrote:
 because selecting an island will also select its vertices, and those
 vertices can belong to other uv islands, and if you select those
 vertices you'll have to select uv vertices on other islands as well.
 Ergo, you either select more islands - which makes the tool useless,
 or you leave your selection state invalid.

 On 18 March 2015 at 08:02, gandalf3 zzyx...@gmail.com wrote:
 I would be surprised if this hasn't been asked before, but finding old
 stuff on the mailing list isn't easy..

 Anyway, trying to select UV islands with L while sync selection is
 enabled gives the error Cannot select linked when sync selection is
 enabled.
 Why must sync selection be disabled? I can't think of any obvious reason
 why there would be a conflict of some sort.. As a matter of fact this
 seems like it would be a really useful ability.

 Is there some technical limitation which prevents this?

 --
 -gandalf3

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

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

Re: [Bf-committers] Why must sync selection be disabled to select UV islands?

[Antony Riakiotakis]

It might be possible to do in face select mode then, but not in vertex
select mode for sure

On 18 March 2015 at 11:11, Paweł Łyczkowski pawellyczkow...@gmail.com wrote:
 gandalf3 wrote:

 Is there some trick to this that I'm missing?


 You have to be in face select mode.

 gandalf3 wrote:

 Plus it doesn't work if you don't have seams (though admittedly most of
 the time this is probably not the case).

 That reminds me, limit by seams doesn't seem to work for me. I mark all
 edges surrounding a bit of geometry as seams, then I select a vertex the
 middle, press Ctrl L and enable limit by seams in the redo panel.
 However the entire part remains selected.. Tested with 2.73a

 Is there some trick to this that I'm missing?

 On 03/18/15 02:52, Paweł Łyczkowski wrote:

 I also always missed this. When selecting in vertex select mode, I would
 expect for vertices in other islands to be selected as well. I would use
 it in face select mode though.

 I usually went around this by identifying where on the model is the
 island I wanted selected, and then used select linked with limit with
 seams turned on in the 3d View - but that's a roundabout way of doing
 this.

 Gaia wrote:

 I made a simple experiment:

 - i select keep UV selection in sync
 - then use the rubber band tool to select an UV island

 As a result i get the related vertices selected on the 3D View,
 just as expected. AND i also get all UV vertices selected
 which belong to other UV islands, which i also expect because
 i have actually chosen to keep UV in Sync with 3dView...

 Now here is my problem with your argumentation:
 If you say, the selection by UV Island is wrong and unusable,
 what makes it ok to have the rubber band selector available,
 which actually suffers from the same issues?

 -gaia-

 On 18.03.2015 10:16, Antony Riakiotakis wrote:

 because selecting an island will also select its vertices, and those
 vertices can belong to other uv islands, and if you select those
 vertices you'll have to select uv vertices on other islands as well.
 Ergo, you either select more islands - which makes the tool useless,
 or you leave your selection state invalid.

 On 18 March 2015 at 08:02, gandalf3zzyx...@gmail.com wrote:

 I would be surprised if this hasn't been asked before, but finding old
 stuff on the mailing list isn't easy..

 Anyway, trying to select UV islands with L while sync selection is
 enabled gives the error Cannot select linked when sync selection is
 enabled.
 Why must sync selection be disabled? I can't think of any obvious
 reason
 why there would be a conflict of some sort.. As a matter of fact this
 seems like it would be a really useful ability.

 Is there some technical limitation which prevents this?

 --
 -gandalf3

 ___
 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 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] Why must sync selection be disabled to select UV islands?

[Antony Riakiotakis]

Committed, 
https://developer.blender.org/rBaff4aa173a78c7bbd7d08666f995d48ea18cdb50

On 18 March 2015 at 11:29, Gaia gaia.cl...@machinimatrix.org wrote:
 I meant Border Select (shortkey b), Sorry for the confusion.
 Maybe the other term slipped into my memory from usage
 with another tool :-[

 Nevertheless i believe that selecting an island via Border select
 (or Lasso select) and selecting the island by using L should
 give identical results.

 And i agree that using any select tool in vertex selection mode
 might be less useful than using it in face selection mode.

 cheers
 gaia

 On 18.03.2015 11:00, Antony Riakiotakis wrote:
 Rubber band tool?

 On 18 March 2015 at 10:40, Gaia gaia.cl...@machinimatrix.org wrote:
 I made a simple experiment:

 - i select keep UV selection in sync
 - then use the rubber band tool to select an UV island

 As a result i get the related vertices selected on the 3D View,
 just as expected. AND i also get all UV vertices selected
 which belong to other UV islands, which i also expect because
 i have actually chosen to keep UV in Sync with 3dView...

 Now here is my problem with your argumentation:
 If you say, the selection by UV Island is wrong and unusable,
 what makes it ok to have the rubber band selector available,
 which actually suffers from the same issues?

 -gaia-

 On 18.03.2015 10:16, Antony Riakiotakis wrote:
 because selecting an island will also select its vertices, and those
 vertices can belong to other uv islands, and if you select those
 vertices you'll have to select uv vertices on other islands as well.
 Ergo, you either select more islands - which makes the tool useless,
 or you leave your selection state invalid.

 On 18 March 2015 at 08:02, gandalf3 zzyx...@gmail.com wrote:
 I would be surprised if this hasn't been asked before, but finding old
 stuff on the mailing list isn't easy..

 Anyway, trying to select UV islands with L while sync selection is
 enabled gives the error Cannot select linked when sync selection is
 enabled.
 Why must sync selection be disabled? I can't think of any obvious reason
 why there would be a conflict of some sort.. As a matter of fact this
 seems like it would be a really useful ability.

 Is there some technical limitation which prevents this?

 --
 -gandalf3

 ___
 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 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] Compositor viewer node

[Antony Riakiotakis]

Is that in master or in gooseberry?

On 9 March 2015 at 11:51, Daniel Salazar - patazstudio.com
zan...@gmail.com wrote:
 Hi I've noticed that the new compositor lightens the backdrop when the
 viewer node is selected. I'd ask to remove that, maybe add some corner
 markers on the backdrop image but changing the actual color of the
 image is not nice.

 best regards

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

Re: [Bf-committers] Compositor viewer node

[Antony Riakiotakis]

Should be fine if you update

On 9 March 2015 at 12:39, Daniel Salazar - patazstudio.com
zan...@gmail.com wrote:
 Oops! It's gooseberry, didn't check master
 Daniel Salazar
 patazstudio.com


 On Mon, Mar 9, 2015 at 5:38 AM, Antony Riakiotakis kal...@gmail.com wrote:
 Is that in master or in gooseberry?

 On 9 March 2015 at 11:51, Daniel Salazar - patazstudio.com
 zan...@gmail.com wrote:
 Hi I've noticed that the new compositor lightens the backdrop when the
 viewer node is selected. I'd ask to remove that, maybe add some corner
 markers on the backdrop image but changing the actual color of the
 image is not nice.

 best regards

 Daniel Salazar
 patazstudio.com
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
 ___
 Bf-committers 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] Luminance patches

[Antony Riakiotakis]

Hi,

We have quite a few functions to select luminance in our code.

Recently there were two patches to cleanup things.

https://developer.blender.org/D1082

https://developer.blender.org/D517

Seeing how developers still use any of the two in the code and how
there's really one correct formula for this it might be good to make
some decision about this.

Choises are - either we change this and break old files slightly or we
keep it and we have wrong histograms, tools and compatibility with
color management pipeline.

I am curious about what coders and artists think about the change
since it will influence both.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Luminance patches

[Antony Riakiotakis]

Hi Thomas, agreed, I am also of the same opinion. It will hurt old
files slightly but better now than never.

On 17 February 2015 at 20:21, Thomas Beck softw...@plasmasolutions.de wrote:
 Hi Antony,

 I'm for fix it properly by breaking old files slightly. I (the artists
 around me agree) prefer to let old files break (in terms of color
 correction) when we get a working color pipeline with correct formulas in
 exchange for it. I would really not like to see a wrong behavior carried on
 endless times just to be compatible to infinity and beyond ;) .

 Greetings, Thomas

 Plasmasolutions
 Design | Development | Training

 Website: Http://www.plasmasolutions.de http://www.plasmasolutions.de/
 Blog: Http://blog.plasmasolutions.de http://blog.plasmasolutions.de/

 Telefon: +49 176 2017 9565

 Blender Foundation Certified Trainer
 http://www.blendernetwork.org/BFCTAutor von Blender 2.7 - das umfassende
 Handbuch http://www.galileo-press.de/3404

 2015-02-17 19:42 GMT+01:00 Antony Riakiotakis kal...@gmail.com:

 Hi,

 We have quite a few functions to select luminance in our code.

 Recently there were two patches to cleanup things.

 https://developer.blender.org/D1082

 https://developer.blender.org/D517

 Seeing how developers still use any of the two in the code and how
 there's really one correct formula for this it might be good to make
 some decision about this.

 Choises are - either we change this and break old files slightly or we
 keep it and we have wrong histograms, tools and compatibility with
 color management pipeline.

 I am curious about what coders and artists think about the change
 since it will influence both.
 ___
 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] VSE Rendering Code

[Antony Riakiotakis]

Hi,

Check sequencer.c sequencer_draw.c. seqeffects.c seqcache.c We use
pthreads under the hood but we wrap it in our own API so you might
want to check that as well.

Some parts, such as effect application and proxy generation is already
threaded. A bottleneck currently is image scaling so source strips
have common dimensions, but I'm not sure this is easily threadable.

On 9 February 2015 at 17:05,  jpyamau...@gmail.com wrote:
 Where is the code that renders the VSE located?

 Also, what multi-threading library does Blender use?  I'm looking at 
 providing multi-core support for rendering in the VSE.

 Thanks,

 JP Yamauchi
 ___
 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] Problem with Open Source ATI drivers on Linux

[Antony Riakiotakis]

If you can't see this in other systems/GPUs with the same version of
blender then it's likely that it's a driver issue. Not seeing the
issue in 2.72 is an indication that this is a bug. It's hard to say
here for certain, but such discussions should always go to the bug
tracker - we can investigate there instead of mailing every person on
this list.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] MinGW libs don't appear to include python sqlite

[Antony Riakiotakis]

Hi an update here, MinGW currently has quite a few issues it seems.
While I managed to compile it crashes on startup due to python
initialization failing. This is most likely because the MSVC 2008
version of python that MinGW depends on is not properly updated to
work with blender now. I urge builders who use MinGW to be a bit
patient until the new system is set up.

On 2 February 2015 at 17:43, Antony Riakiotakis kal...@gmail.com wrote:
 I have quite a few libaries built locally already, just give me a few
 more days to get the rest of them working. For MinGW32 I am not
 maintaining this at all currently.

 On 2 February 2015 at 17:31, Sergey Sharybin sergey@gmail.com wrote:
 Antony was looking into making minwg + gcc-4.9 official (because of a pile
 of threading issues in current mingw). Some things might become broken
 since initial commits for that..

 As for disabling -- don't think it's so bad, just needs upgrade to be
 finished. But for that Antony might want to have a bit of help. Anyway,
 let's wait for his feedback before making any decision here :)



 On Mon, Feb 2, 2015 at 9:23 PM, Campbell Barton ideasma...@gmail.com
 wrote:

 Recently I've notices comments that MinGW fails (IRC  forums).

 Is anyone able to build Blender with MinGW 32/64 currently?

 If not we could disable it in the build-systems and warn in the wiki,
 until its made to work again.

 On Tue, Feb 3, 2015 at 2:13 AM, Rohan Smith
 rohan.preacher.sm...@gmail.com wrote:
  Hi,
  MinGW libs from
  https://svn.blender.org/svnroot/bf-blender/trunk/lib/mingw64 or mingw32
  do not appear to include the sqlite3.dll or sqlite3_d.dll. Does anyone
  have a workaround for building on Windows with MinGW?
 
  --
  Cheers,
  Rohan Smith
 
 
  ---
  This email has been checked for viruses by Avast antivirus software.
  http://www.avast.com
 
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers



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




 --
 With best regards, Sergey Sharybin
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] OpenEXR and OpenImageIO library bump

[Antony Riakiotakis]

Can someone build OSL against new OpenEXR? Looks like it's referenced
from it as well.

Also please make sure that blender compiles with updated libraries
before committing - ideally both cmake and scons should be tested.

On 31 January 2015 at 13:48, Sergey Sharybin sergey@gmail.com wrote:
 Upgraded libraries for linux. Didn't do anything special for ptex tho, that
 would need to have dedicate investigation anyway.

 On Fri, Jan 30, 2015 at 8:15 PM, Martijn Berger martijn.ber...@gmail.com
 wrote:

 Hi everyone.

 I would like to propose bumping OpenEXR to 2.2 and OpenImage IO to 1.4.16.


 OpenImageIO had a number of stability and compilation fixes particularly
 for msvc 2013 . newer and older versions of boost and static PTEX
 compilation.

 full changelog here -
  https://raw.githubusercontent.com/OpenImageIO/oiio/RB-1.4/CHANGES


 OpenEXR 2.2 has faster PIZ compression and 2 new algorithms for lossy
 compression by Dreamworks.

 In the case of OpenImageIO it is really a minor bump and there seem to be
 no issues based on my own testing on windows and linux.
 In the case of OpenEXR it is a minor version bump but I think having
 maximal file reading compatibility is worth the effort it takes to bump. (
 which is also not much based on my personal testing ).

 Attached is a patch for install_deps.sh that builds these versions.

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




 --
 With best regards, Sergey Sharybin
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] MinGW libs don't appear to include python sqlite

[Antony Riakiotakis]

I have quite a few libaries built locally already, just give me a few
more days to get the rest of them working. For MinGW32 I am not
maintaining this at all currently.

On 2 February 2015 at 17:31, Sergey Sharybin sergey@gmail.com wrote:
 Antony was looking into making minwg + gcc-4.9 official (because of a pile
 of threading issues in current mingw). Some things might become broken
 since initial commits for that..

 As for disabling -- don't think it's so bad, just needs upgrade to be
 finished. But for that Antony might want to have a bit of help. Anyway,
 let's wait for his feedback before making any decision here :)



 On Mon, Feb 2, 2015 at 9:23 PM, Campbell Barton ideasma...@gmail.com
 wrote:

 Recently I've notices comments that MinGW fails (IRC  forums).

 Is anyone able to build Blender with MinGW 32/64 currently?

 If not we could disable it in the build-systems and warn in the wiki,
 until its made to work again.

 On Tue, Feb 3, 2015 at 2:13 AM, Rohan Smith
 rohan.preacher.sm...@gmail.com wrote:
  Hi,
  MinGW libs from
  https://svn.blender.org/svnroot/bf-blender/trunk/lib/mingw64 or mingw32
  do not appear to include the sqlite3.dll or sqlite3_d.dll. Does anyone
  have a workaround for building on Windows with MinGW?
 
  --
  Cheers,
  Rohan Smith
 
 
  ---
  This email has been checked for viruses by Avast antivirus software.
  http://www.avast.com
 
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers



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




 --
 With best regards, Sergey Sharybin
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Revisions for 2.73a

[Antony Riakiotakis]

Sergey, please add

b99687169debea80d0777ba83ac185f1f2e04b83

as well, thanks!

On 19 January 2015 at 13:52, Joshua Leung aligor...@gmail.com wrote:
 This one would be good to include as well (though a bit more testing from
 artists first is welcome):
 32ffc63d20908c6433e0e92488be3b5568f81f69

 It fixes a crash when reusing the same Grease Pencil datablock in different
 editor types at the same time, and also makes sure that editing won't
 modify data users can't see in such circumstances.

 On Mon, Jan 19, 2015 at 11:32 PM, Sergey Sharybin sergey@gmail.com
 wrote:

 Hi,

 There's list of revisions which are either marked by authors as candidates
 for 2.73a or which solves some bad issues and are safe one-liners:

 ae18fd5937753d1fc420dc8aef78efacabb9750c
 def2ef88b089b69b2f4e1884a916232101edc8ae
 e02af840e1fbafd068d527ade70146141ab16946 +
 73955e256678c5873ee83d32f861d7f35b917d57 ?
 ca9bdf3f286a4c01eb2da1a5689b71737636f659
 dec523da877facb0573dccce6d95e5b0d2734707
 599c8a2c8e4cf1f904c5422916ebfd8d12eebe69
 1864253db06957ec344e6504b1c33e7f83cdaa99
 9d02e2626bdec0b230cb71103822c773979c516e
 b77dd130044c43fd12a3ce4adf645ef88d871a50
 3f0113be4ddb75e1e4dd159e58112e8c45ebdb12
 653c6f2edd82bdb9b9c4f8357be1ae0ed528b824
 1994e843d6bb144054356fc54e49f730e843e969

 I also included SDL changes since it might solve missing SDL support on
 some distros.

 Are there other revisions which developers thinks are crucial and safe for
 'a'? or maybe you think some revisions should be excluded from the list.

 Capbell, i might have added some extra commits from you, those i'd like you
 to check :)

 --
 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] MinGW buildbots

[Antony Riakiotakis]

It's been resolved since months already.

Sergey, plan sounds fine here.

On 16 January 2015 at 12:44, Caleb Joseph comcal...@gmail.com wrote:
 Slightly off-topic here, but has the OpenMP issue been resolved with
 MinGW-w64 yet?

 If I recall correctly, there were some issues with various parts of Blender
 when compiled with OpenMP because of a bug on MinGW-w64's end, I was just
 wondering if this has been resolved?
 On 16/01/2015 10:06 am, Antony Riakiotakis kal...@gmail.com wrote:

 Probably one of the slaves was my laptop but it's not idle enough to
 act as buildslave.

 Side note - I am preparing an upgrade to a MinGW-w64/gcc/4.9.2
 seh-posix based build for our supported platform.

 On 16 January 2015 at 00:02, Sergey Sharybin sergey@gmail.com wrote:
 Hi,

 There are two mingw64 slaves which were online for quite some time now (at
 least few months).

 Are they gonna to be maintained or we can hide them and stop trying to
 schedule builds on them?

 --
 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
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] MinGW buildbots

[Antony Riakiotakis]

Probably one of the slaves was my laptop but it's not idle enough to
act as buildslave.

Side note - I am preparing an upgrade to a MinGW-w64/gcc/4.9.2
seh-posix based build for our supported platform.

On 16 January 2015 at 00:02, Sergey Sharybin sergey@gmail.com wrote:
 Hi,

 There are two mingw64 slaves which were online for quite some time now (at
 least few months).

 Are they gonna to be maintained or we can hide them and stop trying to
 schedule builds on them?

 --
 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] Proposal: Up blender requirements to OpenGL 2.1

[Antony Riakiotakis]

Hello again,

The times of fixed function OpenGL pipeline have been very fun and
happy, with coders trying to ingeniously hack the fixed function
parameters to do the things they wanted.

But I believe we are getting to the point where fixed function OpenGL
starts holding us back. We already require GLSL support for some of
the fancier features of blender, but probably it's time to feel free
to consider shaders as the primary display mechanism if we want to,
without needing to code fallbacks to a fixed function alternative.

Especially anything that requires mixing multiple textures (such as
texture painting with masks or brush overlays) or attributes in a non
standard way is difficult without shaders.

This is scheduled to happen as part of the viewport refactor, but
having the hardware requirements there will enable us to do more
improvements now.

The proposal is not about throw away every legacy path next release,
rather than assuming that users will need to have access to newer
hardware from now on if they wish to access core features. Shader
availability can be tested to avoid crashes but no alternative
rendering path should be provided for those not meeting the
requirements.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Color space issues in importers/exporters

[Antony Riakiotakis]

Hello, we have a bug report that claims our importers do not do any
sort of color space correction
for external assets, see https://developer.blender.org/T43025

The issue should be that most exporters presume srgb color space while
our material definition is in linear space.

I am not sure if the asset formats have an explicit color space in
their specification but if not we can assume srgb. In that case, we
should make sure to backconvert from srgb to linear when doing
material conversion.

A quick test importing and exporting an obj from blender has no
issues, but that is simply because blender just dumps the linear
material value to the file, so reimporting will have the previous
value.

A way to fix this would be to handle it RNA side assume that assigned
colors are considered srgb and convert them internally but this can
backfire. It might be better to take care of it in our exporter files.

I am sending this to the list because we have a few maintainers for
our various asset formats.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Color space issues in importers/exporters

[Antony Riakiotakis]

From the comments on that report (thanks Brecht) it seems that not all
software exports to srgb after all.
The way I would solve this for such formats is to just have an
option so the user can select the color space their color data is in,
same as we do for images.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Missing 2.73 Release Notes

[Antony Riakiotakis]

Added most of my own as well, I'll do a pass of my commits later to make
sure I didn't forget any.

On 11 December 2014 at 17:52, Campbell Barton ideasma...@gmail.com wrote:

 The list is a bit rough but think its fine --- if you maintain that
 area and think its not needed for commit log. just remove from the
 list.

 (eg,
 https://developer.blender.org/rB13e9c44ce58b070913e2d385704c5a266f154b2e
 is such a minor change I didnt include).
 Its more a reminder to document changes that may need it.

 On Thu, Dec 11, 2014 at 4:26 PM, Thomas Dinges blen...@dingto.org wrote:
  Added mine too:
  http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.73/Cycles
 
  Although I have to say that this is pretty nit picky, since when do we
  note a different/changed *soft* UI range for a property? And the other
  was rather an internal optimization, nothing I considered noteworthy. ;)
 
  Am 10.12.2014 um 16:40 schrieb Julian Eisel:
  Hi all,
  The 2.73 release is getting close, but we are still missing quite a few
 features in the Release Notes. I searched through the commit history to
 find all the missing ones and compiled them into a list:
  http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.73/missing
  !! To every developer whose name is called in it: Please make sure your
 commit/feature gets into the notes ASAP !!
 
  Some of them are only really small changes, but we should try to make
 the Release Notes as complete as possible.
 
  Thanks a lot,
  - Julian -
  ___
  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



 --
 - Campbell
 ___
 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] Regarding: Cycles support for specular color in solid shading mode

[Antony Riakiotakis]

If we have two solutions only then the second worst is the best, right?
right?

Ahem

Most people (OK, that is two out of three admittedly :p) seem to agree that
the result is too bright and that extra controls are redundant.

In that case it makes sense to just dim the default material - the only one
users have no control over - and leave manual specularity control through
the color widget for the rest.

I'm going to leave this as is from now and see how others like it.

On 2 December 2014 at 02:30, Mikhail Rachinskiy wellmader...@gmail.com
wrote:

 Hi Antony,

 https://developer.blender.org/rB4ee53074aa951c42b0fb0899cd6376d124992304
 OK, you chosen the second worst possible solution for this issue.

 Would you also introduce new factor for default Cycles material?

 --
 Regards,
 Mikhail Rachinskiy
 jewelcourses.com
 rachinskiy.com

 On Mon, Dec 1, 2014 at 3:19 PM, Mikhail Rachinskiy wellmader...@gmail.com
 
 wrote:

  Or we can make default intensity value for BI materials equal to 1 to
 make
  materials look similar between BI and Cycles, after that we can lower
  default Diffuse and Specular RGB values for both BI and Cycles.
 
  I thinks it is the best possible solution which will not affect old
  materials and does not require additional factors.
 
 
  --
  Regards,
  Mikhail Rachinskiy
 
 ___
 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] Regarding: Cycles support for specular color in solid shading mode

[Antony Riakiotakis]

I don't mind insults (though I think they are not appropriate for this
list) but I just can't see how the solution you propose will be simpler and
more compatible. Perhaps a patch would help demonstrate this?

On 2 December 2014 at 12:06, Mikhail Rachinskiy wellmader...@gmail.com
wrote:

 We have three solutions:
 1. Leave it as is
 2. Introduce an extra factor (as you did)
 3. Make BI default intensity equal to 1, which will unify colors between BI
 and Cycles, and then just darken default RGB values (which is the only
 logical and simple solution which does not break compatibility)

 Your solution leads to more complicated code and supports ridiculous way to
 manipulate colors by additional factors instead by colors themselves.


 --
 Regards,
 Mikhail Rachinskiy
 jewelcourses.com
 rachinskiy.com

 On Tue, Dec 2, 2014 at 2:17 PM, Antony Riakiotakis kal...@gmail.com
 wrote:

  If we have two solutions only then the second worst is the best, right?
  right?
 
  Ahem
 
  Most people (OK, that is two out of three admittedly :p) seem to agree
 that
  the result is too bright and that extra controls are redundant.
 
  In that case it makes sense to just dim the default material - the only
 one
  users have no control over - and leave manual specularity control through
  the color widget for the rest.
 
  I'm going to leave this as is from now and see how others like it.
 
  On 2 December 2014 at 02:30, Mikhail Rachinskiy wellmader...@gmail.com
  wrote:
 
   Hi Antony,
  
  
 https://developer.blender.org/rB4ee53074aa951c42b0fb0899cd6376d124992304
   OK, you chosen the second worst possible solution for this issue.
  
   Would you also introduce new factor for default Cycles material?
  
   --
   Regards,
   Mikhail Rachinskiy
   jewelcourses.com
   rachinskiy.com
  
   On Mon, Dec 1, 2014 at 3:19 PM, Mikhail Rachinskiy 
  wellmader...@gmail.com
   
   wrote:
  
Or we can make default intensity value for BI materials equal to 1 to
   make
materials look similar between BI and Cycles, after that we can lower
default Diffuse and Specular RGB values for both BI and Cycles.
   
I thinks it is the best possible solution which will not affect old
materials and does not require additional factors.
   
   
--
Regards,
Mikhail Rachinskiy
   
   ___
   Bf-committers mailing list
   Bf-committers@blender.org
   http://lists.blender.org/mailman/listinfo/bf-committers
  
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers
 
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] Regarding: Cycles support for specular color in solid shading mode

[Antony Riakiotakis]

Alright, I guess that was just a language barrier here.

Don't worry too much about this amount of extra code complexity, I can
assure you there are much (like, much!) more complex corner cases in our
drawing code. While setting initial material colors to 1.0 would solve this
more elegantly maybe, it would also make everything brighter, which is what
the initial complaint was about. So while all this is admittedly slightly
crap, it is unavoidable crap, I just chose what I thought was the lesser of
two evils.

Anyway moving on, with new viewport this may not even be relevant
anyway...there might not even be solid
 mode anymore, rather workflow-oriented configurable shaders which won't be
tied to the material anymore.

Details will follow soon.

On 2 December 2014 at 14:33, Mikhail Rachinskiy wellmader...@gmail.com
wrote:

 Hi Thomas,

 I am sorry for my tone, I did not mean to be rude.

  default (no) material spec - what's the big deal with it?
 After Antony's last commit there is no issue with no material. The issue
 with material's color pipeline.

  An additional parameter and an if-clause with a multiplication should
 not be
 considered as complicated
 That's usually how it starts.

  For me and my co-worker is the current solution fine
 Current solution is acceptable for me, but if something could be simpler, I
 think it should be simpler.

 I understand Antony has more important work to do, like VSE improvements.
 But in one year Updated UI Widget Style project will be finished, all
 default colors may be reconsidered. By then Cycles will be default render,
 and the person who will use Cycles materials to prototype default colors
 for no material and BI default material may be confused, since Cycles
 materials have no additional factors dimming down the result — they're
 always be brighter than other cases.
 Yes this is not crucial, but I can't say this is not important.


 PS
 By the way I am actively using VSE, and every single improvement to it was
 marvelous, thanks Antony.

 --
 Regards,
 Mikhail Rachinskiy
 ___
 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] Regarding: Cycles support for specular color in solid shading mode

[Antony Riakiotakis]

Hi, due to the way material data is shared, such a unification cannot be
complete unless we have an extra slider for intensity, which I personally
feel would be redundant - color intensity provides a way to tweak the
intensity anyway so for materials other than the default it's easy to tweak
the result. What we could do is just make sure that the default (no)
material for cycles and blender internal look the same by introducing an ad
hoc factor of 0.8 for cycles. I wouldn't do it for all materials though or
we can get people complaining that their materials are not bright enough.
If more people really think the extra slider is necessary I see no big
problem with exposing it though.

On 1 December 2014 at 10:10, Mikhail Rachinskiy wellmader...@gmail.com
wrote:

 Hi,

 considering last commit:
 https://developer.blender.org/rB9124ecb16b220d314859ec4b1d67e6313bcc

 The difference between Cycles and Internal solid shading modes became too
 noticeable and not in favor of Cycles. Last commit enables specular color
 in viewport for Cycles makes it too bright and uncomfortable, because
 default diffuse color intensity in Cycles is brighter than in Internal:

 Here is few image comparison:
 No Material: http://i.imgur.com/PPeRRKM.png
 Default Material: http://i.imgur.com/1XxLmHD.png

 Default Material values:
 Cycles:  Diffuse RGB 0.8, intensity 1
 Internal: Diffuse RGB 0.8, intensity 0.8
 Cycles:  Specular RGB 1, intensity 1
 Internal: Specular RGB 1, intensity 0.5

 I do not know the values for “no material”.

 I want to propose if not to unify colors between Cysles and Internal solid
 shading modes, but at least to turn down viewport specular color for Cycles
 for both no material and default material shading (as it's not affecting
 render result anyway) to make it again comfortable looking.

 --
 Regards,
 Mikhail Rachinskiy
 ___
 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 platform things to do before 2.73

[Antony Riakiotakis]

I'm not sure if setting the OpenMP variable system wide is a nicer solution
than what we have, but +1 from me on warning about crappy OpenGL.

On 25 November 2014 at 14:49, Martijn Berger martijn.ber...@gmail.com
wrote:

 Hi everyone,

 I would like to propose

 - actually checking the OpenGL context when starting up blender.
- fatal error when less then the required OpenGL 1.4 is found.
- warning when less then OpenGL 2.1 is found (Nvidia  NV30 released in
 2003)

  There are some technical issue with giving the fatal error as it might
 be best to use an OS dependent dialog box explaining that blender cannot
 run on windows at least.
  Mac OS X is unaffected as all versions we support guarantee at least
 this capability.

  On windows at least this would make sure the bugs reported by people
 using GDI driven OpenGL 1.1 will not happen. Also it would get our users
 who still use blender on an pentium 3 with windows XP the ability to adjust
 to the fact that it might not always continue to work with the latest and
 greatest.

 - getting rid of the launcher.
   On windows we have a binary launcher that exists only to set an OPENMP
 related environment variable.
   I would like to get rid of this again in favour of setting it in the
 short-cut or setting the variable globally during install.
   Also we could and should check for this in the System Info.


 Both of these issues touch on the issue of giving the user feedback about
 his or her system configuration / hardware / settings and how they might
 negatively impact blenders performance. I would like feedback on how to
 handle these.

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

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

Re: [Bf-committers] [Bf-blender-cvs] [fae3850] master: Allow explicit control over world background.

[Antony Riakiotakis]

None as far as I know. This has struck me as odd in the past as well.
Committed
https://developer.blender.org/rB435eaa79b26c1b72287dd78df3ae7a1d79db3d32

On 24 November 2014 at 21:59, Joshua Leung aligor...@gmail.com wrote:

 Hi Antony,

 Is there any reason why this *still* isn't applied for OpenGl renders too?
 For certain workflows (e.g. Grease Pencil shorts) where having that makes
 it easy to render things out as intended.

 Joshua
 On 25/11/2014 2:29 AM, Antony Riakiotakis nore...@git.blender.org
 wrote:

  Commit: fae385029394159428799ef0ec690dd6c31e4b72
  Author: Antony Riakiotakis
  Date:   Mon Nov 24 14:29:09 2014 +0100
  Branches: master
  https://developer.blender.org/rBfae385029394159428799ef0ec690dd6c31e4b72
 
  Allow explicit control over world background.
 
  Previosuly, world was shown on the background if Render Only was used.
  Now user should be able to set it independently. This is a prelude to
  (drumroll)...
 
  ===
 
  M   release/scripts/startup/bl_ui/space_view3d.py
  M   source/blender/editors/space_view3d/view3d_draw.c
  M   source/blender/makesdna/DNA_view3d_types.h
  M   source/blender/makesrna/intern/rna_space.c
 
  ===
 
  diff --git a/release/scripts/startup/bl_ui/space_view3d.py
  b/release/scripts/startup/bl_ui/space_view3d.py
  index 0ea552e..d0cfd19 100644
  --- a/release/scripts/startup/bl_ui/space_view3d.py
  +++ b/release/scripts/startup/bl_ui/space_view3d.py
  @@ -2813,6 +2813,7 @@ class VIEW3D_PT_view3d_display(Panel):
 
   col = layout.column()
   col.prop(view, show_only_render)
  +col.prop(view, show_world)
 
   col = layout.column()
   display_all = not view.show_only_render
  diff --git a/source/blender/editors/space_view3d/view3d_draw.c
  b/source/blender/editors/space_view3d/view3d_draw.c
  index 21329e6..d681915 100644
  --- a/source/blender/editors/space_view3d/view3d_draw.c
  +++ b/source/blender/editors/space_view3d/view3d_draw.c
  @@ -3211,7 +3211,7 @@ static void
 view3d_main_area_draw_engine_info(View3D
  *v3d, RegionView3D *rv3d, A
   static void view3d_main_area_clear(Scene *scene, View3D *v3d, ARegion
 *ar)
   {
  /* clear background */
  -   if (scene-world  (v3d-flag2  V3D_RENDER_OVERRIDE)) {  /*
  clear with solid color */
  +   if (scene-world  (v3d-flag3  V3D_SHOW_WORLD)) {  /* clear
  with solid color */
  if (scene-world-skytype  WO_SKYBLEND) {  /* blend sky
 */
  int x, y;
  float col_hor[3];
  diff --git a/source/blender/makesdna/DNA_view3d_types.h
  b/source/blender/makesdna/DNA_view3d_types.h
  index 3efba48..0eee28e 100644
  --- a/source/blender/makesdna/DNA_view3d_types.h
  +++ b/source/blender/makesdna/DNA_view3d_types.h
  @@ -201,7 +201,9 @@ typedef struct View3D {
  char gridflag;
 
  /* transform widget info */
  -   char twtype, twmode, twflag, pad2[2];
  +   char twtype, twmode, twflag;
  +
  +   short flag3;
 
  /* afterdraw, for xray  transparent */
  struct ListBase afterdraw_transp;
  @@ -267,21 +269,24 @@ typedef struct View3D {
  ((view = RV3D_VIEW_FRONT)  (view = RV3D_VIEW_BOTTOM))
 
   /* View3d-flag2 (short) */
  -#define V3D_RENDER_OVERRIDE4
  -#define V3D_SOLID_TEX  8
  -#define V3D_SHOW_GPENCIL   16
  -#define V3D_LOCK_CAMERA32
  -#define V3D_RENDER_SHADOW  64  /* This is a
  runtime only flag that's used to tell draw_mesh_object() that we're
 doing a
  shadow pass instead of a regular draw */
  -#define V3D_SHOW_RECONSTRUCTION128
  -#define V3D_SHOW_CAMERAPATH256
  -#define V3D_SHOW_BUNDLENAME512
  -#define V3D_BACKFACE_CULLING   1024
  -#define V3D_RENDER_BORDER  2048
  -#define V3D_SOLID_MATCAP   4096/* user flag */
  -#define V3D_SHOW_SOLID_MATCAP  8192/* runtime flag */
  -#define V3D_OCCLUDE_WIRE   16384
  -#define V3D_SHADELESS_TEX  32768
  -
  +#define V3D_RENDER_OVERRIDE(1  2)
  +#define V3D_SOLID_TEX  (1  3)
  +#define V3D_SHOW_GPENCIL   (1  4)
  +#define V3D_LOCK_CAMERA(1  5)
  +#define V3D_RENDER_SHADOW  (1  6)/* This
 is
  a runtime only flag that's used to tell draw_mesh_object() that we're
 doing
  a shadow pass instead of a regular draw */
  +#define V3D_SHOW_RECONSTRUCTION(1  7)
  +#define V3D_SHOW_CAMERAPATH(1  8)
  +#define V3D_SHOW_BUNDLENAME(1  9)
  +#define V3D_BACKFACE_CULLING   (1  10)
  +#define V3D_RENDER_BORDER  (1  11)
  +#define V3D_SOLID_MATCAP   (1  12)   /* user flag */
  +#define V3D_SHOW_SOLID_MATCAP  (1  13)   /* runtime flag */
  +#define

Re: [Bf-committers] Usability Suggestion for Pie Menu

[Antony Riakiotakis]

I am not sure I understand what the request is here...Have an explicit
drag/click style option I guess?

On 24 November 2014 at 17:44, - LEON - leon4...@gmail.com wrote:

 My students who have recently shifted from Maya were experiencing a bit
 pain with our pie menu behaviour comparing to Maya's pie. To be exact, if
 the mouse is not moving before shortcuts released, then they have to either
 click on one of the items, or press ESC or RMB to quit. I mean, this extra
 click for confirmation seems unavoidable even for quit only, especially
 when pie keys are mis-triggered.

 Believe me, I know it was designed by design, and for good :), which may be
 helpful for those who got no mouse (when playing with notebook, for
 example). However, I bet that for the majority, press-drag-release' flow
 would be their first choice and used much more often than the
 press-release-click flow.

 So, I may propose to expose it as a toggle. Because, for those who totally
 don't need it it can be more or less an efficiency killer, which they have
 to bear with.

 Thanks for your attention.

 --
 Leon Cheung
 a.k.a. Zhang Yu | 老猫
 ___
 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] make project_netbeans, submit changes

[Antony Riakiotakis]

Hi, you can submit a patch with the changes you've made to the blender
source code using git diff
 and you can paste the patch for review in the differencial system of our
tracker in developer.blender.org.

On 30 October 2014 17:26, Сергей igel...@gmail.com wrote:

 Hello,

 I cloned git://git.blender.org/blender.git repository (commit:
 d8094b62e21d0a98c8d3f22631c2c978b2390609),
  then i run 'make' command,
  then i run 'make project_netbeans'

 In the end i got a truncated nbproject/configurations.xml file
 This is due to the fact that the file configurations.xml not closed in the
 script cmake_netbeans_project.py

 I've corrected the script (just added call f.close() at the end of the
 function 'create_nb_project_main')
 How do I submit my changes back to the blender git repository?
 ___
 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] Viewport project planning

[Antony Riakiotakis]

Hi,

I'm writing here so we have a public record of who is supposed to work on
what for the viewport project.

So, a part of the project is to merge the GSOC branch. Jason Wilkins has
offered to help here.

I want confirmation on the following:

The 2014 GSOC branch basically has the internal API for vertex streaming
plus some basic infrastructure for material support (aspect) which is not
functional. The vertex streaming part is not hooked up to the rest of
blender in the 2014 branch - it used to be in the GSOC 2013 branch though.

So, for merging I propose we keep only the stuff that were tested and
worked in the 2013 branch. That means as far as I know:

* Hook up the vertex stream code to the rest of blender again.
* Separate the aspect system for a future release.

There are some patches for review - notably debug utilities:
https://developer.blender.org/D706
and canonical binding (for which I am unconvinced though - adds too many
chains of define-undefine).
https://developer.blender.org/D699

I'd suggest we focus on the important things though, which is the vertex
streaming functionality itself. If we can have that as a monolithic patch
it would help with less review overhead.

Jason, is a monolithic patch possible? Do you see any roadblocks or issues
here? Can it be done without the canonical binding part? Do you need any
help with this?

Also  I am interested in hearing Alex Kuznetsof's take on the GLES
project...what the state of the code is, what is needed still to make it
fully working, does he have time to work on it etc.

Generally, if we are to merge the branch in this release, we need to have
something ready in about 3 weeks. Maybe there can be an extension if we are
close by then.

I can spend time redesigning the vertex buffer object system and material
code in a separate branch, which can be added later but I can also work on
getting the branch up to speed too if people are unavailable to work on it.
It would help if I am given notice of this early on though.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Texture and Texture Mask from Image Load

[Antony Riakiotakis]

Hi,

A UI that allows users to tweak texture values directly would not be bad (I
was almost thinking about using a separate texture tab with more options
even). I would never expose texture nodes as -the- way to do texturing
though. They are too buggy atm (with threaded issues, conflicts with
rendering etc not being uncommon at all) and we just do our best to sort-of
keep them working. You should really use at your own risk.

On 8 October 2014 11:44, Ronan Ducluzeau zeau...@gmail.com wrote:

 It is surprising that a similar quick setup was not added in GSOC Paint.

 Of course, a Create texture from image file button could be used
 everywhere there is a add new button for textures.
 Maybe, it could made by a shift click on add new button in relevant
 cases.

 It reminds me that Texture node input for BI or BGE does not have a simple
 add new button.

 2014-10-07 1:39 GMT+02:00 Johnny Matthews johnny.matth...@gmail.com:

  Campbell and Antony (and any other interested dev)
 
  Not sure if you two are interested in this little script I created, that
  adds a button to the Brush Texture and Texture Mask panels that opens a
  file browse window, takes a selected image file, creates a new texture
 node
  tree using the image and assigns it to the appropriate brush setting.
 
  demo: https://www.youtube.com/watch?v=vM4539XqiQc
 
  If you want, let me know and I'd be happy to send you what I have and you
  can chop the idea up and use it if you like.
 
 
  Johnny Matthews
  johnny.matth...@gmail.com
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers
 
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] Brushes

[Antony Riakiotakis]

The only purpose is that brushes could coexist in different paint systems,
however this is not supported in blender (maybe yet, but it would take
quite long to fully support). I agree that until then  we should really
clean those up.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Viewport project

[Antony Riakiotakis]

Hi, I have posted a blog post on code.blender.org about the design and
targets of the viewport project.

http://code.blender.org/index.php/2014/09/viewport-project-targets-current-state-of-the-code/

Feedback (and contributions!) are encouraged and welcome!
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Credits Page

[Antony Riakiotakis]

Is it possible to correct patch application with arcanist to also use the
original author? I've been bitten by this before, not acknowledging patch
authors properly.
If not better make it a rule to also not apply patches through arcanist.

On 21 September 2014 10:05, Sergey Sharybin sergey@gmail.com wrote:

 Campbell, i'm not sure what's up to phabricator here. If you want to know
 some data about old patches i can write an exporter for you. For the new
 one using neither maniphest nor differencial is gonna to be accurate --
 with all that tendency to commandeer revision the revisions and those devs
 who doesn't use use arc to commit and screws things up, leading to need to
 abandon the revision instead of marking it as applied, the stats are not
 gonna to be accurate.

 We do need to use proper authorship of the git commits, that would solve
 hell of a lot parsing issues, which currently sounds just weird to have.
 Even more -- it's much cooler when the commit is authored by you instead of
 having just Path by Awesome Guy.

 For this we've got like everything, apart from the email. For this:

 - Phabricator considers this a private information and will show it to
 nobody.
 - You need to ensure someone is OK to provide his email for the commit.
 - You only need to do this once, it's very much likely someone sent some
 patch in the past.
 - You can you use empty email, by explicitly specifying : git commit -a
 --author Awesome Guy  -m Patch adds some real awesome things.
 - By you i mean the one who applies the patch.
 - Personally i'd just make it a rule to sue proper authorship, it's not mre
 difficult than typing Patch By anyway.

 And again, if some data from the past is needed to be exported, i'd suggest
 exporting it once using php script, putting it as a .py dict and use it by
 the script which traverses the git repo to gather contributors.



 On Sun, Sep 21, 2014 at 8:27 AM, Harley Acheson harley.ache...@gmail.com
 wrote:

  Removing the page seems like an extreme reaction.
 
  Why not just keep the page creation as it is right now but then *insert*
  a static html list of the missing 253 names into an Also Thanks To
  section until you have this problem sorted out properly?
 
  Cheers, Harley
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers
 



 --
 With best regards, Sergey Sharybin
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] Withdrawal

[Antony Riakiotakis]

I wouldn't say no to a WIP/Regression scheme. It would be clearer to people
reading the logs or not knowing that code.
 Of course we might forget to do properly or some coders might not like it.
Why not just let coders who like it do it and see how it works?
 The need for meaningful commit messages is taken for granted I think.

On 16 September 2014 08:58, Campbell Barton ideasma...@gmail.com wrote:

 On Tue, Sep 16, 2014 at 4:40 PM, Sergey Sharybin sergey@gmail.com
 wrote:
  @campbell, that sounds to much burocratic for me

 Agree, and I hesitated to propose for this reason.

  :) IMO it'll be just
  easier to be more verbose in the commit log, so it's not just Fix TXXX:
  Foo bar, but also:
  - Includes a bit of explanation what da heck was going on. Having like
  few-kilos-long patch with just title copy-pasted from the tracker is not
  that useful at all. That could be considered a separate topic, a part of
  some code style guideline to help other developers to understand
 what/why
  was changed. might deserve separate thread in the ML perhaps, but it's
  somehow glued in here.
 
  - For the regressions fixes we already did things like To be backported
 to
  final release post-scriptum for 2.71. Worked rather fine, was much
 easier
  to keep track of what fixes are to be for sure ported over. It never
 meant
  to be some some strictly specified sentence for that btw. We're not
 robots,
  so why to construct such a rules?
 
  - Think the same less formal approach would work better for making Bug
  Fixes section generation easier.Could be like This bug was introduced in
  blender 2.69 or The same happened in the release or whatever else.
 
  - Also, for me it was always an issue to parse some developer's commits
 to
  get meaningful information. For example formation like Fit TXXX\nNeed to
  do foo to solve bar is rather a total crap. You ends up going to the
  tracker, reading the description, tries to explain that in one sentence.
  Also sometimes commit logs are like Fix TXXX: Blender total crash.
 What i
  mean is: it's more important to make sure the description of bug in the
  commit message is explicit enough for the release notes page generation.
  Maybe more important than indication of regression/ongoing fixes
 indication.

 IMHO this is 2 issues - having well written commit log is fine, but
 wont ensure you can tell if the error thats fixed was present in last
 release or not.

 If I had to write The same happened in the release after every
 commit that fixes a bug in a release, IMHO this is more annoying then
 having some convention/keyword, everyone will write it a bit
 different, or forget to write, and it means more to read when
 gathering commits to include in release notes.

 At this point I wonder if we should really be spending this time to
 gather fixes for each release, the lists from previous releases are
 incomplete or include fixes for bugs not in the previous release, its
 just not very accurate and automatically selecting commits for
 inclusion involves adding some kind of meta-data to each commit which
 ends up being bureaucratic  devs probably end up not using.

  @troubled, that's just an overkill.
 
  On Tue, Sep 16, 2014 at 9:28 AM, Trouble Daemon troubledae...@gmail.com
 
  wrote:
 
  What about using git notes?
 
https://kernel.org/pub/software/scm/git/docs/git-notes.html
 
  Dan
 
  On Mon, Sep 15, 2014 at 10:10 PM, Campbell Barton ideasma...@gmail.com
 
  wrote:
 
   To follow up on a related point.
  
   Making this list of bugfixes is quite time consuming and unless you
   read the commit logs daily _and_ know the code, its quite hard to tell
   which issues to include in the release log.
  
   It would be good if there was some indication from a commit to know if
   the bug is from some recent change, or if its a bug in the previous
   release.
  
  
   Suggest we could indicate this in the subject:
  
   - Fix T1234: Some Text
   - WIP Fix T1234: Some Text
   - Regression Fix T1234: Some Text
  
  
   Meaning:
  
   - Fix - regular fix for a bug existed in last release.
   - WIP Fix - fix for change in new code (never in a release)
   - Regression Fix - fix for bug introduced in a release.
  
  
   Many fixes would be WIP, so at a glance we can tell not to include
   (its useful for reading commit logs too).
   Often I write something like Fix for recent change in ... so typing
   'WIP' is less hassle.
  
   Although I'm not sure its practical to enforce this long-term (we
   attempted complicated conventions before and ended up not using).
  
   Any suggestions?
  
   On Mon, Sep 15, 2014 at 5:08 AM, Gavin Howard 
 gavin.d.how...@gmail.com
   wrote:
Well, if I don't get it done, you have to. The time constraint was
 so
you could expect it done before having to work on it yourself.
   
On Sun, Sep 14, 2014 at 1:04 PM, Sergey Sharybin 
 sergey@gmail.com
  
   wrote:
Sounds cool, only not sure why to define such a time constraints?
   
   

Re: [Bf-committers] Default inset tool behavior

[Antony Riakiotakis]

I would agree on that.


On 6 September 2014 23:52, gandalf3 zzyx...@gmail.com wrote:

 Almost every time I use the inset tool I find myself disabling the
 select border option in the redo panel.

 Am I the only one? If there are others who also feel like this is the
 case, should this option be disabled by default? Or perhaps a keyboard
 shortcut added to change this option?

 --
 -gandalf3

 ___
 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] Generated image saving

[Antony Riakiotakis]

Hi, currently there are some issues with generated images getting easily
lost. With texture painting in master, this issue has attracted more
attention so I have made a task with some proposed solutions here:

https://developer.blender.org/T41598

Any feedback welcome, especially from developers.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Doubt about bumps.

[Antony Riakiotakis]

As far as I can tell, bump maps in our texture code simply operate with
derivatives between neighbouring pixels, so there's really not any ground
level there.


On 26 August 2014 17:18, Eugenio Pignataro i...@oscurart.com.ar wrote:

 Hi guys!

 We have a doubt about bump maps, the standard b/w, does the bump map has
 a base grey color? or black color its base color for bump?. As far as i
 know displace modifier has gray base color, black goes down whites goes
 up, but bump map?

 Thanks in advance!


 --
 Untitled Document

 Eugenio Pignataro
 Drawing  Digital Art.
 ---
 Sitio: www.oscurart.com.ar
 Reel: vimeo.com/92253804
 Email: i...@oscurart.com.ar
 Móvil: 15-5177-4936
 ___
 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] GLSL display mode

[Antony Riakiotakis]

Hi,

The merge of the paint branch brought material display support in the 3d
viewport.
This means that users can get the equivalent of the GLSL textured display
mode just by choosing material display mode in the 3D viewport.

Now the option itself is redundant for the blender content creation system
but trying to eliminate the option, I found that the game engine uses the
GLSL flag too, and as a global option rather than a per editor flag
instead. One thing I could do is just hide the option when the game engine
is inactive. Alternatively, we could simplify this by supporting GLSL
materials in the game engine based on editor. However this might not be
what game engine users or developers would like. Personally I don't mind
having this kind of duplication but a user asked about it today and
arguably it's two ways to do the exact same thing.

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

Re: [Bf-committers] Duplicated commits in soc-2013-paint?

[Antony Riakiotakis]

To fix that locally I would reset to a safe commit and then cherry pick any
real commits thereafter. Not sure how to proceed with public branches
though.


On 12 July 2014 15:06, Dalai Felinto dfeli...@gmail.com wrote:

 Hi,

 From the look of bf-cvs and the tracker it seems something went wrong in
 recent commit from soc-2013-paint. Basically some master commits showed up
 as commits (with new hashes) in the branch (triggering new emails in bf-cvs
 and adding new related commits to already closed bug reports).

 Is that normal? It's the first time I see this. It seems that either rebase
 was used or the merge went wrong.

 Cheers,
 Dalai
 ___
 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] Duplicated commits in soc-2013-paint?

[Antony Riakiotakis]

Follow up, we did some tests here (checkout new branch from safe commit,
cherry pick from the initial branch, merge master, diff between the two)
and seems all is fine here.

Moving on :)


On 12 July 2014 16:14, Antony Riakiotakis kal...@gmail.com wrote:

 To fix that locally I would reset to a safe commit and then cherry pick
 any real commits thereafter. Not sure how to proceed with public branches
 though.


 On 12 July 2014 15:06, Dalai Felinto dfeli...@gmail.com wrote:

 Hi,

 From the look of bf-cvs and the tracker it seems something went wrong in
 recent commit from soc-2013-paint. Basically some master commits showed up
 as commits (with new hashes) in the branch (triggering new emails in
 bf-cvs
 and adding new related commits to already closed bug reports).

 Is that normal? It's the first time I see this. It seems that either
 rebase
 was used or the merge went wrong.

 Cheers,
 Dalai
 ___
 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] Running Blender from Command Line skips Auto Execution of Driver Scripts

[Antony Riakiotakis]

When reporting an issue, it is very important to make it easy for others to
reproduce the issue, so a blend file set up in a way that requires a
minimum amount of steps to reproduce the issue should be included. On the
steps you have included above there are too many steps left for others
already. A file that has steps 2 and 3 should be set up and and a
description of the expected behaviour should be included or we cannot know
if we are on the same ground.

Our bug tracker is ideal for such discussions. It allows attaching files,
even if this is not really a bug we can determine it there, and such
discussions do not really belong on the mailing where people not interested
in the bug end up getting emails about it.

In general, if unsure, report anyway. Worst case we close the report with
an explanation. We do not hunt people with pitchforks for invalid bug
reports unless it is a blatantly trolling case.


On 10 July 2014 03:05, Chris Lee infin8...@gmail.com wrote:

 I'll report the bug once I get someone to confirm the steps required to
 reproduce it. Otherwise it is wasted.

 Somebody please help me test this.

 I have worked in support before. We need to establish it is reproducable
 under similar conditions.

 Like you said Campbell, you didn't get the same problem. What were the
 steps you used? I guess you didn't refer to an external python file. If
 that is so, then you ran Blender from command line and found auto execute
 working.

 Please provide more detail so I can establish this as part of trouble
 shooting.
 On 10/07/2014 9:57 AM, Campbell Barton ideasma...@gmail.com wrote:

  Hi Chris,
  These issues should really be handled in our bug tracker -
  http://developer.blender.org
 
  On Wed, Jul 9, 2014 at 4:35 PM, Chris Lee infin8...@gmail.com wrote:
   Campbell can you run a test for me to see if you get the same result?
   Or somebody else that is willing to help.
   I need a Blender coder that knows what they are doing to test this and
 I
  do
   not have one available.
  
  
  1. Take a default scene with Auto Execute turned on in User
  Preferences.
  2. Create a driver for a cube to scale according to it's z axis, as
 a
  scripted expression.
  3. Then create a python script to move that object up on the z axis.
  4. Then run that script from the command line and tell me if it
  ignores
  the auto execute user preference setting.
  
   See my previous post for an example of running the python script from
   command line (well, I am using the Run command in windows).
  
   Kind Regards,
   Chris *Chips* Lee
   Mobile: 0410155111
  
   Infin8eye http://infin8eye.carbonmade.com/
   Knight of the DLF
   IGDA Sydney founding member
  
  
   On 9 July 2014 15:47, Campbell Barton ideasma...@gmail.com wrote:
  
   User preferences is used from command-line on my system. did very
   simple test with registered text-block and preferences are respected.
  
   This seems more like it should be a bug report, though this code didnt
   change recently and reports here were mostly user error so far, but
   its possible there is some bug.
  
   On Wed, Jul 9, 2014 at 3:31 PM, Chris Lee infin8...@gmail.com
 wrote:
On 9 July 2014 15:24, Campbell Barton ideasma...@gmail.com wrote:
   
if you know the origin of files and trust them, you can change your
preferences too.
   
   
Okay, in really simple terms, when running blender from command
 line,
  it
ignores your preference for running auto run scripts when starting
   Blender.
Is this a bug?
   
   
Kind Regards,
Chris *Chips* Lee
Mobile: 0410155111
   
Infin8eye http://infin8eye.carbonmade.com/
Knight of the DLF
IGDA Sydney founding member
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
  
  
  
   --
   - Campbell
   ___
   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
 
 
 
  --
  - Campbell
  ___
  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] Learning Blender Code?

[Antony Riakiotakis]

Yes at the beginning it is going to take a lot of time, even days. Don't
give up, perseverance is the
key to successful anything. Even when you feel you do not get anywhere you
slowly gain experience and understanding and it will yield fruits for sure
in the end.


On 2 July 2014 19:01, Jacob Merrill blueprintrand...@gmail.com wrote:

 Logic nodes are not GPL apparently. ... so this would unlock the bge for
 commercial development.

 Also skipping the python interpreter would make
 It smoking fast.
 On Jul 2, 2014 8:58 AM, Jacob Merrill blueprintrand...@gmail.com
 wrote:

  I have a task, that would unlock the true power of of the bge Logic
  nodes, allow sensor input in a property node.
 
  Like
 
  Rayand---property target =Ray hitObject
 
  Or
  Messageand-property message =message Bodies[0]:
 
  Basically a dropdown to select any sensor in a object, and then any
  variable.
 
  Also, adding the data type gameObjectKey and allowing them to be sent
 with
  messages would be nice.
  On Jul 2, 2014 8:50 AM, Howard Trickey howard.tric...@gmail.com
 wrote:
 
  Some introductory FAQ material is here:
  http://wiki.blender.org/index.php/Dev:Doc/FAQ#Source_Code_FAQ
 
  As it says there, reading all of the docs on
  http://wiki.blender.org/index.php/Dev:Source/Architecture
  is useful, though hard-going and somewhat out of date.
 
  It's probably best to start on just a small area of the code and not
 worry
  about the rest.
  Follow through what happens when you execute some command in an area
 that
  you are interested in.
  Do what you are trying to do: fix a small problem or make a small
 feature
  change in that command.
  Probably doing a NURBS task isn't the best idea to start, since there
 is a
  summer student right now working on revamping NURBS, and anyway that
 code
  is fairly old and somewhat removed from the modern part of Blender.
 
  - Howard
 
 
  On Wed, Jul 2, 2014 at 11:07 AM, John Alway jal...@gmail.com wrote:
 
   Hello,
  
   I've been working to understand Blender code so that I can try my hand
  at
   fixing some bugs and adding some features as needed.   However, I'm
  finding
   the learning curve to be quite steep.   C and C++ code per se are no
   problem for me, but it's hard to determine what the code is doing,
  because
   there are many abstract concepts that have been implemented.
  
   I was trying my hand at Issue T39656, just to see what it would take:
   https://developer.blender.org/T39656
  
   And, to help me along, I've been using the Visual Studio debugger and
  I've
   read many things out of the wiki, including this overview:
  
   http://wiki.blender.org/index.php/Dev:Source/Architecture/Overview
  
   However, at the end of the day, this is proving to be pretty heavy
  going.
  
   So, I'm wondering how others have learned the code, or is it just a
  matter
   of putting in lots of time?
  
   I do know OpenGL and I have studied many graphical concepts, and I've
  done
   a lot of matrix math for rotating and translating objects, etc.   But,
  I'm
   sure there is much to more learn, anyway.  There always is!
  
   Anyway, I'm just looking for pointers and any kind of help on this.
  
   Thanks for any feedback!
   ...Regards,
   John
   ___
   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] Color picker redesign, continued

[Antony Riakiotakis]

Hi,

In the 2.71 release I have unfortunately caused a small disturbance due to
my decision to change the HSV setting in color wheels to be in display
space.

Some explanation is due: This was to address an important issue of color
pickers, which was that you never got the exact color you chose, especially
for linear color properties.

The issue here, is that the color displayed is calculated by first doing a
non-linear transform (linear to srgb usually) followed by the linear
transform (barycentric interpolation on the rasterized triangle), while the
value calculated if we do the HSV calculation in linear space, is first
interpolation in HSV (linear interpolation for each piece of the HSV
circle) followed by the non-linear interpolation. It is only natural that
those two values will differ due to linear and non linear transforms not
being commutative.

The solution I have chosen for the 2.71 version is to make sure all HSV
values are in display space. This guarantees we always get the correct
color, which can then be transformed back to the linear space.

Sadly, we ran into issues:

First, it is a common workflow for people to tweak HSV values in linear
space. Especially on rendering this helps with giving an upper bound to
radiance reflected back from a material, by tweaking the color value.

Also for values greater than one, the non linear transform back to linear
rgb can give very bizzare results (See https://developer.blender.org/T40131)

Apparently we must do the interpolation in the property space, and then use
a per pixel transform (easily done by binding a pixel shader through OCIO)
to correct the result for display.

However, we also have another use case which is still not correct enough
and that gave rise to some discussions.

Apparently, it is beneficial to do the calculation on a different
intermediate space.
This is already done in our Cubic style color pickers which -still-
suffer from incorrect display of colors. Generally it may be that, in fact,
many spaces might be disarable as an intermediate calculation space. This
can be hardcoded but can also be configured, through a color picker role
for instance.

In such a workflow, HSV is still calculated in this intermediate space (I
am still unsure if HSV is defined exactly the same for each space though,
which would complicate things), the final display is calculated from pixel
shading and the selected color is taken by transforming from HSV to
intermediate space to initial color space.

Just hooking a display shader for linear properties can work for solving
the current issues, but I was wondering if fixing this might present an
opportunity to take more issues into account.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Color storage - color pickers

[Antony Riakiotakis]

There is something thing that looks error-prone with the current color
storage scheme: Any colors stored as PROP_GAMMA will be stored in the space
of the device the file was saved in. This will invalidate those if the file
is opened on a computer where the display device is different. Maybe all
color properties should be stored as linear (or reference space) instead?
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Particle polygonizer

[Antony Riakiotakis]

That would be great! We will also be looking at revamping blender's hair
and cloth system for the gooseberry project.
Mostly we are going to be looking at robust collision detection, tools and
code design at the beginning.


You might want to drop by on irc. We are on channel #blendercoders on
Freenode
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] libgomp: Thread creation failed

[Antony Riakiotakis]

A proper bug report (a file that shows the issue, system information etc)
will help us solve this properly. This too little information to do
something about it.

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

Re: [Bf-committers] Preview Icon alpha

[Antony Riakiotakis]

I see, thanks for the correction!

Given that most icon images are pngs with the exception of matcaps which
are jpeg and are assumed to be alpha 1.0, and we use byte storage, then I
guess the blend function is to change here.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Preview Icon alpha

[Antony Riakiotakis]

Hi,

I am in the process of updating the paint brush icons [1] and I have been
looking at the icon preview code, file interface_icons.c, function
icon_draw_size.

There are some caveats in the code:

First, we assume premultiplied images, while the pngs used from our
data_to_c conversions use straight alpha.

The second thing is that it looks as if we do not enable blending for icon
previews, which would be cool (new set of icons would work nice if used
with transparency, for instance, as would custom brush icons, I understand).

For the first issue I can convert the images to premultiplied space
externally but then other png's might bite us similarly. Maybe the best
would be to premultiply during data_to_c conversion? For the second issue,
I'm not sure if enabling blending could bite us in other icon rendering
cases.

Thoughts?

[1] https://developer.blender.org/T37960
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting, April 20, 2014

[Antony Riakiotakis]

Hi,

Today I added the current state of the code in blender's git repository.

Just checkout the pie-menus branch. Still unfinished though, don't expect
to see miracles. The only thing that is pie-fied in the branch is the
stroke mode for sculpting (A key).
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender 2.70a OpenMP issues

[Antony Riakiotakis]

I don't disagree with anything, only thing I can say is that from current
information, it seems like different parts of blender are influenced
differently from different openmp number of threads, hence the separate
setting here.
I agree this is impossible to track on every system configuration though,
and it is quite hacky to plug custom code to every case.

Sculpting, as far as I know currently restores the behaviour after a stroke
is finished. Having the setting per scene was supposed to follow the per
render thread settings.

That said, I think we can remove the option since it looks like for
sculpting automatic detection gives the optimum, but I can't tell about
other parts. I seem to remember gcc did not work as well everywhere either,
but jens can give more information here.


On 9 April 2014 20:42, Sergey Sharybin sergey@gmail.com wrote:

 Hello everyone,

 Just wanted to outline some issues which i want to be solved before 2.70a
 release.

 There are couple of issues with the current approach i didn't like at all:

 - We never should expose programmer slang to the interface. How normal
 human being would know what OpenMP is, what it affects n and so on.
 - Adding this new field breaks translations which is not good at all for
 'a' release.
 - Workaround for this two issues might be using Threads instead, which is
 more clear for artists and have a translation already. BUT!
 - Why on earth OpenMP threads is a per-scene setting? Why would one want to
 use N threads in scene A and K threads in scene B? Further, OpenMP is NOT
 only sed by sculpt brushes, it's also used by multires, simulations, some
 bmesh core, custom data (afair), libmv, ceres.. This makes the option from
 sculpt mode's toolshelf affect on loads of areas, which is REALLY bad and
 unpredictable.
 - As a workaround for this issue, the openmp setting is to be moved to the
 user preferences instead.

 I call it workaround because it's really ugly hack to expose such settings
 to user hoping it will solve anything. The thing here is -- as far as i
 understand the root of the issue goes to the fact that new clang on osx
 have performance issues for SOME configurations. I don't see the reason why
 would windows or linux artists change this settings. Actually, i'm not even
 sure why one would think of changing the setting if he thinks performance
 is not good enough.

 We really need to address the root of the issue rather than adding obscure
 settings for artists. And if it's not doable with clang on osx -- i'd
 suggest roll back to gcc which is proven to work. Don't see reason to push
 using clang here.

 --
 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

Re: [Bf-committers] Vertex Buffer Object/Vertex Buffer Array

[Antony Riakiotakis]

Hi,

Added a patch here

https://developer.blender.org/D452

This should serve as a good start for getting rid of quite a lot of ultra
legacy calls.


On 4 April 2014 22:26, Brecht Van Lommel brechtvanlom...@pandora.be wrote:

 Yes, I agree, it would be a clear improvement to use vertex arrays
 even if VBO's are turned off.

 On Fri, Apr 4, 2014 at 8:08 PM, Antony Riakiotakis kal...@gmail.com
 wrote:
  It has struck me as odd that we have support for vertex arrays AND vertex
  buffer objects wrapped in the same code and we still fall back to
 immediate
  OpenGL mode if VBO option is off.
 
  Vertex Arrays are included in OpenGL 1.1 and blender already requires
  OpenGL 1.4 if I remember correctly. They are also faster than immediate
  mode. And apart from that, OpenGL 1.1 has been everywhere since
  like...forever!
 
  We have to spend so much energy maintaining both front-ends, where
  maintaining just one would be much simpler.
  ___
  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] Access to object during drawing

[Antony Riakiotakis]

Hi,

For the new code that displays meshes in texture paint for gsoc, I will
need access to the material at gpu buffer build time. This in turn requires
access to the object, since the code only has access to the derived mesh.

Is there some way to get it? I can only see getting this through
GPUMaterialState but I'm not sure if such a way is nice due to using a
global variable. I see we also have some other uses of global variables
such as  Gtexdraw.

Maybe adding an extra Object pointer to the derived mesh would help here?

Access to the Object would solve some other nice stuff we have, such as
allocating MAXMAT arrays on the stack at GPU buffer creation time.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] MinGW-w64 pthread update

[Antony Riakiotakis]

Hi,

There has been a multitude of fixes to the pthread library of MinGW-w64
recently.

All knowns cases for trouble:

* Openmp related - includes hangs on rendering with multithread/subsurf and
physics baking,
* Crashes on painting
* Crashes on depsgraph update

All seem to function correctly now. Of course there may still be cases I am
not aware of but the builds should be much safer to use now :)
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Revisions for the 2.70a release

[Antony Riakiotakis]

Added 3 own fixes on the list

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

[Bf-committers] Vertex Buffer Object/Vertex Buffer Array

[Antony Riakiotakis]

It has struck me as odd that we have support for vertex arrays AND vertex
buffer objects wrapped in the same code and we still fall back to immediate
OpenGL mode if VBO option is off.

Vertex Arrays are included in OpenGL 1.1 and blender already requires
OpenGL 1.4 if I remember correctly. They are also faster than immediate
mode. And apart from that, OpenGL 1.1 has been everywhere since
like...forever!

We have to spend so much energy maintaining both front-ends, where
maintaining just one would be much simpler.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Vertex Pinning

[Antony Riakiotakis]

One basic flaw:

hflag is a character so you are causing an overflow with

BM_ELEM_INTERNAL_TAG or it may simply be ignored.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Cycles-Baking - 1st round of code review

[Antony Riakiotakis]

I am not really sure this is important for features in development. At that
point it's usually meaningless to talk about which commit 'broke'
something, because that something does not even exist to be tested upon.
For this to maybe work you have to do things correctly right from the
start. But coders usually try things out and then commit. In practice
development itself is rarely linear. You may 'finish' a certain part of the
code only to find later that it may be broken so you refactor, etc. While
this would be nice to have I don't see how this would work in practice with
unfinished features.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Layers for Images, third phase is completed!!

[Antony Riakiotakis]

Hi Fabio,

Congratulations on this milestone!

It would be great to finally merge this into master!
Can you upload a diff against master on phabricator for code review?
I can help if you need any assistance.
Also we should resolve any conflicts with soc-2013-paint. I am focused on
finalizing the branch these days and it should be up for review in about 2
weeks. Depending on the state of those projects it may be beneficial to
merge one or the other first.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC 2014 Aspirant: Implementation of a Pyramid Primitive in Blender

[Antony Riakiotakis]

Hi,

Sorry for being blunt but such a project would last one week at most for
someone inexperienced. Most experienced devs could add something like that
in a day or two. I don't think we would accept such a proposal.

If you really are serious about taking part in GSOC you should think of
something else or check our ideas page:

http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2014/Ideas

If you really want to stay in this direction, then, for example, creating
the basis of a full parametric modelling system (design, user interface, a
few basic primitives) is an appropriately more challenging and interesting
project (just to give you a rough idea of the scale of the project you
should aim for).
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers