The refactoring of texture handles did not take into account that render
services are shared between multiple render session. Now the texture
to handle map is also shared between render sessions.
This makes it easier to set up materials with emission and transparency.
Importers/exporters and add-ons are recommended to now use these rather than
creating separate transparent BSDF and emission nodes.
Cycles lights now use strength and color properties of the light outside
of the shading nodes, just like Eevee. The shading nodes then act as a
multiplier on this, and become optional unless textures, fallof or other
effects are desired.
Backwards compatibility is not exact, as we can't be sure which renderer
the .blend was designed for or even if it was designed for a single one.
If the render engine in the active scene is set to Cycles, lights are
converted to ensure overall light strength remains the same, and removing
unnecessary shader node setups that only included a single emission node.
If the engine is set to Eevee, we increase strength to remove the automatic
100x multiplier that was there to match Cycles.
Differential Revision: https://developer.blender.org/D4588
Cycles now uses the color space on the image datablock, and uses OpenColorIO
to convert to scene linear as needed. Byte images do not take extra memory,
they are compressed in scene linear + sRGB transfer function which in common
cases is a no-op.
Eevee and workbench were changed to work similar. Float images are stored as
scene linear. Byte images are compressed as scene linear + sRGB and stored in
a GL_SRGB8_ALPHA8 texture. From the GLSL shader side this means they are read
as scene linear, simplifying the code and taking advantage of hardware support.
Further, OpenGL image textures are now all stored with premultiplied alpha.
Eevee texture sampling looks a little different now because interpolation
happens premultiplied and in scene linear space.
Overlays and grease pencil work in sRGB space so those now have an extra
conversion to sRGB after reading from image textures. This is not particularly
elegant but as long as engines use different conventions, one or the other
needs to do conversion.
This change breaks compatibility for cases where multiple image texture nodes
were using the same image with different color space node settings. However it
gives more predictable behavior for baking and texture painting if save, load
and image editing operations have a single color space to handle.
Differential Revision: https://developer.blender.org/D4807
It was crashing due to array out of bounds access. This is not a great fix,
but brings back behavior the same as before now. Perhaps images that failed
to load should be stored separately somewhere.
These are the internal changes to Cycles, for Blender integration there are no
functional changes in this commit.
Images are converted to scene linear color space on file load, and on reading
from the OpenImageIO texture cache. 8-bit images are compressed with the sRGB
transfer function to avoid precision loss while keeping memory usages low. This
also means that for common cases of 8-bit sRGB images no conversion happens at
all on image loading.
Initial patch by Lukas, completed by Brecht.
Differential Revision: https://developer.blender.org/D3491
This is the groundwork for supporting loading image textures with arbitrary
color spaces through OpenColorIO.
Initial patch by Lukas, completed by Brecht.
Differential Revision: https://developer.blender.org/D3491
This adds our own OSL texture handle, that has info for OIIO textures or our
own custom texture types. A filename to handle hash map is used for lookups.
This is efficient because it happens at OSL compile time, because the optimizer
can figure out constant strings and replace them with texture handles.
This panel is arguably the most important in the ViewLayer properties, so
the concept of "1 panel open per context" doesn't work. Especially since
the first panel (View Layer) contains only two settings.
This also registers the Passes panels before filter/override so it's sorted in the same way as EEVEE.
Viewport drawing has moved to offscreen buffers, and we no longer need to have
depth, stencil, aa samples, sRGB buffers as part of the window. So all that
code is removed now. The depth buffer was the only one still being allocated,
its removal save a bit of memory.
Code by Germano and Brecht.
Differential Revision: https://developer.blender.org/D4708
This never really worked as it was supposed to. The main goal of this is to
turn noise from sampling tiny hairs into multiple layers of transparency that
do not need to be sampled stochastically. However the implementation of this
worked by randomly discarding hair intersections in BVH traversal, which
defeats the purpose.
If it ever comes back, it's best implemented outside the kernel as a preprocess
that changes hair radius before BVH building. This would also make it work with
Embree, where it's not supported now. But it's not so clear anymore that with
many AA samples and GPU rendering this feature is as helpful as it once was for
CPU raytracers with few AA samples.
The benefit of removing this feature is improved hair ray tracing performance,
tested on NVIDIA Titan Xp:
bmw27: +0.37%
classroom: +0.26%
fishy_cat: -7.36%
koro: -12.98%
pabellon: -0.12%
Differential Revision: https://developer.blender.org/D4532
Shader nodes are now shared with Eevee, so makes more sense to have it in
the core and not be Cycles specific.
Fix T62415: issues with append/link of old Cycles settings.
Now that B-Bone shape data is kept in bPoseChannel_Runtime, the
armature level cache only holds one quaternion value per bone.
It can also be moved to runtime, and the structure removed.
This has an additional effect that, as far as I can tell, now
the Armature modifier can run as soon as all of the bones it
actually needs are done, thus making T59848 a purely depsgraph
level problem.
This is an odd-ball: it's a library which has own style and
guidelines, and just happened to be developed by Blender developers
and also happened to rely on some functionality of intern/ for its
C-API.
Might consider using Google's clang-format in the future (this is
what the style is supposed to be in this library).
