| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
has to determine if a particle update is needed (which depends on dupli objects and their meshes), before deciding to skip the actual syncing.
|
|
= n-1, upsampling = n).
Thanks goes to MiikaH.
|
|
* Fix for changes in the OpenImageIO API.
|
|
|
|
from Bill Currie (taniwha)
|
|
|
|
|
|
|
|
todo: deployment target management
|
|
|
|
* Remove BSP_GhostTest, not used and working for ages, approved by Sergey.
|
|
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.
|
|
with specific object scaling.
Part of Smoke Development Phase III.
Credit also goes to MiikaH: It was a teamwork effort and took days to track down. :)
|
|
* Removed outdated OpenCL comments, kernel features are defined in kernel_types.h now.
|
|
also remove historic comment which isnt helpful.
|
|
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
|
|
totally clear it was a question (user pointed this out, they thought it was just notification and lost their work).
|
|
openmp.
|
|
we've been looking into texture limit for Mango and it's not needed now.
Anyway, this prints didn't cover all the cases when images were loading.
|
|
a mask layer enabled.
|
|
|
|
attribute.
|
|
header must be included in cycles in order to expand the version check macro.
|
|
|
|
be tweaked to fix [#32174])
|
|
|
|
precision is important and doubles are used a lot here anyway. just use doubles, also quiet some double promotion warnings.
|
|
Note: Compile still fails during ceres compile (namespace tr1 problems).
|
|
|
|
required to get consistent ID numbers for particles. The Object ID is not usable since it's a user defined value of the instanced object, which does not vary per instance. Also the random value from the object info node is not consistent over time, since it only depends on the index in the dupli list (so each emitted or dying particle shifts the value).
The particle index is always the same for a specific particle. Randomized values can be generated from this with the use of a noise texture.
|
|
Patch by IRIE Shinsuke, thanks!
|
|
when using MEM_dupallocN. This helps figuring out issues with non-freed
dup_alloc blocks,
Simply enable DEBUG_MEMDUPLINAME in mallocn.c file.
|
|
its handy to see whats actually loading from the blend files)
|
|
collisions with PathRayFlag's
|
|
also some minor style cleanup.
|
|
|
|
|
|
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.
|
|
connect a closure to another closure.
|
|
|
|
named drarnode.c and node_draw.c.
|
|
|
|
appearance
|
|
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.
|
|
|
