max values multiplied by the view's grid setting, like most other buttons
dealing with sizes and locations.
Sorry, untested, as I can't get it to link (error while loading
shared libraries: libavformat.so)
- a Group has Curve node inside
- this Group was re-used more times
- with threaded render activated
- and both groups executed on same time
Then the premultipy optimize table was created twice... causing memory
to confuse.
nothing radical. :)
Just remember to always try higher octree resolutions (256 or 512) or more
complex scenes. Can be 5-10 times faster.
For waiting pleasure; added a per-second header print update to tell where
octree is. Also added an ESC test in octree making.
(Commit in image.c is a faulty print for 'Not an anim').
This filter type uses a filter-image, and spreads color of current pixel
over all neighbour pixels based on this filter-image. That creates a
problem on borders... since there only parts get accumulated.
Solved by going over the to-be-filtered image pretending it is wider
exactly the amount of the filter-image size.
the Preview Panel, you got a crash... this case wasn't anticipated in
code... two cropping mechanisms on top. :)
Works OK now, but offset of cropping is drawn a bit weird... this case
needs recode a bit. On list for later.
Until now, on each mouse/key event preview render restarted with first tile.
It now rememers where it was, and continues rendering.
Also tried to get threaded preview working, but its more work than I can
spend right now. Back to bugs :)
- Improved stats drawing while rendering, it now draws - while preparing
renderdata - each second the amount of verts/faces.
Also while rendering, the amount of finished and total parts are printed.
- Added ESC in loop that generated Group render data
- On deleting Render Layers, the nodes that use them are now checked and
corrected.
- Restored drawing all scanlines in renderwindow... this wasn't the bug!
- I changed the input method for shear quite a bit. It used to be constant
regardless of zooming, so it was quite limiting in the amount of shear you
could do. However, I'm not sure if the current method is quite well
adjusted, if you think it works too fast, please drop me a line.
It's basicly the same method as Shrink-Fatten / Push-Pull except on an
horizontal basis. (since shear is an horizontal motion and the two others
are more like pulling towards/pushing away from you in regards to the center)
- Factored out the input methods in preparation for later code <evil>.
sampling have been activated for UI. Check the pictures here:
http://www.blender.org/bf/filters/index2.html
I also did do tests with anti-aliased shadowbuffers:
http://www.blender.org/bf/filters/index3.html
But this needs more thinking over still...
- Compositor now frees memory of buffers internally used in groups
immediately. This wasn't part of the event-based cache anyway
- New option: "Free Texture Images" (in render Output panel). This
frees after each render of each scene all images and mipmaps as
used by textures. As reference it prints total amount of MB freed.
- Render stage 'creating speed vectors' had no ESC checking yet
- Made drawing scanline updates during render draw 1 scanline less...
dunno, still hunting for weird opengl crashes.
- 3D preview render didn't properly skip sequence or composit render.
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!
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 :)
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).
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
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
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.
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! :)
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
