This switches some areas of Blender which are related on FFmpeg stuff
from deprecated symbols to currently supported one.
Pretty straightforward changes based on documentation of FFmpeg's
API which symbols should be now used.
This should make Blender compatible with recent FFmpeg 0.11.
Should be no functional changes.
This commit simply adds view transform option for image editor. This transform
is being applied on original linear color when float buffer is being converted
into sRGB byte buffer.
Currently supports such transformations:
- ACES ODT ToneCurve transform which shall preserve color ranges on such
a conversion.
- OCIO Raw, Log and RRT view transforms
This commit also contains integration of OCIO backends to Blender, so
now there's c-api and configuration file. Most of things were got from
branch where Xavier Thomas and Lukas Toene were working.
NOTE:
This is just for testing our pipeline, please do not bother me with messages
it's done wrong. It is done correct to support our own pipeline for now, and
real design would be created later when current stoppers for the project are
gone.
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.
Note that currently the reroute nodes are hardcoded to color values, which means they will not work for shader type connections (and possibly cause overhead for float and vector conversion). Looking into a solution.
The image file name function was updating the iuser->framenr using a supposed cfra parameter. However, the actual cfra is unknown when loading movies or sequences, so the iuser->framenr value itself was passed in its place, leading to incremental addition of the iuser frame offset. Removed the cfra parameter altogether from the image path function. This should instead be done separately if necessary, it's not an inherent part of constructing the image file name.
