This is a more correct fix to the issue Brecht was fixing in D6600.
While the fix in that patch worked fine for linking it broke ASAN
runtime under some circumstances.
For example, `make full debug developer` would compile, but trying
to start blender will cause assert failure in ASAN (related on check
that ASAN is not running already).
Top-level idea: leave it to CMake to keep track of dependency graph.
The root of the issue comes to the fact that target like "blender" is
configured to use a lot of static libraries coming from Blender sources
and to use external static libraries. There is nothing which ensures
order between blender's and external libraries. Only order of blender
libraries is guaranteed.
It was possible that due to a cycle or other circumstances some of
blender libraries would have been passed to linker after libraries
it uses, causing linker errors.
For example, this order will likely fail:
libbf_blenfont.a libfreetype6.a libbf_blenfont.a
This change makes it so blender libraries are explicitly provided
their dependencies to an external libraries, which allows CMake to
ensure they are always linked against them.
General rule here: if bf_foo depends on an external library it is
to be provided to LIBS for bf_foo.
For example, if bf_blenkernel depends on opensubdiv then LIBS in
blenkernel's CMakeLists.txt is to include OPENSUBDIB_LIBRARIES.
The change is made based on searching for used include folders
such as OPENSUBDIV_INCLUDE_DIRS and adding corresponding libraries
to LIBS ion that CMakeLists.txt. Transitive dependencies are not
simplified by this approach, but I am not aware of any downside of
this: CMake should be smart enough to simplify them on its side.
And even if not, this shouldn't affect linking time.
Benefit of not relying on transitive dependencies is that build
system is more robust towards future changes. For example, if
bf_intern_opensubiv is no longer depends on OPENSUBDIV_LIBRARIES
and all such code is moved to bf_blenkernel this will not break
linking.
The not-so-trivial part is change to blender_add_lib (and its
version in Cycles). The complexity is caused by libraries being
provided as a single list argument which doesn't allow to use
different release and debug libraries on Windows. The idea is:
- Have every library prefixed as "optimized" or "debug" if
separation is needed (non-prefixed libraries will be considered
"generic").
- Loop through libraries passed to function and do simple parsing
which will look for "optimized" and "debug" words and specify
following library to corresponding category.
This isn't something particularly great. Alternative would be to
use target_link_libraries() directly, which sounds like more code
but which is more explicit and allows to have more flexibility
and control comparing to wrapper approach.
Tested the following configurations on Linux, macOS and Windows:
- make full debug developer
- make full release developer
- make lite debug developer
- make lite release developer
NOTE: Linux libraries needs to be compiled with D6641 applied,
otherwise, depending on configuration, it's possible to run into
duplicated zlib symbols error.
Differential Revision: https://developer.blender.org/D6642
Add toolbar to sequencer regions.
A bit of refactoring has to be done in RNA space.
Currently there is only cut tool implemented to serve as template for
anybody who would like to add more.
Previously the window manager would receive the GHOST event and then query the
latest tablet data from the window to go along with it. If multiple events were
queued, it would then use too new tablet data for handling older events.
Fixes T62565: tablet pressure not working on macOS with some devices
Removing meaningless distinction between NULL pointer and EVT_TABLET_NONE,
and initialize pressure and tilt to 1.0 and 0.0 respectively when no tablet
is used.
`ARegion.alignment` unfortunately is a mixture of value and bitflag
enumerations. When checking for left/right/top/bottom region alignment,
the flags have to be masked out usually.
Most of the fixed cases here probably didn't cause issues in practice,
but could in fact break at any point when surrounding logic changes.
In fact the assert in #region_visible_rect_calc() failed in an older
file from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949035. This
fixes it.
It was too easy to end up with invalid region rectangles and we were
badly protected against them, so that they were hard to catch.
In fact we still create a main region for the top-bar, which ended up
getting a region height of -1. While this doesn't seem to have caused
issues in practice, we should prevent them entirely.
So idea was that at the end of region layout resolving,
`BLI_rcti_is_valid()` should return `true` for the region rectangle.
Further changes here ensure this is true: The `RGN_FLAG_TOO_SMALL` flag
is now set whenever there is not enough space for a region or if it
would get a size of zero or less.
Note: Should the assert fail, please do not just disable it and try to
actually address the root of the issue.
Simply loading factory settings and dragging an area separator
immediately after would cause an assert because of these invalid sizes.
Seems that since rB07499c04f612 we correctly initialize DPI related
UserPref values with 0, which caused DPI dependant initialization of
global areas to set ScrArea.global.size_min/max to 0 too.
When text drawing is disabled in the viewport the color of the sculpt
brh is set to the last used one. In th Light theme this is black what
makes it totally not visible.
This change will render the brush text using `TEXT_HI` as this is the
last one set when the text overlay is on.
event_system.c has been collecting a lot of different functionality,
move generic query/access functions into their own file,
since these are used by operators and other parts of the windowing code
and aren't part of low level event handling.
Also move public last-property API to wm_operators.c.
Logic to convert double-click events into press events wasn't running
in the case an operator had a modal keymap, causing bevel for e.g.
to ignore keys pressed quickly.
Change event handling logic so modal handlers never
receive double click events, so checks for press/release are reliable.
While this is an old issue for mouse events in practice it wasn't
a problem since the first event typically executed/canceled.
Support for keyboard double-click exposed the problem
for all modal operators that take numeric input.
As per T71295, the "duplicate+move" macro fails to store TRANSFORM_OT_translate properties once it's been used with rotation. I believe this is due to it being re-initialized with incorrect properties, reading bogus values from stored TRANSFORM_OT_rotate properties.
Force storing of actual operator id name instead of one defined in the macro, which in turn forces a name mismatch on initialization.
Reviewed By: #modeling, campbellbarton
Maniphest Tasks: T71295
Differential Revision: https://developer.blender.org/D6413
Move redraw tagging to the gesture modal operator
to make sure this only runs when it's needed.
Caused by d591c8a350, which tagged the region to redraw when the
gizmos were tagged to refresh, however they wont redraw when hidden.
Thanks to @jbakker for finding the root cause.
This defaults to selection when not using a gizmo.
The previous behavior to drag anywhere can be set in the tool settings
or by selecting the fallback tool (Alt-W).
See: T66304
Previously the default values were left non-zero to avoid having to
update scripts. However, this meant it wasn't possible to setup
non-modal key bindings for smooth & randomize.
Now these operators follow logic of many other operators where setting
the value executes immediately, leaving unset runs modal.
Existing keymaps & scripts will need to be updated.
Addresses issue raised in f4a4ec8425.
Previously the alpha was hardcoded to 0.7. Now it is possible to control
the cursor alpha by changing the alpha color of the cursor color
property. New alpha default is 0.9. This, with the new saturated colors,
should make the cursor more visible on highdpi screens.
I also removed the cache location preview as it is too visible right now
with the new alpha and color values.
Reviewed By: billreynish
Differential Revision: https://developer.blender.org/D6433
This commit affects `id_sort_by_name()` and `check_for_dupid()` helper:
* Add a new parameter, `ID *id_sorting_hint`, to `id_sort_by_name()`,
and when non-NULL, check if we can insert `id` immediately before or
after it. This can dramatically reduce time spent in that function.
* Use loop over whole list in `check_for_dupid()` to also define the
likely ID pointer that will be neighbor with our new one.
This gives another decent speedup to all massive addition cases:
| Number and type of names of IDs | old code | new code | speed improvement |
| -------------------------------- | -------- | -------- | ----------------- |
| 40K, mixed (14k rand, 26k const) | 39s | 33s | 18% |
| 40K, fully random | 51s | 42s | 21% |
| 40K, fully constant | 40s | 34s | 18% |
Combined with the previous commits, this makes massive addition of IDs more
than twice as fast as previously.
This resolves a logical problem using tweak as a fallback tool.
See: T66304#828742
The select action would immediately show the gizmo underneath it,
then the tweak would be handled by the gizmo instead of moving the item
under the cursor.
Currently this works by hiding the gizmo until the tweak event ends.
While it's simpler to check if the gizmo received a mouse-down event,
it causes flickering before each drag event which feels like a glitch.
This is optional for each gizmo type because there are cases where this
can be useful to activate the gizmo immediately (mesh rip for example).
This commit introduces the first version of an exporter to Pixar's
Universal Scene Description (USD) format.
Reviewed By: sergey, LazyDodo
Differential Revision: https://developer.blender.org/D6287
- The USD libraries are built by `make deps`, but not yet built by
install_deps.sh.
- Only experimental support for instancing; by default all duplicated
objects are made real in the USD file. This is fine for exporting a
linked-in posed character, not so much for thousands of pebbles etc.
- The way materials and UV coordinates and Normals are exported is going
to change soon.
- This patch contains LazyDodo's fixes for building on Windows in D5359.
== Meshes ==
USD seems to support neither per-material nor per-face-group
double-sidedness, so we just use the flag from the first non-empty
material slot. If there is no material we default to double-sidedness.
Each UV map is stored on the mesh in a separate primvar. Materials can
refer to these UV maps, but this is not yet exported by Blender. The
primvar name is the same as the UV Map name. This is to allow the
standard name "st" for texture coordinates by naming the UV Map as such,
without having to guess which UV Map is the "standard" one.
Face-varying mesh normals are written to USD. When the mesh has custom
loop normals those are written. Otherwise the poly flag `ME_SMOOTH` is
inspected to determine the normals.
The UV maps and mesh normals take up a significant amount of space, so
exporting them is optional. They're still enabled by default, though.
For comparison: a shot of Spring (03_035_A) is 1.2 GiB when exported
with UVs and normals, and 262 MiB without. We probably have room for
optimisation of written UVs and normals.
The mesh subdivision scheme isn't using the default value 'Catmull
Clark', but uses 'None', indicating we're exporting a polygonal mesh.
This is necessary for USD to understand our normals; otherwise the mesh
is always rendered smooth. In the future we may want to expose this
choice of subdivision scheme to the user, or auto-detect it when we
actually support exporting pre-subdivision meshes.
A possible optimisation could be to inspect whether all polygons are
smooth or flat, and mark the USD mesh as such. This can be added when
needed.
== Animation ==
Mesh and transform animation are now written when passing
`animation=True` to the export operator. There is no inspection of
whether an object is actually animated or not; USD can handle
deduplication of static values for us.
The administration of which timecode to use for the export is left to
the file-format-specific concrete subclasses of
`AbstractHierarchyIterator`; the abstract iterator itself doesn't know
anything about the passage of time. This will allow subclasses for the
frame-based USD format and time-based Alembic format.
== Support for simple preview materials ==
Very simple versions of the materials are now exported, using only the
viewport diffuse RGB, metallic, and roughness.
When there are multiple materials, the mesh faces are stored as geometry
subset and each material is assigned to the appropriate subset. If there
is only one material this is skipped.
The first material if any) is always applied to the mesh itself
(regardless of the existence of geometry subsets), because the Hydra
viewport doesn't support materials on subsets. See
https://github.com/PixarAnimationStudios/USD/issues/542 for more info.
Note that the geometry subsets are not yet time-sampled, so it may break
when an animated mesh changes topology.
Materials are exported as a flat list under a top-level '/_materials'
namespace. This inhibits instancing of the objects using those
materials, so this is subject to change.
== Hair ==
Only the parent strands are exported, and only with a constant colour.
No UV coordinates, no information about the normals.
== Camera ==
Only perspective cameras are supported for now.
== Particles ==
Particles are only written when they are alive, which means that they
are always visible (there is currently no code that deals with marking
them as invisible outside their lifespan).
Particle-system-instanced objects are exported by suffixing the object
name with the particle's persistent ID, giving each particle XForm a
unique name.
== Instancing/referencing ==
This exporter has experimental support for instancing/referencing.
Dupli-object meshes are now written to USD as references to the original
mesh. This is still very limited in correctness, as there are issues
referencing to materials from a referenced mesh.
I am still committing this, as it gives us a place to start when
continuing the quest for proper instancing in USD.
== Lights ==
USD does not directly support spot lights, so those aren't exported yet.
It's possible to add this in the future via the UsdLuxShapingAPI. The
units used for the light intensity are also still a bit of a mystery.
== Fluid vertex velocities ==
Currently only fluid simulations (not meshes in general) have explicit
vertex velocities. This is the most important case for exporting
velocities, though, as the baked mesh changes topology all the time, and
thus computing the velocities at import time in a post-processing step
is hard.
== The Building Process ==
- USD is built as monolithic library, instead of 25 smaller libraries.
We were linking all of them as 'whole archive' anyway, so this doesn't
affect the final file size. It does, however, make life easier with
respect to linking order, and handling upstream changes.
- The JSON files required by USD are installed into datafiles/usd; they
are required on every platform. Set the `PXR_PATH_DEBUG` to any value
to have the USD library print the paths it uses to find those files.
- USD is patched so that it finds the aforementioned JSON files in a path
that we pass to it from Blender.
- USD is patched to have a `PXR_BUILD_USD_TOOLS` CMake option to disable
building the tools in its `bin` directory. This is sent as a pull
request at https://github.com/PixarAnimationStudios/USD/pull/1048
