- Button option "Single" in render-layer panel will enable to only render
the currently indicated render-layer. It will also skip compositing.
- Brought back the 'Local View' render. This will only render the visible
objects, but with lights from the original view-layers.
To make the option useful, it also temporal enables 'Single', which has
the a disadvantage that you need to set the correct render-layer.
It is a bit a tricky option though... since its quite invisble and
confusing for people who don't know the feature. This might become either
a button in 3d header, or use a popup requester to confirm, or... will
need to think over!
At least; both options display in render window a text to denote the option.
Small bug reported on irc, matrix.translationPart didn't check bounds
properly (needed to use || instead of &&). Also fixed similar bugs in
rotationPart and rich compare.
large scenes... this because it has to make 3 entire databases to find
the vertex-speed to previous and next frame. Even though most of the
prev/next database was freed, the parts I kept were spread all over
memory.
This commit copies from the prev/next database only the two screen aligned
speed vectors and stores that in temporal per-object structs. Even whilst
it takes more memory, it then can free the entire database, making space
for the next database to be built.
Tests reveiled it saves quite some... well, if you want to believe the
'virtual memory' total unix gives... :)
using 1 line per part rendered. Might go back to 1 line again, but at this
moment I need the logs for debugging.
Same prints are active now for UI rendering. Just temporal :)
keys with IKEY in buttons to not work.
- Crash in opengl while rendering was caused by the fact that scanline
updates are drawn in the main thread, whilst the actual render thread
then can already be doing different stuff.
Especially with many layers & passes it's getting confusing easily :)
Convention now is that scanline render updates only happen while the
thread is looping over scanlines. As soon as it reached the last, no
drawing happens, not even to update the last segment.
This isnt a problen, since any finished tile is drawn again entirely.
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
