Re: [Bf-committers] Library update needed: OpenImageIO version 1.7.13

Mac libs on https://developer.blender.org/diffusion/BL/browse/trunk/lib/darwin-9.x.universal/ are still on 1.6.10 since that repo missed a libs updated from early December last year. This one: https://lists.blender.org/pipermail/bf-committers/2016-December/047889.html > On 03 Apr 2017, at

Re: [Bf-committers] Blender developers meeting notes - 2017-02-19

Hi, Any news on OSX 10.6 libraries? As far as I can see they have not been updated to match windows and macos 10.9 https://lists.blender.org/pipermail/bf-committers/2016-December/047904.html Thanks, Francesc > On 19 Feb 2017, at 17:18, Ton Roosendaal wrote: > > Hi all, >

Re: [Bf-committers] Blender 2.78b RELEASE AHOY!

Hi, Just noticed the 2.78b is listed on front page, link to linux version is broken, points to glibc211 but only glibc219 exist on the download folder. Also, what library version has been used for OSX? The ones available on SVN that are not in updated to match the windows libs? Thanks,

Re: [Bf-committers] OpenSubdiv update required

t; > Le 31/01/2017 à 16:51, Francesc Juhe a écrit : >> Hi, >> >> What’s the status of old mac os (darwin 9.x) libs? Are they going to be >> replaced by the new darwin libs for official builds? >> They haven’t been updated in a while and are missing the last bat

Re: [Bf-committers] OpenSubdiv update required

Hi, What’s the status of old mac os (darwin 9.x) libs? Are they going to be replaced by the new darwin libs for official builds? They haven’t been updated in a while and are missing the last batch of updated libs from early December. Thanks, Francesc > On 24 Jan 2017, at 11:52, Sergey

Re: [Bf-committers] BMesh split face edge net

Yes, haven’t found issues caused by it directly, just seemed weird to pass the other list to code below. Found it while looking into another issue I was having were faces 464 and 465 of Suzanne were not cut when intersected with a cube. Steps to reproduce: Default scene. Add suzanne. Add

[Bf-committers] BMesh split face edge net

Hi, I have been going through BMesh boolean code the last days and I found this: https://developer.blender.org/diffusion/B/browse/master/source/blender/bmesh/intern/bmesh_polygon_edgenet.c;fd4caafc53a1c2558f1a27eeaecffb130a146ff4$164 /* attempt one boundary and one wire, or 2 boundary */ if

Re: [Bf-committers] Retiring Linux GLibc 2.11 builder

l Blender binaries? > > > On Sun, Oct 2, 2016 at 4:38 PM, Francesc Juhe <fju...@gmail.com> wrote: > >> It’s not really inconsistent, it’s just having those 'bleeding edge' libs >> on top of RHEL 6.7 and derivatives as a base, which is old. >> If vfxplatform was b

Re: [Bf-committers] Retiring Linux GLibc 2.11 builder

It’s not really inconsistent, it’s just having those 'bleeding edge' libs on top of RHEL 6.7 and derivatives as a base, which is old. If vfxplatform was based on latest RHEL, the requirements would be glibc 2.17 but even that would be below 2.19 On 02 Oct 2016, at 16:23, Bastien Montagne

Re: [Bf-committers] Buildbot cuda-hack

try_compile > CMake trickery? > > On Sun, Aug 28, 2016 at 8:37 PM, Francesc Juhe <fju...@gmail.com> wrote: > >> I run a few tests regarding clang and omp after installing OSX 10.11 and >> Xcode 7.3.1. >> >> It seems that clang-omp-3.5 from libs can’t comp

Re: [Bf-committers] Buildbot cuda-hack

You would definitely loose openmp capability unless you compile and use > a vanilla clang 3.7 which supports it. > > > Jens > > > Am 26.08.2016 um 18:11 schrieb Francesc Juhe: >> Hi, >> >> Some time ago noticed this commit >> https://developer.blend

