Room selection, isolate placed and bounded

I noticed something odd: If I evaluate the Area of an unplaced room in Dynamo it returns a very strange value that appears to be neither null nor 0, see image. The list does contain doubles, not strings, I checked.

Room selection

 

 

 

 

 

 

I do not know if the cause lies in the Object.IsNull node or the Element.GetParameterValueByName node. I did find 2 solutions:

1: Lunchboxes Room Element Collector evaluates the Area parameter via a Python script, see image in bottom right corner.

2: A Code Block workaround I cooked up throws an error, but seems to remain stable and does return a null value that I can then use in a mask.

So, what is the best solution?

First, given Ian Keough’s presentation at Case http://www.case-inc.com/blog/dynamo-now-dynamo-next I am leaning towards an approach that facilitates the collapsing of a Dynamo Graph into a Code Block. Would a Pyhton node be an obstacle in that process?

Second, the beautifull thing about Dynamo is that it circumvents the necessity of code syntax, be it C#, Python or Designscript. I’d rather stick with Dynamo nodes and simple Code Blocks. [Derailed train of thought] @Ian Keough: Will I be able to ‘explode’ a collapsed-into-designscript Code Block back into a Dynamo graph to allow a non-scripting user to adapt functionality? [/Derailed train of thought]

Third, my Code Block does throw an error. How seriously should I be taking that? Will this workflow be unstable?

PS: turns out the mystery value is a string, namely an empty one: “”. Impractical, but workable.Room selection2

Me again. Solved my own question with the Clockwork Time.LapTime node. See image:Room selection3

How long does it take to generate a (small) list of rooms that have an Area (i.e. not unplaced, unbounded or redundant)?

method 1 is an evaluation of the room’s Area parameter for containing “” instead of a double value. 100% Dynamo Nodes by the way.

method 2 is a stripped-down version of the ‘LunchBox Room Element Collector’ Python node (hope I’m not infringing on the copyright?)

method 3 is the original LunchBox node

Looks like method 1 wins by a noselength. Also looks like stripping down a script can benefit performance.

@ All, am I missing something? Just started learning Dynamo 2 weeks ago. Completely open for suggestions.

@Andreas: what does the Time.Laptime value stand for? Is it related to the processor clock or actual seconds?

Ekko, have a look at this graph:

Basically I use these nodes for measuring how long the execution of parts of my graph take (since Dynamo unfortunately does not provide us with an anlytical toolset for code optimization). If you want to compare different methods I would think it were best to create separate graphs, run them and look in the console how long each graph takes.

Tnx Andreas, that’s where I got the idea. Just to make sure, I ought make them execute consecutive in stead of parallel, or indeed in seperate nodes (more work though). But it kind of makes sense that a python script takes longer, needs to load after all.

Yes, basically my use case for the Clockwork Time nodes is to find bottlenecks in slow larger graphs (i.e. identify those portions that take up large amounts of processing time) and that would necessitate setting up the Time nodes in a consecutive sequence. For direct comparison of different methods to solve a particular problem (once it’s identified) I then create separate graphs of the different solutions for that problem and refer to the overall execution time in the console.