| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The issue was caused by leaking error messages caused by
getting OIIO texture handle for built-in images.
|
|
Not fully thread-safe, but is rather harmless. Just some messages
might be logged several times.
|
|
|
|
|
|
|
|
This is where the libraries belongs to actually, they are not only used by
Libmv now, but also by tests and Cycles.
|
|
|
|
While SCons building system was serving us really good for ages it's no longer
having much attention by the developers and started to become quite a difficult
task to maintain.
What's even worse -- there started to be quite serious divergence between SCons
and CMake which was only accumulating over the releases now. The fact that none
of the active developers are really using SCons and that our main studio is also
using CMake spotting bugs in the SCons builds became quite a difficult task and
we aren't always spotting them in time.
Meanwhile CMake became really mature building system which is available on every
platform we support and arguably it's also easier and more robust to use.
This commit includes:
- Removal of actual SCons building system
- Removal of SCons git submodule
- Removal of documentation which is stored in the sources and covers SCons
- Tweaks to the buildbot master to stop using SCons submodule
(this change requires deploying to the server)
- Tweaks to the install dependencies script to skip installing or mentioning
SCons building system
- Tweaks to various helper scripts to avoid mention of SCons folders/files
as well
Reviewers: mont29, dingto, dfelinto, lukastoenne, lukasstockner97, brecht, Severin, merwin, aligorith, psy-fi, campbellbarton, juicyfruit
Reviewed By: campbellbarton, juicyfruit
Differential Revision: https://developer.blender.org/D1680
|
|
list
|
|
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,
|
|
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 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
|
|
|
|
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
|
|
|
|
This way it's easier to pass stuff around and also much easier to add more
state variables.
So far should be no functional changes for artists.
|
|
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
|
|
|
|
The idea is to have separate sets per node name in order to speed up the
comparison process. This will use a bit more memory and slow down simple
shaders, but this extra memory is not so much huge and time penalty is
not really measurable (at least from initial tests).
This saves orders of magnitude seconds when de-duplicating 17K nodes and
overall process now takes 0.01sec on my laptop,
|
|
Was a left-over since 5b33115.
|
|
Use Summary structure to collect all summary related on the shader compilation
process which then could be either simply reported to the log or be passed to
some user interface or so.
This is type of the summary / report which is most flexible and useful and
something we could use for other parts like shader optimization.
|
|
|
|
|
|
The idea of this commit is to merge nodes which has identical settings
and matching inputs into a single node in order to minimize number of
SVM instructions.
This is quite simple bottom-top graph traversal and the trickiest part
is how to compare node settings without too much trouble which seems to
be solved is quite clean way.
Still possibilities for further improvements:
- Support comparison of BSDF nodes
- Support comparison of volume nodes
- Support comparison of curve mapping/ramp nodes
Reviewers: brecht, juicyfruit, dingto
Differential Revision: https://developer.blender.org/D1673
|
|
the value again.
|
|
- When rendering in the Viewport, next_tile is sometimes called after a reset has been performed, but before
new tiles were generated. In that case, the tile list would be invalid, causing Blender to crash randomly.
- When generating new tiles, the TileManager would not clear the tile lists before re-generating them, leading
to some tiles being skipped during viewport rendering.
- When popping the next tile from a tile list, a reference to the just-deleted object would be returned, now the
object is copied before deleting it.
|
|
This way socket type conversions (such as color to float, or float to vector) do not stop the folding process.
Example: http://www.pasteall.org/pic/show.php?id=96803 (selected nodes are folded).
|
|
This commit modifies the TileManager to sort render tiles once after tiling the image,
instead of searching the next tile every time a new tile is acquired by a device.
This makes acquiring a tile run in constant time, therefore the render time is linear
w.r.t. the amount of tiles, instead of the quadratic dependency before.
Furthermore, each (logical) device now has its own Tile list, which makes acquiring
a tile for a specific device easier.
Also, some code in the TileManager was deduplicated.
Reviewers: dingto, sergey
Differential Revision: https://developer.blender.org/D1684
|
|
functions, it's obvious.
|
|
|
|
|
|
This was an oldie TODO since initial work on newer OSL/OIIO support.
Now we should be ready for the libraries bump.
|
|
This is actually intended behavior to return NULL when the socket is not
found. It's used in certain BSDF nodes to query whether some inputs exists
or not.
Perhaps we can be more explicit here and have dedicated logic to query
socket existance and keep assert in place.
In any case, even if we lost assert() for the constant fold now it's
still somewhat better than duplicated code. Perhaps.
|
|
|
|
|
|
Maybe this is pedantic but I read it’s best to explicitly set the
desired component size.
Also append “_ARB” to float texture formats since those need an
extension in GL 2.1.
|
|
|
|
This way, connecting Value or RGB node to e.g. a Math node will still allow folding.
Note: The same should be done for the ConvertNode, but I leave that for another day.
|
|
Previously RGB Curves node will clamp input to 0..1 which is rather useless
when one wants to use HDR image textures and do bit of correction on them.
Now kernel code supports extrapolation of baked LUT based on first/last two
table points and performs linear extrapolation.
The only tricky part is to guess the range to bake the LUT for. Currently
it's using simple approach -- minmax of the input curves. While this behaves
ok for the simple cases it's easy to trick the system up causing incorrect
results.
Not sure we can solve those issues in a general case and since the new code
is giving more expected results it's not that bad actually. In the worst
case artist migh always create explicit point to make sure LUT is created
for the needed HDR range.
Reviewers: brecht, juicyfruit
Subscribers: sebastian_k
Differential Revision: https://developer.blender.org/D1658
|
|
This must have happened months ago, but as I did not `make clean` any build folder since then,
so only noted that today.
Issue is same as dirty patch we have to apply to ODL sources before building it in install_deps.sh - for
some mysterious reason, it has become impossible to compoile .osl files into .oso ones without
giving explicit output file name (otherwise it just produces `.oso` file - utterly stupid and useless).
We could probably fix that in own OSL source, but think being explicit here does not hurt anyway, so...
Let's go the easy way.
|
|
This reduces stress on the the stack memory which could be really handy
on certain operation systems which applies strict limits on the stack.
Reviewers: brecht, juicyfruit, dingto
Reviewed By: brecht, juicyfruit, dingto
Differential Revision: https://developer.blender.org/D1656
|
|
clamping
This fixes remained issues reported in T46908.
|
|
|
|
The code is disabled by default, but we'd better keep it all correct.
|
