This is not nVidia specific as scene updates affect all the devices. The patch is about preparing the data for the kernel a bit faster, by skipping unnecessary work. With this, there is also less data transferred to the GPU between updates (depending on what’s in your scene), regardless of the GPU vendor.
There used to be some OptiX specific improvements (for BVH building) which are no longer possible, but will make a come back at some point.
Neither I do!..
My bad, I actually never used “Object Children” outline filter. I always thought it hides children, but it doesn’t: it removes indentation and hierarchy lines for children objects (quite un-useful btw)
For the Add Object tool this was used, but could’ve worked better.
Most feedback was still given after it became non-experimental.
In the alpha phase, experimental features can be enabled by default more often.
Campbell asked about how we feel about the workboard; if we find it useful.
Release column is very useful.
In general the workboard can be useful, but of course there are many tasks, it’s not too organized.
Julian suggests that’s probably fine for now. Active tasks can be organized well, besides that, it’s more important to have an honest view of the state of the module than to have a clean workboard. (Don’t sweep issues under the rug.)
For bigger projects, create (sub-)projects and milestones more often. Like done for Geometry Nodes and the Asset Browser.
Try to assign the “Good First Issue” task more often. We can promote such issues to contributors then.
We could make more use of the papercuts workboard too.
Preparing a list of easy to solve papercuts could help getting contributors interested.
On the other hand, that would require more patch review and helping.
For now the papercuts simply aren’t our focus. It’s still a good idea to collect them, hopefully we can give them more attention before too long.
Work on classifying reports (60+ at beginning of the bug sprint)
Module members are welcome to help with this.
Add object tool
Use “Default” orientation when not mouse hovering and object. Otherwise, “Surface”.
Make axis switching an option (off by default).
Pablo can check if further design tweaks (size, color, opacity, etc.) should be done.
Categories could be created dynamically, e.g. IDTypeInfo could have a data-member or callback to define a category. Non-ID assets could provide it in a similar way.
The Blender Institute organized things so the project can be worked on for 6-8 weeks by a squad of 5+ people, starting Feb 1.
Milestone 1 and pose libraries should be talked this way.
More information should soon be published by the Institute.
Campbell will be involved with the Asset Browser the coming weeks, has less time for the tool system.
He will try to squeeze time for keymap work in (alternative keymap using the gizmos by default; hold Alt to activate gizmo from anywhere).
All sorts of polish could be done, mostly gizmos to be added or improved, not so much on the tool system side.
Extended Camera Gizmos (T57234 6):
Better not implement 2D widget support (number buttons, menus, etc.) for gizmos yet, but we could do it in future.
For now button-like gizmos can stay simple (no keyframing, text input, etc.)
Add Object Tool: Plane & Circle will be added as “Good First Issue”.
Participant: Julian Eisel.
No new, bigger projects in the team agenda
Dalai proposed a few geometry-nodes related UI tasks that the UI team could tackle:
Alembic procedural patch updated by Kévin to work more like proxies, Brecht will review.
Stefan notes the Cycles standalone repo has no been updated, he will look into it himself and ask Brecht for help if needed.
Stefan also proposes to track the Blender LTS in a Cycles standalone repo branch, for studios that are using Blender LTS along with another Cycles implementation like usdHydra. Brecht agrees with the idea, but to keep amount of work under control perhaps such a branch would be updated once per release along with master, rather than the more frequent Blender LTS releases.
Thomas reports AMD has fixed the normal bug in the driver, expected to be in the next driver release. We already have a workaround in the latest LTS and upcoming release, but this driver update will help users with other Blender versions.
I wouldn’t be surprised if the reason is to not overload the devs. with meetings. They already have Tuesday Talks, module meetings, and now the sprint/scrum meetings. There is a line where over-management starts to occur and productivity plummets.
In short, don’t fix what isn’t broken, but identify the improvements that can be made to the current development model.
It is a move that is lower risk and potentially leads to lower reward, but it also means a higher chance of avoiding a development blunder that could take months or even years to climb out of (which in turn negates any benefit a new model might have).
Pablo did an overview and demo of Expand. The initial impression is positive.
Julien and Daniel will try it for the following days. Pablo will start cleaning up the code to get it ready for merge.
We agree on merging it as soon as possible (2.93) with limited functionality and features for Multires and Dyntopo.
Some of the UI namings of its options (Geodesic distances, Topology diagonals…) can be confusing as they refer to implementation details. We will revisit this in the patch review.
Matcaps were included in 2.80 using a call for content from the community. These matcaps only include a diffuse pass. In 2.81, separate specular pass support was added to matcap rendering, but none of the current matcaps was using this feature because we don’t have access to all the contributed source files. In order to solve this and continue improving matcap rendering, we decided to handle the design of the matcaps ourselves.
Daniel created a file recreating all current matcaps so we could extract diffuse and specular as separate layers.
We went through all current matcaps to discuss a new default set to ship with Blender, focused on functionality. We agree on the current set of matcaps to be the default:
We agree on adding a global smooth strength factor property as part of Sculpt to control the intensity of smoothing without changing to the smooth brush. Pablo will make a patch for this soon.
Daniel reported some bugs in the Scene Project tool related to incorrect and noisy projection. All those bugs (and some more) are now fixed in the branch. The tool should now be ready for master.
Daniel suggested an overlay/cursor option to show the sculpt pivot when using the transform tools. Pablo will try to implement a prototype in sculpt-dev.
Daniel suggested a way to implement lasso projection for the gesture. Pablo will try to implement a limited version of that in sculpt-dev, as the proposed behavior requires too many hacks in the code.
Daniel suggested a tool for adding separate volumes by replicating a mesh along the stroke and then remesh all new geometry. Pablo will try to implement a prototype for this, but probably will have too many limitations and UI issues to be good enough for master
Julien suggested a tool for sculpting and replicating shapes along curves. Pablo will make a prototype of a tube creation brush, but probably more advanced functionality related to curves should be implemented in the curve object.
Julien suggested cleaning up the mask pie menu by creating a Mask Filter. Pablo will work on this.
Julien showed a proposal for cleaning up the UI and show only the most used features. We agree that it needs a broader discussion with the UI team to handle these kinds of changes.
Pablo suggested discussing the patch for cleaning up the keymap (https://developer.blender.org/D10230 ). We agree on addressing only the part related to context menus and obsolete operators in that patch, without removing any brush entries. We still need to decide how to handle brushes, but that should be part of the brush management project. Pablo pointed out that brush management and switching should not be part of the general keymap.
Pablo mentioned the technical documents he wrote last week about Multires limitations and mesh data representation design. He pointed out that before making any decisions regarding these topics, we should have a clear idea (both for sculpting and texture painting) of which techniques, workflows, and styles we want to focus on. After that, we can start making coherent technical decisions for updating the foundations of these modes for the following years. There will be further discussions about this as it is the main blocking topic for new development.
macOS: Embree and OpenImageDenoise are now available for ARM builds, based on work by Apple, Stefan and Brecht. SIMD optimizations to Blender and Cycles using sse2neon will be committed next.
Patrick asks about ARM optimizations for Linux. Brecht explains nearly all of the change are independent of the operating system, so getting all the same changes working there should be possible. make deps script will likely need some fixes to work on ARM Linux. In general patches to make these optimizations work on Linux are welcome.
Kévin is working on optimizations for transfer data from the CPU to the GPU (for OptiX), based on compressing data on the CPU and then decompressing it on the GPU. Kévin also works on prefetching support for the Alembic procedural, to prefetch a specified number of frames to balance memory usage / startup time and playback performance.
AMD Radeon Image Filter patch was updated. Brecht will review, code generally looks good but has not tested yet.
Stefan did a merge of the Blender repo into the standalone Cycles repo, Brecht will review. Some discussion about how to do branching and tagging. Suggestion is to have branches for LTS matching Blender branch names. master can be updated as it is now, once for every Blender release from the release branch. For version number we’ll switch to match Blender versions, to make the connection obvious.
Jeroen continues work on improving Crytpomatte workflow in compositor.
Since the Last Meeting / Announcements
Announcement: Sculpt, Paint & Texture module is going to make a generic attribute painting system. This will also impact weight painting, which will become official part of that module. Once generic attribute painting is implemented, the weight paint specific responsibilities can go to Animation & Rigging.
Sebastian: When did Topology Mirroring last work? He suggests to use UV maps for this, and mirror in UV space. This could be made multi-threaded & fast. Currently it uses a mapping structure from the whole mesh, which is failing (and has been for a while). This in light of T84520 , in his investigation he found lots of other things not working well. Still uncertain how much time he can spend on fixing these, though.
Weight Paint operators that use symmetry settings should expose this more clearly to users. For example in redo panel. T85789
On hold due to Sybren’s work on the Asset Browser / Pose Library. It is a part of the envisioned workflow with the Pose Library, though, as it should be possible to copy-paste poses between blend files.
Bassam: will the Asset system take external and non-blender libraries into account? Sybren: yes, in the sense that the currently envisioned design allows for this. Implementation will come later.
Sebastian: we should have is customizable, pick anything and it’ll mirror around that point. For bones the bone name stays relevant for mirroring, but bones should also be pickable as mirror center.
Bassam: you could 3D cursor or active object, depending on what’s chosen in the 3D Viewport as pivot option. Luciano told him earlier that he didn’t like that, but he’s not available to join the meeting today.
Demeter: Pablo Fournier also asked him for something like this.
Sebastian: could be a per-bone option, like “these bones mirror around that bone”, so becomes more addon-ish scripting than core feature.
Bassam: maybe Blender could expose some generic mirroring code that add-ons could use to simplify the implementation of custom mirroring add-ons?
Sebastian: yes, something like that is already on the radar, where the operator is given a transform it can use for mirroring.
Bassam: maybe not enough, as f.e. 8 selected bones actually could consist of two groups each with their own custom pivot point.
Side-discussion when talking about the pivot point:
Sybren: this touches on Active vs. Selected + using an unselected Active as pivot point. Sebastian: very fragile, as one mis-click changes the active selection.
Bassam: box-select is faster than click-select (heard from other animator, also confirmed by Jeremy and Sebastian), maybe box-select should also set the active bone?
Sebastian: box-select also selects everything, while click-selects has logic to toggle between overlapping elements. Might be two things combined, StarCraft style box-select being faster for users AND click-select being slower to respond in Blender.
Bassam: OpenGL Depth Picking was reported as influencing this a lot, but unknown in which direction.
Jeremy confirmed click-select is slow.
Demeter: How about alt-click to select from a list of overlapping bones, similar to overlapping objects? Demeter will create task for this, Sebastian can implement.
Christoph: discuss the idea of Time Selection. It could be interesting to try out in smaller context to see what works.
Jeremy Bot: bone pivot point should get in Blender. Mostly a matter of deciding where in the UI the option for pivot point position is placed.
Jeremy: Should not be option per bone, but global option. If you need it per bone, custom bone shapes are preferred then. All agree.
Bassam: The option to display axes is on the armature already, and wherever that option is, the slider could go next to that. With the current “Display Axes” option, this means that the pivot point becomes an option armature.