Marissa Farrell

In my earlier investigations (November-ish?) I noticed that the OpenGL calls are outdated. I've already pushed it through in-house. Hopefully something can be resolved soon, as for now, I don't think a function exists that uses the actual OpenGL prefs that we have, I was told the current command on the dev wiki is only relevant for the older engine we used before we upgraded (years ago.. funny how some things slip by )

Just to put this out here - this has been one of my favorite demonstrations of a use case for Marionette so far. Very fun!

@jppp, Alan's suggestion is similar to what I would have suggested, but if you don't think symbols would work out for you, I can help to come up with another solution. Let me know!

The simplest way I can put it is that when Python was introduced to Vectorworks, we duplicated the existing Vectorscript calls into a Python module called vs. All of the vs.FUNCTIONNAME() calls are still Python, but they're directly related to the Vectorscript function library (which is Pascal based). You can think of this kind of like translating code to a different language, and in this case we need these functions because they're linked specifically to the back end of VW. Both Vectorscript and Python calls from the vs module will do the same thing. You can still do pretty much anything you could do with Python within Marionette, the vs calls are really only important for manipulating VW data and creating/editing objects. Any math or calculations or external data saving can be done with vanilla Python just as you would if you were using standalone Python. I'm hoping to find the time to show some examples, but I'm not sure when that will be. Please let me know if you need more clarification.

So basically what happens when you use the "Divide Curve" node is that it creates one long list of all of the points on all of the curves that went into it. I modified that node to chunk them into lists. I also modified the node immediately after it, "Every Other", to not absorb the entire list and flatten it, so it, too, outputs the right values. I commented the lines in each of those nodes that I changed, there is only one line in each. This revision will take a little longer to calculate and finish, but it gives you what you want. I can say that we are working on improvements for future releases to use different methods when working with large data, so keep your eyes open for my post when we get to the point that we can put it out there! Let me know if you have any questions.

I think it's because when you do the "Every Other" on your output from "Divide Curve", sometimes the "Odd" value will be the beginning of the next line. Let me think of the best way to remedy this.

Most Vectorscript calls can be found at the Developer Wiki, although some may be slightly outdated, and others may not be hosted yet. They're fairly well categorized. Hope this helps!

I think I'm just still a little bit lost here. Can you provide a visual of what it's supposed to look like, since it sounds like what's in the image shared above is not what you're looking for exactly? What is the "right position"? I'm up for the challenge.

Attached is a Marionette Object of a threaded bolt, still in progress. Current "NumThreads" must be >0 and <=10, or you will get a failure. This will be fixed (and later removed and replaced with overall length). Fractional values should work. There is much more ahead on this, but I figured sharing now and allowing the community to play with it/improve on it could be beneficial. I will update the variables as I go to follow standard dimensioning of threaded objects, I just haven't gotten around to the math in some areas (such as major diameter, etc.) It will also later include a head, since that's obviously not there

I feel like in most cases, users aren't permitted to see the programming behind PIOs, this allows the creator to keep the complexity of the object hidden from the user (so they can't reproduce it and share it with others who don't have it by default). I've found that taking an object and creating a few viewports (say top, front, and right views) and dimensioning them helps to establish the relationships between different pieces. Then you can take those dimensions and decide which ones you'd want the user to be able to change, and after that you can begin defining it on a script level, either by using Marionette or just a Python script. Also, many plug ins within VectorWorks have been written using the SDK rather than VectorScript/python, and some functions haven't been properly brought into the VectorScript API, which is also a limiting factor in some cases. We're working to identify functions that would be useful in the VectorScript API, that aren't already there, and hope to include them in the future. In any case, I hope to produce a video series in the near future on some practices for programming object creation in 3 dimensions/thinking in 3D space. My primary tool will likely be Marionette, but I think I may dive into some Python scripting as well.

