Basic snapping how to


#1

Feel a bit dumb asking this…

How do I snap a primitive cube to another primitive cube, edge to edge, corner to corner, without making them editable?


#2
  1. Put them in a grid cloner, adjust to taste, make editable, delete the ones you don’t want
  2. Turn on snapping to gridline and set the grid spacing and cube sizes up so that they’re harmonious; i.e your cube is 50cm3 and your gridlines are 50cm

#3

Create a null.
Snap that null to the vertex of the cube you want to move.
Drop the cube as a child of the null.
Snap the null to the other cube.
Unparent the original cube.

It shouldn’t really take 5 steps to snap one primitive to another - but it does.


#4

All good workarounds! The null solution is the one I went for. Thanks guys.


#5

By the way, the Cinema4D SDK samples have a nice tool called “Snap Move” which also works for parametric primitives. I always wondered why such a USEFUL tool would not make it into the main program, if all the code is there already…


#6

The thing that I would love to see are primitives with axis points at freely adjustable locations.

eg: i want a cube on the floor, and to stay on the floor when I increase its size. Wouldn’t it be handy to have the ability to specify the location of the axis - in this case at the bottom.


#7

That would be limited to certain predefined positions though, like a dropdown:

  • center of object
  • center of side (6 possible sides for a cube)
  • corner x (8 possible corners for a cube)
  • middle of edge (12 possible edges for a cube)

with different selections for each primitive (“corner” for a torus would be impractical).
Stuff like “I want my origin five centimeters off the 2nd side, and 1/5th downward to the 7th edge” would not be possible unless you want to introduce complex rules with symbolic positions.


#8

if ‘Snap move’ is in the SDK why couldn’t the parametric axis be developed to be snappable to any ‘vertex’?
If not, even the centre and extremities of the bounding box planes would be better than nothing.


#9

you mean, snappable to any vertex that the cube generator (!) creates? That would only be possible after the fact, and could not be used as option in the parameter list (because at the time when you write the parameters down, there are no vertices yet).
Let’s not forget that the parametrics are created from that parameter list, so the information where the origin of the object should be needs to be available first, then the points are created in this coordinate system. That’s possible as long as you can define the origin position beforehand - or rather, you can define where the points are created relative to the origin.

What you could do is to allow an arbitrary offset from the generational center, which can be changed after the generation itself. That would essentially be another transformation matrix, conceptionally similar to the “Frozen” coordinates. (The frozen coordinates don’t influence the generational center… but theoretically, the concept could be extended here.) But that’s practically the same as putting a Null above your object and using that to control the coordinate system (which then is the one of the Null).

In short, there is no reason why there should not be a different concept for primitives… although some create new difficulties and perhaps would make the understanding of the primitive more challenging.


#10

If the parametric objects are generating indexed points internally, it should be trivial to query their world positions, especially since world position info for the parametric object already exists.

Bounding box should be even more trivial, but here we are 23 releases later, and no way to snap a primitive effectively.


#11

If you know where the relative object center should be and how it’s oriented, then it is indeed trivial.

The most important question is “how does the user select this relative center and orientation”. Which is more a matter of taste and usecase.