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.
This fixes memory overflow caused by creating render result every time
RenderResult is creating when updating sample and not being freed until
tile is fully rendered.
Solved in probably not best way -- RenderResult is being stored in
RenderBuffers, so it's creating only once.
This solves memory issues, but while was looking into this issue
discovered dramatic slowdown caused by samples update in some files
from mango svn.
Solving this slowdown is becoming first priority from now on.
Was requested by Mango team to improve feedback during rendering.
Known issues:
- Updating of samples are accumulative, meaning that visually samples
would be dark in the beginning becoming brighter during progress.
- Could give some % of slowdown, so probably should be disabled in
background mode.
Still to come: update of samples when using CUDA and OpenCL.
Seems this requred cuda context synchronization after every finished sample,
which could give few percent of slowdown. In test made here it was only minor
slowdown, so think it's pretty much acceptable for now.
For sure actual issue is in carve's triangulation system which need
to be investigated and fixed. For now only fixed by re-shuffling a
bit existing degenerative faces check and added extra checks there.
Would look into actual fix a bit later.
This patch switches from boost's filesystem v2 to v3.
This should be completely smooth due to filesystem v3 is pretty
old already.
Patch by Sven-Hendrik Haase (aka svenstaro), thanks!
