Jump to content
Developer Wiki and Function Reference Links Read more... ×
willofmaine

Door Knob Position Unexpectedly Doubled...

Recommended Posts

Attached are two files with a "cabinet face" (door or drawer) Marionette object in them.  In File 14, there are two knobs, and all works as expected.  In File 15, a few nodes have been added so that there's the option to have either one or two knobs, but when there's just one knob (the default), its vertical position seems to be based on a cabinet face that's two times taller than it actually is.  If the "Two Knobs" option is selected, then, again, all works as expected (the horizontal and vertical positioning options).  It doesn't seem like excluding the second knob should affect the positioning of the first knob.  What am I missing??  Thanks!  -Will

14-Cabinet_Door-2_Knobs-12.vwx

15-Cabinet_Door-2nd_Knob_Optional-14.vwx

Share this post


Link to post

I went through your scripts 14 and 15

In 14 I get an error message as soon as I want to change a value in the OIP

I converted in centimeters and tried again from the script and it worked. Then I changed the texture to attribute. This helps but will not change the fact that when you wrap the rotation node wouldn’t follow the fist time (see the next post). Then VW crashed.

Started again and only changed the values in the script, this is working. I haven’t understood the use of the first rectangle (in pink) but this is just a matter of curiosity.

Going to 15 this is totally insane.  I have tried many options from center true to taking out the second knob. I get funny situations but I cannot fin a reason why when you apply you option to the first knob then the cabinet door flies to the its high and the knob is at the right place. The same with the rotation the unique knob rotates around the center but with two knobs it works. I thought it could come from the fact that when you center in x the knobs (going to true in the OIP) in fact you have 2 knobs at the same place, but then you don’t need to take out the knob later so there is no reason from my point of view, it would affect the rest of the script.

Hope someone can find why…

Share this post


Link to post

So I'm seeing a couple of issues with your networks

The Symbol3D node needs to be rewritten. vs.Symbol() takes a 2D point argument, but the whole 3D point is being fed to it - this isn't the issue that's creating the problems in file 15, but it still, nonetheless, can create issues in other circumstances.

For some reason, that I still haven't determined, the movement in Z is being applied twice to that symbol instance. I'm attaching a network that will prevent that, and though it's not the BEST solution, it will absolutely handle that case.

 

Another note, Marionette doesn't like when nodes are named beginning with a number, or when they include non alphanumeric characters (In this case, your '2 Knobs Option' node) So I've renamed it to 'Two Knobs Option'

 

This network can probably be written more efficiently. If you'd like, I can try to help you out with that when I have some free time :) 

 

15-Cabinet_Door-2nd_Knob_Optional-14_MFarrell_v2017.vwx

Share this post


Link to post

@the frogThe "pink" (non-printed Guides class) is the nominal size of the cabinet "face," so that any combination of doors and/or drawers can be assembled without having to worry about the reveal width.

 

Yes, when you center the knobs they are coincident, so it doesn't really matter whether you choose to have one or two knobs.  Typically cabinet doors have a single knob; sometime drawers have two, thus the two-knob option.

 

Regarding all the additional issues you're having... I'm not having them!  So not sure what to say, other than that it's discouraging: either Marionette is not all that stable and it's kinda buggy, or, I'm just more clueless than I thought...

 

@Marissa FarrellYes, I did subsequently realize that nodes don't like being named with numbers and... oops, guess I only changed it in a file that I'd then abandoned... stand by... updated, but to no avail....

 

If you don't know why it's doubling the Z value, I certainly don't!

 

You completely lost me on the Symbol3D node.  The "Knob Position" node outputs an x,y,z 3D point, and the "Knob Symbol" node wants an x,y,z 3D point input, so I'm not sure what the issue is?...

 

Yes, definitely, I'd like to see how this network could be written more efficiently!!

 

Thanks!  -Will

Share this post


Link to post

The vectorscript function 'vs.Symbol()' only takes a 2D argument. It's nothing you're doing wrong, whoever wrote that node just didn't realize it at the time. I replaced the node in your file with a node that meets the requirements, so it's not a huge deal, just something to think about. We don't ship that node, so it was created by an outside user.

 

Also, @the frog is using a French version, I believe, which may not be as up-to-date as our version is, which may be why they are seeing more issues than you. Marionette is pretty stable, overall. I almost never have issues with it, and I also don't see what they are seeing.

 

I'll try to find some time to share a simplified network sometime this week :) 

Share this post


Link to post

Oh, I see.  Looks like you just added a [0] and a p[1] to the 'vs.Symbol' of that node?  I do now vaguely recall that when I was first working with Marionette, months ago, I'd acquired that Symbol3D node from somewhere other than the VW default library...

 

So!... The Symbol3D node doesn't ship with VW; there appears to be no Mirror3D node; and you recently created the ScaleSymbol3D node (thanks for that!).  Which makes me wonder if I'm going down the wrong road in seeking nodes with 3D capabilities in my pursuit of creating 3D Marionette objects?... ... ...

 

Looking forward to seeing the simplified network! :)

 

Also, when I opened your file, the magenta rectangle was  displaced (see attached).  This has happened a few times in other files (including the rectangle's lying flat on the ground plane), though when I recreated another Marionette object from your network, it seemed to work without any issues...  

19-Screenshot of File as Opened-18.png

Share this post


Link to post

We're working on adding more nodes, I wouldn't say you're going down the wrong path - there just haven't been many requests for new things.

We're also slightly limited in what functions are exposed to Python which is why there are a few things you would *think* we'd have by now missing.

 

That displacement is a bug, we tackled it in 2016 and then 2017, but it keeps cropping up. The workaround is to change your variables and run networks from Top/Plan. Top/Plan will always place things in the correct positions.

Share this post


Link to post

Okay, so sounds like it's not unreasonable to keep requesting 3D-capable (or other) types of nodes.

 

Just curious, why Vectorscript AND Python?  Couldn't one programming language have worked for both?...

 

Okay, next time I see the displacement, I'll try running it in Top/Plan view.

 

Thanks!

Share this post


Link to post

@Marissa

I would love to have a list and a file with all the debugged nodes from 2016 and on.

I must be one of the only French trying to work with marionette, so I am not surprise my SP4 version could be left with old nodes.

What I intend to do is to check the scripts (yes one by one and line by line) that have been modified between the French and the American versions and send the package to Cesyam for them to make a patch to our sp4.

my goal, like most of the users, is to be able to produce from marionette so the work is easier.

Share this post


Link to post

Absolutely! Please continue to ask for the functionality you need, I'll do my best to get it onto the forums and hopefully into a shipping version at some point.

 

As for VS/Python, we currently just have the Python API call to the existing VectorScript calls, however a lot of the time I'll use generic Python calls to replace anything that isn't Vectorworks specific (such as writing files, manipulating data, unit conversion, etc.) I'm not really in charge of any of it, so I just roll with the punches and do what I can. Either way, there isn't enough exposed to either language to interact with the back end of Vectorworks.

Share this post


Link to post

Okay, pretty much all of that went over my head (as I suspected it would).  I'll just stick with connecting the colorful nodes with spaghetti and asking for more colorful nodes!  :)

 

Share this post


Link to post

from what I understand DomC node is based on a vs moving a 3D object and Marissa on a vs in 2D am I correct?

 

Share this post


Link to post

Mine still places the symbol at a 3d position. 

The other one was just written a bit incorrectly. The end goal was the same for them. 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

 

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.

×