Blender Git Commits

actually use threading...

Safe and informative GHOST_Xr error handling

This wraps all functions that could fail into some proper (although
unfinished) error handling.

These were the requirements for the error handling strategy:
* If an error occurs, cleanly exit the VR session (or the context if the
error happend during its set up), causing no resource leaks or side
effects to the rest of Blender.
* Show a *useful* error message to the user.
* Don't impair readability of code too much with error handling.

After some back and forth I decided Ghost internal exceptions are the
best way to go about this. I get exceptions are a controversial feature,
IMHO that's because most people use them 'wrong' however. Here's the
rationale:
* Most alternatives require early exiting functions. This early exiting
has to be 'bubbled up' the call stack to the point that performs error
handling. So the code gets really impaired by error checking. Tried
this first and wasn't happy with it at all. Even if error handling is
wrapped into macros.
* All GHOST_Xr resources are managed via RAII. So stack unwinding will
cause them to be released cleanly whenever an exception is thrown.
* GHOST_Xr has a clear boundary (the Ghost C-API) with only a handful of
public functions. That is the only place we need to have try-catch
blocks at.
(Generally, try-catch blocks at kinda random places are a bad code
smell IMHO. Module boundaries are a valid place to put them.)
* Exceptions allow us to pass multiple bits of error information through
mulitple layers of the call stack. This information can also be made
specific with a useful error message.
As of now, they conain a user error message, the OpenXR error code (if
any), as well as the exact source code location the error was caught
at.

So if an error is caught inside GHOST_Xr code, an exception is thrown
with specific and hopefully useful information in it. In the Ghost C-API,
these exceptions are caught and passed on to a custom error handling
callback. This callback will be defined by the Blender window-manager
and output the error information via a usual user report popup (not done
yet). It can also ensure the entire session is shut down.

Note that the majority of errors OpenXR can return are for invalid API
usage. Assuming the API usage is valid though, most error messages
should never reach users and can be left a bit more vague. Maybe we can
add something like "This is probably a bug and should be reported" to
those.

Merge remote-tracking branch 'origin/master' into sybren-usd

USD: Export UV maps of meshes

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.

remove temporary code

use function to compute point input of point emitter

remove unused code

cleanup dependency builder

make updating depsgraph work again

improve fgraph dependencies

USD: Write mesh single/doublesidedness

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.

USD: Write edge creases to USD mesh

Only the crease is written to USD. The "Sharp" edge flag doesn't seem to
be supported by USD, or at least I couldn't find it in the API docs.

fixes

USD: Write current Blender version into USD file

cleanup

multimap fix

Merge remote-tracking branch 'origin/master' into sybren-usd

initial revised function dependency handling

utility functions to access data flow graph

simplify array printing