Jump to content
willofmaine

Marionette Dysfunctional for Me...

Recommended Posts

I got off to a great start with Marionette: its great potential and, let's face it, connecting the colorful nodes is just plain fun.  But...  so far I've made 3 marionette objects, and while they work as expected in their original files, once imported into project files, it's all downhill...

The first is a simple 2D parallelogram that I use to set roof pitches in building sections (rise, run, total run, roof thickness).  I found I first had to import it into a project file's RB before it would work.  Then I learned that, most of the time, it was necessary to run its script in conjunction with duplicating or mirroring it.  In spite of these issues, it's been very helpful.  But today, after not having used it for a while, it's "roof thickness" input is simply being excluded from the OIP (so all I get is a line).  Why??

My second marionette object calculates attic ventilation requirements based on attic area (based on a polygon).  I've only used it once, and (I think) it worked well.  But I'm hesitant to use it again (that it calculates simple things like the area of a 10.00' x 10.00' square as being something like 100.000000321 square feet doesn't help build any trust...).

My third object is a simple cabinet door face (width, height, thickness, reveal, knob symbol, and a variety of options for locating, especially centering, the knob).  When placed from its library file into a project file, there's an immediate script error.  It's been explained to me that there's a script error because Marionette can't run the script because the script is not yet in the file.  A programming Catch-22, I guess?  I'm no programmer (isn't that the whole point of Marionette?...) but it seems we should be able to import Marionette objects without them immediately failing...  And my door object suffers from several other issues as well, some of which were resolved with the help of Tech Support, while others are bugs (such as after the initial placement of the cabinet door in a file, subsequent placements include their knobs only; and textures aren't applied as expected).  Eventually, armed with a list of workarounds, I finally got things working... or so I thought.  A week later, I opened my project file, and my cabinet doors were all over the place...

I deleted them and said goodbye to Marionette.  At least for a year or two.   ***Sigh*** 

Share this post


Link to post

Hi Will,

Have you tried sharing any of the specifics of the problems you are having here in the forums? I've found there's lots of fresh eyes here to help solve problems.

37 minutes ago, willofmaine said:

My second marionette object calculates attic ventilation requirements based on attic area (based on a polygon).  I've only used it once, and (I think) it worked well.  But I'm hesitant to use it again (that it calculates simple things like the area of a 10.00' x 10.00' square as being something like 100.000000321 square feet doesn't help build any trust...).

I have seen these "errors" too. It was explained to me that this is because of how VW does floating point calculations. I think they are not done in base 10 so there are small decimal remainders where you wouldn't expect any.......

Kevin

Share this post


Link to post

Hi Kevin,

I think I've mostly dealt with Tech Support.  I'm not a mathematician, but it seems 10 x 10 should be 100, regardless of base and/or floating point calculations!  I found that I could get the roof thickness of my first Marionette object to reappear in the OIP by editing the script and disconnecting and reconnecting the offending node.  I thought I was all set... but when I tried to mirror it in a blank document, I got an error message.  So, I disconnected and reconnected a couple of the other nodes.  That made the error message go away!  But then the mirrored object was just a single locus point.  Kind of a downward spiral of frustration... Here's a file with the Roof Face Section saved as a PIO in the Resource Browser.  You're welcome to check it out... maybe I'm just completely missing something.  (It sets the vertical thickness of the roof face, which I like to use as a constant throughout a project so that the tops and bottoms of roof faces align at hips and valleys even when they're at different pitches).

Thanks, Will  

01-Roof Face Section.vwx

Share this post


Link to post

Hi,

I recall you playing with the Roof Pitch script. This one is defaulting to the roof thickness in your network when you flip or move as it is reproducing the symbol and not the new object. So will play with it to see why its doing this.

Don't give up, chat here or email us direct so we can assist you. The more you play the easier it becomes. If you get stuck ask in here and we will respond.

Hopefully sort it soon.

I see your delima, for some reason this network resets itself when copied. I rewrote the script in a different way ignoring the change in vertical height as you get steeper which can do if we fix this issue. the extrude doesn't change its in the maths in the move vectors that resets. I put the box in to see if it reset but doesn't.

Will look more tomorrow.

 

01-Roof Face Section_AW001.vwx

Edited by Alan Woodwell
More Information
  • Like 1

Share this post


Link to post
12 hours ago, willofmaine said:

Hi Kevin,

I think I've mostly dealt with Tech Support.  I'm not a mathematician, but it seems 10 x 10 should be 100, regardless of base and/or floating point calculations!  I found that I could get the roof thickness of my first Marionette object to reappear in the OIP by editing the script and disconnecting and reconnecting the offending node.  I thought I was all set... but when I tried to mirror it in a blank document, I got an error message.  So, I disconnected and reconnected a couple of the other nodes.  That made the error message go away!  But then the mirrored object was just a single locus point.  Kind of a downward spiral of frustration... Here's a file with the Roof Face Section saved as a PIO in the Resource Browser.  You're welcome to check it out... maybe I'm just completely missing something.  (It sets the vertical thickness of the roof face, which I like to use as a constant throughout a project so that the tops and bottoms of roof faces align at hips and valleys even when they're at different pitches).

