The title says it all actually.
Added special custom data type, because we don't know in advance
whether we're referencing UV or Color layer. Also made it so vertex
attributes are normalized.
TODO: Border render in viewport ignores the normalization of the
attribute array for some reason, will be looked into still.
Reviewers: mont29, brecht, campbellbarton
Reviewed By: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D2022
At some point the idea was that we could have an optimization where we could
render multiple render layers without re-exporting the scene, by just updating
the layer bits. We are not doing this now and in practice with the available
render layer control like exclude layers it's not always possible anyway.
This makes it easier to support an arbitrary number of layers in the future
(hopefully this summer), and frees up some useful bits in the kernel.
Reviewed By: sergey, dingto
Differential Revision: https://developer.blender.org/D2020
This commit implements Bump node in GLSL, making it possible to
see previews of bump mapping in viewport without need to render.
Nothing really fancy going on here, just uses internal dFdx/dFdy
functions to get derivatives of the surface and map itself.
Quite basic but seems to behave correct-ish.
This commit also makes Displacement material output to affect
viewport shading by re-linking unconnected Normal input to a
node which was used for displacement output (via Bump node).
Intention of all this is to make it really easy to do bump map
painting with Cycles as an active render engine.
Reviewers: campbellbarton, mont29, brecht, psy-fi
Reviewed By: brecht
Subscribers: Blendify, eyecandy
Differential Revision: https://developer.blender.org/D2014
Since version 6 G++ switched to C++11 by default, which breaks some logic
around WITH_CXX11 checks in out CMake files, leading to compilation errors.
This is easy to solve by explicitly enabling older C++ standard when C++11
was not explicitly enabled by CMake options.
However, G++-6 will also use new ABI by default even if older standard was
specified in the compiler options. This is being addressed by a special
define flag.
This tricks made it possible to use new G++-6 without need to recompile
any of pre-compiled libraries.
However, this might break compilation with existing system libraries, which
might already be using new ABI. We can't address this automatically, so
now we simply default WITH_C11 and WITH_CXX11 options to whatever defaults
of the current compiler are. This means, for G++-6 we'll set WITH_CXX11 to
truth. This should make linking with system libraries working just fine,
but to make pre-compiled libraries we still might need to disable CXX11.
This should work fine work for a new environments with G++-6 and install_deps
script run from scratch there, because C++ standard will be the same for
both Blender dependencies and Blender itself.
This commit makes Dynamicpaint modifier evaluation (during playback) a few percents quicker.
However, it makes dynapaint's 'image sequence' baking about 33% quicker (from 119 to 77 seconds
in own heavy test), partly due to switch to BLI_task itself (about 20%), and partly due to
optimizations (remaining ~13%).
As usual, did a lot of tests here to ensure nothing is broken, but a lot more users' testing would definitively
be welcome too! ;)
Note that some quite meaningless omp forloops have been removed (parallelizing thousands of vec copy does
make it two or three times quicker, but the few hundreds of microseconds gained do not make any difference
in a hundreds millisecond process).
Also, this code could still use a lot more cleanup (naming etc.), the way it (tries to) handle malloc faults
is also totally flacky and makes the code horribly verbose and convoluted in some places - without actually
catching all possible faults (memarena could make it more easy to handle here), etc.
Usage:
* D+X - Works anytime, anywhere
* Shift-X - Works in EditMode only
* Via Delete Menu - EditMode only
Often doing video tutorials or perhaps during dailies/shot review you want to
quickly get rid of a quick scribble you made for making a point, without having
to undo (i.e. maybe you edited some objects in between) and/or without having
to use the eraser (i.e. it'd take too long to cover the entire area).
On light coloured backgrounds (especially on white), it was impossible to see
where the cursor was. This commit adds a second ring (black) to the cursor so
that on light backgrounds, even if the light ring isn't visible the black one
will be.
Gives 3-4% speedup in pre-bake step (from 112 to 108 seconds with own heavy test file).
Note that here we have a huge potential performance boost if we replace the flat
`Bounds2D *faceBB` array of UV tris bounding boxes by a real 2D AABB tree (right now,
we can loop over all UV triangles times the number of pixels of the surface times 5...).
It gives some slight differences on the plane corners, but can't
really figure out source of the issue here yet.
It's still better than fully white texture for the previews anyway.
At this point we should perhaps ifdef chunks of the code in order
to have faster GLSL compilation and probably even faster compiled
code. Will look into this shortly.
Compile time per kernel increased alot after recent image commits, re-shuffle some code to fix this.
Patch by "LazyDodo".
Differential Revision: https://developer.blender.org/D2012
In addition to the original bug report, I've gone through cleaning up a range of
related bugs which only became clear when hunting around the code...
* Custom Handle References weren't getting cleared when the bones they used got
deleted. But, neither was the custom bone shape location/transform reference.
* Various places where posebone settings are copied around were also missing code
to handle the new Bendy Bone properties.
(WHY DO WE HAVE SO MANY VARIATIONS OF COPYING POSE DATA!?!?)
* If duplicating a Bendy Bone with custom references, and the custom references
are also selected/duplicated, the new Bendy Bones will use the corresponding
duplicated bones