Marissa Farrell
-
Posts
1,474 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Articles
Marionette
Store
Posts posted by Marissa Farrell
-
-
I can see where this is failing and I can look into ways to resolve this, however I want to clarify some things in general about visual scripting.
Visual scripting IS programming. It does require the mindset of someone who can follow logic.
Although it does appear that some logic is failing in the Rotate node, it does behave as described in most situations. The requirement for angle is defined as the following: "It could be a 2D/3D rotation vector or Point2/Point3 in the Input category. Angles are in degrees"
Therefor, it is not expected that a singular angle will rotate the value around Z.
You're finding an issue with your symbol because the symbol isn't being considered a 2D object, because of this it's using the command to rotate in 3 dimensions, which in standard cases works as intended and defined. I'm looking into why it's not rotating around Z for your symbol, but I haven't quite tracked down why it's failing.
In any regard, I would ask that you try to reconsider your argument that visual scripting should be for everyone "out of the box" because that is not realistic. There will always be a learning curve and a necessity of understanding what's going on behind the scenes. We're just trying to alleviate the requirement of learning syntax.
I appreciate you bringing this to my attention and it will be looked into.
Thanks,
Marissa
-
- I ended up using the Transform2 node. I think there is a coding issue with the Rotate node. It gets confused with 3d point data. I had this problem with the coordinate marker I made before. The Transform2 only tries to rotate around Z and seems to overcome these issues. If you switch back to the Rotate node you'll see things fall apart. I think Marissa or Sarah should spend some time debugging the Rotate node if they haven't already rebuilt it for VW2017.
Kevin, can you tell me what you're seeing that makes the rotate node incorrect? I haven't had any issues using it, and I tested it this morning to make sure I wasn't crazy.
-
Hi Alan,
Great job creating your own node!
We do have this node in the library already. It's called "Regular Polygon" and exists in the Poly 2D nodes.
It might be interesting for you to compare how it was written internally to how you wrote it. (I always find it fun to see how other people put things together.)
-
We used COMSOL often in my Mechanical Engineering undergrad courses.
I believe it would be capable of what you're hoping to accomplish.
We also often used it to compute heat transfer through objects as well as strength of materials.
It will take some learning, though. Each time I opened it up for a while I had to dig into my memory to remember how I needed to set things up, especially considering the processes for the different analyses varied.
-
Didn't find the Thread again but I love your "Create Building from Polygon"
Marionette Work and Video.
Might you be referring to this one?
https://techboard.vectorworks.net/ubbthreads.php?ubb=showflat&Number=231434#Post231434
Everything Alan has been sharing recently has been exceptional!
-
I currently don't have a definitive answer, as I haven't even found the documentation where this is described as a method to order nodes.
Could you point me to where you've found this info? I'll also consult with the engineer on it, but first I'd like to see what the intended method really is.
-
Yes! It's very important to note that it's the node from the skylight example. Somewhere, somehow, the node within VW has become faulty. It will be remedied, rest assured.
-
Yes. You would want to add the record info to the Marionette object.
Another way to do this - if you don't want to have to manually do it - remember that PIO Handle node? Use that with the 'Attach Existing Record' node.
(I haven't tested this, but I'm 90% confident in it.)
You'll want to connect the two networks with a 'pass' node just so that it all runs together in your object. I would put this at the end of the two small scripts.
-
Before digging deeper, my first assumption is that this is because the Marionette object has its own coordinates, so when you insert the symbol into it, it reports back the location of the symbol within the object.
This is because when generating a Marionette object (or any PIO, really) a coordinate system exists solely for generating the geometry within the PIO, that way you can reference points within the object and still move it around freely as an object without breaking those references.
This might not be why though. I'll do some digging. This is just based off of things I've experienced working with Marionette.
-
Hey Alan,
Here's a 2D alignment node. I'll work on the others when I have free time. I just slapped this one together when I got in this morning.
It's very basic. It takes the location of the (one) object attached to the first port and aligns the other objects (attached to the second port) to the first one based on the selection in the OIP.
-
1
-
-
Kevin, Hi, nice work.
When i move this one around I get this error message and graphics drop out.
Any ideas??
Interesting. I haven't had any problems with it here. I wonder if its a PC specific error. Maybe Marissa will know.
Kevin
I'm not experiencing this on my end. Alan, did you make any changes to the file on the machine that you're experiencing the error? The error is referring to incorrect wiring to a node that needs a particular object type - I can't narrow down which one from the error unfortunately.
That is strange. Maybe there's something different about the installations of Python. Or you've found a bug of some sort....KM
There should be no differences with the Python installations. Plus this error refers to a Vectorscript error.
-
That follows my explanation in my previous post. The 3D object will not show in Top/Plan because Marionette creates 'hybrid' objects. I'm not positive, but it's possible that if your referenced symbol was a hybrid symbol that it may display its 2D part in top/plan.
The weird numbers is likely due to moving the object in 3D rather than top plan (which obviously is annoying because you can't place things accurately in Z with just top/plan...)
I don't know if any changes are in-line for how 2D vs. 3D is displayed within a Marionette object, but the offsetting of 2D objects when edited in a 3D view is being extensively worked on.
-
Alan,
Here's the start on a 3D point reference. This will always reference the bottom centerpoint of the cylinder.
There are a few things that I need to mention - in a 3D view, you will not see the text object displaying the coordinates. This is because Marionette actually creates hybrid objects automatically. Anything that is 2D will only be shown in Top/Plan if there is also a 3D object in the script. (in this case, text is 2D, cylinder is 3D. I copied the circle within the script to keep the 2D representation and only extruded one of the circles.) I'm trying to think of a way to also show the text in a 3D view, it may have to do with changing the text from screen plane (which is where Marionette draws 2D objects) to layer plane.
If you move this object in 3D, it is very likely that the text will be offset from the circle in top/plan. This is something we are working on internally, but it is unlikely it will be resolved for 2016. This can be somewhat remedied by moving the circle in top/plan which will reset the association between the two.
-
If anyone is interested in the initial Marionette discussion on the matter, it's posted here:
https://techboard.vectorworks.net/ubbthreads.php?ubb=showflat&Number=230956#Post230956
-
PS. Is there a known issue using hybrid objects? When I tried working with a hybrid symbol through my original script it ended up at some crazy way off point.
Kevin
Which view were you in when you ran the script? We've had some issues running scripts in 3D views, Top/Plan is the most reliable.
Not sure that this is the case, but it may be.
-
I can try my best to answer your questions.
Rounding Errors: This is due to how numbers are stored within vectorworks. We are in the process of having displayed units adhere to the rounding set in the preferences. I haven't yet finished this.
Real Coordinates of Marionette Object: I've attached a file that I hope demonstrates what you're asking for.
Text Centering: I believe the attached file should also help with this. I can look into better improvements on the text node in general so that you wouldn't have to manually script this.
Insertion Point Coordinates: I don't think this is currently set up, but I may be incorrect. There are definitely ways to accomplish this though, with the currently library, if a user sets the object up correctly.
-
I agree with Sarah,
This is GREAT!
Keep sharing what you learn
-
Hi Alan,
The SetWallStyle function takes a string rather than an index, unlike the SetSlabStyle.
You can directly wire your String node to the wallStyle port in your Set Wall Style node.
Hope this helps!
-
But if you DON'T see me come back and address these once that's done, please feel free to throw rocks until I do.
Thanks Jim! We could throw candy instead.... I would assume positive reinforcement has a better chance of success ;-)
I think you should throw kittens.
And send some my way!
(Although I'm sure all that get thrown at Jim will find their way to my desk anyhow
) -
if name != "":
states "if name is not equal to [empty string]". In Python, != is "does not equal" and == is "equals"
This conditional tells the code to only run the script indented below that line to run if name is equal to something.
(I think doing "name != None" should have also worked, but I left it as is.)
if i != vs.Handle(0):
vs.Handle(0) is essentially an empty handle in Vectorworks, or a null handle. I tried using "None" instead of "vs.Handle(0)", but the error was still being returned, and this ended up working instead. It's not what I REALLY wanted to do there.
I think overall what Marionette needs is an update on its internal conditionals. Sarah and I have been working together to locate the nodes that could be improved with additional statements, and it's slowly coming along, but with such a vast library things either haven't been gotten to or have been overlooked.
I'd like to thank you (and everyone else) for asking questions, as that is the best way for us to see how we can help users to understand and utilize Marionette. I can understand without the plethora of documentation that Marionette deserves, it can really be a hit-or-miss on getting networks to behave as expected. We're definitely trying to tackle the issue of documentation internally, and I'm even working independently on my own time to create resources for you all.
I'll keep thinking on if there's any sort of guide that may help you in the meantime, though nothing has come immediately to mind.
Thanks again, and don't hesitate to ask more in depth questions if you ever need guidance!
-
1
-
-
I did a bit of cheating within the nodes... but this works..
The nodes I edited:
Symbol
Move
If you want me to explain what I did within those codes, I'm more than willing to elaborate.
(side note: In a 3D view you may still see some shifts on where the cylinder is placed. This is known and being worked on.)
-
Hi Kevin,
Hopefully the file I'm attaching can help you out a bit.
It's easier to prevent the symbol from being included if you use an IF node right after the string with the name of the symbol you are considering.
Take a look and let me know if this helps at all.
There are many other ways to approach this, but I think this is (hopefully) inline with what you're hoping to accomplish.
-
Currently neither of these are possible, but they are on the list of proposed enhancements.
-
Just to follow up - although I still think it's behaving improperly - the CTRL key allows the temporary change of modes for the eyedropper. I'm assuming that when it's interrupted by the flyover tool, since that ALSO uses the CTRL key to activate it, there's some sort of interference between the tools causing the mode that's not currently active on the eyedropper to get locked on.
I'm looking forward to hearing how the engineers interpret this.
Fence Issue
in Marionette
Posted · Edited by MarissaF
Hey Alan!
That first error message is because the Rotate node expects a list of x, y, and z rotations.
An easy way to remedy this would be to take a "Point 3D" node from the Points category, wire your angle to the "Z" input port, and attach that to the "ang" port on the rotate node.
Doing so will tell the network that you want to rotate about the Z axis of the object (i.e. the axis you would see it rotate about in Top/Plan)
I'm not sure why you're encountering the second error at the moment, I didn't see it when I played around.
Essentially, it's saying that somewhere in your network a node is expecting a 3D object, but there isn't one being supplied to the appropriate port. It's possible that you had a node still wired somewhere (even if it wasn't intended to be used), and it's just kicking back at you as a failsafe.