Thanks, Will  

01-Roof Face Section.vwx

Hi Will,

Your Marionette object seems very straightforward. In your file or a new file I don't have any trouble with it but when I bring it into an existing project file it does some weird things. I don't think its anything you've done that's causing the issues. Do you use template files for your projects that you've brought forward from earlier versions of VW? I'm curious because I do and those files are often the ones that cause issues.

Mirroring issues are definitely not unique to Marionette objects. I have all sorts of mirroring issues with some simple PIOs I have coded in Vectorscript and regular objects often render or behave differently if they're mirrored.

@MarissaFI'd be curious what the official advice is about mirroring Marionette objects. Are they stable if they're mirrored? Is it script dependent? Would the best practice be to build mirroring into the object (e.g.. have a checkbox to mirror the object) rather than using the mirror tool to mirror it? At the moment this approach is not so easy because you would need to do it mathematically (there isn't a mirror node).

Kevin

Share this post


Link to post

Have tried using control geometry node and name node but all works fine until after you change the sizes in the OIP and you mirror or drag a copy of the altered object it reverts back to the original settings. mmm.....

Share this post


Link to post

Hi Will, Try this network and Object, re did it a different way and all seems to be ok to mirror and drag and copy, it doesn't revert back for me so see how you go with this one. If this remains stable I will adjust so the dept of rafter remains consistent irrespective of the Rise /Run. HTH 

The issue I found with all the other ways was if you placed a number in one of the inputs the network and object always reset to the original number on copy or mirror. Needed a way to have the new input override the old number and have it retained. Maybe Marissa or Sarah will be able to form a solution. 

Capture.JPG

01-Roof Face Section_AW002.vwx

Edited by Alan Woodwell
  • Like 1

Share this post


Link to post
On 27/08/2016 at 8:34 AM, Alan Woodwell said:

Kevin, Nicely picked up. On the back of this looked at the Dim node and changed the 0.0 to 000.0 thinking it may allow numbers and seems to work with the titles of the nodes to include numbers. Not sure why maybe its one for the girls.

 

01-Roof Face Section_AW.vwx

Capture.JPG

  • Like 1

Share this post


Link to post

Hi Kevin & Alan,

Thanks for all your time & feedback!  For whatever reason, I'm no longer having the issues with fields missing from the OIP... Maybe because I restarted Vectorworks?  More likely it's due to sunspots...

Kevin, seems like you're onto something with the numbering of the nodes!  

Alan, the rafter in your file AW002 worked well - after importing it into a new file and abusing it as much as possible (copy & paste; multiple duplicates with "move by point;" option + drag duplication; mirroring; rotating; multiple edits) it held up and behaved as expected.  But now I'm thinking maybe it's because the nodes aren't numbered?...

I've removed the numbers from the nodes for my original Roof Face Section object, and it now seems to be equally robust.

Okay, I take that back.  It's just now lost most of its fields in the OIP.  This is ridiculous.

I've restarted Vectorworks, which mostly resolved it... except that duplicates made using "move by point" each have two "Rise" fields... (which double-clicking on each object to edit (run?) its script seems to resolve..).

Draw-order of the nodes seems to affect their order in the OIP, but not consistently (though it's at least confusing...).  Maybe it's a combination of draw-order and alphabetical?...  In any case...

Between the three of us, we sure do have a lot of time in this simple, "straightforward" Marionette object!... ... ...

Let me know when you're ready to tackle the Cabinet Face object!...

In the meantime, thanks again,

Will

 

 

Share this post


Link to post

Hi,

 

Did you check out my last file where I change the node numbers and the numbers seemed to work ok.
Send in the cabinet face object would love to play with it.
The draw order, no one has been able  to understand this yet, no rhyme or reason.

Edited by Alan Woodwell

Share this post


Link to post

If you mean changing it from 0.0 to 000.0, I tried that, but it didn't seem to help.  But maybe I missed something.

I just downloaded your file.  If I change the parameters of the "New Mirror and drag copy Ok" version, such as its rise, and then drag-copy or mirror it, it loses its settings...  Maybe I'm misunderstanding you...

I've removed the number from the nodes of the Cabinet Face object, and it seems like maybe possibly it's a lot more stable (time will tell; before it seemed fine, and a week later I found that it had scattered... but, on the other hand, even then it had a lot of problems initially that now seem greatly reduced...).  Actually, the only problem at this point, I think, is that when a door face is duplicated, it randomly changes to the "Threshold" texture(?!?).  But, double-clicking on the Marionette object and exiting before duplicating it seems to resolve that...

Here is a file with both the original (dysfunctional) Cabinet Face PIO (with numbered nodes) and an updated version without numbered nodes (all of the cabinet faces in the model space are the new, updated version, one of which has the unexpected threshold texture...).

Thanks, Will

02-Cabinet_Face.vwx

Share this post


Link to post

Hi Will,

Sorry to hear its still not working reliably.

53 minutes ago, willofmaine said:

Okay, I take that back.  It's just now lost most of its fields in the OIP.  This is ridiculous.

Can you take a screen shot of what the OIP looks like when fields disappear? I'm curious to know what that's about. I wonder if its related to you running an older version of OSX. I have spent some more time working with the Marionette object to try and break it but so far its pretty solid. I wonder if Marissa or someone at NV has access to an older version like yours to test on.

Kevin

Share this post


Link to post

Hi, The program randomly changes the texture and to date I don't think anyone has resolved that. You can't lock then texture in, everyone has this issue as I understand. Just another issue to look into. :)
Nice work with the Cabinet too, and the random texture would be fun if it wasn't serious.

Edited by Alan Woodwell

Share this post


Link to post

Kevin - The missing fields in the OIP seems to be its own sporadic issue; I think it may be related to duplicating Marionette objects, especially with "move by points."  I'll try and get a screenshot next time it happens.  Otherwise, so far, removing numbers from the nodes seems to help a lot.

Alan - Okay, good to know it's not just me experiencing random texture changes.  "Nice work with the Cabinet too" - thanks!  Next step is rails & stiles and, especially, eliminating joint lines between the two!

 

Edited by willofmaine

Share this post


Link to post

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... :) )

