[Bf-committers] Version number of buildbot builds
Hi devs, Our git master is already in 2.72 release cycle, so I think the buildbot builds should be distributed as 2.72-alpha. Why do we still use a version number of the previous release cycle (2.71)? Thanks! -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] BLENDER_VERSION_CHAR
If we consider the tag and git master as two different projects, we should've bumped BLENDER_VERSION to 271 or made another macro like BLENDER_RELEASECYCLE_VERSION=271 to indicate the git master actually became 2.71-alpha when starting the new release cycle. Currently, there is no infallible way to obtain a version number of current release cycle. IRIE Shinsuke 2014/06/05, Sergey Sharybin wrote: They are specified properly in an appropriate branch/tag. If we do 'a' release it totally happens in the tag now and we only backport there crucial fixes. It's arguable, but don't really think doing 'a' release in a tag would make master branch having 'a' character as well. It's just two different projects. Master is more like a RR. On Thu, Jun 5, 2014 at 4:27 AM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: Because we started 2.71 release cycles in master when we've released 2.70a. That's curious. The 2.71 release cycle has already started when v2.70-rc tag was created: https://developer.blender.org/rBe097c987a8a55f2eb09c19ceac923e7c32e19d89 As far as I remember, BLENDER_VERSION and BLENDER_VERSION_CHAR have been used for indicating latest release version. When 2.68a was released, the version char was indeed bumped to a, and changed again to for 2.69 release: https://developer.blender.org/rBd9b0f660c9e49b13abc212270c0e8a366a2a096f https://developer.blender.org/rBdfe16105041292a1fc7ee29d825c25135a4f6a3c We have another macro BLENDER_VERSION_CYCLE to indicate the release cycle. What's the issue anyway? If BLENDER_VERSION or BLENDER_VERSION_CHAR is not update properly, I have to specify package version of my own deb packages manually... IRIE Shinsuke 2014/06/05, Sergey Sharybin wrote: Because we started 2.71 release cycles in master when we've released 2.70a. What's the issue anyway? On Wed, Jun 4, 2014 at 10:49 PM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: Why was the version char changed only in the tag? I think the same change should have happened in git master as well. IRIE Shinsuke 2014/06/05, Sergey Sharybin wrote: Not sure why cambo showed that commit as an example. Actual change happened when we've been doing 2.70a release. The char was changed in the tag, see f93bc7693a530632455d3ec7acc4bce54a1f85bc. On Wed, Jun 4, 2014 at 10:04 PM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: rBdfe161050412 was a version bump for 2.69 release. BLENDER_VERSION was indeed changed from 268 to 269 in this commit. BLENDER_VERSION_CHAR should've been changed when 2.70a was released but it remains blank since 2.69 release. IRIE Shinsuke 2014/06/05, Campbell Barton wrote: Its still in use, it was changed after 2.70a https://developer.blender.org/rBdfe16105041292a1fc7ee29d825c25135a4f6a3c On Thu, Jun 5, 2014 at 12:57 AM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: Hi devs, Recently I noticed BLENDER_VERSION_CHAR in BKE_blender.h has not been changed since Oct. 8 2013 though 2.69, 2.70, and 2.70a were released after that. Is this macro obsoleted? If so, I have to stop using it to build own .deb packages. If not, please don't forget to update it... Thanks, -- IRIE Shinsuke ___ 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] BLENDER_VERSION_CHAR
Hi devs, Recently I noticed BLENDER_VERSION_CHAR in BKE_blender.h has not been changed since Oct. 8 2013 though 2.69, 2.70, and 2.70a were released after that. Is this macro obsoleted? If so, I have to stop using it to build own .deb packages. If not, please don't forget to update it... Thanks, -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] BLENDER_VERSION_CHAR
rBdfe161050412 was a version bump for 2.69 release. BLENDER_VERSION was indeed changed from 268 to 269 in this commit. BLENDER_VERSION_CHAR should've been changed when 2.70a was released but it remains blank since 2.69 release. IRIE Shinsuke 2014/06/05, Campbell Barton wrote: Its still in use, it was changed after 2.70a https://developer.blender.org/rBdfe16105041292a1fc7ee29d825c25135a4f6a3c On Thu, Jun 5, 2014 at 12:57 AM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: Hi devs, Recently I noticed BLENDER_VERSION_CHAR in BKE_blender.h has not been changed since Oct. 8 2013 though 2.69, 2.70, and 2.70a were released after that. Is this macro obsoleted? If so, I have to stop using it to build own .deb packages. If not, please don't forget to update it... Thanks, -- IRIE Shinsuke ___ 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_VERSION_CHAR
Why was the version char changed only in the tag? I think the same change should have happened in git master as well. IRIE Shinsuke 2014/06/05, Sergey Sharybin wrote: Not sure why cambo showed that commit as an example. Actual change happened when we've been doing 2.70a release. The char was changed in the tag, see f93bc7693a530632455d3ec7acc4bce54a1f85bc. On Wed, Jun 4, 2014 at 10:04 PM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: rBdfe161050412 was a version bump for 2.69 release. BLENDER_VERSION was indeed changed from 268 to 269 in this commit. BLENDER_VERSION_CHAR should've been changed when 2.70a was released but it remains blank since 2.69 release. IRIE Shinsuke 2014/06/05, Campbell Barton wrote: Its still in use, it was changed after 2.70a https://developer.blender.org/rBdfe16105041292a1fc7ee29d825c25135a4f6a3c On Thu, Jun 5, 2014 at 12:57 AM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: Hi devs, Recently I noticed BLENDER_VERSION_CHAR in BKE_blender.h has not been changed since Oct. 8 2013 though 2.69, 2.70, and 2.70a were released after that. Is this macro obsoleted? If so, I have to stop using it to build own .deb packages. If not, please don't forget to update it... Thanks, -- IRIE Shinsuke ___ 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_VERSION_CHAR
Because we started 2.71 release cycles in master when we've released 2.70a. That's curious. The 2.71 release cycle has already started when v2.70-rc tag was created: https://developer.blender.org/rBe097c987a8a55f2eb09c19ceac923e7c32e19d89 As far as I remember, BLENDER_VERSION and BLENDER_VERSION_CHAR have been used for indicating latest release version. When 2.68a was released, the version char was indeed bumped to a, and changed again to for 2.69 release: https://developer.blender.org/rBd9b0f660c9e49b13abc212270c0e8a366a2a096f https://developer.blender.org/rBdfe16105041292a1fc7ee29d825c25135a4f6a3c We have another macro BLENDER_VERSION_CYCLE to indicate the release cycle. What's the issue anyway? If BLENDER_VERSION or BLENDER_VERSION_CHAR is not update properly, I have to specify package version of my own deb packages manually... IRIE Shinsuke 2014/06/05, Sergey Sharybin wrote: Because we started 2.71 release cycles in master when we've released 2.70a. What's the issue anyway? On Wed, Jun 4, 2014 at 10:49 PM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: Why was the version char changed only in the tag? I think the same change should have happened in git master as well. IRIE Shinsuke 2014/06/05, Sergey Sharybin wrote: Not sure why cambo showed that commit as an example. Actual change happened when we've been doing 2.70a release. The char was changed in the tag, see f93bc7693a530632455d3ec7acc4bce54a1f85bc. On Wed, Jun 4, 2014 at 10:04 PM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: rBdfe161050412 was a version bump for 2.69 release. BLENDER_VERSION was indeed changed from 268 to 269 in this commit. BLENDER_VERSION_CHAR should've been changed when 2.70a was released but it remains blank since 2.69 release. IRIE Shinsuke 2014/06/05, Campbell Barton wrote: Its still in use, it was changed after 2.70a https://developer.blender.org/rBdfe16105041292a1fc7ee29d825c25135a4f6a3c On Thu, Jun 5, 2014 at 12:57 AM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: Hi devs, Recently I noticed BLENDER_VERSION_CHAR in BKE_blender.h has not been changed since Oct. 8 2013 though 2.69, 2.70, and 2.70a were released after that. Is this macro obsoleted? If so, I have to stop using it to build own .deb packages. If not, please don't forget to update it... Thanks, -- IRIE Shinsuke ___ 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] [Bf-blender-cvs] [c9209de] master: vertex weights: add weight quantize tool.
In the wiki, how do we make a link to the git commit log? IRIE Shinsuke 13/11/17, Brecht Van Lommel wrote: Hi, Just a friendly reminder to add new features to release notes immediately: http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.70 I'm replying to this particular commit, but I noticed a bunch of recent changes by various developers and no updates in the wiki, so it seems we needed another reminder. (And could you write commit logs with capitalization? Makes it more consistent and easier to generate bug fixes list later.) Thanks, Brecht. On Sun, Nov 17, 2013 at 8:57 AM, Campbell Barton nore...@git.blender.org wrote: Commit: c9209de573ad680dbad6b560c05a90b02b780267 Author: Campbell Barton Date: Sun Nov 17 14:54:42 2013 +1100 http://developer.blender.org/rBc9209de573ad680dbad6b560c05a90b02b780267 vertex weights: add weight quantize tool. === M release/scripts/startup/bl_ui/space_view3d.py M release/scripts/startup/bl_ui/space_view3d_toolbar.py M source/blender/editors/object/object_intern.h M source/blender/editors/object/object_ops.c M source/blender/editors/object/object_vgroup.c === diff --git a/release/scripts/startup/bl_ui/space_view3d.py b/release/scripts/startup/bl_ui/space_view3d.py index ea2826f..16cef7c 100644 --- a/release/scripts/startup/bl_ui/space_view3d.py +++ b/release/scripts/startup/bl_ui/space_view3d.py @@ -1502,6 +1502,7 @@ class VIEW3D_MT_paint_weight(Menu): layout.operator(object.vertex_group_mirror, text=Mirror) layout.operator(object.vertex_group_invert, text=Invert) layout.operator(object.vertex_group_clean, text=Clean) +layout.operator(object.vertex_group_quantize, text=Quantize) layout.operator(object.vertex_group_levels, text=Levels) layout.operator(object.vertex_group_blend, text=Blend) layout.operator(object.vertex_group_transfer_weight, text=Transfer Weights) diff --git a/release/scripts/startup/bl_ui/space_view3d_toolbar.py b/release/scripts/startup/bl_ui/space_view3d_toolbar.py index 088dfc3..8c86cc6 100644 --- a/release/scripts/startup/bl_ui/space_view3d_toolbar.py +++ b/release/scripts/startup/bl_ui/space_view3d_toolbar.py @@ -1115,6 +1115,7 @@ class VIEW3D_PT_tools_weightpaint(View3DPanel, Panel): col.operator(object.vertex_group_mirror, text=Mirror) col.operator(object.vertex_group_invert, text=Invert) col.operator(object.vertex_group_clean, text=Clean) +col.operator(object.vertex_group_quantize, text=Quantize) col.operator(object.vertex_group_levels, text=Levels) col.operator(object.vertex_group_blend, text=Blend) col.operator(object.vertex_group_transfer_weight, text=Transfer Weights) diff --git a/source/blender/editors/object/object_intern.h b/source/blender/editors/object/object_intern.h index 4ff3bc9..313ac1d 100644 --- a/source/blender/editors/object/object_intern.h +++ b/source/blender/editors/object/object_intern.h @@ -222,6 +222,7 @@ void OBJECT_OT_vertex_group_fix(struct wmOperatorType *ot); void OBJECT_OT_vertex_group_invert(struct wmOperatorType *ot); void OBJECT_OT_vertex_group_blend(struct wmOperatorType *ot); void OBJECT_OT_vertex_group_clean(struct wmOperatorType *ot); +void OBJECT_OT_vertex_group_quantize(struct wmOperatorType *ot); void OBJECT_OT_vertex_group_limit_total(struct wmOperatorType *ot); void OBJECT_OT_vertex_group_mirror(struct wmOperatorType *ot); void OBJECT_OT_vertex_group_set_active(struct wmOperatorType *ot); diff --git a/source/blender/editors/object/object_ops.c b/source/blender/editors/object/object_ops.c index 333e5ff..f5c2bcb 100644 --- a/source/blender/editors/object/object_ops.c +++ b/source/blender/editors/object/object_ops.c @@ -191,6 +191,7 @@ void ED_operatortypes_object(void) WM_operatortype_append(OBJECT_OT_vertex_group_levels); WM_operatortype_append(OBJECT_OT_vertex_group_blend); WM_operatortype_append(OBJECT_OT_vertex_group_clean); + WM_operatortype_append(OBJECT_OT_vertex_group_quantize); WM_operatortype_append(OBJECT_OT_vertex_group_limit_total); WM_operatortype_append(OBJECT_OT_vertex_group_mirror); WM_operatortype_append(OBJECT_OT_vertex_group_set_active); diff --git a/source/blender/editors/object/object_vgroup.c b/source/blender/editors/object/object_vgroup.c index a6f7c4d..16ee400 100644 --- a/source/blender/editors/object/object_vgroup.c +++ b/source/blender/editors/object/object_vgroup.c @@ -2398,6 +2398,44 @@ static void vgroup_clean_subset(Object *ob, const bool *vgroup_validmap, const i } } +static void vgroup_quantize_subset(Object *ob, const bool *vgroup_validmap, const int vgroup_tot, const int UNUSED
Re: [Bf-committers] [Bf-blender-cvs] [c9209de] master: vertex weights: add weight quantize tool.
Thanks, I couldn't find that page. IRIE Shinsuke 13/11/17, Brecht Van Lommel wrote: See this page: http://wiki.blender.org/index.php/Template:GitCommit On Sun, Nov 17, 2013 at 10:25 AM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: In the wiki, how do we make a link to the git commit log? IRIE Shinsuke 13/11/17, Brecht Van Lommel wrote: Hi, Just a friendly reminder to add new features to release notes immediately: http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.70 I'm replying to this particular commit, but I noticed a bunch of recent changes by various developers and no updates in the wiki, so it seems we needed another reminder. (And could you write commit logs with capitalization? Makes it more consistent and easier to generate bug fixes list later.) Thanks, Brecht. On Sun, Nov 17, 2013 at 8:57 AM, Campbell Barton nore...@git.blender.org wrote: Commit: c9209de573ad680dbad6b560c05a90b02b780267 Author: Campbell Barton Date: Sun Nov 17 14:54:42 2013 +1100 http://developer.blender.org/rBc9209de573ad680dbad6b560c05a90b02b780267 vertex weights: add weight quantize tool. === M release/scripts/startup/bl_ui/space_view3d.py M release/scripts/startup/bl_ui/space_view3d_toolbar.py M source/blender/editors/object/object_intern.h M source/blender/editors/object/object_ops.c M source/blender/editors/object/object_vgroup.c === diff --git a/release/scripts/startup/bl_ui/space_view3d.py b/release/scripts/startup/bl_ui/space_view3d.py index ea2826f..16cef7c 100644 --- a/release/scripts/startup/bl_ui/space_view3d.py +++ b/release/scripts/startup/bl_ui/space_view3d.py @@ -1502,6 +1502,7 @@ class VIEW3D_MT_paint_weight(Menu): layout.operator(object.vertex_group_mirror, text=Mirror) layout.operator(object.vertex_group_invert, text=Invert) layout.operator(object.vertex_group_clean, text=Clean) +layout.operator(object.vertex_group_quantize, text=Quantize) layout.operator(object.vertex_group_levels, text=Levels) layout.operator(object.vertex_group_blend, text=Blend) layout.operator(object.vertex_group_transfer_weight, text=Transfer Weights) diff --git a/release/scripts/startup/bl_ui/space_view3d_toolbar.py b/release/scripts/startup/bl_ui/space_view3d_toolbar.py index 088dfc3..8c86cc6 100644 --- a/release/scripts/startup/bl_ui/space_view3d_toolbar.py +++ b/release/scripts/startup/bl_ui/space_view3d_toolbar.py @@ -1115,6 +1115,7 @@ class VIEW3D_PT_tools_weightpaint(View3DPanel, Panel): col.operator(object.vertex_group_mirror, text=Mirror) col.operator(object.vertex_group_invert, text=Invert) col.operator(object.vertex_group_clean, text=Clean) +col.operator(object.vertex_group_quantize, text=Quantize) col.operator(object.vertex_group_levels, text=Levels) col.operator(object.vertex_group_blend, text=Blend) col.operator(object.vertex_group_transfer_weight, text=Transfer Weights) diff --git a/source/blender/editors/object/object_intern.h b/source/blender/editors/object/object_intern.h index 4ff3bc9..313ac1d 100644 --- a/source/blender/editors/object/object_intern.h +++ b/source/blender/editors/object/object_intern.h @@ -222,6 +222,7 @@ void OBJECT_OT_vertex_group_fix(struct wmOperatorType *ot); void OBJECT_OT_vertex_group_invert(struct wmOperatorType *ot); void OBJECT_OT_vertex_group_blend(struct wmOperatorType *ot); void OBJECT_OT_vertex_group_clean(struct wmOperatorType *ot); +void OBJECT_OT_vertex_group_quantize(struct wmOperatorType *ot); void OBJECT_OT_vertex_group_limit_total(struct wmOperatorType *ot); void OBJECT_OT_vertex_group_mirror(struct wmOperatorType *ot); void OBJECT_OT_vertex_group_set_active(struct wmOperatorType *ot); diff --git a/source/blender/editors/object/object_ops.c b/source/blender/editors/object/object_ops.c index 333e5ff..f5c2bcb 100644 --- a/source/blender/editors/object/object_ops.c +++ b/source/blender/editors/object/object_ops.c @@ -191,6 +191,7 @@ void ED_operatortypes_object(void) WM_operatortype_append(OBJECT_OT_vertex_group_levels); WM_operatortype_append(OBJECT_OT_vertex_group_blend); WM_operatortype_append(OBJECT_OT_vertex_group_clean); + WM_operatortype_append(OBJECT_OT_vertex_group_quantize); WM_operatortype_append(OBJECT_OT_vertex_group_limit_total); WM_operatortype_append(OBJECT_OT_vertex_group_mirror); WM_operatortype_append(OBJECT_OT_vertex_group_set_active); diff --git a/source/blender/editors/object/object_vgroup.c b/source/blender/editors/object/object_vgroup.c index a6f7c4d..16ee400 100644 --- a/source/blender/editors/object/object_vgroup.c +++ b/source/blender/editors/object
[Bf-committers] SCons build in exported source tree fails
Hi, I tried SCons build in an exported source tree that have no .git/ directory but it failed as follows: UnboundLocalError: local variable 'build_commit_timestamp' referenced before assignment: File /home/irie/build/blender2.6/scons/SConstruct, line 757: dobj = B.buildinfo(env, dynamic) + B.resources File ./build_files/scons/tools/Blender.py, line 439: 'BUILD_COMMIT_TIMESTAMP=%s'%(build_commit_timestamp), commit 58afbb2ee8f9a0e08365db5e840bbb8d9f39c3ab CommitDate: Sat Nov 16 03:26:04 2013 +0100 Thanks, -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [61082] trunk/blender: Made buildinfo aware of builds from GIT
Why is the same if(EXISTS ${SOURCE_DIR}/.git/) ... endif() nested
in buildinfo.cmake?
IRIE Shinsuke
13/11/04, Sergey Sharybin wrote:
Revision: 61082
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=61082
Author: nazgul
Date: 2013-11-04 13:21:39 + (Mon, 04 Nov 2013)
Log Message:
---
Made buildinfo aware of builds from GIT
- Use commit number since last annotated tag as a
revision number replacement. It'll eb followed
by 'M' symbol if there're local modification in
the source tree.
- Commit short SHA1 is included. Helps getting
information about commit used to build blender
with much faster.
- If build is not done from master branch, this also
will be noticed in the splash screen.
This commit also replaces revision stored in the
files with git-specific fields (change and hash).
This is kind of breaks compatibility, meaning
files which were saved before this change wouldn't
display any information about which revision they
were saved with. When we'll finally switch to git,
we'll see proper hash and change number since
previous release in the files, for until then
svn version will be used as a change number and
hash will be empty.
Not a huge deal, since this field was only used
by developers to help torubleshooting things and
isn't needed for blender itself.
Some additional tweaks are probably needed :)
Modified Paths:
--
trunk/blender/build_files/cmake/buildinfo.cmake
trunk/blender/build_files/scons/tools/Blender.py
trunk/blender/release/scripts/modules/sys_info.py
trunk/blender/source/blender/blenkernel/BKE_main.h
trunk/blender/source/blender/blenloader/intern/readfile.c
trunk/blender/source/blender/blenloader/intern/writefile.c
trunk/blender/source/blender/collada/AnimationExporter.h
trunk/blender/source/blender/collada/DocumentExporter.cpp
trunk/blender/source/blender/makesdna/DNA_fileglobal_types.h
trunk/blender/source/blender/python/intern/bpy_app.c
trunk/blender/source/blender/windowmanager/intern/wm_operators.c
trunk/blender/source/blenderplayer/bad_level_call_stubs/CMakeLists.txt
trunk/blender/source/creator/CMakeLists.txt
trunk/blender/source/creator/buildinfo.c
trunk/blender/source/creator/creator.c
Modified: trunk/blender/build_files/cmake/buildinfo.cmake
===
--- trunk/blender/build_files/cmake/buildinfo.cmake 2013-11-04 12:50:33 UTC
(rev 61081)
+++ trunk/blender/build_files/cmake/buildinfo.cmake 2013-11-04 13:21:39 UTC
(rev 61082)
@@ -1,17 +1,83 @@
# This is called by cmake as an extermal process from
# ./source/creator/CMakeLists.txt to write ./source/creator/buildinfo.h
-# The FindSubversion.cmake module is part of the standard distribution
-include(FindSubversion)
-
# Extract working copy information for SOURCE_DIR into MY_XXX variables
# with a default in case anything fails, for examble when using git-svn
-set(MY_WC_REVISION unknown)
+set(MY_WC_HASH )
+set(MY_WC_BRANCH )
+set(MY_WC_CHANGE unknown)
+
# Guess if this is a SVN working copy and then look up the revision
-if(EXISTS ${SOURCE_DIR}/.svn/)
- if(Subversion_FOUND)
- Subversion_WC_INFO(${SOURCE_DIR} MY)
+if(EXISTS ${SOURCE_DIR}/.git/)
+ if(EXISTS ${SOURCE_DIR}/.git/)
+ # The FindSubversion.cmake module is part of the standard
distribution
+ include(FindGit)
+ if(GIT_FOUND)
+ execute_process(COMMAND git rev-parse --short HEAD
+ WORKING_DIRECTORY ${SOURCE_DIR}
+ OUTPUT_VARIABLE MY_WC_HASH
+ OUTPUT_STRIP_TRAILING_WHITESPACE)
+
+ execute_process(COMMAND git rev-parse --abbrev-ref HEAD
+ WORKING_DIRECTORY ${SOURCE_DIR}
+ OUTPUT_VARIABLE MY_WC_BRANCH
+ OUTPUT_STRIP_TRAILING_WHITESPACE)
+
+ # Get latest version tag
+ execute_process(COMMAND git describe --match v[0-9]*
--abbrev=0
+ WORKING_DIRECTORY ${SOURCE_DIR}
+ OUTPUT_VARIABLE _git_latest_version_tag
+ OUTPUT_STRIP_TRAILING_WHITESPACE)
+
+ if(NOT _git_latest_version_tag STREQUAL )
+ execute_process(COMMAND git rev-list HEAD
^${_git_latest_version_tag} --count
+ WORKING_DIRECTORY ${SOURCE_DIR}
+ OUTPUT_VARIABLE MY_WC_CHANGE
+
OUTPUT_STRIP_TRAILING_WHITESPACE)
+ else
[Bf-committers] Revision number in the splash screen
Hi devs, In our wiki, the Migration to Git and Phabricator page says: Which git revision number goes in the splash screen? The SHA hash from git would be the simple solution. If we want incrementing numbers we could do things like count the number of commits since the beginning or since the last release, or include the branch name. No decision here yet. Is there no decision still? I dislike the hash... Thanks -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer meeting minutes - October 20, 2013
Hi, Can one more small fix r60756 + r60763 be merged for the release? Sorry for late proposal. IRIE Shinsuke 13/10/21, Ton Roosendaal wrote: Hi all, Here's a couple of notes from today's meeting in irc.freenode.net #blendercoders 1) Blender 2.69 release candidates - Bug reports keep coming in! All showstoppers were tackled though. - Meeting proposes to call for official 2.69 release build tomorrow. Last fixes from trunk were merged to release branch already. We would like everyone (and Campbell Barton, who's in USA atm) to check if it's OK! 2) projects for 2.70 - No news compared to last week's list of possible projects for 2.70. - Ton Roosendaal mentions he had a meeting with Brecht van Lommel about all UI work the coming period. Brecht agreed on accepting the responsibility to coordinate/lead this, also to look into expanding the UI 'owner' team with more developers and designers. 3) Git and Phabricator migration - We're finally moving to git! Here's the plan: http://wiki.blender.org/index.php/Dev:Ref/Migration_to_Git_Phabricator - There's also work being done to swap the www.blender.org website with the new staging.blender.org one. Even though the latter is not finished, switching it might give a bit more incentives and energy to then do it after all! Thanks, -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer meeting minutes - October 20, 2013
This is actually a regression introduced in r59789, was not in 2.68. IRIE Shinsuke 13/10/21, Sergey Sharybin wrote: Strictly speaking no. It is not a regression and codebase for 2.69 was frozen two weeks ago. On Sun, Oct 20, 2013 at 7:42 PM, IRIE Shinsuke irieshins...@yahoo.co.jpwrote: Hi, Can one more small fix r60756 + r60763 be merged for the release? Sorry for late proposal. IRIE Shinsuke 13/10/21, Ton Roosendaal wrote: Hi all, Here's a couple of notes from today's meeting in irc.freenode.net#blendercoders 1) Blender 2.69 release candidates - Bug reports keep coming in! All showstoppers were tackled though. - Meeting proposes to call for official 2.69 release build tomorrow. Last fixes from trunk were merged to release branch already. We would like everyone (and Campbell Barton, who's in USA atm) to check if it's OK! 2) projects for 2.70 - No news compared to last week's list of possible projects for 2.70. - Ton Roosendaal mentions he had a meeting with Brecht van Lommel about all UI work the coming period. Brecht agreed on accepting the responsibility to coordinate/lead this, also to look into expanding the UI 'owner' team with more developers and designers. 3) Git and Phabricator migration - We're finally moving to git! Here's the plan: http://wiki.blender.org/index.php/Dev:Ref/Migration_to_Git_Phabricator - There's also work being done to swap the www.blender.org website with the new staging.blender.org one. Even though the latter is not finished, switching it might give a bit more incentives and energy to then do it after all! Thanks, -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [60692] trunk/blender/source/blender: Fix build scripts related to PSD support.
In r60726, I corrected a remaining WITH_IMAGE_OPENIMAGEIO. You forgot to modify it. IRIE Shinsuke 13/10/13, Dalai Felinto wrote: I actually think we should have WITH_OPENIMAGEIO instead of WITH_IMAGE_OPENIMAGEIO. It's how it was already in CMakeLists.txt and there is no big compelling argument to change that. I committed the fix in rev.60718 [to get PSD working by default - even if WITH_OPENIMAGEIO is OFF, assuming WITH_CYCLES is ON] Cheers, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2013/10/12 IRIE Shinsuke irieshins...@yahoo.co.jp Got it, but I think the CMake variable WITH_OPENIMAGEIO is not needed. It should be replaced with WITH_IMAGE_OPENIMAGEIO, and Cycles should simply depend on WITH_IMAGE_OPENIMAGEIO like this: # auto enable openimageio for cycles if(WITH_CYCLES) set(WITH_IMAGE_OPENIMAGEIO ON) endif() # auto enable openimageio linking dependencies if(WITH_IMAGE_OPENIMAGEIO) set(WITH_IMAGE_OPENEXR ON) set(WITH_IMAGE_TIFF ON) endif() IRIE Shinsuke 13/10/12, Dalai Felinto wrote: Hi, it causes unwanted behavior that the PSD support is enabled even if WITH_IMAGE_OPENIMAGEIO=OFF and WITH_CYCLES=ON This is actually the wanted behaviour. Bear with me ... If the average user just builds Blender, she gets Cycles, PSD, all the goodies. If the advanced user/developer doesn't want to build Cycles but wants PSD support, she does WITH_CYCLES=OFF and WITH_IMAGE_OPENIMAGEIO=ON If the user doesn't want anything to use OIIO, she simply does WITH_CYCLES=OFF. I believe (may be wrong) that one of main ideas of having those defines in the code is to speed up building (less code to build, less libraries to link to ...). Thus I think we should tie the defines to the library, not the feature. Dalai // mobile ___ 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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [60692] trunk/blender/source/blender: Fix build scripts related to PSD support.
Hi Dalai,
if(WITH_OPENIMAGEIO) in CMakeLists.txt causes unwanted behavior that
the PSD support is enabled even if WITH_IMAGE_OPENIMAGEIO=OFF and
WITH_CYCLES=ON.
IRIE Shinsuke
13/10/12, Dalai Felinto wrote:
Hi,
Thanks for the fix. My Xcode was not cleaning its cache during my tests and
I ended up overseen this PSD.
For CMake I think the actual fix would be only changing
//source/blender/CMakeLists.txt
”
Modified: trunk/blender/source/blender/CMakeLists.txt
===
--- trunk/blender/source/blender/CMakeLists.txt 2013-10-11 22:37:24 UTC
(rev 60691)
+++ trunk/blender/source/blender/CMakeLists.txt 2013-10-11 23:14:01 UTC
(rev 60692)
@@ -117,7 +117,7 @@
add_subdirectory(imbuf/intern/openexr)
endif()
-if(WITH_IMAGE_PSD)
+if(WITH_OPENIMAGEIO)
add_subdirectory(imbuf/intern/oiio)
endif()
”
I won't be in front of a computer before ~18 hours. So if you want to
test/commit the above, it would be much appreciated.
(It require reverting the non scons part of your patch though)
Your patch works and fixed the immediate issue so there is no real rush.
Thanks,
Dalai
On Oct 11, 2013 8:14 PM, Shinsuke Irie irieshins...@yahoo.co.jp wrote:
Revision: 60692
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=60692
Author: irie
Date: 2013-10-11 23:14:01 + (Fri, 11 Oct 2013)
Log Message:
---
Fix build scripts related to PSD support. Both CMake and SCons builds
were broken.
Modified Paths:
--
trunk/blender/source/blender/CMakeLists.txt
trunk/blender/source/blender/blenkernel/SConscript
trunk/blender/source/blender/editors/space_file/CMakeLists.txt
trunk/blender/source/blender/editors/space_image/CMakeLists.txt
trunk/blender/source/blender/imbuf/CMakeLists.txt
trunk/blender/source/blender/imbuf/intern/oiio/CMakeLists.txt
trunk/blender/source/blender/makesrna/SConscript
trunk/blender/source/blender/makesrna/intern/CMakeLists.txt
trunk/blender/source/blender/python/intern/CMakeLists.txt
Modified: trunk/blender/source/blender/CMakeLists.txt
===
--- trunk/blender/source/blender/CMakeLists.txt 2013-10-11 22:37:24 UTC
(rev 60691)
+++ trunk/blender/source/blender/CMakeLists.txt 2013-10-11 23:14:01 UTC
(rev 60692)
@@ -117,7 +117,7 @@
add_subdirectory(imbuf/intern/openexr)
endif()
-if(WITH_IMAGE_PSD)
+if(WITH_IMAGE_OPENIMAGEIO)
add_subdirectory(imbuf/intern/oiio)
endif()
Modified: trunk/blender/source/blender/blenkernel/SConscript
===
--- trunk/blender/source/blender/blenkernel/SConscript 2013-10-11
22:37:24 UTC (rev 60691)
+++ trunk/blender/source/blender/blenkernel/SConscript 2013-10-11
23:14:01 UTC (rev 60692)
@@ -102,7 +102,7 @@
defs.append('WITH_SDL')
if env['WITH_BF_OIIO']:
-defs.append('WITH_OIIO')
+defs.append('WITH_OPENIMAGEIO')
if env['WITH_BF_OPENEXR']:
defs.append('WITH_OPENEXR')
Modified: trunk/blender/source/blender/editors/space_file/CMakeLists.txt
===
--- trunk/blender/source/blender/editors/space_file/CMakeLists.txt
2013-10-11 22:37:24 UTC (rev 60691)
+++ trunk/blender/source/blender/editors/space_file/CMakeLists.txt
2013-10-11 23:14:01 UTC (rev 60692)
@@ -58,7 +58,7 @@
add_definitions(-DWITH_OPENEXR)
endif()
-if(WITH_OPENIMAGEIO)
+if(WITH_IMAGE_OPENIMAGEIO)
add_definitions(-DWITH_OPENIMAGEIO)
endif()
Modified: trunk/blender/source/blender/editors/space_image/CMakeLists.txt
===
--- trunk/blender/source/blender/editors/space_image/CMakeLists.txt
2013-10-11 22:37:24 UTC (rev 60691)
+++ trunk/blender/source/blender/editors/space_image/CMakeLists.txt
2013-10-11 23:14:01 UTC (rev 60692)
@@ -50,7 +50,7 @@
add_definitions(-DWITH_INTERNATIONAL)
endif()
-if(WITH_OPENIMAGEIO)
+if(WITH_IMAGE_OPENIMAGEIO)
add_definitions(-DWITH_OPENIMAGEIO)
endif()
Modified: trunk/blender/source/blender/imbuf/CMakeLists.txt
===
--- trunk/blender/source/blender/imbuf/CMakeLists.txt 2013-10-11
22:37:24 UTC (rev 60691)
+++ trunk/blender/source/blender/imbuf/CMakeLists.txt 2013-10-11
23:14:01 UTC (rev 60692)
@@ -106,7 +106,7 @@
endif()
-if(WITH_OPENIMAGEIO)
+if(WITH_IMAGE_OPENIMAGEIO)
add_definitions(-DWITH_OPENIMAGEIO)
endif()
Modified: trunk/blender/source/blender/imbuf/intern/oiio/CMakeLists.txt
===
--- trunk/blender/source/blender/imbuf/intern/oiio/CMakeLists.txt
2013-10-11 22:37:24 UTC (rev 60691)
+++ trunk/blender/source/blender
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [60692] trunk/blender/source/blender: Fix build scripts related to PSD support.
Got it, but I think the CMake variable WITH_OPENIMAGEIO is not needed. It should be replaced with WITH_IMAGE_OPENIMAGEIO, and Cycles should simply depend on WITH_IMAGE_OPENIMAGEIO like this: # auto enable openimageio for cycles if(WITH_CYCLES) set(WITH_IMAGE_OPENIMAGEIO ON) endif() # auto enable openimageio linking dependencies if(WITH_IMAGE_OPENIMAGEIO) set(WITH_IMAGE_OPENEXR ON) set(WITH_IMAGE_TIFF ON) endif() IRIE Shinsuke 13/10/12, Dalai Felinto wrote: Hi, it causes unwanted behavior that the PSD support is enabled even if WITH_IMAGE_OPENIMAGEIO=OFF and WITH_CYCLES=ON This is actually the wanted behaviour. Bear with me ... If the average user just builds Blender, she gets Cycles, PSD, all the goodies. If the advanced user/developer doesn't want to build Cycles but wants PSD support, she does WITH_CYCLES=OFF and WITH_IMAGE_OPENIMAGEIO=ON If the user doesn't want anything to use OIIO, she simply does WITH_CYCLES=OFF. I believe (may be wrong) that one of main ideas of having those defines in the code is to speed up building (less code to build, less libraries to link to ...). Thus I think we should tie the defines to the library, not the feature. Dalai // mobile ___ 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] PSD file is not displayed with a file choice screen of Image Editor.(r60621)
The corresponding build options for CMake and SCons are WITH_IMAGE_PSD and WITH_BF_PSD, respectively. You need to add WITH_BF_PSD = True to your config file. IRIE Shinsuke 13/10/09, PerfectionCat wrote: Hi. It was directed to add WITH_PSD, and to build. However, I think WITH_PSD to be a form to treat inside. I recognize that it is custom to define in a form of WITH_BF_XXX when you treat it as a build option. And WITH_PSD is not defined by win32-vc-config.py. How should I treat WITH_PSD which is not defined as a build switch? PerfectionCat - Original Message - From: Dalai Felinto dfeli...@gmail.com To: PerfectionCat sindra1961reb...@yahoo.co.jp Date: 2013/10/9, Wed 12:04 Subject: Re: [Bf-committers] PSD file is not displayed with a file choice screen of Image Editor.(r60621) Hi, I think I'm having difficulties understand your English. I fixed the building problem in review 60623. You need to build with WITH_PSD to have photoshop support. If there is a problem I need to see what the problem is, in order to fix. All the best, 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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [60484] trunk/blender/source/blender/ blenkernel/intern: Fix issues reported by coverity scan in recent changes to customdata code
Hi,
Since this commit, I get annoying endless warnings when opening my
.blend files:
CustomData_copy_data_layer: warning null data for CDOrigIndex type ((nil) --
(nil)), skipping
CustomData_copy_data_layer: warning null data for CDOrigIndex type ((nil) --
(nil)), skipping
CustomData_copy_data_layer: warning null data for CDOrigIndex type ((nil) --
(nil)), skipping
CustomData_copy_data_layer: warning null data for CDOrigIndex type ((nil) --
(nil)), skipping
CustomData_copy_data_layer: warning null data for CDOrigIndex type ((nil) --
(nil)), skipping
CustomData_copy_data_layer: warning null data for CDOrigIndex type ((nil) --
(nil)), skipping
CustomData_copy_data_layer: warning null data for CDOrigIndex type ((nil) --
(nil)), skipping
CustomData_copy_data_layer: warning null data for CDOrigIndex type ((nil) --
(nil)), skipping
CustomData_copy_data_layer: warning null data for CDOrigIndex type ((nil) --
(nil)), skipping
CustomData_copy_data_layer: warning null data for CDOrigIndex type ((nil) --
(nil)), skipping
CustomData_copy_data_layer: warning null data for CDOrigIndex type ((nil) --
(nil)), skipping
...
If both src_data and dest_data are null, is the warning really
necessary?
IRIE Shinsuke
13/10/01, Brecht Van Lommel wrote:
Revision: 60484
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=60484
Author: blendix
Date: 2013-10-01 12:48:41 + (Tue, 01 Oct 2013)
Log Message:
---
Fix issues reported by coverity scan in recent changes to customdata code.
Modified Paths:
--
trunk/blender/source/blender/blenkernel/intern/customdata.c
trunk/blender/source/blender/blenkernel/intern/mesh.c
Modified: trunk/blender/source/blender/blenkernel/intern/customdata.c
===
--- trunk/blender/source/blender/blenkernel/intern/customdata.c
2013-10-01 12:48:32 UTC (rev 60483)
+++ trunk/blender/source/blender/blenkernel/intern/customdata.c
2013-10-01 12:48:41 UTC (rev 60484)
@@ -1463,8 +1463,7 @@
for (i = 0; i data-totlayer; ++i)
if (data-layers[i].type == type)
- if ((!name !data-layers[i].name) ||
- (strcmp(data-layers[i].name, name) == 0))
+ if (strcmp(data-layers[i].name, name) == 0)
return i;
return -1;
@@ -1970,11 +1969,9 @@
dest_offset = dest_index * typeInfo-size;
if (!src_data || !dest_data) {
- if (src_data != NULL dest_data != NULL) {
- printf(%s: warning null data for %s type (%p -- %p),
skipping\n,
-__func__,
layerType_getName(source-layers[src_i].type),
-(void *)src_data, (void *)dest_data);
- }
+ printf(%s: warning null data for %s type (%p -- %p),
skipping\n,
+__func__,
layerType_getName(source-layers[src_i].type),
+(void *)src_data, (void *)dest_data);
return;
}
Modified: trunk/blender/source/blender/blenkernel/intern/mesh.c
===
--- trunk/blender/source/blender/blenkernel/intern/mesh.c 2013-10-01
12:48:32 UTC (rev 60483)
+++ trunk/blender/source/blender/blenkernel/intern/mesh.c 2013-10-01
12:48:41 UTC (rev 60484)
@@ -645,7 +645,7 @@
}
cdlp = pdata-layers[poly_index];
cdlu = ldata-layers[loop_index];
- cdlf = do_tessface ? fdata-layers[face_index] : NULL;
+ cdlf = fdata do_tessface ? fdata-layers[face_index] : NULL;
BLI_strncpy(cdlp-name, new_name, sizeof(cdlp-name));
CustomData_set_layer_unique_name(pdata, cdlp - pdata-layers);
@@ -662,8 +662,10 @@
CustomData_set_layer_unique_name(ldata, cdlu -
ldata-layers);
break;
case 2:
- BLI_strncpy(cdlf-name, cdlp-name,
sizeof(cdlf-name));
- CustomData_set_layer_unique_name(fdata, cdlf -
fdata-layers);
+ if (cdlf) {
+ BLI_strncpy(cdlf-name, cdlp-name,
sizeof(cdlf-name));
+ CustomData_set_layer_unique_name(fdata,
cdlf - fdata-layers);
+ }
break;
}
}
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [60568] trunk/blender/source/blender/ blenkernel/intern/customdata.c: Fix for unnecessary customdata warning with empty meshes.
Thanks, but this commit did no functional change.
Did you comment out it accidentally?
IRIE Shinsuke
13/10/05, Brecht Van Lommel wrote:
Revision: 60568
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=60568
Author: blendix
Date: 2013-10-05 13:36:55 + (Sat, 05 Oct 2013)
Log Message:
---
Fix for unnecessary customdata warning with empty meshes.
Modified Paths:
--
trunk/blender/source/blender/blenkernel/intern/customdata.c
Modified: trunk/blender/source/blender/blenkernel/intern/customdata.c
===
--- trunk/blender/source/blender/blenkernel/intern/customdata.c
2013-10-05 12:46:32 UTC (rev 60567)
+++ trunk/blender/source/blender/blenkernel/intern/customdata.c
2013-10-05 13:36:55 UTC (rev 60568)
@@ -1969,9 +1969,11 @@
dest_offset = dest_index * typeInfo-size;
if (!src_data || !dest_data) {
- printf(%s: warning null data for %s type (%p -- %p),
skipping\n,
-__func__,
layerType_getName(source-layers[src_i].type),
-(void *)src_data, (void *)dest_data);
+ //if (!(src_data == NULL dest_data == NULL)) {
+ printf(%s: warning null data for %s type (%p -- %p),
skipping\n,
+__func__,
layerType_getName(source-layers[src_i].type),
+(void *)src_data, (void *)dest_data);
+ //}
return;
}
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Precision and default range of IntProperty
Hi devs, In Python3, int type number has variable precision, but IntProperty provides a fixed precision integer. So, if a Python script saves a very large number in the intger property, the value may overflow and cause unexpected results. Indeed, an error caused by such overflow was reported in the tracker: https://projects.blender.org/tracker/index.php?func=detailaid=36857group_id=9atid=498 Why doesn't integer property use variable precision? Intentional? One more thing, The description of IntProperty says ... min=-sys.maxint, max=sys.maxint, Here, sys.maxint not existing in Python3 can be substituted with sys.maxsize. However, IntProperty actually uses INT_MIN and INT_MAX for the default range, and sys.maxsize is not same as INT_MAX. On Ubuntu (64bit or 32bit), sys.maxsize = 9223372036854775807 or 2147483647 INT_MAX = 2147483647 LONG_MAX = 9223372036854775807L or 2147483647L LLONG_MAX = 9223372036854775807LL We should correct the description or change the default range. Thanks -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Precision and default range of IntProperty
Thanks, Brecht. Will report the issue in the tracker. IRIE Shinsuke 13/10/05, Brecht Van Lommel wrote: On Fri, Oct 4, 2013 at 4:45 PM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: Hi devs, In Python3, int type number has variable precision, but IntProperty provides a fixed precision integer. So, if a Python script saves a very large number in the intger property, the value may overflow and cause unexpected results. Indeed, an error caused by such overflow was reported in the tracker: https://projects.blender.org/tracker/index.php?func=detailaid=36857group_id=9atid=498 Why doesn't integer property use variable precision? Intentional? It's intentional. Blender is written in C/C++, and they used fixed precision, variable precision would be quite difficult to add. One more thing, The description of IntProperty says ... min=-sys.maxint, max=sys.maxint, Here, sys.maxint not existing in Python3 can be substituted with sys.maxsize. However, IntProperty actually uses INT_MIN and INT_MAX for the default range, and sys.maxsize is not same as INT_MAX. On Ubuntu (64bit or 32bit), sys.maxsize = 9223372036854775807 or 2147483647 INT_MAX = 2147483647 LONG_MAX = 9223372036854775807L or 2147483647L LLONG_MAX = 9223372036854775807LL We should correct the description or change the default range. Agreed, but this kind of thing is best reported in the bug tracker. Brecht. ___ 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] SVN commit: /data/svn/bf-blender [60497] trunk/blender/source/blender/ editors/interface/interface_handlers.c: OSX/keys: change to OSX conform cmd-a for 'select-al
Thanks, I've been aware that the actions in the text field are not
operators but I was not sure why we don't use operators.
IRIE Shinsuke
13/10/03, Campbell Barton wrote:
On Wed, Oct 2, 2013 at 2:26 PM, IRIE Shinsuke irieshins...@yahoo.co.jp
wrote:
Why don't we use a keymap for the text input field?
Because these actions are not operators which could be triggered by a
keymap (currently the way keymaps work each key stores an operator
identifier),
So instead the events are handled directly, the UI could be made to
use operators but this likely isn't such a trivial change.
Note that the old keybinding is working again in svn.
I'm a Linux+Emacs user so I want to use Emacs style key bindings
anywhere in Blender, but cannot customize the key bindings of the
text input field. Especially, utf8 input using XIM becomes a
mixture of the different styles of key bindings...
IRIE Shinsuke
13/10/02, Campbell Barton wrote:
Blender so far keeps cross platform key bindings (with a few rare
exceptions we cant avoid like Shift+Numpad on Windows because its not
supported), there is some advantage that a tutorial/screencast on one
platform can be used on another.
I'd like some input from other devs here (OSX devs spesifiically), but
I can't see a good reason to disable keys that used to work and that
work on every other platform.
On Wed, Oct 2, 2013 at 4:49 AM, Jens Verwiebe i...@jensverwiebe.de wrote:
Hi Cambo
I'd say supporting both is wrong.
Ctrl-a is not an OSX-convention for Select-all but Move to beginning of
line/paragraph
Jens
Am 01.10.2013 um 20:26 schrieb Campbell Barton ideasma...@gmail.com:
Shouldn't both be supported?
As far as I can tell, up until now we've added OSX Cmd-key where its
expected but leave Ctrl working too.
On Wed, Oct 2, 2013 at 3:47 AM, jens verwiebe i...@jensverwiebe.de
wrote:
Revision: 60497
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=60497
Author: jensverwiebe
Date: 2013-10-01 17:47:08 + (Tue, 01 Oct 2013)
Log Message:
---
OSX/keys: change to OSX conform cmd-a for 'select-all' in text(-boxes)
Modified Paths:
--
trunk/blender/source/blender/editors/interface/interface_handlers.c
Modified:
trunk/blender/source/blender/editors/interface/interface_handlers.c
===
--- trunk/blender/source/blender/editors/interface/interface_handlers.c
2013-10-01 16:40:11 UTC (rev 60496)
+++ trunk/blender/source/blender/editors/interface/interface_handlers.c
2013-10-01 17:47:08 UTC (rev 60497)
@@ -2228,7 +2228,11 @@
case AKEY:
/* Ctrl + A: Select all */
+#if !defined(__APPLE__)
if (event-ctrl !(event-alt ||
event-shift || event-oskey)) {
+#else
+ if (event-oskey !(event-alt ||
event-shift || event-ctrl)) { // OSX conformity
+#endif
ui_textedit_move(but, data,
STRCUR_DIR_PREV,
false,
STRCUR_JUMP_ALL);
ui_textedit_move(but, data,
STRCUR_DIR_NEXT,
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
--
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
_
Jens Verwiebe
Allerskehre 44 - 22309 Hamburg
Tel.: +49 40 68 78 50
mobil: +49 172 400 49 07
mailto: i...@jensverwiebe.de
web: http://www.jensverwiebe.de
_
___
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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [60497] trunk/blender/source/blender/ editors/interface/interface_handlers.c: OSX/keys: change to OSX conform cmd-a for 'select-al
Why don't we use a keymap for the text input field?
I'm a Linux+Emacs user so I want to use Emacs style key bindings
anywhere in Blender, but cannot customize the key bindings of the
text input field. Especially, utf8 input using XIM becomes a
mixture of the different styles of key bindings...
IRIE Shinsuke
13/10/02, Campbell Barton wrote:
Blender so far keeps cross platform key bindings (with a few rare
exceptions we cant avoid like Shift+Numpad on Windows because its not
supported), there is some advantage that a tutorial/screencast on one
platform can be used on another.
I'd like some input from other devs here (OSX devs spesifiically), but
I can't see a good reason to disable keys that used to work and that
work on every other platform.
On Wed, Oct 2, 2013 at 4:49 AM, Jens Verwiebe i...@jensverwiebe.de wrote:
Hi Cambo
I'd say supporting both is wrong.
Ctrl-a is not an OSX-convention for Select-all but Move to beginning of
line/paragraph
Jens
Am 01.10.2013 um 20:26 schrieb Campbell Barton ideasma...@gmail.com:
Shouldn't both be supported?
As far as I can tell, up until now we've added OSX Cmd-key where its
expected but leave Ctrl working too.
On Wed, Oct 2, 2013 at 3:47 AM, jens verwiebe i...@jensverwiebe.de wrote:
Revision: 60497
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=60497
Author: jensverwiebe
Date: 2013-10-01 17:47:08 + (Tue, 01 Oct 2013)
Log Message:
---
OSX/keys: change to OSX conform cmd-a for 'select-all' in text(-boxes)
Modified Paths:
--
trunk/blender/source/blender/editors/interface/interface_handlers.c
Modified:
trunk/blender/source/blender/editors/interface/interface_handlers.c
===
--- trunk/blender/source/blender/editors/interface/interface_handlers.c
2013-10-01 16:40:11 UTC (rev 60496)
+++ trunk/blender/source/blender/editors/interface/interface_handlers.c
2013-10-01 17:47:08 UTC (rev 60497)
@@ -2228,7 +2228,11 @@
case AKEY:
/* Ctrl + A: Select all */
+#if !defined(__APPLE__)
if (event-ctrl !(event-alt ||
event-shift || event-oskey)) {
+#else
+ if (event-oskey !(event-alt ||
event-shift || event-ctrl)) { // OSX conformity
+#endif
ui_textedit_move(but, data,
STRCUR_DIR_PREV,
false,
STRCUR_JUMP_ALL);
ui_textedit_move(but, data,
STRCUR_DIR_NEXT,
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
--
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
_
Jens Verwiebe
Allerskehre 44 - 22309 Hamburg
Tel.: +49 40 68 78 50
mobil: +49 172 400 49 07
mailto: i...@jensverwiebe.de
web: http://www.jensverwiebe.de
_
___
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] SVN commit: /data/svn/bf-blender [60394] trunk/blender/build_files/ build_environment/install_deps.sh: install_deps.sh fix: add explicit OGG lib handling, we need
On Debian/Ubuntu, libogg-dev is automatically installed due to the package dependencies if VORBIS_USE or THEORA_USE is true. IRIE Shinsuke 13/09/27, Bastien Montagne wrote: Revision: 60394 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=60394 Author: mont29 Date: 2013-09-27 13:56:16 + (Fri, 27 Sep 2013) Log Message: --- install_deps.sh fix: add explicit OGG lib handling, we need it to pass correct values for ffmpeg libraries (at least for static builds). I?\226?\128?\153m not close to understand why this has worked fine until today... :/ Only tested with Debian, but I would not expect any issue with Fedora/Suse/Arch, this is a quite simple change! Modified Paths: -- trunk/blender/build_files/build_environment/install_deps.sh Modified: trunk/blender/build_files/build_environment/install_deps.sh === --- trunk/blender/build_files/build_environment/install_deps.sh 2013-09-27 13:54:40 UTC (rev 60393) +++ trunk/blender/build_files/build_environment/install_deps.sh 2013-09-27 13:56:16 UTC (rev 60394) @@ -247,6 +247,8 @@ # FFMPEG optional libs. VORBIS_USE=false VORBIS_DEV= +OGG_USE=false +OGG_DEV= THEORA_USE=false THEORA_DEV= XVID_USE=false @@ -1890,16 +1892,18 @@ # These libs should always be available in debian/ubuntu official repository... OPENJPEG_DEV=libopenjpeg-dev VORBIS_DEV=libvorbis-dev + OGG_DEV=libogg-dev THEORA_DEV=libtheora-dev _packages=gawk cmake cmake-curses-gui scons build-essential libjpeg-dev libpng-dev \ libfreetype6-dev libx11-dev libxi-dev wget libsqlite3-dev libbz2-dev \ libncurses5-dev libssl-dev liblzma-dev libreadline-dev $OPENJPEG_DEV \ - libopenal-dev libglew-dev yasm $THEORA_DEV $VORBIS_DEV \ + libopenal-dev libglew-dev yasm $THEORA_DEV $VORBIS_DEV $OGG_DEV \ libsdl1.2-dev libfftw3-dev patch bzip2 OPENJPEG_USE=true VORBIS_USE=true + OGG_USE=true THEORA_USE=true # Install newest libtiff-dev in debian/ubuntu. @@ -2307,15 +2311,17 @@ # These libs should always be available in fedora/suse official repository... OPENJPEG_DEV=openjpeg-devel VORBIS_DEV=libvorbis-devel + OGG_DEV=libogg-devel THEORA_DEV=libtheora-devel _packages=gcc gcc-c++ make scons libtiff-devel freetype-devel libjpeg-devel\ libpng-devel libX11-devel libXi-devel wget ncurses-devel \ readline-devel $OPENJPEG_DEV openal-soft-devel \ - glew-devel yasm $THEORA_DEV $VORBIS_DEV patch + glew-devel yasm $THEORA_DEV $VORBIS_DEV $OGG_DEV patch OPENJPEG_USE=true VORBIS_USE=true + OGG_USE=true THEORA_USE=true if [ $RPM = FEDORA -o $RPM = RHEL ]; then @@ -2643,13 +2649,15 @@ # These libs should always be available in arch official repository... OPENJPEG_DEV=openjpeg VORBIS_DEV=libvorbis + OGG_DEV=libogg THEORA_DEV=libtheora _packages=base-devel scons cmake libxi glew libpng libtiff wget openal \ - $OPENJPEG_DEV $VORBIS_DEV $THEORA_DEV yasm sdl fftw + $OPENJPEG_DEV $VORBIS_DEV $OGG_DEV $THEORA_DEV yasm sdl fftw OPENJPEG_USE=true VORBIS_USE=true + OGG_USE=true THEORA_USE=true if $WITH_ALL; then @@ -2912,6 +2920,10 @@ _packages=$_packages $VORBIS_DEV fi + if $OGG_USE; then +_packages=$_packages $OGG_DEV + fi + if $XVID_USE; then _packages=$_packages $XVID_DEV fi ___ Bf-blender-cvs mailing list bf-blender-...@blender.org http://lists.blender.org/mailman/listinfo/bf-blender-cvs ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.69 testbuild1 AHOY
I've changed id_type_items to use the brush icon rather than the particle icon in r60379. IRIE Shinsuke 13/09/26, IRIE Shinsuke wrote: I wouldn't be bothered with the present icon (originally intended for brushes) though. Using the brush icon looks strange to me because the line style is quite different from the brushes... Anyway, the most confusing thing is the particle icon (ICON_PARTICLE_DATA) is used for the ID-block type of line style in rna_ID.c. In driver variable panels on the Graph Editor, ID-type selector and ID-block selector use the different icons for line style. Did you use the particle icon there by mistake? IRIE Shinsuke 13/09/26, Tamito KAJIYAMA wrote: Tamito-san, did you ask anyone to create the line style icon? No, I didn't. I would appreciate it if the person responsible for icon design is willing to create one for Freestyle line style data blocks. I wouldn't be bothered with the present icon (originally intended for brushes) though. Regards, ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.69 testbuild1 AHOY
I understand the Carve is OK, but the font license issue is still unresolved. The DejaVu fonts must be distributed as separate files in the same way as the international fonts to avoid the GPL violation. Tamito-san, did you ask anyone to create the line style icon? IRIE Shinsuke 13/09/25, Sergey Sharybin wrote: Hi, We're using GPLv2+ for our own code and we stick to this. However, it doesn't mean release archive is to be released under exact the same license. We're fine if release archive is licensed with GPLv3, which makes it possible to use Apache2.0 license. Also no issue with Carve. We've contacted Tobias Sargeant and he's totally fine with Carve being distributed under GPLv2.0+. He's working on contacting all other Carve developers before updating LICENSE file and headers in the source files. On Wed, Sep 25, 2013 at 11:46 AM, IRIE Shinsuke irieshins...@yahoo.co.jpwrote: Hi, Two months ago I've pointed out that the DejaVu fonts embedded in the blender executable violate the GPL: http://lists.blender.org/pipermail/bf-committers/2013-July/041258.html In the testbuild1, however, the license violation remains unresolved... Also, as far as I know, Carve is still distributed under the GPLv2 that conflicts with the Apache 2.0 license and the GPLv3. Will the v2.69 be released without resolving the license issues?? BTW, an icon for Freestyle line style is still not in blender_icons.svg, so improper icons are shown in the Outliner and so on. Does anyone have a plan to create the line style icon? Thanks IRIE Shinsuke 13/09/24, Sergey Sharybin wrote: Hi, We're entering BCon4 stage and it is now time for first testbuild. Information for platform maintainers: - Build from trunk SVN revision 60355 - Addons revision 4768 - Locale revision 2274 Keep usual naming and put builds to usual place :) Also a reminder: only fixes are allowed now, also don't update interface strings unless it's really needed (changing UI strings breaks translations). ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.69 testbuild1 AHOY
Taking about Bfont and Bmonofont, not the international fonts. As for international font i've made sure font licenses are getting coped to release archive which seems to be all right with font licenses. bmonofont-i18n.ttf is one of the international fonts, so its license file (LICENSE-bmonofont-i18n.ttf.txt) is needed only when WITH_INTERNATIONAL is ON. As for bfont, it's license is also included. However, didn't see any requirements in cases font being bundled into executable itself. License might be enough, maybe not. Anyway, it was bundled like this since ancient ages and never caused issues. In cases font is bundled into executable, the font data part of the executable can be considered as a derivative of the font software, so restrictions of the font license should be inherited. GPL doesn't allow any further restrictions without additional terms. Anyway, it was bundled like this since ancient ages and never caused issues. There has been the issue since ancient age indeed, but no one was aware of that until I pointed out. Ton, did you investigate this issue? IRIE Shinsuke 13/09/25, Sergey Sharybin wrote: Are we talking about international font or about bfont? As for international font i've made sure font licenses are getting coped to release archive which seems to be all right with font licenses. As for bfont, it's license is also included. However, didn't see any requirements in cases font being bundled into executable itself. License might be enough, maybe not. Anyway, it was bundled like this since ancient ages and never caused issues. On Wed, Sep 25, 2013 at 1:15 PM, IRIE Shinsuke irieshins...@yahoo.co.jpwrote: I understand the Carve is OK, but the font license issue is still unresolved. The DejaVu fonts must be distributed as separate files in the same way as the international fonts to avoid the GPL violation. Tamito-san, did you ask anyone to create the line style icon? IRIE Shinsuke 13/09/25, Sergey Sharybin wrote: Hi, We're using GPLv2+ for our own code and we stick to this. However, it doesn't mean release archive is to be released under exact the same license. We're fine if release archive is licensed with GPLv3, which makes it possible to use Apache2.0 license. Also no issue with Carve. We've contacted Tobias Sargeant and he's totally fine with Carve being distributed under GPLv2.0+. He's working on contacting all other Carve developers before updating LICENSE file and headers in the source files. On Wed, Sep 25, 2013 at 11:46 AM, IRIE Shinsuke irieshins...@yahoo.co.jpwrote: Hi, Two months ago I've pointed out that the DejaVu fonts embedded in the blender executable violate the GPL: http://lists.blender.org/pipermail/bf-committers/2013-July/041258.html In the testbuild1, however, the license violation remains unresolved... Also, as far as I know, Carve is still distributed under the GPLv2 that conflicts with the Apache 2.0 license and the GPLv3. Will the v2.69 be released without resolving the license issues?? BTW, an icon for Freestyle line style is still not in blender_icons.svg, so improper icons are shown in the Outliner and so on. Does anyone have a plan to create the line style icon? Thanks IRIE Shinsuke 13/09/24, Sergey Sharybin wrote: Hi, We're entering BCon4 stage and it is now time for first testbuild. Information for platform maintainers: - Build from trunk SVN revision 60355 - Addons revision 4768 - Locale revision 2274 Keep usual naming and put builds to usual place :) Also a reminder: only fixes are allowed now, also don't update interface strings unless it's really needed (changing UI strings breaks translations). ___ 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 2.69 testbuild1 AHOY
I disagree with the idea that the embedded font is not a part of the executable code. The font files are converted to C programs (bfont.ttf.c and bmonofont.ttf.c), compiled, and merged into a single image. Here, bfont.ttf.c and bmonofont.ttf.c are derivatives of the original font softwares and contain executable code (initialization of variables). Merging the fonts in this way is similar to linking to static libraries. Furthermore, TrueType font is not mere data, because it normally includes hinting programs running on interpreter in the font renderer. Generally, if embedded font was not considered linked to the program, GPLed font such as GNU FreeFont wouldn't need the font embedding exception. An installer exe is quite different from this case because the bundled data is used only for restoring the original files, so the installer and the files it installs are considered as separate works: http://www.gnu.org/licenses/gpl-faq.en.html#GPLCompatInstaller The font embedded in the blender executable is not a separate work and restoring the original font files is not easy. IRIE Shinsuke 13/09/25, Brecht Van Lommel wrote: On Wed, Sep 25, 2013 at 1:17 PM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: As for bfont, it's license is also included. However, didn't see any requirements in cases font being bundled into executable itself. License might be enough, maybe not. Anyway, it was bundled like this since ancient ages and never caused issues. In cases font is bundled into executable, the font data part of the executable can be considered as a derivative of the font software, so restrictions of the font license should be inherited. GPL doesn't allow any further restrictions without additional terms. I don't know if this is really true. Is bundling something into the same executable really the same as what the GPL calls linking, does this actually make it a derivative work? If you bundle all data in a single installer exe, is that also linking? The font isn't executable code, it's data. So to me this doesn't obviously seem like a violation. Anyway, it was bundled like this since ancient ages and never caused issues. There has been the issue since ancient age indeed, but no one was aware of that until I pointed out. Ton, did you investigate this issue? Ton is on vacation at the moment, and he won't be able to reply this week and the next, I don't know if he investigated this. As I understand it, you suspect this to be an issue, but none of us are lawyers, and we don't know if this is actually an issue. If I had to take I guess, I'd say it isn't. Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.69 testbuild1 AHOY
Ah, sorry. Will contact to Ton later. He said I will put it on my agenda for August to investigate. when I reported this issue first. Anyway, I corrected the installation of LICENSE-bmonofont-i18n.ttf.txt. P.S. IRIE is the last name :) IRIE Shinsuke 13/09/26, Sergey Sharybin wrote: IRIE, please start separate thread if you're gonna to continue discussion. However, i would recommend you discussing the issue directly with Ton. There're no lawyers in this list who could make things clear. Thomas, movedbuilds to the download area. Could you please mail Bart so we've got announcement at BN? On Thu, Sep 26, 2013 at 12:36 AM, IRIE Shinsuke irieshins...@yahoo.co.jpwrote: I disagree with the idea that the embedded font is not a part of the executable code. The font files are converted to C programs (bfont.ttf.c and bmonofont.ttf.c), compiled, and merged into a single image. Here, bfont.ttf.c and bmonofont.ttf.c are derivatives of the original font softwares and contain executable code (initialization of variables). Merging the fonts in this way is similar to linking to static libraries. Furthermore, TrueType font is not mere data, because it normally includes hinting programs running on interpreter in the font renderer. Generally, if embedded font was not considered linked to the program, GPLed font such as GNU FreeFont wouldn't need the font embedding exception. An installer exe is quite different from this case because the bundled data is used only for restoring the original files, so the installer and the files it installs are considered as separate works: http://www.gnu.org/licenses/gpl-faq.en.html#GPLCompatInstaller The font embedded in the blender executable is not a separate work and restoring the original font files is not easy. IRIE Shinsuke 13/09/25, Brecht Van Lommel wrote: On Wed, Sep 25, 2013 at 1:17 PM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: As for bfont, it's license is also included. However, didn't see any requirements in cases font being bundled into executable itself. License might be enough, maybe not. Anyway, it was bundled like this since ancient ages and never caused issues. In cases font is bundled into executable, the font data part of the executable can be considered as a derivative of the font software, so restrictions of the font license should be inherited. GPL doesn't allow any further restrictions without additional terms. I don't know if this is really true. Is bundling something into the same executable really the same as what the GPL calls linking, does this actually make it a derivative work? If you bundle all data in a single installer exe, is that also linking? The font isn't executable code, it's data. So to me this doesn't obviously seem like a violation. Anyway, it was bundled like this since ancient ages and never caused issues. There has been the issue since ancient age indeed, but no one was aware of that until I pointed out. Ton, did you investigate this issue? Ton is on vacation at the moment, and he won't be able to reply this week and the next, I don't know if he investigated this. As I understand it, you suspect this to be an issue, but none of us are lawyers, and we don't know if this is actually an issue. If I had to take I guess, I'd say it isn't. Brecht. ___ 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 2.69 testbuild1 AHOY
I wouldn't be bothered with the present icon (originally intended for brushes) though. Using the brush icon looks strange to me because the line style is quite different from the brushes... Anyway, the most confusing thing is the particle icon (ICON_PARTICLE_DATA) is used for the ID-block type of line style in rna_ID.c. In driver variable panels on the Graph Editor, ID-type selector and ID-block selector use the different icons for line style. Did you use the particle icon there by mistake? IRIE Shinsuke 13/09/26, Tamito KAJIYAMA wrote: Tamito-san, did you ask anyone to create the line style icon? No, I didn't. I would appreciate it if the person responsible for icon design is willing to create one for Freestyle line style data blocks. I wouldn't be bothered with the present icon (originally intended for brushes) though. Regards, ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [59904] trunk/blender/source/blender/ makesrna/intern/rna_wm_api.c: rna wrap WM_cursor_warp
Hi Campbell, This commit broke the blenderplayer compilation: Linking CXX executable ../../bin/blenderplayer ../../lib/libbf_rna.a(rna_wm_gen.c.o): In function `Window_cursor_warp_call': rna_wm_gen.c:(.text+0x186d): undefined reference to `WM_cursor_warp' ../../lib/libbf_rna.a(rna_wm_gen.c.o): In function `Window_cursor_warp': rna_wm_gen.c:(.text+0x5431): undefined reference to `WM_cursor_warp' collect2: error: ld returned 1 exit status make[2]: *** [bin/blenderplayer] Error 1 make[1]: *** [source/blenderplayer/CMakeFiles/blenderplayer.dir/all] Error 2 make: *** [all] Error 2 IRIE Shinsuke 13/09/07, Campbell Barton wrote: Revision: 59904 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=59904 Author: campbellbarton Date: 2013-09-06 23:17:29 + (Fri, 06 Sep 2013) Log Message: --- rna wrap WM_cursor_warp Modified Paths: -- trunk/blender/source/blender/makesrna/intern/rna_wm_api.c Modified: trunk/blender/source/blender/makesrna/intern/rna_wm_api.c === --- trunk/blender/source/blender/makesrna/intern/rna_wm_api.c 2013-09-06 22:54:22 UTC (rev 59903) +++ trunk/blender/source/blender/makesrna/intern/rna_wm_api.c 2013-09-06 23:17:29 UTC (rev 59904) @@ -327,17 +327,21 @@ FunctionRNA *func; PropertyRNA *parm; - (void)func; - (void)parm; + func = RNA_def_function(srna, cursor_warp, WM_cursor_warp); + parm = RNA_def_int(func, x, 0, INT_MIN, INT_MAX, , , INT_MIN, INT_MAX); + RNA_def_property_flag(parm, PROP_REQUIRED); + parm = RNA_def_int(func, y, 0, INT_MIN, INT_MAX, , , INT_MIN, INT_MAX); + RNA_def_property_flag(parm, PROP_REQUIRED); + RNA_def_function_ui_description(func, Set the cursor position); func = RNA_def_function(srna, cursor_set, WM_cursor_set); - parm = RNA_def_property(func, icon, PROP_ENUM, PROP_NONE); + parm = RNA_def_property(func, cursor, PROP_ENUM, PROP_NONE); RNA_def_property_enum_items(parm, window_cursor_items); RNA_def_property_flag(parm, PROP_REQUIRED); RNA_def_function_ui_description(func, Set the cursor); func = RNA_def_function(srna, cursor_modal_set, WM_cursor_modal_set); - parm = RNA_def_property(func, icon, PROP_ENUM, PROP_NONE); + parm = RNA_def_property(func, cursor, PROP_ENUM, PROP_NONE); RNA_def_property_enum_items(parm, window_cursor_items); RNA_def_property_flag(parm, PROP_REQUIRED); RNA_def_function_ui_description(func, Set the cursor, so the previous cursor can be restored); ___ Bf-blender-cvs mailing list bf-blender-...@blender.org http://lists.blender.org/mailman/listinfo/bf-blender-cvs ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [59821] trunk/blender/source/blender: add positive_mod() utility function.
Hi Campbell,
Did you assume the 2nd argument in positive_mod() is a positive number?
This function returns a strange value if the devisor is negative.
Anyway, I think the function name positive_mod is inappropriate,
because the mathematically proper modulo operation always yields a
positive number if the deviser is a positive number. The binary %
operator in C language is not an actual modulo operator.
IRIE Shinsuke
13/09/05, Campbell Barton wrote:
Revision: 59821
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=59821
Author: campbellbarton
Date: 2013-09-05 10:12:00 + (Thu, 05 Sep 2013)
Log Message:
---
add positive_mod() utility function.
Modified Paths:
--
trunk/blender/source/blender/blenlib/BLI_math_base.h
trunk/blender/source/blender/blenlib/intern/math_base_inline.c
trunk/blender/source/blender/bmesh/operators/bmo_bridge.c
Modified: trunk/blender/source/blender/blenlib/BLI_math_base.h
===
--- trunk/blender/source/blender/blenlib/BLI_math_base.h 2013-09-05
09:39:38 UTC (rev 59820)
+++ trunk/blender/source/blender/blenlib/BLI_math_base.h 2013-09-05
10:12:00 UTC (rev 59821)
@@ -222,6 +222,7 @@
MINLINE int power_of_2_min_i(int n);
MINLINE int divide_round_i(int a, int b);
+MINLINE int positive_mod(int i, int n);
MINLINE float shell_angle_to_dist(const float angle);
Modified: trunk/blender/source/blender/blenlib/intern/math_base_inline.c
===
--- trunk/blender/source/blender/blenlib/intern/math_base_inline.c
2013-09-05 09:39:38 UTC (rev 59820)
+++ trunk/blender/source/blender/blenlib/intern/math_base_inline.c
2013-09-05 10:12:00 UTC (rev 59821)
@@ -153,6 +153,11 @@
return (2 * a + b) / (2 * b);
}
+MINLINE int positive_mod(int i, int n)
+{
+ return ((i = i % n) 0) ? i + n : i;
+}
+
MINLINE unsigned int highest_order_bit_i(unsigned int n)
{
n |= (n 1);
Modified: trunk/blender/source/blender/bmesh/operators/bmo_bridge.c
===
--- trunk/blender/source/blender/bmesh/operators/bmo_bridge.c 2013-09-05
09:39:38 UTC (rev 59820)
+++ trunk/blender/source/blender/bmesh/operators/bmo_bridge.c 2013-09-05
10:12:00 UTC (rev 59821)
@@ -273,8 +273,7 @@
if (twist_offset != 0) {
const int len_b = BM_edgeloop_length_get(el_store_b);
ListBase *lb_b = BM_edgeloop_verts_get(el_store_b);
- const int offset = twist_offset % len_b;
- LinkData *el_b = BLI_rfindlink(lb_b, (offset 0) ?
(offset + len_b) : offset);
+ LinkData *el_b = BLI_rfindlink(lb_b,
positive_mod(twist_offset, len_b));
BLI_rotatelist(lb_b, el_b);
}
}
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Embedded Bfont violates GPL
1) Fonts are 'libraries normally distrubted with the OS' therefore the GPL linking to such libraries is excluded from any GPL linking restriction Did you mean system library exception? In this case the exception cannot be applied because: - DejaVu fonts are not major essential components of the OS - Bfont and Bmonofont are inseparably embedded in the Blender excutable 2) Fonts are trademarked - the renaming can be viewed as requiring changes to avoid trademark infringement. People aren't allow to make... I didn't mention trademark... The further restrictions imposed by the DejaVu font license are not for avoiding trademark infringement. Bitstream Vera is indeed trademarked, but AFAIK Tavmjong Bah and Arev are not. Apache 1.1 license is incompatible with the GPL for the similar restrictions (The derivative works are prohibited from using Apache names without prior written permission). http://directory.fsf.org/wiki/License:Apache1.1 IRIE Shinsuke 13/07/18, Tom M wrote: 1) Fonts are 'libraries normally distrubted with the OS' therefore the GPL linking to such libraries is excluded from any GPL linking restriction 2) Fonts are trademarked - the renaming can be viewed as requiring changes to avoid trademark infringement. People aren't allow to make changes to other trademarkable items such as the blender logo. Since this is true of all aspects subject to trademark protection, and every GPLed project generally includes trademarkable elements, either all GPLed projects are in violation of the GPL - or the GPL has trademark exceptions in fact, even if not explicitly stated. LetterRip On Wed, Jul 17, 2013 at 7:19 AM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: Hi, Blender's default font (Bfont = DejaVu Sans fonts) is embedded in the program binary, so the Bfont is distributed under GPL. However, this GPLed DejaVu fonts still inherit the following hateful restrictions: - The Font Software may be modified, altered, or added to, and in particular the designs of glyphs or characters in the Fonts may be modified and additional glyphs or characters may be added to the Fonts, only if the fonts are renamed to names not containing either the words Bitstream or the word Vera. - The Font Software may be modified, altered, or added to, and in particular the designs of glyphs or characters in the Fonts may be modified and additional glyphs or characters may be added to the Fonts, only if the fonts are renamed to names not containing either the words Tavmjong Bah or the word Arev. - The Font Software may be sold as part of a larger software package but no copy of one or more of the Font Software typefaces may be sold by itself. Such further restrictions apparently violate the GPL. To avoid the license violation, Blender has to drop the Bitstream Vera derivative fonts (Bfont + Bmonofont) or load these fonts from separate font files as runtime data on startup. The international fonts don't cause the problem because they are distributed as separate font files in 2.6x/datafiles/fonts/ directory. Thanks -- IRIE Shinsuke ___ 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] Embedded Bfont violates GPL
Yeah, the section 7 of GPLv3 indicates two facts: - The GPL needs modification (the additional term) for the embedded font part to prohibit the derivative works from using Bitstream or Arev names - Prohibition of sale of the font only package is further restriction wihch cannot be allowed by the additional terms So I conclude that the Bfont and Bmonofont cannot be embedded in the Blender executable without violating the GPL. IRIE Shinsuke 13/07/18, David Jeske wrote: On Wed, Jul 17, 2013 at 11:20 PM, IRIE Shinsuke irieshins...@yahoo.co.jpwrote: Apache 1.1 license is incompatible with the GPL for the similar restrictions (The derivative works are prohibited from using Apache names without prior written permission). http://directory.fsf.org/wiki/License:Apache1.1 FWIW, GPLv3 seems to specifically allow renaming clauses under section 7.(c,e) 7.Additional Terms. ... Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms: ... c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be *marked in reasonable ways as different from the original version*; or e) *Declining to grant rights* under trademark law for use of some *trade names, trademarks, or service marks*; or ___ 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] Embedded Bfont violates GPL
Hi, Blender's default font (Bfont = DejaVu Sans fonts) is embedded in the program binary, so the Bfont is distributed under GPL. However, this GPLed DejaVu fonts still inherit the following hateful restrictions: - The Font Software may be modified, altered, or added to, and in particular the designs of glyphs or characters in the Fonts may be modified and additional glyphs or characters may be added to the Fonts, only if the fonts are renamed to names not containing either the words Bitstream or the word Vera. - The Font Software may be modified, altered, or added to, and in particular the designs of glyphs or characters in the Fonts may be modified and additional glyphs or characters may be added to the Fonts, only if the fonts are renamed to names not containing either the words Tavmjong Bah or the word Arev. - The Font Software may be sold as part of a larger software package but no copy of one or more of the Font Software typefaces may be sold by itself. Such further restrictions apparently violate the GPL. To avoid the license violation, Blender has to drop the Bitstream Vera derivative fonts (Bfont + Bmonofont) or load these fonts from separate font files as runtime data on startup. The international fonts don't cause the problem because they are distributed as separate font files in 2.6x/datafiles/fonts/ directory. Thanks -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Weekly developer meeting, July 14, 2013
Hi, - Good news! Pixar will release OpenSubdiv in GPL-compatible license! http://graphics.pixar.com/opensubdiv/release_info.html Apache 2.0 license is compatible with GPLv3 but incompatible with v2. Indeed Blender source tree includes GPLv3+ files (in intern/smoke) so I believe Blender has already moved to GPLv3. However, doc/license/GPL-license.txt and release/text/GPL-license.txt files are still v2's ones. Have we forgotten to update these license files? IRIE Shinsuke 13/07/14, Ton Roosendaal wrote: Hi all, Here's a summary of today's meeting in irc.freenode.net #blendercoders. 1) Blender 2.68 release status - Bug tracker still at 115 open reports. No showstopper reports (things that used to work in previous release(s)). - Sergey Sharybin likes a bit of time to fix 2 reports. - Ton Roosendaal checks add-node error for HiDPI screens, Lukas Toenne is around to assist. - Proposal: wednesday release-ahoy, thursday release! Also means the logs would get ready then. - Splash - reminder to Bassam Kurdali to contact Ton! 2) Other projects - Ton proposes: when he's back from Siggraph, during august, he'll try to set up a UI project for defaults and required changes/improvements for 2.7x - Good news! Pixar will release OpenSubdiv in GPL-compatible license! http://graphics.pixar.com/opensubdiv/release_info.html 3) GSoC - Sergey has first threaded Object update work. On his 4 core system speedup was between factor 2-3. Tested with robot attack scene from ToS and a bunch of BBB chinchillas. - Ton has been sending out warnings to students - it's very important to communicate well about progress, especially with good docs and daily well logged commits. - Midterm evaluation starts in two weeks. Students should make sure their planning and deliverables matches what was agreed on. Check for more info on the list here: http://lists.blender.org/mailman/listinfo/soc-2013-dev Thanks, -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Please keep OSL script compatibility
Hi Cycles devs, With Blender 2.66/2.67, I've already used OSL closure specular_toon() in several .blend files (e.g. http://www.blendswap.com/blends/view/67827), but your recent commit renamed this and broke file compatibility so I have to modify many many material node settings in the older .blend files... That's very annoying. To keep the compatibility, could you restore the older name or provide it as an alias? Thanks, -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Please keep OSL script compatibility
Hi,
Thanks for the fix, but I still get errors like below:
ERROR: Closure 'specular_toon' is not supported by the current renderer, called
from (/tmp/tmpsxc72o.osl:15)
Re-compilation solves this but resets all parameters of the OSL script
nodes, so I have to set them again... Could you fix this error?
Or, is there any way to keep the node parameters?
BTW, shader_script_update button in PropertiesMaterialSurface panel
seems not working (always grayed out).
IRIE Shinsuke
13/06/10, Brecht Van Lommel wrote:
I think we should preserve compatibility. It's just a matter of adding
a function to stdosl.h like this
closure color specular_toon(normal N, float size, float smooth) {
return glossy_toon(N, size, smooth); }
On Mon, Jun 10, 2013 at 1:21 PM, Thomas Dinges blen...@dingto.org wrote:
Hi,
changing the closure name was a step to keep the code consistent.
The toon closures were only experimental before, so I rather not add
file compatibility code for this change. (Not sure this is possible
even, maybe with some code duplication).
Thomas
Am 10.06.2013 13:15, schrieb IRIE Shinsuke:
Hi Cycles devs,
With Blender 2.66/2.67, I've already used OSL closure specular_toon()
in several .blend files (e.g. http://www.blendswap.com/blends/view/67827),
but your recent commit renamed this and broke file compatibility so I
have to modify many many material node settings in the older .blend
files... That's very annoying.
To keep the compatibility, could you restore the older name or provide
it as an alias?
Thanks,
--
Thomas Dinges
Blender Developer, Artist and Musician
www.dingto.org
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [56558] trunk/blender/release/scripts/ modules/console_python.py: auto indent for multi-line python statements.
Hi Campbell, This behavior is convenient for keyboard inputs, but very annoying when copypasting a multiline code from text editor because the indentation unwantedly changed causes IndentationError... Cannot the auto-indent be disabled when pasting a code from clipboard? IRIE Shinsuke 13/05/08, Campbell Barton wrote: Revision: 56558 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=56558 Author: campbellbarton Date: 2013-05-08 12:57:00 + (Wed, 08 May 2013) Log Message: --- auto indent for multi-line python statements. Modified Paths: -- trunk/blender/release/scripts/modules/console_python.py Modified: trunk/blender/release/scripts/modules/console_python.py === --- trunk/blender/release/scripts/modules/console_python.py 2013-05-08 12:56:51 UTC (rev 56557) +++ trunk/blender/release/scripts/modules/console_python.py 2013-05-08 12:57:00 UTC (rev 56558) @@ -190,12 +190,17 @@ if is_multiline: sc.prompt = PROMPT_MULTI +indent = line[:len(line) - len(line.lstrip())] +if line.rstrip().endswith(:): +indent += else: sc.prompt = PROMPT +indent = # insert a new blank line -bpy.ops.console.history_append(text=, current_character=0, +bpy.ops.console.history_append(text=indent, current_character=0, remove_duplicates=True) +sc.history[-1].current_character = len(indent) # Insert the output into the editor # not quite correct because the order might have changed, ___ Bf-blender-cvs mailing list bf-blender-...@blender.org http://lists.blender.org/mailman/listinfo/bf-blender-cvs ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [56475] trunk/blender/source/blender/ makesrna/intern/rna_wm.c: Fix #35157: export key configuration did not export text input eve
Hi Brecht,
I'd already sent the similar patch to Campbell to ask him if the
fix is appropriate, but he discussed with Ton and Ton wanted to
investigate further if there is a better way to manage these cases.
Can you discuss this issue with Campbell and Ton?
IRIE Shinsuke
13/05/03, Brecht Van Lommel wrote:
Revision: 56475
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=56475
Author: blendix
Date: 2013-05-02 19:43:52 + (Thu, 02 May 2013)
Log Message:
---
Fix #35157: export key configuration did not export text input events
correctly.
Modified Paths:
--
trunk/blender/source/blender/makesrna/intern/rna_wm.c
Modified: trunk/blender/source/blender/makesrna/intern/rna_wm.c
===
--- trunk/blender/source/blender/makesrna/intern/rna_wm.c 2013-05-02
17:55:17 UTC (rev 56474)
+++ trunk/blender/source/blender/makesrna/intern/rna_wm.c 2013-05-02
19:43:52 UTC (rev 56475)
@@ -124,6 +124,11 @@
{0, NULL, 0, NULL, NULL}
};
+EnumPropertyItem event_textinput_type_items[] = {
+ {KM_TEXTINPUT, TEXTINPUT, 0, Text Input, },
+ {0, NULL, 0, NULL, NULL}
+};
+
EnumPropertyItem event_ndof_type_items[] = {
{NDOF_MOTION, NDOF_MOTION, 0, Motion, },
/* buttons on all 3dconnexion devices */
@@ -319,6 +324,8 @@
{MEDIAFIRST, MEDIA_FIRST, 0, Media First, },
{MEDIALAST, MEDIA_LAST, 0, Media Last, },
{0, , 0, NULL, NULL},
+ {KM_TEXTINPUT, TEXTINPUT, 0, Text Input, },
+ {0, , 0, NULL, NULL},
{WINDEACTIVATE, WINDOW_DEACTIVATE, 0, Window Deactivate, },
{TIMER, TIMER, 0, Timer, },
{TIMER0, TIMER0, 0, Timer 0, },
@@ -664,6 +671,7 @@
if (map_type == KMI_TYPE_TWEAK) return event_tweak_type_items;
if (map_type == KMI_TYPE_TIMER) return event_timer_type_items;
if (map_type == KMI_TYPE_NDOF) return event_ndof_type_items;
+ if (map_type == KMI_TYPE_TEXTINPUT) return event_textinput_type_items;
else return event_type_items;
}
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [55846] trunk/blender: Part I of the Freestyle branch merger: new 'freestyle' folders.
Hi Tamito-san, I experienced that loading .blend file seved in r55764 messes up the render results (Many unwanted outlines appear). Could you look into it before the branch merger? IRIE Shinsuke 13/04/07, Tamito Kajiyama wrote: Revision: 55846 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=55846 Author: kjym3 Date: 2013-04-06 15:45:02 + (Sat, 06 Apr 2013) Log Message: --- Part I of the Freestyle branch merger: new 'freestyle' folders. This commit is the first part of a two-part merger of the soc-2008-mxcurioni (Freestyle) branch. New 'freestyle' folders were added to the source/blender/ and release/script/ directories through a couple of svn copy operations (instead of svn merge, due to broken svn:mergeinfo properties of the branch). Added Paths: --- trunk/blender/release/scripts/freestyle/ trunk/blender/source/blender/freestyle/ ___ Bf-blender-cvs mailing list bf-blender-...@blender.org http://lists.blender.org/mailman/listinfo/bf-blender-cvs ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [55846] trunk/blender: Part I of the Freestyle branch merger: new 'freestyle' folders.
Forgot to mention that the problem happens when using mirror modifier. IRIE Shinsuke 13/04/07, IRIE Shinsuke wrote: Hi Tamito-san, I experienced that loading .blend file seved in r55764 messes up the render results (Many unwanted outlines appear). Could you look into it before the branch merger? IRIE Shinsuke 13/04/07, Tamito Kajiyama wrote: Revision: 55846 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=55846 Author: kjym3 Date: 2013-04-06 15:45:02 + (Sat, 06 Apr 2013) Log Message: --- Part I of the Freestyle branch merger: new 'freestyle' folders. This commit is the first part of a two-part merger of the soc-2008-mxcurioni (Freestyle) branch. New 'freestyle' folders were added to the source/blender/ and release/script/ directories through a couple of svn copy operations (instead of svn merge, due to broken svn:mergeinfo properties of the branch). Added Paths: --- trunk/blender/release/scripts/freestyle/ trunk/blender/source/blender/freestyle/ ___ Bf-blender-cvs mailing list bf-blender-...@blender.org http://lists.blender.org/mailman/listinfo/bf-blender-cvs ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [55846] trunk/blender: Part I of the Freestyle branch merger: new 'freestyle' folders.
Uploaded an example .blend file: http://www.pasteall.org/blend/20600 r55674 and r55846 produce the different render results. The mirror modifier breaks the face mark information. IRIE Shinsuke 13/04/07, IRIE Shinsuke wrote: Forgot to mention that the problem happens when using mirror modifier. IRIE Shinsuke 13/04/07, IRIE Shinsuke wrote: Hi Tamito-san, I experienced that loading .blend file seved in r55764 messes up the render results (Many unwanted outlines appear). Could you look into it before the branch merger? IRIE Shinsuke 13/04/07, Tamito Kajiyama wrote: Revision: 55846 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=55846 Author: kjym3 Date: 2013-04-06 15:45:02 + (Sat, 06 Apr 2013) Log Message: --- Part I of the Freestyle branch merger: new 'freestyle' folders. This commit is the first part of a two-part merger of the soc-2008-mxcurioni (Freestyle) branch. New 'freestyle' folders were added to the source/blender/ and release/script/ directories through a couple of svn copy operations (instead of svn merge, due to broken svn:mergeinfo properties of the branch). Added Paths: --- trunk/blender/release/scripts/freestyle/ trunk/blender/source/blender/freestyle/ ___ Bf-blender-cvs mailing list bf-blender-...@blender.org http://lists.blender.org/mailman/listinfo/bf-blender-cvs ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [55846] trunk/blender: Part I of the Freestyle branch merger: new 'freestyle' folders.
Submitted a bug report in the tracker: http://projects.blender.org/tracker/index.php?func=detailaid=34904group_id=9atid=498 IRIE Shinsuke 13/04/07, IRIE Shinsuke wrote: Uploaded an example .blend file: http://www.pasteall.org/blend/20600 r55674 and r55846 produce the different render results. The mirror modifier breaks the face mark information. IRIE Shinsuke 13/04/07, IRIE Shinsuke wrote: Forgot to mention that the problem happens when using mirror modifier. IRIE Shinsuke 13/04/07, IRIE Shinsuke wrote: Hi Tamito-san, I experienced that loading .blend file seved in r55764 messes up the render results (Many unwanted outlines appear). Could you look into it before the branch merger? IRIE Shinsuke 13/04/07, Tamito Kajiyama wrote: Revision: 55846 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=55846 Author: kjym3 Date: 2013-04-06 15:45:02 + (Sat, 06 Apr 2013) Log Message: --- Part I of the Freestyle branch merger: new 'freestyle' folders. This commit is the first part of a two-part merger of the soc-2008-mxcurioni (Freestyle) branch. New 'freestyle' folders were added to the source/blender/ and release/script/ directories through a couple of svn copy operations (instead of svn merge, due to broken svn:mergeinfo properties of the branch). Added Paths: --- trunk/blender/release/scripts/freestyle/ trunk/blender/source/blender/freestyle/ ___ Bf-blender-cvs mailing list bf-blender-...@blender.org http://lists.blender.org/mailman/listinfo/bf-blender-cvs ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [55846] trunk/blender: Part I of the Freestyle branch merger: new 'freestyle' folders.
Hi Tamito-san, Sorry, I was aware that you had submitted the patch and postponed it, but forgot that... Please close the bug after addressing the issue. BTW, I think we should announce that the branch users have to build Blender from the branch source to convert the older .blend files. Since Graphicall has stopped updating in March 21st, there are no available builds for the migration. My PPA builds for Ubuntu can be used for it now, but they will be deleted after next update. Thanks! IRIE Shinsuke 13/04/07, Tamito KAJIYAMA wrote: Hi Irie-san, Thank you for filing the issue. I am going to address it as soon as possible. Actually the problem is intentionally introduced by me after a discussion with Campbell. Freestyle needs fixes in the Mirror and Solidify modifiers to get edge/face marks working properly. I filed a patch for this problem: http://projects.blender.org/tracker/?func=detailatid=127aid=34859group_id=9 Campbell however prefered to fix the issue in a different way, suggesting to do so after the trunk merger of the Freestyle branch. So, for now Freestyle edge/face marks are supposed not to work with the two modifiers. Regards, ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [55733] trunk/blender/source/blender: More usage of GLSL for color managed image drawing
Hi Sergey,
This commit breaks the compositor. The input from primary renderlayer
is replaced with another renderlayer that is currently selected in the
renderlayer panel, so the expected result cannot be obtained unless the
primary renderlayer is selected.
Thanks,
IRIE Shinsuke
13/04/03, Sergey Sharybin wrote:
Revision: 55733
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=55733
Author: nazgul
Date: 2013-04-02 17:28:37 + (Tue, 02 Apr 2013)
Log Message:
---
More usage of GLSL for color managed image drawing
Uses GLSL for drawing image in Image Editor space.
This requires change in image_buffer_rect_update, so
original float buffer is being updated as well. This
is unlikely be something bad, but will keep an eye
on this change.
Also no byte buffer allocation happens there, this
is so because byte buffer used for display only
and in case of GLSL display such allocation and
partial update is just waste of time.
Also switched OpenGL render from using CPU color
space linearization to GLSL color space transform.
Makes OpenGL rendering pretty much faster (but
still slower than in 2.60).
internal changes:
- Added functions to setup GLSL shader for color
space conversion in colormanagement.c. Currently
conversion form a colorspace defined by a role to
linear space is implemented. Easy to extend to
other cases.
- Added helper functions to glutil.c which does
smarter image buffer draw (calling all needed OCIO
stuff, editors now could draw image buffer with a
single function call -- all the checks are done in
glutil.c).
- Also added helper function for buffer linearization
from a given role to glutil.c. Everyone now able to
linearize buffer with a single call.
This function will do nothing is GLSL routines fails
or not supported.
And one last this: this function uses offscreen
drawing, could potentially give issues on some
cards, also will keep an eye on this.
Modified Paths:
--
trunk/blender/source/blender/editors/include/BIF_glutil.h
trunk/blender/source/blender/editors/render/render_internal.c
trunk/blender/source/blender/editors/render/render_opengl.c
trunk/blender/source/blender/editors/screen/CMakeLists.txt
trunk/blender/source/blender/editors/screen/glutil.c
trunk/blender/source/blender/editors/space_clip/clip_draw.c
trunk/blender/source/blender/editors/space_image/image_draw.c
trunk/blender/source/blender/imbuf/IMB_colormanagement.h
trunk/blender/source/blender/imbuf/intern/colormanagement.c
Modified: trunk/blender/source/blender/editors/include/BIF_glutil.h
===
--- trunk/blender/source/blender/editors/include/BIF_glutil.h 2013-04-02
17:28:29 UTC (rev 55732)
+++ trunk/blender/source/blender/editors/include/BIF_glutil.h 2013-04-02
17:28:37 UTC (rev 55733)
@@ -33,6 +33,9 @@
struct rcti;
struct rctf;
+struct ImBuf;
+struct bContext;
+
void fdrawbezier(float vec[4][3]);
void fdrawline(float x1, float y1, float x2, float y2);
void fdrawbox(float x1, float y1, float x2, float y2);
@@ -223,5 +226,13 @@
} bglMats;
void bgl_get_mats(bglMats *mats);
+/* Color management helper functions for GLSL display/transform * */
+
+/* Draw imbuf on a screen, preferably using GLSL display transform */
+void glaDrawImBuf_glsl_ctx(const struct bContext *C, struct ImBuf *ibuf,
float x, float y, int zoomfilter);
+
+/* Transform buffer from role to scene linear space using GLSL OCIO
conversion */
+int glaBufferTransformFromRole_glsl(float *buffer, int width, int height,
int role);
+
#endif /* __BIF_GLUTIL_H__ */
Modified: trunk/blender/source/blender/editors/render/render_internal.c
===
--- trunk/blender/source/blender/editors/render/render_internal.c
2013-04-02 17:28:29 UTC (rev 55732)
+++ trunk/blender/source/blender/editors/render/render_internal.c
2013-04-02 17:28:37 UTC (rev 55733)
@@ -140,15 +140,23 @@
}
}
if (rectf == NULL) return;
-
- if (ibuf-rect == NULL)
- imb_addrectImBuf(ibuf);
rectf += 4 * (rr-rectx * ymin + xmin);
- IMB_partial_display_buffer_update(ibuf, rectf, NULL, rr-rectx, rxmin,
rymin,
- scene-view_settings,
scene-display_settings,
- rxmin, rymin, rxmin + xmax, rymin +
ymax, TRUE);
+ if (ibuf-rect) {
+ IMB_partial_display_buffer_update(ibuf, rectf, NULL, rr-rectx,
rxmin, rymin,
+ scene-view_settings,
scene-display_settings,
+ rxmin, rymin, rxmin + xmax,
rymin + ymax, TRUE);
+ }
+
+ /* update float buffer as well
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [55733] trunk/blender/source/blender: More usage of GLSL for color managed image drawing
Submitted a bug report in the tracker: http://projects.blender.org/tracker/index.php?func=detailaid=34854group_id=9atid=498 IRIE Shinsuke 13/04/03, Sergey Sharybin wrote: This commit does nothing to do with compositor. Please report a bug to the tracker and attach .blend file which demonstrates the issue. On Wed, Apr 3, 2013 at 1:50 PM, IRIE Shinsuke irieshins...@yahoo.co.jpwrote: Hi Sergey, This commit breaks the compositor. The input from primary renderlayer is replaced with another renderlayer that is currently selected in the renderlayer panel, so the expected result cannot be obtained unless the primary renderlayer is selected. Thanks, IRIE Shinsuke 13/04/03, Sergey Sharybin wrote: Revision: 55733 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=55733 Author: nazgul Date: 2013-04-02 17:28:37 + (Tue, 02 Apr 2013) Log Message: --- More usage of GLSL for color managed image drawing Uses GLSL for drawing image in Image Editor space. This requires change in image_buffer_rect_update, so original float buffer is being updated as well. This is unlikely be something bad, but will keep an eye on this change. Also no byte buffer allocation happens there, this is so because byte buffer used for display only and in case of GLSL display such allocation and partial update is just waste of time. Also switched OpenGL render from using CPU color space linearization to GLSL color space transform. Makes OpenGL rendering pretty much faster (but still slower than in 2.60). internal changes: - Added functions to setup GLSL shader for color space conversion in colormanagement.c. Currently conversion form a colorspace defined by a role to linear space is implemented. Easy to extend to other cases. - Added helper functions to glutil.c which does smarter image buffer draw (calling all needed OCIO stuff, editors now could draw image buffer with a single function call -- all the checks are done in glutil.c). - Also added helper function for buffer linearization from a given role to glutil.c. Everyone now able to linearize buffer with a single call. This function will do nothing is GLSL routines fails or not supported. And one last this: this function uses offscreen drawing, could potentially give issues on some cards, also will keep an eye on this. Modified Paths: -- trunk/blender/source/blender/editors/include/BIF_glutil.h trunk/blender/source/blender/editors/render/render_internal.c trunk/blender/source/blender/editors/render/render_opengl.c trunk/blender/source/blender/editors/screen/CMakeLists.txt trunk/blender/source/blender/editors/screen/glutil.c trunk/blender/source/blender/editors/space_clip/clip_draw.c trunk/blender/source/blender/editors/space_image/image_draw.c trunk/blender/source/blender/imbuf/IMB_colormanagement.h trunk/blender/source/blender/imbuf/intern/colormanagement.c Modified: trunk/blender/source/blender/editors/include/BIF_glutil.h === --- trunk/blender/source/blender/editors/include/BIF_glutil.h 2013-04-02 17:28:29 UTC (rev 55732) +++ trunk/blender/source/blender/editors/include/BIF_glutil.h 2013-04-02 17:28:37 UTC (rev 55733) @@ -33,6 +33,9 @@ struct rcti; struct rctf; +struct ImBuf; +struct bContext; + void fdrawbezier(float vec[4][3]); void fdrawline(float x1, float y1, float x2, float y2); void fdrawbox(float x1, float y1, float x2, float y2); @@ -223,5 +226,13 @@ } bglMats; void bgl_get_mats(bglMats *mats); +/* Color management helper functions for GLSL display/transform * */ + +/* Draw imbuf on a screen, preferably using GLSL display transform */ +void glaDrawImBuf_glsl_ctx(const struct bContext *C, struct ImBuf *ibuf, float x, float y, int zoomfilter); + +/* Transform buffer from role to scene linear space using GLSL OCIO conversion */ +int glaBufferTransformFromRole_glsl(float *buffer, int width, int height, int role); + #endif /* __BIF_GLUTIL_H__ */ Modified: trunk/blender/source/blender/editors/render/render_internal.c === --- trunk/blender/source/blender/editors/render/render_internal.c 2013-04-02 17:28:29 UTC (rev 55732) +++ trunk/blender/source/blender/editors/render/render_internal.c 2013-04-02 17:28:37 UTC (rev 55733) @@ -140,15 +140,23 @@ } } if (rectf == NULL) return; - - if (ibuf-rect == NULL) - imb_addrectImBuf(ibuf); rectf += 4 * (rr-rectx * ymin + xmin); - IMB_partial_display_buffer_update(ibuf, rectf, NULL, rr-rectx, rxmin, rymin, - scene-view_settings, scene-display_settings, - rxmin
Re: [Bf-committers] Swiss Cheese Text Editor Refactor/Merge
Hi Jason, The multi-column character support is what I've implemented. If your change breaks something, I maybe can help you to fix it. Anyway, I'm not planning to change the text editor drastically in the near future. IRIE Shinsuke 13/04/03, Jason Wilkins wrote: This is what I'm talking about. The multicolumn character feature modifies code that has a basic design flaw. I've fixed that flaw already, but it isn't in trunk. I'm trying to puzzle out how to fix it again, but I need to make sure I'm not stomping on any toes. On Wed, Apr 3, 2013 at 2:58 AM, Lockal S lockals...@gmail.com wrote: Would it work with multicolumn characters which were recently added by http://projects.blender.org/tracker/index.php?func=detailaid=34373group_id=9atid=127 ? On Wed, Apr 3, 2013 at 11:34 AM, Jason Wilkins jason.a.wilk...@gmail.com wrote: The drawing would be more efficient regardless of the underlying BLF rendering due to the batching. The text editor changes aren't really dependent on the other changes. My problem is that the text editor (text_draw.c) is starting to diverge in inconvenient ways. On Tue, Apr 2, 2013 at 9:11 PM, Mitchell Stokes moguri...@gmail.com wrote: Would this also include the more efficient BLF rendering? I'm guessing the text editor changes are dependent on that? I'd really love to see BLF getting away from glBegin/glEnd. On Tue, Apr 2, 2013 at 1:28 PM, Jason Wilkins jason.a.wilk...@gmail.com wrote: During the last GSoC I made some modifications to the text editor so that it would batch text before drawing it instead of drawing on character at a time. (Since I was removing immediate mode calls from swiss-cheese, sending one character at a time as WAY too much overhead.) The recent changes to the text editor have been a bit of a nightmare to merge. The code is complicated and fragile (both mine and the original). I wanted to touch base and see if it would be OK to see about going ahead and integrating swiss-cheese's more efficient text rendering into trunk. Perhaps I could also refactor some of the code to be a little bit more maintainable as well. The reason I'm asking is I'm not sure if somebody else might have plans for this area, so I don't want to just continue as I am (merging complex changes) if it just going to be blown away. ___ 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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [55702] branches/soc-2008-mxcurioni: Merged changes in the trunk up to revision 55700.
Hi Tamito-san, ME_DRAW_FREESTYLE_EDGE (1 14) conflicts with ME_DRAWEXTRA_INDICES. Campbell changed the ME_DRAWEXTRA_INDICES from (1 13) to (1 14) when adding ME_DRAWEXTRA_EDGEANG in r55660. Thanks, IRIE Shinsuke 13/04/01, Tamito Kajiyama wrote: Revision: 55702 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=55702 Author: kjym3 Date: 2013-04-01 13:47:19 + (Mon, 01 Apr 2013) Log Message: --- Merged changes in the trunk up to revision 55700. Conflicts resolved: source/blender/editors/mesh/mesh_intern.h Revision Links: -- http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=55700 Modified Paths: -- branches/soc-2008-mxcurioni/CMakeLists.txt branches/soc-2008-mxcurioni/GNUmakefile branches/soc-2008-mxcurioni/build_files/build_environment/install_deps.sh branches/soc-2008-mxcurioni/build_files/buildbot/slave_compile.py branches/soc-2008-mxcurioni/build_files/cmake/cmake_static_check_cppcheck.py branches/soc-2008-mxcurioni/build_files/scons/config/win32-mingw-config.py branches/soc-2008-mxcurioni/build_files/scons/config/win32-vc-config.py branches/soc-2008-mxcurioni/build_files/scons/config/win64-mingw-config.py branches/soc-2008-mxcurioni/build_files/scons/config/win64-vc-config.py branches/soc-2008-mxcurioni/extern/recastnavigation/recast-capi.cpp branches/soc-2008-mxcurioni/intern/audaspace/ffmpeg/AUD_FFMPEGReader.cpp branches/soc-2008-mxcurioni/intern/audaspace/ffmpeg/AUD_FFMPEGReader.h branches/soc-2008-mxcurioni/intern/cycles/blender/addon/properties.py branches/soc-2008-mxcurioni/intern/cycles/blender/addon/ui.py branches/soc-2008-mxcurioni/intern/cycles/blender/blender_session.cpp branches/soc-2008-mxcurioni/intern/cycles/blender/blender_util.h branches/soc-2008-mxcurioni/intern/cycles/render/graph.cpp branches/soc-2008-mxcurioni/intern/dualcon/intern/octree.h branches/soc-2008-mxcurioni/intern/elbeem/intern/solver_init.cpp branches/soc-2008-mxcurioni/intern/ffmpeg/ffmpeg_compat.h branches/soc-2008-mxcurioni/intern/guardedalloc/MEM_sys_types.h branches/soc-2008-mxcurioni/intern/opencolorio/CMakeLists.txt branches/soc-2008-mxcurioni/intern/opencolorio/SConscript branches/soc-2008-mxcurioni/intern/opencolorio/fallback_impl.cc branches/soc-2008-mxcurioni/intern/opencolorio/ocio_capi.cc branches/soc-2008-mxcurioni/intern/opencolorio/ocio_capi.h branches/soc-2008-mxcurioni/intern/opencolorio/ocio_impl.cc branches/soc-2008-mxcurioni/intern/opencolorio/ocio_impl.h branches/soc-2008-mxcurioni/intern/opennl/superlu/superlu_sys_types.h branches/soc-2008-mxcurioni/intern/utfconv/utf_winfunc.c branches/soc-2008-mxcurioni/intern/utfconv/utf_winfunc.h branches/soc-2008-mxcurioni/intern/utfconv/utfconv.h branches/soc-2008-mxcurioni/release/scripts/modules/bl_i18n_utils/bl_extract_messages.py branches/soc-2008-mxcurioni/release/scripts/modules/bl_i18n_utils/settings.py branches/soc-2008-mxcurioni/release/scripts/modules/bl_i18n_utils/utils.py branches/soc-2008-mxcurioni/release/scripts/modules/bpy_extras/anim_utils.py branches/soc-2008-mxcurioni/release/scripts/modules/bpy_types.py branches/soc-2008-mxcurioni/release/scripts/modules/console/complete_import.py branches/soc-2008-mxcurioni/release/scripts/startup/bl_operators/add_mesh_torus.py branches/soc-2008-mxcurioni/release/scripts/startup/bl_operators/node.py branches/soc-2008-mxcurioni/release/scripts/startup/bl_operators/rigidbody.py branches/soc-2008-mxcurioni/release/scripts/startup/bl_operators/wm.py branches/soc-2008-mxcurioni/release/scripts/startup/bl_ui/properties_paint_common.py branches/soc-2008-mxcurioni/release/scripts/startup/bl_ui/properties_physics_common.py branches/soc-2008-mxcurioni/release/scripts/startup/bl_ui/properties_render.py branches/soc-2008-mxcurioni/release/scripts/startup/bl_ui/space_image.py branches/soc-2008-mxcurioni/release/scripts/startup/bl_ui/space_nla.py branches/soc-2008-mxcurioni/release/scripts/startup/bl_ui/space_node.py branches/soc-2008-mxcurioni/release/scripts/startup/bl_ui/space_sequencer.py branches/soc-2008-mxcurioni/release/scripts/startup/bl_ui/space_userpref.py branches/soc-2008-mxcurioni/release/scripts/startup/bl_ui/space_userpref_keymap.py branches/soc-2008-mxcurioni/release/scripts/startup/bl_ui/space_view3d.py branches/soc-2008-mxcurioni/release/scripts/startup/bl_ui/space_view3d_toolbar.py branches/soc-2008-mxcurioni/release/windows/contrib/vfapi/vfapi-plugin.c branches/soc-2008-mxcurioni/source/blender/blenfont/BLF_translation.h branches/soc-2008-mxcurioni/source/blender/blenkernel/BKE_DerivedMesh.h
Re: [Bf-committers] Lack of license docs for external libs and fonts
Hi, Using the Debian's dep5 format looks good, but this is used for describing the source tree, so there are some problems: - In the release archives, locations of the data files (fonts etc.) described by Files fields may be different from the source tree - External static libraries such as OpenCOLLADA cannot be described Anyway, for reference, I attached debian/copyright file I'm using for deb packages in my PPA. Note that this file is still incomplete because it doesn't include descriptions of the functions partially copied from external projects such as glib. IRIE Shinsuke 13/03/26, Campbell Barton wrote: On Mon, Mar 25, 2013 at 5:27 AM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: Hi, Currently, Blender's release archives include license documents only for Blender(GPLv2) and Python, while any license docs for external libraries and fonts such as Bullet physics are not included. I think that violates the software licenses and the copyrights. The release archives should include a directory like licenses which contains the license docs for the external libs/fonts. Thanks, -- IRIE Shinsuke As well as there being external projects who's licenses we might miss, there are functions in files which are copied from other open-source projects. The ones I'm aware of have comments above the function stating its origin, but there isn't a good way to get an overview on who owns this copyright across many files. How about use the debian copyright format? (human and machine readable). http://www.debian.org/doc/manuals/maint-guide/dreq.en.html#copyright http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ ___ 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] SVN commit: /data/svn/bf-blender [55660] trunk/blender: add edge-angle drawing in editmode for manifold edges.
Hi Campbell,
ME_DRAWEXTRA_INDICES (1 14) in DNA_mesh_types.h will conflict with
ME_DRAW_FREESTYLE_EDGE (1 14) when the Freestyle merger is done.
Also, (1 15) is already used for ME_DRAW_FREESTYLE_FACE.
Since the me-drawflag is a short int (16bit), there are no available
bits for new draw flags anymore.
IRIE Shinsuke
13/03/29, Campbell Barton wrote:
Revision: 55660
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=55660
Author: campbellbarton
Date: 2013-03-29 04:01:52 + (Fri, 29 Mar 2013)
Log Message:
---
add edge-angle drawing in editmode for manifold edges.
Modified Paths:
--
trunk/blender/release/scripts/startup/bl_ui/space_view3d.py
trunk/blender/source/blender/editors/include/UI_resources.h
trunk/blender/source/blender/editors/interface/resources.c
trunk/blender/source/blender/editors/space_view3d/drawobject.c
trunk/blender/source/blender/makesdna/DNA_mesh_types.h
trunk/blender/source/blender/makesdna/DNA_userdef_types.h
trunk/blender/source/blender/makesrna/intern/rna_mesh.c
trunk/blender/source/blender/makesrna/intern/rna_userdef.c
Modified: trunk/blender/release/scripts/startup/bl_ui/space_view3d.py
===
--- trunk/blender/release/scripts/startup/bl_ui/space_view3d.py
2013-03-29 01:34:04 UTC (rev 55659)
+++ trunk/blender/release/scripts/startup/bl_ui/space_view3d.py
2013-03-29 04:01:52 UTC (rev 55660)
@@ -2563,6 +2563,7 @@
col.separator()
col.label(text=Numerics:)
col.prop(mesh, show_extra_edge_length)
+col.prop(mesh, show_extra_edge_angle)
col.prop(mesh, show_extra_face_angle)
col.prop(mesh, show_extra_face_area)
if bpy.app.debug:
Modified: trunk/blender/source/blender/editors/include/UI_resources.h
===
--- trunk/blender/source/blender/editors/include/UI_resources.h
2013-03-29 01:34:04 UTC (rev 55659)
+++ trunk/blender/source/blender/editors/include/UI_resources.h
2013-03-29 04:01:52 UTC (rev 55660)
@@ -185,6 +185,7 @@
TH_EDGE_CREASE,
TH_DRAWEXTRA_EDGELEN,
+ TH_DRAWEXTRA_EDGEANG,
TH_DRAWEXTRA_FACEAREA,
TH_DRAWEXTRA_FACEANG,
Modified: trunk/blender/source/blender/editors/interface/resources.c
===
--- trunk/blender/source/blender/editors/interface/resources.c
2013-03-29 01:34:04 UTC (rev 55659)
+++ trunk/blender/source/blender/editors/interface/resources.c
2013-03-29 04:01:52 UTC (rev 55660)
@@ -309,6 +309,8 @@
cp = ts-facedot_size; break;
case TH_DRAWEXTRA_EDGELEN:
cp = ts-extra_edge_len; break;
+ case TH_DRAWEXTRA_EDGEANG:
+ cp = ts-extra_edge_angle; break;
case TH_DRAWEXTRA_FACEAREA:
cp = ts-extra_face_area; break;
case TH_DRAWEXTRA_FACEANG:
@@ -766,6 +768,7 @@
btheme-tv3d.facedot_size = 4;
rgba_char_args_set(btheme-tv3d.extra_edge_len, 32, 0, 0, 255);
+ rgba_char_args_set(btheme-tv3d.extra_edge_angle, 32, 32, 0, 255);
rgba_char_args_set(btheme-tv3d.extra_face_area, 0, 32, 0, 255);
rgba_char_args_set(btheme-tv3d.extra_face_angle, 0, 0, 128, 255);
Modified: trunk/blender/source/blender/editors/space_view3d/drawobject.c
===
--- trunk/blender/source/blender/editors/space_view3d/drawobject.c
2013-03-29 01:34:04 UTC (rev 55659)
+++ trunk/blender/source/blender/editors/space_view3d/drawobject.c
2013-03-29 04:01:52 UTC (rev 55660)
@@ -2601,9 +2601,9 @@
unsigned char col[4] = {0, 0, 0, 255}; /* color of the text to draw */
float area; /* area of the face */
float grid = unit-system ? unit-scale_length : v3d-grid;
- const int do_split = unit-flag USER_UNIT_OPT_SPLIT;
- const int do_global = v3d-flag V3D_GLOBAL_STATS;
- const int do_moving = G.moving;
+ const bool do_split = (unit-flag USER_UNIT_OPT_SPLIT) != 0;
+ const bool do_global = (v3d-flag V3D_GLOBAL_STATS) != 0;
+ const bool do_moving = G.moving;
BMIter iter;
int i;
@@ -2652,6 +2652,48 @@
}
}
+ if (me-drawflag ME_DRAWEXTRA_EDGEANG) {
+ const bool is_rad = (unit-system_rotation ==
USER_UNIT_ROT_RADIANS);
+ BMEdge *eed;
+
+ UI_GetThemeColor3ubv(TH_DRAWEXTRA_EDGEANG, col);
+
+ eed = BM_iter_new(iter, em-bm, BM_EDGES_OF_MESH, NULL);
+ for (; eed; eed = BM_iter_step(iter)) {
+ /* draw
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [55484] branches/soc-2008-mxcurioni/source /blender: Fix for default values different from the factory settings.
Hi Tamito-san,
I think the default line color (and the factory setting) should be
black rather than white, because most of all cartoon pictures use dark
color outlines.
IRIE Shinsuke
13/03/22, Tamito Kajiyama wrote:
Revision: 55484
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=55484
Author: kjym3
Date: 2013-03-21 21:30:05 + (Thu, 21 Mar 2013)
Log Message:
---
Fix for default values different from the factory settings.
Suggested by IRIE Shinsuke through a code review of the branch.
Modified Paths:
--
branches/soc-2008-mxcurioni/source/blender/blenkernel/intern/linestyle.c
branches/soc-2008-mxcurioni/source/blender/freestyle/intern/blender_interface/FRS_freestyle.cpp
Modified:
branches/soc-2008-mxcurioni/source/blender/blenkernel/intern/linestyle.c
===
--- branches/soc-2008-mxcurioni/source/blender/blenkernel/intern/linestyle.c
2013-03-21 21:10:14 UTC (rev 55483)
+++ branches/soc-2008-mxcurioni/source/blender/blenkernel/intern/linestyle.c
2013-03-21 21:30:05 UTC (rev 55484)
@@ -76,7 +76,7 @@
static void default_linestyle_settings(FreestyleLineStyle *linestyle)
{
linestyle-panel = LS_PANEL_STROKES;
- linestyle-r = linestyle-g = linestyle-b = 0.0f;
+ linestyle-r = linestyle-g = linestyle-b = 1.0f;
linestyle-alpha = 1.0f;
linestyle-thickness = 1.0f;
linestyle-thickness_position = LS_THICKNESS_CENTER;
Modified:
branches/soc-2008-mxcurioni/source/blender/freestyle/intern/blender_interface/FRS_freestyle.cpp
===
---
branches/soc-2008-mxcurioni/source/blender/freestyle/intern/blender_interface/FRS_freestyle.cpp
2013-03-21 21:10:14 UTC (rev 55483)
+++
branches/soc-2008-mxcurioni/source/blender/freestyle/intern/blender_interface/FRS_freestyle.cpp
2013-03-21 21:30:05 UTC (rev 55484)
@@ -642,13 +642,13 @@
void FRS_init_freestyle_config(FreestyleConfig *config)
{
- config-mode = FREESTYLE_CONTROL_SCRIPT_MODE;
+ config-mode = FREESTYLE_CONTROL_EDITOR_MODE;
config-modules.first = config-modules.last = NULL;
config-flags = 0;
config-sphere_radius = DEFAULT_SPHERE_RADIUS;
config-dkr_epsilon = DEFAULT_DKR_EPSILON;
- config-crease_angle = DEG2RADF(120.0f);
+ config-crease_angle = DEG2RADF(134.43f);
config-linesets.first = config-linesets.last = NULL;
}
@@ -773,7 +773,7 @@
lineset-linestyle = FRS_new_linestyle(LineStyle, NULL);
lineset-flags |= FREESTYLE_LINESET_ENABLED;
- lineset-selection = FREESTYLE_SEL_IMAGE_BORDER;
+ lineset-selection = FREESTYLE_SEL_VISIBILITY |
FREESTYLE_SEL_EDGE_TYPES | FREESTYLE_SEL_IMAGE_BORDER;
lineset-qi = FREESTYLE_QI_VISIBLE;
lineset-qi_start = 0;
lineset-qi_end = 100;
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developers meeting minutes - March 24 2013
Hi Tamito-san, It seems that you forgot to update me-cd_flag in the migration code. I confirmed the following patch fixes the problem: Index: source/blender/blenloader/intern/readfile.c === --- source/blender/blenloader/intern/readfile.c (revision 1) +++ source/blender/blenloader/intern/readfile.c (working copy) @@ -9336,6 +9336,7 @@ medge++; fed++; } + me-cd_flag |= ME_CDFLAG_FREESTYLE_EDGE; printf(Migrated to CustomData-based Freestyle edge marks\n); } /* Freestyle face marks */ @@ -9359,6 +9360,7 @@ mpoly++; ffa++; } + me-cd_flag |= ME_CDFLAG_FREESTYLE_FACE; printf(Migrated to CustomData-based Freestyle face marks\n); } } With respect to the UI issue, I agree with Bastien. IRIE Shinsuke 13/03/25, Tamito KAJIYAMA wrote: Hi, - Freestyle: more reviews were done, and all handled by Tamito Kajiyama. Should be feasible for final merger this week! Tomorrow we'll do final checks. The new implementation of face/edge marks and the migration code in readfile.c still doesn't work (unfinished yet)... Though the migration code will be removed when the branch merger is done, how can Freestyle branch users convert older blend files? The migration code is working properly as far as I have tested it. Even though the migration code does not go into the trunk, it will stay in the branch at least within a certain range of revisions (actually I don't see any reason not to keep it in the branch code base). Branch users can do data conversions any time using a Freestyle branch build with the migration code in it. For what concerns the CustomData-based implementation of edge/face marks, the idea is to get approval first and then finish the rest of the implementaiton, just to avoid a waste of coding time. As soon as the present proof-of-concept implementation gets approved by core developers, I will work on unfinished parts. BTW, an UI glitch I pointed out in the code review is not fixed yet. I have replied to your review comment concerning the UI issue. Let me quote the comment and my reply here: https://codereview.appspot.com/7416049/diff/1/release/scripts/startup/bl_ui/space_view3d.py#newcode2508 irieshinsuke 2013/03/21 12:39:58 Horizontally split row is too narrow to display labels Freestyle Edge Marks and Freestyle Face Marks, so both of them are truncated to Freestyle. I think col = layout.column() should be inserted here to avoid this glitch. me 2013/03/23 22:46:08 I am not fully sure if this change should be made. Any UI label will be truncated when the panel width is narrower than the label width. The Freestyle Edge/Face Mark labels in question can be completely shown if the panel is widen. Brecht told me that UI controls should be organized in two columns in general, and the Overlays section exactly follows this rule. I tend to be reluctant to violate it here. I am fully open to any decision in this regard and will do whatever required as long as this issue is a merger stopper. With best regards, ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developers meeting minutes - March 24 2013
Hi, - Freestyle: more reviews were done, and all handled by Tamito Kajiyama. Should be feasible for final merger this week! Tomorrow we'll do final checks. The new implementation of face/edge marks and the migration code in readfile.c still doesn't work (unfinished yet)... Though the migration code will be removed when the branch merger is done, how can Freestyle branch users convert older blend files? BTW, an UI glitch I pointed out in the code review is not fixed yet. IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Lack of license docs for external libs and fonts
Hi, Currently, Blender's release archives include license documents only for Blender(GPLv2) and Python, while any license docs for external libraries and fonts such as Bullet physics are not included. I think that violates the software licenses and the copyrights. The release archives should include a directory like licenses which contains the license docs for the external libs/fonts. Thanks, -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [55525] branches/soc-2008-mxcurioni/source /blender: A major code update for making the DNA file specification of Freestyle settin
Hi Tamito-san, This commit breaks CMake compilation. I got the following error: CMake Error at build_files/cmake/macros.cmake:174 (add_library): Cannot find source file: intern/freestyle.c Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx Call Stack (most recent call first): build_files/cmake/macros.cmake:189 (blender_add_lib_nolist) source/blender/blenkernel/CMakeLists.txt:440 (blender_add_lib) CMake attempts to find nonexistent files intern/freestyle.c and BKE_freestyle.h. Regards, IRIE Shinsuke 13/03/23, Tamito Kajiyama wrote: Revision: 55525 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=55525 Author: kjym3 Date: 2013-03-23 03:00:37 + (Sat, 23 Mar 2013) Log Message: --- A major code update for making the DNA file specification of Freestyle settings and RNA for it independent of the build flag for enabling Freestyle. Suggested by Sergey Sharybin through a code review of the branch. * Many #ifdef WITH_FREESTYLE blocks were removed to always have Freestyle-specific DNA file specification and RNA for it built in Blender. This will allow Freestyle setting survive even when a non-Freestyle build is used for loading and saving files. It is noted that operations are still conditionally built through #ifdef WITH_FREESTYLE blocks. * To this end, new blenkernel files BKE_freestyle.h and intern/freestyle.c have been added. All API functions in FRS_freestyle_config.h as well as some of those in FRS_freestyle.h were moved to the new files. Now the relocated API functions have BKE_ prefix instead of FRS_. Modified Paths: -- branches/soc-2008-mxcurioni/source/blender/CMakeLists.txt branches/soc-2008-mxcurioni/source/blender/SConscript branches/soc-2008-mxcurioni/source/blender/blenfont/BLF_translation.h branches/soc-2008-mxcurioni/source/blender/blenfont/CMakeLists.txt branches/soc-2008-mxcurioni/source/blender/blenfont/SConscript branches/soc-2008-mxcurioni/source/blender/blenkernel/BKE_linestyle.h branches/soc-2008-mxcurioni/source/blender/blenkernel/BKE_main.h branches/soc-2008-mxcurioni/source/blender/blenkernel/CMakeLists.txt branches/soc-2008-mxcurioni/source/blender/blenkernel/SConscript branches/soc-2008-mxcurioni/source/blender/blenkernel/intern/anim_sys.c branches/soc-2008-mxcurioni/source/blender/blenkernel/intern/bpath.c branches/soc-2008-mxcurioni/source/blender/blenkernel/intern/group.c branches/soc-2008-mxcurioni/source/blender/blenkernel/intern/idcode.c branches/soc-2008-mxcurioni/source/blender/blenkernel/intern/library.c branches/soc-2008-mxcurioni/source/blender/blenkernel/intern/linestyle.c branches/soc-2008-mxcurioni/source/blender/blenkernel/intern/material.c branches/soc-2008-mxcurioni/source/blender/blenkernel/intern/object.c branches/soc-2008-mxcurioni/source/blender/blenkernel/intern/scene.c branches/soc-2008-mxcurioni/source/blender/blenlib/CMakeLists.txt branches/soc-2008-mxcurioni/source/blender/blenlib/SConscript branches/soc-2008-mxcurioni/source/blender/blenloader/CMakeLists.txt branches/soc-2008-mxcurioni/source/blender/blenloader/SConscript branches/soc-2008-mxcurioni/source/blender/blenloader/intern/readfile.c branches/soc-2008-mxcurioni/source/blender/blenloader/intern/writefile.c branches/soc-2008-mxcurioni/source/blender/editors/animation/CMakeLists.txt branches/soc-2008-mxcurioni/source/blender/editors/animation/SConscript branches/soc-2008-mxcurioni/source/blender/editors/animation/anim_channels_defines.c branches/soc-2008-mxcurioni/source/blender/editors/animation/anim_channels_edit.c branches/soc-2008-mxcurioni/source/blender/editors/animation/anim_filter.c branches/soc-2008-mxcurioni/source/blender/editors/include/ED_anim_api.h branches/soc-2008-mxcurioni/source/blender/editors/include/UI_resources.h branches/soc-2008-mxcurioni/source/blender/editors/interface/CMakeLists.txt branches/soc-2008-mxcurioni/source/blender/editors/interface/SConscript branches/soc-2008-mxcurioni/source/blender/editors/interface/interface_templates.c branches/soc-2008-mxcurioni/source/blender/editors/interface/resources.c branches/soc-2008-mxcurioni/source/blender/editors/render/render_shading.c branches/soc-2008-mxcurioni/source/blender/editors/space_nla/CMakeLists.txt branches/soc-2008-mxcurioni/source/blender/editors/space_nla/SConscript branches/soc-2008-mxcurioni/source/blender/editors/space_nla/nla_buttons.c branches/soc-2008-mxcurioni/source/blender/editors/space_nla/nla_channels.c branches/soc-2008-mxcurioni/source/blender/freestyle/FRS_freestyle.h branches/soc-2008-mxcurioni/source/blender/freestyle/intern/blender_interface/FRS_freestyle.cpp
Re: [Bf-committers] Freestyle: edge/face marks not working since r55228
A comment in readfile.c says: /* The code segment below will be removed when the trunk merger is done. For now it is kept for backward compatibility, giving branch users time to migrate to the new CustomData-based edge/face marks. */ I worry the branch users might not be able to convert their existing data if the migration code doesn't work until the branch merge. IRIE Shinsuke Tamito KAJIYAMA wrote: Yes, the revision 55228 is intended to address review comments and still work in progress. Among mesh modifiers, only the subdivision surface modifier works. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Freestyle: edge/face marks not working since r55228
Hi Tamito-san, Since rev. 55228, the edge/face marks are not working for me. The edge/face marks can be added, but: - Edge marks don't affect the render results when using mirror modifier - Face marks never affect the render results Also, migration from older blend files doesn't work for both edge marks and face marks. Edge/face marks are cleared when loading older blend files, though a message Migrated to CustomData-based Freestyle face marks is shown. Is the implementation still WIP? -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [55202] trunk/blender/release/datafiles/ fonts/bmonofont-i18n.ttf.gz: Add i18n monospace font (bmonofont-i18n.ttf) which will be u
Hi Bastien, I was aware that there're missing scripts for some languages but couldn't prepare available monospace fonts distributed under open-source licenses. We might have to make monospace Hebrew and Devanagari fonts. Full supports for RTL scripts and Brahmic scripts are too complex, so using library such as Pango may be better. IRIE Shinsuke Bastien Montagne wrote: Hi Shinsuke, Welcome aboard and many thanks for those two most useful commits (it also solved issue with stamp rendering, btw)! :) However, the current monospace i18n font lacks some scripts. At least, Hebrew and Devanagari, and the later looks like *highly tricky* to find in monospace (think the way it works is not well suited with monospace)... Do you have time to try to integrate them? And/or any hints about devanagari? Best regards, Bastien On 12/03/2013 08:07, Shinsuke Irie wrote: Revision: 55202 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=55202 Author: irie Date: 2013-03-12 07:07:04 + (Tue, 12 Mar 2013) Log Message: --- Add i18n monospace font (bmonofont-i18n.ttf) which will be used for the text editor and interactive console This is a mixed font based on DejaVu Sans Mono and including M+1M Regular and Wen Quan Yi Micro Hei Mono. Versions and licenses of the included fonts are as follows: - DejaVu fonts: version 2.33, Bitstream font license and Arev font license and public domain - M+ fonts: TESTFLIGHT 54, M+ font license - Wen Quan Yi Micro Hei fonts: version 0.2.0-beta, GPLv3 with font embedding exception or Apache2.0 The font license docs will be added later. Added Paths: --- trunk/blender/release/datafiles/fonts/bmonofont-i18n.ttf.gz Added: trunk/blender/release/datafiles/fonts/bmonofont-i18n.ttf.gz === (Binary files differ) Property changes on: trunk/blender/release/datafiles/fonts/bmonofont-i18n.ttf.gz ___ Added: svn:mime-type + application/octet-stream ___ Bf-blender-cvs mailing list bf-blender-...@blender.org http://lists.blender.org/mailman/listinfo/bf-blender-cvs ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Shinsuke Irie, New Committer
Hi all, thanks for the welcome! BTW, Irie is my last name. :) IRIE Shinsuke Campbell Barton wrote: Hi All, Shinsuke Irie has already done some very useful patches in the area of internationalization for the console text-editor and has now written a quite advanced patch for fixed width fonts. Patch: http://projects.blender.org/tracker/index.php?func=detailaid=34373group_id=9atid=127 Screenshot: https://plus.google.com/photos/108666457756457924138/albums/5847890778201826545/5847890782374975970?authkey=CIPZrc32pPzuTw Since this is a significant addition and quite advanced its best Irie commits and helps maintain. Welcome Irie! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cannot the international font be removed from SVN?
Hi, There is another reason to use system-wide fonts. We perhaps cannot prepare monospace fonts without license issue for all languages Blender supports. If we cannot, Blender has to use system-wide fonts (or drop supports for such languages). In such case, performing font substitutions may be needed if the system-wide font doesn't include ascii characters. IRIE Shinsuke 13/03/01, Campbell Barton wrote: On Sat, Mar 2, 2013 at 12:50 AM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: Hi devs, Recently I submitted a patch and a bug related to the internationalization: [#34373] Use i18n monospace font in Text editor and Python console http://projects.blender.org/tracker/index.php?func=detailaid=34373group_id=9atid=127 [#34396] Some kanji characters in i18n font are unreadable for Japanese users http://projects.blender.org/tracker/index.php?func=detailaid=34396group_id=9atid=498 The patch [#34373] obviously needs additional international font for displaying CJK characters properly. Also, Japanese font is needed to solve the bug [#34396]. So, Blender have to use the following fonts at least: (1) proportional font (default) = bfont.ttf (2) monospace font (default) = bmonofont.ttf (3) proportional font (international) = droidsans.ttf (4) monospace font (international) (5) proportional font (Japanese) (6) monospace font (Japanese) I'm not sure if the other languages need additional fonts. If we solve these issues by adding the fonts (4)-(6) above, file sizes of the release archives increase by 5-10MB. Maybe Linux distro maintainers hate such bundled fonts because they must remove the fonts and apply some patches to build distro packages. I think the the international font should be removed and system-wide fonts should be used instead. Thanks, -- IRIE Shinsuke As long as they are not loaded into memory when unused, I don't think its such a problem to distribute them with Blender. If Linux distros want to remove them from the packages we can make sure its possible to fonts on the system as a build option or just link the font to where blender expects it. ___ 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] Cannot the international font be removed from SVN?
Brecht, Only including bfont.ttf should be able to keep render compatibility, because the other bundled fonts (bmonofont.ttf, droidsans.ttf, and the additional i18n fonts) cannot be used for text objects. At least, including the 3 fonts (bfont.ttf, bmonofont.ttf, and droidsans.ttf) doesn't change existing things. Sergey, Debian and Ubuntu use a patch similar to Alt Linux's one. Probably Fontconfig can be used for all platforms because it doesn't depend on X-window system in any fashion, though it needs own settings appropriate for each platform (except for X11). I agreed that font names should be configurable. Anyway, I think, to support various platforms (Linux/UNIX/Win/Mac/ Android etc.), using an external cross-platform toolkit such as Qt is better than using Blender's own toolkit + GHOST. IRIE Shinsuke 13/03/02, Sergey Sharybin wrote: There was a patch for at least Alt Linux which uses fontconfig to select font from fonts installed to system. I don't consider it's fully finished because name of font is still hardcoded in that patch, but we'll need to make font name configurable or make it possible to choose it from list. On Fri, Mar 1, 2013 at 9:27 PM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: On Fri, Mar 1, 2013 at 2:50 PM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: If we solve these issues by adding the fonts (4)-(6) above, file sizes of the release archives increase by 5-10MB. Maybe Linux distro maintainers hate such bundled fonts because they must remove the fonts and apply some patches to build distro packages. I think the the international font should be removed and system-wide fonts should be used instead. I think it would be good to use system fonts for the user interface, but that needs to be implemented for all operating systems then. Once that works, maybe we should still keep the font for render compatibility of text objects, or for users that prefer the UI to be exactly the same on different operating systems. I don't know how important those things are and I guess we can have that discussion, but we need people to actually implement system font support for Linux/BSD, Windows, Mac, Android, ... before we can actually consider removing the fonts. Brecht. ___ 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] Cannot the international font be removed from SVN?
Hi devs, Recently I submitted a patch and a bug related to the internationalization: [#34373] Use i18n monospace font in Text editor and Python console http://projects.blender.org/tracker/index.php?func=detailaid=34373group_id=9atid=127 [#34396] Some kanji characters in i18n font are unreadable for Japanese users http://projects.blender.org/tracker/index.php?func=detailaid=34396group_id=9atid=498 The patch [#34373] obviously needs additional international font for displaying CJK characters properly. Also, Japanese font is needed to solve the bug [#34396]. So, Blender have to use the following fonts at least: (1) proportional font (default) = bfont.ttf (2) monospace font (default) = bmonofont.ttf (3) proportional font (international) = droidsans.ttf (4) monospace font (international) (5) proportional font (Japanese) (6) monospace font (Japanese) I'm not sure if the other languages need additional fonts. If we solve these issues by adding the fonts (4)-(6) above, file sizes of the release archives increase by 5-10MB. Maybe Linux distro maintainers hate such bundled fonts because they must remove the fonts and apply some patches to build distro packages. I think the the international font should be removed and system-wide fonts should be used instead. Thanks, -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Patches for using i18n monospace font in Text editor and Python console
Hi all, I just submitted patches that add i18n display support to the text editor and the interactive console: http://projects.blender.org/tracker/index.php?func=detailaid=34373group_id=9atid=127 Screenshot: https://plus.google.com/photos/108666457756457924138/albums/5847890778201826545/5847890782374975970?authkey=CIPZrc32pPzuTw On my machine, wrapping, selection, suggestion, etc. work properly even for CJK characters that occupy two columns per one character. The problem is there may be no suitable font which includes all characters of many languages supported by Blender. So, we should provide a mixed font like bf-intl-mono.tff, or make new font setting in user preference so that user can select font file. Anyway, please test/review it. Thanks, -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Freestyle: Polygonalization with small Error
Tamito-san, I experienced a serious problem when I was testing a geometry modifier Polygonalization with a small value of the Error parameter. Steps: 1. Start Blender and use default cube 2. Enable Freestyle 3. Add a line set if necessary 4. Add geometory modifier Polygonalization and set Error=1.0 5. Start render by F12 Then, Blender eats the memory up soon and is killed by system, or crashes immediately. This problem also occurs when combining it with the other geometry modifier such as Perlin Noise 2D, even if Error is not so small. Backtrace: http://www.pasteall.org/39640 r54427 Ubutnu 12.10 amd64 Regards, -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Freestyle: Polygonalization with small Error
Thanks for the fix! It works. However, another crash sometimes happens when adding large amplitude noise before Polygonalization modifier. Steps: 1. Start Blender and use default cube 2. Enable Freestyle 3. Add a line set 4. Add geometory modifier Perlin Noise 2D and set Amplitude=1000 5. Add geometory modifier Polygonalization and set Error=1.0 6. Start render by F12 Blender may (or may not) crash after getting warnings like strip vertex XXX non valid. Backtrace: http://www.pasteall.org/39659 IRIE Shinsuke Tamito KAJIYAMA wrote: Irie-san, Many thanks for the problem report. Indeed there was a bug in the implementation of the Polygonization geometry modifier. I made an attempt to fix it in revision 54518. Could you please test the code and see if the issue has been addressed? Thank you, ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] install_deps.sh doesn't install libqt4-opengl-dev
AFAIK, Qt is used only for the image viewer (iv), NOT required for
building libOpenImageIO. You should be able to avoid build failure
by removing libqt4-dev and txt2man packages:
sudo apt-get remove libqt4-dev txt2man
If you want to use iv, you should install libqt4-opengl-dev manually.
IRIE Shinsuke
knittl wrote:
Hi Blender devs,
the install_deps.sh script does not install the libqt4-opengl-dev
package under Ubuntu. This package contains the QtOpenGL/QGLWidget
file, which is required for building the OpenImageIO library.
The package has existed in the official Ubuntu repos since Lucid, and
was even backported to Hardy (cf.
http://packages.ubuntu.com/search?keywords=libqt4-opengl-dev).
Regards,
Daniel
Obvious patch below:
-8--
diff --git a/blender/build_files/build_environment/install_deps.sh
b/blender/build_files/build_environment/install_deps.sh
index 97bd94f..0a7b21f 100755
--- a/blender/build_files/build_environment/install_deps.sh
+++ b/blender/build_files/build_environment/install_deps.sh
@@ -1311,7 +1311,7 @@ install_DEB() {
libfreetype6-dev libx11-dev libxi-dev wget
libsqlite3-dev libbz2-dev \
libncurses5-dev libssl-dev liblzma-dev libreadline-dev
$OPENJPEG_DEV \
libopenexr-dev libopenal-dev libglew-dev yasm
$THEORA_DEV $VORBIS_DEV \
- libsdl1.2-dev libfftw3-dev patch bzip2
+ libsdl1.2-dev libfftw3-dev patch bzip2 libqt4-opengl-dev
OPENJPEG_USE=true
VORBIS_USE=true
--
typed with http://neo-layout.org
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Freestyle: Blend mode of line thickness modifiers
Hi Tamito-san, In Freestyle build, line thickness modifiers have Blend menu to specify blend mode such as Mix and Multiply. I noticed Divide appears twice in this menu but these two items give the different results. That's very confusing and I couldn't understand how they work. Could you please change the label(s) to clarify their meanings? r54240 -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Freestyle branch: Freestyle settings are unexpectedly deleted
Tamito-san, When I add a new scene with Link Objects option, the new scene is successfully created, but the original scene loses most of all freestyle settings (linesets, linestyles, etc.). r54178 -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Freestyle branch: Cycles render layer UI broken
Thanks for the fix!
Merged Freestyle into trunk locally and confirmed it works fine.
IRIE Shinsuke
13/01/28, Bastien Montagne wrote:
Hi Irie,
Fix is in trunk (r54141), will be in freestyle at the next merge! ;)
Thanks again for spotting this issue. :)
Cheers,
Bastien
On 27/01/2013 19:06, Bastien Montagne wrote:
Very good point! That’s indeed a glitch that needs to be fixed in trunk
itself, as it may affect any panel, will do asap! Thanks for spotting it. :)
On 27/01/2013 18:24, IRIE Shinsuke wrote:
If I start Blender with --factory-startup option, the problem doesn't
happen. My startup file seems to have panel closed flag for the
render layers panel.
Probably you can reproduce the problem as follows:
1. Remove bl_options = {'HIDE_HEADER'} and do make install
2. Start blender with --factory-startup option
3. Change renderer to Cycles, and close the render layers panel
4. Save a .blend file
5. Revert the step 1
6. Start blender and load the .blend file above
Then, the panel shouldn't appear.
I think the panel closed flag should be ignored if the HIDE_HEADER
option is given.
IRIE Shinsuke
13/01/28, Bastien Montagne wrote:
That's really weird… Do you have the other controls in this panel (buttons
to the side of the list, text field below it), or do you have a completely
empty panel?
Hiding header should not affect at all panel's content…
And the same panel with internal works OK? (because they have exactly the
same code!) o_O
If draw() is really not called, then I think we have some kind of bug
unrelated to freestyle… but can't do much if I can't reproduce it :(
On 27/01/2013 17:26, IRIE Shinsuke wrote:
Ah, the render layer list appears if I removed
bl_options = {'HIDE_HEADER'} in CyclesRender_PT_layers.
Otherwise, draw() in CyclesRender_PT_layers seems not to be called.
IRIE Shinsuke
13/01/28, IRIE Shinsuke wrote:
Strange...
Of course I did make install and confirmed that ui.py has been
updated. (The issue (2) indeed has been fixed.)
And I got no error in console.
IRIE Shinsuke
13/01/27, Bastien Montagne wrote:
That’s rather odd… For me it works OK, see
http://www.pasteall.org/pic/44360 …
I suppose you did make install ? ;)
Also, could you have a look to your blender's console, there shoud be
some error message here! :)
On 27/01/2013 15:34, IRIE Shinsuke wrote:
Thanks, but unfortunately the issue (1) still isn't fixed...
Could you look into it again?
IRIE Shinsuke
13/01/27, Bastien Montagne wrote:
Hi Irie, and thanks for the report! Should be fixed in r54119. :)
Best regards,
Bastien
On 27/01/2013 13:35, IRIE Shinsuke wrote:
Tamito, in Freestyle build, render layer panel is not correctly shown
when using Cycles:
(1) Render layer list doesn't appear, so we cannot create a scene
that
uses multiple render layers.
(2) Label Layer is used twice for panel headers. That's confusing.
r54113
Ubuntu 12.10
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Freestyle crash
Hi, When using Freestyle build, I experienced a crash after creating a new scene. You should be able to reproduce it as follows: 1. Start Blender 2. Enable Freestyle and add a line set 3. Add new scene with Link Objects option 4. Undo (Ctrl+Z) Then Blender crashes immediately Made a backtrace: http://www.pasteall.org/39233 Thanks, r54129 Ubuntu 12.10 -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Freestyle crash
The following patch that adds a NULL check for linestyle fixes the
crash, though I'm not sure why it becomes NULL:
Index: source/blender/freestyle/intern/blender_interface/FRS_freestyle.cpp
===
--- source/blender/freestyle/intern/blender_interface/FRS_freestyle.cpp
(revision 54129)
+++ source/blender/freestyle/intern/blender_interface/FRS_freestyle.cpp
(working copy)
@@ -665,8 +665,10 @@
lineset-group-id.us--;
lineset-group = NULL;
}
- lineset-linestyle-id.us--;
- lineset-linestyle = NULL;
+ if (lineset-linestyle) {
+ lineset-linestyle-id.us--;
+ lineset-linestyle = NULL;
+ }
}
BLI_freelistN(srl-freestyleConfig.linesets);
BLI_freelistN(srl-freestyleConfig.modules);
IRIE Shinsuke
13/01/29, IRIE Shinsuke wrote:
Hi,
When using Freestyle build, I experienced a crash after creating a new
scene. You should be able to reproduce it as follows:
1. Start Blender
2. Enable Freestyle and add a line set
3. Add new scene with Link Objects option
4. Undo (Ctrl+Z)
Then Blender crashes immediately
Made a backtrace: http://www.pasteall.org/39233
Thanks,
r54129
Ubuntu 12.10
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Freestyle crash
Hi Tamito, and thanks for the fix! However, unfortunately the build fails if WITH_PLAYER=ON... You forgot to modify source/blenderplayer/bad_level_call_stubs/stubs.c. IRIE Shinsuke 13/01/29, Tamito KAJIYAMA wrote: Irie-san, Thank you for the problem report. The issue was addressed in revision 54172. Both the backtrace and the patch helped a lot. Many thanks! With best regards, ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Freestyle branch: Cycles render layer UI broken
Tamito, in Freestyle build, render layer panel is not correctly shown when using Cycles: (1) Render layer list doesn't appear, so we cannot create a scene that uses multiple render layers. (2) Label Layer is used twice for panel headers. That's confusing. r54113 Ubuntu 12.10 -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Freestyle branch: Cycles render layer UI broken
Thanks, but unfortunately the issue (1) still isn't fixed... Could you look into it again? IRIE Shinsuke 13/01/27, Bastien Montagne wrote: Hi Irie, and thanks for the report! Should be fixed in r54119. :) Best regards, Bastien On 27/01/2013 13:35, IRIE Shinsuke wrote: Tamito, in Freestyle build, render layer panel is not correctly shown when using Cycles: (1) Render layer list doesn't appear, so we cannot create a scene that uses multiple render layers. (2) Label Layer is used twice for panel headers. That's confusing. r54113 Ubuntu 12.10 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Freestyle branch: Cycles render layer UI broken
Ah, the render layer list appears if I removed
bl_options = {'HIDE_HEADER'} in CyclesRender_PT_layers.
Otherwise, draw() in CyclesRender_PT_layers seems not to be called.
IRIE Shinsuke
13/01/28, IRIE Shinsuke wrote:
Strange...
Of course I did make install and confirmed that ui.py has been
updated. (The issue (2) indeed has been fixed.)
And I got no error in console.
IRIE Shinsuke
13/01/27, Bastien Montagne wrote:
That’s rather odd… For me it works OK, see http://www.pasteall.org/pic/44360
…
I suppose you did make install ? ;)
Also, could you have a look to your blender's console, there shoud be some
error message here! :)
On 27/01/2013 15:34, IRIE Shinsuke wrote:
Thanks, but unfortunately the issue (1) still isn't fixed...
Could you look into it again?
IRIE Shinsuke
13/01/27, Bastien Montagne wrote:
Hi Irie, and thanks for the report! Should be fixed in r54119. :)
Best regards,
Bastien
On 27/01/2013 13:35, IRIE Shinsuke wrote:
Tamito, in Freestyle build, render layer panel is not correctly shown
when using Cycles:
(1) Render layer list doesn't appear, so we cannot create a scene that
uses multiple render layers.
(2) Label Layer is used twice for panel headers. That's confusing.
r54113
Ubuntu 12.10
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Freestyle branch: Cycles render layer UI broken
If I start Blender with --factory-startup option, the problem doesn't
happen. My startup file seems to have panel closed flag for the
render layers panel.
Probably you can reproduce the problem as follows:
1. Remove bl_options = {'HIDE_HEADER'} and do make install
2. Start blender with --factory-startup option
3. Change renderer to Cycles, and close the render layers panel
4. Save a .blend file
5. Revert the step 1
6. Start blender and load the .blend file above
Then, the panel shouldn't appear.
I think the panel closed flag should be ignored if the HIDE_HEADER
option is given.
IRIE Shinsuke
13/01/28, Bastien Montagne wrote:
That's really weird… Do you have the other controls in this panel (buttons to
the side of the list, text field below it), or do you have a completely empty
panel?
Hiding header should not affect at all panel's content…
And the same panel with internal works OK? (because they have exactly the
same code!) o_O
If draw() is really not called, then I think we have some kind of bug
unrelated to freestyle… but can't do much if I can't reproduce it :(
On 27/01/2013 17:26, IRIE Shinsuke wrote:
Ah, the render layer list appears if I removed
bl_options = {'HIDE_HEADER'} in CyclesRender_PT_layers.
Otherwise, draw() in CyclesRender_PT_layers seems not to be called.
IRIE Shinsuke
13/01/28, IRIE Shinsuke wrote:
Strange...
Of course I did make install and confirmed that ui.py has been
updated. (The issue (2) indeed has been fixed.)
And I got no error in console.
IRIE Shinsuke
13/01/27, Bastien Montagne wrote:
That’s rather odd… For me it works OK, see
http://www.pasteall.org/pic/44360 …
I suppose you did make install ? ;)
Also, could you have a look to your blender's console, there shoud be some
error message here! :)
On 27/01/2013 15:34, IRIE Shinsuke wrote:
Thanks, but unfortunately the issue (1) still isn't fixed...
Could you look into it again?
IRIE Shinsuke
13/01/27, Bastien Montagne wrote:
Hi Irie, and thanks for the report! Should be fixed in r54119. :)
Best regards,
Bastien
On 27/01/2013 13:35, IRIE Shinsuke wrote:
Tamito, in Freestyle build, render layer panel is not correctly shown
when using Cycles:
(1) Render layer list doesn't appear, so we cannot create a scene that
uses multiple render layers.
(2) Label Layer is used twice for panel headers. That's confusing.
r54113
Ubuntu 12.10
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Isn't Rigify addon maintained anymore?
Thanks, Nathan and Campbell. I think the bad point of Py Script tracker is that all addons are always Open regardless of the actual state. That should prevent the maintainers from being aware of bug reports. IRIE Shinsuke 13/01/23, Nathan Vegdahl wrote: Just took a look at the patches, and both look good. I've applied them and committed. Thanks Irie! And sorry for the delay. --Nathan On Tue, Jan 22, 2013 at 10:25 AM, Nathan Vegdahl ces...@cessen.com wrote: Hi Irie, I'll take a look. Thanks for the heads up! I don't always notice the bug tracker updates for Rigify, since all reports for Rigify go into the same massive ticket (grrr... can we please fix this? It's super annoying.). At a quick glance, however, I'm not getting those errors in recent SVN, and Rigify seems to be working fine for me. I'll take a look at your patch, though--might make Rigify more robust against different system setups. --Nathan On Mon, Jan 21, 2013 at 9:10 AM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: Rigify in Py Script tracker: http://projects.blender.org/tracker/index.php?func=detailaid=25546 IRIE Shinsuke 13/01/22, Campbell Barton wrote: Hi, I wasn't aware of this, could you link to patches and bug reports? Nathan Vegdahl took over rigify from me but if he isn't available I can check on this. On Tue, Jan 22, 2013 at 3:29 AM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: Hi, Rigify addon has been broken for a very long time, and three weeks ago I reported bugs and sent patches, but still no response. Why does no one fix the bugs? I think such a broken addon should be removed from svn repository if it's no longer maintained. -- IRIE Shinsuke ___ 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] Isn't Rigify addon maintained anymore?
Hi, Rigify addon has been broken for a very long time, and three weeks ago I reported bugs and sent patches, but still no response. Why does no one fix the bugs? I think such a broken addon should be removed from svn repository if it's no longer maintained. -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Isn't Rigify addon maintained anymore?
Rigify in Py Script tracker: http://projects.blender.org/tracker/index.php?func=detailaid=25546 IRIE Shinsuke 13/01/22, Campbell Barton wrote: Hi, I wasn't aware of this, could you link to patches and bug reports? Nathan Vegdahl took over rigify from me but if he isn't available I can check on this. On Tue, Jan 22, 2013 at 3:29 AM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: Hi, Rigify addon has been broken for a very long time, and three weeks ago I reported bugs and sent patches, but still no response. Why does no one fix the bugs? I think such a broken addon should be removed from svn repository if it's no longer maintained. -- IRIE Shinsuke ___ 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] Freestyle branch breaks color theme
Hi, In Freestyle build, some UI are shown with incorrect colors. See screenshot: http://www.pasteall.org/pic/42776 For example, manipulator is red arrow + two black arrows, and selected outliner items are black (unreadable!). I confirmed the following patch fixes this issue. = = = = = = = = = = = = = = = S T A R T = = = = = = = = = = = = = = = Index: source/blender/editors/include/UI_resources.h === --- source/blender/editors/include/UI_resources.h (revision 53485) +++ source/blender/editors/include/UI_resources.h (working copy) @@ -200,11 +200,6 @@ TH_STITCH_PREVIEW_UNSTITCHABLE, TH_STITCH_PREVIEW_ACTIVE, -#ifdef WITH_FREESTYLE - TH_FREESTYLE_EDGE_MARK, - TH_FREESTYLE_FACE_MARK, -#endif - TH_MATCH, /* highlight color for search matches */ TH_SELECT_HIGHLIGHT, /* highlight color for selected outliner item */ @@ -225,7 +220,12 @@ TH_AXIS_X, /* X/Y/Z Axis */ TH_AXIS_Y, - TH_AXIS_Z + TH_AXIS_Z, + +#ifdef WITH_FREESTYLE + TH_FREESTYLE_EDGE_MARK, + TH_FREESTYLE_FACE_MARK, +#endif }; /* XXX WARNING: previous is saved in file, so do not change order! */ = = = = = = = = = = = = = = = E N D = = = = = = = = = = = = = = = r53384 Ubuntu 12.10 amd64 -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.65a release AHOY!
Please also bump BLENDER_VERSION_CHAR in trunk to a, not only in blender-2.65a-release. IRIE Shinsuke 12/12/19, Sergey Sharybin wrote: Hi, We've failed to avoid 'a' release.. Again. Anyway, information for platform maintainers: tag: blender-2.65a-release tag revision: 53177 addons revision: 4072 locale revision: 1300 Keep usual naming and let me know when the builds are ready. Thanks! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] DNA_scene_types.h in Freestyle branch
Tamito, please check lines 1204-1205 in source/blender/makesdna/DNA_scene_types.h: #define R_PERSISTENT_DATA 0x200 /* keep data around for re-render */ #define R_EDGE_FRS 0x200 /* R_EDGE for Freestyle */ The flags R_PERSISTENT_DATA and R_EDGE_FRS use the same bit 0x200. R_PERSISTENT_DATA was added in r52054. -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] There is no way to use LLVM as shared library in CMake build
Currently, Blender can use only static libLLVM, while shared OSL
library always uses shared libLLVM if it exists. So, if using shared
OSL library, Blender has to link libLLVM twice as both static one and
shared one.
I think such strange linking should be avoided.
IRIE Shinsuke
12/11/09, IRIE Shinsuke wrote:
Thanks, Brecht.
However, the additional changes for dynamic linking are not working
because libLLVMAnalysis.so does not exist. Most of all LLVM libraries
are contained in libLLVM-3.x.so, so LLVM_LIBRARY must be set such as
LLVM-3.1, instead.
Now I'm testing the following patch on Uubntu 12.10:
Index: CMakeLists.txt
===
--- CMakeLists.txt(revision 52037)
+++ CMakeLists.txt(working copy)
@@ -718,7 +718,7 @@
if(WITH_LLVM)
set(LLVM_DIRECTORY ${LIBDIR}/llvm CACHE PATHPath to the LLVM
installation)
set(LLVM_VERSION 3.0 CACHE STRINGVersion of LLVM to use)
-set(LLVM_STATIC YES)
+set(LLVM_STATIC YES CACHE BOOLLink LLVM libraries statically)
if(EXISTS ${LLVM_DIRECTORY}/bin/llvm-config)
set(LLVM_CONFIG ${LLVM_DIRECTORY}/bin/llvm-config)
else()
@@ -733,9 +733,15 @@
execute_process(COMMAND ${LLVM_CONFIG} --libdir
OUTPUT_VARIABLE LLVM_LIB_DIR
OUTPUT_STRIP_TRAILING_WHITESPACE)
-find_library(LLVM_LIBRARY
- NAMES LLVMAnalysis # first of a whole bunch of libs to
get
- PATHS ${LLVM_LIB_DIR})
+if(LLVM_STATIC)
+find_library(LLVM_LIBRARY
+ NAMES LLVMAnalysis # first of a whole bunch of libs
to get
+ PATHS ${LLVM_LIB_DIR})
+else()
+find_library(LLVM_LIBRARY
+ NAMES LLVM-${LLVM_VERSION}
+ PATHS ${LLVM_LIB_DIR})
+endif()
message(STATUS LLVM version = ${LLVM_VERSION})
message(STATUS LLVM dir = ${LLVM_DIRECTORY})
message(STATUS LLVM lib dir = ${LLVM_LIB_DIR})
So far it works fine for me. I'm not sure if this patch works on the
other distros.
--
IRIE Shinsuke
12/11/09, Brecht Van Lommel wrote:
Hi,
I've committed the llvm-config patch now. Also changed it so it
doesn't only look for static libLLVMAnalysis.a, but also dynamic libs.
That might not be enough to make it work though.
Brecht.
On Thu, Nov 8, 2012 at 12:45 PM, IRIE Shinsuke irieshins...@yahoo.co.jp
wrote:
Please fix this bug! It's annoying that I have to set
LLVM_DIRECTORY=/usr every time I use cmake...
It should be easy to fix.
--
IRIE Shinsuke
12/11/05, IRIE Shinsuke wrote:
Hi,
I'm using system-wide LLVM installed in /usr on Ubuntu 12.10, but
CMakeLists.txt cannot find it so I have to specify the directory
explicitly by a command line option -DLLVM_DIRECTORY=/usr.
The following patch should fix this bug:
Index: blender/CMakeLists.txt
===
--- blender/CMakeLists.txt (revision 51867)
+++ blender/CMakeLists.txt (working copy)
@@ -715,7 +715,7 @@
set(LLVM_DIRECTORY ${LIBDIR}/llvm CACHE PATHPath to
the LLVM installation)
set(LLVM_VERSION 3.0 CACHE STRING Version of LLVM
to use)
set(LLVM_STATIC YES)
- if(LLVM_DIRECTORY)
+ if(EXISTS ${LLVM_DIRECTORY}/bin/llvm-config)
set(LLVM_CONFIG
${LLVM_DIRECTORY}/bin/llvm-config)
else()
set(LLVM_CONFIG llvm-config)
___
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] CMake cannot find system-wide LLVM installation
Thanks, Brecht.
However, the additional changes for dynamic linking are not working
because libLLVMAnalysis.so does not exist. Most of all LLVM libraries
are contained in libLLVM-3.x.so, so LLVM_LIBRARY must be set such as
LLVM-3.1, instead.
Now I'm testing the following patch on Uubntu 12.10:
Index: CMakeLists.txt
===
--- CMakeLists.txt (revision 52037)
+++ CMakeLists.txt (working copy)
@@ -718,7 +718,7 @@
if(WITH_LLVM)
set(LLVM_DIRECTORY ${LIBDIR}/llvm CACHE PATHPath to the
LLVM installation)
set(LLVM_VERSION 3.0 CACHE STRING Version of LLVM to
use)
- set(LLVM_STATIC YES)
+ set(LLVM_STATIC YES CACHE BOOL Link LLVM libraries
statically)
if(EXISTS ${LLVM_DIRECTORY}/bin/llvm-config)
set(LLVM_CONFIG ${LLVM_DIRECTORY}/bin/llvm-config)
else()
@@ -733,9 +733,15 @@
execute_process(COMMAND ${LLVM_CONFIG} --libdir
OUTPUT_VARIABLE LLVM_LIB_DIR
OUTPUT_STRIP_TRAILING_WHITESPACE)
- find_library(LLVM_LIBRARY
-NAMES LLVMAnalysis # first of a whole bunch of
libs to get
-PATHS ${LLVM_LIB_DIR})
+ if(LLVM_STATIC)
+ find_library(LLVM_LIBRARY
+NAMES LLVMAnalysis # first of a whole
bunch of libs to get
+PATHS ${LLVM_LIB_DIR})
+ else()
+ find_library(LLVM_LIBRARY
+NAMES LLVM-${LLVM_VERSION}
+PATHS ${LLVM_LIB_DIR})
+ endif()
message(STATUS LLVM version = ${LLVM_VERSION})
message(STATUS LLVM dir = ${LLVM_DIRECTORY})
message(STATUS LLVM lib dir = ${LLVM_LIB_DIR})
So far it works fine for me. I'm not sure if this patch works on the
other distros.
--
IRIE Shinsuke
12/11/09, Brecht Van Lommel wrote:
Hi,
I've committed the llvm-config patch now. Also changed it so it
doesn't only look for static libLLVMAnalysis.a, but also dynamic libs.
That might not be enough to make it work though.
Brecht.
On Thu, Nov 8, 2012 at 12:45 PM, IRIE Shinsuke irieshins...@yahoo.co.jp
wrote:
Please fix this bug! It's annoying that I have to set
LLVM_DIRECTORY=/usr every time I use cmake...
It should be easy to fix.
--
IRIE Shinsuke
12/11/05, IRIE Shinsuke wrote:
Hi,
I'm using system-wide LLVM installed in /usr on Ubuntu 12.10, but
CMakeLists.txt cannot find it so I have to specify the directory
explicitly by a command line option -DLLVM_DIRECTORY=/usr.
The following patch should fix this bug:
Index: blender/CMakeLists.txt
===
--- blender/CMakeLists.txt (revision 51867)
+++ blender/CMakeLists.txt (working copy)
@@ -715,7 +715,7 @@
set(LLVM_DIRECTORY ${LIBDIR}/llvm CACHE PATHPath to
the LLVM installation)
set(LLVM_VERSION 3.0 CACHE STRING Version of LLVM
to use)
set(LLVM_STATIC YES)
- if(LLVM_DIRECTORY)
+ if(EXISTS ${LLVM_DIRECTORY}/bin/llvm-config)
set(LLVM_CONFIG
${LLVM_DIRECTORY}/bin/llvm-config)
else()
set(LLVM_CONFIG llvm-config)
___
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] CMake cannot find system-wide LLVM installation
Please fix this bug! It's annoying that I have to set
LLVM_DIRECTORY=/usr every time I use cmake...
It should be easy to fix.
--
IRIE Shinsuke
12/11/05, IRIE Shinsuke wrote:
Hi,
I'm using system-wide LLVM installed in /usr on Ubuntu 12.10, but
CMakeLists.txt cannot find it so I have to specify the directory
explicitly by a command line option -DLLVM_DIRECTORY=/usr.
The following patch should fix this bug:
Index: blender/CMakeLists.txt
===
--- blender/CMakeLists.txt (revision 51867)
+++ blender/CMakeLists.txt (working copy)
@@ -715,7 +715,7 @@
set(LLVM_DIRECTORY ${LIBDIR}/llvm CACHE PATHPath to the
LLVM installation)
set(LLVM_VERSION 3.0 CACHE STRING Version of LLVM to
use)
set(LLVM_STATIC YES)
- if(LLVM_DIRECTORY)
+ if(EXISTS ${LLVM_DIRECTORY}/bin/llvm-config)
set(LLVM_CONFIG ${LLVM_DIRECTORY}/bin/llvm-config)
else()
set(LLVM_CONFIG llvm-config)
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Python 3.3 problems on Ubuntu/Debian
Dmitrijs Ledkovs, a package maintainer for 'blender' in Ubuntu, proposed a solution for the build failure of Debian/Ubuntu package: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692376 https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/blender/raring/revision/38 The solution uses pkg-config to find the include directories. I'm not sure if this way can be used for all X11 systems, but it might be helpful for fixing the problem. -- IRIE Shinsuke 12/11/06, IRIE Shinsuke wrote: Hi, I was trying to build Blender with python3.3-dev package on Ubuntu 12.10, but the builds failed as follows: [ 33%] Building C object source/blender/python/intern/CMakeFiles/bf_python.dir/gpu.c.o In file included from /home/irie/Subversion/Blender/blender/source/blender/python/generic/bgl.c:38:0: /usr/include/python3.3m/Python.h:8:22: fatal error: pyconfig.h: No such file or directory compilation terminated. On Ubuntu/Debian, Python.h and pyconfig.h are placed in: /usr/include/python3.3m/Python.h /usr/include/x86_64-linux-gnu/python3.3m/pyconfig.h So the error occurs if assuming all headers are in the same directory. I reported this problem in Debian bug tracker. Then, Debian's package maintainer considers this is Blender's bug, and he said Please use python3.3-config --include. python3.3-config --include returns: -I/usr/include/python3.3m -I/usr/include/x86_64-linux-gnu/python3.3m and indeed the build succeeded after setting CMAKE_C_FLAGS them. I attempted to set these paths to PYTHON_INCLUDE_DIR, but multiple paths cannot be set to it... I think FindPythonLibsUnix.cmake needs drastic changes. Also, there is another problem that numpy cannot be found when using Python3.3 on Ubuntu/Debian. I get the following message: CMake Warning at CMakeLists.txt:1965 (message): 'numpy' path could not be found in: '/usr/lib/x86_64-linux-gnu/python3.3/site-packages/numpy', '/usr/lib/x86_64-linux-gnu/python3/site-packages/numpy', '/usr/lib/x86_64-linux-gnu/python3.3/dist-packages/numpy', '/usr/lib/x86_64-linux-gnu/python3/dist-packages/numpy', WITH_PYTHON_INSTALL_NUMPY option will be ignored when installing python CMakeList.txt searches the above multi-arch paths for numpy, but numpy is actually in /usr/lib/python3/dist-packages/numpy. Thanks, ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Python 3.3 problems on Ubuntu/Debian
Oops, strangely I cannot find Bastien's reply in my mailbox... Will check r51976 soon! 12/11/07, IRIE Shinsuke wrote: Dmitrijs Ledkovs, a package maintainer for 'blender' in Ubuntu, proposed a solution for the build failure of Debian/Ubuntu package: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692376 https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/blender/raring/revision/38 The solution uses pkg-config to find the include directories. I'm not sure if this way can be used for all X11 systems, but it might be helpful for fixing the problem. -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Python 3.3 problems on Ubuntu/Debian
Bastien, your fix actually works for me too, but is still incomplete. You should've added include/i386-linux-gnu/python... to PATH_SUFFIXES for 32bit systems. See search results for pyconfig.h file in Ubuntu package archives: http://packages.ubuntu.com/search?mode=exactfilenamesuite=quantalsection=allarch=anysearchon=contentskeywords=pyconfig.h -- IRIE Shinsuke 12/11/07, IRIE Shinsuke wrote: Oops, strangely I cannot find Bastien's reply in my mailbox... Will check r51976 soon! 12/11/07, IRIE Shinsuke wrote: Dmitrijs Ledkovs, a package maintainer for 'blender' in Ubuntu, proposed a solution for the build failure of Debian/Ubuntu package: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692376 https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/blender/raring/revision/38 The solution uses pkg-config to find the include directories. I'm not sure if this way can be used for all X11 systems, but it might be helpful for fixing the problem. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Python 3.3 problems on Ubuntu/Debian
Thanks for the fix! -- IRIE Shinsuke 12/11/08, Bastien Montagne wrote: Yes indeed… replaced this hard-coded stuff with CMAKE_LIBRARY_ARCHITECTURE, should work for any arch now. :) On 07/11/2012 16:43, IRIE Shinsuke wrote: Bastien, your fix actually works for me too, but is still incomplete. You should've added include/i386-linux-gnu/python... to PATH_SUFFIXES for 32bit systems. See search results for pyconfig.h file in Ubuntu package archives: http://packages.ubuntu.com/search?mode=exactfilenamesuite=quantalsection=allarch=anysearchon=contentskeywords=pyconfig.h ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Which OSL branch should be used for building Blender?
Thanks for the explanation. I will use RB-1.2, too. -- IRIE Shinsuke 12/11/04, Thomas Dinges wrote: Hi IRIE, it should really not matter, we will probably use our own RB-1.2. It depends on how fast our pull request will get accepted (we still have to do that one). Then we can use origin/master too. Thanks for the tip with find_library, will check with Lukas and Jens. Regards, Thomas Am 04.11.2012 05:52, schrieb IRIE Shinsuke: Hi Thomas, 12/11/04, Thomas Dinges wrote: Hi, both branches are fine, and contain the same. It seems that RB-1.2 is based on origin/RB-1.2, while blender-fixes is based on origin/master... I knew both of them can work, but I'm not sure which is better. Which branch will be used for lib/? BTW, I think find_library(OSL... ) in CMakeLists.txt should be removed because it finds unusable system-wide OSL under /usr rather than CYCLES_OSL and causes build failure. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Is Freestyle branch update correct?
Forgot to mention that this code needs style cleanup:
cont = 0 - cont = FALSE
--
IRIE Shinsuke
12/11/04, IRIE Shinsuke wrote:
Hi,
I was checking Freestyle branch r51854 and noticed a part of the
modifications has been lost when some codes in bmo_utils.c were moved
to bmo_similar.c in r51755.
Before r51854, the difference between trunk and Freestyle branch is:
diff -urN trunk/source/blender/bmesh/operators/bmo_utils.c
freestyle/source/blender/bmesh/operators/bmo_utils.c
--- trunk/source/blender/bmesh/operators/bmo_utils.c 2012-10-22
00:20:53.419037000 +0900
+++ freestyle/source/blender/bmesh/operators/bmo_utils.c 2012-10-29
10:09:12.317632000 +0900
@@ -668,6 +668,13 @@
cont = FALSE;
}
break;
+
+ case SIMFACE_FREESTYLE:
+ if (BM_elem_flag_test(fm,
BM_ELEM_FREESTYLE) == BM_elem_flag_test(fs, BM_ELEM_FREESTYLE)) {
+
BMO_elem_flag_enable(bm, fm, FACE_MARK);
+ cont = 0;
+ }
+ break;
}
}
}
@@ -873,6 +880,13 @@
cont = FALSE;
}
break;
+
+ case SIMEDGE_FREESTYLE:
+ if (BM_elem_flag_test(e,
BM_ELEM_FREESTYLE) == BM_elem_flag_test(es, BM_ELEM_FREESTYLE)) {
+
BMO_elem_flag_enable(bm, e, EDGE_MARK);
+ cont = 0;
+ }
+ break;
}
}
}
After r51854, the difference is:
diff -urN trunk/source/blender/bmesh/operators/bmo_similar.c
freestyle/source/blender/bmesh/operators/bmo_similar.c
--- trunk/source/blender/bmesh/operators/bmo_similar.c2012-11-01
18:54:00.725269000 +0900
+++ freestyle/source/blender/bmesh/operators/bmo_similar.c2012-11-04
11:22:56.114902000 +0900
@@ -463,6 +463,12 @@
cont = FALSE;
}
break;
+ case SIMEDGE_FREESTYLE:
+ if (BM_elem_flag_test(e,
BM_ELEM_FREESTYLE) == BM_elem_flag_test(es, BM_ELEM_FREESTYLE)) {
+
BMO_elem_flag_enable(bm, e, EDGE_MARK);
+ cont = 0;
+ }
+ break;
default:
BLI_assert(0);
}
Tamito, did you remove case SIMFACE_FREESTYLE: ... accidentally?
Or, is it no longer necessary?
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] CMake cannot find system-wide LLVM installation
Hi,
I'm using system-wide LLVM installed in /usr on Ubuntu 12.10, but
CMakeLists.txt cannot find it so I have to specify the directory
explicitly by a command line option -DLLVM_DIRECTORY=/usr.
The following patch should fix this bug:
Index: blender/CMakeLists.txt
===
--- blender/CMakeLists.txt (revision 51867)
+++ blender/CMakeLists.txt (working copy)
@@ -715,7 +715,7 @@
set(LLVM_DIRECTORY ${LIBDIR}/llvm CACHE PATHPath to the
LLVM installation)
set(LLVM_VERSION 3.0 CACHE STRING Version of LLVM to
use)
set(LLVM_STATIC YES)
- if(LLVM_DIRECTORY)
+ if(EXISTS ${LLVM_DIRECTORY}/bin/llvm-config)
set(LLVM_CONFIG ${LLVM_DIRECTORY}/bin/llvm-config)
else()
set(LLVM_CONFIG llvm-config)
--
IRIE Shinsuke
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Which OSL branch should be used for building Blender?
Hi developers, I'm testing OSL Script node on Ubuntu. Recently I uploaded OSL's deb package to PPA: https://launchpad.net/~irie/+archive/openshadinglanguage and could use it for building Blender. However, after the OSL node merge, it doesn't work anymore because Blender requires modified version of OSL which includes incompatible API changes. So, I'm using Thomas' repository in github now, but I'm not sure which branch I should use. RB-1.2? or blender-fixes? Anyway, annoying thing is that find_library() in CMakeLists.txt will ignore the OSL's install path specified by CYCLES_OSL if there is a system-wide installation of OSL, so I have to apt-get remove the deb packages before building Blender to avoid build failure. I hope that OSL's source tree will be merged into Blender's tree (under extern/ directory), like bullet physics. Thanks, -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Which OSL branch should be used for building Blender?
Hi Thomas, 12/11/04, Thomas Dinges wrote: Hi, both branches are fine, and contain the same. It seems that RB-1.2 is based on origin/RB-1.2, while blender-fixes is based on origin/master... I knew both of them can work, but I'm not sure which is better. Which branch will be used for lib/? BTW, I think find_library(OSL... ) in CMakeLists.txt should be removed because it finds unusable system-wide OSL under /usr rather than CYCLES_OSL and causes build failure. -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Segmentation fault when rendering in viewport
I've already reported this crash in the bug tracker:
http://projects.blender.org/tracker/index.php?func=detailaid=33048group_id=9atid=498
Ton, could you remove texture from the summary of this report?
--
IRIE Shinsuke
12/11/02, Ton Roosendaal wrote:
Hi,
This is not really the place for bug reports you know...
Also if you would have put in the tracker, it's best to follow the guidelines
written down there:
http://projects.blender.org/tracker/?func=addgroup_id=9atid=498
I would have commented:
- Always be exact: viewport render can mean more things, I thought you
meant OpenGL viewport render.
Say something like: Press F12 for render image with mouse in 3d editor.
- Just always test 2.64a release and mention result.
- And check with an official build from builder.blender.org
- Mention what OS you use even?
I tried OpenGL render here (OSX 64 bits) and it goes fine. On F12 render it
crashes:
0x000101441a34 in rna_Main_meshes_remove (bmain=0x10a1d7838, reports=0x0,
mesh_ptr=0x10993ea38) at rna_main_api.c:262
262 if (ID_REAL_USERS(mesh) = 0) {
(gdb) p mesh
$1 = (Mesh *) 0x0
It's a Cycles bug. Now let's just move this to the tracker?
-Ton-
Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org
Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands
On 2 Nov, 2012, at 2:38, James Wrigley wrote:
Hi everyone,
On this particular blend file I'm working on, when I render in the
viewport Blender will crash with a segmentation fault. This only
happens with a particular file so I've linked it here:
https://docs.google.com/open?id=0B60uSqRHFFciMTVNY2d4VVRwRmc. It's
56MB.
This happens on r51814, to reproduce just open the blend and change to
viewport render in the bottom window.
Thanks, JamesNZ
___
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] byte-compile error in addons/render_povray/render.py
Hi, Since r3803, addons/render_povray/render.py has utf8 BOM and includes non-utf8 characters in line 754, 793, 819, and 972, so byte-compiling fails as follows: Compiling './addons/render_povray/render.py'... *** UnicodeDecodeError: 'utf-8' codec can't decode byte 0x93 in position 32779: invalid start byte Thanks, -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] UI Translation in Blender UI + XIM support patch
Hi, I'm testing the UI translation addon. The addon seems to work for me, but I think it's not so useful unless UTF-8 characters can be input directly in the translation window. Can XIM support patch I posted 5 months ago be merged into trunk? http://projects.blender.org/tracker/?func=detailatid=127aid=30274group_id=9 It allows us to input UTF-8 characters in Blender on X11 systems, so it should speed up our translation works. -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Syntax error in export_3ds.py
Hi CoDEmanX, r3595 causes another error: Traceback (most recent call last): File /usr/lib/python3.2/runpy.py, line 160, in _run_module_as_main __main__, fname, loader, pkg_name) File /usr/lib/python3.2/runpy.py, line 73, in _run_code exec(code, run_globals) File /usr/lib/python3.2/py_compile.py, line 187, in module sys.exit(main()) File /usr/lib/python3.2/py_compile.py, line 169, in main compile(filename, doraise=True) File /usr/lib/python3.2/py_compile.py, line 116, in compile codestring = f.read() File /usr/lib/python3.2/codecs.py, line 300, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe4 in position 905: invalid continuation byte export_3ds.py was accidentally saved with non UTF-8 character encoding. 12/07/08, CoDEmanX wrote: Commited fix: http://projects.blender.org/scm/viewvc.php?view=revroot=bf-extensionsrevision=3595 Should now work as expected. Thanks for reporting! Am 08.07.2012 06:08, schrieb IRIE Shinsuke: Hi, When I was byte-compiling release/scripts/addons/ (r3577), I got a syntax error in io_scene_3ds/export_3ds.py as follows: File /usr/share/blender/2.63/scripts/addons/io_scene_3ds/export_3ds.py, line 227 class _3ds_point_4d(object): Class representing a four-dimensional point for a 3ds file, for instance a quaternion. ^ SyntaxError: invalid syntax The triple-quotes ... are enclosed by the same style of triple-quotes: class _3ds_point_4d(object): Class representing a four-dimensional point for a 3ds file, for instance a quaternion. __slots__ = ... so the inside of the inner ones is not a string literal. Please use the different style of triple-quotes like below: ''' class _3ds_point_4d(object): Class representing a four-dimensional point for a 3ds file, for instance a quaternion. __slots__ = ... ''' Anyway, I think triple-quotes shouldn't be used to comment out multiple lines. -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Why did change the existing behavior of compositor?
Hi developers, As I have reported 5 days ago, new compositor behaves in the different way from old compositor when converting a color into a scalar value: http://projects.blender.org/tracker/index.php?func=detailaid=31531group_id=9atid=498 That is, in the old compositor, output value = (R + G + B) / 3 or output value = R * 0.35 + G * 0.45 + B * 0.2 while in the new compositor, output value = (R + G + B) / 3 * A or output value = (R * 0.35 + G * 0.45 + B * 0.2) * A This change is very annoying that requires me to modify many existing .blend files. So, I posted a patch that rolls back the behavior: http://projects.blender.org/tracker/index.php?func=detailaid=31534group_id=9atid=127 but still got no response. Please let me know if this change accidentally happened or is intended and if I really have to modify my .blend files. Regards, -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
