[Bf-committers] RGBA compositing preview missing
Hey, Did something bad happen to RGBA previews of compositing output or some setting has been added to make it possible to view RGBA? Should it be reported as a bug? (Another thing is that even when we had RGBA previews they were wrong… http://wiki.blender.org/index.php/User:Bartekskorupa/Display_Issues ) Here's a screenshot of what I mean: http://www.pasteall.org/pic/70278 It work this way in build of April 24, 2014, HASH: 3bcc9ee In official 270a it works well. Thanks for any info. Cheers Bartek Skorupa www.bartekskorupa.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] RGBA compositing preview missing
Hey, Thanks. I didn't notice. Sorry for that then. Cheers, Bartek Skorupa www.bartekskorupa.com On 24 kwi 2014, at 14:42, Kévin Dietrich wrote: > > > Hi Bartek, > > This issue has reported a couple of times. > > See developer.blender.org/T39799 > > Kévin. > > Le 2014-04-24 14:35, Bartek Skorupa (priv) a écrit : > >> Hey, >> >> Did something bad happen to RGBA previews of compositing output or some >> setting has been added to make it possible to view RGBA? >> Should it be reported as a bug? >> (Another thing is that even when we had RGBA previews they were wrong… >> http://wiki.blender.org/index.php/User:Bartekskorupa/Display_Issues [1] ) >> >> Here's a screenshot of what I mean: >> http://www.pasteall.org/pic/70278 [2] >> >> It work this way in build of April 24, 2014, HASH: 3bcc9ee >> In official 270a it works well. >> >> Thanks for any info. >> >> Cheers >> Bartek Skorupa >> >> www.bartekskorupa.com [3] >> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers [4] > > > > Links: > -- > [1] http://wiki.blender.org/index.php/User:Bartekskorupa/Display_Issues > [2] http://www.pasteall.org/pic/70278 > [3] http://www.bartekskorupa.com > [4] 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] Color picker redesign, continued
Hey, I was wondering if the discussion about HSV values is still ongoing or the decision has been made to leave it as is? I'd like to refer to this part of Antony's post: > Sadly, we ran into issues: > > First, it is a common workflow for people to tweak HSV values in linear > space. Especially on rendering this helps with giving an upper bound to > radiance reflected back from a material, by tweaking the color value. I am one of those who kept using V of HSV model to specify the color values in linear space. Now it requires several unnecessary steps to be able to do it, so I was wondering if the way of setting colors using HSV will stay as is or it's going to be changed? Thank you. Bartek Skorupa www.bartekskorupa.com On 19 cze 2014, at 20:31, Antony Riakiotakis wrote: > Hi, > > In the 2.71 release I have unfortunately caused a small disturbance due to > my decision to change the HSV setting in color wheels to be in display > space. > > Some explanation is due: This was to address an important issue of color > pickers, which was that you never got the exact color you chose, especially > for linear color properties. > > The issue here, is that the color displayed is calculated by first doing a > non-linear transform (linear to srgb usually) followed by the linear > transform (barycentric interpolation on the rasterized triangle), while the > value calculated if we do the HSV calculation in linear space, is first > interpolation in HSV (linear interpolation for each "piece" of the HSV > circle) followed by the non-linear interpolation. It is only natural that > those two values will differ due to linear and non linear transforms not > being commutative. > > The solution I have chosen for the 2.71 version is to make sure all HSV > values are in display space. This guarantees we always get the correct > color, which can then be transformed back to the linear space. > > Sadly, we ran into issues: > > First, it is a common workflow for people to tweak HSV values in linear > space. Especially on rendering this helps with giving an upper bound to > radiance reflected back from a material, by tweaking the color value. > > Also for values greater than one, the non linear transform back to linear > rgb can give very bizzare results (See https://developer.blender.org/T40131) > > Apparently we must do the interpolation in the property space, and then use > a per pixel transform (easily done by binding a pixel shader through OCIO) > to correct the result for display. > > However, we also have another use case which is still not correct enough > and that gave rise to some discussions. > > Apparently, it is beneficial to do the calculation on a different > intermediate space. > This is already done in our "Cubic" style color pickers which -still- > suffer from incorrect display of colors. Generally it may be that, in fact, > many spaces might be disarable as an intermediate calculation space. This > can be hardcoded but can also be configured, through a color picker role > for instance. > > In such a workflow, HSV is still calculated in this intermediate space (I > am still unsure if HSV is defined exactly the same for each space though, > which would complicate things), the final display is calculated from pixel > shading and the selected color is taken by transforming from HSV to > intermediate space to initial color space. > > Just hooking a display shader for linear properties can work for solving > the current issues, but I was wondering if fixing this might present an > opportunity to take more issues into account. > ___ > 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] Make Parent - shouldn't it work differently?
Hi everyone, I'd like to discuss the issue that I encounter every time I want to make a simple parenting structure of objects: Let's parent object A to object B. Select A, then select B, and hit Ctl-P. Here's what happens: "A" didn't change its visual transformations, it stayed exactly where it was before, it's visual rotation and scale didn't change as well. However now it is a child of B, so it should use B's co-ordinates as its center of the world. If "A" stayed where it was before - its transform properties should change to reflect it's position, rotation and scale in relation to "B", right? This isn't happening. "A"'s transform properties remained untouched. When we clear origin (alt-O) - "A" moves to location of "B". It's transform properties din't change. Now they represent co-ordinates in relation to …. exactly …. to "no-one-knows-what". There is of-course the option to parent objects using Shift-Ctl-P. This creates proper relation between "A"'s transform properties and its visual transformations, but it as well moves "A" to "B"'s location and it's not always the desired result. There is no easy way to make "true" parent. It would be great if after hitting Ctl-P - child stayed where it is, but its transform properties would be recalculated such that they represent transformations in relation to parent. Hitting Shift-Ctl-P should in my opinion make parent, leave transform properties of the child untouched, but move, rotate and scale the child such that now it's transformed properly in relation to its parent. I find it easier to create proper parenting structure using python, than keyboard shortcuts. Is there anyone else who feels the same? What do you think? Cheers Bartek Skorupa ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Make Parent - shouldn't it work differently?
In order to get "proper" parenting I use a little script: active = bpy.context.active_object selected = boy.context.selected_objects for c in selected: if c =! active: m = c.matrix_world c.parent = active c.matrix_world = m This gives me the behavior that I'd like to have under Ctl-P The behavior that I'd like to have under Shift-Ctl-P would be this: active = bpy.context.active_object selected = boy.context.selected_objects for c in selected: if c =! active: c.parent = active Cheers Bartek Skorupa www.bartekskorupa.com On 21 wrz 2012, at 11:08, Remigiusz Fiedler wrote: > oops, haven't read your post to the end > >> There is of-course the option to parent objects using Shift-Ctl-P. This >> creates >> proper relation between "A"'s transform properties and its visual >> transformations, >> but it as well moves "A" to "B"'s location and it's not always the desired >> result. > ___ > 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] Make Parent - shouldn't it work differently?
Yes, yes, I know… I made a mistake: it should be: if c != active: :-) Bartek Skorupa www.bartekskorupa.com On 21 wrz 2012, at 11:49, Bartek Skorupa (priv) wrote: > In order to get "proper" parenting I use a little script: > > > active = bpy.context.active_object > selected = boy.context.selected_objects > for c in selected: > if c =! active: > m = c.matrix_world > c.parent = active > c.matrix_world = m > > > This gives me the behavior that I'd like to have under Ctl-P > > > The behavior that I'd like to have under Shift-Ctl-P would be this: > > > active = bpy.context.active_object > selected = boy.context.selected_objects > for c in selected: > if c =! active: > c.parent = active > > > Cheers > Bartek Skorupa > > www.bartekskorupa.com > > On 21 wrz 2012, at 11:08, Remigiusz Fiedler wrote: > >> oops, haven't read your post to the end >> >>> There is of-course the option to parent objects using Shift-Ctl-P. This >>> creates >>> proper relation between "A"'s transform properties and its visual >>> transformations, >>> but it as well moves "A" to "B"'s location and it's not always the desired >>> result. >> ___ >> 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] Make Parent - shouldn't it work differently?
Ctl-Alt-P ?? When I hit it I get a warning: "Can only make proxy for a referenced object or group" What do I miss? Bartek Skorupa www.bartekskorupa.com On 21 wrz 2012, at 17:06, Nathan Vegdahl wrote: > A transform stack has got my vote. :-) > > Realistically that's probably still a ways off, though. > >> As for the current behaviour, if you: >> ctrl p >> then >> ctrl alt p - clear inverse parent >> i believe you'll have what you want. Not sure if there is an operator that >> just does that > > It wouldn't be hard to script up an operator using those two operators. > > --Nathan > > > > > On Fri, Sep 21, 2012 at 7:16 AM, Bassam Kurdali wrote: >> What i would like to see here is stack based (modo) or nodal (maya) >> transforms- that way you could: >> >> expose inverse parent transform >> get rid of hard coded dx dy dz transforms >> expose constraint offset transforms, and simplify constraints >> expose child of constraint >> freeze transforms ala maya by popping a transform onto stack >> stack as many offsets as you need for rigging >> get rid of hard coded transform/constraint order of evaluation >> get rid of confusion that hidden transforms cause >> make all hidden transforms editable >> >> some of the benefits I list assume of course that constraints and perhaps >> parenting are also in the stack/node tree. Most of the previous list is not >> currently possible. >> >> As for the current behaviour, if you: >> ctrl p >> then >> ctrl alt p - clear inverse parent >> i believe you'll have what you want. Not sure if there is an operator that >> just does that (though editing the parent property in the properties editor >> does. Does it have copy to selected? ) >> >> the default behaviour should be kept, of course. Most users want this. >> >> On Fri Sep 21 2012 05:08:08 AM EDT, Remigiusz Fiedler wrote: >> >>> oops, haven't read your post to the end >>> There is of-course the option to parent objects using Shift-Ctl-P. This creates proper relation between "A"'s transform properties and its visual transformations, but it as well moves "A" to "B"'s location and it's not always the desired result. >>> ___ >>> 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] Make Parent - shouldn't it work differently?
Thank you. However we are only half way there. It solves the major issue as we at least don't have weird properties of the child. The question still remains: How to make a parent such that the child stays at it's current location, rotation and scale, but the values of loc/rot/scale change. This is what should happen by default. @Bassam Kurdali: You wrote: > the default behaviour should be kept, of course. Most users want this. I wouldn't agree with that. I'm scratching my head trying to figure out at least one benefit of current default behavior and can't find anything. Is there any good reason for destroying the order in the scene? Having objects with locations, rotations and scales set in relation to who-the-hell-knows what? What do I miss? Bartek Skorupa www.bartekskorupa.com On 21 wrz 2012, at 20:44, Remigiusz Fiedler wrote: > no ctrl needed, it is "alt p - clear inverse parent" > > 2012/9/21 Bartek Skorupa (priv) : >> Ctl-Alt-P ?? >> When I hit it I get a warning: "Can only make proxy for a referenced object >> or group" >> What do I miss? >> > ___ > 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] Make Parent - shouldn't it work differently?
In one of the previous posts I explained what I do to get proper relation between parent and child and not to lose the position, rotation and scale of the child at the moment of parenting. The script that I use does this: 1. Stores the current world matrix of the child. 2. Makes parent without inverse 3. sets world matrix of child to previously stored world matrix of the child. a - parent b - child m = b.matrix_world b.parent = a b.matrix_world = m Tested it, it works great, I made an operator from it, assigned keyboard shortcut and I use it regularly. I can live with current behavior, especially that I don't use it :-) I have my own hack, but I simply think that this should be default. Bartek Skorupa www.bartekskorupa.com On 22 wrz 2012, at 00:14, Bassam Kurdali wrote: > I don't think it should happen by default. it could be especially nasty > for animation data, linked data, etc. Also it doesn't store as much > information (the relationship between child and parent at the time of > parenting) which could come in handy later. However, it is not hard to > do! > > You need for that is to multiply the inverse transform matrix with the > world transform matrix. I think - I may have gotten the order wrong. > so, an easy way : > 1- do a normal parent operator (creates inverse transform matrix) > 2- multiply the inverse transform and the regular matrix for the object > 3- clear inverse transform > 4- put the matrix from 2 into the transform for the object. > > I think 4 is a bit more complicated, because I *think* that the matrices > are read-only, so you'll have to decompose into > translation/rotation/scale (mathutils provides all those functions > anyway) > bundle that up into an operator and you're home free. > Another good option is just to calculate the inverse parent and avoid > doing the parent-clear inverse dance. If this is done in blender > internally the same code could be used to avoid having two code paths. > > one possibility for blender behavior is to have a parent menu, with a > few choices, similar to the un-parent, and keep the current behavior the > top/default choice. > > On Fri, 2012-09-21 at 21:11 +0200, Bartek Skorupa (priv) wrote: >> Thank you. >> However we are only half way there. It solves the major issue as we at least >> don't have weird properties of the child. >> The question still remains: >> How to make a parent such that the child stays at it's current location, >> rotation and scale, but the values of loc/rot/scale change. >> This is what should happen by default. >> >> @Bassam Kurdali: >> You wrote: >>> the default behaviour should be kept, of course. Most users want this. >> >> >> I wouldn't agree with that. I'm scratching my head trying to figure out at >> least one benefit of current default behavior and can't find anything. >> Is there any good reason for destroying the order in the scene? Having >> objects with locations, rotations and scales set in relation to >> who-the-hell-knows what? >> What do I miss? >> >> Bartek Skorupa >> >> www.bartekskorupa.com >> >> On 21 wrz 2012, at 20:44, Remigiusz Fiedler wrote: >> >>> no ctrl needed, it is "alt p - clear inverse parent" >>> >>> 2012/9/21 Bartek Skorupa (priv) : >>>> Ctl-Alt-P ?? >>>> When I hit it I get a warning: "Can only make proxy for a referenced >>>> object or group" >>>> What do I miss? >>>> >>> ___ >>> 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] I think this should be added
When thinking about adding guides, I'd really appreciate "Action Safe". We have "Title Safe" but that's not enough. Cheers Bartek Skorupa www.bartekskorupa.com On 6 paź 2012, at 10:59, Julian Hh wrote: > This is just a really fancy way of saying that these points are at the same > distance to two of the edges of the image. Not more. I do believe that this > might be a good guide, but it's pretty trivial that it will often look good > to place important things in an image at the same distance to, for example, > the left and the top edge. The reason why I would not include that is > because that is something that is very easy to check without any crazy > lines. Positioning something at equal distance to two borders is something > most people are able to judge with their eyes. Very precisely. > > Doesn't help that he cropped off the top of Mona Lisa, otherwise the line > goes through her nose. > > Just my opinion on this. > > Julian > > 2012/10/6 Nicholas Rishel > >> But don't allow this assumption to prevent you from applying a scientific >> process to verify the disproof. There is knowledge in the ability to say >> that something is verifiability wrong if the hypothesis could be >> intuitively believed. >> >> On Sat, Oct 6, 2012 at 2:05 AM, Harley Acheson >> wrote: >> >>> Take almost any image and bisect a broad diagonal stroke somewhere >>> near the center and the probability is quite high that it will intersect >>> something >>> interesting, especially when your definition of interesting is fuzzy. >>> >>> But for this game you are allowed to do it four times and then choose the >>> best one of the four. Don't be surprised when what you select is >> pleasing >>> to you. That is because you are aligning the guides to the image instead >>> of the image to the guides. >>> >>> 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 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] Python Access to some properties of nodes
Hey everyone, Perhaps at least some of you know that recently I wrote a little Add On for speeding up the work with nodes. Here's the one: wiki: http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Nodes/Nodes_Efficiency_Tools tracker: http://projects.blender.org/tracker/index.php?func=detail&aid=33543&group_id=153&atid=467 When writing this tool I encountered some difficulties just because some properties of nodes or sockets are not available. in python. For example: When I want to check what a certain node is linked to I have to iterate through all of the links and check link's props: from_node, from_socket, to_node or to_socket Would it be possible to add similar properties to the node, or socket itself? We have a property is_linked to check if certain socket is linked. It's fine, but it also would be good to have something like to_node, to_socket, from_node, from_socket as properties of sockets. This way we wouldn't have to iterate through all links to check simple connections. Is it possible to add such properties or it requires rewriting the whole blender? (BTW, I'd also like to ask for checking the code of this add-on. My goal is to work on it, maintain it and maybe some day have it included in trunk) Cheers Bartek Skorupa www.bartekskorupa.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Python Access to some properties of nodes
Thank you Lukas. In a nutshell it means that it's better not to add those properties to sockets right? Without going deeper into it I'd say that it's not a big deal working the old way or use your suggestions. I only said that it would be easier if we had such properties, but it seems that adding them could make other areas harder to maintain. If so, I can live with that. Thank you again. Cheers Bartek Skorupa www.bartekskorupa.com On 20 gru 2012, at 11:30, Lukas Tönne wrote: > Slightly nicer: define 'links' as a property instead of a method: > > class NodeSocket(StructRNA, metaclass=RNAMeta): >__slots__ = () > >@property >def links(self): >"""List of node links from or to this socket""" >return [link for link in self.id_data.links if > link.from_socket == self or link.to_socket == self] > > On Thu, Dec 20, 2012 at 11:10 AM, Lukas Tönne wrote: >> In the bNodeSocket DNA we currently have a sock->link pointer which >> directly points to a bNodeLink. However, this only works for input >> links with the current connectivity model (input only has one possible >> link, outputs can have many). Future nodes can use a different >> connectivity model, then this pointer would be pretty useless. Also >> this pointer is not totally reliable in all cases, e.g. can be invalid >> during node updates. For this reason i would discourage using this >> pointer and always use the nodetree->links list to find connections >> from/to a specific socket. Eventually i'd like to remove the >> sock->link pointer as well to make maintenance easier and remove a >> potential error source. >> >> For getting connections of a socket i would instead suggest to add a >> number of python methods to the NodeSocket class (can be done in >> bpy_types.py). With python this can be done very nicely: >> >> class NodeSocket(StructRNA, metaclass=RNAMeta): >>__slots__ = () >> >># returns a list of links to or from this socket >>def get_links(self): >>return [link for link in self.id_data.links if >> link.from_socket == self or link.to_socket == self] >> >> If necessary such functions could also be added to the RNA directly. >> >> >> On Thu, Dec 20, 2012 at 3:30 AM, Dan Eicher wrote: >>> Assuming Campbell's OK with it it wouldn't be too terribly hard to add >>> something like Socket.link to push the iterating over the links into C >>> since IIRC that's how it works internally. >>> >>> I personally won't have time to mess with it until after New Years but if >>> someone else wants to bang their head against makesrna and node tree >>> structs it might turn out to be as simple as wrapping an existing function >>> (though I do seem to recall that the node links were a little tricky to >>> wrap originally). >>> >>> Dan >>> ___ >>> 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] Color pipeline todo: alpha
IMHO all the confusion comes from the fact that we actually don't refer to ALPHA, but to other three channels, i.e. to colors. We use all those terms to say if the colors have or haven't been altered by the alpha channel. I don't know every single piece of software in the world, but I think that terms "Straight" and "Premultiplied" are the ones that most of the users know and are used to. I'm not a native English speaker, so maybe the way I understand certain terms is totally wrong, but when I think about this stuff I'd vote for having "Straight" and "Premultiplied" as the naming convention. Those two words seem logical to me. "The colors are straight" - means that they are straight. They are unchanged. I can use them as they are and when compositing, I have to multiply them by alpha. "The colors are premultiplied" means that they have already been multiplied (premultiplied, i.e multiplied in advance) by alpha so I don't have to, or I should rather say I mustn't multiply them by alpha again. The confusion results from using the words "straight" or "premultiplied" to describe the alpha, when in fact they describe colors. "Straight Alpha" or "Premultiplied alpha" seem wrong. "Straight colors" or "Premultiplied colors" seem right. "Unpremultiply" sounds to me like saying "unpush" instead of "pull". Bartek Skorupa www.bartekskorupa.com On 20 gru 2012, at 21:01, Troy Sobotka wrote: > On Thu, Dec 20, 2012 at 11:52 AM, Brecht Van Lommel > wrote: >> I like the names associated and unassociated because they don't >> describe how you arrived at the color, just the way it is stored. > > Agree 110%. It also eliminates the rather erroneous assumption that > unassociated and associated alpha are purely as simple as a divide or > multiply away. A do-undo sequence on an associated alpha scene > referred image with >1.0 values would likely destroy the data without > some workarounds. > > That still leaves our "Color Unpremultiply" order of events term a > little... awkward. > > Needless to say, perhaps you or Sergey could agree upon and set the > baseline and then we can work to get the terms consistent throughout > the UI. > > With respect, > TJS > ___ > 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] Color pipeline todo: alpha
> We can agree that "most" is a speculation? Sure. That IS a speculation :-) About the rest - agreed. Bartek Skorupa www.bartekskorupa.com On 20 gru 2012, at 23:52, Troy Sobotka wrote: > On Thu, Dec 20, 2012 at 1:21 PM, Bartek Skorupa (priv) > wrote: >> "Straight" and "Premultiplied" are the ones that most of the users know and >> are used to. > > We can agree that "most" is a speculation? > >> "Unpremultiply" sounds to me like saying "unpush" instead of "pull". > > It might not be fantastic, it is a relatively standard term[1]. While > I'm not a fan of either the Premul or Unpremul, the advantage of the > "un" version is that they form a useful pair. > > Nuke is as attached in the JPG. > Houdini offers both "Multiply by alpha" and "Divide by alpha" in their > Premultiply node. > Shake was manual IIRC. > > With respect, > TJS > > [1] See links in previous email. > ___ > 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] Python Access to some properties of nodes
Thank you very much Lukas. Access to NodeSocket.links may be very helpful and if I had this earlier, I'd probably design my code in: http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Nodes/Nodes_Efficiency_Tools a bit differently. I am especially talking about the operator: NODE_OT_switches_to_outputs. However now after your explanation I begun to wonder if it's not just "hiding" the process from the coder. Let me explain: In my code I wanted to do some operation depending on links connected to outputs that I specified. So in fact I am referring to NodeSocket.links. Because I didn't have direct access to it, I knew that I have to iterate through all of the links. Iterating through all links for all of the outputs seemed not right for me, because I assumed that list of links will in most cases be longer than list of my "selected" outputs. Therefore I wrapped loops the other way, i.e have just one loop "for links" and analyze all my sockets inside this loop. # code A for link: for socket: "do the magic" instead of # code B for socket: for link "do the magic" This was more difficult in my case, but doable. If I had the access to NodeSocket.links, I'd probably not think about it and would simply do: # code C for socket: for socket.links "do the magic" Easy, but isn't it so that accessing NodeSocket.links does iteration through ALL links anyway under the hood? The question is: >From performance point of view: doesn't code B require exactly the same amount >of computing as code C? Or maybe because NodeSocket.links is shorter than all links - it's faster. Does it even matter? Maybe I try to fix the issue that doesn't exist? Bartek Skorupa www.bartekskorupa.com On 22 gru 2012, at 08:21, Lukas Tönne wrote: > IMHO storing the links in a separate list like we do now is one of the > more well-designed code parts ;) > > It may be slightly inconvenient if you want to get a list of links for > a specific socket, but it has several advantages over storing lists of > links in each socket or node: > > * If each socket stores its own link list that means a lot more > overhead for all those lists. Now we have exactly 1 list. > * You only ever need a single loop. If each socket has a list of > links, to walk over all links in a node tree (e.g. for drawing or the > cut operator) you need to walk over all nodes and then all sockets and > then all links ... > * Storing a link in sockets is ambiguous, you could store the link > either in the output or input socket. If you store it on one side only > you have to loop over everything again to find links of the other > side. If you store it in both you have to keep them in sync, which is > error prone and leads to redundant data. > * In terms of time complexity having to filter the list of all links > vs. a reduced list of socket links does not make much difference, both > are essentially O(N+M), where N is number of nodes, M is number of > links. In general though the node DNA should not be judged by > performance criteria too much, if you need to access the node > structure millions of times (e.g. in rendering) you should create an > optimized structure with arrays instead of linked lists and can store > links in whatever way is needed for fast access. All modern node > systems in Blender (cycles, compositor) do this. > > Bottom line: the single links list is the best all-round solution for > the purpose of storing data in .blend files and user manipulation. > > On Sat, Dec 22, 2012 at 2:49 AM, Dan Eicher wrote: >> On Fri, Dec 21, 2012 at 4:52 AM, Lukas Tönne wrote: >> >>> # List of connected (Node, NodeSocket) pairs for 'socket': >>> input_sockets = [(link.from_node, link.from_socket) for link in >>> socket.id_data.links if link.to_socket == socket] >>> output_sockets = [(link.to_node, link.to_socket) for link in >>> socket.id_data.links if link.from_socket == socket] >>> >> >> Somewhat off topic... >> >> Looking at this code I'm starting to think that maybe it was a mistake to >> expose Node.links instead of having it as a property on the sockets >> themselves, it would make the code a lot clearer and it isn't like you can >> really do anything with the links independent of the sockets they're >> assigned to. >> >> It may even be better to totally abstract away the NodeLinks too, maybe >> socket.links just return a list of (Node, NodeSocket) tuples -- have to >> think on this a bit more though since it would probably require >> sub-classing NodeSocket into NodeInputSocket, NodeOutputSocket so you'd >> know if the returned node/socket pair was an input or output for the node. >> >> Would also clean up node.links.new(add?) a bunch. >> >> Dan >> ___ >> 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:
[Bf-committers] Mouse zoom MacOS
Hey, It seems that something changed in mouse behavior on Mac in latest releases. Please correct me if I'm wrong. I've heard that the changes were introduced to make working with "Mighty Mouse" or "Touch Pad" easier or something. If that's the case, I'd like to point out that it also changed the behavior when normal, standard mouse is used. Now to zoom in/out I have to use some strange combinations like Ctrl plus something. Ctrl-wheel works only in 3d view, but doesn't in let's say node editor. There I have to use Ctrl-middle click and drag. Is it intended behavior? Is it going to stay this way? Maybe it has something to do with my OS, so before I report a bug, I'd like to know if it really is a bug. Bartek Skorupa www.bartekskorupa.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Mouse zoom MacOS
I'm not talking about 2.65a, but latest releases. 2.65 works fine. Bartek Skorupa Sent from my iPhone On 24 gru 2012, at 17:50, Fabian Hernandez wrote: > Sorry I meant to say mountain lion, not snow leopard, lol. (10.8.2) > > On Dec 24, 2012, at 5:45 PM, Fabian Hernandez wrote: > >> Can't confirm that for 2.65a. I'm using an iMac running snow leopard, and a >> mouse from steelseries. >> >> On Dec 24, 2012, at 12:49 PM, "Bartek Skorupa (priv)" >> wrote: >> >>> Hey, >>> >>> It seems that something changed in mouse behavior on Mac in latest >>> releases. Please correct me if I'm wrong. >>> I've heard that the changes were introduced to make working with "Mighty >>> Mouse" or "Touch Pad" easier or something. >>> If that's the case, I'd like to point out that it also changed the behavior >>> when normal, standard mouse is used. >>> Now to zoom in/out I have to use some strange combinations like Ctrl plus >>> something. >>> Ctrl-wheel works only in 3d view, but doesn't in let's say node editor. >>> There I have to use Ctrl-middle click and drag. >>> Is it intended behavior? Is it going to stay this way? >>> Maybe it has something to do with my OS, so before I report a bug, I'd like >>> to know if it really is a bug. >>> >>> Bartek Skorupa >>> >>> www.bartekskorupa.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 > > ___ > 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] Mouse zoom MacOS
Hi Ton, Thank you for reply. Unfortunately factory setting didn't solve the issue as well. I'm afraid that in Mac OS those things are somehow linked, I mean trackpad / mighty mouse vs. standard mice. I think Apple guys can't even imagine how on earth anyone can not love their greatest in the world technology and use ancient mice like Logitech :-) Some changes in Blender however must have done something, as in official Blender 2.65a (r53177M) everything is fine with Logitech mouse. I'm not sure if it's relevant, but here are my specs: COMPUTER: MacBook Pro 2,6 GHz Intel Core i7, SOFTWARE: OS X 10.8.2 (12C3012) MOUSE: Mouse - Logitech Marathon Mouse M705, wireless, MOUSE SOFTWARE: Logitech Control Center ver. 3.4.0. BLENDER REVISION: Blender r53345 Thanks again Cheers Bartek Skorupa www.bartekskorupa.com On 28 gru 2012, at 10:03, Ton Roosendaal wrote: > Hi Bartek, > > I've been working on cleaning up code for trackpad and mighty mouse, but that > was for different event types, scrollwheel events didn't change really > (recently). > > Just test with factory settings, maybe one of the add-ons is swallowing > events? > (File menu) > > -Ton- > > > Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org > Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands > > On 26 Dec, 2012, at 12:40, Brecht Van Lommel wrote: > >> If zooming with the mouse wheel in 3D view doesn't work anymore >> without holding ctrl, then indeed please open a report in the tracker. >> These recent changes should only affect the trackpad, if not then I'd >> consider that a bug. >> >> Brecht. >> >> On Mon, Dec 24, 2012 at 12:49 PM, Bartek Skorupa (priv) >> wrote: >>> Hey, >>> >>> It seems that something changed in mouse behavior on Mac in latest >>> releases. Please correct me if I'm wrong. >>> I've heard that the changes were introduced to make working with "Mighty >>> Mouse" or "Touch Pad" easier or something. >>> If that's the case, I'd like to point out that it also changed the behavior >>> when normal, standard mouse is used. >>> Now to zoom in/out I have to use some strange combinations like Ctrl plus >>> something. >>> Ctrl-wheel works only in 3d view, but doesn't in let's say node editor. >>> There I have to use Ctrl-middle click and drag. >>> Is it intended behavior? Is it going to stay this way? >>> Maybe it has something to do with my OS, so before I report a bug, I'd like >>> to know if it really is a bug. >>> >>> Bartek Skorupa >>> >>> www.bartekskorupa.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 > > ___ > 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] Mouse zoom MacOS
Thank you. Bartek Skorupa www.bartekskorupa.com On 28 gru 2012, at 12:45, Ton Roosendaal wrote: > Hi, > > Meanwhile, I can confirm it on my 10.8 macbook too. The 10.7 iMac is all > fine... we will move further discussion to the bug tracker. > > -Ton- > > > Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org > Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands > > On 28 Dec, 2012, at 12:27, Bartek Skorupa (priv) wrote: > >> Hi Ton, >> >> Thank you for reply. Unfortunately factory setting didn't solve the issue as >> well. >> I'm afraid that in Mac OS those things are somehow linked, I mean trackpad / >> mighty mouse vs. standard mice. >> I think Apple guys can't even imagine how on earth anyone can not love their >> greatest in the world technology and use ancient mice like Logitech :-) >> >> Some changes in Blender however must have done something, as in official >> Blender 2.65a (r53177M) everything is fine with Logitech mouse. >> >> I'm not sure if it's relevant, but here are my specs: >> >> COMPUTER: >> MacBook Pro 2,6 GHz Intel Core i7, >> >> SOFTWARE: >> OS X 10.8.2 (12C3012) >> >> MOUSE: >> Mouse - Logitech Marathon Mouse M705, wireless, >> >> MOUSE SOFTWARE: >> Logitech Control Center ver. 3.4.0. >> >> BLENDER REVISION: >> Blender r53345 >> >> >> Thanks again >> >> Cheers >> Bartek Skorupa >> >> www.bartekskorupa.com >> >> On 28 gru 2012, at 10:03, Ton Roosendaal wrote: >> >>> Hi Bartek, >>> >>> I've been working on cleaning up code for trackpad and mighty mouse, but >>> that was for different event types, scrollwheel events didn't change really >>> (recently). >>> >>> Just test with factory settings, maybe one of the add-ons is swallowing >>> events? >>> (File menu) >>> >>> -Ton- >>> >>> >>> Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org >>> Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands >>> >>> On 26 Dec, 2012, at 12:40, Brecht Van Lommel wrote: >>> >>>> If zooming with the mouse wheel in 3D view doesn't work anymore >>>> without holding ctrl, then indeed please open a report in the tracker. >>>> These recent changes should only affect the trackpad, if not then I'd >>>> consider that a bug. >>>> >>>> Brecht. >>>> >>>> On Mon, Dec 24, 2012 at 12:49 PM, Bartek Skorupa (priv) >>>> wrote: >>>>> Hey, >>>>> >>>>> It seems that something changed in mouse behavior on Mac in latest >>>>> releases. Please correct me if I'm wrong. >>>>> I've heard that the changes were introduced to make working with "Mighty >>>>> Mouse" or "Touch Pad" easier or something. >>>>> If that's the case, I'd like to point out that it also changed the >>>>> behavior when normal, standard mouse is used. >>>>> Now to zoom in/out I have to use some strange combinations like Ctrl plus >>>>> something. >>>>> Ctrl-wheel works only in 3d view, but doesn't in let's say node editor. >>>>> There I have to use Ctrl-middle click and drag. >>>>> Is it intended behavior? Is it going to stay this way? >>>>> Maybe it has something to do with my OS, so before I report a bug, I'd >>>>> like to know if it really is a bug. >>>>> >>>>> Bartek Skorupa >>>>> >>>>> www.bartekskorupa.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 >>> >>> ___ >>> 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] Nodes: Reroute node labels - feature request
Hey, When working with nodes many of us label them so that it's easier to know what we're doing especially when nodes setups become more and more complex. Reroute nodes are very helpful in many scenarios but IMHO they are missing one feature: Displaying their labels or names in the node editor, such that we don't have to select them to read the labels in the properties panel. Do you think it's possible to add such feature? Below you'l find a link to image that shows what it could look like. http://www.pasteall.org/pic/42547 Thank you Cheers Bartek Skorupa www.bartekskorupa.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] List the nodes of Frame with API
I was dealing with this issue when working on "Nodes Efficiency Tools": http://projects.blender.org/tracker/index.php?func=detail&aid=33543&group_id=153&atid=467 In the current version I don't set parents, but I certainly will want to be able to do it. The workaround I came up with is as follows: Say you have a node 'frame'. It has children. Say we have a list of them and it's a list called 'children'. Now we want some node outside this frame to be "parented" to it. (Let's call it 'my_node') What I'd do would be: Remove 'frame', but first I'd store it's name, label and maybe some other parameters, then select all of it's children (for node in children: node.select = True), plus 'my_none' (my_node.select = True) and use bpy.ops.node.join() operator. This will create new FRAME node and all of the selected nodes will become its children. Then you may set some previously stored parameters of removed 'frame'. When using operators for nodes you have to mind the context, so it will not work from the console level or simple scripts run from text editor. This is however a workaround and I'd really appreciate if it was possible to simply say node.parent = frame Bartek Skorupa www.bartekskorupa.com On 6 sty 2013, at 19:25, Fabio Russo wrote: > Excellent! : D > But this only allows me to read the relationship, if I instead want to set > up the relationship? How do I? Parent is read only > > > 2013/1/6 Lukas Tönne > >> Nodes have a "parent" pointer that defines the hierarchy. When you >> have a frame node called "frame", the list of attached nodes consists >> of all nodes whose parent is "frame": >> >> node_tree = frame.id_data >> children = [node for node in node_tree.nodes if node.parent == frame] >> >> On Sun, Jan 6, 2013 at 1:17 PM, Fabio Russo wrote: >>> I'm back with some more questions regarding the nodes! >>> I'm trying to improve the addon Compositing Presets, so do not call me >>> annoying :P >>> My new question is how do I know which nodes are located above the frame >>> node via API? >>> >>> Thank you very much, >>> ruesp83 >>> ___ >>> 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] Color Correction Node - "Lift"
I'd like to point out that in "Color Correction" node we have some naming issues. "Lift" in all of the color correction tools do as follows: C - input value L - lift value R - resulting value R = (1-C) * L + C in "Color Correction" node "Lift" simply adds lift value to input color. I think we need to make a decision which color correction model to use. What "Lift" does right now is in fact called "Offset". In my opinion we should either: 1. leave the current behavior of "Lift", but rename it to "Offset", or 2. change it to represent the real lift. I'd opt for second solution. Bartek Skorupa www.bartekskorupa.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color Correction Node - "Lift"
Sorry for double message on the same topic: When analyzing behavior of "Color Correction" node I noticed that in fact all of the terms are messed up here. It seems that this node uses "Offset/Gamma/Slope" model. Therefore "Gain" also doesn't do what it says. What it does is SLOPE, not GAIN. Bartek Skorupa www.bartekskorupa.com On 11 sty 2013, at 16:27, "Bartek Skorupa (priv)" wrote: > I'd like to point out that in "Color Correction" node we have some naming > issues. > "Lift" in all of the color correction tools do as follows: > > C - input value > L - lift value > R - resulting value > > R = (1-C) * L + C > > in "Color Correction" node "Lift" simply adds lift value to input color. > > I think we need to make a decision which color correction model to use. What > "Lift" does right now is in fact called "Offset". > In my opinion we should either: > 1. leave the current behavior of "Lift", but rename it to "Offset", or > 2. change it to represent the real lift. > > I'd opt for second solution. > > > > Bartek Skorupa > > www.bartekskorupa.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] Color Correction Node - "Lift"
I'd prefer it working like LIFT/GAMMA/GAIN does, but this is my personal taste. In my opinion ASC CDL is rather not practical for working with colors. It's great to exchange grades between apps, but I simply don't feel it when grading. The way "Color Correction" node works now is neither LIFT/GAMMA/GAIN nor ASC CDL. It is "kind of" ASC CDL, but according to specs "power" should be used instead of "Gamma". In fact "Gamma" in this case is nothing more than 1/power so maybe it could be left this way, especially that when increasing the value the artist expects colors to be brighter. This is how "Gamma" behaves in LIFT/GAMMA/GAIN. If we all decide to leave the behavior as is - no problem for me, even though I'd opt for changing it. The point of my thread here is to point out inconsistency between how the things work and what the names of operations are. I did my tests just because I was surprised with the results when trying to use this node. I simply know what happens when I change "Lift" or "Gain" and when I changed the parameters that are called "Lift" or "Gain" in this particular node - the behavior was different. If we decide to change the behavior - we lose backwards compatibility, so to make things easier - maybe just changing names of operations would be enough? I would be more than happy if the behavior changes to proper LIFT/GAMMA/GAIN, but if it's left as is - fine, as long as the names say what they should. Best Regards Bartek Skorupa www.bartekskorupa.com On 11 sty 2013, at 18:41, Troy Sobotka wrote: > On Jan 11, 2013 7:27 AM, "Bartek Skorupa (priv)" < > bartekskor...@bartekskorupa.com> wrote: > >> >> R = (1-C) * L + C > > I don't believe this would work well at all with scene referred models / > spaces, of which Blender is. > > Perhaps it is wiser to shift the default operation to ASC CDL format? > > With respect, > TJS > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Please review code of "Nodes Efficiency Tools" Add-On
Hello, I'd like to ask for reviewing the code of Add On: "Nodes Efficiency Tools" http://projects.blender.org/tracker/index.php?func=detail&aid=33543&group_id=153&atid=467 I think it's ready to be included in contrib repository. The Addon is relatively "young". I published it in the middle of December last year, but it got very good response. wiki page for it is ready: http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Nodes/Nodes_Efficiency_Tools Here's a link to video tutorial: http://cg.bartekskorupa.com/nodes-efficiency-tools/ and here's a thread on BA forum: http://blenderartists.org/forum/showthread.php?274755-ADDON-Compositing-Nodes-Efficiency-Tools direct link to the code: http://projects.blender.org/tracker/download.php/153/467/33543/23534/node_efficiency_tools.py With Respect Bartek Skorupa www.bartekskorupa.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Please review code of "Nodes Efficiency Tools" Add-On
Hey Gavin, Thank you for your opinion. About node alignment: The main purpose of this tool was to align nodes let's say "horizontally" and evenly space them on vertical axis. The behavior that you suggest is available without my add-on by hitting S-X-0 or S-Y-0. Such key combinations do exactly what you want. My goal was to additionally evenly distribute the the nodes. This way you have both options: If you want "my" behavior you hit "Shift =" and chose the axis and if you don't want even distribution - S-X-0, or S-Y-0 Cheers Bartek Skorupa www.bartekskorupa.com On 12 sty 2013, at 22:52, Gavin Howard wrote: > Hello all, > Just though that I'd give my opinion of this add-on. I really like it. > I can work much more efficiently in the compositor/materials node editor. > It was stable on my machine. I'd recommend it. > Bartek, I do have one suggestion for the add-on. On the automatic node > alignment, the add-on automatically spaces the aligned nodes the same > distance apart, which often throws off other alignments. I would suggest > that you take that out. If you align them horizontally, only move them > vertically, not horizontally as well. That said, it's a great add-on. > Thanks for making it! > God Bless, > Gavin Howard > > > On Sat, Jan 12, 2013 at 2:43 PM, Bartek Skorupa (priv) < > bartekskor...@bartekskorupa.com> wrote: > >> Hello, >> >> I'd like to ask for reviewing the code of Add On: "Nodes Efficiency Tools" >> >> http://projects.blender.org/tracker/index.php?func=detail&aid=33543&group_id=153&atid=467 >> >> I think it's ready to be included in contrib repository. >> The Addon is relatively "young". I published it in the middle of December >> last year, but it got very good response. >> wiki page for it is ready: >> http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Nodes/Nodes_Efficiency_Tools >> Here's a link to video tutorial: >> http://cg.bartekskorupa.com/nodes-efficiency-tools/ >> and here's a thread on BA forum: >> http://blenderartists.org/forum/showthread.php?274755-ADDON-Compositing-Nodes-Efficiency-Tools >> >> direct link to the code: >> http://projects.blender.org/tracker/download.php/153/467/33543/23534/node_efficiency_tools.py >> >> With Respect >> Bartek Skorupa >> >> www.bartekskorupa.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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color Correction Node - "Lift"
I wouldn't consider it a bug. Color Balance makes no assumptions more than that it receives LINEAR to work on. Every other node assumes the same, so there's no problem here. Conversion to sRBG inside the algorithm can be treated as one of the operations this node performs. If we don't call this "conversion to sRGB", but "primary adjustment" or whatever else - we don't anymore perceive it as a bug, don't you think? Getting back to "Color Correction" node: It's really fine with me that this node behaves as it does. If it's left this way we would only have to change names of the operations. "Gain" should be called "Slope" and "Lift" should be called "offset". Then everybody who knows those terms simply don't get unexpected results. Regards Bartek Skorupa www.bartekskorupa.com On 14 sty 2013, at 04:00, Troy Sobotka wrote: > On Sun, Jan 13, 2013 at 3:57 PM, François T. > wrote: >> but you have to know that Color Balance does a >> sRGB conversion internally. I don't think it would be good to do the same >> in CC > > This is unfortunate. I suspect this should be reported as a bug now > that we have a proper color management system in place for transforms > and expose the transfer curve. > > All nodes should make zero assumptions of the color space and transfer curves. > > With respect, > TJS > ___ > 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] Please review code of "Nodes Efficiency Tools" Add-On
Hello, If anyone finds some time to review the code of "Nodes Efficiency Tools", I'd really appreciate. As an author I believe that it's useful and ready to be moved to "contrib". tracker: http://projects.blender.org/tracker/index.php?func=detail&aid=33543&group_id=153&atid=467 wiki: http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Nodes/Nodes_Efficiency_Tools changelog: http://wiki.blender.org/index.php?title=Extensions:2.6/Py/Scripts/Nodes/Nodes_Efficiency_Tools/Changelog video tutorial: http://cg.bartekskorupa.com/nodes-efficiency-tools/ blenderartists thread: http://blenderartists.org/forum/showthread.php?274755-ADDON-Compositing-Nodes-Efficiency-Tools I keep updating the code, the latest release is always available as an attachment in tracker. Current version: 2.0.04 Regards Bartek Skorupa www.bartekskorupa.com On 12 sty 2013, at 22:43, Bartek Skorupa (priv) wrote: > Hello, > > I'd like to ask for reviewing the code of Add On: "Nodes Efficiency Tools" > http://projects.blender.org/tracker/index.php?func=detail&aid=33543&group_id=153&atid=467 > > I think it's ready to be included in contrib repository. > The Addon is relatively "young". I published it in the middle of December > last year, but it got very good response. > wiki page for it is ready: > http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Nodes/Nodes_Efficiency_Tools > Here's a link to video tutorial: > http://cg.bartekskorupa.com/nodes-efficiency-tools/ > and here's a thread on BA forum: > http://blenderartists.org/forum/showthread.php?274755-ADDON-Compositing-Nodes-Efficiency-Tools > > direct link to the code: > http://projects.blender.org/tracker/download.php/153/467/33543/23534/node_efficiency_tools.py > > With Respect > Bartek Skorupa > > www.bartekskorupa.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] Nodes: Reroute node labels - feature request
Thank you very much for implementing my idea. Checked it in revision 54012 and it's exactly what I was talking about. Bartek Skorupa www.bartekskorupa.com On 28 gru 2012, at 21:58, Bartek Skorupa (priv) wrote: > Hey, > > When working with nodes many of us label them so that it's easier to know > what we're doing especially when nodes setups become more and more complex. > Reroute nodes are very helpful in many scenarios but IMHO they are missing > one feature: Displaying their labels or names in the node editor, such that > we don't have to select them to read the labels in the properties panel. > Do you think it's possible to add such feature? Below you'l find a link to > image that shows what it could look like. > > http://www.pasteall.org/pic/42547 > > Thank you > > Cheers > Bartek Skorupa > > www.bartekskorupa.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
[Bf-committers] Reroute nodes links behavior
Hey, You may call me pain in the &$%# some day, I know :-) I'd like to ask if current behavior of link curves that are connected to "REROUTE" nodes shouldn't be changed. Below you'll find a link to image that shows current behavior when "Noodle curving" is set to default "5" and how it should behave in my opinion. What do you think about it? http://www.pasteall.org/pic/44116 Node editor is designed to work best when the flow of nodes is from left to right. If the behavior of link curves connected to reroute nodes changed to the one I suggest - everything would become more logical and easier to follow. Would it be possible to change this behavior and do you think it should be changed? Thank you Bartek Skorupa www.bartekskorupa.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Shouldn't "REROUTE" node become active?
Hey, Lately I spotted probably not desired behavior when selecting "REROUTE" node. When we select nodes one by one (right click with shift) - we make the nodes selected and the last one becomes active. It happens so with all of the node kinds except "REROUTE". When reroute node is selected as the last one - it doesn't become active. Is this a desired behavior? If so - what is the purpose of it? If this is not desired - should I report it as a bug? Thank you Bartek Skorupa www.bartekskorupa.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Nodes Efficiency Tools" Add-On permission to move to contrib
Hey, I'd like to ask for permission to move my Add-On: "Nodes Efficiency Tools" to contrib. tracker: http://projects.blender.org/tracker/index.php?func=detail&aid=33543&group_id=153&atid=467 wiki: http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Nodes/Nodes_Efficiency_Tools changelog: http://wiki.blender.org/index.php?title=Extensions:2.6/Py/Scripts/Nodes/Nodes_Efficiency_Tools/Changelog video tutorial: http://cg.bartekskorupa.com/nodes-efficiency-tools/ blenderartists thread: http://blenderartists.org/forum/showthread.php?274755-ADDON-Compositing-Nodes-Efficiency-Tools If code review is required - I'd like to ask for this. I'm ready to maintain this script. As you probably noticed I keep asking about it quite frequently. I don't get any answers and I think there may be several reasons: 1. No-one has a time. This is understandable. I will simply try again and again, maybe some day… 2. I'm too impatient, I should sit quiet and wait for my turn. Well, I understand, just let me know :-) 3. There's no need for such add-on because most of the features it gives are planned to be implemented anyway. If so - I'd gladly share any thought I may have, maybe I can be of some help. 4. There's no need for such add-on at all. Well, I understand, just let me know :-) 5. The Add-On is so poorly coded that no-one wants to waste time reviewing such crap. If so - just let me know :-) With Respect Bartek Skorupa www.bartekskorupa.com On 21 sty 2013, at 08:19, Bartek Skorupa (priv) wrote: > Hello, > > If anyone finds some time to review the code of "Nodes Efficiency Tools", I'd > really appreciate. > As an author I believe that it's useful and ready to be moved to "contrib". > > tracker: > http://projects.blender.org/tracker/index.php?func=detail&aid=33543&group_id=153&atid=467 > wiki: > http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Nodes/Nodes_Efficiency_Tools > changelog: > http://wiki.blender.org/index.php?title=Extensions:2.6/Py/Scripts/Nodes/Nodes_Efficiency_Tools/Changelog > video tutorial: http://cg.bartekskorupa.com/nodes-efficiency-tools/ > blenderartists thread: > http://blenderartists.org/forum/showthread.php?274755-ADDON-Compositing-Nodes-Efficiency-Tools > > I keep updating the code, the latest release is always available as an > attachment in tracker. > Current version: 2.0.04 > > Regards > Bartek Skorupa > > www.bartekskorupa.com > > On 12 sty 2013, at 22:43, Bartek Skorupa (priv) > wrote: > >> Hello, >> >> I'd like to ask for reviewing the code of Add On: "Nodes Efficiency Tools" >> http://projects.blender.org/tracker/index.php?func=detail&aid=33543&group_id=153&atid=467 >> >> I think it's ready to be included in contrib repository. >> The Addon is relatively "young". I published it in the middle of December >> last year, but it got very good response. >> wiki page for it is ready: >> http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Nodes/Nodes_Efficiency_Tools >> Here's a link to video tutorial: >> http://cg.bartekskorupa.com/nodes-efficiency-tools/ >> and here's a thread on BA forum: >> http://blenderartists.org/forum/showthread.php?274755-ADDON-Compositing-Nodes-Efficiency-Tools >> >> With Respect >> Bartek Skorupa >> >> www.bartekskorupa.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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Feature request - "Copy Render Layer"
I am missing a little feature that shouldn't be very hard to implement, especially that I was able to create a simple add on that does exactly what I am looking for. When creating render layers we have the option to add new render layer, remove render layer, but what is missing is the ability to make the exact copy of existing render layer. It would help in many cases, like when you want to add new render layer where you'd like to change just one setting comparing to the render layer that already exists. As I mentioned at the beginning I created a simple add on that does it. It adds a button in the render layers panel. The button executes the operator that creates exact copy of selected render layer. I could simply ask for including this add on to blender, but I think such feature shouldn't be implemented via add-on, but on a "higher level". What do you think? Here's the code: http://www.pasteall.org/39349 http://cg.bartekskorupa.com/copy-render-layer/ Cheers Bartek Skorupa www.bartekskorupa.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Feature request - "Copy Render Layer"
@Pablo You're right. It should be called "Duplicate Render Layer". I didn't think about it this way. I'll change it. I'll also try to figure out a way to "Copy/Paste" render layers between scenes or files. My goal here would be to make it work the same as when we copy/paste nodes. Desired behavior would be like this: Select render layer, then click COPY, open another scene or another file and hit PASTE. What do you think about it? I think this kind of behavior would be easier to handle by users than "appending" render layers as it is in "Import Render Layers" add-on. You don't always know all render layers by heard, so probably anyway before running "Imposrt Render Layers" you'd want to open the source file, right? Just to be sure if you import what you want. Cheers Bartek Skorupa www.bartekskorupa.com On 1 lut 2013, at 23:53, PabloVazquez.org wrote: > Hi, > > Great script Bartek! Although I think the name should be "Duplicate > RenderLayer" instead. "Copy" gives me the feeling it would copy it to the > buffer for later paste, like materials/textures menu does (which would be > great indeed!) > > About copying renderlayers between files/scenes, I've been waiting for this > since always. But I always forget to poke the devs about it. > > Now, working on Tube, I needed it a lot. Bassam was kind enough to make a > quick addon for this. > > Import RenderLayers Addon: > http://www.pasteall.org/39351 > > Incredibly useful, it lets you append RenderLayers from another file. > > The only limitation right now due to the lack of time, is that right now it > only imports the renderlayers from the first scene, it should let you > choose from which scene to append the renderlayers from. Any awesome python > hacker to jump in and help? > > Once we have that, I believe this addon should be included in Blender > trunk, perhaps even enabled by default. > > Cheers! > > -- > Pablo Vazquez > CG Artist - Blender Foundation Certified Trainer > Twitter: http://twitter.com/venomgfx > Blender Network: http://blendernetwork.org/member/pablo-vazquez > E-mail: cont...@pablovazquez.org > Website: http://www.pablovazquez.org > > > On Fri, Feb 1, 2013 at 5:31 PM, Juan Pablo Bouza wrote: > >> >> Hi!! >> >> Moreover, I think that there should be an option to copy a render layer >> from one scene to another one >> >> In many cases you need to do exact copies of render layers throughout many >> scenes. Currently the only way to do this is to create an empty scene with >> the render layer settinga, and then you have to start appending the objects >> from the animation scene. >> >> >> >>> From: bartekskor...@bartekskorupa.com >>> Date: Fri, 1 Feb 2013 23:15:23 +0100 >>> To: bf-committers@blender.org >>> Subject: [Bf-committers] Feature request - "Copy Render Layer" >>> >>> I am missing a little feature that shouldn't be very hard to implement, >> especially that I was able to create a simple add on that does exactly what >> I am looking for. >>> When creating render layers we have the option to add new render layer, >> remove render layer, but what is missing is the ability to make the exact >> copy of existing render layer. >>> It would help in many cases, like when you want to add new render layer >> where you'd like to change just one setting comparing to the render layer >> that already exists. >>> >>> As I mentioned at the beginning I created a simple add on that does it. >> It adds a button in the render layers panel. The button executes the >> operator that creates exact copy of selected render layer. >>> I could simply ask for including this add on to blender, but I think >> such feature shouldn't be implemented via add-on, but on a "higher level". >> What do you think? >>> >>> Here's the code: >>> http://www.pasteall.org/39349 >>> >>> >>> http://cg.bartekskorupa.com/copy-render-layer/ >>> >>> >>> Cheers >>> >>> Bartek Skorupa >>> >>> www.bartekskorupa.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 >> > ___ > 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] "Nodes Efficiency Tools" Add-On permission to move to contrib
Thank you Campbell for reviewing the code. I have corrected all issues you pointed out in your review and uploaded latest version to tracker. Yesterday I had doubts about handling keycap items, but during my tests I probably had made some mistakes. I tested everything once again and now in version 2.0.06 it's all exactly as it should be. There is only one thing that I have left untouched although you suggested to change it. line 816 (originally 803): bpy.ops.transform.resize(value = (0.0, 0.0, 0.0)) I left it because my goal here is not to simply move all nodes to the same location, but I use this "hack" to later calculate properly the dimensions of my nodes. I know that now nodes have properties "height", "width" and "width_hidden", but unfortunately they don't give me values that I need. That's why I use a hack to add "reroute" node, then select all of my nodes, "resize" them down to zero and then calculate nodes' dimensions basing on their new locations differences. I need to do all this because nodes' locations are calculated in relation to upper left corner of the node and I need to place them in relation to "visual" center of them. I don't know how I can include modified code here: https://codereview.appspot.com/7235078/ That's why I'd like to ask you to take a look at my code again. Its new version (2.0.06) is uploaded to the tracker: http://projects.blender.org/tracker/index.php?func=detail&aid=33543&group_id=153&atid=467 If the code is fine, will I get the permission to upload it to contrib and maybe eventually to trunk? Thank you again Cheers Bartek Skorupa www.bartekskorupa.com On 25 sty 2013, at 23:12, Bassam Kurdali wrote: > Hi Bartek: > I'm not a decision maker at all, but I looked at the code and it > certainly looks good enough- no trouble understanding it, plenty of > comments, and I could hack a feature in without difficulty if I wanted. > The functionality is great, and I had not encountered any bugs. > > +1 from me for inclusion in contrib > > PS- the only thing that stands out is it is not pep-8 compliant (at > least lines are too long in some places, and there is a space around the > = when assigning values in function calls and I personally like to see > docs for functions ... but this is all code cleanup suggestions, not me > saying that 'it can't go into trunk' as is. > > cheers, > Bassam > On Fri, 2013-01-25 at 13:12 +0100, Bartek Skorupa (priv) wrote: >> Hey, >> >> I'd like to ask for permission to move my Add-On: "Nodes Efficiency Tools" >> to contrib. >> >> tracker: >> http://projects.blender.org/tracker/index.php?func=detail&aid=33543&group_id=153&atid=467 >> wiki: >> http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Nodes/Nodes_Efficiency_Tools >> changelog: >> http://wiki.blender.org/index.php?title=Extensions:2.6/Py/Scripts/Nodes/Nodes_Efficiency_Tools/Changelog >> video tutorial: http://cg.bartekskorupa.com/nodes-efficiency-tools/ >> blenderartists thread: >> http://blenderartists.org/forum/showthread.php?274755-ADDON-Compositing-Nodes-Efficiency-Tools >> >> If code review is required - I'd like to ask for this. >> I'm ready to maintain this script. >> As you probably noticed I keep asking about it quite frequently. >> I don't get any answers and I think there may be several reasons: >> >> 1. No-one has a time. >> This is understandable. I will simply try again and again, maybe some day… >> >> 2. I'm too impatient, I should sit quiet and wait for my turn. >> Well, I understand, just let me know :-) >> >> 3. There's no need for such add-on because most of the features it gives are >> planned to be implemented anyway. >> If so - I'd gladly share any thought I may have, maybe I can be of some help. >> >> 4. There's no need for such add-on at all. >> Well, I understand, just let me know :-) >> >> 5. The Add-On is so poorly coded that no-one wants to waste time reviewing >> such crap. >> If so - just let me know :-) >> >> With Respect >> Bartek Skorupa >> >> www.bartekskorupa.com >> >> On 21 sty 2013, at 08:19, Bartek Skorupa (priv) >> wrote: >> >>> Hello, >>> >>> If anyone finds some time to review the code of "Nodes Efficiency Tools", >>> I'd really appreciate. >>> As an author I believe that it's useful and ready to be moved to "contrib". >>> >>> tracker: >>> http://projects.blender.or
Re: [Bf-committers] "Nodes Efficiency Tools" Add-On permission to move to contrib
Thank you Campbell for reviewing updated code. In your comment in tracker you said: "Hi Bartek, checked the updated script and LGTM. +1 to commit into contrib." It means that I have one "+1" How many "plus ones" do I need to treat this as: "Go ahead, commit"? :-) Is your "+1" enough, or I need to wait for others? Thank you again. Bartek Skorupa www.bartekskorupa.com On 2 lut 2013, at 14:29, Bartek Skorupa (priv) wrote: > Thank you Campbell for reviewing the code. > I have corrected all issues you pointed out in your review and uploaded > latest version to tracker. > Yesterday I had doubts about handling keycap items, but during my tests I > probably had made some mistakes. I tested everything once again and now in > version 2.0.06 it's all exactly as it should be. > There is only one thing that I have left untouched although you suggested to > change it. > > line 816 (originally 803): > bpy.ops.transform.resize(value = (0.0, 0.0, 0.0)) > > I left it because my goal here is not to simply move all nodes to the same > location, but I use this "hack" to later calculate properly the dimensions of > my nodes. I know that now nodes have properties "height", "width" and > "width_hidden", but unfortunately they don't give me values that I need. > That's why I use a hack to add "reroute" node, then select all of my nodes, > "resize" them down to zero and then calculate nodes' dimensions basing on > their new locations differences. I need to do all this because nodes' > locations are calculated in relation to upper left corner of the node and I > need to place them in relation to "visual" center of them. > > I don't know how I can include modified code here: > https://codereview.appspot.com/7235078/ > That's why I'd like to ask you to take a look at my code again. Its new > version (2.0.06) is uploaded to the tracker: > http://projects.blender.org/tracker/index.php?func=detail&aid=33543&group_id=153&atid=467 > > If the code is fine, will I get the permission to upload it to contrib and > maybe eventually to trunk? > > Thank you again > > Cheers > > Bartek Skorupa > > www.bartekskorupa.com > > On 25 sty 2013, at 23:12, Bassam Kurdali wrote: > >> Hi Bartek: >> I'm not a decision maker at all, but I looked at the code and it >> certainly looks good enough- no trouble understanding it, plenty of >> comments, and I could hack a feature in without difficulty if I wanted. >> The functionality is great, and I had not encountered any bugs. >> >> +1 from me for inclusion in contrib >> >> PS- the only thing that stands out is it is not pep-8 compliant (at >> least lines are too long in some places, and there is a space around the >> = when assigning values in function calls and I personally like to see >> docs for functions ... but this is all code cleanup suggestions, not me >> saying that 'it can't go into trunk' as is. >> >> cheers, >> Bassam >> On Fri, 2013-01-25 at 13:12 +0100, Bartek Skorupa (priv) wrote: >>> Hey, >>> >>> I'd like to ask for permission to move my Add-On: "Nodes Efficiency Tools" >>> to contrib. >>> >>> tracker: >>> http://projects.blender.org/tracker/index.php?func=detail&aid=33543&group_id=153&atid=467 >>> wiki: >>> http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Nodes/Nodes_Efficiency_Tools >>> changelog: >>> http://wiki.blender.org/index.php?title=Extensions:2.6/Py/Scripts/Nodes/Nodes_Efficiency_Tools/Changelog >>> video tutorial: http://cg.bartekskorupa.com/nodes-efficiency-tools/ >>> blenderartists thread: >>> http://blenderartists.org/forum/showthread.php?274755-ADDON-Compositing-Nodes-Efficiency-Tools >>> >>> If code review is required - I'd like to ask for this. >>> I'm ready to maintain this script. >>> As you probably noticed I keep asking about it quite frequently. >>> I don't get any answers and I think there may be several reasons: >>> >>> 1. No-one has a time. >>> This is understandable. I will simply try again and again, maybe some day… >>> >>> 2. I'm too impatient, I should sit quiet and wait for my turn. >>> Well, I understand, just let me know :-) >>> >>> 3. There's no need for such add-on because most of the features it gives >>> are planned to be implemented anyway. >>> If so - I'd gladly share
Re: [Bf-committers] "Nodes Efficiency Tools" Add-On permission to move to contrib
Thank you. I will commit later today. Bartek Skorupa www.bartekskorupa.com On 2 lut 2013, at 15:24, Campbell Barton wrote: > Since its contrib, You can go ahead and commit. > This means it will show up in the 'Testing' section of addons and > won't be distributed with releases, we can still review this for > inclusions in release after. > > On Sun, Feb 3, 2013 at 1:16 AM, Bartek Skorupa (priv) > wrote: >> Thank you Campbell for reviewing updated code. >> In your comment in tracker you said: >> "Hi Bartek, checked the updated script and LGTM. +1 to commit into contrib." >> >> It means that I have one "+1" >> >> How many "plus ones" do I need to treat this as: "Go ahead, commit"? :-) >> Is your "+1" enough, or I need to wait for others? >> >> Thank you again. >> >> Bartek Skorupa >> >> www.bartekskorupa.com >> >> On 2 lut 2013, at 14:29, Bartek Skorupa (priv) >> wrote: >> >>> Thank you Campbell for reviewing the code. >>> I have corrected all issues you pointed out in your review and uploaded >>> latest version to tracker. >>> Yesterday I had doubts about handling keycap items, but during my tests I >>> probably had made some mistakes. I tested everything once again and now in >>> version 2.0.06 it's all exactly as it should be. >>> There is only one thing that I have left untouched although you suggested >>> to change it. >>> >>> line 816 (originally 803): >>> bpy.ops.transform.resize(value = (0.0, 0.0, 0.0)) >>> >>> I left it because my goal here is not to simply move all nodes to the same >>> location, but I use this "hack" to later calculate properly the dimensions >>> of my nodes. I know that now nodes have properties "height", "width" and >>> "width_hidden", but unfortunately they don't give me values that I need. >>> That's why I use a hack to add "reroute" node, then select all of my nodes, >>> "resize" them down to zero and then calculate nodes' dimensions basing on >>> their new locations differences. I need to do all this because nodes' >>> locations are calculated in relation to upper left corner of the node and I >>> need to place them in relation to "visual" center of them. >>> >>> I don't know how I can include modified code here: >>> https://codereview.appspot.com/7235078/ >>> That's why I'd like to ask you to take a look at my code again. Its new >>> version (2.0.06) is uploaded to the tracker: >>> http://projects.blender.org/tracker/index.php?func=detail&aid=33543&group_id=153&atid=467 >>> >>> If the code is fine, will I get the permission to upload it to contrib and >>> maybe eventually to trunk? >>> >>> Thank you again >>> >>> Cheers >>> >>> Bartek Skorupa >>> >>> www.bartekskorupa.com >>> >>> On 25 sty 2013, at 23:12, Bassam Kurdali wrote: >>> >>>> Hi Bartek: >>>> I'm not a decision maker at all, but I looked at the code and it >>>> certainly looks good enough- no trouble understanding it, plenty of >>>> comments, and I could hack a feature in without difficulty if I wanted. >>>> The functionality is great, and I had not encountered any bugs. >>>> >>>> +1 from me for inclusion in contrib >>>> >>>> PS- the only thing that stands out is it is not pep-8 compliant (at >>>> least lines are too long in some places, and there is a space around the >>>> = when assigning values in function calls and I personally like to see >>>> docs for functions ... but this is all code cleanup suggestions, not me >>>> saying that 'it can't go into trunk' as is. >>>> >>>> cheers, >>>> Bassam >>>> On Fri, 2013-01-25 at 13:12 +0100, Bartek Skorupa (priv) wrote: >>>>> Hey, >>>>> >>>>> I'd like to ask for permission to move my Add-On: "Nodes Efficiency >>>>> Tools" to contrib. >>>>> >>>>> tracker: >>>>> http://projects.blender.org/tracker/index.php?func=detail&aid=33543&group_id=153&atid=467 >>>>> wiki: >>>>> http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Nodes/Nodes_Efficiency_Tools >>>>
Re: [Bf-committers] Feature request - "Copy Render Layer"
I don't know, but I am working on it just now. Up till now I managed to copy/paste render layers between scenes in the same file. I also managed to paste render layer to different file, but without layers and mask layers. I have problems with those attributes as they are stored in the buffer together with reference to original scene etc. When I open another file - those data are no longer available, so it does't want to work. I will first try to make my solution work and if I succeed - I'll try to combine this with Bassam's script. Bartek Skorupa www.bartekskorupa.com On 2 lut 2013, at 22:43, PabloVazquez.org wrote: > @Bartek > > Yes that'd be a nice addition, but I think both options should be provided. > > Your approach seems good when copying a couple layers, but sometimes is > needed to copy many (characters, bg, fg, zmasks, and so on). > > I think the best way would be to: > - Copy/Paste individual RenderLayer to buffer. > - Import RenderLayers from X scene > - Import RenderLayers from file... >- This could be a little popup invoke that lets you browse to the file, > once the file is chosen it will the scenes in a dropdown, for each scene a > list of the renderlayers to import. > > Is this even possible with current Blender's API? > > > > -- > Pablo Vazquez > CG Artist - Blender Foundation Certified Trainer > Twitter: http://twitter.com/venomgfx > Blender Network: http://blendernetwork.org/member/pablo-vazquez > E-mail: cont...@pablovazquez.org > Website: http://www.pablovazquez.org > > > On Sat, Feb 2, 2013 at 8:10 AM, Bartek Skorupa (priv) < > bartekskor...@bartekskorupa.com> wrote: > >> @Pablo >> You're right. It should be called "Duplicate Render Layer". I didn't think >> about it this way. I'll change it. >> I'll also try to figure out a way to "Copy/Paste" render layers between >> scenes or files. My goal here would be to make it work the same as when we >> copy/paste nodes. >> Desired behavior would be like this: >> >> Select render layer, then click COPY, open another scene or another file >> and hit PASTE. >> What do you think about it? >> >> I think this kind of behavior would be easier to handle by users than >> "appending" render layers as it is in "Import Render Layers" add-on. >> You don't always know all render layers by heard, so probably anyway >> before running "Imposrt Render Layers" you'd want to open the source file, >> right? Just to be sure if you import what you want. >> >> Cheers >> >> Bartek Skorupa >> >> www.bartekskorupa.com >> >> On 1 lut 2013, at 23:53, PabloVazquez.org wrote: >> >>> Hi, >>> >>> Great script Bartek! Although I think the name should be "Duplicate >>> RenderLayer" instead. "Copy" gives me the feeling it would copy it to the >>> buffer for later paste, like materials/textures menu does (which would be >>> great indeed!) >>> >>> About copying renderlayers between files/scenes, I've been waiting for >> this >>> since always. But I always forget to poke the devs about it. >>> >>> Now, working on Tube, I needed it a lot. Bassam was kind enough to make a >>> quick addon for this. >>> >>> Import RenderLayers Addon: >>> http://www.pasteall.org/39351 >>> >>> Incredibly useful, it lets you append RenderLayers from another file. >>> >>> The only limitation right now due to the lack of time, is that right now >> it >>> only imports the renderlayers from the first scene, it should let you >>> choose from which scene to append the renderlayers from. Any awesome >> python >>> hacker to jump in and help? >>> >>> Once we have that, I believe this addon should be included in Blender >>> trunk, perhaps even enabled by default. >>> >>> Cheers! >>> >>> -- >>> Pablo Vazquez >>> CG Artist - Blender Foundation Certified Trainer >>> Twitter: http://twitter.com/venomgfx >>> Blender Network: http://blendernetwork.org/member/pablo-vazquez >>> E-mail: cont...@pablovazquez.org >>> Website: http://www.pablovazquez.org >>> >>> >>> On Fri, Feb 1, 2013 at 5:31 PM, Juan Pablo Bouza >> wrote: >>> >>>> >>>> Hi!! >>>> >>>> Moreover, I think that there should be an option to copy a render layer >>>> from one scene to another one >&
Re: [Bf-committers] Feature request - "Copy Render Layer"
Managed to make it work. Currently we have 4 buttons available: "Duplicate": Duplicates selected render layer "Copy": Copies selected render layer to clipboard "Copy All": Copies all render layers of active scene to clipboard "Paste": Pastes render layers from clipboard to active scene. It works across scenes in the same file as well as between files. If you want to Copy/Paste render layers between files do this: "Copy" or :Copy All", then open the destination file and hit "Paste" All of the render layers will be pasted to current scene of opened file. If any of copied render layers had "material override" or "light override" and such material or light group doesn't exist in destination file - it simply won't be pasted and warning in info panel will appear. Link to wiki and download: http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Render/Copy_Render_Layer Tracker: http://projects.blender.org/tracker/index.php?func=detail&aid=34109&group_id=153&atid=467 Cheers Bartek Skorupa www.bartekskorupa.com On 2 lut 2013, at 23:18, Bartek Skorupa (priv) wrote: > I don't know, but I am working on it just now. > Up till now I managed to copy/paste render layers between scenes in the same > file. > I also managed to paste render layer to different file, but without layers > and mask layers. > I have problems with those attributes as they are stored in the buffer > together with reference to original scene etc. When I open another file - > those data are no longer available, so it does't want to work. > > I will first try to make my solution work and if I succeed - I'll try to > combine this with Bassam's script. > > > Bartek Skorupa > > www.bartekskorupa.com > > On 2 lut 2013, at 22:43, PabloVazquez.org wrote: > >> @Bartek >> >> Yes that'd be a nice addition, but I think both options should be provided. >> >> Your approach seems good when copying a couple layers, but sometimes is >> needed to copy many (characters, bg, fg, zmasks, and so on). >> >> I think the best way would be to: >> - Copy/Paste individual RenderLayer to buffer. >> - Import RenderLayers from X scene >> - Import RenderLayers from file... >> - This could be a little popup invoke that lets you browse to the file, >> once the file is chosen it will the scenes in a dropdown, for each scene a >> list of the renderlayers to import. >> >> Is this even possible with current Blender's API? >> >> >> >> -- >> Pablo Vazquez >> CG Artist - Blender Foundation Certified Trainer >> Twitter: http://twitter.com/venomgfx >> Blender Network: http://blendernetwork.org/member/pablo-vazquez >> E-mail: cont...@pablovazquez.org >> Website: http://www.pablovazquez.org >> >> >> On Sat, Feb 2, 2013 at 8:10 AM, Bartek Skorupa (priv) < >> bartekskor...@bartekskorupa.com> wrote: >> >>> @Pablo >>> You're right. It should be called "Duplicate Render Layer". I didn't think >>> about it this way. I'll change it. >>> I'll also try to figure out a way to "Copy/Paste" render layers between >>> scenes or files. My goal here would be to make it work the same as when we >>> copy/paste nodes. >>> Desired behavior would be like this: >>> >>> Select render layer, then click COPY, open another scene or another file >>> and hit PASTE. >>> What do you think about it? >>> >>> I think this kind of behavior would be easier to handle by users than >>> "appending" render layers as it is in "Import Render Layers" add-on. >>> You don't always know all render layers by heard, so probably anyway >>> before running "Imposrt Render Layers" you'd want to open the source file, >>> right? Just to be sure if you import what you want. >>> >>> Cheers >>> >>> Bartek Skorupa >>> >>> www.bartekskorupa.com >>> >>> On 1 lut 2013, at 23:53, PabloVazquez.org wrote: >>> >>>> Hi, >>>> >>>> Great script Bartek! Although I think the name should be "Duplicate >>>> RenderLayer" instead. "Copy" gives me the feeling it would copy it to the >>>> buffer for later paste, like materials/textures menu does (which would be >>>> great indeed!) >>>> >>>> About copying renderlayers between files/scenes, I've been waiting for >>> this >>>> since always.
Re: [Bf-committers] Node type OUTPUT_MATERIAL undefined
How do I add 'REROUTE' node now?
I tried 'CompositorNodeReroute', but it doesn't work.
Bartek Skorupa
www.bartekskorupa.com
On 19 mar 2013, at 10:49, Lukas Tönne wrote:
> Sorry, should have documented these changes better.
>
> Here is a simple wiki page to collect all changes. The identifier
> string change you ran into is the most important, most other things
> should still work. Please let me know if you encounter more problems
> of this sort:
>
> http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes/API_changes
>
> The sphinx error seems to be a missing default value in RNA, will try
> to track it down.
>
> On Tue, Mar 19, 2013 at 2:33 AM, INTERLICHTSPIELHAUS
> wrote:
>> hi
>>
>> just did a fresh svn update
>> and a script just broke
>>
>> i am creating a new shadernode with the following line
>>
>> out_node = nodeTree.nodes.new('OUTPUT_MATERIAL')
>>
>> i receive the following color
>> RuntimeError: Error: Node type OUTPUT_MATERIAL undefined
>>
>> could someone point me to online dox with the recent python api changes ?
>>
>> when i try to run sphinx_doc_gen.py locally
>> i get the following output + segmentation fault
>>
>> /home/interlichtspielhaus/blender/doc/python_api/rst/bmesh.ops.rst
>> RNA Warning: Current value "0" matches no enum in 'EnumProperty',
>> 'addon_filter', 'default'
>>
>> ./blender() [0x95f41e]
>> /lib/x86_64-linux-gnu/libc.so.6(+0x364a0) [0x7fd9dd28c4a0]
>> /lib/x86_64-linux-gnu/libc.so.6(+0x162c01) [0x7fd9dd3b8c01]
>> ./blender(StringProperty_default_value_length+0x2b) [0x139772b]
>> ./blender(RNA_property_string_length+0x61) [0x12fd831]
>> ./blender(RNA_property_string_get_alloc+0x36) [0x12fd896]
>> ./blender(pyrna_prop_to_py+0x168) [0xcc0b98]
>> ./blender() [0xcc0ec0]
>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(+0xbf9cb) [0x7fd9e1aea9cb]
>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x6003)
>> [0x7fd9e1a92743]
>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x5f62)
>> [0x7fd9e1a926a2]
>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalCodeEx+0x816)
>> [0x7fd9e1a95656]
>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x59f5)
>> [0x7fd9e1a92135]
>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalCodeEx+0x816)
>> [0x7fd9e1a95656]
>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x59f5)
>> [0x7fd9e1a92135]
>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x5f62)
>> [0x7fd9e1a926a2]
>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x5f62)
>> [0x7fd9e1a926a2]
>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalCodeEx+0x816)
>> [0x7fd9e1a95656]
>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalCode+0x3b)
>> [0x7fd9e1a9593b]
>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyRun_FileExFlags+0xb9)
>> [0x7fd9e1bdefc9]
>> ./blender() [0xcb6f96]
>> ./blender() [0x95e871]
>> ./blender(BLI_argsParse+0xc7) [0xf82e97]
>> ./blender(main+0xace) [0x9404fe]
>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7fd9dd27776d]
>> ./blender() [0x95e089]
>>
>> thanks
>> inS
>> ___
>> 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] Node type OUTPUT_MATERIAL undefined
Please don't mind my previous question. Found it.
nodes.new('NodeReroute')
Bartek Skorupa
www.bartekskorupa.com
On 19 mar 2013, at 15:10, Bartek Skorupa (priv)
wrote:
> How do I add 'REROUTE' node now?
> I tried 'CompositorNodeReroute', but it doesn't work.
>
>
> Bartek Skorupa
>
> www.bartekskorupa.com
>
> On 19 mar 2013, at 10:49, Lukas Tönne wrote:
>
>> Sorry, should have documented these changes better.
>>
>> Here is a simple wiki page to collect all changes. The identifier
>> string change you ran into is the most important, most other things
>> should still work. Please let me know if you encounter more problems
>> of this sort:
>>
>> http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes/API_changes
>>
>> The sphinx error seems to be a missing default value in RNA, will try
>> to track it down.
>>
>> On Tue, Mar 19, 2013 at 2:33 AM, INTERLICHTSPIELHAUS
>> wrote:
>>> hi
>>>
>>> just did a fresh svn update
>>> and a script just broke
>>>
>>> i am creating a new shadernode with the following line
>>>
>>> out_node = nodeTree.nodes.new('OUTPUT_MATERIAL')
>>>
>>> i receive the following color
>>> RuntimeError: Error: Node type OUTPUT_MATERIAL undefined
>>>
>>> could someone point me to online dox with the recent python api changes ?
>>>
>>> when i try to run sphinx_doc_gen.py locally
>>> i get the following output + segmentation fault
>>>
>>> /home/interlichtspielhaus/blender/doc/python_api/rst/bmesh.ops.rst
>>> RNA Warning: Current value "0" matches no enum in 'EnumProperty',
>>> 'addon_filter', 'default'
>>>
>>> ./blender() [0x95f41e]
>>> /lib/x86_64-linux-gnu/libc.so.6(+0x364a0) [0x7fd9dd28c4a0]
>>> /lib/x86_64-linux-gnu/libc.so.6(+0x162c01) [0x7fd9dd3b8c01]
>>> ./blender(StringProperty_default_value_length+0x2b) [0x139772b]
>>> ./blender(RNA_property_string_length+0x61) [0x12fd831]
>>> ./blender(RNA_property_string_get_alloc+0x36) [0x12fd896]
>>> ./blender(pyrna_prop_to_py+0x168) [0xcc0b98]
>>> ./blender() [0xcc0ec0]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(+0xbf9cb) [0x7fd9e1aea9cb]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x6003)
>>> [0x7fd9e1a92743]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x5f62)
>>> [0x7fd9e1a926a2]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalCodeEx+0x816)
>>> [0x7fd9e1a95656]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x59f5)
>>> [0x7fd9e1a92135]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalCodeEx+0x816)
>>> [0x7fd9e1a95656]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x59f5)
>>> [0x7fd9e1a92135]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x5f62)
>>> [0x7fd9e1a926a2]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x5f62)
>>> [0x7fd9e1a926a2]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalCodeEx+0x816)
>>> [0x7fd9e1a95656]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalCode+0x3b)
>>> [0x7fd9e1a9593b]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyRun_FileExFlags+0xb9)
>>> [0x7fd9e1bdefc9]
>>> ./blender() [0xcb6f96]
>>> ./blender() [0x95e871]
>>> ./blender(BLI_argsParse+0xc7) [0xf82e97]
>>> ./blender(main+0xace) [0x9404fe]
>>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7fd9dd27776d]
>>> ./blender() [0x95e089]
>>>
>>> thanks
>>> inS
>>> ___
>>> 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] Node type OUTPUT_MATERIAL undefined
Hey,
Nodes:
I just spotted strange behavior when adding links via NodeTree.links.new(from,
to)
When something is linked to the input - newly created link doesn't remove this
old link.
Before latest API changes - it worked ok. Old links were removed as expected.
Now after adding new link - two links are attached to one input which is by no
means not what should happen.
Is this a desired behavior?
If so - how can I "remove" link?
Thanks
Cheers
Bartek Skorupa
www.bartekskorupa.com
On 19 mar 2013, at 15:10, Bartek Skorupa (priv)
wrote:
> How do I add 'REROUTE' node now?
> I tried 'CompositorNodeReroute', but it doesn't work.
>
>
> Bartek Skorupa
>
> www.bartekskorupa.com
>
> On 19 mar 2013, at 10:49, Lukas Tönne wrote:
>
>> Sorry, should have documented these changes better.
>>
>> Here is a simple wiki page to collect all changes. The identifier
>> string change you ran into is the most important, most other things
>> should still work. Please let me know if you encounter more problems
>> of this sort:
>>
>> http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes/API_changes
>>
>> The sphinx error seems to be a missing default value in RNA, will try
>> to track it down.
>>
>> On Tue, Mar 19, 2013 at 2:33 AM, INTERLICHTSPIELHAUS
>> wrote:
>>> hi
>>>
>>> just did a fresh svn update
>>> and a script just broke
>>>
>>> i am creating a new shadernode with the following line
>>>
>>> out_node = nodeTree.nodes.new('OUTPUT_MATERIAL')
>>>
>>> i receive the following color
>>> RuntimeError: Error: Node type OUTPUT_MATERIAL undefined
>>>
>>> could someone point me to online dox with the recent python api changes ?
>>>
>>> when i try to run sphinx_doc_gen.py locally
>>> i get the following output + segmentation fault
>>>
>>> /home/interlichtspielhaus/blender/doc/python_api/rst/bmesh.ops.rst
>>> RNA Warning: Current value "0" matches no enum in 'EnumProperty',
>>> 'addon_filter', 'default'
>>>
>>> ./blender() [0x95f41e]
>>> /lib/x86_64-linux-gnu/libc.so.6(+0x364a0) [0x7fd9dd28c4a0]
>>> /lib/x86_64-linux-gnu/libc.so.6(+0x162c01) [0x7fd9dd3b8c01]
>>> ./blender(StringProperty_default_value_length+0x2b) [0x139772b]
>>> ./blender(RNA_property_string_length+0x61) [0x12fd831]
>>> ./blender(RNA_property_string_get_alloc+0x36) [0x12fd896]
>>> ./blender(pyrna_prop_to_py+0x168) [0xcc0b98]
>>> ./blender() [0xcc0ec0]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(+0xbf9cb) [0x7fd9e1aea9cb]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x6003)
>>> [0x7fd9e1a92743]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x5f62)
>>> [0x7fd9e1a926a2]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalCodeEx+0x816)
>>> [0x7fd9e1a95656]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x59f5)
>>> [0x7fd9e1a92135]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalCodeEx+0x816)
>>> [0x7fd9e1a95656]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x59f5)
>>> [0x7fd9e1a92135]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x5f62)
>>> [0x7fd9e1a926a2]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x5f62)
>>> [0x7fd9e1a926a2]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalCodeEx+0x816)
>>> [0x7fd9e1a95656]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalCode+0x3b)
>>> [0x7fd9e1a9593b]
>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyRun_FileExFlags+0xb9)
>>> [0x7fd9e1bdefc9]
>>> ./blender() [0xcb6f96]
>>> ./blender() [0x95e871]
>>> ./blender(BLI_argsParse+0xc7) [0xf82e97]
>>> ./blender(main+0xace) [0x9404fe]
>>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7fd9dd27776d]
>>> ./blender() [0x95e089]
>>>
>>> thanks
>>> inS
>>> ___
>>> 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] Node type OUTPUT_MATERIAL undefined
Thank you Lukas, now everything works fine.
Bartek Skorupa
www.bartekskorupa.com
On 20 mar 2013, at 10:55, Lukas Tönne wrote:
> @Bartek: This was a bug in the RNA function, link counting was not
> taking the new link into account, fixed in r55436. Thanks for
> reporting!
>
> On Wed, Mar 20, 2013 at 9:03 AM, Bartek Skorupa (priv)
> wrote:
>> Hey,
>>
>> Nodes:
>> I just spotted strange behavior when adding links via
>> NodeTree.links.new(from, to)
>> When something is linked to the input - newly created link doesn't remove
>> this old link.
>> Before latest API changes - it worked ok. Old links were removed as expected.
>> Now after adding new link - two links are attached to one input which is by
>> no means not what should happen.
>> Is this a desired behavior?
>> If so - how can I "remove" link?
>>
>> Thanks
>>
>> Cheers
>>
>> Bartek Skorupa
>>
>> www.bartekskorupa.com
>>
>> On 19 mar 2013, at 15:10, Bartek Skorupa (priv)
>> wrote:
>>
>>> How do I add 'REROUTE' node now?
>>> I tried 'CompositorNodeReroute', but it doesn't work.
>>>
>>>
>>> Bartek Skorupa
>>>
>>> www.bartekskorupa.com
>>>
>>> On 19 mar 2013, at 10:49, Lukas Tönne wrote:
>>>
>>>> Sorry, should have documented these changes better.
>>>>
>>>> Here is a simple wiki page to collect all changes. The identifier
>>>> string change you ran into is the most important, most other things
>>>> should still work. Please let me know if you encounter more problems
>>>> of this sort:
>>>>
>>>> http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes/API_changes
>>>>
>>>> The sphinx error seems to be a missing default value in RNA, will try
>>>> to track it down.
>>>>
>>>> On Tue, Mar 19, 2013 at 2:33 AM, INTERLICHTSPIELHAUS
>>>> wrote:
>>>>> hi
>>>>>
>>>>> just did a fresh svn update
>>>>> and a script just broke
>>>>>
>>>>> i am creating a new shadernode with the following line
>>>>>
>>>>> out_node = nodeTree.nodes.new('OUTPUT_MATERIAL')
>>>>>
>>>>> i receive the following color
>>>>> RuntimeError: Error: Node type OUTPUT_MATERIAL undefined
>>>>>
>>>>> could someone point me to online dox with the recent python api changes ?
>>>>>
>>>>> when i try to run sphinx_doc_gen.py locally
>>>>> i get the following output + segmentation fault
>>>>>
>>>>> /home/interlichtspielhaus/blender/doc/python_api/rst/bmesh.ops.rst
>>>>> RNA Warning: Current value "0" matches no enum in 'EnumProperty',
>>>>> 'addon_filter', 'default'
>>>>>
>>>>> ./blender() [0x95f41e]
>>>>> /lib/x86_64-linux-gnu/libc.so.6(+0x364a0) [0x7fd9dd28c4a0]
>>>>> /lib/x86_64-linux-gnu/libc.so.6(+0x162c01) [0x7fd9dd3b8c01]
>>>>> ./blender(StringProperty_default_value_length+0x2b) [0x139772b]
>>>>> ./blender(RNA_property_string_length+0x61) [0x12fd831]
>>>>> ./blender(RNA_property_string_get_alloc+0x36) [0x12fd896]
>>>>> ./blender(pyrna_prop_to_py+0x168) [0xcc0b98]
>>>>> ./blender() [0xcc0ec0]
>>>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(+0xbf9cb) [0x7fd9e1aea9cb]
>>>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x6003)
>>>>> [0x7fd9e1a92743]
>>>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x5f62)
>>>>> [0x7fd9e1a926a2]
>>>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalCodeEx+0x816)
>>>>> [0x7fd9e1a95656]
>>>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x59f5)
>>>>> [0x7fd9e1a92135]
>>>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalCodeEx+0x816)
>>>>> [0x7fd9e1a95656]
>>>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x59f5)
>>>>> [0x7fd9e1a92135]
>>>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x5f62)
>>>>> [0x7fd9e1a926a2]
>>>>> /usr/lib/x86_64-linux-gnu/libpython3.3m.so.1.0(PyEval_EvalFrameEx+0x5f62)
>>>>> [0x7fd9e1a926a2]
>>
[Bf-committers] scons build error r.55464
Hey, I'm not sure if this is a right place to post this. I begun getting errors when compiling with scons. Everything worked fine till yesterday evening (r.55452) MacOS 10.8.3 XCode version: 4.5 Is there anything I can do in user-config to avoid this or we begun to have some general issue? Here's the log: Updated to revision 55464. bartek-3:blender-build Bartek$ cd blender/ bartek-3:blender Bartek$ python scons/scons.py -j9 scons: Reading SConscript files ... Command-line arguments No command-line arguments given Command-line targets No targets given, using default Using config file: build_files/scons/config/darwin-config.py Using user-config file: user-config.py Build with parallel jobs: 9 Build with debug symbols: False Detected Xcode version: -- 4.5 -- Available OS X SDKs: Mac OS X 10.7 -sdk macosx10.7 OS X 10.8 -sdk macosx10.8 iOS SDKs: iOS 6.0 -sdk iphoneos6.0 iOS Simulator SDKs: Simulator - iOS 6.0 -sdk iphonesimulator6.0 Auto-setting available MacOSX SDK -> MacOSX10.7.sdk 3D_CONNEXION_CLIENT_LIBRARY not found, disabling WITH_BF_3DMOUSE JackOSX install not found, disabling WITH_BF_JACK Building in: /Users/Bartek/blender-build/build/darwin Configuring library bf_avi Configuring library bf_bmesh Configuring library bf_blenkernel Configuring library bf_blenkernel_mask Configuring library bf_blenlib Configuring library bf_blenloader Configuring library bf_gpu Configuring library bf_editor_datafiles Configuring library bf_editors_space_api Configuring library bf_editors_util Configuring library bf_editors_interface Configuring library bf_editor_io Configuring library bf_editors_animation Configuring library bf_editors_armature Configuring library bf_editors_mask Configuring library bf_editors_mesh Configuring library bf_editors_metaball Configuring library bf_editors_object Configuring library bf_editors_curve Configuring library bf_editors_gpencil Configuring library bf_editors_physics Configuring library bf_editors_render Configuring library bf_editors_sound Configuring library bf_editors_space_buttons Configuring library bf_editors_space_clip Configuring library bf_editors_space_file Configuring library bf_editors_space_image Configuring library bf_editors_space_info Configuring library bf_editors_space_graph Configuring library bf_editors_space_node Configuring library bf_editors_space_outliner Configuring library bf_editors_space_time Configuring library bf_editors_space_view3d Configuring library bf_editors_space_action Configuring library bf_editors_space_nla Configuring library bf_editors_space_script Configuring library bf_editors_space_text Configuring library bf_editors_space_sequencer Configuring library bf_editors_space_game Configuring library bf_editors_space_console Configuring library bf_editors_space_userpref Configuring library bf_editors_transform Configuring library bf_editors_screen Configuring library bf_editors_sculpt_paint Configuring library bf_editors_uvedit Configuring library bf_imbuf Configuring library bf_dna Configuring library bf_render Configuring library bf_render_raytrace Configuring library bf_nodes Configuring library bf_cmpnodes Configuring library bf_shdnodes Configuring library bf_texnodes Configuring library bf_modifiers Configuring library bf_ikplugin Configuring library bf_windowmanager Configuring library bf_blenfont Configuring library bf_rna Configuring library bf_python_bmesh Configuring library bf_python_ext Configuring library bf_python_mathutils Configuring library bf_python Configuring library bf_imbuf_dds Configuring library bf_imbuf_cineon Configuring library bf_imbuf_openexr Configuring library bf_quicktime Configuring library bf_collada Configuring library bf_composite Configuring library ge_blen_routines Configuring library ge_converter Configuring library ge_logic_expressions Configuring library ge_logic Configuring library ge_logic_ketsji Configuring library bf_network Configuring library ge_logic_ngnetwork Configuring library ge_logic_loopbacknetwork Configuring library ge_phys_dummy Configuring library ge_rasterizer Configuring library ge_oglrasterizer Configuring library ge_scenegraph Configuring library ge_videotex Configuring library ge_player_common Configuring library ge_player_ghost Configuring library ge_phys_bullet Configuring library blenkernel_blc Configuring library bf_intern_audaspace Configuring library bf_intern_string Configuring library bf_intern_ghost GHOST COCOA WILL BE COMPILED WITH APPLE GCC Configuring library bf_intern_guardedalloc Configuring library bf_intern_moto Configuring library bf_intern_memutil Configuring library bf_intern_iksolver Configuring library bf_intern_itasc Configuring library bf_intern_opencolorio Configuring library bf_intern_opennl Configuring library bf_intern_mikktspace Configuring library bf_intern_smoke Configuring library bf_intern_raskter Configuring library bf_in
Re: [Bf-committers] scons build error r.55464
Hey, I just compiled r.55501 using scons on Mac 10.8.3 with no problems. Thank you. Bartek Skorupa www.bartekskorupa.com On 21 mar 2013, at 15:25, Bartek Skorupa (priv) wrote: > Hey, > > I'm not sure if this is a right place to post this. > I begun getting errors when compiling with scons. Everything worked fine till > yesterday evening (r.55452) > MacOS 10.8.3 > XCode version: 4.5 > Is there anything I can do in user-config to avoid this or we begun to have > some general issue? > > Here's the log: > > > Updated to revision 55464. > bartek-3:blender-build Bartek$ cd blender/ > bartek-3:blender Bartek$ python scons/scons.py -j9 > scons: Reading SConscript files ... > Command-line arguments > No command-line arguments given > Command-line targets > No targets given, using default > Using config file: build_files/scons/config/darwin-config.py > Using user-config file: user-config.py > Build with parallel jobs: 9 > Build with debug symbols: False > Detected Xcode version: -- 4.5 -- > Available OS X SDKs: > Mac OS X 10.7 -sdk macosx10.7 > OS X 10.8 -sdk macosx10.8 > > iOS SDKs: > iOS 6.0 -sdk iphoneos6.0 > > iOS Simulator SDKs: > Simulator - iOS 6.0 -sdk iphonesimulator6.0 > > Auto-setting available MacOSX SDK -> MacOSX10.7.sdk > 3D_CONNEXION_CLIENT_LIBRARY not found, disabling WITH_BF_3DMOUSE > JackOSX install not found, disabling WITH_BF_JACK > Building in: /Users/Bartek/blender-build/build/darwin > Configuring library bf_avi > Configuring library bf_bmesh > Configuring library bf_blenkernel > Configuring library bf_blenkernel_mask > Configuring library bf_blenlib > Configuring library bf_blenloader > Configuring library bf_gpu > Configuring library bf_editor_datafiles > Configuring library bf_editors_space_api > Configuring library bf_editors_util > Configuring library bf_editors_interface > Configuring library bf_editor_io > Configuring library bf_editors_animation > Configuring library bf_editors_armature > Configuring library bf_editors_mask > Configuring library bf_editors_mesh > Configuring library bf_editors_metaball > Configuring library bf_editors_object > Configuring library bf_editors_curve > Configuring library bf_editors_gpencil > Configuring library bf_editors_physics > Configuring library bf_editors_render > Configuring library bf_editors_sound > Configuring library bf_editors_space_buttons > Configuring library bf_editors_space_clip > Configuring library bf_editors_space_file > Configuring library bf_editors_space_image > Configuring library bf_editors_space_info > Configuring library bf_editors_space_graph > Configuring library bf_editors_space_node > Configuring library bf_editors_space_outliner > Configuring library bf_editors_space_time > Configuring library bf_editors_space_view3d > Configuring library bf_editors_space_action > Configuring library bf_editors_space_nla > Configuring library bf_editors_space_script > Configuring library bf_editors_space_text > Configuring library bf_editors_space_sequencer > Configuring library bf_editors_space_game > Configuring library bf_editors_space_console > Configuring library bf_editors_space_userpref > Configuring library bf_editors_transform > Configuring library bf_editors_screen > Configuring library bf_editors_sculpt_paint > Configuring library bf_editors_uvedit > Configuring library bf_imbuf > Configuring library bf_dna > Configuring library bf_render > Configuring library bf_render_raytrace > Configuring library bf_nodes > Configuring library bf_cmpnodes > Configuring library bf_shdnodes > Configuring library bf_texnodes > Configuring library bf_modifiers > Configuring library bf_ikplugin > Configuring library bf_windowmanager > Configuring library bf_blenfont > Configuring library bf_rna > Configuring library bf_python_bmesh > Configuring library bf_python_ext > Configuring library bf_python_mathutils > Configuring library bf_python > Configuring library bf_imbuf_dds > Configuring library bf_imbuf_cineon > Configuring library bf_imbuf_openexr > Configuring library bf_quicktime > Configuring library bf_collada > Configuring library bf_composite > Configuring library ge_blen_routines > Configuring library ge_converter > Configuring library ge_logic_expressions > Configuring library ge_logic > Configuring library ge_logic_ketsji > Configuring library bf_network > Configuring library ge_logic_ngnetwork > Configuring library ge_logic_loopbacknetwork > Configuring library ge_phys_dummy > Configuring library ge_rasterizer > Configuring library ge_oglra
[Bf-committers] Node Efficiency Tools - can it go to trunk?
Hey, After recent commits of node_efficiency_tools.py I as an author call this add-on ready. All of the features that I had in mind have been included, documented on wiki and in video tutorial. Recent API changes have taken into account. It certainly will develop further, but at this stage it's IMHO ready to go trunk. I'd like to ask for reviewing the code and hopefully permission to move this add-on to trunk. https://svn.blender.org/svnroot/bf-extensions/contrib/py/scripts/addons/node_efficiency_tools.py Here's the wiki page: http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Nodes/Nodes_Efficiency_Tools Tracker: http://projects.blender.org/tracker/?func=detail&atid=468&aid=33543&group_id=153 Thread on blenderartists: http://blenderartists.org/forum/showthread.php?274755-ADDON-Nodes-Efficiency-Tools Many users appreciate this add-on and wish to have it in official Blender releases. I declare to maintain the code. Please let me know if you feel that it's worth including or not. With Respect, Bartek Skorupa www.bartekskorupa.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Node Efficiency Tools - can it go to trunk?
Thank you for this quick review.
Yes you're right about my understanding of bl_label. I did mismatch this and I
can change it, np.
About my 'option' properties:
In many cases I can change it to enums, but sometimes StringProperty is used
because I need to pass more than one property in one go.
Say I need to set 3 properties:
prop1 = True
prop2 = True
prop3 = False
I wrap it in one StringProperty that gets the value of 'True True False' and
then in execute I use string split( ), and eval to get 3 booleans.
Please take a look at line 1325 for example:
layout.operator(NodesLinkActiveToSelected.bl_idname, text="Replace
Links").option = 'True True False'
option then is passed to execute of NodesLinkActiveToSelected and split.
see lines: 795 to 798:
option_split = self.option.split( )
replace = eval(option_split[0])
use_node_name = eval(option_split[1])
use_outputs_names = eval(option_split[2])
This way I get 3 variables out of one property 'option'
Is there a better way of doing it?
Another question:
Could you please explain me why using StringProperty instead of proper
EnumProperty is wrong?
Is it a convention, speed issues or anything else?
Thank you in advance
Regards
Bartek Skorupa
www.bartekskorupa.com
On 25 mar 2013, at 15:24, Bastien Montagne wrote:
> Hi Bartek,
>
> Just did a (very quick) skim review of your addon, and I agree that
> there are valuable features in it, worth moving it to trunk. However, I
> noted at least two points that imho should be addressed before the move:
>
> First, you seems to mismatch labels and tips of operators! E.g. instead
> of this line:
>
> bl_label = "Copy Settings of Active Node to Selected Nodes"
>
> I would rather see those:
>
> bl_label = "Copy Node Settings"
> bl_description = "Copy the settings of the active node to selected
> ones"
>
> The second point is, I think, more important. You should replace your
> “multipurpose” "option" StringProperty by relevant properties. E.g.
>
> # option: 'from active', 'from node', 'from socket'
> option = StringProperty()
>
> Should be replaced by:
>
> source = EnumProperty(name="Source", description="A relevant
> description…", default='FROM_ACTIVE',
> items=(('FROM_ACTIVE', "From Active", "A
> relevant description…", 'ICON_NONE', 1),
> ('FROM_NODE', "From Node", "A relevant
> description…", 'ICON_NONE', 2),
> ('FROM_SOCKET', "From Socket", "A
> relevant description…", 'ICON_NONE', 3),
> )
> )
>
> (with relevant changes in other parts of the code).
>
> Best regards,
> Bastien
>
> On 25/03/2013 14:00, Bartek Skorupa (priv) wrote:
>> Hey,
>>
>> After recent commits of node_efficiency_tools.py I as an author call this
>> add-on ready.
>> All of the features that I had in mind have been included, documented on
>> wiki and in video tutorial.
>> Recent API changes have taken into account.
>> It certainly will develop further, but at this stage it's IMHO ready to go
>> trunk.
>>
>> I'd like to ask for reviewing the code and hopefully permission to move this
>> add-on to trunk.
>> https://svn.blender.org/svnroot/bf-extensions/contrib/py/scripts/addons/node_efficiency_tools.py
>>
>> Here's the wiki page:
>> http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Nodes/Nodes_Efficiency_Tools
>>
>> Tracker:
>> http://projects.blender.org/tracker/?func=detail&atid=468&aid=33543&group_id=153
>>
>> Thread on blenderartists:
>> http://blenderartists.org/forum/showthread.php?274755-ADDON-Nodes-Efficiency-Tools
>>
>>
>> Many users appreciate this add-on and wish to have it in official Blender
>> releases.
>> I declare to maintain the code.
>>
>> Please let me know if you feel that it's worth including or not.
>>
>>
>> With Respect,
>>
>> Bartek Skorupa
>>
>> www.bartekskorupa.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
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Node Efficiency Tools - can it go to trunk?
Thank you for the explanation.
> props = layout.operator(NodesLinkActiveToSelected.bl_idname, text="Replace
> Links").prop1 = True
> props.prop2 = True
> props.prop3 = False
Oops… I didn't know you can do it :-) Really…
Every day I learn something.
I will change all those properties accordingly.
Thank you once again
Regards
Bartek Skorupa
www.bartekskorupa.com
On 25 mar 2013, at 16:02, Bastien Montagne wrote:
> Hi,
>
> On 25/03/2013 15:51, Bartek Skorupa (priv) wrote:
>> Thank you for this quick review.
>> Yes you're right about my understanding of bl_label. I did mismatch this and
>> I can change it, np.
>>
>> About my 'option' properties:
>> In many cases I can change it to enums, but sometimes StringProperty is used
>> because I need to pass more than one property in one go.
>> Say I need to set 3 properties:
>> prop1 = True
>> prop2 = True
>> prop3 = False
>>
>> I wrap it in one StringProperty that gets the value of 'True True False' and
>> then in execute I use string split( ), and eval to get 3 booleans.
>>
>> Please take a look at line 1325 for example:
>> layout.operator(NodesLinkActiveToSelected.bl_idname, text="Replace
>> Links").option = 'True True False'
>>
>> option then is passed to execute of NodesLinkActiveToSelected and split.
>> see lines: 795 to 798:
>> option_split = self.option.split( )
>> replace = eval(option_split[0])
>> use_node_name = eval(option_split[1])
>> use_outputs_names = eval(option_split[2])
>>
>> This way I get 3 variables out of one property 'option'
>>
>> Is there a better way of doing it?
> Yes there is! :)
>
> In such case, you should do that:
>
> props = layout.operator(NodesLinkActiveToSelected.bl_idname,
> text="Replace Links").prop1 = True
> props.prop2 = True
> props.prop3 = False
>
>> Another question:
>> Could you please explain me why using StringProperty instead of proper
>> EnumProperty is wrong?
>> Is it a convention, speed issues or anything else?
> First of all, it is a convention. True/false options should be booleans,
> options with a well defined set of choices should be enums, etc.
>
> This also helps on documentation level (as each enum items has its own
> label/description, you do not need comments in code, and doc can be
> retrieved easily by multiple ways).
>
> And there is also an UI interest, as using enums you can get a nice
> drop-down list as a control, or you can even auto-generate a menu where
> each entry will execute the operator with one of the options of the enum, …
>
> By the way, note that if you have a set of related booleans options that
> are not mutually exclusive, you can use an enum with 'ENUM_FLAG' option
> (in that case you are just limited to at most 32 different flags - the
> length of a classical integer ;) ).
>
> Kind regards,
> Bastien
>
>> Thank you in advance
>>
>> Regards
>>
>> Bartek Skorupa
>>
>> www.bartekskorupa.com
>>
>> On 25 mar 2013, at 15:24, Bastien Montagne wrote:
>>
>>> Hi Bartek,
>>>
>>> Just did a (very quick) skim review of your addon, and I agree that
>>> there are valuable features in it, worth moving it to trunk. However, I
>>> noted at least two points that imho should be addressed before the move:
>>>
>>> First, you seems to mismatch labels and tips of operators! E.g. instead
>>> of this line:
>>>
>>> bl_label = "Copy Settings of Active Node to Selected Nodes"
>>>
>>> I would rather see those:
>>>
>>> bl_label = "Copy Node Settings"
>>> bl_description = "Copy the settings of the active node to selected
>>> ones"
>>>
>>> The second point is, I think, more important. You should replace your
>>> “multipurpose” "option" StringProperty by relevant properties. E.g.
>>>
>>> # option: 'from active', 'from node', 'from socket'
>>> option = StringProperty()
>>>
>>> Should be replaced by:
>>>
>>> source = EnumProperty(name="Source", description="A relevant
>>> description…", default='FROM_ACTIVE',
>>> items=(('FROM_ACTIVE', "From Active", "A
>>> relevant description…", 'ICON_NONE', 1),
>>>
Re: [Bf-committers] Node Efficiency Tools - can it go to trunk?
Noticed that, thank you. Bartek Skorupa www.bartekskorupa.com On 25 mar 2013, at 17:20, Bastien Montagne wrote: > On 25/03/2013 17:19, CoDEmanX wrote: >> Proper formatting: >> >> props = layout.operator(NodesLinkActiveToSelected.bl_idname, >> text="Replace Links") >> >> props.prop1 = True >> props.prop2 = True >> props.prop3 = False > > Yes, right, sorry… :/ > ___ > 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] Node Efficiency Tools - can it go to trunk?
Hey, @CoDEmanX: I don't quite get what you mean by: > But please don't do this if the amount of props varies (prop1-propN)! Could you elaborate, please? Bartek Skorupa www.bartekskorupa.com On 25 mar 2013, at 17:19, CoDEmanX wrote: > Proper formatting: > > props = layout.operator(NodesLinkActiveToSelected.bl_idname, > text="Replace Links") > > props.prop1 = True > props.prop2 = True > props.prop3 = False > > But please don't do this if the amount of props varies (prop1-propN)! > Use a CollectionProperty instead. I think i did this in the Game > Property Visulizer addon to replace the evil eval(). > > > Am 25.03.2013 16:08, schrieb Bartek Skorupa (priv): >> Thank you for the explanation. >>> props = layout.operator(NodesLinkActiveToSelected.bl_idname, text="Replace >>> Links").prop1 = True >>> props.prop2 = True >>> props.prop3 = False >> Oops… I didn't know you can do it :-) Really… >> >> Every day I learn something. >> I will change all those properties accordingly. >> >> Thank you once again >> >> Regards >> >> Bartek Skorupa >> >> www.bartekskorupa.com >> >> On 25 mar 2013, at 16:02, Bastien Montagne wrote: >> >>> Hi, >>> >>> On 25/03/2013 15:51, Bartek Skorupa (priv) wrote: >>>> Thank you for this quick review. >>>> Yes you're right about my understanding of bl_label. I did mismatch this >>>> and I can change it, np. >>>> >>>> About my 'option' properties: >>>> In many cases I can change it to enums, but sometimes StringProperty is >>>> used because I need to pass more than one property in one go. >>>> Say I need to set 3 properties: >>>> prop1 = True >>>> prop2 = True >>>> prop3 = False >>>> >>>> I wrap it in one StringProperty that gets the value of 'True True False' >>>> and then in execute I use string split( ), and eval to get 3 booleans. >>>> >>>> Please take a look at line 1325 for example: >>>> layout.operator(NodesLinkActiveToSelected.bl_idname, text="Replace >>>> Links").option = 'True True False' >>>> >>>> option then is passed to execute of NodesLinkActiveToSelected and split. >>>> see lines: 795 to 798: >>>> option_split = self.option.split( ) >>>> replace = eval(option_split[0]) >>>> use_node_name = eval(option_split[1]) >>>> use_outputs_names = eval(option_split[2]) >>>> >>>> This way I get 3 variables out of one property 'option' >>>> >>>> Is there a better way of doing it? >>> Yes there is! :) >>> >>> In such case, you should do that: >>> >>> props = layout.operator(NodesLinkActiveToSelected.bl_idname, >>> text="Replace Links").prop1 = True >>> props.prop2 = True >>> props.prop3 = False >>> >>>> Another question: >>>> Could you please explain me why using StringProperty instead of proper >>>> EnumProperty is wrong? >>>> Is it a convention, speed issues or anything else? >>> First of all, it is a convention. True/false options should be booleans, >>> options with a well defined set of choices should be enums, etc. >>> >>> This also helps on documentation level (as each enum items has its own >>> label/description, you do not need comments in code, and doc can be >>> retrieved easily by multiple ways). >>> >>> And there is also an UI interest, as using enums you can get a nice >>> drop-down list as a control, or you can even auto-generate a menu where >>> each entry will execute the operator with one of the options of the enum, … >>> >>> By the way, note that if you have a set of related booleans options that >>> are not mutually exclusive, you can use an enum with 'ENUM_FLAG' option >>> (in that case you are just limited to at most 32 different flags - the >>> length of a classical integer ;) ). >>> >>> Kind regards, >>> Bastien >>> >>>> Thank you in advance >>>> >>>> Regards >>>> >>>> Bartek Skorupa >>>> >>>> www.bartekskorupa.com >>>> >>>> On 25 mar 2013, at 15:24, Bastien Montagne wrote: >>>> >>>>
Re: [Bf-committers] Node Efficiency Tools - can it go to trunk?
@ Bastien Changed the code according to your guidelines. Is the script now ok to go to trunk? Thank you for your help. Cheers, Bartek Skorupa www.bartekskorupa.com On 25 mar 2013, at 17:33, Bartek Skorupa (priv) wrote: > Hey, > @CoDEmanX: > I don't quite get what you mean by: >> But please don't do this if the amount of props varies (prop1-propN)! > Could you elaborate, please? > > > Bartek Skorupa > > www.bartekskorupa.com > > On 25 mar 2013, at 17:19, CoDEmanX wrote: > >> Proper formatting: >> >> props = layout.operator(NodesLinkActiveToSelected.bl_idname, >> text="Replace Links") >> >> props.prop1 = True >> props.prop2 = True >> props.prop3 = False >> >> But please don't do this if the amount of props varies (prop1-propN)! >> Use a CollectionProperty instead. I think i did this in the Game >> Property Visulizer addon to replace the evil eval(). >> >> >> Am 25.03.2013 16:08, schrieb Bartek Skorupa (priv): >>> Thank you for the explanation. >>>> props = layout.operator(NodesLinkActiveToSelected.bl_idname, text="Replace >>>> Links").prop1 = True >>>>props.prop2 = True >>>>props.prop3 = False >>> Oops… I didn't know you can do it :-) Really… >>> >>> Every day I learn something. >>> I will change all those properties accordingly. >>> >>> Thank you once again >>> >>> Regards >>> >>> Bartek Skorupa >>> >>> www.bartekskorupa.com >>> >>> On 25 mar 2013, at 16:02, Bastien Montagne wrote: >>> >>>> Hi, >>>> >>>> On 25/03/2013 15:51, Bartek Skorupa (priv) wrote: >>>>> Thank you for this quick review. >>>>> Yes you're right about my understanding of bl_label. I did mismatch this >>>>> and I can change it, np. >>>>> >>>>> About my 'option' properties: >>>>> In many cases I can change it to enums, but sometimes StringProperty is >>>>> used because I need to pass more than one property in one go. >>>>> Say I need to set 3 properties: >>>>> prop1 = True >>>>> prop2 = True >>>>> prop3 = False >>>>> >>>>> I wrap it in one StringProperty that gets the value of 'True True False' >>>>> and then in execute I use string split( ), and eval to get 3 booleans. >>>>> >>>>> Please take a look at line 1325 for example: >>>>> layout.operator(NodesLinkActiveToSelected.bl_idname, text="Replace >>>>> Links").option = 'True True False' >>>>> >>>>> option then is passed to execute of NodesLinkActiveToSelected and split. >>>>> see lines: 795 to 798: >>>>>option_split = self.option.split( ) >>>>>replace = eval(option_split[0]) >>>>>use_node_name = eval(option_split[1]) >>>>>use_outputs_names = eval(option_split[2]) >>>>> >>>>> This way I get 3 variables out of one property 'option' >>>>> >>>>> Is there a better way of doing it? >>>> Yes there is! :) >>>> >>>> In such case, you should do that: >>>> >>>>props = layout.operator(NodesLinkActiveToSelected.bl_idname, >>>> text="Replace Links").prop1 = True >>>>props.prop2 = True >>>>props.prop3 = False >>>> >>>>> Another question: >>>>> Could you please explain me why using StringProperty instead of proper >>>>> EnumProperty is wrong? >>>>> Is it a convention, speed issues or anything else? >>>> First of all, it is a convention. True/false options should be booleans, >>>> options with a well defined set of choices should be enums, etc. >>>> >>>> This also helps on documentation level (as each enum items has its own >>>> label/description, you do not need comments in code, and doc can be >>>> retrieved easily by multiple ways). >>>> >>>> And there is also an UI interest, as using enums you can get a nice >>>> drop-down list as a control, or you can even auto-generate a menu where >>>> each entry will execute the operator with one of the options of the enum, … >>>> >>>> By the way, note that if you have a se
Re: [Bf-committers] Node Efficiency Tools - can it go to trunk?
I will ask Campbell for review. If he reviews and say that it's ok - can I treat this as "You have a permission to move it to trunk"? Thank you. Cheers Bartek Skorupa www.bartekskorupa.com On 26 mar 2013, at 17:01, Bastien Montagne wrote: > Yes, imho it's good for addons/ dir. Would be cool if you could get > Campbell (ideasman_42) to review it too in the next days, else just move > it! :) > > Bastien > > On 26/03/2013 16:54, Bartek Skorupa (priv) wrote: >> @ Bastien >> Changed the code according to your guidelines. >> >> Is the script now ok to go to trunk? >> Thank you for your help. >> >> Cheers, >> Bartek Skorupa >> >> www.bartekskorupa.com >> >> On 25 mar 2013, at 17:33, Bartek Skorupa >> (priv) wrote: >> >>> Hey, >>> @CoDEmanX: >>> I don't quite get what you mean by: >>>> But please don't do this if the amount of props varies (prop1-propN)! >>> Could you elaborate, please? >>> >>> >>> Bartek Skorupa >>> >>> www.bartekskorupa.com >>> >>> On 25 mar 2013, at 17:19, CoDEmanX wrote: >>> >>>> Proper formatting: >>>> >>>> props = layout.operator(NodesLinkActiveToSelected.bl_idname, >>>> text="Replace Links") >>>> >>>> props.prop1 = True >>>> props.prop2 = True >>>> props.prop3 = False >>>> >>>> But please don't do this if the amount of props varies (prop1-propN)! >>>> Use a CollectionProperty instead. I think i did this in the Game >>>> Property Visulizer addon to replace the evil eval(). >>>> >>>> >>>> Am 25.03.2013 16:08, schrieb Bartek Skorupa (priv): >>>>> Thank you for the explanation. >>>>>> props = layout.operator(NodesLinkActiveToSelected.bl_idname, >>>>>> text="Replace Links").prop1 = True >>>>>>props.prop2 = True >>>>>>props.prop3 = False >>>>> Oops… I didn't know you can do it :-) Really… >>>>> >>>>> Every day I learn something. >>>>> I will change all those properties accordingly. >>>>> >>>>> Thank you once again >>>>> >>>>> Regards >>>>> >>>>> Bartek Skorupa >>>>> >>>>> www.bartekskorupa.com >>>>> >>>>> On 25 mar 2013, at 16:02, Bastien Montagne wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> On 25/03/2013 15:51, Bartek Skorupa (priv) wrote: >>>>>>> Thank you for this quick review. >>>>>>> Yes you're right about my understanding of bl_label. I did mismatch >>>>>>> this and I can change it, np. >>>>>>> >>>>>>> About my 'option' properties: >>>>>>> In many cases I can change it to enums, but sometimes StringProperty is >>>>>>> used because I need to pass more than one property in one go. >>>>>>> Say I need to set 3 properties: >>>>>>> prop1 = True >>>>>>> prop2 = True >>>>>>> prop3 = False >>>>>>> >>>>>>> I wrap it in one StringProperty that gets the value of 'True True >>>>>>> False' and then in execute I use string split( ), and eval to get 3 >>>>>>> booleans. >>>>>>> >>>>>>> Please take a look at line 1325 for example: >>>>>>> layout.operator(NodesLinkActiveToSelected.bl_idname, text="Replace >>>>>>> Links").option = 'True True False' >>>>>>> >>>>>>> option then is passed to execute of NodesLinkActiveToSelected and split. >>>>>>> see lines: 795 to 798: >>>>>>>option_split = self.option.split( ) >>>>>>>replace = eval(option_split[0]) >>>>>>>use_node_name = eval(option_split[1]) >>>>>>>use_outputs_names = eval(option_split[2]) >>>>>>> >>>>>>> This way I get 3 variables out of one property 'option' >>>>>>> >>>>>>> Is there a better way of doing it? >>>>>> Yes there is! :) >>>>>> >>
Re: [Bf-committers] Node Efficiency Tools - can it go to trunk?
Thank you very much. Bartek Skorupa www.bartekskorupa.com On 26 mar 2013, at 17:53, CoDEmanX wrote: > if the number of properties you pass to an operator differ, e.g. one > prop per Custom Property of the active object, then you shouldn't do > something like > > prop1 = ... > prop2 = ... > ... > prop20 = ... > > to allow for up to 20 properties be passed to the operator. Why? Cause > you don't need 20 properties if you mostly need to pass just one or two, > and there may be situations in which you need more than 20. So a fixed > amount is really bad. > > Instead, you can use a CollectionProperty and add an item for every > element you need to pass. > > Here's an example: > > http://www.pasteall.org/40829/python > > > If ideasman is fine with your code, then it's ok to move to trunk! > > > Am 25.03.2013 17:33, schrieb Bartek Skorupa (priv): >> Hey, >> @CoDEmanX: >> I don't quite get what you mean by: >>> But please don't do this if the amount of props varies (prop1-propN)! >> Could you elaborate, please? >> >> >> Bartek Skorupa >> >> www.bartekskorupa.com >> >> On 25 mar 2013, at 17:19, CoDEmanX wrote: >> >>> Proper formatting: >>> >>> props = layout.operator(NodesLinkActiveToSelected.bl_idname, >>> text="Replace Links") >>> >>> props.prop1 = True >>> props.prop2 = True >>> props.prop3 = False >>> >>> But please don't do this if the amount of props varies (prop1-propN)! >>> Use a CollectionProperty instead. I think i did this in the Game >>> Property Visulizer addon to replace the evil eval(). >>> >>> >>> Am 25.03.2013 16:08, schrieb Bartek Skorupa (priv): >>>> Thank you for the explanation. >>>>> props = layout.operator(NodesLinkActiveToSelected.bl_idname, >>>>> text="Replace Links").prop1 = True >>>>> props.prop2 = True >>>>> props.prop3 = False >>>> Oops… I didn't know you can do it :-) Really… >>>> >>>> Every day I learn something. >>>> I will change all those properties accordingly. >>>> >>>> Thank you once again >>>> >>>> Regards >>>> >>>> Bartek Skorupa >>>> >>>> www.bartekskorupa.com >>>> >>>> On 25 mar 2013, at 16:02, Bastien Montagne wrote: >>>> >>>>> Hi, >>>>> >>>>> On 25/03/2013 15:51, Bartek Skorupa (priv) wrote: >>>>>> Thank you for this quick review. >>>>>> Yes you're right about my understanding of bl_label. I did mismatch this >>>>>> and I can change it, np. >>>>>> >>>>>> About my 'option' properties: >>>>>> In many cases I can change it to enums, but sometimes StringProperty is >>>>>> used because I need to pass more than one property in one go. >>>>>> Say I need to set 3 properties: >>>>>> prop1 = True >>>>>> prop2 = True >>>>>> prop3 = False >>>>>> >>>>>> I wrap it in one StringProperty that gets the value of 'True True False' >>>>>> and then in execute I use string split( ), and eval to get 3 booleans. >>>>>> >>>>>> Please take a look at line 1325 for example: >>>>>> layout.operator(NodesLinkActiveToSelected.bl_idname, text="Replace >>>>>> Links").option = 'True True False' >>>>>> >>>>>> option then is passed to execute of NodesLinkActiveToSelected and split. >>>>>> see lines: 795 to 798: >>>>>> option_split = self.option.split( ) >>>>>> replace = eval(option_split[0]) >>>>>> use_node_name = eval(option_split[1]) >>>>>> use_outputs_names = eval(option_split[2]) >>>>>> >>>>>> This way I get 3 variables out of one property 'option' >>>>>> >>>>>> Is there a better way of doing it? >>>>> Yes there is! :) >>>>> >>>>> In such case, you should do that: >>>>> >>>>> props = layout.operator(NodesLinkActiveToSelected.bl_idname, >>>>> text="Replace Links").prop1 = True >>>>>
Re: [Bf-committers] Node Efficiency Tools - can it go to trunk?
Thank you Campbell, Bastien and CoDEmanX for reviewing my code. I have implemented all of your suggestions. All of the issues pointed in this review: https://codereview.appspot.com/7651047/diff/1/node_efficiency_tools.py#newcode103 have been addressed. The review has been done using not the latest version of the script, so some of the suggestions have been implemented earlier. The script with all of those changes is version 2..1.4 and has been committed as revision: 4434. Is it now ok to move it to trunk? Thank you. With Respect Bartek Skorupa www.bartekskorupa.com On 26 mar 2013, at 17:55, Bartek Skorupa (priv) wrote: > Thank you very much. > > Bartek Skorupa > > www.bartekskorupa.com > > On 26 mar 2013, at 17:53, CoDEmanX wrote: > >> if the number of properties you pass to an operator differ, e.g. one >> prop per Custom Property of the active object, then you shouldn't do >> something like >> >> prop1 = ... >> prop2 = ... >> ... >> prop20 = ... >> >> to allow for up to 20 properties be passed to the operator. Why? Cause >> you don't need 20 properties if you mostly need to pass just one or two, >> and there may be situations in which you need more than 20. So a fixed >> amount is really bad. >> >> Instead, you can use a CollectionProperty and add an item for every >> element you need to pass. >> >> Here's an example: >> >> http://www.pasteall.org/40829/python >> >> >> If ideasman is fine with your code, then it's ok to move to trunk! >> >> >> Am 25.03.2013 17:33, schrieb Bartek Skorupa (priv): >>> Hey, >>> @CoDEmanX: >>> I don't quite get what you mean by: >>>> But please don't do this if the amount of props varies (prop1-propN)! >>> Could you elaborate, please? >>> >>> >>> Bartek Skorupa >>> >>> www.bartekskorupa.com >>> >>> On 25 mar 2013, at 17:19, CoDEmanX wrote: >>> >>>> Proper formatting: >>>> >>>> props = layout.operator(NodesLinkActiveToSelected.bl_idname, >>>> text="Replace Links") >>>> >>>> props.prop1 = True >>>> props.prop2 = True >>>> props.prop3 = False >>>> >>>> But please don't do this if the amount of props varies (prop1-propN)! >>>> Use a CollectionProperty instead. I think i did this in the Game >>>> Property Visulizer addon to replace the evil eval(). >>>> >>>> >>>> Am 25.03.2013 16:08, schrieb Bartek Skorupa (priv): >>>>> Thank you for the explanation. >>>>>> props = layout.operator(NodesLinkActiveToSelected.bl_idname, >>>>>> text="Replace Links").prop1 = True >>>>>>props.prop2 = True >>>>>>props.prop3 = False >>>>> Oops… I didn't know you can do it :-) Really… >>>>> >>>>> Every day I learn something. >>>>> I will change all those properties accordingly. >>>>> >>>>> Thank you once again >>>>> >>>>> Regards >>>>> >>>>> Bartek Skorupa >>>>> >>>>> www.bartekskorupa.com >>>>> >>>>> On 25 mar 2013, at 16:02, Bastien Montagne wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> On 25/03/2013 15:51, Bartek Skorupa (priv) wrote: >>>>>>> Thank you for this quick review. >>>>>>> Yes you're right about my understanding of bl_label. I did mismatch >>>>>>> this and I can change it, np. >>>>>>> >>>>>>> About my 'option' properties: >>>>>>> In many cases I can change it to enums, but sometimes StringProperty is >>>>>>> used because I need to pass more than one property in one go. >>>>>>> Say I need to set 3 properties: >>>>>>> prop1 = True >>>>>>> prop2 = True >>>>>>> prop3 = False >>>>>>> >>>>>>> I wrap it in one StringProperty that gets the value of 'True True >>>>>>> False' and then in execute I use string split( ), and eval to get 3 >>>>>>> booleans. >>>>>>> >>>>>>> Please take a look at line 1325 for example: >>>>>>> layout.operator(NodesLinkA
Re: [Bf-committers] Node Efficiency Tools - can it go to trunk?
Note about "Select Parent/Children": This operator allows to select 'FRAME' that wraps selected nodes or select all of the nodes that are "children" of selected 'FRAME'. It's done using '[' and ']' keys. Campbell said that it could be implemented on a higher level, but before it happens, I'd leave it in my code. When this option is implemented I'll immediately remove this class from node_efficiency_tools.py Bartek Skorupa www.bartekskorupa.com On 27 mar 2013, at 09:06, Bartek Skorupa (priv) wrote: > Thank you Campbell, Bastien and CoDEmanX for reviewing my code. > I have implemented all of your suggestions. > All of the issues pointed in this review: > https://codereview.appspot.com/7651047/diff/1/node_efficiency_tools.py#newcode103 > have been addressed. > The review has been done using not the latest version of the script, so some > of the suggestions have been implemented earlier. > The script with all of those changes is version 2..1.4 and has been committed > as revision: 4434. > > Is it now ok to move it to trunk? > > Thank you. > > With Respect > Bartek Skorupa > > www.bartekskorupa.com > > On 26 mar 2013, at 17:55, Bartek Skorupa (priv) > wrote: > >> Thank you very much. >> >> Bartek Skorupa >> >> www.bartekskorupa.com >> >> On 26 mar 2013, at 17:53, CoDEmanX wrote: >> >>> if the number of properties you pass to an operator differ, e.g. one >>> prop per Custom Property of the active object, then you shouldn't do >>> something like >>> >>> prop1 = ... >>> prop2 = ... >>> ... >>> prop20 = ... >>> >>> to allow for up to 20 properties be passed to the operator. Why? Cause >>> you don't need 20 properties if you mostly need to pass just one or two, >>> and there may be situations in which you need more than 20. So a fixed >>> amount is really bad. >>> >>> Instead, you can use a CollectionProperty and add an item for every >>> element you need to pass. >>> >>> Here's an example: >>> >>> http://www.pasteall.org/40829/python >>> >>> >>> If ideasman is fine with your code, then it's ok to move to trunk! >>> >>> >>> Am 25.03.2013 17:33, schrieb Bartek Skorupa (priv): >>>> Hey, >>>> @CoDEmanX: >>>> I don't quite get what you mean by: >>>>> But please don't do this if the amount of props varies (prop1-propN)! >>>> Could you elaborate, please? >>>> >>>> >>>> Bartek Skorupa >>>> >>>> www.bartekskorupa.com >>>> >>>> On 25 mar 2013, at 17:19, CoDEmanX wrote: >>>> >>>>> Proper formatting: >>>>> >>>>> props = layout.operator(NodesLinkActiveToSelected.bl_idname, >>>>> text="Replace Links") >>>>> >>>>> props.prop1 = True >>>>> props.prop2 = True >>>>> props.prop3 = False >>>>> >>>>> But please don't do this if the amount of props varies (prop1-propN)! >>>>> Use a CollectionProperty instead. I think i did this in the Game >>>>> Property Visulizer addon to replace the evil eval(). >>>>> >>>>> >>>>> Am 25.03.2013 16:08, schrieb Bartek Skorupa (priv): >>>>>> Thank you for the explanation. >>>>>>> props = layout.operator(NodesLinkActiveToSelected.bl_idname, >>>>>>> text="Replace Links").prop1 = True >>>>>>> props.prop2 = True >>>>>>> props.prop3 = False >>>>>> Oops… I didn't know you can do it :-) Really… >>>>>> >>>>>> Every day I learn something. >>>>>> I will change all those properties accordingly. >>>>>> >>>>>> Thank you once again >>>>>> >>>>>> Regards >>>>>> >>>>>> Bartek Skorupa >>>>>> >>>>>> www.bartekskorupa.com >>>>>> >>>>>> On 25 mar 2013, at 16:02, Bastien Montagne wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On 25/03/2013 15:51, Bartek Skorupa (priv) wrote: >>>>>>>> Thank you for this quick review. >>>>>>>> Yes you
Re: [Bf-committers] Node Efficiency Tools - can it go to trunk?
@Campbell Thank you for cleaning up my code of node_efficiency_tools.py (revision 4435) I assume that now it's ready to be moved to trunk, is it? Do I have your permission to do it? Thank you for your time. With Respect Bartek Skorupa Revision: 4435 http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-extensions&revision=4435 Author: campbellbarton Date: 2013-03-27 10:17:08 + (Wed, 27 Mar 2013) Log Message: --- minor code cleanup Modified Paths: -- contrib/py/scripts/addons/node_efficiency_tools.py On 27 mar 2013, at 09:14, Bartek Skorupa (priv) wrote: > Note about "Select Parent/Children": > This operator allows to select 'FRAME' that wraps selected nodes or select > all of the nodes that are "children" of selected 'FRAME'. > It's done using '[' and ']' keys. > Campbell said that it could be implemented on a higher level, but before it > happens, I'd leave it in my code. > When this option is implemented I'll immediately remove this class from > node_efficiency_tools.py > > Bartek Skorupa > > www.bartekskorupa.com > > On 27 mar 2013, at 09:06, Bartek Skorupa (priv) > wrote: > >> Thank you Campbell, Bastien and CoDEmanX for reviewing my code. >> I have implemented all of your suggestions. >> All of the issues pointed in this review: >> https://codereview.appspot.com/7651047/diff/1/node_efficiency_tools.py#newcode103 >> have been addressed. >> The review has been done using not the latest version of the script, so some >> of the suggestions have been implemented earlier. >> The script with all of those changes is version 2..1.4 and has been >> committed as revision: 4434. >> >> Is it now ok to move it to trunk? >> >> Thank you. >> >> With Respect >> Bartek Skorupa >> >> www.bartekskorupa.com >> >> On 26 mar 2013, at 17:55, Bartek Skorupa (priv) >> wrote: >> >>> Thank you very much. >>> >>> Bartek Skorupa >>> >>> www.bartekskorupa.com >>> >>> On 26 mar 2013, at 17:53, CoDEmanX wrote: >>> >>>> if the number of properties you pass to an operator differ, e.g. one >>>> prop per Custom Property of the active object, then you shouldn't do >>>> something like >>>> >>>> prop1 = ... >>>> prop2 = ... >>>> ... >>>> prop20 = ... >>>> >>>> to allow for up to 20 properties be passed to the operator. Why? Cause >>>> you don't need 20 properties if you mostly need to pass just one or two, >>>> and there may be situations in which you need more than 20. So a fixed >>>> amount is really bad. >>>> >>>> Instead, you can use a CollectionProperty and add an item for every >>>> element you need to pass. >>>> >>>> Here's an example: >>>> >>>> http://www.pasteall.org/40829/python >>>> >>>> >>>> If ideasman is fine with your code, then it's ok to move to trunk! >>>> >>>> >>>> Am 25.03.2013 17:33, schrieb Bartek Skorupa (priv): >>>>> Hey, >>>>> @CoDEmanX: >>>>> I don't quite get what you mean by: >>>>>> But please don't do this if the amount of props varies (prop1-propN)! >>>>> Could you elaborate, please? >>>>> >>>>> >>>>> Bartek Skorupa >>>>> >>>>> www.bartekskorupa.com >>>>> >>>>> On 25 mar 2013, at 17:19, CoDEmanX wrote: >>>>> >>>>>> Proper formatting: >>>>>> >>>>>> props = layout.operator(NodesLinkActiveToSelected.bl_idname, >>>>>> text="Replace Links") >>>>>> >>>>>> props.prop1 = True >>>>>> props.prop2 = True >>>>>> props.prop3 = False >>>>>> >>>>>> But please don't do this if the amount of props varies (prop1-propN)! >>>>>> Use a CollectionProperty instead. I think i did this in the Game >>>>>> Property Visulizer addon to replace the evil eval(). >>>>>> >>>>>> >>>>>> Am 25.03.2013 16:08, schrieb Bartek Skorupa (priv): >>>>>>> Thank you for the explanation. >>>>>>>> props = layout.operator(NodesLinkActiveToSelected.bl_idnam
Re: [Bf-committers] Node Efficiency Tools - can it go to trunk?
Final code clean up before moving to trunk: revision 4436. All suggested changes have been made. I'd like to ask for final permission before I commit. Thank you With Respect Bartek Skorupa www.bartekskorupa.com On 27 mar 2013, at 11:35, Bartek Skorupa (priv) wrote: > @Campbell > Thank you for cleaning up my code of node_efficiency_tools.py (revision 4435) > I assume that now it's ready to be moved to trunk, is it? > Do I have your permission to do it? > > Thank you for your time. > > With Respect > Bartek Skorupa > > > Revision: 4435 > > http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-extensions&revision=4435 > Author: campbellbarton > Date: 2013-03-27 10:17:08 + (Wed, 27 Mar 2013) > Log Message: > --- > minor code cleanup > > Modified Paths: > -- > contrib/py/scripts/addons/node_efficiency_tools.py > > > > > On 27 mar 2013, at 09:14, Bartek Skorupa (priv) > wrote: > >> Note about "Select Parent/Children": >> This operator allows to select 'FRAME' that wraps selected nodes or select >> all of the nodes that are "children" of selected 'FRAME'. >> It's done using '[' and ']' keys. >> Campbell said that it could be implemented on a higher level, but before it >> happens, I'd leave it in my code. >> When this option is implemented I'll immediately remove this class from >> node_efficiency_tools.py >> >> Bartek Skorupa >> >> www.bartekskorupa.com >> >> On 27 mar 2013, at 09:06, Bartek Skorupa (priv) >> wrote: >> >>> Thank you Campbell, Bastien and CoDEmanX for reviewing my code. >>> I have implemented all of your suggestions. >>> All of the issues pointed in this review: >>> https://codereview.appspot.com/7651047/diff/1/node_efficiency_tools.py#newcode103 >>> have been addressed. >>> The review has been done using not the latest version of the script, so >>> some of the suggestions have been implemented earlier. >>> The script with all of those changes is version 2..1.4 and has been >>> committed as revision: 4434. >>> >>> Is it now ok to move it to trunk? >>> >>> Thank you. >>> >>> With Respect >>> Bartek Skorupa >>> >>> www.bartekskorupa.com >>> >>> On 26 mar 2013, at 17:55, Bartek Skorupa (priv) >>> wrote: >>> >>>> Thank you very much. >>>> >>>> Bartek Skorupa >>>> >>>> www.bartekskorupa.com >>>> >>>> On 26 mar 2013, at 17:53, CoDEmanX wrote: >>>> >>>>> if the number of properties you pass to an operator differ, e.g. one >>>>> prop per Custom Property of the active object, then you shouldn't do >>>>> something like >>>>> >>>>> prop1 = ... >>>>> prop2 = ... >>>>> ... >>>>> prop20 = ... >>>>> >>>>> to allow for up to 20 properties be passed to the operator. Why? Cause >>>>> you don't need 20 properties if you mostly need to pass just one or two, >>>>> and there may be situations in which you need more than 20. So a fixed >>>>> amount is really bad. >>>>> >>>>> Instead, you can use a CollectionProperty and add an item for every >>>>> element you need to pass. >>>>> >>>>> Here's an example: >>>>> >>>>> http://www.pasteall.org/40829/python >>>>> >>>>> >>>>> If ideasman is fine with your code, then it's ok to move to trunk! >>>>> >>>>> >>>>> Am 25.03.2013 17:33, schrieb Bartek Skorupa (priv): >>>>>> Hey, >>>>>> @CoDEmanX: >>>>>> I don't quite get what you mean by: >>>>>>> But please don't do this if the amount of props varies (prop1-propN)! >>>>>> Could you elaborate, please? >>>>>> >>>>>> >>>>>> Bartek Skorupa >>>>>> >>>>>> www.bartekskorupa.com >>>>>> >>>>>> On 25 mar 2013, at 17:19, CoDEmanX wrote: >>>>>> >>>>>>> Proper formatting: >>>>>>> >>>>>>> props = layout.operator(NodesLinkActiveToSelected.bl_idname, >>>&
Re: [Bf-committers] Node Efficiency Tools - moved to trunk
Thank you very much Campbell for your changes. I was so excited about possibility to move the Add On to trunk that I missed those other mixed cases that you corrected. Sorry for that and once again - thank you. With Respect Bartek Skorupa www.bartekskorupa.com On 27 mar 2013, at 19:34, Campbell Barton wrote: > On Wed, Mar 27, 2013 at 10:49 PM, Bartek Skorupa (priv) > wrote: >> Final code clean up before moving to trunk: >> revision 4436. >> All suggested changes have been made. >> >> I'd like to ask for final permission before I commit. >> Thank you >> >> With Respect >> >> Bartek Skorupa >> >> www.bartekskorupa.com >> >> On 27 mar 2013, at 11:35, Bartek Skorupa (priv) >> wrote: >> >>> @Campbell >>> Thank you for cleaning up my code of node_efficiency_tools.py (revision >>> 4435) >>> I assume that now it's ready to be moved to trunk, is it? >>> Do I have your permission to do it? >>> >>> Thank you for your time. >>> >>> With Respect >>> Bartek Skorupa >>> >>> >>> Revision: 4435 >>> >>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-extensions&revision=4435 >>> Author: campbellbarton >>> Date: 2013-03-27 10:17:08 + (Wed, 27 Mar 2013) >>> Log Message: >>> --- >>> minor code cleanup >>> >>> Modified Paths: >>> -- >>> contrib/py/scripts/addons/node_efficiency_tools.py >>> >>> >>> >>> >>> On 27 mar 2013, at 09:14, Bartek Skorupa (priv) >>> wrote: >>> >>>> Note about "Select Parent/Children": >>>> This operator allows to select 'FRAME' that wraps selected nodes or >>>> select all of the nodes that are "children" of selected 'FRAME'. >>>> It's done using '[' and ']' keys. >>>> Campbell said that it could be implemented on a higher level, but before >>>> it happens, I'd leave it in my code. >>>> When this option is implemented I'll immediately remove this class from >>>> node_efficiency_tools.py >>>> >>>> Bartek Skorupa >>>> >>>> www.bartekskorupa.com >>>> >>>> On 27 mar 2013, at 09:06, Bartek Skorupa (priv) >>>> wrote: >>>> >>>>> Thank you Campbell, Bastien and CoDEmanX for reviewing my code. >>>>> I have implemented all of your suggestions. >>>>> All of the issues pointed in this review: >>>>> https://codereview.appspot.com/7651047/diff/1/node_efficiency_tools.py#newcode103 >>>>> have been addressed. >>>>> The review has been done using not the latest version of the script, so >>>>> some of the suggestions have been implemented earlier. >>>>> The script with all of those changes is version 2..1.4 and has been >>>>> committed as revision: 4434. >>>>> >>>>> Is it now ok to move it to trunk? >>>>> >>>>> Thank you. >>>>> >>>>> With Respect >>>>> Bartek Skorupa >>>>> >>>>> www.bartekskorupa.com >>>>> >>>>> On 26 mar 2013, at 17:55, Bartek Skorupa (priv) >>>>> wrote: >>>>> >>>>>> Thank you very much. >>>>>> >>>>>> Bartek Skorupa >>>>>> >>>>>> www.bartekskorupa.com >>>>>> >>>>>> On 26 mar 2013, at 17:53, CoDEmanX wrote: >>>>>> >>>>>>> if the number of properties you pass to an operator differ, e.g. one >>>>>>> prop per Custom Property of the active object, then you shouldn't do >>>>>>> something like >>>>>>> >>>>>>> prop1 = ... >>>>>>> prop2 = ... >>>>>>> ... >>>>>>> prop20 = ... >>>>>>> >>>>>>> to allow for up to 20 properties be passed to the operator. Why? Cause >>>>>>> you don't need 20 properties if you mostly need to pass just one or two, >>>>>>> and there may be situations in which you need more than 20. So a fixed >>>>>>> amount is really bad. >>>>>>> >>>>>>>
Re: [Bf-committers] Stereoscopy Implementation Proposal
My 2 cents to the topic (loose thought and presentation of my AddOn for setting Stereo Base): On last Blender Conference in Amsterdam I made a speech about stereoscopy and the way I'm creating stereo stuff in blender now: http://www.youtube.com/watch?v=WD7xzwxhhVU I was working on several stereo animations, some of them to be displayed on 52-inch monitors and some (three of them actually) for cinema screens. No live action was involved in those projects, so my task was a lot easier as I had full control over the final result. I'm really glad that so much effort is put into the matter of stereoscopy implementation in Blender. Having read all of the posts in this thread and the wiki entry I'd like to share some of my loose thoughts: 1. >From user's perspective ability to view stereo when working would be great. 2. WYSIWYG approach in this case is IMHO not good. What I mean by that is: User should have ability to make some post adjustments. It's obvious that correcting depth bracket in post is practically impossible, but post shifting should be made possible. This allows to adjust depth positioning. In my workflow I always render both views using parallel cameras. My goal is to use off-axis approach, but I want to have freedom in post when it comes to shifting images (setting depth positioning). Therefore I always render wider images than I need. This allows me to shift them without losing the edges. Adding those spare pixels after setting everything up is at the moment not possible with one click. We need to change the render resolution. Making the image wider means that the aspect ratio changes. When we manually widen the image (increase X resolution) - our view doesn't get wider, but instead it gets lower, so we lose upper and lower parts of what we saw in our frame before. The workaround is to adjust the focal length accordingly. The math behind it is not that difficult, so it can be done by users who know the stuff, but it would be great to have an option like: "Add 40 pixels on each side" in render settings when working with stereo. If camera shift is possible - widening the image shouldn't IMHO be much of a problem. 3. "left", "right" and "center" cameras: Most of the rigs I came across use the approach of having "center" camera and left/right cameras are accordingly apart from "center". This seems logical, but I agree with Adriano about cons of such approach. (below the quote of Adriano's post). It often happens that we need to "convert" some of our animations to stereo and want to use our existing renders as "left" or "right" view and simply set and render the other camera. Option for using "main" camera as left or right should be definitely added. This of-course means that the pivot of our rig is not in the middle (between the cameras), but my experience shows that it's not a problem in 99.9% of cases. The additional advantage of having "left" or "right" camera at the pivot of the rig is that when we happen to make a mistake in setting Stereo Base - it can be corrected and only one view needs to be re-rendered, not both of them. On 4 kwi 2013, at 00:59, Adriano wrote: > Sugestion: > > It would be nice if we can manage to set an existing camera to be left or > right, and don't me moved at all when we setup planes in stereoscopy. > > This would be very usefull to convert old project to 3d, so we can keep old > renders as left or right and just render one new camera. > > If the addon turns old camera into "center", this is not possible and we > have to render every thing allover again. 4. Interocular Distance / Stereo Base: Lot of effort is put to create user friendly UI, implementing preview capabilities, making rendering easier etc. As I see - the whole idea is very well thought over and everybody here tries to make this consistent, compatible with the standards and easy to use. I really appreciate this. @ Dalai Felinto: In the wiki entry you say as follows: >>>"Later we should be able to expand this functionalities to let the users to >>>work with pixel separation, instead of directly with interocular/plane >>>distances"<<< Here I could offer my help. I have some experience in creating AddOns and some time ago I created the tool for my own use. I didn't publish it though as I thing it's not yet "elegant" enough to be seriously considered for implementation in Blender. However now, when I see a serious work going on in this field, I'd like to share my code and explain how it works, so that everybody knows my way of thinking here. (I made a brief presentation of this in action at Amsterdam's conference. It's the last part of my presentation). The AddOn is designed for off-axis approach and shifting needs to be done after rendering. However only small changes are needed to make shifting before rendering possible. The way it works is as follows: We have the scene with a single camera. We select this camera, hit Shift-Alt-T and the stereo setup is cr
Re: [Bf-committers] Stereoscopy Implementation Proposal
Oops, I was so fixed on standard stereo displayed on screens, that I didn't notice what this presentation is about. Sorry. Cheers Bartek Skorupa Sent from my iPhone On 6 kwi 2013, at 23:27, Harley Acheson wrote: > Bartek, > >> WRONG! When two view of an object are identical it tells your brain that > they are ON THE SCREEN. >> When positive parallax of an object equals the distance between viewer's > eyes - they appear at infinity. > > To be fair, he's not wrong. But neither are you, since you are both talking > about different things... > > You are right in that if you present the same image onto a *screen* in > front of the user then it will appear to be at the depth of the screen > itself. Really no different than a normal 2D image on the screen and the > user can determine the distance to it using convergence. Your right eye > has to look a little to the left, and the left eye rotates a little to the > right, the amount of which your brain uses to gauge the distance. > > However, the presentation was talking about VR headsets like the Oculus > Rift. Present an identical image to each eye on this type of headset and > you no longer have convergence to determine depth. Each eye will stare > straight forward in this case and your brain will therefore place the image > at infinity as was mentioned in the presentation. > > 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
Re: [Bf-committers] Blender 2.67a release AHOY! (again) - addons revision
Hey, In the AHOY call it's said that revision 4542 for addons should be used. I noticed however that the changes that I committed in 4514, 4515, 4534, 4537, 4538 and 4541 are not included in 2.67a release even though they are earlier than 4542. That's a pity as those commits were mostly bug fixes. Is there a reason for that or this is a mistake? (I am talking about Mac OS 64bit version). With Respect, Bartek Skorupa www.bartekskorupa.com On 20 maj 2013, at 23:17, Campbell Barton wrote: > Given some days to make sure no regressions/show-stoppers were > reported, looks like we're really ready this time. > > Information for platform maintainers: > tag: blender-2.67a-release > tag revision: 56914 > addons revision: 4542 > locale revision: 1888 > > To avoid doing a full checkout of svn. > > # first ensure no local changes > svn revert -R . > # check for no additional source files > svn st > # switch to the release tag > svn switch > https://svn.blender.org/svnroot/bf-blender/tags/blender-2.67a-release/blender > > -- > - 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] Blender 2.67a release AHOY! (again) - addons revision
Thank you. Next time I'll do it properly. Bartek Skorupa www.bartekskorupa.com On 24 maj 2013, at 12:14, Campbell Barton wrote: > On Fri, May 24, 2013 at 7:16 PM, Bartek Skorupa (priv) > wrote: >> Hey, >> >> In the AHOY call it's said that revision 4542 for addons should be used. >> I noticed however that the changes that I committed in 4514, 4515, 4534, >> 4537, 4538 and 4541 are not included in 2.67a release even though they are >> earlier than 4542. >> That's a pity as those commits were mostly bug fixes. >> >> Is there a reason for that or this is a mistake? >> (I am talking about Mac OS 64bit version). >> >> With Respect, >> Bartek Skorupa > > This isn't a mistake, for new addon commits to be included in a bugfix > release we would have had to merge them into the addon tag (which we > did for a few fixes), but this doesn't happen automatic. > > Next time reply on the mailing list with bug-fix revisions to be > included. (there was a thread about which revs to include) > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer weekly meeting notes - May 26, 2013
> - Campbell Barton made an initial list of fixes of he likes to see included > in an update: > http://wiki.blender.org/index.php/User:Ideasman42/267b_bugfix Maybe now is the good moment to ask for including some of my commits to addons? I made some changes to node_efficiency_tools.py and most of them fix bugs, so maybe it would be good to have them included. Here's the list of commits: 4514, 4515, 4534, 4537, 4538 and 4541 Thank you in advice. Bartek Skorupa www.bartekskorupa.com On 26 maj 2013, at 17:39, Ton Roosendaal wrote: > Hi all, > > Here are the notes for the weekly developer meeting in irc.freenode.net > #blendercoders > > 1) Blender 2.67a review > > - Right after the 2.67a a couple of bugs were reported and fixed... > especially features that worked in 2.66 before should be in a release. > Proposal is to ask the release team to make a new build this week. > > - Campbell Barton made an initial list of fixes of he likes to see included > in an update: > http://wiki.blender.org/index.php/User:Ideasman42/267b_bugfix > > - We'll review the list in irc and on this list. These will go in the svn > release branch, so we can update a bugfix-2.67 simply. > > - Tuesday an ahoy is expected for it. > > - Meeting spent some time on a review why this happened, it's mix of bad > luck, and too much maintenance work in BCon3/4 periods. In general, keeping a > 'stable' branch around and update as frequently as possible is never bad. > > 2) 2.68 targets > > - Dalai Felinto makes great progress on stereoscopic rendering/compositing > and viewing. https://github.com/dfelinto/blender/tree/multiview > It's unsure still if this will be ready for 2.68. Code review will start > a.s.a.p. > > - Bastien Montagne is almost done with Linux OpenEXR 2.0 install-deps script. > > - Release target list has been updated, We now move to "BCon2": > http://wiki.blender.org/index.php/Dev:Doc/Projects#2.6x_release_cycle > > 3) Other projects > > - Campbell and Sergey Sharybin (and others) are testing converting svn > history to git. There's also tests going on with Phabricator. > > A more formal proposal for git migration is coming, a feasible target for > migration is October this year. > > - Sergey: The Tomato branch has a WIP feature, mask tracking! > http://download.blender.org/ftp/incoming/mask_tracking_test.avi > This is not a release target yet, get the tomato branch for testing. > > - Leap Motion device seed has started, we wait a bit for it to arrive > everywhere. There's a developer from Leap who already added support for the > BGE, he will be connecting with us soonish. > > 4) Google Summer of Code > > - Tomorrow 19 UTC Google will announce the official results. Shortly after > the http://code.blender.org blog will introduce the students and their > projects. > > > > -Ton- > > > Ton Roosendaal - t...@blender.org - www.blender.org > Chairman Blender Foundation - Producer Blender Institute > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer weekly meeting notes - May 26, 2013
… Of course I wanted to thank you IN ADVANCE, not "in advice" :-) Bartek Skorupa www.bartekskorupa.com On 27 maj 2013, at 10:44, Bartek Skorupa (priv) wrote: >> - Campbell Barton made an initial list of fixes of he likes to see included >> in an update: >> http://wiki.blender.org/index.php/User:Ideasman42/267b_bugfix > > Maybe now is the good moment to ask for including some of my commits to > addons? > I made some changes to node_efficiency_tools.py and most of them fix bugs, so > maybe it would be good to have them included. > > Here's the list of commits: > 4514, 4515, 4534, 4537, 4538 and 4541 > > Thank you in advice. > > Bartek Skorupa > > www.bartekskorupa.com > > On 26 maj 2013, at 17:39, Ton Roosendaal wrote: > >> Hi all, >> >> Here are the notes for the weekly developer meeting in irc.freenode.net >> #blendercoders >> >> 1) Blender 2.67a review >> >> - Right after the 2.67a a couple of bugs were reported and fixed... >> especially features that worked in 2.66 before should be in a release. >> Proposal is to ask the release team to make a new build this week. >> >> - Campbell Barton made an initial list of fixes of he likes to see included >> in an update: >> http://wiki.blender.org/index.php/User:Ideasman42/267b_bugfix >> >> - We'll review the list in irc and on this list. These will go in the svn >> release branch, so we can update a bugfix-2.67 simply. >> >> - Tuesday an ahoy is expected for it. >> >> - Meeting spent some time on a review why this happened, it's mix of bad >> luck, and too much maintenance work in BCon3/4 periods. In general, keeping >> a 'stable' branch around and update as frequently as possible is never bad. >> >> 2) 2.68 targets >> >> - Dalai Felinto makes great progress on stereoscopic rendering/compositing >> and viewing. https://github.com/dfelinto/blender/tree/multiview >> It's unsure still if this will be ready for 2.68. Code review will start >> a.s.a.p. >> >> - Bastien Montagne is almost done with Linux OpenEXR 2.0 install-deps script. >> >> - Release target list has been updated, We now move to "BCon2": >> http://wiki.blender.org/index.php/Dev:Doc/Projects#2.6x_release_cycle >> >> 3) Other projects >> >> - Campbell and Sergey Sharybin (and others) are testing converting svn >> history to git. There's also tests going on with Phabricator. >> >> A more formal proposal for git migration is coming, a feasible target for >> migration is October this year. >> >> - Sergey: The Tomato branch has a WIP feature, mask tracking! >> http://download.blender.org/ftp/incoming/mask_tracking_test.avi >> This is not a release target yet, get the tomato branch for testing. >> >> - Leap Motion device seed has started, we wait a bit for it to arrive >> everywhere. There's a developer from Leap who already added support for the >> BGE, he will be connecting with us soonish. >> >> 4) Google Summer of Code >> >> - Tomorrow 19 UTC Google will announce the official results. Shortly after >> the http://code.blender.org blog will introduce the students and their >> projects. >> >> >> >> -Ton- >> >> >> Ton Roosendaal - t...@blender.org - www.blender.org >> Chairman Blender Foundation - Producer Blender Institute >> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands >> >> >> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.67b release AHOY!
Hi, It seems that I made a mistake that I would like to apologize for. On May 27th I made a list of my commits that I wanted to be included in 2.67b release. It is all related to node_efficiency_tools.py add on. In trunk the version is ok, but in my list I omitted one very important commit that removed one syntax error. My list was as follows: Here's the list of commits: 4514, 4515, 4534, 4537, 4538 and 4541 I ommited commit 4539 that was: Revision: 4539 http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-extensions&revision=4539 Author: bartekskorupa Date: 2013-05-17 17:45:56 + (Fri, 17 May 2013) Log Message: --- Bug fix. Simple syntax error. Sorry Modified Paths: -- trunk/py/scripts/addons/node_efficiency_tools.py Modified: trunk/py/scripts/addons/node_efficiency_tools.py === --- trunk/py/scripts/addons/node_efficiency_tools.py2013-05-17 17:20:20 UTC (rev 4538) +++ trunk/py/scripts/addons/node_efficiency_tools.py2013-05-17 17:45:56 UTC (rev 4539) @@ -1124,7 +1124,7 @@ valid = False if (space.type == 'NODE_EDITOR' and space.node_tree is not None and -context.active_node is not None and +context.active_node is not None ): valid = True return valid Because this commit was omitted now in official release we have syntax error. This is my mistake. I did fix the bug, but when creating list of commits to be included I omitted this very important one. I am very sorry for that. Is there any way of fixing this at this point? With Respect Bartek Skorupa www.bartekskorupa.com On 29 maj 2013, at 19:51, Campbell Barton wrote: > Lets hope this is the last 2.67 release :) > > Information for platform maintainers: > tag: blender-2.67b-release > tag revision: 57123 > addons revision: 4542 > locale revision: 1888 > > To avoid doing a full checkout of svn. > > # first ensure no local changes > svn revert -R . > # check for no additional source files > svn st > # switch to the release tag > svn switch > https://svn.blender.org/svnroot/bf-blender/tags/blender-2.67b-release/blender > > For reference, list of revs merged: > http://wiki.blender.org/index.php/User:Ideasman42/267b_bugfix > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.67b release AHOY!
Hi Ton, This is a good lesson for me. I am very sorry for what happened. With Respect Bartek Skorupa www.bartekskorupa.com On 31 maj 2013, at 10:21, Ton Roosendaal wrote: > Hi Bartek, > > For our releases we try to keep everyone stick to "only add crucial fixes" in > the last weeks before a release, and certainly for an 'a' update. > > I've just checked a few of your commits, but it appears to be regular > maintenance and development work as well. > > Add-ons in a release should go via the same ruling as the rest of code. I am > not following the add-on tracker commit mails though, might well be happening > already :) > > Anyway - perfect releases don't exist. I propose to add a short note on the > download page about the Node Efficiency Tools and link to where the update > can be loaded. > > We're now 3 weeks after the 2.67 release too, with a bi-monthly cycle a next > release would happen within 5-6 six weeks anyway. Let's try to do better next > time, and just communicate well about unfortunate errors. > > -Ton- > > > Ton Roosendaal - t...@blender.org - www.blender.org > Chairman Blender Foundation - Producer Blender Institute > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > > > On 30 May, 2013, at 20:36, Bartek Skorupa (priv) wrote: > >> Hi, >> >> It seems that I made a mistake that I would like to apologize for. >> On May 27th I made a list of my commits that I wanted to be included in >> 2.67b release. >> It is all related to node_efficiency_tools.py add on. >> >> In trunk the version is ok, but in my list I omitted one very important >> commit that removed one syntax error. >> My list was as follows: >> >> Here's the list of commits: >> 4514, 4515, 4534, 4537, 4538 and 4541 >> >> I ommited commit 4539 that was: >> >> Revision: 4539 >> >> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-extensions&revision=4539 >> Author: bartekskorupa >> Date: 2013-05-17 17:45:56 + (Fri, 17 May 2013) >> Log Message: >> --- >> Bug fix. Simple syntax error. Sorry >> >> Modified Paths: >> -- >> trunk/py/scripts/addons/node_efficiency_tools.py >> >> Modified: trunk/py/scripts/addons/node_efficiency_tools.py >> === >> --- trunk/py/scripts/addons/node_efficiency_tools.py 2013-05-17 17:20:20 UTC >> (rev 4538) >> +++ trunk/py/scripts/addons/node_efficiency_tools.py 2013-05-17 17:45:56 UTC >> (rev 4539) >> @@ -1124,7 +1124,7 @@ >> valid = False >> if (space.type == 'NODE_EDITOR' and >> space.node_tree is not None and >> -context.active_node is not None and >> +context.active_node is not None >> ): >> valid = True >> return valid >> >> Because this commit was omitted now in official release we have syntax error. >> This is my mistake. I did fix the bug, but when creating list of commits to >> be included I omitted this very important one. >> I am very sorry for that. >> Is there any way of fixing this at this point? >> >> With Respect >> Bartek Skorupa >> >> www.bartekskorupa.com >> >> On 29 maj 2013, at 19:51, Campbell Barton wrote: >> >>> Lets hope this is the last 2.67 release :) >>> >>> Information for platform maintainers: >>> tag: blender-2.67b-release >>> tag revision: 57123 >>> addons revision: 4542 >>> locale revision: 1888 >>> >>> To avoid doing a full checkout of svn. >>> >>> # first ensure no local changes >>> svn revert -R . >>> # check for no additional source files >>> svn st >>> # switch to the release tag >>> svn switch >>> https://svn.blender.org/svnroot/bf-blender/tags/blender-2.67b-release/blender >>> >>> For reference, list of revs merged: >>> http://wiki.blender.org/index.php/User:Ideasman42/267b_bugfix >>> ___ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-extensions-cvs] [ff8ac35] master: Merge branch 'master' of git.blender.org:blender-addons
It seems that this "merge" just reverted two of my commits in addons. Should I re-commit? I don't want to create more mess. Bartek Skorupa www.bartekskorupa.com On 18 lis 2013, at 20:21, Maurice Raybaud wrote: > Commit: ff8ac3525a3efc19cc598fe12411084dc2e42464 > Author: Maurice Raybaud > Date: Mon Nov 18 20:08:16 2013 +0100 > http://developer.blender.org/rBAff8ac3525a3efc19cc598fe12411084dc2e42464 > > Merge branch 'master' of git.blender.org:blender-addons > > === > > > > === > > > > ___ > Bf-extensions-cvs mailing list > bf-extensions-...@blender.org > http://lists.blender.org/mailman/listinfo/bf-extensions-cvs ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
