Blender Git Loki

Bugfix: duplicate time node didn't copy the curve itself.

Thread rendering stability commit.

I noticed still several cases where the Imbuf library was called within a
thread... and that whilst the Imbuf itself isn't threadsafe. Also the
thread lock I added in rendering for loading images actually didn't
work, because then it was still possible both threads were accessing the
MEM_malloc function at same time.

This commit nearly fully replaces ImBuf calls in compositor (giving another
nice speedup btw, the way preview images in Nodes were calculated used
clumsy imbuf scaling code).

I've also centralized the 'mutex' locking for threading, which now only
resides in BLI_threads.h. This is used to secure the last ImBuf calls
I cannot replace, which is loading images and creating mipmaps.

Really hope we get something more stable now!

=== bugfix ===
Fixing case where BLI_make_file_string reads one byte before passed in string when the string is empty.
Leftover from patch tracker item #2740 - thanks Andrew Zabolotny.
Also fixed the part that made sure exactly one slash is appended at the end of the dir - comment wasn't telling what the code did here :)

Two significant improvements in vectorblur:

1) Accumulation buffer alpha handling
Accumulating colors in an accumulation is simple; a weighting factor can
make sure colors don't over- or undersaturate.
For alpha this is a bit more complex... especially because the masks for
vectorblur are anti-aliased themselves with alpha values. Up to now I just
premultiplied the mask-alpha with the actual color alpha, which worked OK
for solid masks, but not for transparent ones. I thought that would be an
acceptable situation, since 'ztra' faces only get blurred with alpha==1.

However, it gives bad results when using 'mist' in Blender, which just
gives pixels an alpha value based on camera distance. In these cases the
alpha became oversaturated, accumulating into too high values.

The solution is to store the mask-alpha separately, only premultiply this
alpha with the weighting factor to define the accumulation amount.
This is the math:

blendfactor: the accumulation factor for a vectorblur pass
passRGBA: color and alpha value of the current to be accumulated pass
accRGBA: color and alpha value of accumulation buffer (initialized
with original picture values)
maskA: the mask's alpha itself

accRGBA = (1 - maskA*blendfactor)*accRGBA + (maskA*blendfactor)*passRGBA

This formula accumulates alpha values equally to colors, only using the
mask-alpha as 'alpha-over' operation.
It all sounds very logical, I just write this extensive log because I
couldn't find any technical doc about this case. :)

2) Creating efficient masks with camera-shake

Vector blur can only work well when there's a clear distinction between
what moves, and what doesn't move. This you can solve for example by
rendering complex scenes in multiple layers. This isn't always easy, or
just a lot of work. Especially when the camera itself moves, the mask
created by the vectorblur code becomes the entire image.
A very simple solution is to introduce a small threshold for
moving pixels, which can efficiently separate the hardly-moving pixels
from the moving ones, and thus create nice looking masks.

You can find this new option in the VectorBlur node, as 'min speed'.
This mimimum speed is in pixel units. A value of just 3 will already
clearly separate the background from foreground.
Note; to make this work OK, all vectors in an image are scaled 3 pixels
smaller, to ensure everything keeps looking coherent.

Test renders; 'Elephants Dream' scene with lotsof moving parts; rendered
without OSA, image textures, shadow or color correction.

No vectorblur:
http://www.blender.org/bf/vblur.jpg

With vectorblur, showing the alpha-saturation for mist:
http://www.blender.org/bf/vblur1.jpg

New accumulation formula:
http://www.blender.org/bf/vblur2.jpg

Same image, but now with a 3 pixel minimum speed threshold:
http://www.blender.org/bf/vblur3.jpg

Next frame, without minimum speed
http://www.blender.org/bf/vblur4.jpg

Same frame with speed threshold:
http://www.blender.org/bf/vblur5.jpg

(Only 20 steps of vectorblur were applied for clarity).

Potential ugly bugfix in MEM_cache; the function

int IMB_cache_limiter_get_refcount()

Did not return a value at all. Any compiler should flag big warnings for
this btw... tsk tsk!

