r this example, but presumably you would have this data in some sort of spreadsheet that you could substitute here.
All the springs are trying to reach a target length of 10 units - simply minimising the distance would result in all the points becoming coincident, but you could alternatively also include a 'ClampLength' goal to keep some minimum distance between all points and then set the target length of the connections to 0.
You'll need the latest Kangaroo to open this definition.…
Added by Daniel Piker at 8:21am on August 22, 2017
ee. That said these things (masterminded by a certain David R) are not bad at all ... but if you write code that is "supposedly" transferable (kinda) to other CAD apps ... well ... I would strongly recommend the other classic nested C# collections.
2. The HLP method is one out of many: for instance for a better approximation of the required fitted plane we can use the divide Curve method etc etc.
3. GH components use (in most of cases) methods exposed in Rhino SDK > get the thingy and start digging into the rabbit hole. Of course David did some other components as well that use "less" classic SDK methods (if at all).
4. HLP is a classic approach to count the beans in nurbs curves. Of course I could use PolyCurves and recursive explosion blah, blah ... but here we are not after segments (at least at present time). On the other hand if that was a Faceted Dome (planar Polylines) ... well getting the nodes that way it could be an overkill (this means business for V2).
5. Mastermind some plane orientation policies in order to finish(?) the @$%@$ thing. For instance: Given Plane plane, define a Plane.WorldXY at plane.Origin and section these 2 > then get the cross product (sectionVector, plane.ZAxis) for the new orientedPlane Y axis etc etc (this presupposes that any plane Z axis points "outwards": use Dot Product and a center point as apex etc etc).…
s for some solution "as it is" no matter the cost? (that's an extra stupid approach, very old fashioned). Do you use EvoluteTools Pro and/or Kangaroo for "optimization" ?
2. What is the FEA/FIM stuff in use? Do you expect "from/back" interactions? (If this is not doable ... increase this or that etc etc).
3. Do you validate real-life components with FEA/FIM? By what means you design these components? - present and/or future (inside Rhino?). This makes things "interesting" in a variety of ways (we need to extensively talk about that - Skype). The problem is that Rhino IS NOT a feature driven solid modeling app and thus ... a "certain" bottleneck arrives in no time: In the CATIA world you design ("MANUALLY") a parametric history driven component that "complies" to his parent "directives" (say: the Topology) and/or "imposes" his rules to his parent. This is what we call top<>bottom design approach (would become a standard across the AEC industry pretty soon: in around 123 years give or take some). This is far and beyond from what Rhino can do - but we DO make real-life things don't we?
4. Are all these things under a BIM umbrella ? What BIM? What type of details (blue prints) you deliver? (or you just make the thing?).
5. By what means cost is restricting/encouraging the solution? By what means you get feedback from component(s) cost that is outsourced? (i.e. outside your company). Do you monitor all things via some RDBMS? (that's Data Base).
6. What are the long term plans for dealing with such solutions? Using what apps (even in theory for the moment).…
i want to draw a line between them. The first point called FisrtPt is a fixed point from RHINO but the second point called SecondPt is the point which i want to be able to get its data from the UI.)…
mations we use a STANDARD thingy (Plane.WorldXY) VS any other plane (that's what the Orient does). This applies for blocks/cats/dogs/anything: meaning that if anyone in the present or the future uses such a "component" he knows the origin (especially if other CAD apps are used in parallel).
2. NEVER EVER make a thing (i.e. the profile) to be oriented "off center" (in the occasion domain start/end values for x/y). If you want to do that treat the destination plane accordingly. That way you build up a mentality were the "source" is standard - so to speak.
3. RHS (but HEB/HEA/IPN/IPE blah, blah) fillets are related with thickness (in real-life) ... therefore when you offset (always inwards: meaning neg values for counter clock wise closed curves) ... take into consideration that simple fact.
…
r even a geometry.
We want to develop open source architecture, and be able to reuse easily open source elements of projects shared by the community.
We are interested to display the 3D files in the browser, thanks to connection with external services like http://beta.speckle.xyz or others though at the moment it is not yet available.
When I discovered the grasshoper forum, I liked the fact that people talk very openly about their modelling problems and share definition files...
But I think Bricks could be a complementary publication mode, to find in a glance an element with all its geometry and a link back to the forum post to join the discussion.
Indeed when I work as an architect, I have not always the time to browse a forum with all its discussions to find a suitable element for my project.
I've quickly reposted 2-3 forums posts to test it out.
I would love to have your feedbacks on this new way of publishing grasshoper definition files and more globally 3d reusable geometries.
Here you can see a single definition or the list of definitions that can be classified at the left thanks to custom categories.
If you create an account and upload a few definitions and 3d images and files, you could also tell us, what you think of this process.
Sébastien
www.twitter.com/sebastien_lucas…
console app into "Rhino\System\" directory the program runs fine. I've searched for days regarding the loading of dll's but to no avail. Could it be that the Rhino dll's are protected in the program files directory? The code is very simple, please take a look.
using Rhino.Geometry;using System;using System.Collections.Generic;using System.Text;namespace Rhino{ class Program { static void Main(string[] args) { Point3d j = new Point3d(1, 1, 1); Point3d k = new Point3d(2, 2, 2); List<Point3d> list = new List<Point3d>(); list.Add(j); list.Add(k); Console.WriteLine(new List<Point3d>{j,k}); Point3d p = Point3d.Add(j, k); Console.WriteLine(Point3d.ArePointsCoplanar(list, 1.0)); Console.Read(); } }}
…
that "all-in-one" thing. Some people believe that this is not a big deal (I guess that they have no real-life experience from AEC studies). GC is s l o w, has more bugs than Sahara has grains of sand, and Robert Aish - the equivalent of David Rutten - had escaped to Autodesk (did the Dynamo since). GC is either stand-alone (+ Microstation) or a MS add-on. GC has a very steep learning curve. GC works on a "sequential" mode that is far better suited for engineering purposes. Microtation includes the best solid (NOT surface) engine known to mankind (same as Siemens/NX). Microstation also includes the best rendering engine (straight from the US movie industry: the notorious Nexus engine). Microstation has a lot of bugs.
GH: fast, vibrant community, fast becoming the standard for entry-level parametric adventures (not AEC), evolving 10 times faster than GC. But ... Rhino is NOT an AEC app nor it would ever be not to mention that surface modelling thingy, the non existent feature modelling capabilities and ... er... hmm ... MIA assembly/component capabilities as well.
For some MS+GC+... normal (and abnormal) adventures: https://www.behance.net/peterfotiadis
PS: post some real-life case (GH <> AECOSim) in MS native format (.dgn).…
You can create Design Options using the Iris Layer component!
For each set of geometries that you create, you can assign a layer and define whether it will be visible or not in Virtual Reality on the
Added by IrisVR to IrisVR at 8:34am on January 23, 2017