Share this post


Link to post

Alan - I place 2D sections into my 3D model which I then use as guides to build the 3D model.  My "Roof Face Section" Marionette object is used in the 2D sections to quickly establish where Roof Faces in the 3D model will be.  I typically use a thin Roof Face for the upper roof (typically 1" vertical thickness that corresponds to the drip edge) and a second Roof Face to represent the rest of the roof/ceiling assembly.  See attached screenshot (the two Marionette objects are highlighted in red).  (The roof edge (eave) is then modeled entirely separately from the Roof Face objects).  Because Roof Faces are set by their bottom faces, and because I want their top faces to always align at valleys and ridges, regardless of roof pitch, I use a constant vertical roof thickness (such that the actual (perpendicular) roof thickness (as set in the OIP) varies).  So by the "Roof Edge Thickness" field in the OIP I really mean the vertical roof thickness.  As far as I can tell, your "Rafter with angle correction_001.vwx" does that, as does my original "Roof Face Section" (when it's working properly...).  Ideally, the "Roof Face Section" Marionette object would show the perpendicular roof thickness in the OIP so that Roof Faces could then be created accordingly, but I guess Marionette info can't be displayed in the OIP...

Marissa - If Marionette objects can't be mirrored or duplicated, I feel like I've completely missed the point of Marionette... Am I trying to use it in a way that it wasn't intended to be used?

Thanks!

Will 

 

 

Share this post


Link to post
42 minutes ago, willofmaine said:

Marissa - If Marionette objects can't be mirrored or duplicated, I feel like I've completely missed the point of Marionette... Am I trying to use it in a way that it wasn't intended to be used

 

 

The original intention was for Marionette to have a 'mirror' node. Unfortunately it didn't make it into 2016, and since it was backend work, I had a hard time resolving it. (We can't fix/introduce API stuff between versions, to my understanding, due to the possibility of introducing bad code.) This should be resolved in the near future, which should then allow you to mirror the components within your Marionette object (and hopefully get rid of the current limitation you've encountered)

As for mirroring a Marionette Object itself on the screen with the Mirror Tool, honestly, it could work. I haven't tested it, therefor I wouldn't recommend it. I'm not sure how VW stores a mirrored state of an object, and my thinking is that if you were to mirror an object, then change a parameter in the OIP, it may regenerate only parts of the object, or it would completely redraw the whole thing - if it redraws anything in a non-mirrored state, it would no longer look like what you intended. I could be wrong though, it could work regardless, I just can't imagine that we store a mirrored object the way that Marionette Objects would need to be stored.

My suggestion is to wait it out until the Mirror node is working properly and then use that within your Marionette script to mirror your objects. (it will take in the handle to an object and two points of a line of which to mirror over, similarly to how the current Mirror Tool works.)

 

 

Or again, once you have your Marionette object looking how you'd like, you can then ungroup it (which will detach it from the parametric script) and mirror that object instead.

  • Like 2

Share this post


Link to post

Okay, so back to my original post, waiting a while for Marionette to evolve might help avoid some frustrating growing pains...  

In the meantime, having removed numbers from the nodes (so that there's no control over the order of their fields in the OIP) seems to have resolved a number of issues, at least based on limited testing: both the Roof Face Section and the Cabinet Face I can now mirror and duplicate without issues (except that using "move by point" to duplicate seems to sometimes remove, or even add, fields to the OIP (which can then be cleaned up by editing the object's script)).

