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.
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!
selecting Box instead of Flat as projection, and then setting the blend value.
Blend 0.0 will not do any blending between box sides, higher values will give
a smooth transition between the sides
This is useful for mapping image texture without too obvious patterns in a
way that looks seamless, without the need for UV mapping. This works basically
the same as the mango node setup that was posted, just a bit faster:
http://mango.blender.org/production/blended_box/
- images that can't be loaded because of the limit are printed in the console.
- textures that can't be found show up as pink (so we know somethings wrong).
save memory during render and cache render results.
Implementation notes:
In the render engine API it's now possible to get the render result for
one render layer only, and retrieve the expected tile size in case save
buffers is used. This is needed because EXR expects tiles with particular
size and coordinates.
The EXR temporary files are now also separated per layer, since Cycles
can't give the full render result for all render layers, and EXR doesn't
support writing parts of tiles.
In Cycles internally the handling of render buffers and multi GPU
rendering in particular changed quite a bit, and could use a bit more
refactoring to make things more consistent and simple.
