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.
Carve proved it's a way to go, so the time have came to get rid of old
boolean operation module which isn't used anymore.
Still kept BOP interface but move it to BSP module. At some point it
could be cleaned up further (like perhaps removed extra abstraction
level or so) but would be nice to combine such a refactor with making
BSP aware of NGons.
Tested on linux using both cmake and scons, possible regressions on
windows/osx. Would check windoes build just after commit.
This required wrapping create and update pytohn callbacks as into begin/end
allow threading macroses. From quick tests this seems to be stable enough,
but more tests would be needed before considering this stable.
It was read of initialized memory around holdout_weight in cases when
holdout material is used. Seems that it should be assigned to result
of shader_holdout_eval here.
If Brecht could double check this it'll be great.
This could potentially fix#32224: Holdout Error with CUDA Cycles Render
