Odd Results when Network Added to Wrapper

[willofmaine]

I've created an EAP that uses a profile symbol and a 4-point 3D polygon as the path, and now I'm trying to make the path a function of the size of the profile (since there seems no way to control the insertion point of a profile used in a Marionette EAP(?)...).  But I'm getting varying results...  See attached file (Vectorworks 2017).

 

The network on the left works pretty well, except that it produces two EAPs, each with different relationships to the path, rather than just one EAP as expected.

 

The network on the right is (at least theoretically...) the same as the network on the left, except that more of it has been incorporated into the "Exterior Trim" node (in which the network is in a symbol).  Yet it produces very odd results - an EAP that might make for a great whimsical door frame, but... not what I'm looking for...  Maybe it's creating one EAP that uses twice as many points, points that the other network is using instead to create two separate EAPs?... ... ...

 

 

08-Odd Results When Wrapped-00.vwx

[Marissa Farrell]

Hi Will,

 

Can you please post a screenshot? I think you're still using 2017 and I want to see if I'm seeing different things in 2018.

 

Thanks!

[willofmaine]

Hi Marissa,

 

Here's a screenshot, showing the two groups created by each of the networks (actually, those should be in the VW file that I posted, as well).

 

Thanks!  Will

09-Odd Results When Wrapped-08.pdf

[Marissa Farrell]

Okay, I started with your left network - the problem here is that in your Profile Width and Symbol Height wrapper, when you Ungroup that object you're getting the values for both the poly AND the locus. That's why two profiles are being drawn. You can get around this by doing some math, but I'm not sure what dimensional values the object is supposed to depend on, if you could give me a drawing that shows how your input dimensions are used in the end result, I can help further.

 

I would also suggest using the Contents node rather than Ungroup inside that wrapper, as well as moving the Delete node to right after the profile instead of after the Ungroup node.

 

Taking a peek at the other network soon.

[Marissa Farrell]

Your right network is facing the same issues where it's using values supplied by the locus in the symbol. You can verify this by removing the locus in the symbol definition. Again, we can work out a different way to offset the placement in the EAP.

[willofmaine]

Ah ha, okay, so, at least I was on the right path thinking that something was being doubled...

 

Dimensionally speaking, I'm trying to create an object where any profile can be used.  The purpose of the locus is to establish the location of the trim with respect to the opening (as in, the trim is usually held back something like 1/4" from the edge of the opening (but this varies)).  In an ideal world, the locus (the symbol insertion point) would be on the path, but as far as I can tell, in Marionette, the profile is centered both ways on the path.  So, the locus is also creating the overall profile width that the network is using to do the math (basically, I'm adding the width of the profile and locus (whatever it may be) to the width of the opening ("Width") to create a path that's centered on where the trim (+ locus) should be).

 

You'd suggested using the "Contents" node before, but I had no luck with it...

 

I'm all for a better way to offset the placement of the EAP profile!  Thanks!

[willofmaine]

Okay!  I've eliminated the locus and added a "Profile Offset" input, and now everything's great!  See attached.  And I think I actually like this better anyway, because the offset can be changed without having to update the profile symbol and then re-run every single Marionette object using that symbol's profile.  Speaking of which...

 

Is there any way to use a profile symbol that doesn't insert as a group, so that when the symbol is updated all of the Marionette objects using that symbol profile would automatically be updated accordingly?...

 

I'd still like to understand the "Contents" node that you've been suggesting, and where exactly you mean for the "Delete" node to be (though it seems to work where I have it(?)...).

 

Thanks!

11-Great Results When Wrapped-00.vwx

[willofmaine]

@Marissa FarrellOkay, I've moved the "Delete" node from the "Ungroup" node to the "Symbol" node, without any apparent ill effects (or any effects of any kind, really...).  But when I use the "Contents" node, I get unexpected results; see attached file.  The "Profile Symbol Width & Height" node in the network on the left uses the "Ungroup" node, while the one on the right uses the "Contents" node.  Otherwise both networks are the same, and both use an opening size of 36" x 80", which is represented by the red rectangles in Front view.  The Marionette object on the left is as expected, where the red rectangle corresponds with the inside face of the EAP.  But even though both networks are doing the same math (to create the EAP's path at the center of the profile, however wide the profile may be), the EAP of the Marionette object on the right is inexplicably centered on the edges of the opening, rather than being centered on where its path is (or should...) be (i.e., a distance away from the edge of the opening that's half the width of the profile...).  Are the "Ungroup" node and the "Contents" node providing different results for the width of the profile?  Or?...    

MLF 12

16-Ungroup vs Contents-15C.vwx

[Marissa Farrell]

Interestingly enough, in your network the Contents node isn't pulling that object out.

I know it was working when I first looked at your network so I'll have to take another look.

 

If your ungroup node is working for you, it's fine to do that. It shouldn't hurt you in this network specifically, but it can cause problems in other situations.

[willofmaine]

Okay, thanks, I'll stick with the "Ungroup" node.  Let me know what you figure out, and maybe what the difference is between the two nodes and maybe even why and when "Ungroup" might decide it wants to be problematic...  Thanks!