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
Remove limit for number of textures when using CPU rendering,
so huge scenes from Mango could be rendered properly.
Re-arranged float and bytes textures for this, so now float
textures goes before byte. This is needed to make alignment
stuff easier for variable number of textures.
Also replace code-generated CPU kernel structure's members
with an array, which makes it easier to access textures
without adding bunch of cases in switch.
Should be no functional changes when rendering with GPU
or OpenCL devices.
Issue was caused by Cycles using render options from rendering scene, not
from active scene.
For now solved by passing render resolution inside RenderEngine structure.
This probably could be solved in more general way, like adding bindings
for RenderEngine->Render, which would avoid passing options like
is_animation, came_override and so via RenderEngine. Would think about
this a bit more and probably would do that.
The same issue happens in trunk as well, but not consider such a change
trunk-ready, would want to make more tests and probably clean the code
a little bit before commiting this into trunk.
Update samples displayign in the interface once in a whiel only
(currently once in 1 sec). This still keeps rendering interactive
enough for artists and it eliminates slowdown caused by constant
uploading sampels from GPU to host.
This also allowed to get rid of hack with storing render result
in render buffers, due to it's not so big overhead ow to create
render result when sample needs to be updated.
Tests made with different files shows that now render speed is
really close to oroginal speed from before we started hackign
into this stuff.
There still some issues with interactive update when rendering
several render layers, but that seems to be irrelivant to all
this sampels commtis, so woudl look into this as a separate
patch.
Copy pixels for combined pass only when updating tile after each sample
skipping all other passes. Behaves noticeable faster on scenes with
lots passes used.
Would check further tomorrow from studio whether stuff could be speed
up further.
