Re: [Bf-committers] Collecting fixes for 2.66a release.
Hi, Commit 54754 is mine. But good to see it included ;) Thomas Am 02.03.2013 05:42, schrieb Campbell Barton: Hi I went over commits since release and make a suggested list of changes to be included in 2.66a. There are some areas I'm unsure of: * Mougri's BGE animation fixes (mixed in a bit with refactoring). * Aligorith made some animation fixes after fairly large commits to animation code. * Sergof's Bullet/Physics are mixed with features and fixes. need feedback which are safe for release. * Cessen made changes/fixes to Rigify. == Revs Checked == Trunk: 54697 -- 54965 Ext: 4315 -- 4336 Arranged by name so authors can check on their own work since last release. == Trunk == dfelinto: 54733 54754 54912 moguri: 54738 54764 54767 54780 54837 nazgul: 54746 54748 54901 54934 54935 54946 54947 54960 blendix: 54760 54793 54868 54885 54942 54943 54944 54945 54959 54965 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 psy-fi: 54788 ton: 54789 54790 54794 54816 54908 54910 54954 54961 nicholasbishop: 54827 gaiaclary: 54856 == Trunk (MAYBE) == dingto: 54948 aligorith: 54924 54926 54927 sergof: 54757 54799 54822 54855 54862 alexk: 54761 moguri: 54769 54772 gaiaclary: 54888 mont29: 54891 nazgul: 54904 54937 === Ext == campbellbarton: 4320 4325 4327 cessen: 4321 4334 4335 - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- 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
Re: [Bf-committers] Collecting fixes for 2.66a release.
Hi Campbell, Due to some bad timing, most of the intensive testing we were planning for 2.66 ended been done after 2.66 was out. That's not ideal, but I prefer taking changes of having animation or multi uv system not working, than the certainty of they not working (as it is in 2.66 now). So those are my suggestions (on top of yours): ==Trunk== 54745, 54757, 54759, 54766, 54769, 54772, 54777, 54828, 54922 + patch from #34428 ==Trunk(MAYBE)==: 54806, 54813, 54814, 54815 The explanations: = dfelinto: 54745 (alpha for other OSs - it works for OSX, this patch make it work for others) + [ gaiaclary: 54747 (buidfix) ] ((maybe that's the one you mistyped as 54754?)) 54922 (rst update) moguri: 54772 (definitively - no brainer) 54766 (animation fix) 54769 (animation fix part 2) 54777 (material anim port) - may be a MAYBE, but I think it's a safe and needed one. 54828 (harmless, removing excessive warning from console) patch on #34428 (to be committed asap by Mitchell) http://projects.blender.org/tracker/index.php?func=detailaid=34428group_id=9atid=306 [final fix for the multi-uv problems. I've been testing it and it's good. But I'm waiting for Mitchell to commit it] sergof: 54757 (that fix a segfault iirc) alexku: 54759 (fix for windows size on windows) MAYBE: (I'm not in X11, so I didn't try it, but it does seem as an important, no?) campbell: 54806 (fix for fullscreen on X11 - BGE) psy-fi: 54813: (same/complement of 54806) 54814: (same/complement of 54806) 54815: (same/complement of 54806) -- Dalai blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2013/3/1 Campbell Barton ideasma...@gmail.com Hi I went over commits since release and make a suggested list of changes to be included in 2.66a. There are some areas I'm unsure of: * Mougri's BGE animation fixes (mixed in a bit with refactoring). * Aligorith made some animation fixes after fairly large commits to animation code. * Sergof's Bullet/Physics are mixed with features and fixes. need feedback which are safe for release. * Cessen made changes/fixes to Rigify. == Revs Checked == Trunk: 54697 -- 54965 Ext: 4315 -- 4336 Arranged by name so authors can check on their own work since last release. == Trunk == dfelinto: 54733 54754 54912 moguri: 54738 54764 54767 54780 54837 nazgul: 54746 54748 54901 54934 54935 54946 54947 54960 blendix: 54760 54793 54868 54885 54942 54943 54944 54945 54959 54965 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 psy-fi: 54788 ton: 54789 54790 54794 54816 54908 54910 54954 54961 nicholasbishop: 54827 gaiaclary: 54856 == Trunk (MAYBE) == dingto: 54948 aligorith: 54924 54926 54927 sergof: 54757 54799 54822 54855 54862 alexk: 54761 moguri: 54769 54772 gaiaclary: 54888 mont29: 54891 nazgul: 54904 54937 === Ext == campbellbarton: 4320 4325 4327 cessen: 4321 4334 4335 - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collecting fixes for 2.66a release.
Sergey did a fix such that the dilated region outside a displacement map isn't very dark. Without it you get really bad filtering seams. Perhaps sergey can chime in? Cheers, Morten. On Sat, Mar 2, 2013 at 2:47 AM, Dalai Felinto dfeli...@gmail.com wrote: Hi Campbell, Due to some bad timing, most of the intensive testing we were planning for 2.66 ended been done after 2.66 was out. That's not ideal, but I prefer taking changes of having animation or multi uv system not working, than the certainty of they not working (as it is in 2.66 now). So those are my suggestions (on top of yours): ==Trunk== 54745, 54757, 54759, 54766, 54769, 54772, 54777, 54828, 54922 + patch from #34428 ==Trunk(MAYBE)==: 54806, 54813, 54814, 54815 The explanations: = dfelinto: 54745 (alpha for other OSs - it works for OSX, this patch make it work for others) + [ gaiaclary: 54747 (buidfix) ] ((maybe that's the one you mistyped as 54754?)) 54922 (rst update) moguri: 54772 (definitively - no brainer) 54766 (animation fix) 54769 (animation fix part 2) 54777 (material anim port) - may be a MAYBE, but I think it's a safe and needed one. 54828 (harmless, removing excessive warning from console) patch on #34428 (to be committed asap by Mitchell) http://projects.blender.org/tracker/index.php?func=detailaid=34428group_id=9atid=306 [final fix for the multi-uv problems. I've been testing it and it's good. But I'm waiting for Mitchell to commit it] sergof: 54757 (that fix a segfault iirc) alexku: 54759 (fix for windows size on windows) MAYBE: (I'm not in X11, so I didn't try it, but it does seem as an important, no?) campbell: 54806 (fix for fullscreen on X11 - BGE) psy-fi: 54813: (same/complement of 54806) 54814: (same/complement of 54806) 54815: (same/complement of 54806) -- Dalai blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2013/3/1 Campbell Barton ideasma...@gmail.com Hi I went over commits since release and make a suggested list of changes to be included in 2.66a. There are some areas I'm unsure of: * Mougri's BGE animation fixes (mixed in a bit with refactoring). * Aligorith made some animation fixes after fairly large commits to animation code. * Sergof's Bullet/Physics are mixed with features and fixes. need feedback which are safe for release. * Cessen made changes/fixes to Rigify. == Revs Checked == Trunk: 54697 -- 54965 Ext: 4315 -- 4336 Arranged by name so authors can check on their own work since last release. == Trunk == dfelinto: 54733 54754 54912 moguri: 54738 54764 54767 54780 54837 nazgul: 54746 54748 54901 54934 54935 54946 54947 54960 blendix: 54760 54793 54868 54885 54942 54943 54944 54945 54959 54965 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 psy-fi: 54788 ton: 54789 54790 54794 54816 54908 54910 54954 54961 nicholasbishop: 54827 gaiaclary: 54856 == Trunk (MAYBE) == dingto: 54948 aligorith: 54924 54926 54927 sergof: 54757 54799 54822 54855 54862 alexk: 54761 moguri: 54769 54772 gaiaclary: 54888 mont29: 54891 nazgul: 54904 54937 === Ext == campbellbarton: 4320 4325 4327 cessen: 4321 4334 4335 - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] proposal for better integration of addon functionality
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. ___ 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] Collecting fixes for 2.66a release.
The multi-uv fix patch that Dalai mentioned has been committed as r54972, and it fixes three of our bug reports. Cheers, Mitchell On Sat, Mar 2, 2013 at 6:48 AM, Morten Mikkelsen mikkels...@gmail.comwrote: Sergey did a fix such that the dilated region outside a displacement map isn't very dark. Without it you get really bad filtering seams. Perhaps sergey can chime in? Cheers, Morten. On Sat, Mar 2, 2013 at 2:47 AM, Dalai Felinto dfeli...@gmail.com wrote: Hi Campbell, Due to some bad timing, most of the intensive testing we were planning for 2.66 ended been done after 2.66 was out. That's not ideal, but I prefer taking changes of having animation or multi uv system not working, than the certainty of they not working (as it is in 2.66 now). So those are my suggestions (on top of yours): ==Trunk== 54745, 54757, 54759, 54766, 54769, 54772, 54777, 54828, 54922 + patch from #34428 ==Trunk(MAYBE)==: 54806, 54813, 54814, 54815 The explanations: = dfelinto: 54745 (alpha for other OSs - it works for OSX, this patch make it work for others) + [ gaiaclary: 54747 (buidfix) ] ((maybe that's the one you mistyped as 54754?)) 54922 (rst update) moguri: 54772 (definitively - no brainer) 54766 (animation fix) 54769 (animation fix part 2) 54777 (material anim port) - may be a MAYBE, but I think it's a safe and needed one. 54828 (harmless, removing excessive warning from console) patch on #34428 (to be committed asap by Mitchell) http://projects.blender.org/tracker/index.php?func=detailaid=34428group_id=9atid=306 [final fix for the multi-uv problems. I've been testing it and it's good. But I'm waiting for Mitchell to commit it] sergof: 54757 (that fix a segfault iirc) alexku: 54759 (fix for windows size on windows) MAYBE: (I'm not in X11, so I didn't try it, but it does seem as an important, no?) campbell: 54806 (fix for fullscreen on X11 - BGE) psy-fi: 54813: (same/complement of 54806) 54814: (same/complement of 54806) 54815: (same/complement of 54806) -- Dalai blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2013/3/1 Campbell Barton ideasma...@gmail.com Hi I went over commits since release and make a suggested list of changes to be included in 2.66a. There are some areas I'm unsure of: * Mougri's BGE animation fixes (mixed in a bit with refactoring). * Aligorith made some animation fixes after fairly large commits to animation code. * Sergof's Bullet/Physics are mixed with features and fixes. need feedback which are safe for release. * Cessen made changes/fixes to Rigify. == Revs Checked == Trunk: 54697 -- 54965 Ext: 4315 -- 4336 Arranged by name so authors can check on their own work since last release. == Trunk == dfelinto: 54733 54754 54912 moguri: 54738 54764 54767 54780 54837 nazgul: 54746 54748 54901 54934 54935 54946 54947 54960 blendix: 54760 54793 54868 54885 54942 54943 54944 54945 54959 54965 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 psy-fi: 54788 ton: 54789 54790 54794 54816 54908 54910 54954 54961 nicholasbishop: 54827 gaiaclary: 54856 == Trunk (MAYBE) == dingto: 54948 aligorith: 54924 54926 54927 sergof: 54757 54799 54822 54855 54862 alexk: 54761 moguri: 54769 54772 gaiaclary: 54888 mont29: 54891 nazgul: 54904 54937 === Ext == campbellbarton: 4320 4325 4327 cessen: 4321 4334 4335 - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Build Error: collada_utils.cpp
Hello, Since commit #54970 I'm having a compilation error (scons msvs9) with collada_utils.cpp: collada_utils.cpp(59) : fatal error C1083: Cannot open include file: 'bmesh.h': No such file or directory Cheers, Harley ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Build Error: collada_utils.cpp
Apologize for that. I use cmake and i forgot to maintain the SConscript. I hope its fixed by now (revision 54976) cheers, Gaia On 02.03.2013 19:55, Harley Acheson wrote: Hello, Since commit #54970 I'm having a compilation error (scons msvs9) with collada_utils.cpp: collada_utils.cpp(59) : fatal error C1083: Cannot open include file: 'bmesh.h': No such file or directory Cheers, Harley ___ 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] Reset to Defaults Updated Sample Patch
Hello, I've noticed that Reset to Default Values has not been removed. To help in evaluating whether that feature is useful I have made a new patch against the current state of SVN (54976). This one adds default values to almost all the items found only on the Scene panel of the Properties editor. I have only done that one panel because of the time involved. I am hoping that you can try it and wade in on whether this is useful. So please try the following patch: http://projects.blender.org/tracker/download.php/9/127/32894/24303/DefaultsAsDefinesScene.diff Once installed you should be able to right-click on almost anything on that panel and reset to default values including render dimensions, frame range, etc. It is especially nice on the layers region because it would not be too obvious to many people which 6 of the 9 layers are included by default, or which 2 of the 18 passes are enabled by default. Cheers, Harley ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Render resolution question
Hello,
In working on some sprites I often find the need to change cameras and render
dimensions. I figured I'd make a small change in the source to give cameras the
option of using their own render dimensions for rendering instead. So far I
have added the resolution properties and a flag entry 'CAM_USELOCALRES' to the
camera. However, I can't figure out where I would need to switch between using
the scene.render dimensions or the active camera's ones. For my purposes it is
enough to have it switch when I'm in camera view (so that the view frame shows
accordingly) and when rendering (no need for changes in OpenGL rendering, BGE,
etc.). Ideally there would be one or two places where I could do something
along the lines of:
if(scene.camera.flag CAM_USELOCALRES){dimension_x = scene.camera.resX}
else{dimension_x = scene.r.xsch} //at least I think xsch is the one here?
Any help on this would be much appreciated.
Cheers,
Patrick
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] please help with BLI_STATIC_ASSERT build failure on linux
Hi; Today i have added some bmesh code to the collada exporter. This annoyingly produced compile errors on linux and i apologize for that.However there was a bit of researching in the blendercoders IRC to find out why that issue occurs, but no solution was found. So i commentedout my change for now. Please can someone tell what causes this problem on linux when you use gcc-4.6.3 ? Actually you only need to uncomment the include statement in line 60 of collada_utils.cpp then the build no longer works. The error on linux is something like: In file included from source/blender/bmesh/bmesh.h:248:0, from source/blender/collada/collada_utils.cpp:59: source/blender/bmesh/bmesh_class.h:85:1: error: expected constructor, destructor, or type conversion before »(« token On windows this problem does not show up. That's also why i was not at all aware of it. Below you find the breaking patch. Many thanks in advance for any help on this. cheers Gaia Index: source/blender/collada/collada_utils.cpp === --- source/blender/collada/collada_utils.cpp(revision 54982) +++ source/blender/collada/collada_utils.cpp(working copy) @@ -57,7 +57,7 @@ #include WM_api.h // XXX hrm, see if we can do without this #include WM_types.h -//#include bmesh.h +#include bmesh.h } @@ -387,12 +387,10 @@ bool use_beauty = false; bool tag_only = false; -/* BMesh *bm = BM_mesh_create(bm_mesh_allocsize_default); BM_mesh_bm_from_me(bm, me, FALSE, 0); BM_mesh_triangulate(bm, use_beauty, tag_only, NULL, NULL); BM_mesh_bm_to_me(bm, me, FALSE); BM_mesh_free(bm); -*/ } ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Render resolution question
On Sun, Mar 3, 2013 at 10:55 AM, patrick boelens p_boel...@msn.com wrote:
Hello,
In working on some sprites I often find the need to change cameras and render
dimensions. I figured I'd make a small change in the source to give cameras
the option of using their own render dimensions for rendering instead. So far
I have added the resolution properties and a flag entry 'CAM_USELOCALRES' to
the camera. However, I can't figure out where I would need to switch between
using the scene.render dimensions or the active camera's ones. For my
purposes it is enough to have it switch when I'm in camera view (so that the
view frame shows accordingly) and when rendering (no need for changes in
OpenGL rendering, BGE, etc.). Ideally there would be one or two places where
I could do something along the lines of:
if(scene.camera.flag CAM_USELOCALRES){dimension_x = scene.camera.resX}
else{dimension_x = scene.r.xsch} //at least I think xsch is the one here?
Any help on this would be much appreciated.
Cheers,
Patrick
Hi, don't think theres any shortcut to this, search for xsch shows 56
results, even discounting game engine and envmap there are still many
references to this.
Not sure this feature would be accepted, but think the correct way to
do this would be to replace scene.r.xsch with a function call that
takes (scene-r, scene-camera).
If this is only for your own use you could use a
'bpy.app.handlers.render_pre' python callback which sets the render
size from camera properties.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Render resolution question
Ah, darn. =( This is indeed for personal use only; I think finding a real, nice
solution for merging scene and camera properties like this would take quite a
bit of effort and discussion on what belongs where first.
I thought about using the Py handler, but that would not update the frame from
Camera View. I could replace the Scene's render dimensions with the Camera's,
but then I would still need to manually execute an operator every time I select
a new camera (not a big issue, but still). I guess that's the way I'll go then
though.
Thanks,
Patrick
Date: Sun, 3 Mar 2013 12:44:45 +1100
From: ideasma...@gmail.com
To: bf-committers@blender.org
Subject: Re: [Bf-committers] Render resolution question
On Sun, Mar 3, 2013 at 10:55 AM, patrick boelens p_boel...@msn.com wrote:
Hello,
In working on some sprites I often find the need to change cameras and
render dimensions. I figured I'd make a small change in the source to give
cameras the option of using their own render dimensions for rendering
instead. So far I have added the resolution properties and a flag entry
'CAM_USELOCALRES' to the camera. However, I can't figure out where I would
need to switch between using the scene.render dimensions or the active
camera's ones. For my purposes it is enough to have it switch when I'm in
camera view (so that the view frame shows accordingly) and when rendering
(no need for changes in OpenGL rendering, BGE, etc.). Ideally there would
be one or two places where I could do something along the lines of:
if(scene.camera.flag CAM_USELOCALRES){dimension_x = scene.camera.resX}
else{dimension_x = scene.r.xsch} //at least I think xsch is the one here?
Any help on this would be much appreciated.
Cheers,
Patrick
Hi, don't think theres any shortcut to this, search for xsch shows 56
results, even discounting game engine and envmap there are still many
references to this.
Not sure this feature would be accepted, but think the correct way to
do this would be to replace scene.r.xsch with a function call that
takes (scene-r, scene-camera).
If this is only for your own use you could use a
'bpy.app.handlers.render_pre' python callback which sets the render
size from camera properties.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] proposal for better integration of addon functionality
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. -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Linking error with libge on Windows
Hi I am getting a compiling problem with the latest svn #54983, something todo with the GE code. For example \source\gameengine\Ketsji\KX_KetsjiEngine.cpp:389:52: warning: 'scene' may be used uninitialized in this function [-Wuninitialized] Linking CXX static library ..\..\..\lib\libge_logic_ketsji.a [ 50%] Built target ge_logic_ketsji mingw32-make: *** [all] Error 2 http://www.pasteall.org/40166 thanks k ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Linking error with libge on Windows
Strange, I'm not seeing an actual error in that log output. Warnings usually don't stop a compile, and that particular warning (unused scene in dome code) has been around for a long time. --Mitchell On Sat, Mar 2, 2013 at 6:34 PM, Kursad Karatas gonder...@plecxus.comwrote: Hi I am getting a compiling problem with the latest svn #54983, something todo with the GE code. For example \source\gameengine\Ketsji\KX_KetsjiEngine.cpp:389:52: warning: 'scene' may be used uninitialized in this function [-Wuninitialized] Linking CXX static library ..\..\..\lib\libge_logic_ketsji.a [ 50%] Built target ge_logic_ketsji mingw32-make: *** [all] Error 2 http://www.pasteall.org/40166 thanks k ___ 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] Linking error with libge on Windows
On 03/02/2013 11:14 PM, Mitchell Stokes wrote: Strange, I'm not seeing an actual error in that log output. Warnings usually don't stop a compile, and that particular warning (unused scene in dome code) has been around for a long time. --Mitchell Mitchell, thanks for the reply. I will see if this is a local issue. This is a regular vanilla build that normally builds fine, that is why in thought I would report it first. thanks k ___ 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 Campbell, aligorith: 54924 54926 54927 I think it's best if we held off including these for 2.66a. There's still a bit of polish needed for a few edge cases. On Sun, Mar 3, 2013 at 7:13 PM, Sergej Reich sergej.re...@googlemail.comwrote: Hi Campbell sergof: 54757 54799 54822 54855 54862 I'd like to have them all included as well as 54818, 54990 and 54991. Am Samstag, den 02.03.2013, 15:42 +1100 schrieb Campbell Barton: Hi I went over commits since release and make a suggested list of changes to be included in 2.66a. There are some areas I'm unsure of: * Mougri's BGE animation fixes (mixed in a bit with refactoring). * Aligorith made some animation fixes after fairly large commits to animation code. * Sergof's Bullet/Physics are mixed with features and fixes. need feedback which are safe for release. * Cessen made changes/fixes to Rigify. == Revs Checked == Trunk: 54697 -- 54965 Ext: 4315 -- 4336 Arranged by name so authors can check on their own work since last release. == Trunk == dfelinto: 54733 54754 54912 moguri: 54738 54764 54767 54780 54837 nazgul: 54746 54748 54901 54934 54935 54946 54947 54960 blendix: 54760 54793 54868 54885 54942 54943 54944 54945 54959 54965 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 psy-fi: 54788 ton: 54789 54790 54794 54816 54908 54910 54954 54961 nicholasbishop: 54827 gaiaclary: 54856 == Trunk (MAYBE) == dingto: 54948 aligorith: 54924 54926 54927 sergof: 54757 54799 54822 54855 54862 alexk: 54761 moguri: 54769 54772 gaiaclary: 54888 mont29: 54891 nazgul: 54904 54937 === Ext == campbellbarton: 4320 4325 4327 cessen: 4321 4334 4335 - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
