Re: [Bf-committers] Color space and alpha issues
Re wiki page: When explaining math behind mixing "Over" image with background (straight alpha) it should be: [(Over.RGB * Over.Alpha) + (Background.RGB * (1 - Over.Alpha))]. Formula at the page is: [(Over.RGB * Over.Alpha) + Background.RGB]. Shouldn't it be corrected? In my opinion it should be as follows: "over" image mixed with "normal" blending mode, or "mix" blending mode: [(Over.RGB * Over.Alpha) + (Background.RGB * (1 - Over.Alpha))] "over" image mixed with "Add" blending mode: [((Over.RGB + Background.RGB) * Over.Alpha) + (Background.RGB * (1 - Over.Alpha))]. "over" image mixed with "Multiply" blending mode: [((Over.RGB * Background.RGB) * Over.Alpha) + (Background.RGB * (1 - Over.Alpha))]. Other blending modes - accordingly to their math. Bartek Skorupa On 2011-12-15, at 15:31, Brecht Van Lommel wrote: > Hi, > > Color management and alpha issues are a recurring topic, I've written > a wiki page explaining issues with the current code and what I think > should be done to solve them: > http://wiki.blender.org/index.php/Dev:Source/Image/Color > > You might notice I'm not really mentioning OIIO/OCIO. It's a nice > project to integrate those, but it doesn't solve current issues and is > fairly orthogonal to the proposed changes. > > I might not have time to tackle this for 2.62, but it doesn't > necessarily need to be done all in one big change. Feedback welcome, > about what you think should be done different, and which alpha format > convention should be used? > > Thanks, > Brecht. > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender App Central / Add-on Manager
I must disagree with you on that All add-ons or scripts are for users, not for developers. If I want my addon to be used only by me - I wouldn't have made it public in a first place. Believe it or not, but current system is way too difficult for artists. Artists don't have a clue what SVN and other such things are and they will never learn because this is not their field. There are several scripts or addons that people don't know about because it's simply impossible to find them for "human being". If I know how to write a script, decided to maintain it - it shouldn't be that hard to follow some rules. I personally maintain a simple script and don't find that very hard to take care about all required stuff. Script without documentation is worth absolutely nothing, no matter how fantastic it is. If it can be used only by its developer? Who needs it? Cheers Bartek Skorupa On 2012-01-09, at 16:19, Aurel W. wrote: > Another managment overlay for scripts? The current scheme is already > way too bureaucratic, wikipages, script tracker, svn,... all sorts of > conventions. It's hard what you have to care about, when you just want > to maintain a simple script. > > aurel > > On 9 January 2012 15:23, Ton Roosendaal wrote: >> Hi Moraes, >> >> Good you remind us, and a promising concept this... it is probably >> well possible to make this work inside a browser and somehow hook >> it up via python with Blender itself. Makes it more feasible to >> implement too. >> >> Next steps could also be to add import/exporters, themes, default >> startup blends, material repositories, node groups... or then even >> docs, tutorials, video tuts? >> >> And then the obvious question pops up "But would it allow >> commercial offers too?". I am well aware of the success of Mac's >> appstore, Android Market and Ubuntu Centre. >> >> It's something we could carefully look into and investigate. >> Blender Foundation/Instutute is doing good bizz still selling dvds >> and books, but that won't last forever. Selling (licensed) digital >> data is not something BF itself should do though, we have a mission >> to keep things free and open. >> >> However; there must be ways to cooperate with a 'closed' world, >> especially if the boundary is clear, and when the spirit of our >> project is not in danger (Blender as a full functional open and >> free environment for 3d creation). >> >> -Ton- >> >> >> Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org >> Blender Institute Entrepotdok 57A 1018AD Amsterdam The >> Netherlands >> >> On 9 Jan, 2012, at 14:22, Mango Jambo wrote: >> >>> Hi all, >>> >>> At Blender Pro, the Blender conference Brazil, I was talking to >>> Ton, Dalai, >>> Pablo Vasquez and other artists about a great idea for Blender: >>> the Blender >>> Addon/App Central. >>> >>> *The problem today:* >>> - It is hard to find an add-on if you never did before; >>> - Even if you did it, you need to find it again: Blender.org > >>> Download > >>> wiki Python Scripts (add-ons?) > Script Catalog; >>> - Some of them gives an outside link to download, like >>> blenderartist, >>> dropbox, etc.; >>> - To install you need to Download and then install by Blender Add-on >>> install button or copy straight to the add-on folder (and find this >>> folder). Some Add-ons has folders and other files, so the install >>> button >>> doesn't work for it; >>> - We never know if there is a new add-on version (Contrib and >>> External); >>> - We don't know which add-ons are most downloaded or even users >>> feedback >>> about it. Well, there is some Blenderartists threads, but nothing >>> more >>> "official" about it; >>> - Every time we need to install Blender in another computer, we >>> need to >>> copy/download add-ons again. Some people makes use of Dropbox for >>> it, or >>> copy the Blender user Preferences Folder, but it is not a casual >>> task >>> (mainly for artists, thrust me! ;] ); >>> >>> *Proposal* >>> To transform the current Script Catalog into a friendly and >>> intuitive >>> Add-on/App Manager inside Blender, showing votes, comments, updates, >>> favorites, etc. and, option
Re: [Bf-committers] Render Layer Proposal
Before I start commenting, let me say that I am with you and also think that the way Render Layers are rendered could get some improvements. I fully agree that it would be very useful to have an option to automatically render every pass of every render layer to separate folder without having to go through the pain of dozens of File Outputs. I have however a few questions: > *Only 1 RenderLayer* > You can't use the power of RenderLayer when saving into file > sequence! By > that I mean using more than 1 RenderLayer with each of them having > specific > parameters (Layers, mat overall, certain passes). > Only the first RenderLayer get rendered the other one are ignore. > This mean > using the power of this feature is only available if you are using B's > compositor otherwise it is useless. What do you mean saying that "Only the first RenderLayer gets rendered"? When you render to MultiLayer exr - all passes of all render layers get stored. > *Only Combined get Saved* > Probably the worst part. If you have checked multiple passes, but > didn't > save into a Multi-layer file format (ie exr), then the passes are > useless. I don't quite follow. If you really want to store all of the passes - you simply select MultiLayer as a format and you're done. You can add in in compositor in some other file if you wish and have full access to all of the passes of all of the render layers. I don't fully understand what you mean here. Cheers Bartek Skorupa www.bartekskorupa.com On 2012-01-16, at 21:46, François T. wrote: > Hi everyone, > > Yet another proposal, so I know nobody have times for proposal and > stuff > but since I passed the entire day linking renderlayers passes to > fileOut > one by one, my head hurts ! So I have to give it a shot ! > Once again, I guess I'm the only one using Blender with other apps > because > I really don't understand how people can stand the current workflow. > > I'm working on a project where all 3D is done in Blender and > composited in > AE. AE does support EXR multilayer extraction, but its via plugin (not > native as in Nuke) so it is slow (especially if you working in 32bpc > HD). > So I decided to render each 3D passes (in my case Combined, Z, > Diffuse, > Spec, Color, Velocity, UV and AO) to its own file sequences and here > are > all the bumps I got. > > *Only 1 RenderLayer* > You can't use the power of RenderLayer when saving into file > sequence! By > that I mean using more than 1 RenderLayer with each of them having > specific > parameters (Layers, mat overall, certain passes). > Only the first RenderLayer get rendered the other one are ignore. > This mean > using the power of this feature is only available if you are using B's > compositor otherwise it is useless. > > *Only Combined get Saved* > Probably the worst part. If you have checked multiple passes, but > didn't > save into a Multi-layer file format (ie exr), then the passes are > useless. > To do so you have to (except if I missed something) : > - turn ON the compositor > - plug a pass to a FileOut Node > - setup the FileOut Node > - repeat the step for each passes > - leave a Compositor Node (otherwise it refuse to render the > animation) > which will create another file sequence in the output folder you > defined in > your Render settings (extra useless GB used on my harddrive) > > Yes, I could probably create a quick and dirty python scripts which > will do > all that for me in one click! But this is not the point since, > correct me > if I'm wrong, I think that going through the compositor only to do > that is > slowing down the render time and play with memories and stuff for > nothing. > Its like combining passes, to seperate them again to save them into > different files o_O > > Plus on top of that, even with a python script, this workflow is > still a > pain in the *** > > > > *Proposal* > > The idea would be to bypass all this nightmare in case you have : > - more than 1 renderLayer turn ON > - AND/OR more than 1 pass checked > - you didn't select a Multi-Layer file format > - the compositor is not turn OFF > > Then all we have to do is using RenderLayers name and passes name to > construct the file path as : > > render.folderPath + "/" + sceneRenderLayer.name + "/" + > render.fileName + >> "_" + PassName + .EXT > > > *note that in this case seperating the render.folderPath and the > render.fileName would also be a change to the actual render.FilePath* > * > * > Yet I don't know how complicated it would be to
[Bf-committers] bpy.context.scene.frame_set(i) issue
Hi, I'd like to draw your attention to frame_set(i) method. In many scripts we have to refresh the scene several times, sometimes we need to collect some data for every frame in the whole animation. In such cases the only way I know in blender's python is to set the frame using bpy.context.scene.frame_set(frame) Almost every exporter that base on baking the data and exporting them as "keyframe for every frame" use this kind of loop: start = bpy.context.scene.frame_start end = bpy.context.scene.frame_end for frame in range (start, end + 1): bpy.context.scene.frame_set(frame) ''' all the magic that needs data for each frame ''' My exporter to Adobe After Effects (io_export_after_effects.py) does exactly the same. The issue here is that setting the frame sometimes takes ages. I was once advised to use bpy.context.frame_current = frame Well... It's very fast, but doesn't do the trick. It sets the frame, but doesn't update the scene and in most cases - this is what we want - We want to have our scene refreshed for every frame. bpy.context.scene.frame_set(frame) method is so slow, that many exporters become almost useless or if not useless - very badly perceived because of their performance. The process of simple export to After Effects can sometimes take several minutes and this is definitely not the performance we are looking for. I looked through many existing exporters and they all use this method, so I suppose I'm not the only one facing "frame_set" speed issue. Does anyone know other method to achieve refreshing the scene for every frame, but not that slow? Isn't this performance a bug of some kind? I'd appreciate any help. 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] bpy.context.scene.frame_set(i) issue
1. Take any scene that plays back 1 frame per second or so. (I can't upload any example now, but I'm sure everybody has such scene somewhere). Many objects (2000?, 3000?), constraints, shapekeys, armatures, curves etc. 2. No matter if the layers are active or not, no matter what the draw mode is etc - it is slow. I can place all of my obs in layer 2, activate only empty layer 1, and it doesn't influence the speed. 3. Even if frame_set() is as fast as playback - I'm not happy. 250 frames - 1 frame per second = 250sec. = 4 minutes. Who wants to wait 4 minutes? Bartek Skorupa www.bartekskorupa.com On 2012-01-21, at 00:58, Campbell Barton wrote: > Hi Bartek, > > Would you be able to upload a test scene which is unusably slow? > can't see why this would be any slower then playing back the animation > (if anything should be faster since it doesn't have to draw). > > On Sat, Jan 21, 2012 at 9:58 AM, Bartek Skorupa > wrote: >> Hi, >> >> I'd like to draw your attention to frame_set(i) method. >> In many scripts we have to refresh the scene several times, sometimes >> we need to collect some data for every frame in the whole animation. >> In such cases the only way I know in blender's python is to set the >> frame using bpy.context.scene.frame_set(frame) >> Almost every exporter that base on baking the data and exporting them >> as "keyframe for every frame" use this kind of loop: >> >> start = bpy.context.scene.frame_start >> end = bpy.context.scene.frame_end >> for frame in range (start, end + 1): >> bpy.context.scene.frame_set(frame) >> ''' >> all the magic that needs data for each frame >> ''' >> >> My exporter to Adobe After Effects (io_export_after_effects.py) does >> exactly the same. >> >> The issue here is that setting the frame sometimes takes ages. >> I was once advised to use bpy.context.frame_current = frame >> Well... It's very fast, but doesn't do the trick. It sets the frame, >> but doesn't update the scene and in most cases - this is what we want >> - We want to have our scene refreshed for every frame. >> >> bpy.context.scene.frame_set(frame) method is so slow, that many >> exporters become almost useless or if not useless - very badly >> perceived because of their performance. >> The process of simple export to After Effects can sometimes take >> several minutes and this is definitely not the performance we are >> looking for. >> I looked through many existing exporters and they all use this >> method, >> so I suppose I'm not the only one facing "frame_set" speed issue. >> Does anyone know other method to achieve refreshing the scene for >> every frame, but not that slow? >> >> Isn't this performance a bug of some kind? >> >> I'd appreciate any help. >> >> Cheers, >> Bartek Skorupa >> >> www.bartekskorupa.com >> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > > > > -- > - Campbell > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] bpy.context.scene.frame_set(i) issue
Thank you very much for that.
I will try it and maybe it will do the trick.
I wonder however if it updates objects when their matrices depend on
other objects not included in selection (parenting, constraints, etc).
Anyway, thank you very much, I'll see if it improves anything.
Bartek Skorupa
www.bartekskorupa.com
On 2012-01-21, at 11:54, Campbell Barton wrote:
frame_set() updates all layers of the scene which I expect is the
problem here,
there could be an optional argument to pass a layer list to
frame_set() but this doesn't necessarily help if the current scene
layers are not setup efficiently.
looking into this you could update only the objects you want like
this...
# objects to update
objects = bpy.context.selected_objects
scene = bpy.context.scene
start = scene.frame_start
end = scene.frame_end
for frame in range (start, end + 1):
scene.frame_current = frame
for obj in objects:
obj.update_tag(refresh={'OBJECT'}) # 'DATA' too if you care
about geometry
scene.update()
'''
all the magic that needs data for each frame ....
'''
On Sat, Jan 21, 2012 at 7:56 PM, Bartek Skorupa
wrote:
1. Take any scene that plays back 1 frame per second or so. (I can't
upload any example now, but I'm sure everybody has such scene
somewhere). Many objects (2000?, 3000?), constraints, shapekeys,
armatures, curves etc.
2. No matter if the layers are active or not, no matter what the draw
mode is etc - it is slow. I can place all of my obs in layer 2,
activate only empty layer 1, and it doesn't influence the speed.
3. Even if frame_set() is as fast as playback - I'm not happy. 250
frames - 1 frame per second = 250sec. = 4 minutes. Who wants to
wait 4
minutes?
Bartek Skorupa
www.bartekskorupa.com
On 2012-01-21, at 00:58, Campbell Barton wrote:
Hi Bartek,
Would you be able to upload a test scene which is unusably slow?
can't see why this would be any slower then playing back the
animation
(if anything should be faster since it doesn't have to draw).
On Sat, Jan 21, 2012 at 9:58 AM, Bartek Skorupa
wrote:
Hi,
I'd like to draw your attention to frame_set(i) method.
In many scripts we have to refresh the scene several times,
sometimes
we need to collect some data for every frame in the whole
animation.
In such cases the only way I know in blender's python is to set the
frame using bpy.context.scene.frame_set(frame)
Almost every exporter that base on baking the data and exporting
them
as "keyframe for every frame" use this kind of loop:
start = bpy.context.scene.frame_start
end = bpy.context.scene.frame_end
for frame in range (start, end + 1):
bpy.context.scene.frame_set(frame)
'''
all the magic that needs data for each frame
'''
My exporter to Adobe After Effects (io_export_after_effects.py)
does
exactly the same.
The issue here is that setting the frame sometimes takes ages.
I was once advised to use bpy.context.frame_current = frame
Well... It's very fast, but doesn't do the trick. It sets the
frame,
but doesn't update the scene and in most cases - this is what we
want
- We want to have our scene refreshed for every frame.
bpy.context.scene.frame_set(frame) method is so slow, that many
exporters become almost useless or if not useless - very badly
perceived because of their performance.
The process of simple export to After Effects can sometimes take
several minutes and this is definitely not the performance we are
looking for.
I looked through many existing exporters and they all use this
method,
so I suppose I'm not the only one facing "frame_set" speed issue.
Does anyone know other method to achieve refreshing the scene for
every frame, but not that slow?
Isn't this performance a bug of some kind?
I'd appreciate any help.
Cheers,
Bartek Skorupa
www.bartekskorupa.com
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
--
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
--
- 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] bpy.context.scene.frame_set(i) issue
Tried it and it doesn't work unfortunately.
It simply doesn't update :-(
Tried with a default scene where I added keyframes for cube's location
and printed locations for every frame. It showed exactly the same
values throughout the animation.
Bartek Skorupa
www.bartekskorupa.com
On 2012-01-21, at 11:54, Campbell Barton wrote:
frame_set() updates all layers of the scene which I expect is the
problem here,
there could be an optional argument to pass a layer list to
frame_set() but this doesn't necessarily help if the current scene
layers are not setup efficiently.
looking into this you could update only the objects you want like
this...
# objects to update
objects = bpy.context.selected_objects
scene = bpy.context.scene
start = scene.frame_start
end = scene.frame_end
for frame in range (start, end + 1):
scene.frame_current = frame
for obj in objects:
obj.update_tag(refresh={'OBJECT'}) # 'DATA' too if you care
about geometry
scene.update()
'''
all the magic that needs data for each frame
'''
On Sat, Jan 21, 2012 at 7:56 PM, Bartek Skorupa
wrote:
1. Take any scene that plays back 1 frame per second or so. (I can't
upload any example now, but I'm sure everybody has such scene
somewhere). Many objects (2000?, 3000?), constraints, shapekeys,
armatures, curves etc.
2. No matter if the layers are active or not, no matter what the draw
mode is etc - it is slow. I can place all of my obs in layer 2,
activate only empty layer 1, and it doesn't influence the speed.
3. Even if frame_set() is as fast as playback - I'm not happy. 250
frames - 1 frame per second = 250sec. = 4 minutes. Who wants to
wait 4
minutes?
Bartek Skorupa
www.bartekskorupa.com
On 2012-01-21, at 00:58, Campbell Barton wrote:
Hi Bartek,
Would you be able to upload a test scene which is unusably slow?
can't see why this would be any slower then playing back the
animation
(if anything should be faster since it doesn't have to draw).
On Sat, Jan 21, 2012 at 9:58 AM, Bartek Skorupa
wrote:
Hi,
I'd like to draw your attention to frame_set(i) method.
In many scripts we have to refresh the scene several times,
sometimes
we need to collect some data for every frame in the whole
animation.
In such cases the only way I know in blender's python is to set the
frame using bpy.context.scene.frame_set(frame)
Almost every exporter that base on baking the data and exporting
them
as "keyframe for every frame" use this kind of loop:
start = bpy.context.scene.frame_start
end = bpy.context.scene.frame_end
for frame in range (start, end + 1):
bpy.context.scene.frame_set(frame)
'''
all the magic that needs data for each frame
'''
My exporter to Adobe After Effects (io_export_after_effects.py)
does
exactly the same.
The issue here is that setting the frame sometimes takes ages.
I was once advised to use bpy.context.frame_current = frame
Well... It's very fast, but doesn't do the trick. It sets the
frame,
but doesn't update the scene and in most cases - this is what we
want
- We want to have our scene refreshed for every frame.
bpy.context.scene.frame_set(frame) method is so slow, that many
exporters become almost useless or if not useless - very badly
perceived because of their performance.
The process of simple export to After Effects can sometimes take
several minutes and this is definitely not the performance we are
looking for.
I looked through many existing exporters and they all use this
method,
so I suppose I'm not the only one facing "frame_set" speed issue.
Does anyone know other method to achieve refreshing the scene for
every frame, but not that slow?
Isn't this performance a bug of some kind?
I'd appreciate any help.
Cheers,
Bartek Skorupa
www.bartekskorupa.com
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
--
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
--
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Nodes auto hide sockets on collapsed nodes
Hello, Am I the only one who hates auto hide sockets when we hit H to collapse the node? Collapsing the node doesn't mean that I will not want to connect anything to it later. In older versions of Blender when we hit H - the node was collapsed but we had the access to its sockets. Now when I hit H - the node becomes useless. If I want to connect anything to it I have to first unhide it, then connect something to it, then hide it again. It's frustrating because I have to go through some unnecessary steps just to make a simple connection. Please tell me - am I the only one? 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] Nodes auto hide sockets on collapsed nodes
If I understand you correctly you mean not being able to select individual socket and connect to the selected one? If so - I've been fighting for bringing this feature back for some time now. In 2.49 we could simply select the output socket of one node, input socket of another node, hit F and BAM - connection created. Now it's gone. Imagine node group with 17 outputs and another node group with 17 inputs. Let's now connect output 7 of first group to input 16 of second group... You have to drag the connection holding down the mouse button. It's ok when your groups are placed close to each other, but that's not always the case. or: We have Render Layer input node with several passes. Let's connect AO pass to 5 inputs of 5 other nodes. It would be great to be able to select AO output socket then shift select ALL of the inputs, hit F and have all 5 connections. and once again: Please, please, please don't force me to unhide every node to make a connection by auto hiding unused sockets in collapsed nodes. What was wrong with leaving the option to the user? If I really wanted to hide unused sockets I could hit Ctl-H. Bartek Skorupa www.bartekskorupa.com On 2012-04-08, at 22:19, Daniel Salazar - 3Developer.com wrote: Connecting to some random nameless socket was not good either.. -1 Daniel Salazar patazstudio.com On Sun, Apr 8, 2012 at 2:13 PM, Davis Sorenson >wrote: You're not the only one. :) I can also confirm this is very confusing, I nearly reported a bug the first time I came across this (I think I eventually figured it out). I don't think this should be a default. Davis On Sun, Apr 8, 2012 at 11:03 PM, Bartek Skorupa < bartekskor...@bartekskorupa.com> wrote: Hello, Am I the only one who hates auto hide sockets when we hit H to collapse the node? Collapsing the node doesn't mean that I will not want to connect anything to it later. In older versions of Blender when we hit H - the node was collapsed but we had the access to its sockets. Now when I hit H - the node becomes useless. If I want to connect anything to it I have to first unhide it, then connect something to it, then hide it again. It's frustrating because I have to go through some unnecessary steps just to make a simple connection. Please tell me - am I the only one? 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 auto hide sockets on collapsed nodes
In many cases I do. Believe it or not :-) If I don't like such collapsed node, I can hit Ctl-H and unused sockets are hidden. It was so up till 2.61. Let me then ask another question: What's good with this one? http://www.pasteall.org/pic/29810 How would you connect those nodes? Bartek Skorupa www.bartekskorupa.com On 2012-04-08, at 23:20, Daniel Salazar - 3Developer.com wrote: What's wrong you ask? this is what's wrong http://www.pasteall.org/pic/29809 unless you're a psychic how do you know what each of those sockets is! Daniel Salazar patazstudio.com On Sun, Apr 8, 2012 at 3:15 PM, Bartek Skorupa < bartekskor...@bartekskorupa.com> wrote: If I understand you correctly you mean not being able to select individual socket and connect to the selected one? If so - I've been fighting for bringing this feature back for some time now. In 2.49 we could simply select the output socket of one node, input socket of another node, hit F and BAM - connection created. Now it's gone. Imagine node group with 17 outputs and another node group with 17 inputs. Let's now connect output 7 of first group to input 16 of second group... You have to drag the connection holding down the mouse button. It's ok when your groups are placed close to each other, but that's not always the case. or: We have Render Layer input node with several passes. Let's connect AO pass to 5 inputs of 5 other nodes. It would be great to be able to select AO output socket then shift select ALL of the inputs, hit F and have all 5 connections. and once again: Please, please, please don't force me to unhide every node to make a connection by auto hiding unused sockets in collapsed nodes. What was wrong with leaving the option to the user? If I really wanted to hide unused sockets I could hit Ctl-H. Bartek Skorupa www.bartekskorupa.com On 2012-04-08, at 22:19, Daniel Salazar - 3Developer.com wrote: Connecting to some random nameless socket was not good either.. -1 Daniel Salazar patazstudio.com On Sun, Apr 8, 2012 at 2:13 PM, Davis Sorenson > **wrote: You're not the only one. :) I can also confirm this is very confusing, I nearly reported a bug the first time I came across this (I think I eventually figured it out). I don't think this should be a default. Davis On Sun, Apr 8, 2012 at 11:03 PM, Bartek Skorupa < bartekskorupa@bartekskorupa.**com > wrote: Hello, Am I the only one who hates auto hide sockets when we hit H to collapse the node? Collapsing the node doesn't mean that I will not want to connect anything to it later. In older versions of Blender when we hit H - the node was collapsed but we had the access to its sockets. Now when I hit H - the node becomes useless. If I want to connect anything to it I have to first unhide it, then connect something to it, then hide it again. It's frustrating because I have to go through some unnecessary steps just to make a simple connection. Please tell me - am I the only one? Cheers Bartek Skorupa www.bartekskorupa.com __**_ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/**mailman/listinfo/bf-committers<http://lists.blender.org/mailman/listinfo/bf-committers > __**_ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/**mailman/listinfo/bf-committers<http://lists.blender.org/mailman/listinfo/bf-committers > __**_ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/**mailman/listinfo/bf-committers<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 auto hide sockets on collapsed nodes
I'd say something like this: If I am one of not so many, let it be. Let's leave auto hide sockets when collapsing the node, but could we have the option to hit Ctl-H to unhide them if we want? I know that Lukas can do EVERYTHING :-) The point here is to agree what option would make the majority happy, right? But still... If I as a member of the minority had the option to unhide hidden sockets of collapsed nodes - I don't think it would make any harm to the majority who loves to have them always hidden :-) Bartek Skorupa www.bartekskorupa.com On 2012-04-08, at 23:38, Daniel Salazar - 3Developer.com wrote: Easy, because Lukas will read this thread and say "HEY! I could make the sockets visible of only the nodes close to the mouse when hovering over them" :D Daniel Salazar patazstudio.com On Sun, Apr 8, 2012 at 3:27 PM, Bartek Skorupa < bartekskor...@bartekskorupa.com> wrote: In many cases I do. Believe it or not :-) If I don't like such collapsed node, I can hit Ctl-H and unused sockets are hidden. It was so up till 2.61. Let me then ask another question: What's good with this one? http://www.pasteall.org/pic/**29810 <http://www.pasteall.org/pic/29810 > How would you connect those nodes? Bartek Skorupa www.bartekskorupa.com On 2012-04-08, at 23:20, Daniel Salazar - 3Developer.com wrote: What's wrong you ask? this is what's wrong http://www.pasteall.org/pic/**29809 <http://www.pasteall.org/pic/29809 > unless you're a psychic how do you know what each of those sockets is! Daniel Salazar patazstudio.com On Sun, Apr 8, 2012 at 3:15 PM, Bartek Skorupa < bartekskorupa@bartekskorupa.**com > wrote: If I understand you correctly you mean not being able to select individual socket and connect to the selected one? If so - I've been fighting for bringing this feature back for some time now. In 2.49 we could simply select the output socket of one node, input socket of another node, hit F and BAM - connection created. Now it's gone. Imagine node group with 17 outputs and another node group with 17 inputs. Let's now connect output 7 of first group to input 16 of second group... You have to drag the connection holding down the mouse button. It's ok when your groups are placed close to each other, but that's not always the case. or: We have Render Layer input node with several passes. Let's connect AO pass to 5 inputs of 5 other nodes. It would be great to be able to select AO output socket then shift select ALL of the inputs, hit F and have all 5 connections. and once again: Please, please, please don't force me to unhide every node to make a connection by auto hiding unused sockets in collapsed nodes. What was wrong with leaving the option to the user? If I really wanted to hide unused sockets I could hit Ctl-H. Bartek Skorupa www.bartekskorupa.com On 2012-04-08, at 22:19, Daniel Salazar - 3Developer.com wrote: Connecting to some random nameless socket was not good either.. -1 Daniel Salazar patazstudio.com On Sun, Apr 8, 2012 at 2:13 PM, Davis Sorenson < davis.soren...@gmail.com> **wrote: You're not the only one. :) I can also confirm this is very confusing, I nearly reported a bug the first time I came across this (I think I eventually figured it out). I don't think this should be a default. Davis On Sun, Apr 8, 2012 at 11:03 PM, Bartek Skorupa < bartekskorupa@bartekskorupa.com > wrote: Hello, Am I the only one who hates auto hide sockets when we hit H to collapse the node? Collapsing the node doesn't mean that I will not want to connect anything to it later. In older versions of Blender when we hit H - the node was collapsed but we had the access to its sockets. Now when I hit H - the node becomes useless. If I want to connect anything to it I have to first unhide it, then connect something to it, then hide it again. It's frustrating because I have to go through some unnecessary steps just to make a simple connection. Please tell me - am I the only one? Cheers Bartek Skorupa www.bartekskorupa.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers<http://lists.blender.org/**mailman/listinfo/bf-committers > **<http://lists.blender.org/**mailman/listinfo/bf-committers<http://lists.blender.org/mailman/listinfo/bf-committers > **> ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers<http://lists.blender.org/**mailman/listinfo/bf-committers > **<http://lists.blender.org/**mailman/listinfo/bf-committers<http://lists.blender.org/mailman/listinfo/bf-committers > **
Re: [Bf-committers] Nodes auto hide sockets on collapsed nodes
Hey Lukas, Thank you for your reply and for bringing back individual sockets selection. I missed it because now you select socket by left clicking. I was trying to select them by right clicking (as it was in 2.49) and when it failed I was sure we still don't have this option available. This feature is a real time saver. I'm really glad you are thinking about improving it. I'm sure you'll come up with the best possible solution. Auto hide sockets: As I can see from your post you are all the time thinking about automatic behavior. If I may suggest something - I'd rather leave more options to the user. As I suggested in my previous message: If most of the users love auto hide feature (I still don't understand why, but let it be) - why don't we leave this behavior, but let the user unhide sockets of collapsed node with Ctl-H? Most of the users would simply hide the nodes without doing anything else afterwards and I would hit H, Ctl-H to have the nodes the way I like them. Bartek Skorupa www.bartekskorupa.com On 2012-04-09, at 08:24, Lukas Tönne wrote: > I agree that automatic socket hiding is a bit annoying atm. Several > possible solutions (or a combination of these) come to mind: > a) Only auto-hide sockets in long lists (e.g. geometry node, render > layers) > b) For nodes with only 2 or 3 sockets, don't hide them all, or only > hide if at least one of them is connected. > > Actually socket selection + connect with fkey was reimplemented a > while back. It could be improved in a few places though: > > * The autoconnect (fkey) operator still basically works on x-axis > ordering, connects nodes on the left side to nodes further right. > That's a prerequisite for the previous default behaviour (first > chooses two nodes to connect, then tries to find suitable matching > sockets). When having single sockets selected this is usually not > necessary and prevents some useful linking from nodes further to the > right. > > * Linking by click+drag currently also selects sockets. Even though > sockets are deselected after linking, the nodes still stay selected, > so this messes with the users previous selection. Linking and then > directly moving nodes afterward often has unexpected 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] Nodes auto hide sockets on collapsed nodes
I don't mind this kind of collapsed nodes. If you don't like them, why don't you just hit Ctl-H? That's what worries me: http://www.pasteall.org/pic/29810 Not everybody drags noodles. Some of us (like me) love keyboard shortcuts. I'd like to select all those nodes or preferably individual sockets (but how to do it when they are hidden) and hit F. Collapsing nodes shouldn't make them useless. Bartek Skorupa www.bartekskorupa.com On 2012-04-10, at 20:09, Daniel Salazar - 3Developer.com wrote: > Anything is better than this http://www.pasteall.org/pic/29809 I > don't see > what's the hurry to get this reverted. > > Daniel Salazar > patazstudio.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 auto hide sockets on collapsed nodes
Let me heby begin a little battle against auto-hide sockets of collapsed nodes: Please take a look: https://vimeo.com/40237189 Bartek Skorupa www.bartekskorupa.com On 2012-04-10, at 09:47, Ton Roosendaal wrote: > Hi Lukas, > > I would like to see such usability changes in nodes to go via at > least the other listed node UI owners too. > > For me huge alarm bells ring when people talk about "adding options" > or "giving users choices". That's usually just patching flawed > designs... > > Remove the autohide for now? We should spend design powers on how we > want to work with node systems in general. > > -Ton- > > > Ton Roosendaal Blender Foundation t...@blender.org > www.blender.org > Blender Institute Entrepotdok 57A 1018AD Amsterdam The > Netherlands > > On 9 Apr, 2012, at 21:10, François T. wrote: > >> I'm with Bartek on this one :( >> >> 2012/4/9 Lukas Tönne >> >>>> I missed it because now you select socket by left clicking. I was >>>> trying to select them by right clicking (as it was in 2.49) and >>>> when >>>> it failed I was sure we still don't have this option available. >>>> This feature is a real time saver. >>> >>> The primary way of selecting sockets is with SHIFT + RMB. First this >>> was implemented as simple RMB select, but this turned out to be >>> quite >>> chaotic since it effectively allows multiple nodes selected (see >>> [1]). >>> Selecting sockets with LMB is a side effect of the select-on-link >>> "feature" (which i'd like to remove again). You see this area is >>> pretty complicated, lots of different little features interfering >>> with >>> each other :S >>> >>>> Auto hide sockets: >>>> As I can see from your post you are all the time thinking about >>>> automatic behavior. >>>> If I may suggest something - I'd rather leave more options to the >>>> user. >>> >>> Yeah, i implemented this on explicit request (i think Sebastian >>> asked >>> for it, don't remember), i suggest you talk to him. The CTRL+H idea >>> seems good, i didn't realize this doesn't work on the auto-hidden >>> sockets now. Feedback is important for us coders :) Will have to >>> check >>> with core devs if i can add this right away of have to wait for next >>> BCon1. >>> >>> [1] >>> http://lists.blender.org/pipermail/bf-blender-cvs/2012-March/044066.html >>> ___ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> >> >> >> -- >> >> François Tarlier >> www.francois-tarlier.com >> www.linkedin.com/in/francoistarlier >> ___ >> 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 auto hide sockets on collapsed nodes
In my opinion auto-hide should be reverted as a first step and it should be done before even beginning of thinking about what the target behavior should be. Now it is so that users lost some really crucial functionality without getting anything but "nicer look" in return. This "nicer look" can be achieved very easily with "good old" behavior by simply hitting Ctl-H. Let me quote Ton: On 2012-04-10, at 09:47, Ton Roosendaal wrote: > Hi Lukas, > > I would like to see such usability changes in nodes to go via at > least the other listed node UI owners too. > > For me huge alarm bells ring when people talk about "adding options" > or "giving users choices". That's usually just patching flawed > designs... > > Remove the autohide for now? We should spend design powers on how we > want to work with node systems in general. > > -Ton- Regards Bartek Skorupa www.bartekskorupa.com On 2012-04-16, at 09:20, Lukas Tönne wrote: > Bartek: Funny video, illustrates your point ;) > > Can we reach an agreement on this matter now? I'm a bit indifferent, > just don't want to be blamed for eternal suffering of artists in the > history books ;) > > Different, but related idea that came up before: make collapsing > nodes/hiding sockets work when just hovering over the node (like > stacked panels), so explicit prior selection is not necessary. Then > perhaps the ctrl+h hiding would be quick enough that auto-hiding can > be reverted. > ___ > 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 auto hide sockets on collapsed nodes
Thank you very much, I really appreciate. Bartek Skorupa www.bartekskorupa.com On 2012-04-16, at 12:53, Lukas Tönne wrote: > Reverted socket auto-hiding in SVN. Hope this settles the argument :) > > Cheers, > Lukas > ___ > 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] Quaternion interpolation is bumpy/wrong
The issue is not "bad" blender's behavior but difficulties with understanding what is going on when certain rotation models are used. When animating rotations we often use our intuition and expect some behavior because we know our particular case. Algorithms don't know exactly what our goal is. They have to be universal. All algorithms have their flows. I'd strongly vote not to mess up with the rotation interpolation as it is correct and we can do nothing about it. We have 2 main rotation models: Euler and Quaternions. Quaternions will interpolate exactly as shown in the example and we the humans intuitively perceive it as "wrong", but it's not. In every single case we have to choose proper model, but can't change the model itself. Every single model (and in fact we have 7 main choices) will fail in some scenarios. We simply have to choose the one that has least chance of failure in our particular case. In our scenario Quaternions fail, so we have to use one of the 6 available Euler models (6 possible rotations orders) or some smart parenting structure. The first thought that came to my mind when I saw the example was: "Something is broken. Quaternions shouldn't work this way", but then I analyzed this and figured out that there's nothing wrong with it. I tested the same scenario using another app. I used quaternions model there and behavior was exactly as in Blender, so there's nothing wrong with Blender. F-curves for quaternions: I don't know anybody who use individual animation curves when working with quaternions, but this doesn't mean that there's no one doing it. I simply didn't have a chance to meet such person. However I've heard some day that at least few people on the face of this earth CAN do it. Therefore I wouldn't get rid of the curves. Normal human beings will not use them, but let's leave them for other species :-) Cheers Bartek Skorupa www.bartekskorupa.com On 2012-04-26, at 03:36, Bassam Kurdali wrote: Rotations in 3D are just a horrible beast, and I think it is non trivial to figure out what constitutes a 'nice' interpolation across all cases, perhaps not even possible. You might be to use hierachies to isolate axis for some very specific setups, however: >>> way how it could be correctly implemented. My attempt would be to >>> remove >>> the possibility to edit f-curves for quaternions (who does that >>> anyway?) Lots and lots of animators edit quat f-curves- and wouldn't like 'taking the curve editor away' unless it is replaced with something better... (curve editor++ ? direct editing of paths/handles in the 3D view?) >>> and to use another interpolation scheme for this kind of rotations. >>> euler will have it's own, worse interpolation issues, but I'm not sure how axis angle would behave in this specific case. Does anyone actually use axis-angle and it's just me living in the stone age? On 2012-04-26, at 03:19, Nathan Vegdahl wrote: >> But I think that this is not really the kind of >> interpolation an animator would want to have >> in this case. As an animator I would prefer >> a direction interpolation and a separate "roll" >> interpolation. > > Believe me, as an animator and rigger, I have thought about this > problem a lot. But it's not as simple as you make it out to be. > Whenever you separate out axes of rotation like that, you introduce > singularities. So you could, for example, use euler rotation with an > appropriate rotation order to accomplish what you want here, but then > it will interpolate strangely in other circumstances. > > For example, in this file: http://www.pasteall.org/blend/13547 >> From key-1 to key-2, and from key-2 to key-3, the interpolation > behaves as you expect. But from key-3 to key-4 it behaves strangely. > > Even if we hide the interpolation curves entirely and let Blender do > whatever strange things it wants to accomplish various interpolation > methods internally, it's not clear to me that there's an obvious way > to accomplish what you want in the general case, because "roll" is > actually ill-defined for fully general 3d rotations. Besides which, > if we do that, then we deprive animators of a lot of control via > interpolation curves. > > You might be able to accomplish something close to what you want via > some clever rigging, however, by having separate controls for the > pointing direction and the roll. But you have to choose what > "pointing without rolling" means then, which involves making some > limiting assumptions. > > In any case, there is nothing broken about how Blender is > interpolating your key frames. I agree it&
[Bf-committers] 16 bpc TIFF interpretation
I'm not sure if this is known yet, but I recently noticed that 16bpc tiff images are interpreted differently when viewed directly in UV image editor and when passed to compositor. It seems as if sRGB gamma is used when source is viewed in UV image editor, but in compositor no gamma correction is applied. Here is a comparison of the same image - upper panel - source viewed in UV image editor, lower panel - taken from input image node to viewer node: http://www.pasteall.org/pic/31145 This comes from official Blender 2.63. Bartek Skorupa www.bartekskorupa.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Multi Layer EXR issues
Issue: In official Blender 2.63a: Opened MultiLayerEXR created in blender 2.62 and passes are completely messed up. Color pass from one render layer shows AO from another render layer. AO pass outputs Normal Pass from different layer etc. I tried to re-render Multilayer file (blend created in 2.62) and it gave me different results, but messed up as well. Tried the same in build of today: r46714. Same results. Bartek Skorupa www.bartekskorupa.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Multi Layer EXR issues
Sorry, in r46714 - no RenderLayers show up. All passes from all render layers grouped together. This is how my "Input Image" node looks like: http://www.pasteall.org/pic/31959 Bartek Skorupa www.bartekskorupa.com On 2012-05-17, at 12:27, Bartek Skorupa wrote: > Issue: > > In official Blender 2.63a: > Opened MultiLayerEXR created in blender 2.62 and passes are > completely messed up. > Color pass from one render layer shows AO from another render layer. > AO pass outputs Normal Pass from different layer etc. > > I tried to re-render Multilayer file (blend created in 2.62) and it > gave me different results, but messed up as well. > Tried the same in build of today: r46714. Same results. > > > 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] New compositor issues
I didn't expect easy transfer of my old complicated setups, so I don't mind that much, but I'm experiencing many weird things in "tiles". Chroma Key doesn't seem to work at all, alpha gets crazy, input images when set to image sequence simply disappear. Regards Bartek Skorupa www.bartekskorupa.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[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 a
[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
up to date. scons: `/Users/Bartek/blender-build/build/darwin/lib/libbf_editors_space_nla.a' is up to date. scons: `/Users/Bartek/blender-build/build/darwin/lib/libbf_editors_space_script.a' is up to date. scons: `/Users/Bartek/blender-build/build/darwin/lib/libbf_editors_space_text.a' is up to date. scons: `/Users/Bartek/blender-build/build/darwin/lib/libbf_editors_space_sequencer.a' is up to date. scons: `/Users/Bartek/blender-build/build/darwin/lib/libbf_editors_space_game.a' is up to date. scons: `/Users/Bartek/blender-build/build/darwin/lib/libbf_editors_space_console.a' is up to date. scons: `/Users/Bartek/blender-build/build/darwin/lib/libbf_editors_space_userpref.a' is up to date. Compiling ==> 'transform.c' Linking library ==> 'libbf_editors_space_node.a' Compiling ==> 'area.c' Compiling ==> 'glutil.c' Compiling ==> 'screen_context.c' Compiling ==> 'screen_edit.c' Compiling ==> 'screen_ops.c' Compiling ==> 'screendump.c' Compiling ==> 'paint_cursor.c' Compiling ==> 'paint_hide.c' Compiling ==> 'paint_image.c' Compiling ==> 'paint_image_2d.c' Compiling ==> 'paint_image_proj.c' Compiling ==> 'paint_stroke.c' Compiling ==> 'paint_utils.c' Compiling ==> 'paint_vertex.c' source/blender/editors/sculpt_paint/paint_cursor.c: In function ‘load_tex’: source/blender/editors/sculpt_paint/paint_cursor.c:191: warning: ignoring #pragma omp parallel source/blender/editors/transform/transform.c: In function ‘drawAutoKeyWarning’: source/blender/editors/transform/transform.c:1688: error: invalid initializer scons: *** [/Users/Bartek/blender-build/build/darwin/source/blender/editors/transform/transform.o] Error 1 scons: building terminated because of errors. Thanks, Bartek Skorupa www.bartekskorupa.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
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
igned 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 created. Our initially selected camera becomes the "left" camera. Second camera (right) is created. It's parented to "left" (left camera is the pivot of the rig). Camera data of "right" are set such that focal length and sensor size of "left" and "right" are linked together. Cameras are parallel. Shift for "right" camera is applied such that the "near plane" is placed on screen. This shift is not treated as the target shift, it only set's the starting point for shifting in post-production. All transform properties of "right" are locked. location.x of "right" is driven and take all of the needed data into account to create a "proper" Stereo Base. Two additional objects are added - planes representing "near plane" and "far plane". User needs to position them such that near plane is placed at the distance of the nearest object in the scene and far plane at the distance of the furthest object in the scene. Driver of "right" camera's location.x takes locations of those planes into account and sets stereo base such that pixel separation doesn't exceed the value specified by the user. "right" camera has custom properties assigned to it. First of them is "Depth Bracket" and here the user specifies desired depth bracket in pixels. "FP Influence" is a parameter that specifies the influence of "Far Plane" on the location.x of the right camera. By default it's set to 1.0 (full influence), but the user can set it to 0.0 and then everything is calculated as if the furthest object is in infinity. Third property "FP/NP Minimum Ratio" prevents from setting too big stereo base when the volume of the scene is shallow (distance between FP and NP is low). Rendering needs to be set up manually. No additional scenes are created, We need to simply manually render everything using "left" camera and then using the "right" camera. Link to the AddOn: https://dl.dropbox.com/u/18831655/object_stereo_setup.zip All of the calculations used in this AddOn were made by me from scratch. I tested them and I'm sure about them, however I can't link to any documents that could prove it. That's simply because I was not basing on any existing formulas, I made my own calculations basing on my own notes and sketches. 5. This is just a small comment to the document the Sean Olson referred to and Dalai commented (quotes below) In Slide 19 I found a huge mistake. It states as follows: >>>"When two views of an object are identical it tells your brain that they are >>>at infinity, at least in terms of convergence and stereo disparity."<<< 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. On 3 kwi 2013, at 07:12, Dalai Felinto wrote: > Interesting, thanks for the link Sean. Slide 19 illustrates very well a > problem I was trying to argue with Ton the other day. Basically UI on top > of the stereo-3d view (mis)leads to confusing depth cues. referring to: > http://media.steampowered.com/apps/valve/2013/Team_Fortress_in_VR_GDC.pdf 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] 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
