RFC: Copy Groups

[phkahler]

I have a preliminary implementation of copy groups. You can try it out on my "copy-groups" branch here: https://github.com/phkahler/solvespace.git

If this is of interest, I'd like some clarification on how it should work.

First, I used SHIFT-C instead of CTRL-C. I would prefer to use control, just wondering if there are any concerns about that. AFAICT That key combo currently does nothing for 3d groups.

Shift-C immediately makes a copy of the current group. Should CTRL-C do the same? I'd also like CTRL-V to add another copy within the same "copy" group to avoid having one new group for each copy.

If you've ever took the time to make a screw hole with a countersink you know how bad you wanted to just press a key to make a copy of that feature. This does that! These groups also have 6 degrees of freedom, so be careful. They don't seem to rotate easily unless you pin some point down.

I'm also thinking they should have a user adjustable scale other than 1.0.

Comments, thoughts, suggestions?

[whitequark]

I don't think adding general copy groups is a good idea at the moment. The reason for that is group ordering. Internally, groups are hierarchical, but they're linearized for display in the group list, which can have very confusing results.

Adding mirror groups, as a more restricted version, at least avoids making the problem worse than it is now.

I'm also not sure if every new feature we introduce should immediately gain a key binding. We'll just run out of keys.

[whitequark]

(If the explanation above doesn't make a lot of sense to you, let me know and I'll try to go into more detail, but that'll happen later as I haven't been feeling well the last week.)

[phkahler]

@whitequark I understood, and I mostly agree. I just wanted to see if anyone else jumped in.

Key bindings are a limited resource. Also, trying to mimic copy/paste will probably never really work, it's not the same thing and would be confusing.

My replicating holes example is not that great either, you can already copy a complex hole with step translating. It's not as flexible as having each copy with it's own position and orientation but it helps to remember what's already possible.

Yesterday I was able to turn a single copy into a mirror copy just by internally adding the appropriate constrains and scale (-1). It is allowed to move the same way as my previous mirror implementation with much less invasive implementation. Problem is dragging is nowhere near as nice.

All of my new toys are going to take quite a while to figure out the "right" implementation. That's why I post partial stuff - for feedback. Thanks!

[whitequark]

All of my new toys are going to take quite a while to figure out the "right" implementation. That's why I post partial stuff - for feedback. Thanks!

Great, we're on the same page then! It may not always look like it but I'm really happy to see you making progress on many of the oldest issues, even if I think the result can't be shipped right away.

Yesterday I was able to turn a single copy into a mirror copy just by internally adding the appropriate constrains and scale (-1).

"Mirror copy" feature is long awaited & really needed.

[phkahler]

This is also similar to #223 but in 3D.

[ruevs]

...group ordering. Internally, groups are hierarchical, but they're linearized for display in the group list, which can have very confusing results.

Indeed #120

[gwhitney]

I see this is rather old, but I wanted to chime in that I would very much like a feature like this. I often want to create 3D configurations that consist of multiple copies of the same repeating geometry, but in which each copy is free to rotate/translate in 3D independently of the others (at least until I constrain some of its points further). So it seems as though "Copy Group" is exactly what I need, unless there is some better way to obtain what I just described with Solvespace as it stands? I am currently using SolveSpace 3.1 via snap, but I will try compiling from source and then seeing if I can get phkahler's copy groups branch to work for me (I wasn't currently able to find any way to make a copy of one group that was free to position with respect to the first, but maybe it is just because I am inexperienced with SolveSpace?).

[ruevs]

The currently implemented method to have multiple freely moveable copies of the same object is to draw it alone and save it in a separate file and then "link/assemble" it multiple times in the file you are working on.

[gwhitney]

Thanks for the pointer, I really appreciate it. (Rebasing the referenced branch on master and compiling was easy, fyi, but then the result didn't work too well: the first constraint I set linking two copies worked fine, but the second constraint said it was unsatisfiable, when to a person looking at the constraints from the point of view of their geometric knowledge, it certainly was satisfiable.) Will try the link/assemble method and see if that works better.

[gwhitney]

Ah, I think I still end up running into the concerns described in https://solvespace.com/forum.pl?action=viewthread&parent=1238&tt=1638401711 even with link/assembly. (I am actually doing something quite similar in concept, although with different shapes than planar pentagons and hexagons.) Would be nice to be able to solve an assembly in which three copies have to jointly move to satisfy the constraints, but it seems that's not possible at the moment? Unless there's a way to merge the groups from two Link/Assembly imports? (Seems doubtful.)