Better lofting

Hej, How can I loft better these two surfaces so I get one singular volume?

I am trying to get a good volume because I need to split it up later.

Attachments:

PARAMETRIC BUILDING.gh, 35 KB

Replies to This Discussion

Permalink Reply by Daniel González Abalde on March 11, 2016 at 7:41am

Make the loft with the boundary curves of the Patch surfaces, instead of the input Patch curves. They are not the same, the Patch is not an accuracy method.

Permalink Reply by peter fotiadis on March 11, 2016 at 10:00am

Well ... I have good, bad and ugly news:

Good: I have exactly this as training material for my people (part of my take-no-prisoners anti-Blob crusade [no mercy]). In fact it deals with how to invite a Patch thingy to a closed Brep party ... (using some stuff that is not available as native component).

Bad: It's not a cluster.

Ugly: See note related with the boolean toggle

WARNING: This contains the ParisHiltonPinkVirusN666 > if you change the pink hue on that ugly blob > Armageddon.

best, Lord of Darkness

Attachments:

The_Dark_Side_V1.gh, 123 KB

Permalink Reply by peter fotiadis on March 11, 2016 at 11:59pm

Added some omitted return clauses.

Attachments:

The_Dark_Side_V1A.gh, 124 KB

Permalink Reply by Arturo De La Fuente on March 11, 2016 at 12:21pm

This is another solution.

Attachments:

PARAMETRICBUILDING.gh, 42 KB

Permalink Reply by Nik Willmore on March 12, 2016 at 6:47am

The Grasshopper Solid Union component fails to invoke a normal Rhinocommon MakeBooleanUnion command so cannot accept simple overlapping surfaces like the Rhino BooleanUnion command can, but a two line Python script will do that for you and then you merely need to not trim your patches and also extend your lofted surface beyond the source curves, so the loft and the patches really overlap. This extremely fast too compared to manually splitting things in Grasshopper via intersection curves, teasing out the right list items and joining, and even then the intersection curves are actually not high tolerance enough minus any tolerance options, to work to split right and afford a closed solid!

Attachments:

Boolean-Union-Rhinocommon-TEMP.jpg, 96 KB

Permalink Reply by peter fotiadis on March 12, 2016 at 11:17am

BTW: If you want to do this

in one go (Break: just image a far more complex case, say with 10 surfaces engulfing some space: what are you going to do? you tell me) ...

... just do that (surfaces "extended" a bit and/or underlying surfaces used etc etc)

and then use this Brep.CreateSolid Method:

Permalink Reply by Stefania Dinea on March 12, 2016 at 12:38pm

Thanks guys, I will check all of them out - I am sure they are all very educational and I appreciate all the options you gave me. :D ...

I managed to do this - see minivideo - https://www.instagram.com/p/BC0SxfXN4TV/

and see how the shape affects energy consumption per year. (concept stage energy analysis)

Permalink Reply by Nik Willmore on March 12, 2016 at 4:28pm

I see, I can indeed directly replace CreateBooleanUnion with CreateSolid in my script above but CreateSolid takes 30% more time, 115ms vs. 87ms, which matters for using real time sliders.

Permalink Reply by peter fotiadis on March 12, 2016 at 11:26pm

Indeed but it's a good thing to have this in mind especially if there's many surfaces involved.

BTW: what about a Xeon E5 1630 V3 (avoid the zillion cores rabbit hole: pointless) in a decent LGA 2011-3 X99 chipset mobo? (avoid Asus X99 Deluxe: too many unresolved issues). Add DDR4 ECC memory and off you go.

Permalink Reply by Nik Willmore on March 13, 2016 at 1:53am

But to upgrade from my 2.6Ghz to 3.7Ghz is a mere 30% boost, whereas doubling to 8 cores would be 200% for Photoshop and Python parallel processing of slow Grasshopper steps. I already have memory with heat sinks on it and a good motherboard with durable capacitors (goodbye Dell forever), so I don't imagine memory is often a bottleneck.

Is there much parallel capacity in the latest Rhino 6 I wonder? I doubt it. How about Grasshopper 2?

Parallel processing is particularly easy in Python, only a single function and a call to a parallel use of it. And boy does it work well! 100% CPU use without bogging down my browser use as I wait.

Permalink Reply by peter fotiadis on March 13, 2016 at 2:26am

Ghz means nothing (or "nothing" to be accurate). It's "like" saying that you ride your bike at 9000 rpm whilst ... well ... speed (i.e. gear used and torque available) and not engine revolutions are the point of interest.

Anyway ... find a friend with a similar Xeon (he must know how to "tune" mobo BIOS as well) and see things that you merely could believe. Additionally for large CAD stuff worked over a long period of time (by many)... ECC memory is solid gold.

// may be the holly grail ... but in complex cases ... without a scheduler ... is like tuning a Harley Davidson (avoid at any cost).

BTW: what is your main personal system? what brain? what mobo?

Permalink Reply by Nik Willmore on March 13, 2016 at 12:05pm

KEYBOARD: classic Califone, not the new flat ones, found by the case on Ebay, can handle minor beer spills and homicidally angry pounding during Grasshopper sessions.

VIDEO: NVIDIA Quadro K4000 3GB.

MONITOR: LaCie 324i.

CPU: Intel i7 920 2.67GHz 4-core (fake 8-core in Windows Activity Monitor).

MEMORY: 24GB Latency: 9-9-9-24-2N G.SKILL Ripjaws X Series DDR3 SDRAM.

MOTHERBOARD: EVGA X58.

CPU COOLER: Zalman.

CASE: lots of big fans, SilverStone Fortress.

MOUSE A: vintage Microsoft Trackball Explorer with steel support balls replaced by Ebay-purchased ruby balls.

MOUSE B: 3DConnexion Space Navigator.

MOUSE C: Geomagic Omini-Touch.

But I still only have super-fast hard drives (Velociraptors) instead of SSDs since I've been too scared to have to reinstall my OS to upgrade, since so much of my support software is not listed in some spreadsheet, but just sits there and works a year later when I need it.