Driver Usability Features to improve parametric design workflow

[ecosky]

While CAD Sketcher already had support for using Blender drivers to
centralize the data used to specify values on constraints, it can be
cumbersome when there are lots of data to manage. The previous workflow
involved finding a property somewhere, context menu on it to
Copy as New Driver, then going back to the constraint and pasting it.
Since the data are typically stored in custom properties, this also
means relying on Blender's custom property interfaces which don't offer
many organizational features.

This PR aims to improve some of these issues with the following:

• Added buttons to the constraint panel that displays a context menu
  which allow the user to select a suitable constraint target from a user
  defined set of objects.
• Added a new panel that allows the user to select any number of
  objects for use by the new driver selection context menu.

When the driver selection menu appears, it will sort all the candidates
alphabetically and for each one, list all the int and float custom
properties that are suitable for use as drivers. Choosing one will
cause any existing driver to be destroyed, and creates a new one using
the selected property.

These features make selecting sources for constraints very efficient
because each sketch can specify which set of source objects to pull data from,
which provides the option to organize dimensional data many useful ways.

I have done only a small amount of testing and while it seems to be
working for me, it may not work for you.

Possible future enhancements include:

• A global list of driver sources that are shared with all sketches.
• An option to "add" the driver to the existing driver, to facilitate
  the creation of expressions that use data from multiple driver sources
• Copy/Paste driver sources between sketches
• Informative tooltips
• Drag & drop the list of driver sources for organizational purposes

I have done only a small amount of testing and while it seems to be
working for me, it may not work for you.

I don't do PRs very often so I'm not sure how exactly to manage the extra file and change I made to the README.md as part of a pull, I am assuming those two commits shouldn't be included but I haven't yet figured out how to submit a PR for just the one feature commit.

[ecosky]

Couple screenshots:

[hlorus]

Hey there, thanks alot for the high quality PR! This looks like a great improvement in general, the main concern is that it seems a bit too complicated. Why is there the concept of sourceobjects, can't we just have a global place to store properties? Especially with the current limitation of per-sketch sources only this results in alot of extra steps needed. Also i'd like to avoid having dummy objects in the scene.

We could add an empty PropertyGroup to the sketcher_group to store properties, something like "context.scene.sketcher.custom_properties". The downside here is that we'd likely have to provide an UI to create and edit properties there.

[ecosky]

Hey there thanks for checking it out. I'm trying to migrate from FreeCAD to Blender, and the underlying motivation for this PR is to make the job of switching from expressions(FreeCad) to drivers(Blender) as easy as possible. As I started to migrate a project over manually, I found the process of creating and using all the drivers so slow and error prone that I felt it necessary to streamline the process.

Re: The use of per-sketch sources
I am a casual CAD user, however my most recent experiments with FreeCAD to make a relatively simple object had about 70 expressions for different types of features, some of them relevant to all but some only relevant to specific parts of the model.

I didn't like the notion of having a menu with 70 items in there visible to every sketch, even if there was a tree that had them all or something like that. I mainly wanted to have some way to organize them so that selecting the one I needed would be as efficient as possible. For instance, the sketch that might only need to reference the dimensions of the fasteners I'm using doesn't really need to know about the dozens (or hundreds) of other expressions I might be using across the entire model. I can't imagine how many hundreds of parameters a detailed model might want to use.

Re: sources visible to all sketches
I agree that from a usability standpoint there should be a central set of objects whose attributes are accessible to all sketches. I almost added that, and calling it "global sources" or "shared sources", but I was running out of time and wanted to wrap it up at least for the time I had last weekend. Also, I wasn't sure where to put this list but it sounds like context.scene.sketcher.custom_properties would be a good place to store a list of shared sources. This would be a trivial improvement, I can add that sometime. I can imagine some people won't even want to use sketch-specific sources if that were available. I'll still use them however :)

Re: dummy objects in the scene
In my example, I used empties just to illustrate how to use them. I expect the actual sources for real projects will be associated with the main model being built, or other objects within it's hierarchy or elsewhere in the scene. I didn't want to impose a structure there. I do value the convenience of being able to just select them in the outliner, and in the drop down in the list of sources. Speed and usability is my goal for this feature. I suppose it would be possible to make a custom layout that has a list of objects whose sole purpose is to hold properties, but it seemed that the existing system for custom properties on objects was a great fit.

[hlorus]

