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
This patch contains the work that I did during my week at the Code Quest - adding support for tiled images to Blender.
With this patch, images now contain a list of tiles. By default, this just contains one tile, but if the source type is set to Tiled, the user can add additional tiles. When acquiring an ImBuf, the tile to be loaded is specified in the ImageUser.
Therefore, code that is not yet aware of tiles will just access the default tile as usual.
The filenames of the additional tiles are derived from the original filename according to the UDIM naming scheme - the filename contains an index that is calculated as (1001 + 10*<y coordinate of the tile> + <x coordinate of the tile>), where the x coordinate never goes above 9.
Internally, the various tiles are stored in a cache just like sequences. When acquired for the first time, the code will try to load the corresponding file from disk. Alternatively, a new operator can be used to initialize the tile similar to the New Image operator.
The following features are supported so far:
- Automatic detection and loading of all tiles when opening the first tile (1001)
- Saving all tiles
- Adding and removing tiles
- Filling tiles with generated images
- Drawing all tiles in the Image Editor
- Viewing a tiled grid even if no image is selected
- Rendering tiled images in Eevee
- Rendering tiled images in Cycles (in SVM mode)
- Automatically skipping loading of unused tiles in Cycles
- 2D texture painting (also across tiles)
- 3D texture painting (also across tiles, only limitation: individual faces can not cross tile borders)
- Assigning custom labels to individual tiles (drawn in the Image Editor instead of the ID)
- Different resolutions between tiles
There still are some missing features that will be added later (see T72390):
- Workbench engine support
- Packing/Unpacking support
- Baking support
- Cycles OSL support
- many other Blender features that rely on images
Thanks to Brecht for the review and to all who tested the intermediate versions!
Differential Revision: https://developer.blender.org/D3509
Also adds a generic popover that can be used whenever an active tool has too
many settings than can fit in the horizontal area. The popover calls the active
tool's draw_settings with "extra" set to True.
Users should be able to know explicitly what they are testing.
By having them all enabled we run into a scenario where a new
experimental feature may have been introduced, and the user
is now using it without being even aware of that.
Differential Revision: https://developer.blender.org/D6404
It seems it does work along multiple axes in some cases, but not at all. So
restored the UI for now, waiting for a better fix.
This reverts commit 9569425b02.
Part of T70240
This is the initial implementation of Weld Modifier.
New features will be added later.
ToDo:
- Seams: restrict welding to vertices along boundary edges.
- Edge Collapse: collapse edges below the length threshold.
- New icon.
- Some customdata are not being correctly interpolated.
Differential Revision: https://developer.blender.org/D6383
Scale Cage was using the same shortcut as Insert Scale Keyframe (Shift-R)
This isn't neccessary anyway since you can use the same key to cycle the tools.
Custom render passes are added in the Shader AOVs panel in the view layer
settings, with a name and data type. In shader nodes, an AOV Output node
is then used to output either a value or color to the pass.
Arbitrary names can be used for these passes, as long as they don't conflict
with built-in passes that are enabled. The AOV Output node can be used in both
material and world shader nodes.
Implemented by Lukas, with tweaks by Brecht.
Differential Revision: https://developer.blender.org/D4837
The issue is that `something.path_resolve('"custom_property"')` raises a
`ValueError` when the custom property is set to `None`. Since `None`
cannot be stored in a keyframe anyway, the property is now silently
skipped. Not having an explicit value is the closest we can get to
`None`. This of course breaks when the value should be `None` in between
not-`None` values, but I would consider that as a problem with the rig,
and not something Blender can fix.
This can be used to make closed surfaces behave more like a soft body.
Reviewed By: Jacques Lucke
Differential Revision: http://developer.blender.org/D5788
This makes is so repeated key presses will cycle the tools in the same slot in the toolbar.
Users can tap Q repeatedly to switch selection tools, or press Ctrl-E repeatedly to enable the various Extrude tools, etc.
Modes: Linear interpolation (default), stepped linear, smoothstep and smootherstep.
This also includes an additional option for the **Clamp node** to switch between **Min Max** (default) and **Range** mode.
This was needed to allow clamping when **To Max** is less than **To Min**.
Reviewed By: JacquesLucke, brecht
Differential Revision: https://developer.blender.org/D5827
Allows each File Browser list item in Volumes and System to use individual icons.
Differential Revision: https://developer.blender.org/D5802
Reviewed by Julian Eisel
Implement T66304 as an experimental option,
available under the preferences "Experimental" section.
- When enabled most tools in the 3D view have a gizmo.
- Dragging outside the gizmo uses the 'fallback' tool.
- The fallback tool can be changed or disabled in the tool options
or from a pie menu (Alt-W).
Multisample buffers were used for smooth line drawing. As we now have
an algorithm that doesn't need the multisample buffers we can remove
them.
The user preference for viewport multi_sampling is replaced by single
toggle overlay `use_overlay_smooth_wire`. By default this setting is
enabled as the new drawing is really quick (<1ms) and uses zero hacks.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6367
Enables Windows 10 feature that automatically adjusts non-client area (title bar) on high-DPI displays.
Differential Revision: https://developer.blender.org/D6370
Reviewed by Brecht Van Lommel
Previously the decimation would take the whole curve into account when
decimating and not just the selected part.
This also contains various smaller bug fixes for the fcurve decimation.
Reviewed By: Sybren
Differential Revision: http://developer.blender.org/D6286
Add new icons and panels Grease Pencil Dopesheet to manage layers without having the properties panel visible.
Also, the icons are in the same order in Dopesheet, Layers and Material list to keep consistency.
As the number of columns for icons is limited to 3 and we also need use a factor, I have impleted the change using slider area. Also, the slider option is enabled by default for 2D Template.
See T72026 for more info.
Reviewed By: mendio, pepeland, billreynish
Differential Revision: https://developer.blender.org/D6328
Introduced a way to specify cloth pressure force influence with a vertex
group. This will allow users to only have pressure affect certain parts
of the mesh.
In addition to this, the "shrink factor" is now also unlocked to allow
negative values and thus allowing the cloth mesh to grow as well.
Reviewed By: Jaques Lucke
Differential Revision: http://developer.blender.org/D6347
Stupid mistake, 'original' filepath is a blender-flavored one, with
potentially weird things like the '//' relative 'header'... This can
work on linux (also it could have broken in other places too), but on
windows that is fully invalid path and python `os.path` library just
generates empty result here.
Simply using proper valid path instead fixes it...
This is the unification of all overlays into one overlay engine as described in T65347.
I went over all the code making it more future proof with less hacks and removing old / not relevent parts.
Goals / Acheivements:
- Remove internal shader usage (only drw shaders)
- Remove viewportSize and viewportSizeInv and put them in gloabl ubo
- Fixed some drawing issues: Missing probe option and Missing Alt+B clipping of some shader
- Remove old (legacy) shaders dependancy (not using view UBO).
- Less shader variation (less compilation time at first load and less patching needed for vulkan)
- removed some geom shaders when I could
- Remove static e_data (except shaders storage where it is OK)
- Clear the way to fix some anoying limitations (dithered transparency, background image compositing etc...)
- Wireframe drawing now uses the same batching capabilities as workbench & eevee (indirect drawing).
- Reduced complexity, removed ~3000 Lines of code in draw (also removed a lot of unused shader in GPU).
- Post AA to avoid complexity and cost of MSAA.
Remaining issues:
- ~~Armature edits, overlay toggles, (... others?) are not refreshing viewport after AA is complete~~
- FXAA is not the best for wires, maybe investigate SMAA
- Maybe do something more temporally stable for AA.
- ~~Paint overlays are not working with AA.~~
- ~~infront objects are difficult to select.~~
- ~~the infront wires sometimes goes through they solid counterpart (missing clear maybe?) (toggle overlays on-off when using infront+wireframe overlay in solid shading)~~
Note: I made some decision to change slightly the appearance of some objects to simplify their drawing. Namely the empty arrows end (which is now hollow/wire) and distance points of the cameras/spots being done by lines.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D6296
Instead of having the option to show marker lines,
make the marker region optional.
- Added a Show Markers entry in the View menu of the animation editors.
- If the markers region is not active then the Marker menu gets hidden.
- Removed marker menu from the driver editor
and don't allow to use marker operators.
This patch will allow the user to select the EEVEE renderpass to be
shown in the viewport by default the combined pass will be shown.
Limitations:
* Viewport rendering stores the result in a `RenderResult`. RenderResult
is not aware of the type of data it holds. In many places where RenderResult
is used it is assumed that it stores a combined pass and the display+view
transform are applied.
I will propose to fix this in a future patch. But that is still being
designed and discussed.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6319
This adds support to the current sculpt sample detail operator to sample
a voxel size for the voxel remesher when sculpting on regular meshes.
It provides an approximation of a voxel size that is going to preserve
the sampled sculpt details after remeshing. It is not going to be 100%
accurate in all cases as it relies on having consistent edge length in
the whole sculpt, but it saves a lot of time and avoids guessing the
voxel size by trying different values.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D6251
