Marissa Farrell
-
Posts
1,474 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Articles
Marionette
Store
Posts posted by Marissa Farrell
-
-
This is a known issue that also bothered (still bothers...) me.
I believe it's a high priority on our list of things to solve, hopefully we can implement it sooner rather than later.
Be assured we are working on it either way!
-
We've actually started talking about encryption of Marionette recently, but there are a lot of things to consider.
Right now, Marionette is very much open source, and I think it's important to keep that element for a handful of reasons - it makes it such a valuable learning tool for one.
I have my own opinions on how encryption should be handled - I think we should definitely offer the option to encrypt or lock objects, and possibly wrappers as well, but I really don't agree with locking nodes. I think it's important for safety concerns (since it's all written in python) and I'm a big advocate on learning by example - being able to see the script inside will allow more people to become proficient in python as a language and it will help to teach elements and concepts of use cases for Marionette.
I'm sure other people who work on Marionette with me don't share all of my opinions, so I really couldn't tell you which direction things will go.
If we do take the route to encryption, it won't be until after at least another version. We're working on a lot of exciting improvements for 2017, and I don't know if we would be able to throw another large task into 2017 (but again, I don't know). I'm also uncertain on how difficult it would be to implement.
So in short, I wouldn't hold my breath on it, but there's a chance that in the future we'll get something added in.
-
Yes! Please let me know if other nodes are affected/show the same issue.
I'm trying my best to make our default library as consistent and accurate as possible.
-
Sorry Markus!
This accidentally fell off of my radar!
I looked at your file and failed to see where you're using a "Objs by Crit" node. Are you possibly referring to the Name node?
Either way, we can definitely add an if statement to prevent it from freezing Vectorworks.
As for your question about saving the Python script to the script palette, since you're receiving the character limit, I would say no. And you're correct that it will execute immediately if you use Run Script.
There may be a way to save it as a menu command, but I'm not familiar with the process as of yet. Maybe another user could point you in the right direction.
-
Martyn,
Can you check if the node in this file works how you expect it would?
I did some preliminary testing, but you know the problem better than I.
Thanks!
Marissa
-
I don't know if this situation was explored when the node was created, but I'm adding it to our list of things to look into.
Thanks for reporting!
-
The closest I can think of would be to use the filter node to filter items from a list that meet a certain requirement...
But even then, the user wouldn't be able to choose one the way that I think you're asking for. There's not currently a way that I'm aware of to interrupt the script to have user selection.
There might be some hope if using dialog boxes, but I haven't explored that.
-
Are you aware of Debug Mode?
Many users aren't completely satisfied with it in its current state, but to use it, have the Marionette tool selected and in the mode bar activate the Bug icon.
To use it, you can click on a wired output and it will activate a dialog box with the data that flows through that wire.
We're trying to find a more user friendly way to run it - right now, each time you select a wire, the entire network is rerun (annoying) but it provides at least another method of seeing what's flowing through your network.
-
This isn't currently possible because the OIP controls are defined before runtime. We can't dynamically refresh the OIP controls within the script, unfortunately.
I can't remember if this limitation is a hard limit or if we can find a workaround at a later time, but I'm going to guess it will be this way for at least another version.
-
MMMmmmmmmm. So. Your door tool is different than ours.
I'll have to see what I can find out about this one. I'll let you know if I make progress.
Who's your distributor, by the way?
-
Hi mattao!
Can you show me what you mean by attaching a file with a simple example of what you're seeing?
-
So what I did here was divide the shell thickness by two, and then shelled each contour twice - once in each direction (positive half-thickness, and negative half-thickness) This in a sense will center where the shell is created on the contour.
I converted them to a solid because when they were shells, I wasn't able to add the two halves together to create just one object, that's probably just something funny with how the Add Solid command works with shell objects.
Does all of this make sense, or should I try to explain it differently?
-
I also hate this
Jim, hurry it up!
-
Can you show me where these parameters are? Like in a screenshot of the advanced parameter window?
I'm guessing that variable names aren't localized, and that you can still extract the data, it's just probably not under what you think it is.
-
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!
Brise Soleil Object Breaking Issue
in Marionette
Posted
I've been actually working to solve this problem for a while now. I first encountered it when I was playing with my Stair object, although in that case it was due to a convert to NURBS.
It does have to do with being in Top/Plan vs. a 3D view. I think we tried what fixed some other situations to try to handle this, but it hasn't worked out as expected.
I'll take another look into a way to solve this. I'm thinking in the direction of saving whatever 3D view you're in at runtime to a variable, and then changing to top/plan for calculations, and then resetting back to your custom view. I've just been trying to avoid that since there should be a better way.