It used to be a dependency cycle which lead to incorrect or
missed tesselation on some circumstances.
Seems to be introduced in rev41627.
This commit seems to behaving properly on simple cases,
probably could fail in some other cases, so need to be
checked further.
Discovered when was looking into:
#32034: Metaball used as render object(group) for particle will display wire only.
Issue was caused by missed value for this enum, fixed by adding check
in tooltip generation.
Default value for this enum should also be fixed, but that would be
in separated commit.
The direction for these are flipped from other end caps, so add a root
flag to indicate whether the cap polygon's vertex output order should be
reversed.
Fixes bug [#32079] Skin-modifier calculates root's normals wrong
projects.blender.org/tracker/index.php?func=detail&aid=32079&group_id=9&atid=498
re-optimized the Defocus node.
* localized MemoryBuffers
* removed read(x,y) calls
* shuffled some lines in the execute pixel
* added a readNoCheck function to the memorybuffer (only use this when
you are certain you are reading a pixel inside the memorybuffer.
This adds color management controls to the sequencer space,
which are applying on the displaying image.
Currently used the same UI approach as was used for other
areas, but this would probably be cleaned up in the nearest
future.
This required a bit of hackish stuff to be done, Namely color
management for the sequencer requires one extra step in the
conversion chain to convert sRGB float buffer to linear space.
This was made by setting special flag in ImBuf. Later this
could be done using input color space for the ImBuf probably.
Added OpenCL kernel for the directional blur.
This operation always uses the full input image. In the current
implementation this input image is not cached on the device.
Future enhancement could be to cache it on the available opencl devices
The instance modifier needs to access the derived mesh data of the particle parent object to create stuff on the hairs, however the dm does not exist when the particle modifier is hidden. This is a general design problem: Objects accessing another object's derived mesh data is unsafe. For now it just checks valid dm pointer and uses identity transform if NULL.
- Fixed issue with black areas appearing when too many sites
are defined.
Currently tweak epsilon value for this, but probably actual
issue is somewhere else, can't see it yet.
- Fixed issue with bright pixels appearing in the sites, was
caused by accumulating color for pixels, which isn't needed.
Once color for pixel was set stop iterating via triangles.
Could give some speedup too.
- Ignore markers which are outside of frame bounds, they were
giving bad triangulation and they can't affect on gradient
due to color fir such sites is not known.
- Sites used to be created at position without track offset
taken into account.
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/
- Fixed issues with calculating matte with balance != 0.5
It used to be used concave combination of minimal and maximal
channel values which could be inpredictable.
Use concave combination of two non-major channels sorted
by their index, so such combination would always use the same
coefficients for particular non-major channels.
- Added despill balance slider which defines balance between
non-major channels used for calculating average of two
colors. Difference between average value and pixel value of
major screen channel defines amount of despill. Balance of
0.5 gives the same behavior as it was before this slider
was added.
---
svn merge -r48678:48679 -r48789:48790 ^/branches/soc-2011-tomato
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.
This helps keeping memory usage low and have cached segments untouched
when mixing stuff like tracking and rendering -- now you wouldn't be
need to re-cache segment you're working on after rendering.
---
svn merge -r48550:48552 ^/branches/soc-2011-tomato