Re: [Bf-committers] Buildbot cuda-hack

ely loose openmp capability unless you compile and use > a vanilla clang 3.7 which supports it. > > > Jens > > > Am 26.08.2016 um 18:11 schrieb Francesc Juhe: >> Hi, >> >> Some time ago noticed this commit >> https://developer.blender.org/rB3a24e

[Bf-committers] Buildbot cuda-hack

Hi, Some time ago noticed this commit https://developer.blender.org/rB3a24e6320f31a790ea9d3c912a35db2186140b71 changing the nvcc compiler on builbot but I did not give it much though as I was having no issues compiling with cuda 7.5 and clang 3.5 from libs folder on OSX 10.9. But now with

Re: [Bf-committers] Build Errors on Windows with MSVC2013

Mac OS X also fails to build, see buildbot logs: https://builder.blender.org/one_line_per_build Reverting 4adffde fixes the issue. On 18 May 2016, at 07:24, Joshua Leung wrote: > Hi, > > It looks like one of the recent code cleanups in the CMake files may have > broken

[Bf-committers] Blender 2.77 release

Hi, While preparing my custom blender builds I noticed some oddities in official Blender 2.77 release builds. - Windows version is using a version of OpenColorIO and SDL2 libraries different from the one on public lib repo. - Mac version has addons_contrib included. - Mac version also has

Re: [Bf-committers] Cmake OS X Broken?

Hi, Not directly related to the issue but current mac buildbot seems to be missing blenderplayer binary inside app, libiomp5.dylib and info.plist when compared to RC2. Cheers, Francesc On 10 Mar 2016, at 08:16, Campbell Barton wrote: > Committed change to CMake

[Bf-committers] Compilation failure scons win64

Hi, I tried to compile a recent master build with scons on windows and it failed on file: source/gameengine/Rasterizer/RAS_ICanvas.cpp Solved by adding BF_PTHREADS_INC to: source/gameengine/Rasterizer/SConscript if env['OURPLATFORM'] in ('win32-vc', 'win32-mingw', 'linuxcross', 'win64-vc',

Re: [Bf-committers] macrovellum's fluid designer for linux

Hi, I can confirm it is doable if they examine the scripts prepare_release_env.sh and install_deps.sh. Instead of running them right away they can just try to run them step by step manually. Right now, prepare_release_env.sh fails for missing files it needs from debian repos which are no

[Bf-committers] Incorrect drawing of DIRECTION property sphere

Hello, I found a minor issue on the drawing function for DIRECTION properties that is fixed with this one line patch. diff --git a/source/blender/editors/interface/interface_draw.c b/source/blender/editors/interface/interface_draw.c index 84767ea..8ae8466 100644 ---

Re: [Bf-committers] Link custom node trees to datablocks.

, at 16:19, Alexander Romanov <a.roma...@blend4web.com> wrote: > > > On 22.10.2015 13:39, Francesc Juhe wrote: >> On 22 Oct 2015, at 10:58, Alexander Romanov <a.roma...@blend4web.com> wrote: >> >>>>>> As for issue, (1) Generalized nodetree edi

Re: [Bf-committers] Link custom node trees to datablocks.

On 21 Oct 2015, at 16:32, Alexander Romanov wrote: > There is a problem of backward compatibility. You need to think > carefully and not to break existing Addons if you want to remove custom > trees from bpy.data.node_groups. In any case, it will be a low-level >

Re: [Bf-committers] Link custom node trees to datablocks.

ubtype='SCENE') # to store a scene >> bpy.props.IDProperty(subtype='NODE_TREE', type=NodeTreeType) # to store >> a node tree >> >> Would a property like this make sense? >> >> Thanks, >> ~ Isaac >> >> On Tue, Oct 20, 2015 at 1:58 PM,

Re: [Bf-committers] Link custom node trees to datablocks.

