Marissa Farrell

If I had to guess, it would be because somewhere the connection with "Top of Structure" for your wall style and the generated objects are missing each other. Since the wall style depends the top of a structure, and it's apparently not picking up on that within the Marionette object, the height of the walls isn't being set appropriately. I'll look into it. There may be a sneaky workaround.

I haven't found anything browsing the internet that can do that. Python appears to only have 4 numeric types - int, float, long, and complex - unfortunately it doesn't look like any of them would play nicer with round.

I also want to clarify what you're seeing with python's Round function. https://docs.python.org/2/library/functions.html#round http://stackoverflow.com/questions/7515266/rounding-problem-with-python

A float is a variable type. You could compare it to a double. Since Python is an interpreted language, it generally chooses the type of our variables on its own. In actuality, I believe ALL of our Math nodes use only Python. This is for development reasons, Vectorscript isn't really being maintained anymore since Python is much more flexible. The reason the number of decimal places is so long is because VW uses long floats in its math. This becomes more apparent when displaying values from a script. Since VW has the preference of how far out numbers are displayed, many users aren't aware how precise the values used in the software actually are. In my post right above your most recent one is my best solution so far. The Str node will get rid of trailing zeros, so after you pick your precision with the Round node, it's done the best at displaying what you want (except in the case of an Integer, then you would want to use Trunc). This will also change the variable type, though, from float to string, so I would advise doing any math you want done BEFORE converting it. You're more than welcome to use the VS Round function, but it is unlikely we will ever ship it with default content since it's getting outdated.

Also - to follow up. Since the reason for your rounding is display purposes, another way to get rid of trailing zeros would be to use the "String" node (str) in the String category. This would be useful for the cases where you may want to round out 3 decimal places but still see what's past the whole number. After you convert the number to a string, you can put it right back into the text object.

Hey Kevin, So rounding doesn't appear to truncate the number, which is what you're really looking for. If you use the "trunc" node after your "round" node, I think you'll get what you want. I'm also in the process of getting nodes to follow the rounding display preferences set in the application, but that won't be available for a bit longer. EDIT: Trunc may only solve the issue if you're looking for whole numbers.

I'm glad you tracked it down! Could you email me your old preferences file? I'd be interested to see what may have been saved in there that was affecting your networks. Thanks!

Kevin, Although you're correct that it's creating a hybrid object, I'm very hesitant to believe that's where the error is coming from. I still haven't tracked it down. The 2D objects that are drawn are unrelated to the rest of the network, they're kind of just hanging out. However, the reason this is creating that 'hybrid' object is because when Alan uses the If node to determine which shape to take on for the extrudes, he's using the same shape that he decides to delete. Since the 2D objects don't need to be retained in this case, the easiest thing to do would be to wire both the circle and rectangle nodes to the delete, it isn't really necessary to wire the "If" node to delete. The Delete node is special, in a way. The logic behind it knows to leave all objects alone until after the script has entirely run. Since this object doesn't require any 2D entities, you can pretty much wire every single one to it, if you wanted. The other great thing about Delete is that you really only need one in the network, you can wire every single thing you want to delete to one single Delete node, and nothing will happen until the end. It just creates a list to delete later while it's running. This prevents users from accidentally deleting a handle to an object that they intend to use later, or that the network may depend on at a later instance (such as Extrude Along Paths, which aren't generated until the very end.)

Sure! Or you could set it up to do different heights for different colors. I'm working with grayscale only because I like the idea of querying the brightness of the pixels rather than the colors. It's perfectly acceptable to assign a height to a color rather than a brightness.

