Page MenuHome

Select new active element using box/circle/lasso select [WIP]
AbandonedPublic

Authored by Jacques Lucke (JacquesLucke) on Jan 16 2019, 5:57 PM.

Details

Reviewers
None
Group Reviewers
User Interface
Summary

Based on the discussion in https://developer.blender.org/T60557#601013

There are still quite few things missing here, but maybe someone wants to test if it actually makes sense.

Also performance wise some things could be much better.
E.g. in theory it is not necessary to store all the changed elements, however I'd like to keep the new-active-decision out of the selection code.

@Brecht Van Lommel (brecht), can I make a new generic ArrayBase that is similar to ListBase but more efficient in many cases.
It would just be an array that doubles in size when it is full.

Diff Detail

Repository
rB Blender
Branch
select_active (branched from master)
Build Status
Buildable 2746
Build 2746: arc lint + arc unit

Event Timeline

@Brecht Van Lommel (brecht) Van Lommel (brecht), can I make a new generic ArrayBase that is similar to ListBase but more efficient in many cases.
It would just be an array that doubles in size when it is full.

BLI_array seems to have functions for this, see BLI_array_grow.

I'm not sure about all the consequences of this, would need to be carefully checked if it breaks any important use cases.

There are many selection tools, some part of Blender C, some in Python or addons, so all those also need to work with the new behavior too.

I fear this might be a rabbit hole that is deeper than we want to go down right now.

Would rather not change active for circle/box/lasso selection, unless there is a really compelling use case.

The selection order was meant for explicit selections, where as circle select is more like lasso/box select than picking.

  • For larger brushes order will be random from user POV.
  • Having a random order will seem erratic (for faces especially), where the material and image in the UV editor will always follow the active face which may have a different material after each stroke (flickering the interface).
  • It adds a performance overhead (maintaining this data will slow down some future operations which maintain selection history while editing).
  • It adds the user expectations that this behavior will apply to other areas too (object, armature, lattice, nodes, sequence strips ... etc).

Edit: after reading T60557#601002,
This is jarring for the same reasons changing active object is jarring, it's just less obvious that this applies to geometry too since it's mainly an issue with faces, less so for vertices (although active vertex is used in the interface for adjusting weights).

I see, will not continue to work in this for now.

@Brecht Van Lommel (brecht), As for the array data structure, BLI_array.h seems to be overly complicated and fragile. Having an actual ArrayBase struct is more helpful because that would make it possible to pass a pointer it around.
Also this structure could be used to simplify code in many existing areas of Blender. There are A LOT of new places where an array of objects (Object **) is used. Currently the array and length are always passed along separately. Joining them in one struct also makes many function signatures simpler because no return parameter is necessary.

@Jacques Lucke (JacquesLucke), I guess you would want to preserve type safety though, probably defining an ObjectArray and similar for all types you want to pass along like that. It might be a good idea, @Campbell Barton (campbellbarton) is effectively the maintainer of these kinds of data structures so would be good to hear his opinion.

@Jacques Lucke (JacquesLucke), I guess you would want to preserve type safety though, probably defining an ObjectArray and similar for all types you want to pass along like that. It might be a good idea, @Campbell Barton (campbellbarton) is effectively the maintainer of these kinds of data structures so would be good to hear his opinion.

Yes, unfortunately C makes it fairly hard to make dynamic data structures type safe. The same problem exists for ListBase and for most other structures as well.
Maybe a not-type-safe ArrayBase can be defined, and then we use wrapper functions/macros to get some basic type safety when using the structure.

@Jacques Lucke (JacquesLucke) agree BLI_array.h isn't great, was added as part of BMesh, but we don't have good replacements for it in some cases. The ability to switch between stack and heap allocations as a fallback is useful too (BLI_array_staticdeclare).

Some API's in this area:

  • BLI_buffer.h is a generic array but suffers not being typed.
  • BLI_stack can be used when accumulating.
  • BLI_memiter / BLI_mempool - uses chunks of memory.
  • BLI_utildefines_stack.h utilities to avoid basic mistakes when using array as a stack (bounds checked, some useful asserts).

As for having a generic vector type that avoids passing along multiple args, would be interesting to try but think this may be tricky to do in C without nasty tradeoffs.

It'd be interesting to try adding ArrayBase we could have debug-mode typechecking.

An alternative could be to have a header w/o a guard that uses a macro to declare: ArrayBase_ ## type

See list_sort_impl.h (although this should be done with fewer defines). And we'd want to avoid re-declaring new functions in every case (types that cast to void ** can share utility functions). Would need to try this to see if it can be done in an acceptable way.

Best move this discussion to a design task if you plan to look into this.

Best move this discussion to a design task if you plan to look into this.

Discussion can continue here: D4225