Marissa Farrell

Correct. Good point. I'll see if I can add more logic to this node, I didn't write it originally, but I'll see if there's a way to ignore points that are already on an existing edge and try to modify it. I didn't even think of that! So big thanks for bringing that situation to my attention!

Let's try this one!

Oh how weird. Something is going wrong with the AddSolid command. it actually doesn't add them... If you take that line out and replace the self.Params.shell.value with "Shell1" and run it, you'll see that it was fixed there... but when you add the resulting solids together half gets deleted... Sorry! I'll keep poking.

So Get Center works with 3D polys and takes the points at each index in order to get the average value of x, y, and z for each point on the poly. So say you had a 3D poly with 4 points - (0,0,0), (3,0,0), (3,3,3), and (0,3,3). The Get Center will average all of the x, y, and z values to create the averaged point, i.e. x = (0 + 3 + 3 + 0) / 4 = 6/4 y = (0 + 0 + 3 + 3) / 4 = 6/4 z = (0 + 3 + 3 + 0) / 4 = 6/4 (This example is super simplistic and produces boring results...) With more complex polys, it's possible that the point won't be on a planar piece of the poly at all, since it's just averaging the points. You can kind of think of it as finding where the gravitational center of the poly would be? If that makes any sense?

Yes, I did this with Marionette. I'm still trying to figure out the best way to help you with your frame challenge! The biggest problem right now, in my opinion, is that dimensions are returned as strings when you get the record information, so I'm trying to get around to writing a node that will convert those strings to proper dimensions. Once I get that figured out, I think many things will be MUCH easier

Okay. So as a workaround, it now shells in each direction by half of the distance. This is an inadequate final fix, I'll probably throw in an OIP control to let you decide in which direction the shelling takes place, but at least for now, it makes this uniform. (Figure if someone's shelling a bowl shape or something of the sort, you wouldn't want to shell in both directions, but maybe offering the choice would be a positive improvement?)

Oooooh this is very irritating. So, this is happening because the function used in the shell node takes the normal of the NURBS object that it's going to shell.. I'm not sure why, but it appears that when a NURBS curve is converted to a NURBS surface, it doesn't reliably have the normal in the same direction. I'll see if I can figure out a way to at least get them all to shell in the same direction.

I can answer your first two questions quickly, and I'll get to the third one later today after I wake up a bit more 1) I'll have to look at Get Center. I don't know who wrote it initially, and I haven't really dove into the logic of it. I think there's a better way to do this anyhow, I'll try to come up with a fix and post it here. EDIT: I think Get Center works. I'm getting correct results. Can you explain why you think it's incorrect? 2) Get Gravity Center is broken. It's not using the correct function. Again, I'll post it here once I'm sure it's working. Note on the node once I post it: It probably won't be accurate for Multiple Extrude objects, which is why I haven't already posted it. I've been trying to figure out if I can get it to work for them. So, for question 3, once I get a better handle on these things, I can hopefully answer this as well for you EDIT2: Attached file with a correct Gravity Center node. NOTE: This node will not work on polys. Use Get Center from the Poly3D category instead.

Patrick, With regards to your suggestion for the Curve node using Cubic/Bezier modes, since this node produces a NURBS curve, I don't think it's as simple to give those options. I can, however, modify the poly nodes to behave in this manner, and I've already begun doing so. NURBS Curves use a boolean called "byFit" to determine whether it's a curved index or not, and does interpolation to calculate the line, at least to my knowledge. I'll attach the modified poly nodes to this post once I complete them.