Thanks for your response & explanations!

Will 

  • Like 1

Share this post


Link to post

In case anyone hasn't come across the good news - the mirror node works in Vectorworks 2017!

 

Be sure to check it out and see if it helps you in your workflows!

Share this post


Link to post

So... I thought I'd give Marionette another try... my good old Cabinet Door object...

 

Trying to use or edit the Cabinet Door in Vectorworks 2017 resulted in lots of error messages; wire spaghetti with tiny, disconnected nodes; spinning beachballs; and, ultimately, the frequent need to Force Quit Vectorworks.  A bad start.

 

So I went back to Vectorworks 2016, where it maybe wasn't quite as problematic (though still a close second to 2017's issues...).

 

At least in 2016, in my Marionette Library file, I was able to access the original Network, which I copied and pasted to a 1:1 design layer.  I then saved that file and opened it with 2017.

 

In the new 2017 file, I re-created the Marionette Door Object from the Network, and re-saved it as the "Cabinet Door-Face" PIO Symbol.  And (even with numbered input nodes!...), it seems like possibly it may actually maybe mostly work as expected!  (VW File Attached)

 

Though a bunch of things don't work as one would expect but, at least so far, they were relatively minor and easy to overcome:

 

1.) It seems necessary to first import the PIO symbol into a file, otherwise (I guess) the script is not yet in the new file, so, it fails to run without error messages.

2.) After initial placement of the Door PIO, subsequently just the door knob symbol is placed.

3.) Mirroring the door seems to work(!), but when both are selected and their height changed, only the height of one actually changes.

4.) Mirror one of those doors that has a new height, and it's necessary to change its width twice (it seems necessary to "step" back through its original size before it will acknowledge the new width).

5.) If there are other textures in the new file, the texture originally associated with the door is replaced with another texture (seemingly the first one alphabetically...).

 

So those types of issues aside, maybe there's hope yet... VWIS103

04-Cabinet_Door_Marionette_Object.vwx

  • Like 1

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×
×
  • Create New...