I haven't had much time to play with it recently... Testing new features is top priority in-house! But here's a sneak peek at where things have gone (and will continue to be going) This set of extrusions is created from an image that exists in VW. Originally, I was just querying images externally, so I'd have to use the path to the image on the disk. Now if the image is already existing on your drawing area, the script will be able to export it out, query it, and then bring the data back in. It's been upgraded to be cross-platform (I'm primarily a Windows user), the usability is easiest in 2017, which again is why I'm not sharing quite yet. Once we get closer to release and more of the new tasks are signed off as completed, I hope to have more time to improve on it. (also, this will NOT be limited to just creating reliefs/extrusions/etc. The possibilities will be ever expanding with it.)

Hey Alan! That first error message is because the Rotate node expects a list of x, y, and z rotations. An easy way to remedy this would be to take a "Point 3D" node from the Points category, wire your angle to the "Z" input port, and attach that to the "ang" port on the rotate node. Doing so will tell the network that you want to rotate about the Z axis of the object (i.e. the axis you would see it rotate about in Top/Plan) I'm not sure why you're encountering the second error at the moment, I didn't see it when I played around. Essentially, it's saying that somewhere in your network a node is expecting a 3D object, but there isn't one being supplied to the appropriate port. It's possible that you had a node still wired somewhere (even if it wasn't intended to be used), and it's just kicking back at you as a failsafe.

I can see where this is failing and I can look into ways to resolve this, however I want to clarify some things in general about visual scripting. Visual scripting IS programming. It does require the mindset of someone who can follow logic. Although it does appear that some logic is failing in the Rotate node, it does behave as described in most situations. The requirement for angle is defined as the following: "It could be a 2D/3D rotation vector or Point2/Point3 in the Input category. Angles are in degrees" Therefor, it is not expected that a singular angle will rotate the value around Z. You're finding an issue with your symbol because the symbol isn't being considered a 2D object, because of this it's using the command to rotate in 3 dimensions, which in standard cases works as intended and defined. I'm looking into why it's not rotating around Z for your symbol, but I haven't quite tracked down why it's failing. In any regard, I would ask that you try to reconsider your argument that visual scripting should be for everyone "out of the box" because that is not realistic. There will always be a learning curve and a necessity of understanding what's going on behind the scenes. We're just trying to alleviate the requirement of learning syntax. I appreciate you bringing this to my attention and it will be looked into. Thanks, Marissa

Kevin, can you tell me what you're seeing that makes the rotate node incorrect? I haven't had any issues using it, and I tested it this morning to make sure I wasn't crazy.

Hi Alan, Great job creating your own node! We do have this node in the library already. It's called "Regular Polygon" and exists in the Poly 2D nodes. It might be interesting for you to compare how it was written internally to how you wrote it. (I always find it fun to see how other people put things together.)

We used COMSOL often in my Mechanical Engineering undergrad courses. I believe it would be capable of what you're hoping to accomplish. We also often used it to compute heat transfer through objects as well as strength of materials. It will take some learning, though. Each time I opened it up for a while I had to dig into my memory to remember how I needed to set things up, especially considering the processes for the different analyses varied.

Might you be referring to this one? https://techboard.vectorworks.net/ubbthreads.php?ubb=showflat&Number=231434#Post231434 Everything Alan has been sharing recently has been exceptional!

I currently don't have a definitive answer, as I haven't even found the documentation where this is described as a method to order nodes. Could you point me to where you've found this info? I'll also consult with the engineer on it, but first I'd like to see what the intended method really is.

Yes! It's very important to note that it's the node from the skylight example. Somewhere, somehow, the node within VW has become faulty. It will be remedied, rest assured.

Yes. You would want to add the record info to the Marionette object. Another way to do this - if you don't want to have to manually do it - remember that PIO Handle node? Use that with the 'Attach Existing Record' node. (I haven't tested this, but I'm 90% confident in it.) You'll want to connect the two networks with a 'pass' node just so that it all runs together in your object. I would put this at the end of the two small scripts.

Before digging deeper, my first assumption is that this is because the Marionette object has its own coordinates, so when you insert the symbol into it, it reports back the location of the symbol within the object. This is because when generating a Marionette object (or any PIO, really) a coordinate system exists solely for generating the geometry within the PIO, that way you can reference points within the object and still move it around freely as an object without breaking those references. This might not be why though. I'll do some digging. This is just based off of things I've experienced working with Marionette.

Hey Alan, Here's a 2D alignment node. I'll work on the others when I have free time. I just slapped this one together when I got in this morning. It's very basic. It takes the location of the (one) object attached to the first port and aligns the other objects (attached to the second port) to the first one based on the selection in the OIP.

Interesting. I haven't had any problems with it here. I wonder if its a PC specific error. Maybe Marissa will know. Kevin I'm not experiencing this on my end. Alan, did you make any changes to the file on the machine that you're experiencing the error? The error is referring to incorrect wiring to a node that needs a particular object type - I can't narrow down which one from the error unfortunately. There should be no differences with the Python installations. Plus this error refers to a Vectorscript error.

That follows my explanation in my previous post. The 3D object will not show in Top/Plan because Marionette creates 'hybrid' objects. I'm not positive, but it's possible that if your referenced symbol was a hybrid symbol that it may display its 2D part in top/plan. The weird numbers is likely due to moving the object in 3D rather than top plan (which obviously is annoying because you can't place things accurately in Z with just top/plan...) I don't know if any changes are in-line for how 2D vs. 3D is displayed within a Marionette object, but the offsetting of 2D objects when edited in a 3D view is being extensively worked on.

Alan, Here's the start on a 3D point reference. This will always reference the bottom centerpoint of the cylinder. There are a few things that I need to mention - in a 3D view, you will not see the text object displaying the coordinates. This is because Marionette actually creates hybrid objects automatically. Anything that is 2D will only be shown in Top/Plan if there is also a 3D object in the script. (in this case, text is 2D, cylinder is 3D. I copied the circle within the script to keep the 2D representation and only extruded one of the circles.) I'm trying to think of a way to also show the text in a 3D view, it may have to do with changing the text from screen plane (which is where Marionette draws 2D objects) to layer plane. If you move this object in 3D, it is very likely that the text will be offset from the circle in top/plan. This is something we are working on internally, but it is unlikely it will be resolved for 2016. This can be somewhat remedied by moving the circle in top/plan which will reset the association between the two.

If anyone is interested in the initial Marionette discussion on the matter, it's posted here: https://techboard.vectorworks.net/ubbthreads.php?ubb=showflat&Number=230956#Post230956