Jump to content
Sign in to follow this  
Bas Vellekoop

test 1, 2, 3, test 1, 2, 3,: strange offset and how to substract?

Recommended Posts

Playing around with Marionette.

Not getting two things:

How two Boolean the two groups in the file?

And why, in the second try, some of the nurbs-curves not offset too the same side?

Share this post


Link to post

If you unplug the Boolean node and run your script you'll see there's an error message. This means its never getting to the Ungroup or Boolean nodes to execute them.....

Its interesting how the network runs without giving an error when you execute it immediately after opening the file. If you try and run it a second time it fails with an error message. Not sure why that's happening....

Kevin

Share this post


Link to post

The file you posted does not have an object named "bli". without that object, the Contours command can't run.

What kind of object were you using for bli?

Can you post a file that is complete with everything you are trying to do?

Share this post


Link to post

@ Pat: the bli-object object is in one of the 2 groups and in the shelled solid

@ kevin: Strange, here it runs without errors, even if I run the script several times, or remove the group and Boolean commands

What I`m trying to do:

- draw by hand a surface (here it is a interpolated surface)

- shell the surface

- create ribs on the surface (could be any kind of geometry)

- Boolean the shelled surface with the ribs

attached the file only with the surface. If I run the command I get 2 groups. One with the lofted ribs and one with the shelled interpolated surface.

Both are in a group, I thought: ungroup them and then Boolean them... but that doesn't work?

Thanks for helping!

Share this post


Link to post

I think there's a bug here somewhere. I've had some issues myself with the grouping of output from nodes that generate geometry.

Pat, when Nodes output geometry is it always in a group regardless of what the interior node code says? If you look at the bottom branch of this script using the Debug Tool it says the Shell node is outputting "Vectorworks Handle type: 84" which is a solid, isn't it? Yet if you unplug the node and select the generated object its a group containing a solid (shell). Because the Ungroup node will see the handle as "Vectorworks Handle type: 84" it doesn't ungroup the object. A similar thing is happening in the top branch which is generating four "Vectorworks Handle type: 86" which also come out grouped but then don't ungroup with the following Ungroup node.

In my own scripts I've had problems with getting two different groups out of the Duplicate Node which may be related.

Kevin

Share this post


Link to post

You can see the bug in this simple duplicate script, where you get two resultant groups when you duplicate an object three times. The Duplicate node is trying to append to the original object it receives but it doesn't see the group, it only sees the polygon handle (Vectorworks Handle type: 5) output by the Regular Polygon node. Append can't append to a polygon object so it starts a new group instead and puts the last two object in it. Definitely a bug.

That said, then the original node network should boolean properly if you take the Ungroup nodes out, but it doesn't. The result is still two groups.

Kevin

Share this post


Link to post

Each node that generates geometry (or duplicates it) puts it in a group. This group is what links the geometry back to the node that created it so it can be deleted when the script is run again. These groups are not passed through the wires because what we actually want to manipulate (usually) in the network is the geometry, not the container group. Not sure there is a bug here. What exactly is the problem? maybe I can come up with a solution.

Share this post


Link to post

What I am seeing here is that the output of the network is two groups. One group is a single polygon, probably the one generated by the original Regular Polygon node. The other has three polygons, the same number as specified to the into the Duplicate Object node.

I think the question or bug is why is a network with a single open output generating two groups?

Share this post


Link to post
Each node that generates geometry (or duplicates it) puts it in a group. This group is what links the geometry back to the node that created it so it can be deleted when the script is run again. These groups are not passed through the wires because what we actually want to manipulate (usually) in the network is the geometry, not the container group. Not sure there is a bug here. What exactly is the problem? maybe I can come up with a solution.

I doesn't seem to be possible to boolean/subtract the two groups. Hope you can help

Share this post


Link to post
Because the geometry is generated by 2 nodes. 1 creates a polygon and another creates some duplicates. They are independant operations.

So EVERY node that creates an object or objects in a network will result in an group as the output of the network? Even if the object created was only to be used as source geometry for further operations???

If I add a GROUP node at the end and take the output of the Polygon node and the Duplicate Object node into the objs input, I get a single group out. That group contains a single group and that group contains 5 polygons.

If I add Group node to just the Duplicate Object node, I get a group/group/4 polygons which is closer to what I would expect.

There is something here that is not making sense to me at all. What am I missing?

What do I need to do to get a single group with 4 polygons, the original and the 3 duplicates?

Share this post


Link to post
I doesn't seem to be possible to boolean/subtract the two groups. Hope you can help

I'd be curious as to why the boolean doesn't work too. If I ungroup the resulting geometry and manually Add Solids they boolean just fine. The Boolean node doesn't seem to do anything to these objects in any of the three modes.

Because the geometry is generated by 2 nodes. 1 creates a polygon and another creates some duplicates. They are independant operations.

From a logical perspective this makes sense but I feel like the residual geometry is just in the way. I guess the Duplicate node is a direct interpretation of the Edit>Duplicate command. I would prefer a duplicate operation where you can choose to retain the original object or not like Duplicate Array or Move by Points with duplicate on. I looked around for other nodes that Duplicate/Copy and the only one I saw was Copy. Interestingly copy has two outputs (orig and copy) and in my testing only generates one object.

In my example, what happens downstream, does the next node in the sequence see the input as individual pieces of geometry even though they are contained in two separate groups?

What do I need to do to get a single group with 4 polygons, the original and the 3 duplicates?

It seems like adding a Group node and then an Ungroup node does the trick... though this couldn't be the only way, could it?

So the irony is if you end a network with an Ungroup node you'll still end up with a group as the result.....

This is all very insightful albeit a bit confusing.

Kevin

Share this post


Link to post

I made the following changes to the file.

- I checked the "Create a duplicate object" option in the Name node. Otherwise the Shell node consumes the surface on the first run.

- I removed the ungroup nodes. Even though the result of a node creating geometry ends up in a group in the work space, the objects themselves are what get passed through the wires. So ungrouping is not necessary here. If fact what you are telling it to ungroup here is the objects, not the groups. In this example, harmless but in other cases I could see it causing problems. Like, if you were passing a plugin object to the ungroup node, it would try and ungroup the plugin.

- I switched the order of the inputs to the Boolean node. We want to add each of the ribs to the shell, not add the shell to each of the ribs. Maybe I need to explain this in the description for the Boolean node or change the logic so there is no difference.....not sure if that’s possible or desirable in all cases. Things get complicated with lists and lists of lists and what the "correct" behavior is.

Share this post


Link to post

OK, you are right. I will explain the problem later when I have a minute to investigate something. For now, this is an example that should do what you want.

Share this post


Link to post

@Mark

I had a quick look at the file.

Is it intended to work like this, or should it work as in your post/file from 09/23/15 as well?

Don't want to burn it down, but it seems (too) complicated, for the relative simple task of adding or subtracting geometry.

I don't have any experience with scripting what so ever so it could be my ignorance.

Share this post


Link to post

The problem in this file is that EAP's are plugins which dont get fully reset until after the script completes. This is a legacy "feature" from VectorScript designed to protect against avalanches of plugins reseting each other during script execution. So, as a result the extrude along path geometry is not available for use in booleans in the same script that creates them. Very unfortunate, but thats the way it is for now. Please file a bug or enhancement request and maybe we can find away around it.

Share this post


Link to post
The problem in this file is that EAP's are plugins which dont get fully reset until after the script completes. This is a legacy "feature" from VectorScript designed to protect against avalanches of plugins reseting each other during script execution. So, as a result the extrude along path geometry is not available for use in booleans in the same script that creates them. Very unfortunate, but thats the way it is for now. Please file a bug or enhancement request and maybe we can find away around it.

I've submitted it to the wishlist here - https://techboard.vectorworks.net/ubbthreads.php?ubb=showflat&Number=216600Post216600

Mark, could you act on a duplicate of the EAP or convert it to a generic solid within the Marionette script or do you run up against the same limitation? Do EAPs used as control geometry have the same issue?

Kevin

Edited by Kevin McAllister

Share this post


Link to post

Kevin, Converting to generic solids should have the same problem because the geometry has to be created before it gets converted. An EAP as control geometry should not have any problem, as it will be fully defined before the script is run.

Share this post


Link to post

Hello Bas,

I took a look at your script; I was facing the same problem with boolean a "Path Extrude". I fixed it with adding this line: "vs.SetObjectVariableBoolean(eap, "1167", "True")". Hope it will help you!

Ruud

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.

Sign in to follow this  

 

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