It was caused by wrong copy-paste thing, which replaced check
"whether alpha channel is enabled" with "whether alpha channel
is not zero" (which is always zero in accumulator).
Compositor always works with RGBA, so no need to do any special
checks here.
TODO: Maybe MapUV ode shall ignore alpha channel?
This disables crazy adaptive sampling happening in diagonal direction.
This still gives some doggyness, but it's much less dramatic now,
and behavior is pretty damn the same as EWA filtering when rendering
textures with Blender Internal.
Problem is that the read/write buffer operations only work with actual
image inputs. If a singular value is used as group input no actual
buffer will be created, the write operation does not schedule any chunks
and the ReadBufferOperation subsequently returns zero
(MemoryBuffer::read).
The fix uses the (0,0) resolution to detect single value input of the
WriteBufferOperation. The actual resolution is then clamped to (1,1) to
ensure we have a single pixel to store the value in. A m_single_value
flag is also set, so we can reliably distinguish this from genuine image
resolutions without having to check m_width/m_height later on.
The ReadBufferOperation copies this flag from the associated
WriteBufferOperation and if set will always return the single value from
pixel (0,0).
In fact, there's no need to get float buffer at all,
conversion could be done in pixel processor level
after interpolation.
It might give slightly worse interpolation results
(which i'm not sure would be visible by eye) but
it gives more than 2x speedup on my laptop on node
setups used for warping image.
--
svn merge -r58988:58989 ^/branches/soc-2011-tomato
This commit includes all the changes made for plane tracker
in tomato branch.
Movie clip editor changes:
- Artist might create a plane track out of multiple point
tracks which belongs to the same track (minimum amount of
point tracks is 4, maximum is not actually limited).
When new plane track is added, it's getting "tracked"
across all point tracks, which makes it stick to the same
plane point tracks belong to.
- After plane track was added, it need to be manually adjusted
in a way it covers feature one might to mask/replace.
General transform tools (G, R, S) or sliding corners with
a mouse could be sued for this. Plane corner which
corresponds to left bottom image corner has got X/Y axis
on it (red is for X axis, green for Y).
- Re-adjusting plane corners makes plane to be "re-tracked"
for the frames sequence between current frame and next
and previous keyframes.
- Kayframes might be removed from the plane, using Shit-X
(Marker Delete) operator. However, currently manual
re-adjustment or "re-track" trigger is needed.
Compositor changes:
- Added new node called Plane Track Deform.
- User selects which plane track to use (for this he need
to select movie clip datablock, object and track names).
- Node gets an image input, which need to be warped into
the plane.
- Node outputs:
* Input image warped into the plane.
* Plane, rasterized to a mask.
Masking changes:
- Mask points might be parented to a plane track, which
makes this point deforming in a way as if it belongs
to the tracked plane.
Some video tutorials are available:
- Coder video: http://www.youtube.com/watch?v=vISEwqNHqe4
- Artist video: https://vimeo.com/71727578
This is mine and Keir's holiday code project :)
- fix thumbnail preview (previously it showed only one input)
- make SplitViewer node update even if the second input is not connected
- now it works when the first socket is connected to a zero-sized node tree (e. g. Color Input node)
- SplitViewer node is now based on 2 operations: SplitOperation and ViewerOperation.
- ViewerBaseOperation was removed as a redundant one. Any future viewer style node can use the same principle and prepare the output before passing to an actual ViewerOperation.
Thanks Lukas Toenne for reviewing this patch and giving me get few pieces of advice.
This was in fact really nasty bug, caused by multitex_nodes
function using global variable R (which is a copy of current
renderer). this variable is not initialized to anything
meaningful for until first rendering (preview or final)
happened.
Since multitex_nodes might be used outside of render pipeline,
made it so whether CM is on or off as an argument to functions
multitex_ext_safe and multitex_ext. Now multitex_nodes() is
only shall be used for stuff happening from render pipeline!
Also needed to make some changes to other places, so all the
usages of texture sampling knows for the fact whether CM is
on or off.
And one more change is related on behavior of dispalcement,
wave, warp, weightvg modifiers and smoke. They'll be always
using CM off since texture is used for influence, not for
color.
It's rather bigger patch, but it's mostly straightforward
changes, which we really need to be done.
Reviewed by Brecht, thanks!
buffer antialiasing that was restored in 2.67 after it was missing in the new
compositor implementation.
This option tends to make results worse rather then better for Cycles renders,
but is useful for Blender internal. Their Z-buffers look quite different for
antialiasing, and I'd rather not change either.
This mistake happens over and over, it's just not clear what the index arguments in these relink functions mean ... We really need to clean up that interface.
by splitting the compositor module into 3 parts. The operating system limit is
32767, which gives less than 120 characters per file with 272 cpp files.
Such mapping only worked foe compositor output node
(with some issues btw) and failed dramatically for
nodes like previews and viewers.
For now let's behave the same way as border+crop
worked in 2.66 for until proper feature support
is ready (which could take some time).
Fixes#35313: object and ID anti-aliased masks get messed up
when using border render + crop
Issue was caused by file output node actually,
The thing here is, compositor output does have fixed
resolution and we could predict how to map coordinates
for border and cropping in that case.
But viewers and file output nodes are currently totally
depending on an input resolution. Could not see how
border could be applied reliably in this cases.
Disabling border option for file output node, so
now it shall behave the same way as it was before.
Discovered issues when using cropping to render border,
namely there's an offset in viewer nodes and previews,
but this is separate issue i guess (file output seems
to work fine). Will revisit this issue in next days.
Issue was caused by too hight value used for size,
which came from infinite Z-buffer point.
Solved the crash by clamoing maximal gaussian table
radius to 30K, which seems to be reasonable.
The design changes coming with pynodes for the node editor allow editing multiple node groups or pinning. This is great for working on different node groups without switching between them all the time, but it causes a problem for viewer nodes: these nodes all write to the same Image data by design, causing access conflicts and in some cases memory corruption. This was not a problem before pynodes because the editor would only allow 1 edited node group at any time. With the new flexibility of node editors this restriction is gone.
In order to avoid concurrent write access to the viewer image buffer and resolve the ambiguity this patch adds an "active viewer key" to the scene->nodetree (added in bNodeTree instead of Scene due to otherwise circular DNA includes). This key identifies a specific node tree/group instance, which enables the compositor to selectively enable only 1 viewer node.
The active viewer key is switched when opening/closing node groups (push/pop on the snode->treepath stack) or when selecting a viewer node. This way only the "last edited" viewer will be active.
Eventually it would be nicer if each viewer had its own buffer per node space so one could actually compare viewers without switching. But that is a major redesign of viewer nodes and images, not a quick fix for bcon4 ...
