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!
from Shinsuke Irie (irie)
(from the tracker submission)
- allow us to input non-latin languages such as Japanese/Chinese
- recover XIM connection and its input contexts when XIM server restarted
Currently it supports only "root window" style input, while most people (and I) want "over the spot" or "on the spot" style one. Probably the implementation of "over the spot" or "on the spot" style becomes much complicated, because XIM server requires the coordinates of current cursor location relative to the screen in order to show the candidate window in appropriate position.
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/
Replace pseudo-LRU approach of determining which buffer
to remove when running out of space allowed for cache
with approach which would remove the frame which is most
far away from newly added frame.
This is still a bit tricky because it's impossible to
distinguish which frame to delete in situation of:
CCCC...CC
^
it's either user wants to extend left segment of cached
frames and buffers from right segment should be removed
or he wants to join this two segments and in that case
buffers from right segment should be removed.
Would need a bit more investigation which situation
is more common in general usecase.
Additional changes:
- Cleanup some memutil files (which are familiar to cache limiter)
- Add option to make moviecache verbose. If DEBUG_MESSAGES is
defined in moviecache.c detailed logs would be printed to the
console.
- Movie caches are now named which helps reading debug messages.
