Is anyone else having trouble with stack nodes on modded parts?

[sumghai]

And you can still have a problem in Unity. Let me give an example where this can pop up, I should add that it might also shift back to the old axis. Suppose that you want to add a collider mesh to a another design. In this case you create a game object that contains two parallel created game objects. Unity will want to place the first mesh into the level 1 object, in this case you move the object to the second layer, and you might find the mesh reverts to the old rotation or old reference coordinates. Therefore if you are making complex parts in Unity you have to continually check to make sure the coordinates and orientation remain set properly.

By moving the object to the "second layer", I presume you mean making it as a child of the first object?

Of course you're going to get changes in object coordinates, since you're breaking the prefab's hierarchy. Avoid object hierarchy changes in Unity, and do that in Blender instead.

[PB666]

By moving the object to the "second layer", I presume you mean making it as a child of the first object?

Of course you're going to get changes in object coordinates, since you're breaking the prefab's hierarchy. Avoid object hierarchy changes in Unity, and do that in Blender instead.

For collider meshes, it is one of two recommended mechanisms to import a down-triangle version separately.

I can give an example of the problem.

Let us say you want to make a large concave part in which parts can move in and out and parts can attach on the inside, in this case you do not want a collision mesh that flattens over the concave area. The solution is to start the entire piece in blender, then break that entire work up into pieces that have minimal concavity. Only the center piece will have coordinates of 0,0,0. All the side pieces will have centers where zero is off the piece.

The intent of doing this is to break up pieces. Since the intent is to break them up having concave outcomes in Unity is pointless, since the intent is to circumvent the concave-less restrictions.

Next the zero coordinates of the side pieces need to be moved, easy enough in blender. And its best to move that point to its primary node stack point on the piece. So working from the first piece to the second piece one knows exactly were the secondary nodes are in blender for the center piece and the primary node for the side piece, then the exact origin is reset. This can be done by creating two parallel planes at the margin between the two intended objects with two overlapping points. One set of point has planes and the other lacks them, then use to plane select point to discriminate the two sets and in two file saves the parts can be separated.

So what happens when you send the side pieces to Unity. If you allow Unity to make the collision mesh (wasteful and potentially impossible) there is no problem. However if you decide to make a second collision mesh, then the tricky part is from the start you need to set up the Unity game object in the correct hierarchy, then second you need to make sure you drop both in the correct child-object that they not either be moved. Noting at this point the coordinates and the orientation are correct and as specified in blender with 90' rotation on the X axis. But if you should move either object to another point in the heirarchy, mysteriously Unity is able to cipher the original object coordinates and uses these instead.

Critical in this process also is that the 0.23 part tools need to be loaded into the highest tier, and set properly before the other child object are introduced.

[sumghai]

For collider meshes, it is one of two recommended mechanisms to import a down-triangle version separately.

I can give an example of the problem.

Let us say you want to make a large concave part in which parts can move in and out and parts can attach on the inside, in this case you do not want a collision mesh that flattens over the concave area. The solution is to start the entire piece in blender, then break that entire work up into pieces that have minimal concavity. Only the center piece will have coordinates of 0,0,0. All the side pieces will have centers where zero is off the piece.

The intent of doing this is to break up pieces. Since the intent is to break them up having concave outcomes in Unity is pointless, since the intent is to circumvent the concave-less restrictions.

Next the zero coordinates of the side pieces need to be moved, easy enough in blender. And its best to move that point to its primary node stack point on the piece. So working from the first piece to the second piece one knows exactly were the secondary nodes are in blender for the center piece and the primary node for the side piece, then the exact origin is reset. This can be done by creating two parallel planes at the margin between the two intended objects with two overlapping points. One set of point has planes and the other lacks them, then use to plane select point to discriminate the two sets and in two file saves the parts can be separated.

So what happens when you send the side pieces to Unity. If you allow Unity to make the collision mesh (wasteful and potentially impossible) there is no problem. However if you decide to make a second collision mesh, then the tricky part is from the start you need to set up the Unity game object in the correct hierarchy, then second you need to make sure you drop both in the correct child-object that they not either be moved. Noting at this point the coordinates and the orientation are correct and as specified in blender with 90' rotation on the X axis. But if you should move either object to another point in the heirarchy, mysteriously Unity is able to cipher the original object coordinates and uses these instead.

Critical in this process also is that the 0.23 part tools need to be loaded into the highest tier, and set properly before the other child object are introduced.

I sort of see what you mean, since I've made concave parts with multiple convex colliders myself (e.g. FusTek Station Parts tapered end ring).

In Blender, I would select the offset side colliders, and apply the current location/rotation/transformation - this causes the origin of the colliders to be reset to 0,0,0, but the collider meshes themselves remain at the desired positions.

(tl;dr - an object's origin can be outside or far away from the object mesh itself)