Wed, Jun 21
Thu, Jun 15
I have found that the builds after June 4th address the texture to scale distortion bug.
Tue, Jun 13
Mon, Jun 12
(for the records the original claim that clamping is the issue could be solved with P494, but RNA is already clamping the values before we get to the compositor, so this patch is uneeded)
This is not related to the directional blur node. Here is an even simpler file using another node:
Note that the compositor node is not even being used.
Confirmed. Note to other testers on how to test it:
- Load file, enable auto-run scripts
- Switch viewport to rendered
- The viewport has nothing rendered.
Sun, Jun 4
The title is based on initial observations.
It is definitely a bug so I will leave it to developers to figure it out.
Sat, Jun 3
I see that too, and all I have to do is go Converter > Math and it renders corrupted. Even before I hook it up.
Title maybe should be changed to "....cause corrupted backdrop image"
Decided to play with the texture node before plugging it into Scale offset
Sorry about that!
There is no need of blend file.
Please try with a build from builder.blender.org/download
I have same crash with Win7 64 bit and ATI HD4670
Yes, that's the setup that crashes Blender.
It was mentioned from another user I just replicated it on my machine.
Thanks for the report but it would be helpful if you add a blend-file to the report that demonstrates the issue at hand.
Do you mean like this?
Fri, Jun 2
May 22 2017
May 19 2017
Brought behavior back to how it was before. But i find this all weak, and some cleaner design (which follows artists' expectations instead of dictating them how to use something) is really needed in compositor.
@Aaron Carlisle (Blendify), so "squished" part i think we can investigate (as in "resolution" if you wish).
May 18 2017
@Sergey Sharybin (sergey) but why did it work in 2.77?
Scaling down can not work within the current compositor design. Fixing this issue would mean changing the design completely, which is out of the scope of the bug tracker.
May 17 2017
May 16 2017
This is a known limitation. Output node doesn't know of the nature of the data and assumes this is image pixels.
Anti-aliasing happens from the outside side of the spline, which is actually happened to be an inner side of your "buggy" spline. Just switch direction of the spline and anti-alias will work fine.
May 15 2017
This was a poorly implemented feature which was not thread-safe and was causing lots of crashes. It was disabled in the code, but interface part remained. Thus happened 3 years ago, so think it's safe to let this feature to disappear from the interface.
Unfortunately, this is a limitation of the current compositor design, which has half-finished canvas awareness. The following internal issues are happening:
May 14 2017
Apr 30 2017
I see what you want to achieve now. Afraid you'll need to follow some workaround like @ronan ducluzeau (zeauro) suggests with the current BI design.
Apr 29 2017
Apr 28 2017
You can add a boolean modifier to your UpperCube.
If you would not specify mask at all you'll have the result you're looking for here.
I tried this, but it gives me wrong result. Upper cube's outline doesn't follow lower cube contour.
Thanks for the report, but the code is working as it was designed to (and here i don't mean it is not confusing for artists). The Edge enhance pass is using Z-pass calculated for objects from current render layer objects and objects which are set by Z-pass mask layers. So adding Z-pass mask does not mean you exclude that unselected layers from edge enhancement.
Final render and preview are having decoupled render border settings. This way you can keep tweaking some specific area in the compo and hit F12 to have a better idea of what's happening on the frame. There is currently no way to automatically inform compositor that some render result was cropped and that it should not calculate anything outside of that region.