Re: [Bf-committers] Blender 2.62 Release AHOY!
Compiled again this morning Problem of bad working seems to be solved (though I do not know why ;-) ) Peter 2012/2/17 Nathan Letwory nat...@letworyinteractive.com Do the release binaries for Windows work fine, though? /Nathan On Fri, Feb 17, 2012 at 8:55 AM, Peter K.H. Gragert pkhgrag...@gmail.com wrote: Hi, the compilation with mingw32-make install (cmake on Vista) gave a working but horribly working blender.exe any click let the program ask for full power of the CPU all was very 'traege (german) such that it is not usable at all, with other words horrible. I asked at blendercoders yesterday, but nobody replied to my questions maybe a forgotten option in cmake options(which I do not know). greetings Peter 2012/2/16 Ton Roosendaal t...@blender.org Hi all, The release is out! Thanks for all the efficient work! It's getting easier it seems :) SVN has been unfrozen already a couple of hours ago. Commit ahead, but keep in mind we try to keep svn ready for the big BMesh merger next week or so. Laters, -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 16 Feb, 2012, at 8:05, Sergey Sharybin wrote: Copied OSX, windows, linux and freebs i386 builds to default location. RC1 builds will be removed after official release announce. Thanks everybody for the builds! On Thu, Feb 16, 2012 at 7:32 AM, pete larabell xgl.asyl...@gmail.com wrote: I'm having serious compile trouble on FreeBSD 9.0. I've been unable to get Blender to compile, with gcc42, gcc46, or clang. I have uploaded the FreeBSD 8.2 i386 version to the normal location. ___ 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 ___ 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 -- Nathan Letwory Letwory Interactive http://www.letworyinteractive.com ___ 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 [44178] trunk/blender: Camera tracking: animation datablock for MovieClip
Looks like you're missing a few things:
- an entry in expand_movieclips() or whatever that is called. This is
done for all lib-linked stuff
- BKE_animdata_main_cb(), and BKE_all_animdata_fix_paths_rename()
On Fri, Feb 17, 2012 at 9:13 PM, Sergey Sharybin sergey@gmail.com wrote:
Revision: 44178
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=44178
Author: nazgul
Date: 2012-02-17 08:13:45 + (Fri, 17 Feb 2012)
Log Message:
---
Camera tracking: animation datablock for MovieClip
Added AnimData block to MovieClip datablock which allows to animate different
properties in clip.
Currently supports animation of stabilization influence only.
--
svn merge -r44129:44130 ^/branches/soc-2011-tomato
Revision Links:
--
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=44129
Modified Paths:
--
trunk/blender/source/blender/blenkernel/intern/anim_sys.c
trunk/blender/source/blender/blenkernel/intern/movieclip.c
trunk/blender/source/blender/blenloader/intern/readfile.c
trunk/blender/source/blender/blenloader/intern/writefile.c
trunk/blender/source/blender/makesdna/DNA_movieclip_types.h
trunk/blender/source/blender/makesrna/intern/rna_movieclip.c
trunk/blender/source/blender/makesrna/intern/rna_tracking.c
Property Changed:
trunk/blender/
trunk/blender/source/blender/editors/space_outliner/
Property changes on: trunk/blender
___
Modified: svn:mergeinfo
-
/branches/soc-2011-cucumber:37517,38166-38167,38177,38179-38180,38187,38242,38384,38387,38403-38404,38407,38968,38970,38973,39045,40845,42997-42998,43439
/branches/soc-2011-tomato:42376,42378-42379,42383,42385,42395,42397-42400,42407,42411,42418,42443-42444,42446,42467,42472,42486,42650-42652,42654-42655,42709-42710,42733-42734,42801,43872
+
/branches/soc-2011-cucumber:37517,38166-38167,38177,38179-38180,38187,38242,38384,38387,38403-38404,38407,38968,38970,38973,39045,40845,42997-42998,43439
/branches/soc-2011-tomato:42376,42378-42379,42383,42385,42395,42397-42400,42407,42411,42418,42443-42444,42446,42467,42472,42486,42650-42652,42654-42655,42709-42710,42733-42734,42801,43872,44130
Modified: trunk/blender/source/blender/blenkernel/intern/anim_sys.c
===
--- trunk/blender/source/blender/blenkernel/intern/anim_sys.c 2012-02-17
07:32:18 UTC (rev 44177)
+++ trunk/blender/source/blender/blenkernel/intern/anim_sys.c 2012-02-17
08:13:45 UTC (rev 44178)
@@ -88,6 +88,7 @@
case ID_LA: case ID_CA: case ID_WO:
case ID_SPK:
case ID_SCE:
+ case ID_MC:
{
return 1;
}
@@ -2335,6 +2336,9 @@
/* speakers */
EVAL_ANIM_IDS(main-speaker.first, ADT_RECALC_ANIM);
+ /* movie clips */
+ EVAL_ANIM_IDS(main-movieclip.first, ADT_RECALC_ANIM);
+
/* objects */
/* ADT_RECALC_ANIM doesn't need to be supplied here, since
object AnimData gets
* this tagged by Depsgraph on framechange. This optimisation
means that objects
Modified: trunk/blender/source/blender/blenkernel/intern/movieclip.c
===
--- trunk/blender/source/blender/blenkernel/intern/movieclip.c 2012-02-17
07:32:18 UTC (rev 44177)
+++ trunk/blender/source/blender/blenkernel/intern/movieclip.c 2012-02-17
08:13:45 UTC (rev 44178)
@@ -64,6 +64,7 @@
#include BLI_mempool.h
#include BLI_threads.h
+#include BKE_animsys.h
#include BKE_constraint.h
#include BKE_library.h
#include BKE_global.h
@@ -889,6 +890,8 @@
IMB_free_anim(clip-anim);
clip-anim= FALSE;
}
+
+ BKE_free_animdata((ID *) clip);
}
void BKE_movieclip_reload(MovieClip *clip)
Modified: trunk/blender/source/blender/blenloader/intern/readfile.c
===
--- trunk/blender/source/blender/blenloader/intern/readfile.c 2012-02-17
07:32:18 UTC (rev 44177)
+++ trunk/blender/source/blender/blenloader/intern/readfile.c 2012-02-17
08:13:45 UTC (rev 44178)
@@ -6050,6 +6050,8 @@
MovieTracking *tracking= clip-tracking;
MovieTrackingObject *object;
+ clip-adt= newdataadr(fd, clip-adt);
+
if(fd-movieclipmap) clip-cache= newmclipadr(fd, clip-cache);
else clip-cache= NULL;
@@ -6087,6 +6089,9 @@
clip= main-movieclip.first;
while(clip) {
if(clip-id.flag LIB_NEEDLINK) {
+ if (clip-adt)
+ lib_link_animdata(fd, clip-id, clip-adt);
+
clip-gpd= newlibadr_us(fd, clip-id.lib, clip-gpd);
clip-id.flag -=
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [44178] trunk/blender: Camera tracking: animation datablock for MovieClip
Ah, indeed. Easy to miss some of changes when they need to be done in
several places. Will fix it soon.
On Fri, Feb 17, 2012 at 4:25 PM, Joshua Leung aligor...@gmail.com wrote:
Looks like you're missing a few things:
- an entry in expand_movieclips() or whatever that is called. This is
done for all lib-linked stuff
- BKE_animdata_main_cb(), and BKE_all_animdata_fix_paths_rename()
On Fri, Feb 17, 2012 at 9:13 PM, Sergey Sharybin sergey@gmail.com
wrote:
Revision: 44178
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=44178
Author: nazgul
Date: 2012-02-17 08:13:45 + (Fri, 17 Feb 2012)
Log Message:
---
Camera tracking: animation datablock for MovieClip
Added AnimData block to MovieClip datablock which allows to animate
different properties in clip.
Currently supports animation of stabilization influence only.
--
svn merge -r44129:44130 ^/branches/soc-2011-tomato
Revision Links:
--
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=44129
Modified Paths:
--
trunk/blender/source/blender/blenkernel/intern/anim_sys.c
trunk/blender/source/blender/blenkernel/intern/movieclip.c
trunk/blender/source/blender/blenloader/intern/readfile.c
trunk/blender/source/blender/blenloader/intern/writefile.c
trunk/blender/source/blender/makesdna/DNA_movieclip_types.h
trunk/blender/source/blender/makesrna/intern/rna_movieclip.c
trunk/blender/source/blender/makesrna/intern/rna_tracking.c
Property Changed:
trunk/blender/
trunk/blender/source/blender/editors/space_outliner/
Property changes on: trunk/blender
___
Modified: svn:mergeinfo
-
/branches/soc-2011-cucumber:37517,38166-38167,38177,38179-38180,38187,38242,38384,38387,38403-38404,38407,38968,38970,38973,39045,40845,42997-42998,43439
/branches/soc-2011-tomato:42376,42378-42379,42383,42385,42395,42397-42400,42407,42411,42418,42443-42444,42446,42467,42472,42486,42650-42652,42654-42655,42709-42710,42733-42734,42801,43872
+
/branches/soc-2011-cucumber:37517,38166-38167,38177,38179-38180,38187,38242,38384,38387,38403-38404,38407,38968,38970,38973,39045,40845,42997-42998,43439
/branches/soc-2011-tomato:42376,42378-42379,42383,42385,42395,42397-42400,42407,42411,42418,42443-42444,42446,42467,42472,42486,42650-42652,42654-42655,42709-42710,42733-42734,42801,43872,44130
Modified: trunk/blender/source/blender/blenkernel/intern/anim_sys.c
===
--- trunk/blender/source/blender/blenkernel/intern/anim_sys.c
2012-02-17 07:32:18 UTC (rev 44177)
+++ trunk/blender/source/blender/blenkernel/intern/anim_sys.c
2012-02-17 08:13:45 UTC (rev 44178)
@@ -88,6 +88,7 @@
case ID_LA: case ID_CA: case ID_WO:
case ID_SPK:
case ID_SCE:
+ case ID_MC:
{
return 1;
}
@@ -2335,6 +2336,9 @@
/* speakers */
EVAL_ANIM_IDS(main-speaker.first, ADT_RECALC_ANIM);
+ /* movie clips */
+ EVAL_ANIM_IDS(main-movieclip.first, ADT_RECALC_ANIM);
+
/* objects */
/* ADT_RECALC_ANIM doesn't need to be supplied here,
since object AnimData gets
* this tagged by Depsgraph on framechange. This
optimisation means that objects
Modified: trunk/blender/source/blender/blenkernel/intern/movieclip.c
===
--- trunk/blender/source/blender/blenkernel/intern/movieclip.c
2012-02-17 07:32:18 UTC (rev 44177)
+++ trunk/blender/source/blender/blenkernel/intern/movieclip.c
2012-02-17 08:13:45 UTC (rev 44178)
@@ -64,6 +64,7 @@
#include BLI_mempool.h
#include BLI_threads.h
+#include BKE_animsys.h
#include BKE_constraint.h
#include BKE_library.h
#include BKE_global.h
@@ -889,6 +890,8 @@
IMB_free_anim(clip-anim);
clip-anim= FALSE;
}
+
+ BKE_free_animdata((ID *) clip);
}
void BKE_movieclip_reload(MovieClip *clip)
Modified: trunk/blender/source/blender/blenloader/intern/readfile.c
===
--- trunk/blender/source/blender/blenloader/intern/readfile.c
2012-02-17 07:32:18 UTC (rev 44177)
+++ trunk/blender/source/blender/blenloader/intern/readfile.c
2012-02-17 08:13:45 UTC (rev 44178)
@@ -6050,6 +6050,8 @@
MovieTracking *tracking= clip-tracking;
MovieTrackingObject *object;
+ clip-adt= newdataadr(fd, clip-adt);
+
if(fd-movieclipmap) clip-cache= newmclipadr(fd, clip-cache);
else clip-cache= NULL;
@@ -6087,6 +6089,9 @@
clip= main-movieclip.first;
while(clip) {
Re: [Bf-committers] About COLLADA im/export functionality situation
I'm sorry I couldn't commit my python export plugin yet, I'm on a trip and then I'll be attending GDC. After that I hope i'll have a little more time for this. Juan On Tue, Feb 7, 2012 at 4:36 PM, Ton Roosendaal t...@blender.org wrote: Hi, We're going in a circle now again, back to where it all started! Let's try to solve this complex issue in tiny little steps with Gaia Clary's team. They are actual stakeholders (= they use and need collada). If more stakeholders pop up we can add them to the team too, and together they can define what to use for testing and validation. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 7 Feb, 2012, at 20:04, Erwin Coumans wrote: I agree we need to test our COLLADA exporter AND our COLLADA importer, against various applications. In addition, you might want to test your export/import using the official conformance test: http://www.khronos.org/conformance/implementers/collada (I think this test became available free of charge) Thanks, Erwin On 7 February 2012 09:34, Brecht Van Lommel brechtvanlom...@pandora.be wrote: Hi, On Tue, Feb 7, 2012 at 10:28 AM, Arystanbek Dyussenov arysta...@gmail.com wrote: At the moment i only can verify that the exported rig and the mesh weights are now recognized from the Second Life Importer. But it would be of a much higher value if there where some Collada standard viewer where we can check the exports. I think we could use FX-Composer. It is free and, as it seems to me, has a good level of COLLADA support. I think we should not make the assumption that there is a standard viewer that we can check everything against, in practice it just needs to be tested against many applications like MeshLab, Sketchup, Max, Maya, ... same as was done for FBX. Otherwise you just end up fixing things for one application and breaking it for others again. 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] blender users group for Chicago IL
TorQ and I had a ChiBUG in Chicago for a while. But it was pretty much only the two of us who showed up, for a couple of meetings. No idea how much longer I'm going to be in the area, but would love to see a real Blender BUG happen in Chicago. pete larabell xgl.asyl...@gmail.com writes: Here's another one from WI that would like to attend. :) On Tue, Feb 14, 2012 at 9:59 AM, CG Cookie jonat...@cgcookie.com wrote: Hey Seth, Myself and the CG Cookie studio are based in the Western suburbs. I would love to take part in a Chicago area users group. -- CG Cookie Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Tuesday, February 14, 2012 at 8:38 AM, Kent Mein wrote: On Feb 13, 2012, at 7:16 PM, seth wilson wrote: Hello, I'm not sure if this is the right place to ask. I have been unable to find any Blender users or training anywhere near Chicago IL. I am wondering if I could be authorized to start and or take part in a Blender users group for the Chicagoland area. I would still consider myself at the intermediate level with Blender but have been using the software for over 2 years now. Having nothing but online support has made my journey very slow. Which is why I want to do this. I currently work at U of C in the special events department and may be able to obtain a space to use and a/v equipment for presentations and classes. Thanks,Seth ___ Bf-committers mailing list Bf-committers@blender.org (mailto:Bf-committers@blender.org) http://lists.blender.org/mailman/listinfo/bf-committers Hi Seth, Sounds good. You do not need any approval to form a users group. Go for it. You might want to post something to blender nation to let others know about it. Kent Mein ___ Bf-committers mailing list Bf-committers@blender.org (mailto: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 [44205] branches/cycles/intern/cycles/ blender/addon/presets/: Cycles Presets:
Sorry, ignore that, wanted to commit to trunk. Am 17.02.2012 20:25, schrieb Thomas Dinges: Revision: 44205 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=44205 Author: dingto Date: 2012-02-17 19:25:51 + (Fri, 17 Feb 2012) Log Message: --- Cycles Presets: * New presets folder in the addon folder. Added Paths: --- branches/cycles/intern/cycles/blender/addon/presets/ Property changes on: branches/cycles/intern/cycles/blender/addon/presets ___ Added: bugtraq:number + true ___ Bf-blender-cvs mailing list bf-blender-...@blender.org http://lists.blender.org/mailman/listinfo/bf-blender-cvs -- 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] Color Unpremultiply
Hi. I have some questions regarding the new Color Unpremultiply option in Blender. I understand what it does, but I wonder if there isn't a more elegant or accurate way to expose it. First of all, the text in the tooltip is a little bit misleading. The operation performed isn't done to avoid a fringe on light backgrounds. It's done because colorspace conversions shouldn't be performed on premultiplied data. The resulting effect when doing it wrong is indeed a fringe, but what the operation does is to deliver a properly converted image, not avoiding a fringe. This may sound silly, but I think that using a more accurate tooltip would have an educational effect because people would know what it does or would investigate more rather than this is for reducing a fringe. A fringe can come from a wrong compositing earlier, and believing that color unpremultiply will fix it is wrong. Apart from that, I wonder if it's really necessary to have that option instead of just applying it whenever premultiplied alpha is selected and the output file is gamma-corrected. Actually, I wonder if Blender shouldn't use premultiplied or straight (graying out sky) when output is RGBA and conversely offer just sky when output is RGB. I don't know if blender's internals allow this, but it would simplify the UI a little and help to avoid some common mistakes caused by mere distraction. Apart from that it would have an educational value making easier to new users to choose the right values. Makes sense? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] [Patch]: Remove RST section in docs about row major vs. column major matrix modes
Hi, I've just stumbled over the passage about matrix modes in the gotchas section of the online python API: http://www.blender.org/documentation/blender_python_api_2_62_release/info_gotcha.html#matrix-multiplication-is-wrong From my understanding of this commit, the above mentioned section should be removed or at least modified: http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=42858 My patch simply removes the passage from the blender/doc/python_api/rst/info_gotcha.rst section. Have fun Konrad Index: info_gotcha.rst === --- info_gotcha.rst (revision 44051) +++ info_gotcha.rst (working copy) @@ -117,15 +117,6 @@ bpy.ops.wm.redraw_timer(type='DRAW_WIN_SWAP', iterations=1) - -Matrix multiplication is wrong -== - -Every so often users complain that Blenders matrix math is wrong, the confusion comes from mathutils matrices being column-major to match OpenGL and the rest of Blenders matrix operations and stored matrix data. - -This is different to **numpy** which is row-major which matches what you would expect when using conventional matrix math notation. - - I can't edit the mesh in edit-mode! === ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color Unpremultiply
Hi, The problem is that it's not actually true that this is always the correct thing to do. Ideally, you should never do color space conversion on images with alpha, because you can only really do it right after it has been composited over some background. If you're compositing over a black background, leaving this option off will give the exact correct result. If you're compositing over a lighter background, enabling it will likely give better results, but it's actually still not quite right then. It could be made so that it's enabled by default, since maybe it's more common to composite alpha images over a light background (e.g. for the web), but I don't think we should remove the option. Brecht. On Fri, Feb 17, 2012 at 9:04 PM, gespert...@gmail.com gespert...@gmail.com wrote: Hi. I have some questions regarding the new Color Unpremultiply option in Blender. I understand what it does, but I wonder if there isn't a more elegant or accurate way to expose it. First of all, the text in the tooltip is a little bit misleading. The operation performed isn't done to avoid a fringe on light backgrounds. It's done because colorspace conversions shouldn't be performed on premultiplied data. The resulting effect when doing it wrong is indeed a fringe, but what the operation does is to deliver a properly converted image, not avoiding a fringe. This may sound silly, but I think that using a more accurate tooltip would have an educational effect because people would know what it does or would investigate more rather than this is for reducing a fringe. A fringe can come from a wrong compositing earlier, and believing that color unpremultiply will fix it is wrong. Apart from that, I wonder if it's really necessary to have that option instead of just applying it whenever premultiplied alpha is selected and the output file is gamma-corrected. Actually, I wonder if Blender shouldn't use premultiplied or straight (graying out sky) when output is RGBA and conversely offer just sky when output is RGB. I don't know if blender's internals allow this, but it would simplify the UI a little and help to avoid some common mistakes caused by mere distraction. Apart from that it would have an educational value making easier to new users to choose the right values. Makes sense? ___ 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] UI/RNA question
While looking into this, I ran into the issue that currently you can't
tell which brush tool is in use with only a brush pointer -- it could
be the sculpt_tool, vertexpaint_tool, or imagepaint_tool.
I can see a couple possible solutions:
1) Simplest change is to have separate capability properties for the
different modes. Maybe have three nested structures in Brush RNA --
SculptCapabilities, VertexPaintCapabilities, ImagePaintCapabilities.
Each of these then gets boolean properties indicating support for
direction, stroke methods, etc.
2) As an alternative, we could change brushes to only be active in one
paint mode at a time. I've posted a patch
(http://codereview.appspot.com/5671088/) that does this. This feels
simpler to me, don't see that much value right now in having brushes
be accessible from different paint modes.
Thoughts?
-Nicholas
On Thu, Feb 16, 2012 at 11:35 PM, Jason Wilkins
jason.a.wilk...@gmail.com wrote:
I agree and this was the direction I wanted to go. My name for it was
going to be brush semantics.
Rather than have complex checks scattered throughout the code it would
be better to have something like, for example:
isBrushTypeMove()
isBrushIgnoresStrength()
isBrushTypeClay()
isBrushCanLayer()
Basically figure out what the name of the set X is when you say brush
element of set X
I called it semantics because I had some vague idea of some other
things that fit the same idea besides Boolean predicates.
On Thu, Feb 16, 2012 at 3:31 PM, Campbell Barton ideasma...@gmail.com wrote:
+1 for adding readonly, boolean properties (as proposed) rather than
checking brush type all over.
when there are many similar checks: if some.mode in {'A', 'B', 'C'} ...
these kinds of checks tend to get out of sync (devs modify in one
place but not others), if they can be generalized into bool props this
should be less error prone and more readable too.
On Fri, Feb 17, 2012 at 5:09 AM, Sergey Sharybin sergey@gmail.com
wrote:
Hi.
You can define RNA prop which isn't connected to any DNA property and
just write your own get/set function for it. Think it'll be much easier to
just point into sources rather than telling the same here.
So, you can open rna_tracking.c file and near line 963 you'll see a
definition of select property. It doesn't have DNA
analog.Functions rna_trackingTrack_select_get
and rna_trackingTrack_select_set are used to get/set vallue of this prop.
Think you shall just set NULL instead of set function and clear
PROP_EDITABLE flag for you prop. And in get function it'll be just
something like return ELEM(brush-type, CLAY, etcetcetc)
Thinks it'll be easiest way for you and will help keeping py code clear and
easy to follow.
On Thu, Feb 16, 2012 at 11:46 PM, Nicholas Bishop
nicholasbis...@gmail.comwrote:
I was looking today at updating the menus in sculpt/paint modes,
currently they are incomplete.
In sculpt especially right now, the toolbar UI has a lot of code like
this: if tool in {'CLAY', 'FLATTEN', 'FILL', ...}. I'd rather not
duplicate such code for menus. One option is to add more functions to
properties_paint_common.py, but I was wondering if it would be better
to make this information available through RNA? E.g. add read-only
boolean properties like has_direction, has_stroke_method, etc,
with a get function to check current tool and such.
Would appreciate guidance as to whether that's appropriate RNA usage,
or other options.
-Nicholas
___
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
--
- 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] UI/RNA question
In the future I'd like to be able to paint and sculpt at the same
time. Maybe it would be better if you made paint_mode into a set of
bit flags? Right now the brushes could be exclusive to one mode, but
in the future they could be combinations. Am I thinking too far
ahead? It would effect how you check the paind_mode, using along
with ==, which may be extra trouble if we decide in the future to
combine capabilities in a different way. Also, a lot of combinations
make no sense, like sculpting and weight paint...
Perhaps better to go with something simple until this is worked out.
On Fri, Feb 17, 2012 at 3:51 PM, Nicholas Bishop
nicholasbis...@gmail.com wrote:
While looking into this, I ran into the issue that currently you can't
tell which brush tool is in use with only a brush pointer -- it could
be the sculpt_tool, vertexpaint_tool, or imagepaint_tool.
I can see a couple possible solutions:
1) Simplest change is to have separate capability properties for the
different modes. Maybe have three nested structures in Brush RNA --
SculptCapabilities, VertexPaintCapabilities, ImagePaintCapabilities.
Each of these then gets boolean properties indicating support for
direction, stroke methods, etc.
2) As an alternative, we could change brushes to only be active in one
paint mode at a time. I've posted a patch
(http://codereview.appspot.com/5671088/) that does this. This feels
simpler to me, don't see that much value right now in having brushes
be accessible from different paint modes.
Thoughts?
-Nicholas
On Thu, Feb 16, 2012 at 11:35 PM, Jason Wilkins
jason.a.wilk...@gmail.com wrote:
I agree and this was the direction I wanted to go. My name for it was
going to be brush semantics.
Rather than have complex checks scattered throughout the code it would
be better to have something like, for example:
isBrushTypeMove()
isBrushIgnoresStrength()
isBrushTypeClay()
isBrushCanLayer()
Basically figure out what the name of the set X is when you say brush
element of set X
I called it semantics because I had some vague idea of some other
things that fit the same idea besides Boolean predicates.
On Thu, Feb 16, 2012 at 3:31 PM, Campbell Barton ideasma...@gmail.com
wrote:
+1 for adding readonly, boolean properties (as proposed) rather than
checking brush type all over.
when there are many similar checks: if some.mode in {'A', 'B', 'C'} ...
these kinds of checks tend to get out of sync (devs modify in one
place but not others), if they can be generalized into bool props this
should be less error prone and more readable too.
On Fri, Feb 17, 2012 at 5:09 AM, Sergey Sharybin sergey@gmail.com
wrote:
Hi.
You can define RNA prop which isn't connected to any DNA property and
just write your own get/set function for it. Think it'll be much easier to
just point into sources rather than telling the same here.
So, you can open rna_tracking.c file and near line 963 you'll see a
definition of select property. It doesn't have DNA
analog.Functions rna_trackingTrack_select_get
and rna_trackingTrack_select_set are used to get/set vallue of this prop.
Think you shall just set NULL instead of set function and clear
PROP_EDITABLE flag for you prop. And in get function it'll be just
something like return ELEM(brush-type, CLAY, etcetcetc)
Thinks it'll be easiest way for you and will help keeping py code clear and
easy to follow.
On Thu, Feb 16, 2012 at 11:46 PM, Nicholas Bishop
nicholasbis...@gmail.comwrote:
I was looking today at updating the menus in sculpt/paint modes,
currently they are incomplete.
In sculpt especially right now, the toolbar UI has a lot of code like
this: if tool in {'CLAY', 'FLATTEN', 'FILL', ...}. I'd rather not
duplicate such code for menus. One option is to add more functions to
properties_paint_common.py, but I was wondering if it would be better
to make this information available through RNA? E.g. add read-only
boolean properties like has_direction, has_stroke_method, etc,
with a get function to check current tool and such.
Would appreciate guidance as to whether that's appropriate RNA usage,
or other options.
-Nicholas
___
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
--
- 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
Re: [Bf-committers] UI/RNA question
Bit flags is indeed what brushes currently have (via the ob_mode field.)
To give an example of how this causes trouble, let's say I want to
check in RNA whether the direction (add/subtract) property is
supported. The brush's ob_mode flag indicates it's enabled in both
sculpt and vpaint. The sculpt tool is draw brush, but the vertexpaint
tool is the blur brush. The former supports direction, the latter does
not, so there's no way to get the correct answer without examining
context (specifically, the active object.)
-Nicholas
On Fri, Feb 17, 2012 at 7:52 PM, Jason Wilkins
jason.a.wilk...@gmail.com wrote:
In the future I'd like to be able to paint and sculpt at the same
time. Maybe it would be better if you made paint_mode into a set of
bit flags? Right now the brushes could be exclusive to one mode, but
in the future they could be combinations. Am I thinking too far
ahead? It would effect how you check the paind_mode, using along
with ==, which may be extra trouble if we decide in the future to
combine capabilities in a different way. Also, a lot of combinations
make no sense, like sculpting and weight paint...
Perhaps better to go with something simple until this is worked out.
On Fri, Feb 17, 2012 at 3:51 PM, Nicholas Bishop
nicholasbis...@gmail.com wrote:
While looking into this, I ran into the issue that currently you can't
tell which brush tool is in use with only a brush pointer -- it could
be the sculpt_tool, vertexpaint_tool, or imagepaint_tool.
I can see a couple possible solutions:
1) Simplest change is to have separate capability properties for the
different modes. Maybe have three nested structures in Brush RNA --
SculptCapabilities, VertexPaintCapabilities, ImagePaintCapabilities.
Each of these then gets boolean properties indicating support for
direction, stroke methods, etc.
2) As an alternative, we could change brushes to only be active in one
paint mode at a time. I've posted a patch
(http://codereview.appspot.com/5671088/) that does this. This feels
simpler to me, don't see that much value right now in having brushes
be accessible from different paint modes.
Thoughts?
-Nicholas
On Thu, Feb 16, 2012 at 11:35 PM, Jason Wilkins
jason.a.wilk...@gmail.com wrote:
I agree and this was the direction I wanted to go. My name for it was
going to be brush semantics.
Rather than have complex checks scattered throughout the code it would
be better to have something like, for example:
isBrushTypeMove()
isBrushIgnoresStrength()
isBrushTypeClay()
isBrushCanLayer()
Basically figure out what the name of the set X is when you say brush
element of set X
I called it semantics because I had some vague idea of some other
things that fit the same idea besides Boolean predicates.
On Thu, Feb 16, 2012 at 3:31 PM, Campbell Barton ideasma...@gmail.com
wrote:
+1 for adding readonly, boolean properties (as proposed) rather than
checking brush type all over.
when there are many similar checks: if some.mode in {'A', 'B', 'C'} ...
these kinds of checks tend to get out of sync (devs modify in one
place but not others), if they can be generalized into bool props this
should be less error prone and more readable too.
On Fri, Feb 17, 2012 at 5:09 AM, Sergey Sharybin sergey@gmail.com
wrote:
Hi.
You can define RNA prop which isn't connected to any DNA property and
just write your own get/set function for it. Think it'll be much easier to
just point into sources rather than telling the same here.
So, you can open rna_tracking.c file and near line 963 you'll see a
definition of select property. It doesn't have DNA
analog.Functions rna_trackingTrack_select_get
and rna_trackingTrack_select_set are used to get/set vallue of this prop.
Think you shall just set NULL instead of set function and clear
PROP_EDITABLE flag for you prop. And in get function it'll be just
something like return ELEM(brush-type, CLAY, etcetcetc)
Thinks it'll be easiest way for you and will help keeping py code clear
and
easy to follow.
On Thu, Feb 16, 2012 at 11:46 PM, Nicholas Bishop
nicholasbis...@gmail.comwrote:
I was looking today at updating the menus in sculpt/paint modes,
currently they are incomplete.
In sculpt especially right now, the toolbar UI has a lot of code like
this: if tool in {'CLAY', 'FLATTEN', 'FILL', ...}. I'd rather not
duplicate such code for menus. One option is to add more functions to
properties_paint_common.py, but I was wondering if it would be better
to make this information available through RNA? E.g. add read-only
boolean properties like has_direction, has_stroke_method, etc,
with a get function to check current tool and such.
Would appreciate guidance as to whether that's appropriate RNA usage,
or other options.
-Nicholas
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
--
With best regards,
Re: [Bf-committers] UI/RNA question
I think you'll have to drill down more because I'm not sure I see the problem.
If the brush is enabled for both vpaint and sculpt modes then
direction is supported for sculpting.
Currently I do not think any brushes should be enabled for multiple
modes because we do not support that. If a brush has both bits set
then it shouldn't be usable in any mode.
If/When we enable brushes for multiple modes simultaneously we might
need to split the direction field into multiple fields for each mode.
It has been a while since I've been in the code, so maybe I'm seeing this wrong.
On Fri, Feb 17, 2012 at 7:06 PM, Nicholas Bishop
nicholasbis...@gmail.com wrote:
Bit flags is indeed what brushes currently have (via the ob_mode field.)
To give an example of how this causes trouble, let's say I want to
check in RNA whether the direction (add/subtract) property is
supported. The brush's ob_mode flag indicates it's enabled in both
sculpt and vpaint. The sculpt tool is draw brush, but the vertexpaint
tool is the blur brush. The former supports direction, the latter does
not, so there's no way to get the correct answer without examining
context (specifically, the active object.)
-Nicholas
On Fri, Feb 17, 2012 at 7:52 PM, Jason Wilkins
jason.a.wilk...@gmail.com wrote:
In the future I'd like to be able to paint and sculpt at the same
time. Maybe it would be better if you made paint_mode into a set of
bit flags? Right now the brushes could be exclusive to one mode, but
in the future they could be combinations. Am I thinking too far
ahead? It would effect how you check the paind_mode, using along
with ==, which may be extra trouble if we decide in the future to
combine capabilities in a different way. Also, a lot of combinations
make no sense, like sculpting and weight paint...
Perhaps better to go with something simple until this is worked out.
On Fri, Feb 17, 2012 at 3:51 PM, Nicholas Bishop
nicholasbis...@gmail.com wrote:
While looking into this, I ran into the issue that currently you can't
tell which brush tool is in use with only a brush pointer -- it could
be the sculpt_tool, vertexpaint_tool, or imagepaint_tool.
I can see a couple possible solutions:
1) Simplest change is to have separate capability properties for the
different modes. Maybe have three nested structures in Brush RNA --
SculptCapabilities, VertexPaintCapabilities, ImagePaintCapabilities.
Each of these then gets boolean properties indicating support for
direction, stroke methods, etc.
2) As an alternative, we could change brushes to only be active in one
paint mode at a time. I've posted a patch
(http://codereview.appspot.com/5671088/) that does this. This feels
simpler to me, don't see that much value right now in having brushes
be accessible from different paint modes.
Thoughts?
-Nicholas
On Thu, Feb 16, 2012 at 11:35 PM, Jason Wilkins
jason.a.wilk...@gmail.com wrote:
I agree and this was the direction I wanted to go. My name for it was
going to be brush semantics.
Rather than have complex checks scattered throughout the code it would
be better to have something like, for example:
isBrushTypeMove()
isBrushIgnoresStrength()
isBrushTypeClay()
isBrushCanLayer()
Basically figure out what the name of the set X is when you say brush
element of set X
I called it semantics because I had some vague idea of some other
things that fit the same idea besides Boolean predicates.
On Thu, Feb 16, 2012 at 3:31 PM, Campbell Barton ideasma...@gmail.com
wrote:
+1 for adding readonly, boolean properties (as proposed) rather than
checking brush type all over.
when there are many similar checks: if some.mode in {'A', 'B', 'C'} ...
these kinds of checks tend to get out of sync (devs modify in one
place but not others), if they can be generalized into bool props this
should be less error prone and more readable too.
On Fri, Feb 17, 2012 at 5:09 AM, Sergey Sharybin sergey@gmail.com
wrote:
Hi.
You can define RNA prop which isn't connected to any DNA property and
just write your own get/set function for it. Think it'll be much easier
to
just point into sources rather than telling the same here.
So, you can open rna_tracking.c file and near line 963 you'll see a
definition of select property. It doesn't have DNA
analog.Functions rna_trackingTrack_select_get
and rna_trackingTrack_select_set are used to get/set vallue of this prop.
Think you shall just set NULL instead of set function and clear
PROP_EDITABLE flag for you prop. And in get function it'll be just
something like return ELEM(brush-type, CLAY, etcetcetc)
Thinks it'll be easiest way for you and will help keeping py code clear
and
easy to follow.
On Thu, Feb 16, 2012 at 11:46 PM, Nicholas Bishop
nicholasbis...@gmail.comwrote:
I was looking today at updating the menus in sculpt/paint modes,
currently they are incomplete.
In sculpt especially right now, the toolbar UI has a lot of code like
this: if tool
Re: [Bf-committers] UI/RNA question
If the brush is enabled for both vpaint and sculpt modes then direction is supported for sculpting. Right, this is indeed fine if we define the properties to be specific to a single mode. Then (in Python) we can do Brush.sculpt_capabilities.direction, or Brush.vertexpaint_capabilities.direction. I was simply suggesting we simplify this down to Brush.has_direction -- a change that would require the brush to know which of its tools is active. Currently I do not think any brushes should be enabled for multiple modes because we do not support that. If a brush has both bits set then it shouldn't be usable in any mode. Our current default .blend does include brushes enabled in multiple modes (BRDraw is in all modes.) -Nicholas ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
