Implements the GPv2 onion skinning functionality.
There are no functional changes exept for the `use_ghosts_always`
option, which has been removed. This was used to show onion
skinning in the final render.
Pull Request: https://projects.blender.org/blender/blender/pulls/119792
`UUID` generally stands for "universally unique identifier". The session identifier that
we use is neither universally unique, nor does it follow the standard. Therefor, the term
"session uuid" is confusing and should be replaced.
In #116888 we briefly talked about a better name and ended up with "session uid".
The reason for "uid" instead of "id" is that the latter is a very overloaded term in Blender
already.
This patch changes all uses of "uuid" to "uid" where it's used in the context of a
"session uid". It's not always trivial to see whether a specific mention of "uuid" refers
to an actual uuid or something else. Therefore, I might have missed some renames.
I can't think of an automated way to differentiate the case.
BMesh also uses the term "uuid" sometimes in a the wrong context (e.g. `UUIDFaceStepItem`)
but there it also does not mean "session uid", so it's *not* changed by this patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/117350
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
Part 1/3 of #109135, #110272
Adds a new DNA structure for defining node group interfaces without
using `bNodeSocket` and with additional node UI item types.
Node group interfaces are organized as a hierarchy of "items", which
can be sockets or panels. Panels can contain both sockets and other
panels (although nested panels beyond the root panel may be disabled to
avoid complexity on the user level).
Sockets can be added to the interface in any order, not just the
conventional outputs..inputs order. Sockets can be marked as both input
and output, generating 2 sockets on node instances.
The C++ API in the DNA struct allows manipulating the interface
declaration by adding and removing items, moving them inside the
interface or into a different panel.
Pull Request: https://projects.blender.org/blender/blender/pulls/110885
Add an API for armature layer access. Instead of accessing `arm->layer`
and friends directly, the code now uses this API. This will make things
easier to replace by bone collections in the future.
The functions are named "bonecoll" (short for "bone collection"), as
that's the soon-to-be-introduced replacement for armature layers. This
API is the first step towards that replacement, and should help to
reduce the changes necessary when functional changes are committed.
This also creates a new module `source/blender/animrig` for Animation &
Rigging code. This will, for example, house the bone collection system
in the near future.
There is a bunch of code currently spread across blenkernel and editors
in a rather ad-hoc way; it is intended that at some point that code gets
moved into `animrig` as well (or at least the subset of that code where
such a move makes sense; brain still required).
Ref: #108941
No functional changes.
This data-block was originally added in eb4e3bbe68.
However, that original plan wasn't fully implemented, with simulations
now integrated with geometry nodes and modifiers instead of a separate
data-block. We kept the data-block around anyway since we have the
loose plan of using a similar data-block to make global simulations
connected between multiple objects. But it may be a while before we
implement that, and in the meantime having this just causes confusion.
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
Adds the initial stage for the grease pencil 3.0 project.
This patch includes:
* New ID and new object type.
* New DNA structures.
* New drawing engine for grease pencil (gpencil-next).
* Tests for the new grease pencil data-type.
* A few operators for conversion, switching modes and (simple) drawing.
Exposed to the user:
* An experimental option to switch to the new grease pencil.
* This will switch the grease pencil render engine to gpencil-next which can only render the new object type.
Current grease pencil objects will no longer render.
* Changing this option currently requires a restart of blender (for the keymap to update).
* A conversion setting in the `Object` > `Convert To` operator.
* A drawing operator in `Draw Mode`.
Pull Request: https://projects.blender.org/blender/blender/pulls/106848
This option is true by default, but it can be changed for
any asset library (that may be using Link as import method).
This also fix "Reset to Default Value" for the Import Method
since this was originally not using the defaults.
Pull Request: https://projects.blender.org/blender/blender/pulls/107345
This checkin will use OIIO to replace the image save/load code for BMP,
DDS, DPX, HDR, PNG, TGA, and TIFF.
This simplifies our build environment, reduces binary duplication,
removes large amounts of hard to maintain code, and fixes some bugs
along the way.
It should also help reduce rare differences between Blender and Cycles
which already uses OIIO for most situations. Or potentially makes them
easier to solve once discovered.
This is a continuation of the work for #101413
Pull Request: https://projects.blender.org/blender/blender/pulls/105785
The goal is to solve confusion of the "All rights reserved" for licensing
code under an open-source license.
The phrase "All rights reserved" comes from a historical convention that
required this phrase for the copyright protection to apply. This convention
is no longer relevant.
However, even though the phrase has no meaning in establishing the copyright
it has not lost meaning in terms of licensing.
This change makes it so code under the Blender Foundation copyright does
not use "all rights reserved". This is also how the GPL license itself
states how to apply it to the source code:
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software ...
This change does not change copyright notice in cases when the copyright
is dual (BF and an author), or just an author of the code. It also does
mot change copyright which is inherited from NaN Holding BV as it needs
some further investigation about what is the proper way to handle it.
During the discussion for #101413 there was consensus that we could make
OIIO a mandatory dependency. This patch does just that.
The `idiff` testing tool remains optional.
Pull Request #105111
Adds a new `source/blender/asset_system` directory and moves asset
related files from BKE to it. More asset related code can follow
(e.g. asset indexing, ED_assetlist stuff) but needs further work to
untangle it. I also kept `BKE_asset.h` and `asset.cc` as is, since they
deal with asset DNA data mostly, thus make sense in BKE.
Motivation:
- Makes the asset system design more present (term wasn't even used in
code before).
- An `asset_system` directory is quite descriptive (trivial to identify
core asset system features) and makes it easy to find asset code.
- Asset system is mostly runtime data, with little relation to other
`Main`/BKE/DNA types.
- There's a lot of stuff in BKE already. It shouldn't be just a dump for
all stuff that seems core enough.
- Being its own directly helps us be more mindful about encapsulating
the module well, and avoiding dependencies on other modules.
- We can be more free with splitting files here than in BKE.
- In future there might be an asset system BPY module, which would then
map quite nicely to the `asset_system` directory.
Checked with some other core devs, consensus seems that this makes
sense.
This adds support for showing geometry passed to the Viewer in the 3d
viewport (instead of just in the spreadsheet). The "viewer geometry"
bypasses the group output. So it is not necessary to change the final
output of the node group to be able to see the intermediate geometry.
**Activation and deactivation of a viewer node**
* A viewer node is activated by clicking on it.
* Ctrl+shift+click on any node/socket connects it to the viewer and
makes it active.
* Ctrl+shift+click in empty space deactivates the active viewer.
* When the active viewer is not visible anymore (e.g. another object
is selected, or the current node group is exit), it is deactivated.
* Clicking on the icon in the header of the Viewer node toggles whether
its active or not.
**Pinning**
* The spreadsheet still allows pinning the active viewer as before.
When pinned, the spreadsheet still references the viewer node even
when it becomes inactive.
* The viewport does not support pinning at the moment. It always shows
the active viewer.
**Attribute**
* When a field is linked to the second input of the viewer node it is
displayed as an overlay in the viewport.
* When possible the correct domain for the attribute is determined
automatically. This does not work in all cases. It falls back to the
face corner domain on meshes and the point domain on curves. When
necessary, the domain can be picked manually.
* The spreadsheet now only shows the "Viewer" column for the domain
that is selected in the Viewer node.
* Instance attributes are visualized as a constant color per instance.
**Viewport Options**
* The attribute overlay opacity can be controlled with the "Viewer Node"
setting in the overlays popover.
* A viewport can be configured not to show intermediate viewer-geometry
by disabling the "Viewer Node" option in the "View" menu.
**Implementation Details**
* The "spreadsheet context path" was generalized to a "viewer path" that
is used in more places now.
* The viewer node itself determines the attribute domain, evaluates the
field and stores the result in a `.viewer` attribute.
* A new "viewer attribute' overlay displays the data from the `.viewer`
attribute.
* The ground truth for the active viewer node is stored in the workspace
now. Node editors, spreadsheets and viewports retrieve the active
viewer from there unless they are pinned.
* The depsgraph object iterator has a new "viewer path" setting. When set,
the viewed geometry of the corresponding object is part of the iterator
instead of the final evaluated geometry.
* To support the instance attribute overlay `DupliObject` was extended
to contain the information necessary for drawing the overlay.
* The ctrl+shift+click operator has been refactored so that it can make
existing links to viewers active again.
* The auto-domain-detection in the Viewer node works by checking the
"preferred domain" for every field input. If there is not exactly one
preferred domain, the fallback is used.
Known limitations:
* Loose edges of meshes don't have the attribute overlay. This could be
added separately if necessary.
* Some attributes are hard to visualize as a color directly. For example,
the values might have to be normalized or some should be drawn as arrays.
For now, we encourage users to build node groups that generate appropriate
viewer-geometry. We might include some of that functionality in future versions.
Support for displaying attribute values as text in the viewport is planned as well.
* There seems to be an issue with the attribute overlay for pointclouds on
nvidia gpus, to be investigated.
Differential Revision: https://developer.blender.org/D15954
Currently, the compositor can be disabled using the WITH_COMPOSITOR
build option. Since, we intent to always build the realtime compositor,
we need to make the distinction between both compositors clear.
So this patch renames the option to WITH_COMPOSITOR_CPU. Additionally,
the check for the option was moved inside the compositor modules' own
CMake file in preparation for the realtime compositor code.
Differential Revision: https://developer.blender.org/D15622
Reviewed By: Jeroen Bakker, Ray Molenkamp
There's currently 4 places that need to be edited when adding
a DNA header, and as you can imagine, this has gotten out of
sync quite a bit.
source/blender/CMakeLists.txt - 84 headers
source/blender/makesdna/intern/CMakeLists.txt - 33 headers
source/blender/makesdna/intern/makesdna.c@includefiles - 77 headers
source/blender/makesdna/intern/makesdna.c@Disabletypes - 76 headers
This diff makes source/blender/CMakeLists.txt the only place
where we need to keep track of dna headers, less maintenance
less mistakes. For all old places there is now a comment reminding
people of the new location.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D13048
This adds a new sculpt mode to the experimental new curves object.
Currently, this mode can only be entered and exited, nothing else.
The main initial purpose of this node will be to use it for hair grooming.
The patch also adds the `editors/curves/` directory for the new curves
object, which will be necessary for many other things as well.
I added a completely new mode (`OB_MODE_SCULPT_CURVES`), because
`OB_MODE_SCULPT` seems to be rather specific to meshes, and reusing
it doesn't seem worth the trouble. The tools/brushes used in mesh vs.
curves sculpt mode are quite distinct as well.
I had to add DNA_userdef_enums.h to make the patch compile with C++
(forward declaration of enums isn't allowed). This follows the same
pattern that we use for other enums in dna.
Differential Revision: https://developer.blender.org/D14107
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
Based on discussions from T95355 and T94193, the plan is to use
the name "Curves" to describe the data-block container for multiple
curves. Eventually this will replace the existing "Curve" data-block.
However, it will be a while before the curve data-block can be replaced
so in order to distinguish the two curve types in the UI, "Hair Curves"
will be used, but eventually changed back to "Curves".
This patch renames "hair-related" files, functions, types, and variable
names to this convention. A deep rename is preferred to keep code
consistent and to avoid any "hair" terminology from leaking, since the
new data-block is meant for all curve types, not just hair use cases.
The downside of this naming is that the difference between "Curve"
and "Curves" has become important. That was considered during
design discussons and deemed acceptable, especially given the
non-permanent nature of the somewhat common conflict.
Some points of interest:
- All DNA compatibility is lost, just like rBf59767ff9729.
- I renamed `ID_HA` to `ID_CV` so there is no complete mismatch.
- `hair_curves` is used where necessary to distinguish from the
existing "curves" plural.
- I didn't rename any of the cycles/rendering code function names,
since that is also used by the old hair particle system.
Differential Revision: https://developer.blender.org/D14007
Make building the thumbnail extraction executable optional,
disable on macOS as this was not linking, further, macOS doesn't use
this for thumbnail extraction so it could be left disabled.
Thumbnail extraction now shares code between Linux/Windows,
allowing thumbnails from Zstd compressed blend files to be extracted.
The main logic is placed in blendthumb_extract.cc and is built as static
library. For windows there is DLL which is registered during blender
install and which then reads and generates thumbnails.
For other platforms there is blender-thumbnailer executable file which
takes blend file as an input and generates PNG file. As a result
Python script blender-thumbnailer.py is no longer needed.
The thumbnail extractor shares the same code-path as Blenders file
reading, so there is no need to duplicate any file reading logic.
This means reading compressed blend files is supported (broken since
the recent move Zstd compression - D5799).
This resolves T63736.
Contributors:
- @alausic original patch.
- @LazyDodo windows fixes/support.
- @campbellbarton general fixes/update.
- @lukasstockner97 Zstd support.
Reviewed By: sybren, mont29, LazyDodo, campbellbarton
Ref D6408
This commit adds a fields version of the mesh to curve node, with a
field for the input selection. In order to reduce code duplication,
it adds the mesh to curve conversion to the new geometry module
and calls that implementation from both places.
More details on the geometry module can be found here: T86869
Differential Revision: https://developer.blender.org/D12579
Add `BLI_uuid` and `DNA_uuid_types.h` with a UUID implementation
following RFC4122 (https://datatracker.ietf.org/doc/html/rfc4122.html).
The following features are implemented:
- A struct of 128 bits that can be used in DNA definitions.
- Generation of version 4 UUIDs, that is, purely random ones.
- UUID equality function.
- String to UUID and UUID to string conversion functions that are
compatible with RFC4122.
- C++ stream operator that outputs the UUID as string.
This UUID will be used by the asset system, to uniquely identify asset
catalogs.
Reviewed By: Severin, jacqueslucke
Differential Revision: https://developer.blender.org/D12475
This adds the LineArt grease pencil modifier.
It takes objects or collections as input and generates various grease
pencil lines from these objects with the help of the active scene
camera. For example it can generate contour lines, intersection lines
and crease lines to name a few.
This is really useful as artists can then use 3D meshes to automatically
generate grease pencil lines for characters, enviroments or other
visualization purposes.
These lines can then be baked and edited as regular grease pencil lines.
Reviewed By: Sebastian Parborg, Antonio Vazquez, Matias Mendiola
Differential Revision: http://developer.blender.org/D8758
This avoids adding DNA_ID.h into other headers, recently changed in
cfa48c84d0
Note that other enums could be moved too, this is a smaller change
to avoid indirectly including DNA_ID.h in many places.
Asset metadata is what turns a regular data-block into an asset. It is a small
data-structure, but a key part of the technical design of the asset system.
The design foresees that asset data-blocks store an `ID.asset_data` pointer of
type `AssetMetaData`. This data **must not** have dependencies on other
data-blocks or data-block data, it must be an independent unit. That way we can
read asset-metadata from .blends without reading anything else from the file.
The Asset Browser will use this metadata (together with the data-block name,
preview and file path) to represent assets in the file list.
Includes:
* New `ID.asset_data` for asset metadata.
* Asset tags, description and custom properties.
* BKE code to manage asset meta-data and asset tags.
* Code to read asset data from files, without reading IDs.
* RNA for asset metadata (including tags)
Part of the first Asset Browser milestone. Check the #asset_browser_milestone_1
project milestone on developer.blender.org.
Differential Revision: https://developer.blender.org/D9716
Reviewed by: Bastien Montagne, Brecht Van Lommel
This is first step of refactoring task T77580.
Next step will be breaking up files into smaller ones.
Reviewed By: sergey, brecht
Differential Revision: https://developer.blender.org/D8492
Function names will be updated in a separate commit.
This will be the place for the new particle system and other
code related to the Simulation data block. We don't want
to have all that code in blenkernel.
Approved by brecht.
This adds a new `CPPType` that encapsulates information about how to handle
instances of a specific data type. This is necessary for the function evaluation
system, which will be used to evaluate most of the particle node trees.
Furthermore, this adds an `IndexMask` class which offers a surprisingly useful
abstraction over an array containing unsigned integers. It makes two assumptions
about the underlying integer array:
* The integers are in ascending order.
* There are no duplicates.
`IndexMask` will be used to "select" certain particles that will be
processed in a data-oriented way. Sometimes, operations don't have to
be applied to all particles, but only some, those that are in the indexed by
the `IndexMask`. The two limitations imposed by an `IndexMask` allow for
better performance.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D7957
NOTE: While most of the milestone 1 goals are there, a few smaller features and
improvements are still to be done.
Big picture of this milestone: Initial, OpenXR-based virtual reality support
for users and foundation for advanced use cases.
Maniphest Task: https://developer.blender.org/T71347
The tasks contains more information about this milestone.
To be clear: This is not a feature rich VR implementation, it's focused on the
initial scene inspection use case. We intentionally focused on that, further
features like controller support are part of the next milestone.
- How to use?
Instructions on how to use this are here:
https://wiki.blender.org/wiki/User:Severin/GSoC-2019/How_to_Test
These will be updated and moved to a more official place (likely the manual) soon.
Currently Windows Mixed Reality and Oculus devices are usable. Valve/HTC
headsets don't support the OpenXR standard yet and hence, do not work with this
implementation.
---------------
This is the C-side implementation of the features added for initial VR
support as per milestone 1. A "VR Scene Inspection" Add-on will be
committed separately, to expose the VR functionality in the UI. It also
adds some further features for milestone 1, namely a landmarking system
(stored view locations in the VR space)
Main additions/features:
* Support for rendering viewports to an HMD, with good performance.
* Option to sync the VR view perspective with a fully interactive,
regular 3D View (VR-Mirror).
* Option to disable positional tracking. Keeps the current position (calculated
based on the VR eye center pose) when enabled while a VR session is running.
* Some regular viewport settings for the VR view
* RNA/Python-API to query and set VR session state information.
* WM-XR: Layer tying Ghost-XR to the Blender specific APIs/data
* wmSurface API: drawable, non-window container (manages Ghost-OpenGL and GPU
context)
* DNA/RNA for management of VR session settings
* `--debug-xr` and `--debug-xr-time` commandline options
* Utility batch & config file for using the Oculus runtime on Windows.
* Most VR data is runtime only. The exception is user settings which are saved
to files (`XrSessionSettings`).
* VR support can be disabled through the `WITH_XR_OPENXR` compiler flag.
For architecture and code documentation, see
https://wiki.blender.org/wiki/Source/Interface/XR.
---------------
A few thank you's:
* A huge shoutout to Ray Molenkamp for his help during the project - it would
have not been that successful without him!
* Sebastian Koenig and Simeon Conzendorf for testing and feedback!
* The reviewers, especially Brecht Van Lommel!
* Dalai Felinto for pushing and managing me to get this done ;)
* The OpenXR working group for providing an open standard. I think we're the
first bigger application to adopt OpenXR. Congratulations to them and
ourselves :)
This project started as a Google Summer of Code 2019 project - "Core Support of
Virtual Reality Headsets through OpenXR" (see
https://wiki.blender.org/wiki/User:Severin/GSoC-2019/).
Some further information, including ideas for further improvements can be found
in the final GSoC report:
https://wiki.blender.org/wiki/User:Severin/GSoC-2019/Final_Report
Differential Revisions: D6193, D7098
Reviewed by: Brecht Van Lommel, Jeroen Bakker
This moves the `alembic`, `avi`, `collada`, and `usd` modules into a common
`io` directory.
This also cleans up some `#include "../../{somedir}/{somefile}.h"` by
adding `../../io/{somedir}` to `CMakeLists.txt` and then just using
`#include "{somefile}.h"`.
No functional changes.
A collection of smaller changes that are required in the /blender/source files. A lot of them are also due to variable renaming.
Reviewed By: sergey
Maniphest Tasks: T59995
Differential Revision: https://developer.blender.org/D3855
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
Custom profiles in bevel allows the profile curve to be controlled by
manually placed control points. Orientation is regularized along
groups of edges, and the 'pipe case' is updated. This commit includes
many updates to comments and changed variable names as well.
A 'cutoff' vertex mesh method is added to bevel in addition to the
existing grid fill option for replacing vertices.
The UI of the bevel modifier and tool are updated and unified.
Also, a 'CurveProfile' widget is added to BKE for defining the profile
in the interface, which may be useful in other situations.
Many thanks to Howard, my mentor for this GSoC project.
Reviewers: howardt, campbellbarton
Differential Revision: https://developer.blender.org/D5516
Previously this was done in the deps builder due to the fact we needed
both 32 and 64 bit versions of this dll and CMAKE does not support that
in a single build folder. Now that 32 bit support has been dropped, this
can be safely moved into the codebase.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D5633
Falk David
Jacques Lucke
Campbell Barton
Lukas Tönne
Hans Goudey
Sybren A. Stüvel
Sergey Sharybin
Dalai Felinto
Jesse Yurkovich
Falk David
Julian Eisel
Omar Emara
Ray Molenkamp
Campbell Barton
YimingWu
Richard Antalik
Sebastián Barschkis