I am a newbie to Dynamo and was studying Design Script. While doing so I came upon a script example that asked for the extraction of surface geometry of a cuboid. The argument went:
Cuboid.Faces.SurfaceGeometry()
Cuboid here was predefined in a variable.
Now the question is, when I usually enter a function and “.” , the designscript provides me with the list of avialable functions ahead to select from. But in this case, Cuboid.faces. ---- doesnt provide me anything ahead. Whereas SurfaceGeometry does seem to exist. Why so ?
Also if this is something true, is there an exhaustive, comprehensive list of functions I can search from available online ? like a dictionary or PDF?
See image:
Honestly the line Cuboid.Faces.SurfaceGeometry(c); is problematic, and likely never worked though I would be curious to see the tutorial you reference to know if/how it worked.
- Object oriented programming (which design script is a type of) has a few concepts to cover.
Objects which are the things you create.
- Classes which are a series of commands to define types of objects. Within a class we have three types of commands:
- Constructors which create new instances of a class. These are called by typing the name of the class, then a dot, and then the name of the constructor used, and then opening parenthesis, providing the inputs required, and closing the parenthesis. You did this in line 16 with both
CoordinateSystem.Identity() and Cuboid.ByLengths(…).
- Actions or modifiers which alter an existing instance of the class. One way these can be called is by calling the class, a dot, the name of the modifier, parenthesis, the instance of the class which you want to modify, the inputs, and then closing the parentheses. The other is to provide a reference to an existing object of the class, a dot, the name modifier, parenthesis, the inputs, and then closing the parentheses. I like the later which would be implemented something like this
c.Translate(10,10,10); where I am taking the cuboid c and using the Translate it 10 units on the X, Y and Z axis.
- Properties which contain information about a given object. These are called in two ways as well.
- The first is by providing the type, a dot, the name of the property, a parentheses and a reference to an object of the class, and closing the parentheses. Alternatively you can call an object of the class, followed by a dot, followed by the name of the property you want. I like the later and it would be called something like
c.Height.
Looking at the line you have which is failing…
Cuboid is a class, not an object. As such calling Cuboid just refers to the class, not an instance thereof. You’d want a constructor to create the object before you can pull any properties of it.
Faces is a property which can be read from a topology (a abstract class that covers almost all geometry). How ever as you are calling this off the Cuboid class not an object thereof you’re not getting any result.
1 Like
Now that that is out of the way, the autocomplete is not apt to work in a few situations. Offhand the most common are:
- Namespace collision. Civil 3D has this in MANY cases, where things existed in the Dynamo environment but Civil3D wanted them as well and wanted to keep them aligned to their API. As such things like ‘Line’ could refer to a Dynamo line object or a Civil3D line object. It’s kind of like standing in your kitchen and saying to a robot helper ‘fetch me the fork’ - your helper is not likely to find the right fork. Prefixing it with a class or namespace is one way to fix that - but you have a method there in your case. This can be complicated by adding packages (I believe Rhythm has a Point class as an example).
- Lack of clear object types. After a few levels of nesting the code block doesn’t know what you have. As the code block doesn’t maintain content and only knows ‘what you have’ at runtime this can be problematic when working on inner code bits such as inside a definition. You can get by this by substituting the class for your object (i.e.
Cuboid instead of c but that requires you know what the object class is and where the object resides.
So simplifying how you write your code should bring out more content. In this case I think it is the lack of clear object rather than any of the issues above.
And now to answer your last question about a dictionary of all design script functions… Yes - they are all listed in your Dynamo node library.
The class is the part of the name before the dot, and the action is the part after the dot. As your node library can be significantly expanded on and configured individually as you define your own environment, this means that a complete listing isn’t possible. But it does mean that I’d you can find the node you want you can work out the DesignScript method. Place the node on canvas, wire in some inputs, highlight the node (or nodes), right click the canvas (not the node) and select “node to code” and your design script will write itself. This can then be pasted into another code block and you can progress from there.
Now there are exceptions to this (usually around node model nodes - these have a space (“ ”) in the name and/or have special UI components like a number slider. Some of those can be called directly, but you have to look up how in the GitHub or other reference that exposes source code.
Lastly I’ll leave with some advice on writing DesignScript.
- Keep to associative code unless you must break that. Imperative is slower and more error prone and harder to write.
- Start with lines in active execution and then transition to definitions. This will surface more meaningful errors as they come up.
- Refrain from using custom nodes in DesignScript, as the underlaying packages don’t surface as a dependency.
1 Like
Thank you @jacob.small , all of this is great help ! Although some of the terms and things you wrote I am not quite able to understand (being not accustomed to coding), but a lot of this makes sense. I think I liked the “Dynamo Language Manual” which was a saviour for me to learn the basics of the language behind it. And that’s where the classes and operators came into my understanding. But other than that The primer is what I am studying currently.
I will come back to this again once I have gathered more thoughts.
This particular exercise above is also from the same Dynamo Language manual -
So I was trying this out but unfortunately couldn’t find any node (in the node library) that extracts faces from a cuboid in Dynamo. Puzzling !
There are nodes for Topology, Solids but none to extract faces from cuboids.
But when I put in :
surfaces = c.Faces.SurfaceGeometry();
It did give me the desired results.
But the whole script doesn’t give me the diagonals as expected on the cuboid surfaces.
See code:
def makediagonal(surface)
{
corner_1 = Autodesk.Surface.PointAtParameter(0,0);
corner_2 = Autodesk.Surface.PointAtParameter(1,0);
corner_3 = Autodesk.Surface.PointAtParameter(1,1);
corner_4 = Autodesk.Surface.PointAtParameter(0,1);
diag_1 = Line.ByStartPointEndPoint(corner_1,corner_3);
diag_2 = Line.ByStartPointEndPoint(corner_2,corner_4);
return = [diag_1, diag_2];
}
c = Cuboid.ByLengths(CoordinateSystem.Identity(),10,20,30);
surfaces = c.Faces.SurfaceGeometry();
diag = makediagonal(surfaces);
See Snip:
There seems to be an error in the definition itself. I think the definition argument isn’t correct. But it doesn’t accept “Autodesk.Surface” either:
So questions:
- Why isn’t cuboid node to query its faces present in the library?
- What’s wrong with the definition of the function here?
- Is “Autodesk.Surface” usage correct when defining corner parameters?
But it did work when I changed the class from ‘Autodesk.Surface’ to ‘Surface’:
def makediagonal(surface)
{
corner_1 = surface.PointAtParameter(0,0);
corner_2 = surface.PointAtParameter(1,0);
corner_3 = surface.PointAtParameter(1,1);
corner_4 = surface.PointAtParameter(0,1);
diag_1 = Line.ByStartPointEndPoint(corner_1,corner_3);
diag_2 = Line.ByStartPointEndPoint(corner_2,corner_4);
return = [diag_1, diag_2];
}
c = Cuboid.ByLengths(CoordinateSystem.Identity(),10,20,30);
surfaces_for_diagonals = c.Faces.SurfaceGeometry();
diag = makediagonal(surfaces_for_diagonals);
Now this confuses me since Autodesk.Surface seems to be the only available option within the autocomplete menu. And that’s the only one which give the further suggestions too. Suggestions which make life easier while coding.
Point at parameter is an action in the library. As such you need to declare the surface you are taking action on.
Autodesk.Surface is the class for surfaces.
surface is the name of the variable which is provided in your definition’s first line.
By typing surface.PointAtParameter(0.5,0.5) you are telling Dynamo which surface to work on (the input surface), what the U and V parameter are.
By typing Autodesk.Surface.PointAtParameter(0.5,0.5) you are never saying ‘use this surface’, only the U and V parameters.
You could type Autodesk.Surface.PointAtParameter(surface, 0.5,0.5) and get valid results as well as we are now providing a class, the method, a surface, a U and V parameter.
Skipping the class and just acting on the object with surface is fine - Dynamo, design script, and other object oriented programming languages will usually look at the object’s type and then see if it has the method provided.
One thing which will make it easier for you, don’t jump into definitions until you must - they suppress warnings like and errors. If you tried typing those lines directly outside of a definition you would get the warning surfaced which would tell you useful information when troubleshooting. After you get the core code to work you can then wrap things in a definition.
2 Likes
Thank you so much @jacob.small & @christian.stan . Much appreciate the patience with novices like me. I might have made some repeated errors here. But that explanation clarified @jacob.small. I think the advantage of writing the longer way - Autodesk.Surface & then the surface within parenthesis is good for a novice like me because I get Autocomplete suggestions there. But definitely as I progress the other way of simply using surface.PointAtParameter is much convenient.
The reason I am doing all these is just since I am learning from the Dynamo Language Manual, the designScript syntax. Honestly I couldn’t find a latest comprehensive source of DesignScript tutorials which covers all concepts. This guide does them but its pretty old and hence doesn’t contain the current Revit + Dynamo nuances.
There is the DesignScript Language Model Specification 2.1 - but its too technical for me and this starting guide which I got is much better that way.
I feel there should be some comprehensive tutorials for DesignScript learning for non-programming background users. There are many concepts like Looping, Conditionals which are useful but aren’t there in any tutorials I could find. I am opening a new thread for “while” syntax next. Hope to seek help from you all there;)
1 Like
hi,
i learned a lot thanks to this document
and the help and advice of all (i am still learning)
cordially
christian.stan
1 Like
DesignScript isn’t something that can document all the methods, as the methods will vary based on your environment. Your request thereof is less ‘where can I find documentation for Design Script?’ and more for ‘where can I find documentation for all the nodes in my library?’ which interestingly enough is done with the nodes themselves. Place the node you want documentation for, and hit F1.
It would be good to get some more documentation out there, as what is there is old. Fortunately design script has changed very little since Dynamo 1.2 with the introduction of dictionaries. The Dynamo methods called certainly have changed, but as noted that documentation is already in the tool. 
3 Likes
