basis).
2. Rhino does not have a proper object display capability (objects per layer per view basis and/or per "collections" per view).
3. TSplines does NOT have any on-the-fly coordinate system definition capability (making "edit" a pointless waste of time). A small example about what this means as regards view navigation matters: imagine "hoovering" along a myriad of 3d objects: if you choose/opt for it: the moment that you touch an element (that could define a vector): this instantly becomes the working plane Z axis (very common capability in top MCAD apps). Not the same as a SpaceNavigator controller mind (far from it).
If these 3 were available > rebuilding anything with TSplines could be a joy (and very fast: about 2 minutes for your mesh)
Get this as well - Load Rhino file first attached in my previous reply (just for fun: not for your case, but we could do an extra WOW MERO spaceframe out of this paranoid M mesh).
BTW: Exo W is "tricky"…
chitecture for quite a while. I've been through all versions of 3DS Max and I've used Maya and Softimage as well. In the last 3 years though, I started using the 3D apps as an architectural design tool, but you must already know that this it not the main purpose of them.
That's when a friend of mine introduced me to GH and I was blown away by it. This is like THE perfect thing for design. I'm currently designing a high-rise for a city here in China where I live and it has a very intricate twisting, thus I took the leap and started learning GH, but I think they time it'll take me to learn it will far exceed the time of this deadline so I did the whole model in 3Ds Max, but it was a real pain in the ass moving every individual row of vertices manually, and leading myself but nothing but rudimentary techniques to make it look right, and still, it doesn't look as I want and when having to modify it, it's just another full exhausting day at work.
Anyway, that's briefly the reason. I'm hoping to learn a lot from here. If you have any essential sources (preferably updated) from where I can push my knowledge do let me know please!
Thanks!!…
priety software). Think Kangaroo with RON 100 fuel (add some nitrous oxide).
Back to domes.
1. Obviously you know the free WinDome Bono thing...but anyway get it (code included).
2. As I said on another thread (http://www.grasshopper3d.com/forum/topics/the-necessity-for-a-data-tree-manager) ... the big thing in AEC (because, for instance, nobody does domes for decoration/artistic stuff etc etc) is how to implement already designed things (see images above) within a smart stuff definition (or many).
3. Goes several steps beyond: these "breps" (to speak GH/Rhino language) are in most cases nested and some parts are "locked" for transformations some other not. That's the big thing when trying to outline real-life AEC solutions in the so called Smart applications. I think that this is not doable in Rhino since there's no way to edit (in place) a nested block.
4. Goes even further: for each custom made thing (truss nodes and the likes) ... there's a bill waiting. Meaning that the less customized a solution is (with regard industrial sourced existed parts) the more is possible for the client to sign the dotted line.
Best, Peter…
subsequently able to retain a higher level of flexibility.
In Rhino however a rectangle is defined as only a plane and two numeric intervals (one for x, one for y). The possible solutions to this would be:
Extend the Rhino SDK Rectangle3d type to include constant radius fillet corners. This can be done, but is a lot of work and will break the SDK.
Create a new type in Grasshopper which is smarter than Rectangle3d. This complicates developing for Grasshopper because now you have to keep two different types in mind whereas before only one was needed.
Remove the Fillet Radius input from Rectangle components. I like this solution because it results in cleaner, simpler code, but it does mean people may need to use two components where before one was sufficient.
Make the Rectangle type smart enough so that it can recognise filleted rectangles and undo the filleting. This is something I can do right now for Grasshopper 1.0 and it in all likelihood would not break actual existing files even though it is technically a behavioural change.
I'll try and get (4) done for Rhino 6 SR1, I might decide to do (3) for Grasshopper 2.0. I sincerely doubt that (1) will ever get done and I dislike (2).…
Added by David Rutten at 4:38am on November 6, 2017
ion of surfaces and/or "solids" : it's a very complex assembly of "components" either bespoke or widely available in the market. This demo combo summarizes the "common" cases (but the insulation for the opaque parts is WRONG 100%):
2. Contemporary trends (a bit of nonsense) point towards "liquid" forms. These ARE NOT made via "classic" linear systems. Very few actually can do it (I mean: do it yielding a building that doesn't leak]). Here's a totally wrong take on that matter from a very reputable Swiss facade maker:
And er ... hmm ... this :
3. Facade systems (curtain walls, that is) are classified in 4 classes: (a) the good old known humble stuff like the one shown in the first image (b) semi structural [yes], (c) structural [NO] and (d) planar frame-less systems.
4. Designing any proper facade is impossible with Rhino/GH: you'll need totally different software apps to do it - in real life - despite what most people believe/hope/wish.
5. Designing anything without a proper bottom-top approach (I.e. : first do the pistons then the engine) is the best recipe for not becoming (ever) a pro .…
on) ... the only way to do something meaningful/realistic is to follow Bentley System's way: they had 3 rendering engines (all highly problematic and archaic), a bunch of highly paid "gurus" to "develop" the dead fish and an export to Maxwell capability as well (Maxwell is very slow and has no chance VS Nexus, see below). PS: "Gurus" had no idea about Quest3D and the likes.
At the time, I was near to some permanent ban (he he) from all Bentley Forums due to my acid writings about how stupid these methods were. In fact I openly proposed to Bentley (to Ray Bentley to be exact) to fire all "gurus" involved ... and follow the outsource path.
Finally Ray (he's very smart) did the right thing: after an agreement with Luxology ... now Microstation (the core product) uses the Nexus engine (as found in Modo). This means that the Nexus is fully integrated across the whole vertical suite of BIM AEC Bentley apps the likes of AECOSim (that includes Generative Components as well).
And as everyone knows THIS is the real McCoy (US movie industry is behind that thing).
Additionally Modo has the best GUI known to mankind (US movie ... blah blah) and astonishingly innovative thinking (US movie ... blah blah).
…
quite know where I'm going wrong. I can say that I have successfully put together a separate file which will send data directly to the Arduino (switch on a boolean toggle and watch an LED light up... how fun:) but receiving the data is a bit more complicated. For a long time, I was getting a continuous loop error, which would freeze my app. I've changed around the code (see attached file), but I'm still not receiving any data from my COM port (which I know is definitely working because I can turn on the Serial Monitor from the Arduino IDE and see the data coming in). I did have one question: Can you call different routines inside the script class (from Grasshopper), or do you have to always call the run script subroutine? If you guys have any suggestions I would greatly appreciate it. I understand it's a bit tricky to trouble shoot this issue since you may or may not have an Arduino handy to stream the data to your computer... but let me know if you see any glaring issues with the code.
Cheers,
Andy…
le] demo):
1. A transformation Matrix is a 4*4 collection of 16 values that "deform" 3d things according the values in the cells. The orthodox way is to deploy "cells" left to right and top to bottom. Rhino does the opposite (why?) hence we need the transpose method.
2. Since "translate" and "perspective" are "symmetrical" the transpose boolean toggle (within the C#) "flips" rows with columns ... so we get perspective or move.
3. When in perspective "mode" the vanishing points are computed internally within a min/max limit (per X/Y/Z axis) thus avoiding the usual havoc with "extreme" perspective angles (very common "glitz" in pretty much every CAD app - CATIA excluded). Vanishing points (and limits) are oriented with respect the pos/neg value of a given control slider.
Note: slider values are percentages between min/max (mode: perspective) and/or actual values*100 (mode: move).
4.In order to start mastering the whole thing: don't change anything: just play with these 4 sliders selected:
5. The 123 sardine cans challenge: even with DeusExMachine = true (see inside C#: that one redirects the transformation per BrepFace and then joins the breps instead of applying it on a brep basis)... odd things (and/or invalid breps) occur ... thus what is required in order to make things working 100% ??.
he, he
best, Lord of Darkness …