- 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
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.
Use float in moto instead of double for MT_Scalar.
This switch allow future optimization like SSE.
Additionally, it changes the OpenGL calls to float versions as they are
very bad with doubles.
Reviewers: campbellbarton, moguri, lordloki
Reviewed By: lordloki
Subscribers: brecht, lordloki
Differential Revision: https://developer.blender.org/D1610
Performance is about the same or slightly better for typical IK chains.
In extreme cases with many bones and multiple targets, of which some are
unreachable, I've seen 2x speedups.
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.
Use new GPU_legacy_support() function.
Determine GLSL version once instead of per shader.
For Texture Buffers, allow ARB or EXT version of the extension. Either
one will do.
In practice this gives us a context that is *compatible* with GL 2.1. On
my machine it gives a GL 3.3 or 4.3 compatibility profile context,
depending on graphics card installed.
Also fixed enum for core profile (not used yet).
Also added option for GL 3.2 compatibility profile. This will be useful
during Blender 2.8 development, until we are able to use the core
profile. On my machine this gives exactly a GL 3.2 compatibility profile
context, not 3.3 or 4.
My previous edit to this check was too lax.
OSD's shader for the Transform Feedback evaluator declares itself
#version 410 so disable the feature if user's GL < 4.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
There were multiple issues which are solved now:
- It was possible that ray wouldn't be bounced off the BSSRDF, for example
when PDF or shader eval is zero. In this case PathState might have been
left in pre-bounced state which would have been gave incorrect shading
results.
This is solved by having separate PathState for each of the hits.
- Path radiance summing wasn't happening correct as well, indirect rays
were using wrong path radiance in the case when there were more than
one hit recorded.
This is now using a bit trickier state machine which calculates path
radiance for just SSS (both direct and indirect) and then sums it back
to the final radiance.
- Previous commit wasn't totally correct either and was an induced bug
due to wrong path state left from the "un-happened" ray bounce.
There should be no special case happening here, BSSRDFs will be replaced
with diffuse ones due to PATH_RAY_DIFFUSE_ANCESTOR flag.
- Merged back codebases for "delayed" and "immediate" indirect SSS ray
tracing, hopefully making it easier to maintain the codebase.
Sure this changes brings memory usage back by about 4-5%, but overall
it's still about 2x memory reduction for the experimental kernel here.
Thanks Brecht for the review!
This is actually how it was intended to work, just didn't notice it wasn't
really happening in the main ray loop.
Solves some memory issues reported in T46880.
