Re: [Bf-committers] Help on linking added lib on XCode
Just to document the solution that Brecht helped me with: Error 1: Cannot use typeid with -fno-rtti It was just a matter of editing the corresponding CMakeLists.txt to remove the flags -fno-rtti, since OpenVDB uses typeid. Errors 2 and on: No member named 'punned_cast' in namespace 'tbb::internal' OpenImageIO has its own version of tbb that gets included. This version of tbb, however, is not complete - probably a subset of what OIIO needs. But since the preprocessor definition symbols are the same, this version got included, and the full tbb dependency I added didn't, hence the missing symbols series of errors. The fix was to change the include order in the corresponding CMakeLists.txt file, causing my tbb dependency to be included first. These changes will be committed later today. Thanks, Rafael. On Sat, Jul 20, 2013 at 9:45 AM, Rafael Campos wrote: > > Hi all, > > As part of SoC, I had to add the intel tbb library to Blender (tbb files > not committed), and it compiled and ran fine on Windows. Now, I'm trying to > setup the same project on Mac, and I keep getting these linker errors. > Trunk builds ok. > > I've added a tbb folder, with include and lib dirs, to cmake's LIBDIR, > which is lib/darwin-9.x.universal/ here. > > On XCode, in Library Search Paths, I currently have > > /Users/rafael/Projects/blender/blenderSVN/blender/../lib/darwin-9.x.universal/tbb/lib > > /Users/rafael/Projects/blender/blenderSVN/blender/../lib/darwin-9.x.universal/tbb/lib/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME) > > and in Other Linker Flags, among many listed, I have > -ltbb > -ltbb_debug > > On Windows, the libraries were tbb.dll and tbb_debug.dll, so I kept these > names on CmakeLists.txt, but the actual files now are libtbb.dylib and > libtbb_debug.dylib - not sure if the preceding lib makes a difference here. > In all cases, not statically linked, but it did work on Windows. :( > > The errors I'm getting are below - there are 20, but same error messages. > cycles_kernel_osl Group > Semantic Issue Group > /Users/rafael/Projects/blender/blenderSVN/blender/extern/openvdb/internal/openvdb/Types.h:166:72: > Cannot use typeid with -fno-rtti > > /Users/rafael/Projects/blender/blenderSVN/lib/darwin-9.x.universal/tbb/include/tbb/aligned_space.h:47:34: > No member named 'punned_cast' in namespace 'tbb::internal' > > /Users/rafael/Projects/blender/blenderSVN/lib/darwin-9.x.universal/tbb/include/tbb/internal/_concurrent_unordered_impl.h:820:37: > Use of undeclared identifier '__TBB_ReverseBits' > > And I suspect I might be missing something obvious. Any ideas? > > Thanks a lot, > Rafael. > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] sculpt mode wireframe display issue and question
@Sergey - Another way to consider the question is -- does anyone thinks it's worth the effort to properly fix hiding-of-coplanar edges in non-dynamic sculpt mode? or is the simpler solution, forcing all edges to display like dyntopo, sufficient? It sounds like you think forcing all edges to display is the right choice. It would be great if you could ask other artists if they agree. @Ronan - I see. Did explicit wire-control work much better than the current "optimal display"? (which as far as I can tell means "draw only base-mesh edges") I'll take a peek and see where that feature went. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Patch [#36296] object->display-properties subpanel layout cleanup
https://projects.blender.org/tracker/index.php?func=detail&aid=36296&group_id=9&atid=127 This patch is a small cleanup to the layout of the object->display-properties subpanel. The main result is visible in this comparison display.. though note that the wording "Maximum draw type:" was used instead of "Limit draw to:" in order to match the name of that menu-widget and the tooltip. http://www.pasteall.org/pic/show.php?id=56188 See path for more details. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] sculpt mode wireframe display issue and question
... another small related question. Is it desirable that sculpt mode uses full selection color wireframes, rather than using something more subtle like the weight paint wireframes? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] cuda 32bit kernels
> I don't see OSL libraries for this platform in svn, so I guess it's > not supported. I'm not sure what the status is here exactly. any idea when it will be implemented here? i think Antony is mingw maintainer. Regards Yousef Harfoush ba...@msn.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] sculpt mode wireframe display issue and question
Explicit wire-control adapts itself to information you want to display. Wire helps to evaluate possibilities for future strokes when using specific brushes (grab/crease/pinch/smooth...). But it does not necessary require to display highest level to be useful. It can help to take decision to switch to a lower level to sculpt. Base-mesh reminds UV seams, UV Islands, vertex color, weight groups, vertices influenced by shapekeys. It explicits borders or areas that you may want to avoïd while sculpting because it correponds to a node material transition. So, it is less useful. Now, that we have hiding and masking. In 2.49, multiresolution was not a modifier. The feature was lost while 2.5 interface changes when multi-resolution became a modifier. On 27/07/2013 00:25, David Jeske wrote: > @Sergey - Another way to consider the question is -- does anyone thinks > it's worth the effort to properly fix hiding-of-coplanar edges in > non-dynamic sculpt mode? or is the simpler solution, forcing all edges to > display like dyntopo, sufficient? It sounds like you think forcing all > edges to display is the right choice. It would be great if you could ask > other artists if they agree. > > @Ronan - I see. Did explicit wire-control work much better than the current > "optimal display"? (which as far as I can tell means "draw only base-mesh > edges") I'll take a peek and see where that feature went. > ___ > 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] sculpt mode wireframe display issue and question
Yes , it is desirable to have it little more subtile but not too much. It should still show wireframe more obvious than just a flat shading. On 27/07/2013 00:44, David Jeske wrote: > ... another small related question. > > Is it desirable that sculpt mode uses full selection color wireframes, > rather than using something more subtle like the weight paint wireframes? > ___ > 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] sculpt mode wireframe display issue and question
> > In 2.49, multiresolution was not a modifier. The feature was lost while > 2.5 interface changes when multi-resolution became a modifier. I see. Just glancing at it, it looks like "optimal display" marks edges for display which correspond to level-0 edges. I don't see why the same technique couldn't work to revive the "edges:#" feature from 2.49, but I'll have to dig a little deeper to see if I'm understanding this correctly. > Yes , it is desirable to have it little more subtile but not too much. > It should still show wireframe more obvious than just a flat shading. > My proposal is to use the same alpha-white lines as weight paint mode You can see the difference here.. http://www.pasteall.org/pic/show.php?id=56387 I think it's more subtle, and shows up clearly in more situations. It becomes invisible with a pure-white object, just as the current orange selection color becomes invisible with a selection-color object. If this is preferred, I think the right thing to do is make this an additional theme-color (sculpt-mode-wireframe). Weight paint doesn't theme this white-alpha color, but it knows what color the weight paint surfaces will be underneath. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
