Currently it makes more sense to use single tile for GPU rendering
and in this case tile-based progress report doesn't work well.
Since threading happens within single tile, it's possible to
detect currently computing sample and report it to the interface,
This also allows to display smoother progress when using CPU
with small amount of tiles.
Do not discard (fill with black) tiles which are not fully rendered
(not all the samples are calculated for tile) when canceling render.
This could be helpful to tweak some settings when render glitch is
discovered. Also it could be used in such scenarios as setting
samples number to something really high and render still image
until result is reasonable, controlling this manually.
This could make cancel not so responsible on CPU, but it wouldn't
be less responsible than GPU, also could potentially give some
%% of speedup by avoiding checking cancel state after every pixel
sampled.
This is an intended feature but works too unreliably.
- This setting was stored in each face and only editable by re-running the unwrap, this is too hidden (only discovered this by reading code).
- This worked with blender internal but not with cycles, such basic options as changing an image shouldn't behave different depending on the render engine selected.
I've ifdef'd out the aspect correction for now, it could be added back as a per scene option and be made to run on both cycles or blender internal but for now I prefer to keep this disabled.
The reason is that the per-node updates used for Reroute node type inheritance are not supposed to be looking at connected nodes, they are purely for "local" updates. For this sort of "global" update which requires depth-first search, the update function on the node tree level must be used instead.
Useful in cases when masking stuff like self-intersecting
ropes. This could probably be smarter option, but can't
currently think about robust approach here.
Enable self-intersection check for preview. In own tests average
time for this operation on mango files was ~0.0015sec, and it was
like 20 splines max which still gives pretty smooth performance
on my core quad machine.
Would think let's check how it works for now, if it'll give some
issues here, would just avoid tessellation on every redraw by
storing tessellation in some cache (probably in mask user).
Another change is related on a way which loop to collapse.
Changed length check with AABB size check. A bit slower but
should be a bit more predictable.
Also, there was a needless loop through all three loops of
a tesselation triangle, which all share the same original face.
Also, made an early out for case where an edge cut had already
been discovered on a Knife edge.
