Mark Flamer

That is really great. Thanks for sharing.

Python is a "Dynamically Typed" language. Values are typed, not variables. So, you can assign a value of any type to a variable x for example and then later assign a value of a completely different type to x. What this implies is that there is no static type checking during compilation, it is done at run-time. This allows you a lot of freedom in your code. The drawback is that you will not catch these type errors until the program is run.

I agree, we need a node like this for display of data.

This is really interesting work Dom.

Here is an example that works. The node is "Set 3D Info". Looks like this uses one of the really old API calls that is view dependent. So, if you are in a 3D view other than "top", you will get unexpected results. There is an easy fix for this, we will try and get it into the next library release.

Here is an example using a loft node. Each time its runs you will get a different curvy vase thing. The trick with this node is that it wants a group of curves instead of just a list. Maybe we should change that.

Alan, "Parent POI handle" is probably getting the handle of the Marionette object it self. In the network that defines a Marionette object it is sometimes necessary to get the handle of the object. In this case it is assigning the hole cutting geometry to the skylight object. Let me know if that does not make sense.

Yes, really easy to create a node that does this. It's a good example of how to create custom "commands" using Marionette. I went ahead and threw one together.

What about digitalmechanics? Are you still not able to use Marionette?

Can you take a look inside Marionette.py at that path and tell me what's inside? There was a problem a while back with this file ending up empty. Thanks, my apologies for the trouble.

Good ideas. Btw, there should not be any problem launching the predefined dialogs defined in the dev wiki using Marionette. It just takes a line or 2 of code you can almost cut and paste into a node from the wiki. Here's an example in a couple images.

You can absolutly suggest new ideas for content. And if we don't develop them, there is always a chance that someone else in the community will. Much of Grasshoppers success is due to the incredible ammount of additional content and packages that were developed. Almost none of this was produced internally. Kangaroo, Mantis, Ladybug, Honeybee, almost any animal name you can think of.......all developed by outsiders. Hint, hint...;-)

Here is a folder of additional Marionette libraries that is shipping in SP2...but why wait? The attached image shows where they will be in the release.

These are the current OIP controls offered in Marionette Int Bool Real RealCoord RealAngle RealArea RealVolume Text TextStatic TextStaticParam Popup PopupClasses PopupLayers Separator PopupTextures This list and other useful Marionette code is in Marionette.py

OMG, you took Sarah's tutorial and mixed it with my truss network! Incredible.

Chris, It is a limitation in VW that hybrid objects (objects that contain screen plane objects for 2D plan representation in addition to 3D objects) can not be rotated so they would end up non coplanar with the layer plane. I added a couple node to your network as shown in the attached image. This solves the 3D rotation problem. There still is a problem with the dimensions. I think this is related to some of the old VS calls that Marionette wraps that only work in screen plane coordinates. Specifically HWidth() & HHeight(). I'm looking into this. I am confident this object could be made to work as you like even with these restrictions. We might just have to model it using a slightly different technique. Maybe you could copy the control poly and use its geometry more directly for the extrusions. And possibly use some linear extrudes for the frames. That way you could even add more complex shapes for the stiles, etc..

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.

I believe so. Scipy has an image processing library. Once we can work with the individual components of the image (colors, pixels, etc) alot should be possible. We could draw and extrude a grid of circles whose radius was determined by the average brightness of the pixels, for example.

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.

We actually added a path exactly for this reason on the mac. It should be available in SP2. It is just outside the package at "../Libraries/PythonExternals". Python modules will be available to VW and Marionette from this location. Also, In response to DomC above...I have seen Marionette launch dialogs and plot data from SciPy. It is possible. Take a look at the enormous functionality of these libraries. http://docs.scipy.org/doc/scipy/reference/ All sorts of good stuff there. VW + Marionette + Signal Processing? ;-)

You are correct in that you need to install Numpy and Scipy in order to run my example that uses these libraries. You do not need to install Python, that is alraedy on your machine.

Matt, It should have the exact same functionality as if you were scripting in VectorScript as far as punching holes goes.

You dont need to install Python, it's already in the VW package. I know another user who sucessfully got this setup on the mac yesterday. I just sent him an email asking if he can give a tips here. We'll get it...as a community.

vs.Marionette_DisposeObj() flags an object to be deleted...after the entire network has run. This is a really important difference from vs.DelObject() which immedatly deletes the object. If you use vs.DelObject(obj) in a node, and then have another node that operates on the same object after it has been deleted, you can say goodbye to VW.....crash! Once you are in the script and working with object handles, you are no longer protected. You have to be careful and abide by the same rules as we do. ;-)

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.