filtersizes (below 2 pixels). This because Bokeh actually does 2 peaks...
/\ /\
/ \/ \
I've added some fixes in the filter calculus though, and made sure that
on size 1 at least the image gets copied straight away.
Also fixed error, Bokeh shifted image 1 pixel up.
Todo; make filters become real floats in size...
- Links now can be made between any socket type. The nodes recognize amount
of channels, and will convert types if needed.
Conversions from RGBA to 1 channel will use the 'RGB to BW' formula.
Also note that conversions only happen when required. So you can blur an
alpha channel, filter it, and put this in a 1-channel socket without any
conversion to happen, which saves memory & cpu time.
http://www.blender.org/bf/rt.jpg
The blur nodes don't accept Vector input yet... But filter does.
- RGB Curve Nodes now have the premultiply option resored, 2 x faster
- Fixed some confusing code in Node Group handling... much stabler now
At long last!
This new constraint is pretty simple. Following in the footsteps of such giants as Copy Loc and Copy Rot, it lets you constrain the size of an object/bone to another object/bone, with per axis restrictions.
- Texture Node
Allows to use any Blender Texture block as input for masks or color
blending. The texture node doesn't generate a real image, but adjusts to
the size as mapped with during an operation. So it won't work to use it
as Image input for Blur or Filter nodes.
Note; the Vector inputs for this node only work with manual input now!
- Translation Node
Give any image an offset in X or Y direction
For the Texture node to work, I needed to move the central 'pixel
processor' up one level... to allow differently sized images to merge
and allow 'procedural images' without size.
Temporal image of the day: http://www.blender.org/bf/rt.jpg
(NOTE: new include dependency in Render module, might need MSVC update!
It has to include the imbuf/intern/openexr/ directory in search path)
-> New Composite node: "Hue Saturation".
Works like the former 'post process' menu. There's no gamma, brightness or
multiply needed in this node, for that the Curves Node functions better.
-> Enabled Toolbox in Node editor
This now also replaces the SHIFT+A for adding nodes. The nodes are
automatically added to the menus, using the 'class' category from the
type definition.
Current classes are (compositor examples):
Inputs: RenderResult, Image
Outputs: Composite, Viewer
Color Ops: RGB Curves, Mix, Hue Saturation, AlphaOver
Vector Ops: Normal, Vector Curves, Map Value
Filters: Filter, Blur, VectorBlur
Convertors: ColorRamp, RGBtoBW, Separate RGBA, Separate HSVA, Set Alpha
Generators: RGB, Value, Time
Groups: the list of custom defined nodes
-> OpenEXR tile saving support
Created an API for for saving tile-based Images with an unlimited amount
of layers/channels. I've tested it for 'render result' now, with the idea
that this can (optionally) replace the current inserting of tiles in the
main result buffers. Especially with a lot of layers, the used memory for
these buffers can easily go into the 100s of megs.
Two other advantages:
- all 'render result' layers can be saved entirely in a single file, for
later use in compositing, also for animation output.
- on each render, per scene, a unique temp file can be stored, allowing
to re-use these temp files on starting Blender or loading files, showing
the last result of a render command.
The option is currently disabled, needs more work... but I had to commit
this because of the rest of the work I did!
-> Bug fix
The Image node didn't call an execute event when browsing another image.
they work ok in testing here and get done what I need, any checks or fixes are welcome.
* Separate RGBA: Separates an input RGBA image into its R, G, B and A channels
* Separate HSVA: Separates an input RGBA image into H, S, V and A channels
* Set Alpha: Takes an input RGBA image and an alpha value channel and combines them
into a single RGBA image channel. You can also set the alpha for the entire image
with the number field when there's no input alpha channel. TODO: Allow input alpha
channel with no input image, in order to output a solid colour, with alpha.
In Orange we've been fighting the past weeks with memory usage a lot...
at the moment incredible huge scenes are being rendered, with multiple
layers and all compositing, stressing limits of memory a lot.
I had hoped that less frequently used blocks would be swapped away
nicely, so fragmented memory could survive. Unfortunately (in OSX) the
malloc range is limited to 2 GB only (upped half of address space).
Other OS's have a limit too, but typically larger afaik.
Now here's mmap to the rescue! It has a very nice feature to map to
a virtual (non existing) file, allowing to allocate disk-mapped memory
on the fly. For as long there's real memory it works nearly as fast as
a regular malloc, and when you go to the swap boundary, it knows nicely
what to swap first.
The upcoming commit will use mmap for all large memory blocks, like
the composit stack, render layers, lamp buffers and images. Tested here
on my 1 GB system, and compositing huge images with a total of 2.5 gig
still works acceptable here. :)
http://www.blender.org/bf/memory.jpg
This is a silly composit test, using 64 MB images with a load of nodes.
Check the header print... the (2323.33M) is the mmap disk-cache in use.
BTW: note that is still limited to the virtual address space of 4 GB.
The new call is:
MEM_mapalloc()
Per definition, mmap() returns zero'ed memory, so a calloc isn't required.
For Windows there's no mmap() available, but I'm pretty sure there's an
equivalent. Windows gurus here are invited to insert that here in code! At
the moment it's nicely ifdeffed, so for Windows the mmap defaults to a
regular alloc.
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 :)
- 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.
- 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!
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! :)
- 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. :)
You now can set a Preview panel in the Image window, to define a sub-rect
of an image to be processed. Works like the preview in 3D Window. Just
press SHIFT+P to get it activated. Very nice speedup!
This is how it works:
- The compositor still uses the scene image size (including % setting) for
Viewer or Composite output size
- If a preview exists, it calculates the cropped rect from its position
in the Image window, and stores that in the Scene render data
- On composite execute, it copies only this part from the 'generator nodes',
right now Images or Render Results. That makes the entire composite tree
only using small rects, so it will execute fast.
- Also the render window will only display the cropped rect, and on F12
only the cropped part is being executed
- On rendering in background mode, the cropping is ignored though.
Usability notes:
- translating or zooming view will automatically invoke a recalculation
- if you zoom in on details, the calculated rect will even become smaller
- only one Imagewindow can have this Preview Panel, to prevent conflicts of
what the cropped area should be. Compositing is on Scene level, not local
per image window. (Note; 3D Previews are local per window!)
- Closing the preview panel will invoke a full-size recalculation
- All passes/layers from rendering are nicely cropped, including Z and
vectors.
The work to make the compositor do cropping was simple, but getting the
Image window displaying correctly and get all events OK was a lot of work...
indeed, we need to refactor Image Window usage once. Sorry for making the
mess even bigger now. :) I've tried not to interfere with UV edit or Paint
though... only when you're in compositing mode the panel will work.
BUG fix:
3D Preview render didn't work when multiple layers were set in the current
scene.
- Mark Border Seam: mark edges on the border of face selection as seam.
- Clear Seam: clears seams in selected faces.
Hotkey: Ctrl+E
- Alt+RMB Click: mark/clear edge as seam
- Alt+Shift+RMB Click: mark/clear seams along the shortest/straightest path
from last marked seam. The cost of the path also includes some measure of
'straightness' next to the typical distance to make things work more
predicatble and edgeloop friendly. Note that this cuts a path from edge to
edge, not vertex to vertex. That gives some nice control over the direction
of the seam.
Also includes:
- Removed old LSCM code.
- Fix updates glitches with DerivedMesh/Subsurf drawing in FaceSelect mode.
Now there's a drawMappedFacesTex instead of drawFacesTex.
- Minimize Stretch menu entry called Limit Stitch.
- Removed the lasttface global, was being set before it was used anyway, so
might as wel return from a function.
- Moved some backbuf sampling code to drawview.c from editmesh, so it can be
used by Faceselect and VPaint.
- Use BLI_heap in parametrizer.c.
- Composit cache now gets fully freed on a render. Each output socket of a
node stores the entire image... and while render that's a waste of memory
- Sky 'paper' render was using wrong texture coordinates
- Found missing test_break() in ztransp rendering.
+ 'scons blenderplayer' builds blender AND blenderplayer now (tested on Linux
only, but was only linking issue, so should work on other platforms too).
NOTE: I noticed some compileflags for GE specific libs that were left out -
I re-enabled them in the SConscripts, but I'm going to do a test build my-
self now, so if there are problems with them on win32, I probably already
know about them :)
with SHIFT+G. This works as well for local groups as library-linked
groups.
Also fixed that group nodes were copying internal data to the outside,
which made it impossible to use the socket-buttons to set individual
values for each group-instance.
Library-linked groups are prevented from editing. But, try to open a
group and it will give a request for 'make local'. The make local rule
is identical to other library data in blender, meaning:
- if all users of the library data are local -> the library data is
flagged 'local', and if needed a unique name is made
- if there's mixed users (local and from other library data) it makes
a full copy, and assigns this copy to all local users.
vectors. It's actually shutter speed, but in this case works identical to
the old motionblur 'blur fac' button.
Note; the "Max Speed" button only clips speed, use this to prevent
extreme speed values. Max speed applied before the scaling happens.
After a couple of experiments with variable blur filters, I tried
a more interesting, and who knows... original approach. :)
First watch results here:
http://www.blender.org/bf/rt0001_0030.avihttp://www.blender.org/bf/hand0001_0060.avi
These are the steps in producing such results:
- In preprocess, the speed vectors to previous and next frame are
calculated. Speed vectors are screen-aligned and in pixel size.
- while rendering, these vectors get calculated per sample, and
accumulated in the vector buffer checking for "minimum speed".
(on start the vector buffer is initialized on max speed).
- After render:
- The entire image, all pixels, then is converted to quad polygons.
- Also the z value of the pixels is assigned to the polygons
- The vertices for the quads use averaged speed vectors (of the 4
corner faces), using a 'minimum but non-zero' speed rule.
This minimal speed trick works very well to prevent 'tearing' apart
when multiple faces move in different directions in a pixel, or to
be able to separate moving pixels clearly from non-moving ones
- So, now we have a sort of 'mask' of quad polygons. The previous steps
guaranteed that this mask doesn't have antialias color info, and has
speed vectors that ensure individual parts to move nicely without
tearing effects. The Z allows multiple layers of moving masks.
- Then, in temporal buffer, faces get tagged if they move or not
- These tags then go to an anti-alias routine, which assigns alpha
values to edge faces, based on the method we used in past to antialias
bitmaps (still in our code, check the antialias.c in imbuf!)
- finally, the tag buffer is used to tag which z values of the original
image have to be included (to allow blur go behind stuff).
- OK, now we're ready for accumulating! In a loop, all faces then get
drawn (with zbuffer) with increasing influence of their speed vectors.
The resulting image then is accumulated on top of the original with a
decreasing weighting value.
It sounds all quite complex... but the speed is still encouraging. Above
images have 64 mblur steps, which takes about 1-3 seconds per frame.
Usage notes:
- Make sure the render-layer has passes 'Vector' and 'Z' on.
- add in Compositor the VectorBlur node, and connect the image, Z and
speed to the inputs.
- The node allows to set amount of steps (10 steps = 10 forward, 10 back).
and to set a maximum speed in pixels... to prevent extreme moving things
to blur too wide.
