Yaroslav

Will, thanks for your time on this issue.

one solution would be to make the snap-to function work on object that get their location changed by scaling of the parent object

I tried this myself as well and it seems more of a bug – theoretically, snap shouldn’t stop working if a geometry was modified. Fixing this would actually solve my whole case, as it would allow to move any object in accordance with the other object without making it a child of the latest.

For now, i was able to work around this for my specific isolated case with the following solution. For anyone reading this who doesn’t have experience with JS – please note this solution is not universal and works only for my specific case where the object we are snapping to:

– is not being dynamically rotated
– aligned to be resized on Z-axis

So what i did was making a simple function which gets a bounding box of my ring and finds the position of its surface after resize:

   v3dApp.ExternalInterface.snapObjectToBound = function(obj_name, obj_pos_name)
    {

      var Obj = v3dApp.scene.getObjectByName(obj_name);
      var ObjPosition = v3dApp.scene.getObjectByName(obj_pos_name);

      var BoundBox = new v3d.Box3().setFromObject(ObjPosition);
      var BoundDepth = BoundBox.getSize().z;

      var Pos = ObjPosition.position;

      Obj.position.z = BoundDepth/2;
    }

Then, when a resize callback happens, all i have to do is to call snapObjectToBound with my gem as an object to get bounded and ring as a bounding target to make it fit:

My resume for this case is: while being able to solving it with JS, snapping objects to pre-defined vertexes of another object (defined with either an Empty or with a Vertex Group, whatever works for developers best) is a vital function which should not be broken after modifying an object (at least with built-in Puzzle modifiers). All in all, fixing the behavior Will mentioned in his previous post seems important.