Rule-based design, can grasshopper do it?

Can grasshopper allow me to do things like draw an architectural beam, and then have a rule saying you can't put a light fixture within a certain distance of it, like 2 feet?

For my profession, there is a lot of technical rule books that don't allow you to place certain things like lights, plumbing pipes, ceiling objects like fans and heating ducts too close to eachother and stuff. It would be really helpful if I could 'program' rules into a 3d building model so that I couldn't violate the technical rule books. Can grasshopper do anything like this?

Replies to This Discussion

Permalink Reply by Luke W on May 19, 2012 at 6:11am

Thanks for the reply Luis,
now that it's pretty much confirmed to be theoretically possible in GH to do, just as it is theoretically possible to do in VB or python etc, I just have to figure out if my brain can 'see' the solutions given enough studying :)
hopefully GH is a ton easier than bare languages because I only have a 2 year timeframe

Permalink Reply by dominic on August 18, 2012 at 6:19am

Rules based design has a long history.... that precedes the script approach that GH et al takes.

You may want to look at Designpower's Design++ framework... http://dp.com

Your piping design example sounds similar to what Design++ enables for Bentley's Plantwise app... http://www.bentley.com/en-GB/Products/PlantWise/Product-Overview.htm

The rules engine is pretty fast. Design++ is based on a lot of 'old' KBE tools that were initiated in early AI research, based on LISP. It uses a 'frame-based knowledge representation' to define BIM objects, using 'production rules' that are based on simple 'if-then' expressions/functions that are stored in 'slots' that can be nested.

Its simple geometric manipulation functions are based on configuring or assembling elements: 'below', 'above', in-front' etc which is a little different to the 'richer' and more generative approach that GH takes.

OTOH, this assembly approach is part of the 'rules' or 'relations' way of defining an assembly. GH et al approach falls down a lot in situations because the whole assembly is strictly defined as part of a Directed Acyclic Graph. This makes making changes that 'flows upstream' - something that is pretty common in everyday engineering / BIM practice- easier, compared to GH et al.

Design++'s approach to defining BIM objects also have common roots to the next step for IFC... which includes IFD data dictionaries etc which are always defined using a rules based language framework. I suppose, at some point, you would be able to read an IFC model, and there would be rules associated with the piping, vessels, nozzles etc that the rule engine can read, so that when you move a valve or vessel, the related piping would be able to 'generatively' re-route themselves by doing a 'solution space' search around those other trades, based on pre-defined clearance or separation 'rules'.

Or, you could move the pipe, and get the valves and vessels to follow. This would be problematic in GH, as the changes would be going 'upstream' wrt the DAG/script, in all the cases that haven't been 'hard-coded' in the DAG.