Marissa Farrell
-
Posts
1,474 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Articles
Marionette
Store
Posts posted by Marissa Farrell
-
-
I haven't had much time exploring the best practices when using a script exported by Marionette as the script for a plug-in object.
I'll do my best to revisit this after release. Things are pretty hectic internally right now.
-
That alert often means that you're trying to ungroup a plug-in object.
For example, if you were to insert a door into your drawing and attempted to ungroup it, you would encounter that error.
I would guess that your network may be using a command that creates a plug-in object when you encounter that error using your modified ungroup node.
-
1
-
-
Hey Alan!
The reason the Marionette script always results in a group is so that when you re-run the network you don't end up with duplicate objects. The group created by Marionette is directly associated with the network.
The change you made may cause problems in the end. Say you wanted to change your base shape, by altering the ungroup node, you will now end up with 2 pillar objects instead of replacing the original one.
The best practice is to manually ungroup once you're satisfied with your results to detach your object(s) from the network.
-
It's not really feasible for a Marionette object to run on selected objects because you'd have to select the Marionette network to run it...
The criteria you can use for the Objs by Crit node is here:
http://developer.vectorworks.net/index.php/VS:Search_Criteria http://developer.vectorworks.net/index.php/VS:Search_Criteria
And as for creating/deleting classes/layers, I know for sure you can create them, and I'm also pretty sure they can be deleted as well with our default content
EDIT: Confirmed. You can delete the layers and classes using the Delete node if you pass their handle into it (which you can do using the "Name" node in the input category.)
-
Kevin covered most of what I was going to answer initially when you started this thread. I just wanted clarification before I gave information that may have been irrelevant to what you wanted
I believe all of these things are already possible with Marionette. I'd be more than happy to try to go over all of these cases in the near-ish future.
-
1
-
-
Could you please elaborate on this?
How would you like to determine which objects are selected?
How would you like to manipulate them?
I'd like to help you with a workflow for this in Marionette.
-
I tested with both the polyline and freehand tools, both sticking to my initial results of drawing to the left when negative, right when positive.
I've also tested by 'reversing' the polys and get the same results. So there must be more to it. I don't know what determines the sides.
-
That's funny because I'm seeing different results here.
(Which is why I'm holding off on it
) -
Currently the orientation for Rectangle is in vector form, I know, it's not ideal. It just hasn't been updated yet.
You'll want to use the Vec2 node for orientation.
We're working on a better naming convention for the ports to show right on the node what type of variable needs to be wired there/is being wired from the port.
Unfortunately, because of the way descriptions are stored/queried from the object, I don't think we can do a contextual menu item with the description. I know many changes are coming with resources in general, and I'm working with some of the people on the platforms team to come up with a better way to display descriptions.
The reason the error points to the rectangle is because that's where the script is failing. The rectangle node houses the script to create the rectangle, and because it's receiving an incorrect variable type, it's the one kicking back saying "Hey, you wired something wrong to me."
If you want to see the code for the node, just double click on the node. It will bring you to the "guts" of the script. Unfortunately, currently the line numbers returned in an error are misleading. How Marionette works in the end is that it compiles the entire network into a singular script and runs that instead, so those line errors could be pointing to something there OR they could be pointing to functions in Marionette.py which exists in your Application folder, if I remember correctly.
If you're interested in seeing what the Marionette script compiles into, if you right click on your network you can select "Save Marionette Script as Python Script" and that has the script the network uses at the end.
-
1
-
-
Hey Kevin,
I'll have to think of the best way to word things, but yes, I can work on making that change.
There are other cases with the offset node - in your case, it seems you're talking about closed polys. It's always important to also consider open shapes - like an "S" shape, I want to believe that it follows the negative = left, positive = right, but I don't want to be incorrect on any information before I share it, and I need to think about cases like 'What if the "S" is rotated 90 degrees?'
I can certainly, for the time being, work on including a note for closed shapes.
-
You can use the "Any" node which will evaluate the input you give it and assign it to a variable type chosen by Python.
It's USUALLY pretty good at determining the best type to give something, however there may be some mistakes occasionally when using numbers that you want to be strings.
-
1
-
-
The set layer node is kind of a pain right now.
If you want to update the list to show the layers you have in your document, I believe you have to open the script of the node, close it (you don't have to make changes), run the network again, and at that point the OIP control for the set layer node SHOULD have your actual layers in it. If it doesn't work the first time, follow those steps again.
Let me know if you still can't get it to work after that.
-
Hey Alan,
2016 doesn't have the capability of radio buttons for Marionette, but I put in a strong request for them to be added to the possible OIP controls.
I suppose you'll have to wait it out and hope they make it into 2017
-
1
-
-
Hey guys,
Sarah and I were talking this morning, and I figured it would be a good idea to share some alternative nodes for Classes with you.
In the attached file are 2 nodes.
Class Name - this node will allow you to choose a class in the OIP and will output the string name of that class. It can be used in conjunction with the currently existing "Set Class" node.
Set Class V2 - This is a modified version of the existing "Set Class" node. Instead of passing a string name into the styleClass port, the OIP control will define which class the object goes into.
NOTES:
1) The current Set Class node that exists in the default library is located in the Attributes section, in case you're looking for it.
2) When setting the class of an object, that class will NOT be applied to the group which the object is created in. (Reminder - this group is created so that when you re-run the script, the old objects get replaced by the new objects.) If you enter the resulting group, the object inside will have the class applied to it.
-
If I had to guess, it would be because somewhere the connection with "Top of Structure" for your wall style and the generated objects are missing each other.
Since the wall style depends the top of a structure, and it's apparently not picking up on that within the Marionette object, the height of the walls isn't being set appropriately.
I'll look into it. There may be a sneaky workaround.
-
I haven't found anything browsing the internet that can do that.
Python appears to only have 4 numeric types - int, float, long, and complex - unfortunately it doesn't look like any of them would play nicer with round.
-
I also want to clarify what you're seeing with python's Round function.
https://docs.python.org/2/library/functions.html#round
Note: The behavior of round() for floats can be surprising: for example, round(2.675, 2) gives 2.67 instead of the expected 2.68. This is not a bug: it’s a result of the fact that most decimal fractions can’t be represented exactly as a float. See Floating Point Arithmetic: Issues and Limitations for more information.http://stackoverflow.com/questions/7515266/rounding-problem-with-python
The documentation for the built-in round() function says that it rounds to the nearest value, rounding ties away from zero. Since the decimal fraction 2.675 is exactly halfway between 2.67 and 2.68, you might expect the result here to be (a binary approximation to) 2.68. It’s not, because when the decimal string 2.675 is converted to a binary floating-point number, it’s again replaced with a binary approximation, whose exact value is2.67499999999999982236431605997495353221893310546875
Since this approximation is slightly closer to 2.67 than to 2.68, it’s rounded down.
-
A float is a variable type. You could compare it to a double.
Since Python is an interpreted language, it generally chooses the type of our variables on its own.
In actuality, I believe ALL of our Math nodes use only Python. This is for development reasons, Vectorscript isn't really being maintained anymore since Python is much more flexible.
The reason the number of decimal places is so long is because VW uses long floats in its math. This becomes more apparent when displaying values from a script. Since VW has the preference of how far out numbers are displayed, many users aren't aware how precise the values used in the software actually are.
In my post right above your most recent one is my best solution so far. The Str node will get rid of trailing zeros, so after you pick your precision with the Round node, it's done the best at displaying what you want (except in the case of an Integer, then you would want to use Trunc). This will also change the variable type, though, from float to string, so I would advise doing any math you want done BEFORE converting it.
You're more than welcome to use the VS Round function, but it is unlikely we will ever ship it with default content since it's getting outdated.
-
Also - to follow up.
Since the reason for your rounding is display purposes, another way to get rid of trailing zeros would be to use the "String" node (str) in the String category.
This would be useful for the cases where you may want to round out 3 decimal places but still see what's past the whole number.
After you convert the number to a string, you can put it right back into the text object.
-
Hey Kevin,
So rounding doesn't appear to truncate the number, which is what you're really looking for.
If you use the "trunc" node after your "round" node, I think you'll get what you want.
I'm also in the process of getting nodes to follow the rounding display preferences set in the application, but that won't be available for a bit longer.
EDIT:
Trunc may only solve the issue if you're looking for whole numbers.
-
I'm glad you tracked it down!
Could you email me your old preferences file? I'd be interested to see what may have been saved in there that was affecting your networks.
Thanks!
-
Kevin,
Although you're correct that it's creating a hybrid object, I'm very hesitant to believe that's where the error is coming from. I still haven't tracked it down. The 2D objects that are drawn are unrelated to the rest of the network, they're kind of just hanging out.
However, the reason this is creating that 'hybrid' object is because when Alan uses the If node to determine which shape to take on for the extrudes, he's using the same shape that he decides to delete.
Since the 2D objects don't need to be retained in this case, the easiest thing to do would be to wire both the circle and rectangle nodes to the delete, it isn't really necessary to wire the "If" node to delete.
The Delete node is special, in a way. The logic behind it knows to leave all objects alone until after the script has entirely run. Since this object doesn't require any 2D entities, you can pretty much wire every single one to it, if you wanted. The other great thing about Delete is that you really only need one in the network, you can wire every single thing you want to delete to one single Delete node, and nothing will happen until the end. It just creates a list to delete later while it's running. This prevents users from accidentally deleting a handle to an object that they intend to use later, or that the network may depend on at a later instance (such as Extrude Along Paths, which aren't generated until the very end.)
-
Sure!
Or you could set it up to do different heights for different colors. I'm working with grayscale only because I like the idea of querying the brightness of the pixels rather than the colors. It's perfectly acceptable to assign a height to a color rather than a brightness.
-
I haven't had much time to play with it recently... Testing new features is top priority in-house!
But here's a sneak peek at where things have gone (and will continue to be going)
This set of extrusions is created from an image that exists in VW. Originally, I was just querying images externally, so I'd have to use the path to the image on the disk. Now if the image is already existing on your drawing area, the script will be able to export it out, query it, and then bring the data back in. It's been upgraded to be cross-platform (I'm primarily a Windows user), the usability is easiest in 2017, which again is why I'm not sharing quite yet.
Once we get closer to release and more of the new tasks are signed off as completed, I hope to have more time to improve on it.
(also, this will NOT be limited to just creating reliefs/extrusions/etc. The possibilities will be ever expanding with it.)
Marionette Dysfunctional for Me...
in Marionette
Posted
Currently I'm not sure that I would advise mirroring a Marionette Object - since it's generated by a script, I think that any adjustment could 'reset' it and revert it back to a state you didn't desire. What you COULD do, if you're 100% on mirroring it, is 'ungroup it' (which would detach it from the Marionette script) and mirror that (which would currently eliminate the parametric parameters for it, unfortunately), but it should certainly allow less mishaps when mirroring/duplicating/etc.
As for duplicating Marionette objects - I think there may still be some logic missing on the back-end there. I looked into it for a while a few months ago because the object wasn't being generated properly (specifically using 'move by points') so, again, I would suggest 'ungrouping' the object before duplicating it (I know, it's not necessarily ideal... but it would also make your filesize smaller...
)