The approach is fairly simple, just apply an edge detection filter to the view normal and scale the brightness based on that.
The overlay is disabled at object boundaries to avoid dark lines around objects.
Generally, this implementation follows the proposal of @monio at https://blender.community/c/rightclickselect/J9bbbc.
The changes are:
- Dynamic filter radius (on high-DPI displays, a radius of two is used)
- Options to reduce the strength of both ridges and valleys
- Tweaked function for the strength reduction (the original method actually had a local maximum, resulting in a brighter line inside valleys)
- Multiplication for blending instead of overlay, which doesn't work reliably with scene-referred intensities
- Renamed to point out the distinction between it and the SSAO-based cavity overlay
Reviewers: jbakker
Reviewed By: jbakker
Subscribers: billreynish, manitwo, linko, monio
Differential Revision: https://developer.blender.org/D3617
This commit makes it so that subsurf/multires modifiers will respect
the WITH_OPENSUBDIV option. The WITH_OPENSUBDIV_MODIFIER option is
now gone.
For artists it mean that subsurf modifier will behave same as it is
planned for 2.80. Multires will now support sculpting, but it has some
known limitations. Those will be worked on before the final release.
If OpenSubdiv is disabled, no subsurf/multires functionality will
present.
For the details see:
https://wiki.blender.org/wiki/Reference/Release_Notes/2.80/Modeling#Subsurf.2FMultires
Go for the simple solution for now (disable auto-texspace in evaluated mesh).
Proper fix would be part of known TODO redesign of bbox handling.
Solution suggested by @sergey, thanks!
mesh_finalize_eval() may set ob->data to evaluated mesh, needs to be
done *after* call to BKE_mesh_texspace_copy_from_object(), else that one
is meaningless.
Related to investigations on T57985, but does not solve it at all. :(
Thinks whole bbox code needs a complete rewrite, one can see a lot of
old history in it, it has way too many functions doing
nearly-the-same-thing(c), it spreads in very inconsistent ways across a
lot of files, ... But have no time for this right now, and would not be
a good idea with Beta comming up close anyway.
So for now going the simple and (hopefully) sane & safe way: forbid
object-level functions to affect data-level bbox. Mesh and curve ones
would generate bbox in obdata instead of object, for some reason (all
other obdata types only use object's bbox ever). That may have been
working in old ages, but with CoW and threaded depsgraph this is just
calling for piles of issues.
Implements the first changes for T54115:
* Rename "User Preferences" window to "Settings" in the UI.
We'll likely put workspace settings in there, separate from the global
user settings. System settings should become separate from user
settings in future to allow settings for specific hardware.
* Add sidebar region for navigation (scrolls independently).
Addresses space problems, so we can add more categories as needed now.
* Increase size of Settings window to compensate new navigation bar.
* Group sections into User Preferences and System.
Icons for section groups by Andrzej Ambroz. Thanks!
* Bumps subversion for file compatibility.
Screenshot: https://developer.blender.org/F5715337
I also added categories for future work, but commented them out.
We may also want to redesign contents of each section now.
Reviewers: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D3088
Design Task: https://developer.blender.org/T54115
Bring back per-viewport localview. This is based on Blender 2.79.
We have a limit of 16 different local view viewports.
We are using both the numpad /, as well as the regular /.
Missing features:
* Hack to make sure lights are always visible.
* Make rendered mode with external engines to support this as well
(probably just need to support this in the RNA iterators).
* Support over 16 viewports by taking existing viewports out of local view.
The code can use a cleanup pass in the future to unify the test to see
if an object is visible (or we can use TESTBASE in more places).
Computing the shape of a B-Bone is a quite expensive operation, and
there are multiple constraints that can access this information in
a variety of useful ways. This means computing the shape once per
bone and saving it is good for performance.
Since the shape may depend on the position of up to two other bones,
often in a "cyclic" manner, this computation has to be a separate
node with its own dependencies.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D3975
Explicitly tag copy-on-write form library remap. Previously, this
tag was used implicitly via geometry/transform tagging, which worked
ok for objects. For non-objects we do need to ensure all copies has
correct pointer and the only way to do so is to pass tag explicitly.
There is probably more places in the library remap where this is
needed, but not being familiar with the code makes it difficult to
spot where possible tags are missing.
Use `BKE_curve_texspace_get` instead `BKE_curve_boundbox_get`.
The snap to curve, even out of edit mode, is not done on the displist. So test a boundbox that covers the points seens in edit mode.
Boundbox does not depend on transform and only need geometry
component.
This change solves possible race condition accessing geometry
data and allocating/assigning pointers.
Based on disacussion in IRC with @mano-wii and @brecht.
This is part of T57829.
Reduce the number of batches used to only one by shader type. This reduces GPU overhead and increase a lot the FPS. As the number of batches is small, the time to allocate and free memory was reduced in 90% or more.
Also the code has been simplified and all batch management has been removed because this is not necessary. Now, all shading groups are created after all vertex buffer data for all strokes has been created using DRW_shgroup_call_range_add().
All batch cache data has been moved to the Object runtime struct and not as before where some parts (derived data) were saved inside GPD datablock.
For particles, now the code is faster and cleaner and gets better FPS.
Thanks to Clément Foucault for his help and advices to improve speed.
Previously each of the objects which has armature modifier will
request deformation matricies from bbones. Thing is, all those
deformations are the same and do not depend on object which is
being modified. What's even worse is that this calculation is
not cheap.
This change makes it so bbones deformation is calculated once
and stored in the armature object. After this armature modifiers
simply use it.
With a rigs we've got here dependency graph evaluation time
goes down from 0.02 sec to 0.012 sec.
Possible further optimization is to make bbone deformation
calculated at the time when bone is calculated. This will avoid
an extra threaded loop over all bones.
Seems all the usecases of derived mesh are if-defed already,
so no need to have API for it in place, and definitely no
need to waste CPU ticks on converting evaluated mesh to
derived mesh.
Currently we never return CCGDM from the modifier stack,
so the optimization was doing pretty much nothing.
Removing it completely for now, it needs to be re-done
with the new evaluated Mesh/Subdiv.
* Less Lengthy enum/macro names.
* Optimize computation of Spherical Harmonics.
* Reduce radiance cubemap size a bit. Higher resolution is not necessary.
* Remove STUDIOLIGHT_LIGHT_DIRECTION_CALCULATED (was not used).
* Do windowing on each component separately instead of using luminance.
* Use ITER_PIXELS to iterate on each pixels, using pixel center coords.
* Remove gpu_matcap_3components as it is only needed when creating the gputex.
* Fix a lot of confusion in axis denomination/swizzle.
These changes should not affect functionallity.
