Re: [Bf-committers] making CurveMapping objects editable from Python
On Mon, Jan 17, 2011 at 8:38 PM, Stephen Swaney wrote: > On Mon, Jan 17, 2011 at 04:17:27AM -0700, Dan Eicher wrote: >> I did a patch for this a while back but it was rejected for reasons I >> can't remember now. >> >> http://www.pasteall.org/18339/diff > > Reasons we submit patches to the patch tracker are so > > * they do not get overlooked or forgotten > > * they can be discussed > > * problems can be corrected > > Just a thought... > -- > Stephen Swaney > sswa...@centurytel.net > Pretty sure I did submit it just too lazy to search (and it was easier to pasteall it). Or maybe not, either way still too lazy to search... ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] color wheel upside down
> Look at Blender ones, the red is at the bottom, while all in that page > put it at the top or the right side, following typical starts for > clocks or angles (resp.). That is what he is pointing, that Blender is > yet another style with hard to explain "0 points down". As opposed to 0 being lower left or middle right? There certainly is no such thing as a standard here from what research is available. > And if the video scopes do something else as he pointed, that is > really bad, because it is inconsistent with itself and only causes > headaches. Agree. Xat and Matt would be able to help on the reasoning behind the scopes. Unifying the wheel orientations for internal consistency makes solid design sense. As to models to follow, it comes down to audience. If the audience is a grading specialist, probably following Resolve or Lustre makes sense. Just throwing it out there... Lustre: http://download.autodesk.com/us/systemdocs/help/2010/Lustre2010/help/images/MED/Lustre/Help/English/primary_colour_grading/ink_svg/PR_lin.png Avid: http://digitalfilms.files.wordpress.com/2010/03/blg_wheels_avid_1.jpg Davinci Resolve: http://www.digitalcontentproducer.com/mag/510MIL_BetaSight-daVinci1.jpg ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] color wheel upside down
Hi, troy.sobo...@gmail.com (2011-01-17 at 1952.47 -0800): > > Would it be possible to display the color wheels "correctly" ? I actually > > don't know if there is a correct or wrong way, I guess not, but to me it is > > upside down. > > Which one is correct? > > http://www.willrosecrans.com/blog/2010/09/color-wheels/ Look at Blender ones, the red is at the bottom, while all in that page put it at the top or the right side, following typical starts for clocks or angles (resp.). That is what he is pointing, that Blender is yet another style with hard to explain "0 points down". If anybody knows the vital reason to do it, better document it ASAP. And if the video scopes do something else as he pointed, that is really bad, because it is inconsistent with itself and only causes headaches. One of the two will have to change, that has no way to be reasoned. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] color wheel upside down
> Would it be possible to display the color wheels "correctly" ? I actually > don't know if there is a correct or wrong way, I guess not, but to me it is > upside down. Which one is correct? http://www.willrosecrans.com/blog/2010/09/color-wheels/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] making CurveMapping objects editable from Python
On Mon, Jan 17, 2011 at 04:17:27AM -0700, Dan Eicher wrote: > I did a patch for this a while back but it was rejected for reasons I > can't remember now. > > http://www.pasteall.org/18339/diff Reasons we submit patches to the patch tracker are so * they do not get overlooked or forgotten * they can be discussed * problems can be corrected Just a thought... -- Stephen Swaney sswa...@centurytel.net ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] ASC-CDL Saturation Node
Hey Blender Coders,
The attached patch introduces a new node called "ASC-CDL Saturation"
that implements the saturation function as discribed by the ASC Color
Decision List (ASC CDL) Transfer Functions and Interchange Syntax
(v1.2) spec.
This is the first patch I've ever done, so there may be some cargo
cult programming as I have based the node on CMP_gamma.c and the
registration of it on various commits. Also, the algorithm is adapted
from the ASC-CDL reference code.
There is one caviate however. The output from blender does not match
the reference spec. I suspect that this is due to some issue with
blender's image or color management. That said, the node still does a
"good enough" job of desaturating an image.
I have attached an image showing the discrepancy on the patch tracker.
http://projects.blender.org/tracker/index.php?func=detail&aid=25695&group_id=9&atid=127
Cheers,
Andrew
=== modified file 'source/blender/blenkernel/BKE_node.h'
--- source/blender/blenkernel/BKE_node.h 2010-12-04 13:00:28 +
+++ source/blender/blenkernel/BKE_node.h 2011-01-17 23:52:27 +
@@ -361,6 +361,7 @@
#define CMP_NODE_COLOR_MATTE 259
#define CMP_NODE_COLORBALANCE 260
#define CMP_NODE_HUECORRECT 261
+#define CMP_NODE_SATURATION 262
#define CMP_NODE_GLARE 301
#define CMP_NODE_TONEMAP 302
=== modified file 'source/blender/blenkernel/intern/node.c'
--- source/blender/blenkernel/intern/node.c 2011-01-08 11:08:51 +
+++ source/blender/blenkernel/intern/node.c 2011-01-18 01:15:08 +
@@ -3229,6 +3229,7 @@
nodeRegisterType(ntypelist, &cmp_node_zcombine);
nodeRegisterType(ntypelist, &cmp_node_colorbalance);
nodeRegisterType(ntypelist, &cmp_node_huecorrect);
+ nodeRegisterType(ntypelist, &cmp_node_saturation);
nodeRegisterType(ntypelist, &cmp_node_normal);
nodeRegisterType(ntypelist, &cmp_node_curve_vec);
=== modified file 'source/blender/makesdna/DNA_node_types.h'
--- source/blender/makesdna/DNA_node_types.h 2010-08-25 02:18:37 +
+++ source/blender/makesdna/DNA_node_types.h 2011-01-18 00:00:22 +
@@ -324,6 +324,10 @@
float uspillr, uspillg, uspillb;
}NodeColorspill;
+typedef struct NodeSaturation {
+ double luma;
+} NodeSaturation;
+
/* TEX_output */
typedef struct TexNodeOutput {
char name[32];
=== modified file 'source/blender/makesrna/intern/rna_nodetree.c'
--- source/blender/makesrna/intern/rna_nodetree.c 2011-01-16 18:38:54 +
+++ source/blender/makesrna/intern/rna_nodetree.c 2011-01-18 00:24:02 +
@@ -2200,6 +2200,11 @@
RNA_def_property_update(prop, NC_NODE|NA_EDITED, "rna_Node_update");
}
+static void def_cmp_saturation(StructRNA *srna)
+{
+
+}
+
static void def_cmp_zcombine(StructRNA *srna)
{
PropertyRNA *prop;
=== modified file 'source/blender/makesrna/intern/rna_nodetree_types.h'
--- source/blender/makesrna/intern/rna_nodetree_types.h 2010-12-13 21:17:00 +
+++ source/blender/makesrna/intern/rna_nodetree_types.h 2011-01-18 00:25:17 +
@@ -109,6 +109,7 @@
DefNode( CompositorNode, CMP_NODE_DIST_MATTE, def_cmp_distance_matte, "DISTANCE_MATTE", DistanceMatte,"Distance Matte","" )
DefNode( CompositorNode, CMP_NODE_COLORBALANCE, def_cmp_colorbalance, "COLORBALANCE", ColorBalance, "Color Balance", "" )
DefNode( CompositorNode, CMP_NODE_HUECORRECT, def_cmp_huecorrect, "HUECORRECT", HueCorrect, "Hue Correct", "" )
+DefNode( CompositorNode, CMP_NODE_SATURATION, def_cmp_saturation, "SATURATION", Saturation, "ASC-CDL Saturation", "" )
DefNode( TextureNode,TEX_NODE_OUTPUT, def_tex_output, "OUTPUT", Output, "Output","" )
DefNode( TextureNode,TEX_NODE_CHECKER,0, "CHECKER",Checker, "Checker", "" )
=== modified file 'source/blender/nodes/CMP_node.h'
--- source/blender/nodes/CMP_node.h 2010-02-12 13:34:04 +
+++ source/blender/nodes/CMP_node.h 2011-01-18 00:06:07 +
@@ -61,6 +61,7 @@
extern bNodeType cmp_node_zcombine;
extern bNodeType cmp_node_colorbalance;
extern bNodeType cmp_node_huecorrect;
+extern bNodeType cmp_node_saturation;
extern bNodeType cmp_node_normal;
extern bNodeType cmp_node_curve_vec;
=== modified file 'source/blender/nodes/CMakeLists.txt'
--- source/blender/nodes/CMakeLists.txt 2010-12-22 23:09:30 +
+++ source/blender/nodes/CMakeLists.txt 2011-01-18 01:14:32 +
@@ -85,6 +85,7 @@
intern/CMP_nodes/CMP_sepcombYUVA.c
intern/CMP_nodes/CMP_setalpha.c
intern/CMP_nodes/CMP_splitViewer.c
+ intern/CMP_nodes/CMP_sat.c
intern/CMP_nodes/CMP_texture.c
intern/CMP_nodes/CMP_tonemap.c
intern/CMP_nodes/CMP_translate.c
=== added file 'source/blender/nodes/intern/CMP_nodes/CMP_sat.c'
--- source/blender/nodes/intern/CMP_nodes/CM
Re: [Bf-committers] Problem compiling under Win32 with scons (SHARD_PATHA in GHOST_SystemPathsWin32.cpp)
> Thanks for reporting, I overlooked that the define wasn't available for > mingw. I have added the missing #defines for mingw, so hopefully you > should be able to compile again. Sorry for the inconvenience. > > - Andrea Thank you for the fix, I'll check again ASAP (probably tomorrow). Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Problem compiling under Win32 with scons (SHARD_PATHA in GHOST_SystemPathsWin32.cpp)
Hello Martin, > I recently got back from a short hiatus from Blender and noticed that I can't > compile under Windows/scons anymore. > > GHOST seems to use a new define (SHARD_PATHA), that doesn't actually seem to > be defined anywhere (that I can find). > Thanks for reporting, I overlooked that the define wasn't available for mingw. I have added the missing #defines for mingw, so hopefully you should be able to compile again. Sorry for the inconvenience. - Andrea ___ 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 [34184] trunk/blender/source/blenderplayer /bad_level_call_stubs/stubs.c: stubs.c updates provided by Kupoman.
poke.
I'll be more on IRC from now on, so if not by email I'll try to contact you
there.
2011/1/8 Dalai Felinto
> why the "#if 1" ??
> Iirc those are the entries that have to be commented out to compile with
> msvc+cmake. I'm not sure there is a #if NOT WINCMAKE or similar. Though
> I don't think this would be the correct solution (as in why cmake+msvc fails
> but not scons+msvc or cmake+gcc)
>
> -- Dalai
>
> 2011/1/9 Mitchell Stokes
>
> Revision: 34184
>>
>> http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=34184
>> Author: moguri
>> Date: 2011-01-09 02:43:26 + (Sun, 09 Jan 2011)
>> Log Message:
>> ---
>> stubs.c updates provided by Kupoman.
>>
>> Modified Paths:
>> --
>>trunk/blender/source/blenderplayer/bad_level_call_stubs/stubs.c
>>
>> Modified: trunk/blender/source/blenderplayer/bad_level_call_stubs/stubs.c
>> ===
>> --- trunk/blender/source/blenderplayer/bad_level_call_stubs/stubs.c
>> 2011-01-09 01:17:56 UTC (rev 34183)
>> +++ trunk/blender/source/blenderplayer/bad_level_call_stubs/stubs.c
>> 2011-01-09 02:43:26 UTC (rev 34184)
>> @@ -263,6 +263,11 @@
>> void ED_object_constraint_update(struct Object *ob){}
>> struct bDeformGroup *ED_vgroup_add_name(struct Object *ob, char
>> *name){return (struct bDeformGroup *) NULL;}
>> void ED_vgroup_vert_add(struct Object *ob, struct bDeformGroup *dg, int
>> vertnum, float weight, int assignmode){}
>> +void ED_vgroup_vert_remove(struct Object *ob, struct bDeformGroup *dg,
>> int vertnum){}
>> +void ED_vgroup_vert_weight(struct Object *ob, struct bDeformGroup *dg,
>> int vertnum){}
>> +void ED_vgroup_delete(struct Object *ob, struct bDeformGroup *defgroup){}
>> +void ED_vgroup_object_is_edit_mode(struct Object *ob){}
>> +
>> void ED_sequencer_update_view(struct bContext *C, int view){}
>> float ED_rollBoneToVector(struct EditBone *bone, float
>> new_up_axis[3]){return 0.0f;}
>> void ED_space_image_size(struct SpaceImage *sima, int *width, int
>> *height){}
>> @@ -379,10 +384,12 @@
>> struct wmKeyMap *WM_modalkeymap_add(struct wmKeyConfig *keyconf, char
>> *idname, EnumPropertyItem *items){return (struct wmKeyMap *) NULL;}
>>
>> /* intern/decimation */
>> +#if 1
>> int LOD_FreeDecimationData(struct LOD_Decimation_Info *info){return 0;}
>> int LOD_CollapseEdge(struct LOD_Decimation_Info *info){return 0;}
>> int LOD_PreprocessMesh(struct LOD_Decimation_Info *info){return 0;}
>> int LOD_LoadMesh(struct LOD_Decimation_Info *info){return 0;}
>> +#endif
>>
>> /* smoke */
>> void LzmaCompress(void) { return; }
>> @@ -428,6 +435,7 @@
>> char blender_path[] = "";
>>
>> /* CSG */
>> +#if 1
>> struct CSG_BooleanOperation * CSG_NewBooleanFunction( void ){return
>> (struct CSG_BooleanOperation *) NULL;}
>> void CSG_FreeBooleanOperation(struct CSG_BooleanOperation
>> *operation){return;}
>> void CSG_FreeFaceDescriptor(struct CSG_FaceIteratorDescriptor *
>> f_descriptor){return;}
>> @@ -448,4 +456,5 @@
>>CSG_VertexIteratorDescriptorobBVertices)
>>{ return 0;}
>>
>> +#endif
>> #endif // WITH_GAMEENGINE
>>
>> ___
>> Bf-blender-cvs mailing list
>> bf-blender-...@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-blender-cvs
>>
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] color wheel upside down
Hi, I have been meaning to ask that for a while now (actually maybe I already did and don't remember). Would it be possible to display the color wheels "correctly" ? I actually don't know if there is a correct or wrong way, I guess not, but to me it is upside down. Maybe there is a good reason for that. But I think it would be more intuitive to have it like the vector scope way. Because right now I have to twist my mind to go the other way around each time I'm grading by looking at the scopes, and some how it doesn't feel natural and doesn't look really consistent as well. Is there a special reason for it to be display in that matter ? F ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Removing auto registration
--- On Mon, 1/17/11, Campbell Barton wrote: > Agree panel order shouldn't be a > factor in this discussion, it should > be solved irrespective of registration so addons panels can > be added in a logical order. Ideally, this should be done before going out of beta. > Though I'm still for auto-registration removal even if its > bug free, > most likely re-iterating from previous mails. It's not so much the reiteration of your same arguments that bugs me but the fact that you've completely ignored the problems with the registration order and properties registration that I've highlighted many times and that has to be dealt with regardless of the registration method if we want to correctly and cleanly handle enabling and disabling addons (which you seem to think is an argument for manual registration but is completely irrelevant). > - to me it feels mysterious that blender is operating on > classes > without being asked & errors don't trace back to > authors code. The traceback issue can be fixed quite simply. The Metaclass has more info than manual registration on the class definition itself (you can have the file and line where the class is defined if that's what you want). As for blender operating on classes without being asked, that's the whole point of inheritance. > - in simple cases where all classes are registered its not > a big win > to have it automatic, in complicated cases of dynamic > runtime registration this gets in the way. Yes, you did raise that point last time, it was bunk back then too. Can you show an example of dynamic runtime registration that deals correctly with registration order and unregistration without making a truckload of assumptions or not working at all? Registration order is tightly coupled with internal workings of Blender, exposing that to python is completely ridiculous. > - it makes internals more complicated we need to support - > 3 cases: > direct execution, modules and addons. There's only two cases, runtime execution and delayed execution. Modules are addons that are registered automatically after definition. > - Matt Ebb and Nathan Vegdahl have complained about > auto-registration > in its current state fir renderman support which does > dynamic > generated classes from shaders, and rigify for rig types. Didn't I addressed Nathan's issues last time? There's nothing about autoregistration that prevents runtime definition of classes. > It is regrettable that I accepted this patch in the first > place, but I > felt some obligation to do so since Martin addressed the > issues that > concerned me, also because Brecht and Andria also approved > of this > functionality at the time. It's regrettable that I tried to address the real problems two months ago, after which you said you'd have to look into it yourself and never came back until now, trying to force a decision again. It's regrettable that you think autoregistration is an opaque black box just because there's the word metaclass in there. But most of all, it's regrettable that you think shoving that back in the ands of python developers will solve all problems magically when in fact it means having to write more documentation with warnings all over the place about proper registration order. Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Problem compiling under Win32 with scons (SHARD_PATHA in GHOST_SystemPathsWin32.cpp)
I recently got back from a short hiatus from Blender and noticed that I can't compile under Windows/scons anymore. GHOST seems to use a new define (SHARD_PATHA), that doesn't actually seem to be defined anywhere (that I can find). >SNIP> ... ... scons: Building targets ... scons: `source\lib\libbf_intern_audaspace.a' is up to date. scons: `source\lib\libbf_intern_string.a' is up to date. Compiling ==> 'GHOST_SystemPathsWin32.cpp' intern\ghost\intern\GHOST_SystemPathsWin32.cpp: In member function `virtual void GHOST_SystemPathsWin32::addToSystemRecentFiles(const char*) const': intern\ghost\intern\GHOST_SystemPathsWin32.cpp:86: error: `SHARD_PATHA' was not declared in this scope intern\ghost\intern\GHOST_SystemPathsWin32.cpp:86: warning: unused variable 'SHARD_PATHA' scons: *** [source\intern\ghost\intern\GHOST_SystemPathsWin32.o] Error 1 scons: building terminated because of errors. http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=34099 Thanks for any help, Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] making CurveMapping objects editable from Python
I did a patch for this a while back but it was rejected for reasons I can't remember now. http://www.pasteall.org/18339/diff ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
