A very strange PLine (actually a Tube on it)

Replies to This Discussion

Permalink Reply by peter fotiadis on January 30, 2012 at 8:01am

Here's a Rhino file that (just) can be posted here - all components included (minus some really complex WIP stuff).

It's interesting to note:

1. We have 3 kind of goals here (a) the "hangar" (actually is a exhibition building) generic outline (easy with GH), (b) real nested parametric part inclusion in the definition (hmm), (c) a GH ability to bake structured geometry to Rhino...and then Rhino (acting as a "companion" app to a given AEC app + FE analysis + cost analysis + ...) export properly structured data. 

2. "Whole" and "Detail" here are tightly related : there's no meaning to promote an "idea" without solving the nuts and bolts of it. This is the so called "bottom-to-top" design mentality.

It's a mystery to me why GH doesn't include, say, some ways to control bake on a per block basis (actually on a per nested block basis).

 

Attachments:

• GenComponents-for-Rhino-TR12B2.zip, 4.7 MB

Permalink Reply by RWNB on January 30, 2012 at 8:25am

hi peter,

the pictures make curious for more.

is it possible to see more of the project?

thanks

Permalink Reply by peter fotiadis on January 30, 2012 at 10:32am

Sure as far ...er... I have some stuff more. I expect the GH part to be ready in 10-15 days (read the reason of delay below).

You know..the problem with me is that I can't proceed designing something/anything if I don't know how exactly the bits are. This means that 2 groups do "inverse" stuff at the same time: one does top-to-bottom and the other bottom-to-top (hence 1:1 3d details, so to speak, at conceptual stage). Then either the concept has a future or the bits prove that is very expensive or problematic or stupid or just academic. Cost of course in this case means e-mailing 3d data (usually STEP) related mostly with custom parts to various manufacturers and wait for some kind of brief approximation.

In general, in this case, the biggest problem (truss span : ~ 80/70m) is a successful planar glazing facade system (obviously custom: no need to pay 1K/m2 for something that actually costs 1/3 of that price max).

Permalink Reply by RWNB on January 30, 2012 at 11:12am

hi peter,

many thanks for another picture.
i'm looking forward to more. :-)

thanks!

Permalink Reply by Jon Mirtschin on January 30, 2012 at 1:57pm

Hi Peter,

I think the cause of your problem here is the rhino document tolerance.  For Architectural/Engineering modelling, I'd advise tightening the Rhino defaults using the options as per this screen shot.  I haven't quite had success with the pipe command (if you bake the polyline in Rhino and run the rhino command it works with the tolerance values as shown) but I do get a single brep with sweep (I used the SDR version, but Grasshopper sweep should be similar).  You can save better tolerance values into your templates so that you don't need to set them each time you start a new document.

Hope it helps in some way,

Jon

Attachments:

• TRUSSTRIANGLESURF2 sdr.gh, 215 KB

Permalink Reply by peter fotiadis on January 31, 2012 at 3:59am

Hi Jon

What's up?

VBI (Very Big Ideas) section: Why not take GH into the next stage by doing some wonder stuff that could put these components into place? (I mean the truss related weird "things" posted already). Why not doing some "structure" (i.e assembly/component) related tools that could "classify" GH baked things into nested blocks...that...er...could been exported,say, to Microstation/CATIA/NX as 3d Shared Cells/Components? (the rest could be history, he he).

That way GH/Rhino could be considered as viable "companion" apps to the big AEC boys (because intelligence without proper structures = nothing). I add CATIA to AEC segment due to the Plant market segment.

