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.
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
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.
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.
