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.

(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.)

@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!

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.

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

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

Indeed #120

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?).

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.

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.

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.)

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?

No. Solving can modify constraints in the current group, but not in previous groups. So (as in the forum example you linked) if three flat polygons in three different groups have to move to meet at a vertex only the one from the las/current group will be able to move and solving will fail. A very minimal demonstration of this problem/feature :-) is this:

• In sketch 1 create a single unconstrained point.
• In sketch 2 create a second fixed point (for example by setting the X and Y distances from the X and Y axes)
• Try to constrain the two points coincident. It should fail.

Unless there's a way to merge the groups from two Link/Assembly imports? (Seems doubtful.)

No. So the only solution I can currently think of (using linking) is to draw some "construction" lines (can be in 3D) in the "second" group ("representing" the third group) that allow you to constrain it in the required position. After that the third group should constrain fine.

As an example it will require some careful planning to assemble a dodecahedron from 12 linked copies of a pentagon. But it can be done - e.g. the first few groups can strategically rotate a line segment to form a scaffolding onto which the polygons can be attached.

But for a non uniform object this would be really tedious and annoying.