Re: [Bf-committers] Collecting fixes for 2.66a release.
Updated from reading over replies and recent fixes since I last mailed. There are 2 maybe's from Sergey outstanding, one from alexk. == Revs Checked == Trunk: 54697 -- 55009 Ext: 4315 -- 4337 == Trunk == dfelinto: 54733 54912 54745 dingto: 54754 54996 54948 moguri: 54738 54764 54766 54769 54767 54772 54777 54780 54828 54837 54972 nazgul: 54746 54748 54901 54934 54935 54946 54947 54960 blendix: 54760 54793 54868 54885 54942 54943 54944 54945 54959 54965 54993 campbellbarton: 54776 54781 54783 54824 54833 54834 54835 54865 54866 54875 54877 54878 54879 54882 54883 54899 54900 54903 54907 54917 54920 54921 54923 54928 54929 54969 54971 55004 55007 psy-fi: 54788 ton: 54789 54790 54794 54816 54908 54910 54954 54961 nicholasbishop: 54827 gaiaclary: 54856 sergof: 54757 54799 54822 54855 54862 54818, 54990 54991 alexk: 54759 mont29: 54891 == Trunk (MAYBE) == alexk: 54761 nazgul: 54904 54937 === Ext == campbellbarton: 4320 4325 4327 cessen: 4321 4334 4335 ___ 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 [54759] trunk/blender/intern/ghost/intern/ GHOST_WindowWin32.cpp: Fix for windows size on win32
On Sat, Feb 23, 2013 at 2:57 AM, Alexander Kuznetsov kuzsa...@gmail.com wrote:
Revision: 54759
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=54759
Author: alexk
Date: 2013-02-22 15:57:50 + (Fri, 22 Feb 2013)
Log Message:
---
Fix for windows size on win32
Modified Paths:
--
trunk/blender/intern/ghost/intern/GHOST_WindowWin32.cpp
Modified: trunk/blender/intern/ghost/intern/GHOST_WindowWin32.cpp
===
--- trunk/blender/intern/ghost/intern/GHOST_WindowWin32.cpp 2013-02-22
15:54:10 UTC (rev 54758)
+++ trunk/blender/intern/ghost/intern/GHOST_WindowWin32.cpp 2013-02-22
15:57:50 UTC (rev 54759)
@@ -470,38 +470,22 @@
void GHOST_WindowWin32::getClientBounds(GHOST_Rect bounds) const
{
RECT rect;
- GHOST_TWindowState state = this-getState();
- LONG_PTR result = ::GetWindowLongPtr(m_hWnd, GWL_STYLE);
- int sm_cysizeframe = GetSystemMetrics(SM_CYSIZEFRAME);
- ::GetWindowRect(m_hWnd, rect);
+ POINT coord;
+ ::GetClientRect(m_hWnd, rect);
- if ((result (WS_POPUP | WS_MAXIMIZE)) != (WS_POPUP | WS_MAXIMIZE)) {
- if (state == GHOST_kWindowStateMaximized) {
- // in maximized state we don't have borders on the
window
- bounds.m_b = rect.bottom -
GetSystemMetrics(SM_CYCAPTION) - sm_cysizeframe * 2;
- bounds.m_l = rect.left + sm_cysizeframe;
- bounds.m_r = rect.right - sm_cysizeframe;
- bounds.m_t = rect.top;
- }
- else if (state == GHOST_kWindowStateEmbedded) {
- bounds.m_b = rect.bottom;
- bounds.m_l = rect.left;
- bounds.m_r = rect.right;
- bounds.m_t = rect.top;
- }
- else {
- bounds.m_b = rect.bottom -
GetSystemMetrics(SM_CYCAPTION) - sm_cysizeframe * 2;
- bounds.m_l = rect.left;
- bounds.m_r = rect.right - sm_cysizeframe * 2;
- bounds.m_t = rect.top;
- }
- }
- else {
- bounds.m_b = rect.bottom;
- bounds.m_l = rect.left;
- bounds.m_r = rect.right;
- bounds.m_t = rect.top;
- }
+ coord.x = rect.left;
+ coord.y = rect.top;
+ ::ClientToScreen(m_hWnd, coord);
+
+ bounds.m_l = coord.x;
+ bounds.m_t = coord.y;
+
+ coord.x = rect.right;
+ coord.y = rect.bottom;
+ ::ClientToScreen(m_hWnd, coord);
+
+ bounds.m_r = coord.x;
+ bounds.m_b = coord.y;
}
Checking commits for 2.66a and not sure about this one.
What does this fix?
Surely if resizing a window on ms-win was broken we would have had
many complaints.
--
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collecting fixes for 2.66a release.
Hi, First of all i thought we're backporting only fixes for regressions and pipeline stoppers, and ignoring fixes for bugs existing in previous release (increases probablility of nothing is broken again). Then, i would ignore 54947, 54759. Also not sure about all that multi-uv fixes in GE, doesn't seem so much small fix. 54891 shall go together with 54893 Also not sure about revisions: 54777 - no idea if it had any impact on artists, or it's just cleaning internal logic. 54903 - what does it fix from user perspective? 54766, 54959 - would like area maintainers to double-check on this revisions. 54761 - couldn't actually follow changes On Mon, Mar 4, 2013 at 2:04 PM, Campbell Barton ideasma...@gmail.comwrote: Updated from reading over replies and recent fixes since I last mailed. There are 2 maybe's from Sergey outstanding, one from alexk. == Revs Checked == Trunk: 54697 -- 55009 Ext: 4315 -- 4337 == Trunk == dfelinto: 54733 54912 54745 dingto: 54754 54996 54948 moguri: 54738 54764 54766 54769 54767 54772 54777 54780 54828 54837 54972 nazgul: 54746 54748 54901 54934 54935 54946 54947 54960 blendix: 54760 54793 54868 54885 54942 54943 54944 54945 54959 54965 54993 campbellbarton: 54776 54781 54783 54824 54833 54834 54835 54865 54866 54875 54877 54878 54879 54882 54883 54899 54900 54903 54907 54917 54920 54921 54923 54928 54929 54969 54971 55004 55007 psy-fi: 54788 ton: 54789 54790 54794 54816 54908 54910 54954 54961 nicholasbishop: 54827 gaiaclary: 54856 sergof: 54757 54799 54822 54855 54862 54818, 54990 54991 alexk: 54759 mont29: 54891 == Trunk (MAYBE) == alexk: 54761 nazgul: 54904 54937 === Ext == campbellbarton: 4320 4325 4327 cessen: 4321 4334 4335 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collecting fixes for 2.66a release.
54903 - what does it fix from user perspective? Thought my commit log explained this well enough. If you instance group objects from a scene they now use their original layers, rather then setting all layers - requested by the guys making `Naughty 5` (very safe change) Also select newly drag'n'dropped objects rather then just making active. (active+unselected is OK but a bit confusing to create this context by default). ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] proposal for better integration of addon functionality
Message: 11 Date: Sun, 3 Mar 2013 13:02:03 +1100 From: Campbell Barton ideasma...@gmail.com Subject: Re: [Bf-committers] proposal for better integration of addon functionality To: bf-blender developers bf-committers@blender.org Message-ID: caecf3nxhczkpzacc8j1+qpjgqgsuous4wyj5yxhnpkckka_...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 On Sun, Mar 3, 2013 at 4:16 AM, Gaia gaia.cl...@machinimatrix.org wrote: On 26.02.2013 15:44, CoDEmanX wrote: The addon's name could be added to the tooltip, but screencasts wouldn't benefit then... Adding the Addon Name to the tooltips sounds good. for video tutorials it would make sense to indicate whether users need an addon or if need just the built-in functions append_after(bpy.ops.*) looks ok, but shouldn't it rather be append_after(mesh.foobar) ? yes, good. And what to call the other function? prepend_before (I dislike)? maybe: name add_after() and add_before() One problem is still not covered: what if someone uses an addon with older blender, addon works but the given op / op name of a built-in function doesn't exist in that version? Isn't that a general problem ? We face this sort of issues a lot. Blender developers told me they mostly just provide the addon per release. So in that case there should be no problems. And when an addon shall span over multiple blender versions, a lot of extra work needs to be done anyways (potentially) . Am 26.02.2013 14:04, schrieb Gaia: Basically to help users to understand what comes from Blender and what has been added from outside. Especially the first part of my proposal about getting the ability to add menu entries inbetween the standard entries might make it convenient to know that this is from blender, and that is from an addon. Well it may be useful to distinguish between system addons which are distributed along with blender (and can be considered as part of blender), and the rest of the world. And ok, so lets make it a system option mark addon elements in user preferences. then a screencaster can enable that to give visual hints to the users. and users can decide to not care and disable the visual mark... On 26.02.2013 13:36, Bart Crouch wrote: On Tue, Feb 26, 2013 at 10:41 AM, Gaia gaia.cl...@machinimatrix.org wrote: Currently you can not tell if a button or a panel has been added by an addon. Could you perhaps explain why it would be desired to make a visual distinction between add-ons and built-in functionality? From a user-perspective I don't think it is very interesting to know whether a tool was written in Python or in C. And from a developers-perspective, I like the integration I can get when writing an add-on. Not sure its really needed to identify addons as being different to built-in functionality. As for adding items in the middle of a menu, this can be done already, but the menu its self needs to be modified. so rather then... bpy.types.SOME_MT_menu.append(draw_func) you could do... bpy.types.SOME_MT_menu.my_section.append(draw_func) Where `my_section` is simply a list defined in the class which the menu draw function calls. The main problem with this is we need to add these sections in blender releases, so addon devs can't just insert themselves into the middle of any menu. Its possible to do python tricks with intercepting the class draw function to insert your own logic, but these are so horrible I wouldn't recommend them. Blender could have a simple menu tree stored as text or data in user preferences: View 3D: Object: Transform: Origin to Geometry Origin to Active Randomize transform Edit Mode: Tool Shelf: Tetrahedron Maker Every Blender version would ship with such a menu tree structure. When registering an addon, a key for that addon is parsed from bl_info[name] and bl_info[location], Blender looks up the key inside the menu tree, and inserts the addon at the found location. The menu tree can have lots of missing keys: for any entry key that is not found in the menu tree, current behavior is simply followed. cheers Sjoerd ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] new API: ProgressBar()
how is Window.DrawProgressBar() implement in new API? How can I indicate for user a progress of running process? cheers Remigiusz ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Texture painting considerations (preparations for bratwurst merge)
This is supposed to happen. Internally texture paint uses stroke masking to avoid repainting on the same region. Solution: use air brush ;). ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Feature Request] Separate Cycles Rendered 3dView (Layer) Configuration
Hi, On Sun, Mar 3, 2013 at 9:12 PM, imagene...@gmail.com imagene...@gmail.com wrote: Solution: I would at least like to be able to hide emitters yet still have their output be rendered in the Rendered view. One way this can be accomplished is to be able to select a different set of layers for the 3d Rendered View, or have the ability to set a set of layers for each 3d View which would be useful in and of itself. In general: I think it makes sense to be able to configure the Rendered Cycles 3d View separately and quite possibly with additional configuration parameters from the standard 3d Views used for editing as this view and its intended functionality is quite different from a standard 3d View. There's a button next to the layers in the 3D view header that makes it possible to select different layers per 3D view, which seems to be what you describe? There's also an option to use the settings from the active render layer, this allows you to show extra layers rather than hide them. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collecting fixes for 2.66a release.
All merges done, URL for 2.66a: https://svn.blender.org/svnroot/bf-blender/tags/blender-2.66a-release/blender -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Feature request: Material Viewport Output Node
On Fri, Mar 1, 2013 at 12:49 AM, Vicente vicenteca...@gmail.com wrote: Hi, I want to propose a new feature: The Material Viewport Output Node. Sometimes the realtime display(in the 3D View) of a material has nothing to do with the final rendered material (i.e. using some kind of textures). In those cases could be ideal to count with a new node (Called Viewport Output) so you could create a single material with 2 different outputs, one for the render and one for the viewport. In my case I use Freestyle for the outlining of my models. It's impossible to use Freestyle in real time in the 3D viewport so I have 2 options, don't see the outlining in the viewport or create a fake black border using the normal node of the material so I can see it in real time but then I have to deactivate it each time I want to do a render. So the new Viewport Output node would be great. I'm thinking also in somekind of LOD applied only to the viewport display and not the render result. I guess there are a lot of applications for this feature. I hope this could be of help for more people. Best Regards, Vicente I posted the same idea last week and got no responses on the BF fun list. I think the main devs are all very hard at work on 2.66a -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Adding bone shape keys for easier support of character morphing
I wonder if blender could get skeleton shape keys for bone length changes. A typical usage would be character morphing, for example changing a character's arm length also needs changing the arm bones lengths along with the mesh shape . Other tools like DAZ Studio provide character morphing features which also seem to directly change the skeleton, one nice example for how far this can go is the DAZ genesis-character. Here is what DAZ studio provides: http://www.youtube.com/watch?v=cTBBnc2SJ90 Actually we have programmed this feature into our Blender Addon Avastar, but it is made for one particular rig and it is insanely slow because it needs to recalculate the mesh shape whenever a bone length changes and the access to the needed data seems to be extremely slow. Here is what we can currently do with our own addon (by far not as impressive as the DAZ tool): http://blog.machinimatrix.org/avastar/custom-shape-sliders/ So ... I think it would be really cool if blender provides some tools for implementing character morphing. One idea out of the blue: Skeleton shape keys work exactly like shape keys, there is a skeleton-basis and one or more skeleton-shapes with corresponding shape sliders. And a mesh could be tied to the bone shape via its bone weights. cheers, Gaia ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Texture painting considerations (preparations for bratwurst merge)
My previous answer is wrong it seems. It looks like when using the space stroke option, the two modes (projective/2D) operate slightly differently. Spacing is done on image/uv space for image editor and screen space for projective texturing. That means that most of the time, the 2D code will generate many more strokes per pixel than the projective case (because generally texture is zoomed out in viewport). This has the effect of getting a more intense result when painting in the 2D view. I wouldn't count this as a bug though, it is intended behaviour. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposed default margin increase for baked textures
Awesome! Thanks! -Andy On 04/03/2013 04:35, Campbell Barton wrote: On Mon, Mar 4, 2013 at 3:32 PM, Morten Mikkelsen mikkels...@gmail.com wrote: Go for it! :) On Sun, Mar 3, 2013 at 7:01 PM, Antony Riakiotakis kal...@gmail.com wrote: This is trivial but will require yet another version patch. If others agree I could commit it wit h a value of 16. Why version patch?, old files can keep their margin. Just update scene.c's bake_filter for newly added scenes, rna_scene.c's default and startup.blend. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Texture painting considerations (preparations for bratwurst merge)
That's ok, as long as you admit that you were wrong :) (kidding) On Mon, Mar 4, 2013 at 7:02 AM, Antony Riakiotakis kal...@gmail.com wrote: My previous answer is wrong it seems. It looks like when using the space stroke option, the two modes (projective/2D) operate slightly differently. Spacing is done on image/uv space for image editor and screen space for projective texturing. That means that most of the time, the 2D code will generate many more strokes per pixel than the projective case (because generally texture is zoomed out in viewport). This has the effect of getting a more intense result when painting in the 2D view. I wouldn't count this as a bug though, it is intended behaviour. ___ 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] build error on Windows with Mingw32 ( bf_blenlib.dir/intern/winstuff.c.obj] Error 1 )
Hi I am getting a build error on Windows7 with Mingw32. I used Cmake to create the build for using with Mingw32 on Windows7 64bit. here is the tail D:/_BLENDER_BUILDS/SVN/blender/source/blender/blenlib/BLI_path_util.h:110:1: error: unknown type name 'bool' D:/_BLENDER_BUILDS/SVN/blender/source/blender/blenlib/BLI_path_util.h:111:1: error: unknown type name 'bool' D:/_BLENDER_BUILDS/SVN/blender/source/blender/blenlib/BLI_path_util.h:115:1: error: unknown type name 'bool' D:/_BLENDER_BUILDS/SVN/blender/source/blender/blenlib/BLI_path_util.h:115:24: error: unknown type name 'bool' D:/_BLENDER_BUILDS/SVN/blender/source/blender/blenlib/BLI_path_util.h:140:1: error: unknown type name 'bool' D:/_BLENDER_BUILDS/SVN/blender/source/blender/blenlib/BLI_path_util.h:143:1: error: unknown type name 'bool' D:/_BLENDER_BUILDS/SVN/blender/source/blender/blenlib/BLI_path_util.h:157:1: error: unknown type name 'bool' D:/_BLENDER_BUILDS/SVN/blender/source/blender/blenlib/BLI_path_util.h:163:1: error: unknown type name 'bool' D:\_BLENDER_BUILDS\SVN\blender\source\blender\blenlib\intern\winstuff.c:208:1: warning: 'UNUSED_BLI_alloc_utf16_from_8' defined bu t not used [-Wunused-function] mingw32-make[2]: *** [source/blender/blenlib/CMakeFiles/bf_blenlib.dir/intern/winstuff.c.obj] Error 1 mingw32-make[1]: *** [source/blender/blenlib/CMakeFiles/bf_blenlib.dir/all] Error 2 mingw32-make: *** [all] Error 2 and here is the rest http://www.pasteall.org/40204 k ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] r55041 Build Error
Where are W_OK, X_OK defined? I cannot see it in at least SVN. Environment: windows XP/SP3 32bits msvc9+SCONS PerfectionCat. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] r55041 Build Error
It is fileops.c that an error occurs. X_OK,W_OK,R_OK,F_OK is not defined in msvc9. In addition, there is not the value to correspond to X_OK of the access function in msvc9. PerfectionCat. - Original Message - From: PerfectionCat sindra1961reb...@yahoo.co.jp To: bf-committers@blender.org bf-committers@blender.org Date: 2013/3/5, Tue 15:14 Subject: [Bf-committers] r55041 Build Error Where are W_OK, X_OK defined? I cannot see it in at least SVN. Environment: windows XP/SP3 32bits msvc9+SCONS PerfectionCat. ___ 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] r55041 Build Error
Checking on this.. shouldn't take long to resolve. On Tue, Mar 5, 2013 at 5:56 PM, PerfectionCat sindra1961reb...@yahoo.co.jp wrote: It is fileops.c that an error occurs. X_OK,W_OK,R_OK,F_OK is not defined in msvc9. In addition, there is not the value to correspond to X_OK of the access function in msvc9. PerfectionCat. - Original Message - From: PerfectionCat sindra1961reb...@yahoo.co.jp To: bf-committers@blender.org bf-committers@blender.org Date: 2013/3/5, Tue 15:14 Subject: [Bf-committers] r55041 Build Error Where are W_OK, X_OK defined? I cannot see it in at least SVN. Environment: windows XP/SP3 32bits msvc9+SCONS PerfectionCat. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