VBN (Very Bad News) section: Er...the higher the tolerance the less pipe is shown: for instance NO bottom pipe any more (meaning that God - Himself - definitely doesn't approve PLines/Pipes on these ugly trusses of mine , simple as that). But the good news are that your stuff works (but one needs segments here - kinda like a straight Loft). Anyway this truss (in modular version) is already near-by completion - I'll post great(????) things(?) soon(???).

Next Project : Marry Caroline of Monaco (or something equivalent) > quit this $##%##^ business > ride NCR Ducatis (in pink) and some Ferrari Italia (in purple).

Be The Force (dark option) with us

Permalink Reply by Jon Mirtschin on January 31, 2012 at 5:37am

Hi Peter,

I'm well, hope you are too.

I'm sure you've seen from my blog and our discussions, my VBI is akin to yours.  However it's a balance of keeping a freehand for formulating designs, but conforming to standards and practical aspects of efficient fabrication etc.  Nested blocks etc is pretty adequately defined in STEP, which is what IFC is based and derived from.  The trouble really is getting the other AEC software to acknowledge IFC models (that are more than primitive coordination models).  This takes time, and as you've seen, I've started developing the importer for the receiving software (Revit at this stage).  If demand exists and time permits, I'll consider other software to follow.  I just haven't encountered enough interest yet from any of the software you mention to consider it a higher priority.  I also acknowledge my IFC tools are still very much in progress, but priority for development is given to projects requiring particular functionality.

The geometric issue you're encountering is different.  Every CAD system operates to a tolerance at some level (due to binary computers vs decimal human number systems) even if it is hidden from the user.  My tools (like grasshopper) adopt this tolerance from Rhino again giving the user the ability to control aspects (such as fabrication tolerances etc).  Be careful, there's always confusion with higher/lower tolerance values, I'd prefer to use terms looser or stricter.  If you raise (relax) the tolerance, I expect the pipe to be less successful (are you modelling something 50metres long to a micromillimetre tolerance etc).  This effects various steps in formulating a sweep or a pipe function.

Again the designer has the knowledge or decisions to make if a curved member is actually curved, or broken into linear segments with miter ends at connections etc.  With IFC you can nominate cutPlanes (half spaced solids) etc, not exactly trivial at this stage but possible.  If this information is required for fabrication etc, best to set the GH definition up this way.  If you're visualizing only, sweeping/piping the polyline will give the effect (but be difficult to use downstream in any subsequent software).

I'm sure I'm not really enlightening you on much here, but my 2c anyway.  Say hi to Caroline (or any equivalents) when you next see her for me.  

Permalink Reply by peter fotiadis on January 31, 2012 at 7:12am

Hi again Jon

Serious things first : with regard the Caroline thing (or equivalent) I'm working on it.

Trivial stuff follows : indeed there's no demand (at present time) for "structured" GH output. Correction: there's no visible demand. Explanation: a lot of AEC oriented people (Smart Geo daydreamers) they think - potentially - about GH but they are rejecting it for more than obvious reasons: our job is 1% about the smart thing and 99% about the structured aspect of the smart (or stupid thing).

Back to that "hangar" : The primary role of this GH definition provided herein (and hopefully some future updates) is NOT to outline some academic solution (via some abstract collection of pipes/lines/points/surfaces) ...but to place in 3d space - properly structured -  all the real-life (hmm, he he) bits that can compose the actual project. Of course if the bits could be parametrically driven assemblies  ...well...you get the gist of the message.

All in all: I think that Engineers who are GH skeptics could see GH with a totally new perspective if, say, a collection of similar examples/test cases could be available for demo/evaluation/whatever > Ah! at last : this appears to be a real thing > what software did it? > say it again - Grass Components you said? > what sort of name is this?  ... etc etc etc.

But since a similar development is quite expensive (and requires a team of several gurus), maybe this is rather a future potential task for the GH/Rhino people if they think that the AEC market segment could be beneficial for their products. Combine a similar capability with tools like yours and/or Evolute (planar quads are "a-la-mode" these days).

PS: forget trivial stuff > what about Stefanie? (plan B : better something than nothing)

Permalink Reply by peter fotiadis on January 31, 2012 at 11:22am

Did some dark PDF (crude faceting due to file size limit - 5mb) in order to focus...er...hmm...to the core of the matter, Plan A that is, he he (but you can alter display styles and lights at will in Reader).

In the mean time I do sarcastic comments/notes to my people - in order to make some more stupid "3d bits" for that thing.

I'll post soon the mother of all trusses - forget tubes > custom sheet metal, SS 316L cables and other useful (???) stuff.

He He

Attachments:

• TEST-TRUSS1-MASTER-015A.pdf, 3.8 MB

Permalink Reply by RWNB on February 4, 2012 at 4:35am

many thanks for the interesting information!

it would interest me,
how you have solved the design of the bearing of the truss,
and the connection of the truss to the facade?

thanks in advance

Permalink Reply by peter fotiadis on February 4, 2012 at 6:20am

Well,

1. "solved" is highly optimistic (for the current design phase) ... in fact "outline a potential solution out of many" is the correct word.

2. For "bottom-to-top" things (always I do/we do things both ways) I use CATIA, NX and Microstation. Due to the parametric approach Microstation is the only combo that "does-it-all" (that's highly optimistic).

3. Planar glazing details (i.e. the facade) are not designed yet (but it's very easy to do it provided that you know the hidden issues related with suspended glazing systems).

Depending upon the potential issues that I could encounter (kinda the Planar GH component chaos explained already) I'll post various definition updates as soon as they are ready.

That said, I insist that there's a great potential for GH in the AEC market - if and when suitable methods and tools could be available.

Permalink Reply by peter fotiadis on February 3, 2012 at 10:54am

UPDATE:

Worked a bit further on that truss thing.

I have bad, bad and bad news:

1. You may wonder why I use this "cut and paste" crude method for creating the 3 main support trusses. Sure there's far more elaborated ways to make a definition, don't you agree? But never say never, he he.

2. Well...here's an explanation (more strange cases to follow) :

(a) Imagine 3 identical sets of data (in this case the main tube lines > truss is Modular by now, but this is user controlled). Say truss1, truss2, truss3. Structure of data is 100% correct - see, for instance - the secondary/diagonal truss items that are 100% correct.

(b) Imagine EXACTLY the same portion of code applied in the 3 sets as above (er...the "cut and paste" crude thing).

(c) It works...er...in 2 out of 3 cases > see notes (and Saved View) about where the problem is: appears that for some reason (that I can't imagine) GH fails - when working with the truss1 data, i.e 72 lines that belong to 3 branches each having 24 items - to create "properly" 3 branches of data.

(d) Data (the module connecting flanges/profiles for Loft etc etc) are collected "randomly" thus the Loft fails, the "grouping" per truss segment fails .. and in general chaos is the name of the game. But only in the truss1 case (is this an Omen of some sort?).

NOTE: Tree8 is used (but the cluster alternative fails as well, so it's not a Tree8 issue).

Compare EXACTLY the same thing working perfectly with the 2 other trusses

Morel1: Karma, what else?

Moral2: Path to glory is long (and hilly).

Attachments:

• TRUSS-TRIANGLE-SURF4.3dm, 32 KB
• TRUSS-TRIANGLE-SURF4.gh, 557 KB

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page