Merge keying node from tomato branch into trunk.
It was considered stable and helpful by Mango team and it'll help
studio pipeline, because nodes would stop disappearing when opening
files in current trunk.
Full information about keying nodes could be found there:
http://wiki.blender.org/index.php/User:Nazg-gul/Keying
Merge Keying Screen node developed in tomato branch into trunk.
This node is aimed to make dealing with non-even greenscreens better
by generating gradiented image which could be used a input for keyer
nodes.
Based on building voronoi diagram using motion tracking markers as
sites position and average pattern color as color for that site.
Pretty straignforward node, some documentation is there
http://wiki.blender.org/index.php/User:Nazg-gul/Keying#Screen_color
KX_RadarSensor.angle was returning the angle that was used to construct Bullet's physics shape, which is calculated from the logic brick gui. KX_RadarSensor.angle now recalculates the original value from the gui. However, m_coneradius isn't actually used by KX_RadarSensor that I can see, so it might be better to just assign the original angle to m_coneradius instead of the calculated value. I've also made KX_RadarSensor.angle read-only, since setting m_coneradius does not appear to have any affect, which means writing to KX_RadarSensor.angle never worked properly.
Added a check to TRANSFORM_OT_create_orientation so it throws an exception instead of crashing blender (due to invalid view3d)
Can still create an orientation from the console just can't set it to active with the 'use' parameter
the bug was introduced by accident in r47826, finishing a render node acted as if escape was pressed.
also changed order of signaling and releasing the buffer to match the old compositor.
from Benoit Donat-Bouillud (ladeheria)
from tracker -
When using a screw axis (reference edge for screw), the operation always give the same result (as if the orientation of the reference edge was not take into account).
direct and indirect lighting differently. Rather than picking one light for each
point on the path, it now loops over all lights for direct lighting. For indirect
lighting it still picks a random light each time.
It gives control over the number of AA samples, and the number of Diffuse, Glossy,
Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample.
This helps tuning render performance/noise and tends to give less noise for renders
dominated by direct lighting.
This sampling mode only works on the CPU, and still needs proper tile rendering
to show progress (will follow tommorrow or so), because each AA sample can be quite
slow now and so the delay between each update wil be too long.