Alan, I believe you're aware of the Developer Wiki, which contains our VectorScript API and is often a good place to start looking for the functions you may need. Another way you could do this, if you have a Marionette network that you'd like to consolidate into a singular node, it's pretty easy to just grab the pieces of the code within the nodes that you'd need. I've gotten into the habit of first writing what I want using the standard Marionette node set, and then I dissect the nodes to find the code snippets required to consolidate it. There are still functions on the wiki that we haven't introduced to Marionette, though, but most functions have an example posted on how to use them on the wiki, which could also be of use. Also, since we use Python 3.3 as the coding basis of Marionette, it may also help to familiarize yourself with some standard Python practices. I've always found this to be a useful resource. You can likely skip to Chapter 3, since within Vectorworks it's not really necessary to use an interpreter. (If you'd like to use one for a better understanding of Python overall, that's also fine.) I actually had never even touched Python before using Marionette, so Marionette has essentially been my Python teacher Please let me know if you get stuck or need guidance!

Attached is a wrapper for a rectangular array. Note: If you input a 2D object, currently all repeats in the Z direction will stack on top of each other at the same Z height, 3D objects will move as expected. I'm working on resolving this. I will also be writing this as a standalone node.

V2 will rotate the duplicated objects to uniformly face the center.

In the attached file is a wrapper that creates a uniform circular array based on inputs of object, center, and number of duplicates. I will later create this as a standalone node.

A parametric button - again, simple. Please let me know if you run into any issues while changing parameters in 3D - there's an inconsistency I'm trying to track down. Not shown in image - you can choose the number of holes to thread through.

What about using the Text Along Path command with a straight line as the path? You can ungroup the resulting Text Along Path object to just use the surfaces.

I've recently purchased a 3D printer (I'll share more details with anyone who asks ) and decided that it would be fun and gratifying to begin modeling objects using Marionette with the intention of printing them. My first share is this parametric door hook. Although simple, it was a great drawing project (I actually took much longer on this than I thought I originally would...). Once I get around to printing one (or four) out, I'll happily share the results! If there are any questions on the best practices for using Marionette to model for 3D printing, I would love to be a resource for you. I'd also love suggestions as to what other objects might be fun to model for print!

The solid subtraction would also have been my suggestion. (Other than Marionette, but that would be slightly more time consuming )

I'm having a hard time understanding what you're hoping to do/where you're running into an issue. First off, I don't see a "Control Geometry" node in your network. In most cases, this is what you want to use if you're planning to use control geometry (although it is acceptable to continue using the "Name" nodes, it's just important to understand that they won't work the same way that control geometry does) Where are you placing your soft goods objects? When you wrap your network, are you placing them into the control geometry of the Marionette Object? (Side note: We currently only have support for a single piece of control geometry, although there may be ways around this, so placing two soft goods objects into the control geometry will likely not behave as you would expect) Can you give me a better explanation if what you're hoping to accomplish? I'm more than happy to help.

Kevin & bc, Out of curiosity, what layer scale are you using when you see this?

Hi Chad, Currently I'm not aware of anything that is foolproof to get this to work. I'm not even really sure what determines the order in the first place. I'll add it to our list of areas to improve on! Marissa

If you want to send it, I'd definitely love to see it! Hopefully I'll be able to help you troubleshoot and find a solution. You can email it to me at ---, and I'll take a look first chance I have

No problem! The reason you're still able to call objects by name is because that node will look through your entire document drawing area for objects that are of the same name. I'm actually surprised that groups aren't being recognized, to be honest. So regardless of you putting those objects in Control Geometry, leaving them on your Design Layer, or even copy-pasting them into your wrapped script, they should be located by the Name node. I'll try to do some further investigating as to why groups aren't being manipulated, since I really think they should have worked just as they would have in your unwrapped script.

Ruud, At a first glance, I don't believe you're using Control Geometry properly. Control geometry is defined with the "Control Geometry" node in the Input category. This node will look for objects in your defined control geometry (where you put your group and rectangle objects) At this time, there is no simple support for multiple control geometry objects.

Also, part of me believes that what Alan found actually solves the issue for using a 2D symbol profile on its own. I'll do some further testing.