I'm attaching a file with a node, Centroid2D, I haven't taken the time to handle unit conversions (it appears that the VS function doesn't take them into account) so this node in its current state works with Feet/Inches as document units. If you're working with millimeters, just take out the "/25.4" in the x and y lines, and if you're working with other units, use the factor to convert from millimeters to whichever other document units you're using. I'll get around to doing error handling on this at a later time. Hope this helps!

I'm running into an issue where I can't figure out which direction the door swings, which is unfortunate. I do have it working with Bi-Part now, and I suppose the worst case scenario is that you'd have to mirror the drawn-in swings... I'll keep poking around to see if I can figure out a way to see where the door swings from though!

Here's my progress so far. This allows you to just run the script and it will look for any doors that already exist in the drawing, for simplicity. That way you still get all of your door options, and the swing is just added on. This does conflict with the hybrid aspect of the door, these lines will show in 3D view as well as 2D. Maybe classing them could help for final drafts? Looking into showing the door thickness, checking the swing configuration, etc. I'll keep working on it when I can. (I'd be careful using this script in a file that you're really working on because if you have any configurations other than Swing Simple, it's not going to be accurate on those doors... Plus it's just not done ) So essentially, the bulk of the math is done, just need to refine it. Let me know if there are any configuration types in particular that you want me to focus on, since I'll have to do them individually I think. Note: The error is due to setting attributes with the Attributes node, because there isn't currently handling to not try to assign fills to lines. It can be ignored, the script still runs to completion.

Hi Tom, Could you give me an image showing how you'd like this to look? I may be able to provide you with some help on this using Marionette. I've already started my experiments, and it's coming along to the point where I just need an example to work from. Thanks!

So I touched on all of those wishes you had with the attached revision. The worksheet specified should update accordingly (node about "Create Worksheet", if the worksheet already exists, it will provide the handle to the worksheet without changing anything about the existing worksheet, I'll clear that up in the description later.) I changed the locus node to a Symbol node, which allows you to choose which symbol is inserted by name. I've boxed that in the script in yellow. Modification of the text was implemented using the Set Text Orientation, I also included the "Set Text Properties" node to allow you to define justification/spacing/etc. The description gets cut off as to what the parameters are in the dialog box currently, but if you open the script inside the node, you can read the values associated with justification. Let me know how this works for you!

Yes, I wrote the Site Z Height as well as the worksheet nodes. I've actually been working to expand our default library for Marionette. Your further requests are easy to implement, and next time I hop onto Vectorworks I'll dive in

I'm attaching my addition of a script to your file in order to get the information you're querying. I didn't incorporate the worksheet nodes into this file, but you can bring them in from my previous one and they should work with this one as well, as long as you wire them correctly. I had to name both your site model and building footprint in this circumstance, although there are other ways to grab the handle to the objects... I just find this more consistent. I created the node "Site Z Height" to get the Z value at each midpoint, it appears to have the exact results of your stake objects, so I'm feeling confident. (The slight difference is the numbering of the midpoints, if this matters, it can definitely be adjusted.) If you need more help after playing with this a bit, feel free to reach out. I hope this was helpful! Marissa

In short, ABSOLUTELY. I'm attaching a file that starts the process, I don't have a site model to work with at the moment (if you have a small file you could share, I could work with that) In this case, the building is composed of walls. We could explore using other objects as well - spaces, etc. (It all depends on how your footprint is created/best represented) There are functions available in Vectorscript that I think would work to get your Z value at the points on the site model, they aren't currently included in the Marionette library, but I can create them. And obviously my data attached to the text & worksheet isn't accurate to what your template is, but I'm demonstrating that we can put it there if we can extract it. Does this look like something that would help solve your problem?

I think the problem with feature enhancements not making it in is that the priority of other fixes takes precedence, and sometimes, maybe even more than I think, that precedence isn't determined only by internal employees. We have a long, long, long list of enhancement requests that we sort through; we consider the time it will take to implement, determine the priority, and hopefully get to include them in a release at some point. We definitely take into account how many people have wished for the items, but not everything finds its way in as soon as one would hope. It's also good to remember that Marionette solutions can be created and shared MUCH more frequently than Service Packs or Versions, and most of the time, involved enhancements won't be released in Service Packs, for fear of breaking something important, or for time constraints, or for some other logical reason, and instead end up in a new Version altogether. That's why I try to solve what I can with Marionette (and just to claim my ownership, I created that script, and it can be found here ), to at least attempt to satisfy users in our community. I do agree with you that it would be awesome to include everything that can be done with Marionette in the application itself, and I assure you, I'm working to do what I can to get everything I can figure out with Marionette included in the base package, but until I can expand my knowledge and weight in development choices, most of what I want probably won't happen as quickly as it could I still have a lot to learn when it comes to compiled languages, but I'm hopeful to expand my knowledge and help you and all of the other users however I can. EDIT: After speaking with Jim, I realized I should clarify that I hope to create actual tools that perform the same way that my Marionette scripts do, not just include the Marionette scripts in the software.

You're correct in the case that this specific script only goes in one direction to update the worksheet, however it's also possible to go the other direction to create/update text objects in the document from values in a worksheet. I think the problem with Text Objects vs. objects such as Callouts is that Callouts and the like generally have a hidden record attached to them which holds the information, whereas text objects do not. This is definitely a limitation for the situation you bring up. I shared my script because for the situation Xsasinator was in, it seemed to be the simplest solution for his specific request. My script won't solve everyone's problem, but for the time being, it was helpful to him. As for your statement about devoting Marionette efforts to much greater things, Marionette was introduced as a tool to allow users further control and a simpler approach to scripting. It's completely up to the user on how they would like to use it, as simple or as complex as they would like. I don't think it's fair to suggest that anything Marionette does is less than great, if it solves a problem or provides an alternative workflow, I think it's completely appropriate to create.

I'm investigating this for you. Right now, since a Marionette Object essentially uses its own coordinate space, I don't think the object would be able to follow the door using your current script. I also attempted to work with using a door as Control Geometry, but had no success since I believe that has to be 2D. I do have an idea, though. I'll update you if I get it working.

RickR, Where are you seeing conversion issues most frequently? Are you seeing them using your soft goods example? Also, for your default values, how necessary is it to have units adhered to them? In the OIP, these values will all adhere to document units anyhow, so they should behave the same as if you were to use any other object in the OIP. Just curious.

Marionette might be able to help you with this. I'm attaching a simple file with some text objects and a Marionette script. This script will traverse through all text objects and insert their values into Column A. This script can be modified to better suit your needs. If you're interested in trying this method, and want to give me more information as to what else you need accomplished (i.e. appending to an existing worksheet, adding more information, only adding strings that are numeric, etc.) I'd be more than happy to help.

Alan! How sneaky! I'm assuming this is the result of negative inputs. Do you think I should do error handling on this or leave it as is?

I think I've got it. Here's the standalone node - with all of my ugly edits and test cases still in the script guts... well not all of them This file has both the network and a Marionette object. I'll clean up the script at some point... maybe

I've created a wrapper, that I will hopefully soon consolidate into a node, that creates a rounded rectangular extrude (you could also think of it as a rectangular extrude with same-radius fillets on all edges) My original RRExtrude node is inside of the wrapper. If you're interested, running it alone will produce sharp corners.. hence the creation of this wrapper to smooth them. Feedback appreciated.