Applying patch #3826

smooth and bevel shortcuts listed in menus and toolbox were incorrect.

no new functionality

ABF Fix:

With two adjacent quads sharing three vertices, splitting to triangles
could create duplicate triangles. This broke unwrapping of Suzanne near
the nose, where there is a sort of t-joint with quads that isn't really
a t-joint. Now works fine:
http://users.pandora.be/blendix/suzanne.png

i have a file running into this check causing a 'hang' without
may be it's a development hick up .. still i think that error trap should be there

Added ability to render Zbuffer to an image.
Just use SHIFT-F3 and save an image.

Basically all this does is copy the zbuffer to a new Image buffer
and pass that to the save image function.

Sample output:
http://www.cs.umn.edu/~mein/blender/kungfu_zbuf255.jpg

Also thanks to Jesterking for helping me debug dumbness... ;)
and the nice screenshot.

Kent

Interesting commit for artists using huge textures;

The code that generated mipmaps took a real long time to do it... on a
5k x 5k image it took here (no optim, debug compile) 32.5 sec.

Recoded the very old filtering routine, which already brought it down to
2.8 seconds. Then tested if we even need this filtering... in many cases
the images are painted or photographs, which is filtered OK already.
Without the filter, the mipmap timing went down to 0.39 second. :)

http://www.blender.org/bf/filters/index1.html

Here's an example of two 'mips' generated with or without gauss filter.
Note that aliasing in an image remains there... which can be a wanted
effect anyway.

So; added the gauss filter as option in making mipmaps. Also had to
reshuffle the buttons there in a more logical manner.
There's also disabled code in the do_versions to set 'gauss' on in older
files. Will be enabled during release time.

Upgrade for Node type definitions: the min/max allowed values for input
sockets were not used yet... now they're verified on read, and written
in socket stack data on adding new nodes.
Also the buttons in Nodes use these values now. Special request from
Nathan Vegdahl who seems to be messing around with my precious nodes! :)

Faceselect mode fixes:
- Don't allow entering faceselect mode on a linked mesh (only checked object).
- Enable drawing of seams after ctrl+E seam marking.

===Python API===
Three more changes for the Mesh module:
(1) Bug fix for UV vertices ("sticky"). me->msticky was not being updated
when vertices were added or deleted from the mesh.
(2) Vertex, edge and face .extend() methods accept zero-length sequences
instead of throwing an exception. (Note that not giving any argument
is still an error).
(3) Edge and face .extend() methods ignore "invalid" edges or faces which
have the same vertex twice instead of throwing an exception. Cam and I
argued about this for a while... :-)

Ken

Testing commit for the studio; a bump-correction factor for when images
get sampled on larger distance. It actually just flattens bump when the
sampled area is (much) larger than pixel size, to prevent weird things
like:

current render:
http://www.blender.org/bf/b1.jpg

distance corrected:
http://www.blender.org/bf/b2.jpg

(image based on Alexander file :)

Tested on env's dinos too... seems to work, but we'll see.

Addition to previous commit: disabling RenderLayer "Halo" did not skip
lamphalo rendering yet... silly me!

Tweaks in RenderLayer rendering:

- LampHalos can be rendered separately too. Just disable 'Solid' in a
layer and keep 'Halo' option enabled.
- Note that disabling 'Solid' will still fill in Z values for the solid
faces, to provide occlusion information for the Ztransp and Halo layer
options. The latter didn't work this way until now for OSA render.

ALso note that that Ztransp+LampHalo still isn't good marriage... it
renders a bit weird, but that's an old issue. :)

make msvc6 compile (thanks peter)
so beat me if it does not work ;)

Potential thread render bug/crashing:
Discovered I forget to re-enable the 'imbuf load' and 'envmap' mutexes.

Feature:
- Appending Images now re-assigns relative paths, to match with the file
as currently being used

Bugfix:
- Memory error in creating preview render rects... gave no issues here,
but i guess that's not saying anything! Hope its more stable now. :)

...umm msvc6 projects again