IMO this is a rather specific workflow, usually not every constraint is driven by a property. While it's ok to improve things for that case we shouldn't optimize things for one specific usecase. Why exactly do you need such an extensive amount of drivers?

IMO the driver sources menu seems a bit overkill as you can choose what source+object from the native "Add Driver" menu.

I generally like the driver menu but would say it should mainly streamline the following actions:

• Add the value of an existing constraint to the driver or create driver implicitly
• Add a new custom property in a global place
• Add one of the previously added custom properties

What's your opinion on the topic @TheMakerTales ?

[ecosky]

Lots of drivers are because I'm a fan of parametric modelling, where many things are driven by variables.
Perhaps the driver sources menu should be an option that people who want the extra organizational feature could enable?

Not sure exactly what you mean by "add the value of an existing constraint or create driver implicitly" - can you elaborate? Maybe I overlooked a simpler way to do this.

The last two points, are you saying, add a panel with custom properties just for this, and have the driver menu choose from them?

[ecosky]

Added a global driver list and stored them in sketcher properties as suggested.
Made a short video to demonstrate, check it out here:
https://youtu.be/HDxBm8dC7eU

[ecosky]

I just realized what you were describing. The driver sources list could be a list much like the custom property list on objects in the scene, avoiding the necessity to link to objects in the scene. This might not be too much trouble, and I'll look into it.

[hlorus]

I just realized what you were describing. The driver sources list could be a list much like the custom property list on objects in the scene, avoiding the necessity to link to objects in the scene. This might not be too much trouble, and I'll look into it.

Yeah, i'd prefer to remove the "setup" step where you first have to define a source object. Also the additional utility panels like the "driver sources" panel.
I would rather just place all available properties in the driver menu, maybe with sub-menus or filtering.

[hlorus]

Not sure exactly what you mean by "add the value of an existing constraint or create driver implicitly" - can you elaborate? Maybe I overlooked a simpler way to do this.

A constraint can be driven by another constraint. IMO this is the most important use-case and we should streamline creating such driver setups. Therefore i'd say the driver menu should mainly show a list of all dimensional constraints. Maybe we can add sub-menus.

[ecosky]

I looked into what it would take to make the driver sources panel provide a list of properties similar to the custom properties of objects in the scene, and it soon started looking like it would require replicating the custom property panel of objects in the scene. It's not clear to me what doing it this way would require yet, either. I appreciate what you are talking about with respect to minimizing setup and trying to contain everything within the sketch, but the way I see it the sketch is just one of several important parts of the workflow I'm trying to improve. Essentially, the variables going into the sketch are also likely to be referenced by geometry node trees and I want a centralized, neutral home for them that is easy to navigate to, possibly in a top level panel or something like that, from which both the sketch and geometry nodes can easily reference them. There will always be some kind of setting up of the variables in the first place, they do have to live somewhere. Perhaps it would make sense to have Sketcher know how to discover the global ones. I am pretty keen on the sketch-local sources though, and I don't know how that would work without adding this data to sketches in some way.

Related to the desire to have driver sources external to the sketch, I've also added functionality to the geometry node editor to let me paste constants preconfigured with whatever driver is in the buffer, as shown here: https://youtu.be/hk_baeS4Evc I did this in anticipation of wanting to quickly pull drivers out of a shared space and into the node editor. I might do a similar sort of driver menu somewhere along the way, maybe a sub menu of the existing add menu. That's a ways off though, and not really connected to this PR other than I'm trying to do something that will all eventually work together in a somewhat similar manner.

I've been looking into making improvements to Blender's built in custom property editor, because this almost does what I want, however I will probably experiment with some other usability improvements I have in mind.

It would be nice to split out the dimensional constraints from the rest, I find myself only caring about one class of those at a time and that one panel gets big & a little unwieldy pretty fast right now. Sort of related, some of the panels feel like they could use a bit of packing, like the one line per tool could be one row of icons that have tooltips, that sort of thing. I only mention it because I can imagine the UI feels pretty big and I appreciate wanting to not let it get even bigger unless there's a good reason. I did what I could to minimize the footprint but I can see why you'd prefer it to be even tighter.

I think for now I need to pause and think about how the other things I want to do fit into your feedback.

[kesselborn]

Was just reading up on this. I really like the idea of making drivers more usable, though I think that my Blender sometimes suddenly get's super slow when I use too many drivers (different topic though).
Out of interest: will this be PR be merged or still refined?