July 12, 2019, 16:59 (GMT) |
macOS: remove hardcoded paths for code signing python/dylib/so Differential Revision: https://developer.blender.org/D5234 |
July 12, 2019, 15:01 (GMT) |
[Fast import/export] Added proper material support |
July 12, 2019, 15:01 (GMT) |
[Fast import/export] Fixed index of normals |
July 12, 2019, 14:37 (GMT) |
Fix T66601: Redo Panels are empty the first time a workspace is active We need to indicate a preferred size to avoid `RGN_FLAG_TOO_SMALL` the first time the region is created. Differential revision: https://developer.blender.org/D5238 |
July 12, 2019, 14:20 (GMT) |
Fix T66773: Active edit-bone isn't updating |
July 12, 2019, 14:14 (GMT) |
Cleanup: use `_orig` as a suffix |
July 12, 2019, 13:59 (GMT) |
USD: added USD export to the File > Export menu This also required exposing the build option `bpy.app.build_options.usd`. |
July 12, 2019, 13:20 (GMT) |
USD: Avoid writing invisible particle emitter meshes |
July 12, 2019, 13:19 (GMT) |
USD: Offer choice for viewport or render settings The exporter operator now takes a parameter to choose the depsgraph evaluation mode (Viewport/Render). This makes it easier to switch between exporting particle hair (Render) or mesh hair (Viewport). |
Revision b6b26ef by Jacques Lucke (builtin-simulation-nodes, functions, functions-experimental-refactor, particle-solver-dev, simulation-tree) July 12, 2019, 13:06 (GMT) |
Merge branch 'master' into functions |
Revision a84fcf8 by Jacques Lucke (builtin-simulation-nodes, functions, functions-experimental-refactor, particle-solver-dev, simulation-tree) July 12, 2019, 12:49 (GMT) |
actually use threading... |
Revision 330f062 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) July 12, 2019, 12:40 (GMT) |
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. |
July 12, 2019, 12:30 (GMT) |
July 12, 2019, 12:24 (GMT) |
Fix T66747: Active bone not showing in edit-mode |
July 12, 2019, 12:24 (GMT) |
Merge remote-tracking branch 'origin/master' into sybren-usd |
July 12, 2019, 12:18 (GMT) |
Fix AttributeError in mesh properties panel when mesh is pinned When a mesh datablock is pinned in the properties panel, `context.object` is `None`. This in turn causes `obj.mode` to raise an `AttributeError` exception as `None.mode` doesn't exist. Since there is no (fast/simple) way to check whether the owning object is in edit mode or not, the properties will be disabled. Not ideal, but better than spewing an exception on every panel draw. Reviewed By: campbellbarton, brecht Differential Revision: https://developer.blender.org/D5237 |
July 12, 2019, 12:15 (GMT) |
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. |
July 12, 2019, 12:09 (GMT) |
Fix T66689: Viewport isn't updating children hair particle on particle edit Reviewers: fclem, brecht Maniphest Tasks: T66689 Differential Revision: https://developer.blender.org/D5229 |
Revision 60a2d39 by Jacques Lucke (builtin-simulation-nodes, functions, functions-experimental-refactor, particle-solver-dev, simulation-tree) July 12, 2019, 12:08 (GMT) |
remove temporary code |
Revision 45b4704 by Jacques Lucke (builtin-simulation-nodes, functions, functions-experimental-refactor, particle-solver-dev, simulation-tree) July 12, 2019, 12:05 (GMT) |
use function to compute point input of point emitter |
|
|
|


Master Commits
MiikaH:n Sivut a.k.a. MiikaHweb | 2003-2021