- check for class/static methods assumed nonzero args.
- subclass references and set-flag items are now sorted.
- use 'order' for Py operator mix-ins,
so operator settings don't show in random order.
Most of this patch was created by Daniel Stokes, I'm mostly just cleaning
it up and testing it. Still todo: hardness. I need to figure out how to
handle the integer -> float conversion on a dynamic uniform.
Reviewers: psy-fi, brecht
Reviewed By: psy-fi
Subscribers: psy-fi
Differential Revision: https://developer.blender.org/D511
An assertion to check if `re->clipsta` < 0 (added as part of addressing
T36009 in rBrB795034c17d76bef2a15e576ac9c70ae2268a823b) was failing when
Freestyle viewport preview rendering takes place in the camera view with
an orthographic camera (in this case, the user-defined clipping range is
used without changes, so that `re->clipsta` is positive). The
`re->clipsta` property has a negative value only when the 3D viewport is
in an orthographic view but not in the camera view. It seems that this
viewport setting cannot be identified from rendering settings accessible
from Freestyle. Now a negative `re->clipsta` value is directly checked
instead, without relying on other render flags.
This commit mainly:
* Exposes PreviewImage struct in RNA, including ways for user to set images data.
* Adds a new kind of PreviewImage, using a file path and IMB_thumb to get image.
* Adds a new kind of custom icon using PreviewImage, unrelated to ID previews system.
* Adds a python API (utils.previews) to allow python scripts to access those custom previews/icons.
Note that loading image from files' thumbnails is done when needed (deferred loading), not
when defining the custom preview/icon.
WARNING: for release addons who would want to use this, please keep it to a strict minimum, really needed level.
We do not want our UI to explode under hundreds of different flashy icons!
For more info, see also the release notes of Blender 2.75 (http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.75/Addons)
and the example/templates featured with Blender.
Patch by Campbell (ideasman42), Inês (brita) and Bastien (mont29).
Differential Revision: https://developer.blender.org/D1255
Currently we can't update the physics mesh of an added rigid body.
The cause is that that we need to update all shapes to say that the mesh was changed, for static object we don't do that previously because we use a odd way to reallocate memory at the same place.
So now when a mesh is changed we iterate all physics controllers which use the same shape info and recreate its shape with the correct mesh.
example file : {F168100}
Reviewers: scorpion81, sergof, hg1, sybren, moguri, agoose77
Reviewed By: moguri, agoose77
Subscribers: sybren
Differential Revision: https://developer.blender.org/D1269
This makes OCIO viewport color correction a little bit faster (about -0.5s for 100 samples)
Also set max half float value to 65504.0 to conform with IEEE 754.
Many thanks to Sergey, for practically giving the solution!
Note that it may also fix T44345, depends whether there are other missing
protections/locks or not...
Was confusing to have shade smooth/soft in both edge & vertex menu named differently.
This is an edge-flag, so keep in the edge-menu, use vertex option when in vertex mode.
rendering
Make scene background color as default for render-to-texture instead of
current blue color (0, 0, 255).
It is very useful for mirrors setups.
Reviewers: moguri, ben2610, sybren, panzergame, hg1
Reviewed By: panzergame, hg1, moguri
Subscribers: mpan3
Differential Revision: https://developer.blender.org/D1287
Only those ones are priority for now, all the rest are still testable
if CYCLES_OPENCL_TEST or CYCLES_OPENCL_SPLIT_KERNEL_TEST environment
variables are set.
This commit contains all the work related on the AMD megakernel split work
which was mainly done by Varun Sundar, George Kyriazis and Lenny Wang, plus
some help from Sergey Sharybin, Martijn Berger, Thomas Dinges and likely
someone else which we're forgetting to mention.
Currently only AMD cards are enabled for the new split kernel, but it is
possible to force split opencl kernel to be used by setting the following
environment variable: CYCLES_OPENCL_SPLIT_KERNEL_TEST=1.
Not all the features are supported yet, and that being said no motion blur,
camera blur, SSS and volumetrics for now. Also transparent shadows are
disabled on AMD device because of some compiler bug.
This kernel is also only implements regular path tracing and supporting
branched one will take a bit. Branched path tracing is exposed to the
interface still, which is a bit misleading and will be hidden there soon.
More feature will be enabled once they're ported to the split kernel and
tested.
Neither regular CPU nor CUDA has any difference, they're generating the
same exact code, which means no regressions/improvements there.
Based on the research paper:
https://research.nvidia.com/sites/default/files/publications/laine2013hpg_paper.pdf
Here's the documentation:
https://docs.google.com/document/d/1LuXW-CV-sVJkQaEGZlMJ86jZ8FmoPfecaMdR-oiWbUY/edit
Design discussion of the patch:
https://developer.blender.org/T44197
Differential Revision: https://developer.blender.org/D1200
The goal is to be able to compile kernel with nodes which are actually needed
to render current scene, hence improving performance of the kernel,
The idea is:
- Have few node groups, starting with a group which contains nodes are used
really often, and then couple of groups which will be extension of this one.
- Have feature-based nodes disabling, so it's possible to disable nodes related
to features which are not used with the currently used nodes group.
This commit only lays down needed routines for this approach, actual split will
happen later after gathering statistics from bunch of production scenes.
This will be used by split kernel in order to compile most optimal kernel.
Maximum number of closures is actually being cached in the session, so viewport
rendering will not trigger kernel re-loading when number of closures goes down.
This is currently unused but crucial for things like calculating amount of
device memory required to deal with the tasks.
Maybe not really best place to store it, but consider it good enough for now.
Previously we only had experimental flag passed to device's load_kernel() which
was all fine. But since we're gonna to have some extra parameters passed there
it makes sense to wrap them into a single struct, which will make it easier to
pass stuff around.
This header was already included into some of the implementation files already,
and this change is needed for some upcoming changes in the way how kernel_types.h
works.
Previously it was only set at compilation time which is all fine but does
not let us to check which closure the node corresponds to prior to the
compilation.
