Surrounding includes with an 'extern "C"' block is not necessary anymore.
Also that made it harder to add any C++ code to some headers, or include headers
that have "optional" C++ code like `MEM_guardedalloc.h`.
I tested compilation on linux and windows (and got help from @LazyDodo).
If this still breaks compilation due to some linker error, the header containing
the symbol in question is probably missing an 'extern "C"' block.
Differential Revision: https://developer.blender.org/D7653
When writing out the module information in a crashdump
we did not include what symbol file was loaded and if
that symbol file actually matches our executable.
Given the backtraces may contain invalid information
if the symbols are unmatched this is relevant to know.
This diff adds the symbol file and an indication if
unmatched symbols are used.
To detect if private of public symbols were loaded we were relying
on a strcmp with a known filename, which was not great, the symbol
api has a field we can query which should be more flexible and
reliable.
With the recent backtrace overhaul, the fact that BLI_assert calls
BLI_system_backtrace slipped somehow trough the cracks, causing
issues for debug builds.
This change allows BLI_system_backtrace to run again without having
an exception record.
Also minor improvements to the comments.
Particle systems have two names: the name of the particle system itself,
and the name of the particle system settings. The USD exporter used to
use the latter name, and now switched to the former. This is to be in
line with the Alembic exporter, as well as to give users more freedom in
the naming (the particle system can have a unique name but still share
settings from other particle systems).
The matcap flipping didn't work with the workbench engine in rendered mode because
of a missing depedency graph update. This commit tags the scene id for a dependency
graph update in `toggle_matcap_flip`.
Reviewed By: fclem, sergey
Differential Revision: https://developer.blender.org/D7657
In the situation that the viewport was set to solid/texture mode and
switch to wireframe and sculpt mode, an assert was triggered in
`workbench_cache_sculpt_populate`.
The construction of the export graph is now split into a few steps:
- Construct a `HierarchyContext` object for the to-be-exported object.
- Determine the graph index, i.e. the export-parent and the duplicator.
- Update the `HierarchyContext` object for this graph index.
This allows the upcoming new Alembic exporter to override the location of
an object in the export graph, in order to support "flattened" exports.
Aside from that, this also simply makes the code cleaner.
No functional changes.
The long-term goal is to move code out of `abc_util.{h,cc}` into either
files with better, more concrete names, or simply into the one file
where they are used.
No functional changes.
When loading a file from the Python console with load_ui=False,
the event was never freed from the queue causing the command
to continuously be executed.
Operators should almost always implement exec() so that they can work without
user event input. In this case there was no reason to have invoke() at all
since no event is needed.
The file browser exit() callback was not called. RNA get functions should never
modify data, here the area type info to be changed before the screen and area
were properly updated.
The Extrude operator, whose orientation is NORMAL, has undergone some seemingly accidental changes:
- In 2.79 if you press the same key as the axis in constraint, it changes from Normal to No Contraint -> Global -> Normal and repeat this.
- In 2.80 it changes from Normal to Local -> No Contraint -> Global -> Local and repeat this.
This committee resumes the behavior of 2.79
Part of T74960 (and hence T75724).
This commit only adds the basics helper code, and alter some internal libquery
code to use it.
Porting each IDType to the new system will be done gradually from there,
to allow better detection and handling of potential issues.
Differential Revision: https://developer.blender.org/D7598
