[Bf-committers] 2.60 feature(s)
xgl.asyliax at gmail.com
Wed Aug 24 21:36:39 CEST 2011
As some of you know I wrote the Double Edge Matte compositor node a
while back, but didn't get it into blender due to high number of bugs
in tracker (not with this node, but in general).
I agree with the idea that we don't add more and more features while
tracker grows and grows, so I'm not in any way complaining about that.
After 20yrs of programming, I totally understand.
Here's the situation:
I currently have 3 compositor nodes in fully functional form that I'd
like to submit. I think they'd be beneficial to lots of people out
there across a few different fields in the overall CG industry.
1.) Double Edge Matte (variably feathered edges...)
http://www.youtube.com/watch?v=VcjEfoNIHZs (sorry about volume... xD)
Should be very useful for next open-movie???
Takes two singe channel inputs (imagine two black images with a
while ball in each) and outputs your choice of:
Screen Space Center (xmax+xmin)/2, (ymax+ymin)/2
Screen Space 2d Center of Gravity (would weight a 2d
baseball bat correctly, more toward thicker end)
Each channel has it's own set of options, so you can get
distance *FROM* point A, Channel 1's closest point to Channel 2, *TO*
point B, Channel 2's 2d center of gravity. (any combo will work)
Screen Space (0.0,0.0)-(1.0,1.0) space...
Pixel Space (where distances are measured in pixels in buffer...)
Connect renderlayers (or objectID mask) to this node,
connect output to blur, blur objects more/less based on distance to
eachother... or something similar.
Takes single channel input node, outputs:
Proportion of white to non-white pixels (if 1/4 of pixels
of input channel pixels are 1.0, then output would be 0.25)
Can also output full white-pixel count. (literal number of
pixels of that were full bright)
Connect renderlayer (or objectID mask) to this node,
connect output to blur, blur object more/less based on how much screen
coverage it has.
So my main reason to email ML is this:
These were all coded to work with existing, regular 2.5x node
input-outputs/ node core.
They'd be even more efficient with Lukas's node improvements.
Shall I wait till AFTER 2.60 so Lukas's better node code is in, alter
my nodes, and then submit them?
Shall I submit them sooner, but then have to redo them all anyway once
the better node code gets merged from Lukas's branch?
Also, what about jbakker's Compo? These nodes (all 3) require full
buffer to operate, and would stall the whole execution branch they are
Anyone care to offer advice on when these rightfully should get submitted?
More information about the Bf-committers