This patch adds new render passes to EEVEE. These passes include:
* Emission
* Diffuse Light
* Diffuse Color
* Glossy Light
* Glossy Color
* Environment
* Volume Scattering
* Volume Transmission
* Bloom
* Shadow
With these passes it will be possible to use EEVEE effectively for
compositing. During development we kept a close eye on how to get similar
results compared to cycles render passes there are some differences that
are related to how EEVEE works. For EEVEE we combined the passes to
`Diffuse` and `Specular`. There are no transmittance or sss passes anymore.
Cycles will be changed accordingly.
Cycles volume transmittance is added to multiple surface col passes. For
EEVEE we left the volume transmittance as a separate pass.
Known Limitations
* All materials that use alpha blending will not be rendered in the render
passes. Other transparency modes are supported.
* More GPU memory is required to store the render passes. When rendering
a HD image with all render passes enabled at max extra 570MB GPU memory is
required.
Implementation Details
An overview of render passes have been described in
https://wiki.blender.org/wiki/Source/Render/EEVEE/RenderPasses
Future Developments
* In this implementation the materials are re-rendered for Diffuse/Glossy
and Emission passes. We could use multi target rendering to improve the
render speed.
* Other passes can be added later
* Don't render material based passes when only requesting AO or Shadow.
* Add more passes to the system. These could include Cryptomatte, AOV's, Vector,
ObjectID, MaterialID, UV.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D6331
editmode
This was already supported in "Select" & "Deselect" but not in "Assign".
So similar to rB6b39dc7672eb, we now check if the material corresponding
to the currently selected material slot is found in other objects
materials and assign this (instead of always assigning their 'own'
actcol).
Maniphest Tasks: T73871
Differential Revision: https://developer.blender.org/D6869
PAINT_TEXTURE)
This fails because some tool contexts define their tools with functions
[see the following list for context that fail]:
- PARTICLE (_defs_particle.generate_from_brushes)
- SCULPT (_defs_sculpt.generate_from_brushes)
- PAINT_TEXTURE (_defs_texture_paint.generate_from_brushes)
- PAINT_VERTEX (_defs_vertex_paint.generate_from_brushes)
- PAINT_WEIGHT (_defs_weight_paint.generate_from_brushes)
- PAINT_GPENCIL (_defs_gpencil_paint.generate_from_brushes)
- SCULPT_GPENCIL (_defs_gpencil_sculpt.generate_from_brushes)
- WEIGHT_GPENCIL (_defs_gpencil_weight.generate_from_brushes)
ToolSelectPanelHelper._tools_flatten() is usually called with
cls.tools_from_context(context) [that already yields from the function].
But when registering a tool, _tools_flatten() will still give back this
function, not a ToolDef - and we cannot get a bl_idname from that.
Now check for this and yield None in that case.
Also share logic across all tool_flatten functions:
- _tools_flatten
- _tools_flatten_with_tool_index
- _tools_flatten_with_keymap
Maniphest Tasks: T63892
Differential Revision: https://developer.blender.org/D6763
The latest versions of Embree support Catmull-Rom splines
which use less memory than the previously used Hermite splines.
The representation is also much closer to Cycles own data structures
and can hopefully be unified in the future for more memory savings.
Memory savings using Victor benchmark scene:
Compared to previous Embree: ~400MB
Compared to Cycles' native BVH: ~1GB
Consequences of own refactor of usercount handling in readfile.c
(rB367ecff15d74).
Not super happy to have to call that function twice, but that should be
OK (not a real overhead here anyway).
The functionality of the mask modifier remains unchanged.
This patch updates the mask modifier so that it uses C++.
The manual memory management has been replaced with proper containers.
The large `applyModifier` function has been splitup into multiple smaller functions.
A large speedup is achieved by using simple arrays instead of hash tables in multiple places.
In my performance test file the playback speed increased from 1.1 to 5.1 fps on my laptop.
Reviewers: campbellbarton, brecht
Differential Revision: https://developer.blender.org/D6779
The problem is that Custom Shape Bones can also have a custom size.
So the pchan->disp_mat doesn't always consider the actual length of the bone.
The proposed solution is to calculate the axes matrix at the drawing pass.
Ref T65640
Reviewed By: fclem
Differential Revision: http://developer.blender.org/D5049
We detect the case where we need to invert the facing directly inside the
DRWView update and do the appropriate GL calls at draw time.
Fix T63047 Camera with negative scale works only in Cycles Rendered view
Fix T71352 Negative scale camera causes BLI_assert
This commit replaces the "Use Gradient" checkbox theme option with an
enum and implements a radial background.
Whith this change, it should be easier to implemet other types of more
complex background types, like a world space oriented gradient.
Reviewed By: billreynish, fclem, brecht
Differential Revision: https://developer.blender.org/D6825
It does not make sense to read those values when loading a file and they can crash the cursor if they contain invalid coordinates.
Reviewed By: brecht
Maniphest Tasks: T54270
Differential Revision: https://developer.blender.org/D6754
By pinching this way, we can fix some artifacts when sculpting following
the topology direction. It does not make much difference with dyntopo/
remesher, but I think this should improve the quality of the brush when
working with Multires.
Reviewed By: JulienKaspar, jbakker
Differential Revision: https://developer.blender.org/D6587
Depsgraph RNA pointer would generate infinite loop in override comparisons.
Depsgraph pointer should never be considered here anyway, this is purely
runtime data.
Some fluid cache functions were not using Blender's more secure BLI_gzopen() function. On Windows there are some special cases which this function can handle compared to the plain gzopen().
Having that extra ID users handling at readfile level, besides generic
one ensured by libquery, has been something bothering me for a long time
(had to fix my share of bugs due to mismatches between those two areas).
Further more, work on undo speedup will require even more complex ID
refcount management if we want to keep it in readfile.c area.
So idea is instead to generalize what we did for linked data already
when undoing: recompute properly usercount numbers after liblink step,
for all IDs.
Note that extra time required here is neglectable in a whole .blend file
reading (few extra milliseconds when loading a full production scene
e.g.).
Notes:
* Some deprecated data (IPOs) are not refcounted at all anymore, this
should not be an issue in pratice since the are supposed to get deleted
after doversion anyway.
* Refcounting happens after `do_versions_after_linking`, i.e those
functions won't get valid ID usercounts currently. Again, this is not a
problem in current code, if needed we could recompute refcount before,
and then ensure `do_versions_after_linoiing()` actually handles properly
usercount, which it does not currently.
Differential Revision: https://developer.blender.org/D6881
Only use the hack in `key_block_get_data` for the bmesh shapekey.
The remaining shapekeys can use the original offset values.
Differential Revision: https://developer.blender.org/D6516
This commit actually fixes several issues in this modifier, but main one
from the report was caused by adding a `CD_NORMAL` layer to loops to
store temp real clnors. Unless we plan on modifying the topology itself,
this is useless, and would require some additional 'dirty normals'
tagging to work properly, so just switched to simpler, cleaner solution
of having a local array of computed clnors.
The node would render black in this case (but should use the
'active_render' layer choosen in the object data properties -- this is
now in line to how this is handled for e.g. UVs)
This introduces ATTR_STD_VERTEX_COLOR and uses this thoughout, if no
particular layer is specified in the node.
Maniphest Tasks: T73938
Differential Revision: https://developer.blender.org/D6887
The actual naming might also be a subject to change, especially the one
around `level`. Tricky part here is that at some point in the API there
will be change from Blender modifier's Quality to OpenSubdiv's Level,
but which API level is most suitable for this?
At least now meaning of settings is better documented ans should be
clear what's going on.
