- Move color management settings to scene, so it's now clear for
all areas (such as compositor, sequencer) which settings to
use for display buffers
- Currently removed per-editor color management settings. It could
be nice to have them, but they don't fit nicely into overall
pipeline and could be added as a override settings for display
only later.
- Make sequencer working in space defined by sequencer_workspace
role in OCIO configuration file.
If this role is not set, sequencer will fallback to legacy sRGB
Gamma 2.2 space.
Currently use vd16 color space for sequencer. Not sure what exactly
this color space is, but it's pretty close to SPI Film view and
it's still invertable.
- Sequencer will now output linear float buffers, not color managed
float buffers.
Before this sequencer used to output float buffers in sRGB space,
which was sequencer's working space. Now it can not output buffers
in this space since other areas are not aware of this space.
This also makes it's consistent that all float buffers in Blender
are in linear space.
- When saving render result into byte file format scene's display
transform would be applied on this buffer.
When saving files from image editor, there'll be a display
transform settings which are default set to scene's settings but
could also be overwritten.
Additional details are there (would be extended soon):
http://wiki.blender.org/index.php/User:Nazg-gul/ColorManagement
Incorrect read was happening after nodes which are not affect on output
were removed from the graph. Other nodes could have been connected to
this nodes which lead to accessing freed memory in some other places.
Solved by removing links from unused nodes before removing them from
the graph.
Seems some variables used for light sampling should be reset when
integrator's use_direct_light flag is setting to false, otherwise
this values could be used from previously rendered layer resulting
in using freed memory of __light_distribution texture.
Apparently for viewport rendering on GPU tile size of 1024 gives
much better performance than using single tile. Not sure why it
doesn't work for background rendering, need to be investigated
further.
Meanwhile use old debug value of 1024 for tile size.
Before this debug_tile_size was used as a size of tile, which
became hidden property since tile-based rendering implementation
and couldn't have been controlled.
This resolves the issue with single thread used for viewport
rendering in some cases. Also it makes possible to control tiles
for CUDA viewport rendering, which still behaves much faster when
using the single tile.
Also fixed issue with minimal tile size which was used to calculate
divider of final resolution to be used for initial rendering. Now
it's a Resolution Divider property in Performance tab. This option
could be used to tweak initial resolution of viewport for faster
navigation or faster refresh when changing some properties.
Currently it makes more sense to use single tile for GPU rendering
and in this case tile-based progress report doesn't work well.
Since threading happens within single tile, it's possible to
detect currently computing sample and report it to the interface,
This also allows to display smoother progress when using CPU
with small amount of tiles.
Do not discard (fill with black) tiles which are not fully rendered
(not all the samples are calculated for tile) when canceling render.
This could be helpful to tweak some settings when render glitch is
discovered. Also it could be used in such scenarios as setting
samples number to something really high and render still image
until result is reasonable, controlling this manually.
This could make cancel not so responsible on CPU, but it wouldn't
be less responsible than GPU, also could potentially give some
%% of speedup by avoiding checking cancel state after every pixel
sampled.
Issue was caused by wrong camera motion stored in device in cases
when first render layer does not have vector pass enabled.
Solved by forcing device camera update in cases when scene's motion
changed since previous device camera update.
Move center tile acquiring code into own function. Should be
easier for time being when we'll want to support other tile
render orders.
Also now there should be a single bucket growing from center
when multi-GPU is used. Can't test this here tho.
This commit solves couple of issues appeared with new integrator:
- Render job progress bar is now shows progress based on number of
rendered tiles. This is the same as Blender Internal does.
This still requires some further thoughts because for GPU it's
better to use single tile and in this case progress bar should
be based on number of rendered samples.
- Removes "global" sample counter from progress descriptor. There's
no more global-being sample which makes sense.
This counter was replaced with tile counter.
- Use proper sample number when copying render buffer to blender.
It used to be final sample number used which lead to tiles
appearing from complete dark to normal brightness as they're
being rendered. Now tile would be displayed with proper
brightness starting from the very first sample.
Use sample counter stored in render tile descriptor and pass
it to update / write callbacks.
This was tested on CPU and GPU CUDA rendering.
Additional change:
OpenCL rendering now should be cancellable before it finished
rendering all the samples (the same change as for CPU/CUDA from
a while ago).
This part of commit wasn't actually tested, would do it later.