Hello, As the main developer behind the Mitsuba exporter I like your proposal. It would greatly improve the current workflow. But I would also like to make another proposal. - Add to Blender a bpy.props.NodeTree(type=NodeTreeType) that can be attached to ID. This way there is no need to fill

Re: [Bf-committers] Why SpaceNodeEditor is a bpy_struct? Was: Why is SceneRenderLayer a bpy_struct?

properties to a space it's more important to understand why exactly you need them and see maybe it's something what is actually belong to python nodes instead. On Sat, Aug 22, 2015 at 9:19 AM, Francesc Juhe fju...@gmail.com wrote: I don’t understand it completely because of my lack of knowledge

Re: [Bf-committers] Why SpaceNodeEditor is a bpy_struct? Was: Why is SceneRenderLayer a bpy_struct?

is actually belong to python nodes instead. On Sat, Aug 22, 2015 at 9:19 AM, Francesc Juhe fju...@gmail.com wrote: I don’t understand it completely because of my lack of knowledge about all possible internal consequences. Do all custom properties have undo? In the case of SpaceNodeEditor

Re: [Bf-committers] Why SpaceNodeEditor is a bpy_struct? Was: Why is SceneRenderLayer a bpy_struct?

and undo pushes wouldn't happen for this properties, making use of them rather unreliable. On Fri, Aug 21, 2015 at 9:33 PM, Francesc Juhe fju...@gmail.com wrote: Hi, Reading this I remembered I wanted to create my own shader types for a custom NodeTree and found that shader type is a property

Re: [Bf-committers] Why SpaceNodeEditor is a bpy_struct? Was: Why is SceneRenderLayer a bpy_struct?

editor needs to know where to get node tree from, but this issue already exists and needs to be addressed in one way or another. On Sat, Aug 22, 2015 at 12:09 PM, Francesc Juhe fju...@gmail.com wrote: Hi again, Sorry to be annoying but I have been thinking on another approach that does

Re: [Bf-committers] Why SpaceNodeEditor is a bpy_struct? Was: Why is SceneRenderLayer a bpy_struct?

Hi, Reading this I remembered I wanted to create my own shader types for a custom NodeTree and found that shader type is a property of SpaceNodeEditor which is also a bpy_struct. Can I propose that Space or SpaceNodeEditor are considered for a promotion to ID from bpy_struct so they can be

[Bf-committers] Fix T45317: Cycles material preview unnecessarily re-rendering

Hello, The fix https://developer.blender.org/rBb0df19667fa30ad80631da86198710981ca03824 seems to break node material preview updates on external renderer like LuxRender or Mitsuba. Any suggestion on how to trigger a preview update when working with custom nodes? Thanks, Francesc

Re: [Bf-committers] Fix T45317: Cycles material preview unnecessarily re-rendering

there? On Wed, Jul 22, 2015 at 4:14 PM, Francesc Juhe fju...@gmail.com wrote: Hi, Thanks! I tested it and it seems to trigger a refresh even if the custom node is totally unrelated to any material and also it only triggers for custom properties and custom sockets. If the Custom node has a standard

Re: [Bf-committers] Fix T45317: Cycles material preview unnecessarily re-rendering

our side. Do have a patch for this [1] but before going ahead want to have feedback from our python/rna department. [1] http://www.pasteall.org/59763/diff On Wed, Jul 22, 2015 at 2:40 PM, Francesc Juhe fju...@gmail.com wrote: Hello, The fix https://developer.blender.org

Re: [Bf-committers] Build problem with OpenShadingLanguage

Hi, I had the same error. Changing the line 1377 cmake_d=$cmake_d -D -DLLVM_ENABLE_TERMINFO=OFF” to: cmake_d=$cmake_d -D LLVM_ENABLE_TERMINFO=OFF On llvm compile function and then run the script with —force-llvm to recompile it again without terminfo fixed the issue for me and osl