Efficiency in Definition Design

Packages
1

Hello all,

I’ve gone through the verbose version of making a definition - that works fine. It is, however, exceedingly bloated. I was wondering if anyone would care to share their thoughts on arriving at the same geometrical output that I have?

I’ve attached a series of images of how I got to the end result. The premise is relatively simple:

  • Four points at Ceiling level - can change via sliders
  • Four points at top of Column level - can change via sliders. Rotated 45° from the first series of points.
  • Lines taken from each Ceiling points to the centrepoint (0.5 parameter along curve) of the Column points.
  • Lines taken from each of the Column points to the centrepoint (0.5 parameter along curve) of the Ceiling lines.
  • Offset based off a slider for points at 0.25 along curves between Ceiling and Columns.
  • Nurbs curve created after some List Manipulation to gain arcing curves.
  • Nurbs curves divided to form 'smoothing/divisions' and lines created between these points.
  • Polysurfaces created from each of the line segments.
For some reason Code Blocks don't seem to be working for me in the pre-release build (Or I would have conjoint a whole bunch of Point.ByCoordinates(X,Y,Z)'s together, Lines.ByStartPointEndPoint together etc). Beyond that, what kind of major efficiencies am I missing? Or is my thought process dubious and misinformed? :)

 

DMGL_Canopy_1

 

DMGL_Canopy_2

 

 

 

 

DMGL_Canopy_3

 

 

 

 

 

 

DMGL_Canopy_4

 

 

 

 

 

 

DMGL_Canopy_5

 

 

 

 

 

DMGL_Canopy_6

 

 

 

 

 

DMGL_Canopy_7

2

Here is another approach. I used EllipesArc for loft section.

이1미지 001

 

 

 

 

 

 

 

 

 

이1미지 003

3

Ah, a much better approach Hyunu Kim :slight_smile: Thanks!

4

My pleasure, Sol.

It was a good example for me to train as well, though it made me sleep later last night. :slight_smile:

5

Hyunu Kim,

I replicated your definition and have ran into a small problem that I can’t seem to fix because I know it’s correct!

The final Geometry.Rotate is failing with the Code Block input of: 90…360…90; (As shown below in the image)

If I simply put in 90, 180 or 270 in singular form into the ‘degrees’ input of Geometry.Rotate it functions perfectly.

I’m a little stumped… I even tried RadiansToDegrees and DegreesToRadians thinking that might be the problem and we through every node’s output to check it made sense (Which I believe it does).

The image below shows what occurs… kind of seems like a lacing problem even though it shouldn’t be?

HyunuKim_Rotated_Column_Finish

6

Change the lacing to Cross Product.

90…360…90 means {90,180,270,360}, so the code block makes 4 rotated geometries of each(two in this case) geometries in the list when you select Cross Product lacing.

이미지 1

 

7

Oh how did I miss that… sheepish grin

Thanks :slight_smile:

8

BTW, this thread inspired part of my blog post on tips and tricks last week. Though not specifically algorithm-oriented, as your question is, here are some thoughts on organizing your graph using Code Blocks several different ways.

9

Colin, I love your post. it’s essential. Thanks.

BTW, can you tell anyone in your Dynamo team about the unit bug issue at following link? I really don’t get it.

http://dynamobim.com/forums/topic/intersecting-revit-elements/

10

Ah fun, thanks Colin. This is the kind of stuff I need to be learning :slight_smile:

11

Hi Kim.
Could you tell us if there is a way to create a surface with six openings. This one is having just 1. Could you share a way to create 6. Thanks