Having two ways to control color balance now seems a bit overkill
and not clear.
Removed old Color Balance settings from the interface and logic,
added versioning code to convert this settings to modifier.
Unfortunately, since color balance was a pointer, it's not actually
possible to preserve compatibility of old files saved in new
blender and opened back in old blender.
Hopefully there's no regressions :)
Regular rendering now works tiled, and supports save buffers to save memory
during render and cache render results.
Brick texture node by Thomas.
http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Textures#Brick_Texture
Image texture Blended Box Mapping.
http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Textures#Image_Texturehttp://mango.blender.org/production/blended_box/
Various bug fixes by Sergey and Campbell.
* Fix for reading freed memory in some node setups.
* Fix incorrect memory read when synchronizing mesh motion.
* Fix crash appearing when direct light usage is different on different layers.
* Fix for vector pass gives wrong result in some circumstances.
* Fix for wrong resolution used for rendering Render Layer node.
* Option to cancel rendering when doing initial synchronization.
* No more texture limit when using CPU render.
* Many fixes for new tiled rendering.
- Color managed RGB values wouldn't be displayed anymore for
byte images (which are currently unsupported to be managed).
- Color rectangle would now be color managed
- Sequencer was passing non-linear float to information line,
now it'll pass linear float.
This tonemap was added as a temporary option only and if it'll be
needed again, it'll be better to implement is as either a spline
in OCIO or as a film response curve (as some of such curves were
added as a presets for RGB curves in Mango production SVN).
Also revert changes made to IMB_buffer_byte_from_float since it's
not actually needed anymore and makes it's clearer changes against
trunk.
during a WM_draw. tiny is max 8* size of pointer and it is maintained at
that size. So no worries there.
* cleanup some code to be certain that deinitialization happens
correctly.
Two bugs: first, the point-in-face function had a bug that made it fail for the xz or yz planes.
Second, in ortho mode, simultaneous linehits need careful sorting.
Also, in orth mode it is somewhat random whether the edges exactly behind the front ones are reported 'hit' by bvh tree, so put in code to prevent cuts along the parallel-to-view faces when not in cut-through mode.
Issue was caused by getting image from compositor node conversion code,
now it'll check whether rendering happens and if so, frame wouldn't be
stored in the cache.
This possible fixes#32465: Memory leak when rendering
Checked by Brecht when were in Blender Institute.
Discovered when was looking into #32296: Node Texture - Node Material - GLSL Viewport rendering issue
The problem is that the visibility of view edges in the view map may be incorrect.
The main cause of this issue is that view edges are constructed from a series of FEdges
without testing the visibility of the FEdges being concatenated. Later view edges
are split into pieces if two view edges intersect in the 2D image coordinate system.
After that the visibility of the view edges is computed by taking account of occluding
faces in the 3D scene. In many cases this procedure results in correct line visibility,
but not always (that is the problem).
A simple solution experimentally implemented here is not to chain FEdges at all.
Instead view edges are constructed from at most one FEdge now. This solution is only
applied to sharp FEdges (roughly corresponding to edges in the input mesh data; specifically,
silhouette, crease, border, edge mark, contour, external contour, and material boundary).
A better solution is to reorder the three steps of view edges construction mentioned above,
i.e., first splitting FEdges at 2D intersection, computing the visibility of the FEdges,
then concatenating them to build view edges. This solution is left for future work for now.
* Location: Basically the same as the location from Object Info node for object instances on particles, but in principle there could be additional offsets for dupli objects, so included for completeness.
* Size: Single float scale of the particle. Also directly translates to object scale for current dupli objects, but handy to have as a single float to start with instead of a scale vector (currently not even exposed in Object Info).
* Rotation: This is a quaternion, which are not yet supported by Cycles nodes. The float4 is copied to internal Cycles data and stored in the particles texture data, but the node doesn't have a socket for it yet and the data is not yet written to the stack. Code is just commented out so could be enabled quickly if/when rotation support is added to cycles.
* Velocity: Linear velocity vector of particles.
* Angular Velocity: Angular velocity around principle axes.
The texture data is currently packed tightly into the particles texture, which saves a few bytes, but requires an additional texture lookup for some vector attributes which spread over two float4s. Could also add another float4 to particle size to avoid this.
bone renaming
* Renaming F-Curves now checks if the corresponding F-Curve's group can also be
renamed accordingly.
* Changed the RNA updates for bone renaming so that they properly update the
channel lists
