This time, all tools' code itself.
Not much to say, except that we can also get rid of that OMP caching pre-process ugly stuff
for multires smoothing.
Together with previous commit, we have about 5% average speedup on stroke execution
(though this vary a lot, up to 30% speedup in rare cases, and in even rarer cases some
odd massive slowdowns...).
Tech note: we may want to add 'guided'-similar feature to our BLI_task threaded loop,
I suspect this could explain random massive slowdowns of new code (very rare, but annoying...).
The issue was caused by OSL using TLS which is required to be freed before the
Cycles session is freed. This is quite tricky to do in Cycles because different
render session are sharing the same task scheduler, so when one session is being
freed TLS might need to be active still.
In order to solve this, we are now doing JIT optimization ahead of the time
which ensures either TLS of JIT is freed before the render on multi-core system
or freed on OSLRenderSession destroy on single-core system.
This might increase synchronization time due to JIT of unused function, but
that we can solve later with some smart idea,
Logic here is weird. Generally, textured drawing overrides
material color unless material uses object color instead?
It doesn't make sense, material color is a material color
whatever the circumstance.
Repeating: idea as always is to push all those options out of per-
polygon callbacks and make decisions such as color enable in the higher
level functions.
It would be good to get rid of this entirely, ideally decision
about mcols can be taken at material level and not done per face. More
work needs to be done for that to work though.
Only used for color for now, but we need this for any kind of buffer
updates actually.
This should get rid of some allocation/deallocation, making
vertex painting a bit faster.
This commit overrides the user's choice of tile order in the case of viewport rendering and always uses bottom-to-top instead.
This was already done until the TileManager redesign, but since it removed the distinction between viewport and regular rendering
in the manager, the viewport was now also using the selected order. Since this requires sorting of the generated tiles,
it slows down rendering a bit. With the forced bottom-to-top order, this sorting step can now be avoided again.
Since the tile order is invisible anyways for viewport rendering, this commit won't have any impact on users (apart from a slight speedup).
This commit adds "Bands Saw" and "Rings Saw" to the options for the Wave texture node in Cycles, behaving similar to the Saw option in BI textures.
Requested by @cekuhnen on BA.
Reviewers: dingto, sergey
Subscribers: cekuhnen
Differential Revision: https://developer.blender.org/D1699
This gives usual nice boost in parallelized sections themselves, on global sculpting stroke
it's a bit hard to say, seems like we have an average 5% speedup, but it varies a lot...
Note that this area is only parallelized when you have a big brush over dense geometry, otherwise
there's no change at all.
As a side note, this commit also factorizes code here, three times nearly the same code, tst...
This is an attempt to emulate real CMOS cameras which reads sensor by scanlines
and hence different scanlines are sampled at a different moment in time, which
causes so called rolling shutter effect. This effect will, for example, make
vertical straight lines being curved when doing horizontal camera pan.
This is controlled by the Shutter Type option in the Motion Blur panel.
Additionally, since scanline sampling is not instantaneous it's possible to have
motion blur on top of rolling shutter.
This is controlled by the Rolling Shutter Time slider which controls balance
between pure rolling shutter effect and pure motion blur effect.
Reviewers: brecht, juicyfruit, dingto, keir
Differential Revision: https://developer.blender.org/D1624
Vector mapping node was doing some weird mapping of both original and mapped
coordinates. Mapping of original coordinates was caused by the clamping nature
of the LUT generated from the node. Mapping of the mapped value again was quite
totally obscure -- one needed to constantly keep in mind that actual value will
be scaled up and moved down.
This commit makes it so values in the vector curve mapping are always absolute.
In fact, it is now behaving quite the same as RGB curve mapping node and the
code could be de-duplicated. Keeping the code duplicated for a bit so it's more
clear what exact parts of the node changed.
Reviewers: brecht
Subscribers: bassamk
Differential Revision: https://developer.blender.org/D1672
eg:
blender -b --python-exit-code 1 --python script.py --render-anim
This causes blender not to continue parsing command line arguments and exit if the script raises an exception.
This gives about 2x speedup (3.2sec vs. 11.9sec with 32716 handled nodes) when
updating shader for the shader tree.
Reviewers: brecht, juicyfruit, dingto, lukasstockner97
Differential Revision: https://developer.blender.org/D1700
From recent experience, turns out we often do want to use something else than basic
range of parallelized forloop as control parameter over threads usage, so now BLI func
only takes a boolean, and caller defines best check for its own case.
This makes it possible to move some parts of evaluation from host to the device
and hopefully reduce memory usage by avoid having full RGBA buffer on the host.
Reviewers: juicyfruit, lukasstockner97, brecht
Reviewed By: lukasstockner97, brecht
Differential Revision: https://developer.blender.org/D1702
Main goal is to make kernel signatures editing easier and less prone to the
errors caused by missing function signature update or so.
This will also make it easier to add new CPU architectures.
Reviewers: juicyfruit, dingto, lukasstockner97, brecht
Reviewed By: dingto, lukasstockner97, brecht
Differential Revision: https://developer.blender.org/D1703
