3d Locus does not Rotate about a point?

[Benson Shaw]

Another rotation hurdle. The Rotate Node works for many types of objects, but not for a 3d locus?

Or is there a method to rotate a 3d locus via the rotate node?

 

Circle created and rotated

 

 

Locus created, but did not rotate.

 

 

 

Here is my workaround using essentially create location via sin and cos 

 

-B

 

[Pat Stanford]

The Vectorscript/Python function the node is using does not work on Loci. Design Decision made many moons ago in the MiniCad days.

 

It does work on Groups. So you could check to see if the object is a Loci, if so, group it, Rotate, Ungroup.

[Benson Shaw]

@Pat Stanford - Ja. Good idea! Thanks!

 

I wonder about that MiniCad design decision idea. The workspace tools and commands seem to work as expected with 3d Loci.

 

Not to take away from Pat's tip, but this seems a workaround. How would Marionette users (especially inexperienced ones) know to do that conversion.  Is that perhaps addressed somewhere in those multiple hours of intro videos?

 

 

Thanks again, Pat

-B

[Pat Stanford]

If you select the Rotate 3D node and then click the Description button in the OIP, it tells you exactly what types of objects the node works on.  I just wanted to know why, so I looked at the script. Turns out it used the Set3DRot vector script function (that has been around since Minicad). And the Vectorscript Function Reference has the same list of the types of objects it works on.

 

Programming (even using Marionette) is always an issue of understanding the limitations of what the code can do.

[Benson Shaw]

@Pat StanfordThanks for looking and commentary.  Those such as yourself with loads of experience in the underlying VS might find and understand the limitations.  I look at the Rotation node description and see nothing that indicates a 2d or 3d locus would not be an acceptable object for action by the node.

Maybe there is some mathematical or VS argument that a 3d locus is NOT an object? (A locus is only a location? One is not a prime number? String theory and multiple universes are . . . um . . . something?)

 

 

I am not versed in VS. That Set3dRotation line in the node script is not informative for me. (not your fault!)

 

@Marissa Farrell is kindly reviewing some of these older nodes to update descriptions, scripts, user friendliness, etc.  This presents hope for me and other occasional Marionette dabblers that I will have easier rout to success in future!  I think Marionette is really cool and full of potential, but only implement it occasionally. And usually run into roadblocks. To the forum I go! Thanks all!

 

-B

[Pat Stanford]

I was talking about the description for the Rotate 3D node.

 

 

Under the hood, the Rotate node uses the same Vectorscript function for non-planar objects as the Rotate 3D node, therefore the exclusion of loci.

[Benson Shaw]

Doh! Rotate 3d! Either way got it to work with the Group idea.  Thx again

 

-B

[Antonio Landsberger]

"Angles are in Radians" has already been reported (https://jira.vectorworks.net/browse/VB-169146) a while (almost 5 years) ago.

[Benson Shaw]

Also not clear why 3d loci are not on list of "acceptable" objects.  Loci from 3d tool set respond as expected to the Rotate 3d command in the Modify menu.  If I understand properly, the  Rotate 3d command somehow incorporates that same Set3dRotation script?   Something about a locus seems counter to the script.  Or maybe script could be modified to include the 3d loci?  Meanwhile, group it! And, I'm off to slider questions

 

-B

[Antonio Landsberger]

Benson,

In general when it comes to scripting and objects in Vectorworks, I would advice everyone to first do all computations mathematically and then move or create objects in the drawing pane. With 2D and 3D loci I would simply set new coordinates (after the calculation) using the Move node.

[Pat Stanford]

No real information, but likely that the original thought was that loci are used as "layout locations" and therefore should not respond to menu commands to move them. At that time loci were used for things like the center  of a sweep and the center point of a mirror.

 

And once things get set in a programming language, they are hard to change. Change it to do what you want and how many other scripts that depended on the old functionality will be unknowingly broken.

 

You know it is not working, so do what you have to to make your script work as you want.

[Benson Shaw]

@Antonio Landsberger Thanks. That's basically what I am doing to move things forward, along with asking for others' help.  I'm not at all a scriptor/pythonista. Often my knowledge of trig and other maths can be applied to networks of existing nodes. With that, I'm often wishing some of the nodes behave more closely to the drawing space tools and commands.

 

@Pat Stanford 

On 6/11/2025 at 8:20 AM, Pat Stanford said:

the old functionality will be unknowingly broken

Absolutely. See also comments above by @Marissa Farrell regarding node updates and breaking networks.  My preferred solution would be to issue a brand new node with better functionality but with a new name, v2 suffix or the like.  This way the old node is available for replicating structure and function of older networks.  Witness the Enhanced Rectangle node by @DomC.

 

And, yes. Take an alternate path when network not working. A stop at the forum might help determine whether the problem is pilot error or node problem.  It was wild to see @Letti R cook up 3 alternate networks for rotation. I have since created another couple.

 

-B

[Marissa Farrell]

14 hours ago, Benson Shaw said:

 This way the old node is available for replicating structure and function of older networks.

Most of the time when I change how a node works, I add an option in the OIP so users can still use the old behavior if they want. That way, we don’t need to keep around legacy nodes, but we still preserve the legacy behavior. I think it’s important to cut down on node clutter so users aren’t stuck asking, “Do I use this node or that one?” Instead, they can just choose how they want it to behave. For example, the original move node only supported moving an object relative to its current position. When I updated it in 2018, I added an option in the OIP to move to an absolute location, rather than making a separate node.
 

Right now, I’m working on combining nodes that only work on 2D or 3D objects into one that supports both. Depending on whether the input object is 2D or 3D, it’ll use the appropriate functions. But in cases where a user might want to move something only in 2D even if they’re using a 3D vector, I’m adding options to force a 2D or 3D move, or let it auto-detect based on the input. The new default will be to let it decide automatically, but users can override that if needed.
 

Another update I’m making is to the Get Vertex node. Instead of having different versions for 2D polys, 3D polys, and Meshes, it’ll now support all of them in a single node. This way, you can pass in a list that includes four 3D polys, a mesh, and then another poly, and it’ll still give you the correct vertex or point for each one. If you don’t specify an index, it’ll return all of the vertices for each object at once as a list of lists. This should help keep networks cleaner, since you won’t need to split out different branches just to support different object types.
 

I’m hoping this will make Marionette feel more intuitive and less overwhelming to dig through. I’m also reorganizing things based on what the node does rather than what kind of object it works on, which is how the current library is structured. The goal is to help users understand that they’re not limited to different nodes just because they’re working with different object types. Ideally, any node that performs an operation on an object should work on all relevant object types.
 

For example, I’ll make sure the rotate nodes handle loci properly without needing any kind of workaround. And please keep pointing out when you think a node should support something it currently doesn’t - this is a big library, and I often don’t catch missing functionality unless someone flags it.


EDITING TO ADD!!!

I’m also working on some “under-the-hood” handling for when a node expects a certain type of input but gets something else. For example, we’ve talked about cases where a node wants a vector input, but a user might naturally provide a scalar angle instead. In those situations, I want the node to be smart enough to figure out what you meant and respond appropriately, whether it’s a vector or an angle.
 

I’m adding this in quietly for now - no big announcements - but as nodes become more flexible, I will update the port descriptions to reflect that they accept multiple types, even if the prefix is still there. The idea is to eventually drop the prefixes altogether once it’s been tested enough, but I want to make the transition as smooth as possible. The goal is to make nodes feel smarter without surprising anyone.