oto )
I tried so many different ways but none worked !i need 3 layers, each layer has a different number of points, so there will be different size of holes. ( I think I've reached this point )I used a pop2d -> 2D Voronoi -> Scaled ( dist from curve ) but I want all three layers connected to each other, i tried also 3D Voronoi and the Voronax Plugin and none worked !I'm so confused :D
…
Added by Arian Sadafi at 3:59am on January 30, 2017
e in Euclidean space then the distance metric can be discontinuous:
Discontinuous means that a tiny change in input may result in a large change in output. Observe the image above, we start measuring euclidean distances from point A. At first the process appears to be continuous. We measure at distance b and we get point B. We increase the distance slightly to c and we get point C, which is very close to point B. We increase the distance slightly again to d, but now suddenly we're in a completely different location. This jumping behaviour can mean that certain questions (such as: "how do I divide this curve into 4 points, all equally far apart?") do not have an answer. It could be possible for 3 and 5, but not 4.
Another problem is that there may be multiple solutions. In the image above the point D isn't the only point that is d units away from A and coincident with the curve. There may be any number of those points depending on the shape of the curve, the location of A and the value of d. And of course once you have two (or more) solutions, you can have two (or more) answers. Then each of those solutions may yet again have more than one outcome for the next point in the chain and before you know it the question you asked has 35295 different answers and good luck trying to find one you like.
Now of course sometimes it is possible to answer your question unambiguously. I made a solution that uses Galapagos. It's pretty slow, and it'll get slower the more segments you want:
--
David Rutten
david@mcneel.com
Tirol, Austria…
Added by David Rutten at 4:26am on September 9, 2013
- C
{2;0} (N=61) - D
{2;1} (N=60) - E
{2;2} (N=61) - F
group 2:
{0;0} (N=10) - U
{0;1} (N=10) - V
{0;2} (N=10) - W
{0;3} (N=10) - X
{0;4} (N=10) - Y
{0;5} (N=10) - Z
the idea case is I can merge those date sets in a pattern of A-U-B-V-C-W-D-X-E-Y-F-Z...so on
therefore I am thinking how could I modify the path on group 2 and make them becomes things like:
{0;0} (N=10) - U
{0;1} (N=10) - V
{0;2} (N=10) - W
{1;0} (N=10) - X
{1;1} (N=10) - Y
{1;2} (N=10) - Z
but I have no idea how could I modify the path in that way....
can anyone show me how to?…
Added by Preston Chan at 8:34pm on October 26, 2010
ort and export from the images below and also from the HELP file of DB in attachments (Page 71: Importing Geometric Data; Page 78-80: Import 3 - D CAD Data). In their HELP file, they mention about "import geometric data".
However, regarding the input of schedules, loads, constructions and etc., DB normally uses "Component " and "Template" (Page 29: Templates And Components; Page 591: Templates; Page 533: Components). "Templates" are databases of typical generic data, including Activity templates, Construction templates, Glazing templates, Facade templates, HVAC templates, Location Templates, and etc. "Component " are databases of individual data items (e.g. a construction type, material, window pane).
Both "Component " and "Template" are allowed to be imported and exported by using "Import / Export library data" command (.ddf format - DB Database File; Page 734: Import Components/Templates, Export Components/Templates). DB also allows us to build up our own libraries of templates and components (Page 731: Library Management; Page 733: Template Library Management).
In order to import both geometric information and other information related to schedules, loads, constructions and etc. from GH to BD, we supposed the following two ways:
1. GH(HB+GB) --> gbXML (both geometric and "Component " and "Template" information) --> DB
This is the way we most prefer. We did see information related to schedules, loads, constructions encoded in the gbXML file generated by GB, but still do not know the reason why DB did not take this information (I also mentioned this in Q6 within the gh file). We assume this might because the gbXML file we create encodes the schedules based on a different template / schema than the one DB expects. We also post this question to the DB forum for help.
(http://www.designbuilder.co.uk/component/option,com_forum/Itemid,25/page,viewtopic/p,13755/#13755)
2. GH(HB+GB) --> gbXML (geometric information only) + .ddf ("Component " and "Template" information only) --> DB
If the first way doesn't work and DB only takes geometric information from the gbXML, then we might think of the other way - generating the .ddf files from GH(HB+GB) to pass the schedule, load and construction information to DB.
I was wondering if it is feasible for HB and GB to have this function? And what is your suggestion to achieve this?
In addition, we notice that DB can export XML files (not gbXML), so we are trying to figure out if DB also accepts / reads the XML file. If so, we might be able to convert the gbXML (with both geometric and schedule information) to XML. What do you think about that?
Thank you again for all your help!
Best,
Ding
DB import
DB export
Template libraries
Component libraries
…
ces, cats, dogs anything.
3. Pick some in 2 and write down some algorithm (rather impossible without code) that makes "random" tree - like columns that grow with some fractal logic and "end" to the grid points in 1. Take case about some "even distribution" (see step 4). Obviously columns are made by tubes welded on site (expensive + tricky) or modular via some MERO variant (cheaper but a bit ugly).
Break: in order to do WOW tree-columns you need quality code not a mesh (or a CRAY or even ... hmm ... HAL9000). Estimated CPU time for a random tree-like column with, say, 5-20 nodes: 0.001 milliseconds.
4. place I beams (or C or IPE or IPN) along a given direction (or both) using points in 1 and support them by the ends of the tree-columns. I would recommend ball-pivot joints for obvious reasons.
Now ... this ... (as I said: I'm a bit lost). I mean ... doing this in a large scale (as your initial image suggests) is rather out of question even in Dubai (prior the D-Day). Maybe out of question even in China (where billions are aplenty).…
g that there's clash issues related with the convex edges: the "inward" ones so to speak).
2. If we call the teeth that is contained inside the Face "inside" (Length as in D) and the other "outside" (shorter Length > make a sketch > trigonometry > etc) ... then there's no clash issues ("along" each teeth: i.e. "along" the initial donor edge direction) since the inside meats always the corresponding outside.
3. However there's clash issues related with the start/end portions of the polyline (due to offset).
4. There's also clash issues ("across" each teeth, i.e. perpendicular to the initial donor edge) .. meaning that the polyline must take into account all these constrains (at creation time ... or at "offset" time)).
Guru refused to dig into more details (God knows what he actually means with all the above). He only added that the trick is an ability to watch BOTH polylines (per adjacent Face) at once (rather easy for him).
Moral: a tipple espresso for me please. …
ies of reference boxes and using the Box Morph component.
So far I've had some success, as shown in the image. However a few things have cropped up (probably not helped by my limited GH skills!)
1- The morphed geometry isn't aligned. I have ensured the original points match point for point; I have a feeling the u&v directions might have swapped?
2- So far I have been splitting the complex geometry manually in Rhino and defining manually in GH, then matching reference box to target box one by one. This was more for the sake of expedience, and to see if it worked; however I feel there must be a better way of doing this. Maybe the reference boxes split the complex geometry, then test for any contained geometry (the 'Inside' component?)
3- I feel there might be a better (existing!) solution somewhere, as I can't be the first person to try this!
I've attached an image of what I'm trying to do + the definition. The .3dm file is 12MB, I can send it upon request :D
All help would be much appreciated, thanks…
the end.
Then optimize the WWR for one particular location for multiple objectives by using Octopus.In this case the objectives would be min energy use, lighting level of 500lux, solar gains, total radiation on the facade.While the glazing type is a fixed parameter that I am not planning to include.
Here the problem is as you commented on the other discussion (http://www.grasshopper3d.com/group/ladybug/forum/topics/idf-import-and-setepzonethresholds-issues?commentId=2985220%3AComment%3A1267045&xg_source=msg_com_gr_forum)
- How to weight all objectives properly? So I could get a .csv and present the results will pollination or in other graphs.
- How to do that in GH and Octopus?
- How would the iteration process go?Would there be a feedback process, where I have to go back and re run energy simulations ?(see image)Because of many objective I find it hard to design this workflow chart, and the definition.
I am a newbie, there are no tutorials online for Oct. and I find it very confusing.
I will see If I can do something with your file now.But if you have any idea that would accelerate my process of learning by doing, you would be a major time saver :D (you already are a live saver with HB and LB.)
Regards,
N
…
N, O}. In this case it's very obvious what needs to happen. You want to create lines combining the following points {AK, BL, CM, DN, EO}.
If the second set however only contains 3 points {K, L, M}, it is no longer obvious. The default behaviour for Components is to keep on matching points until both sets are depleted. This is called Longest List Matching. It will give you 5 lines, that connect the following points: {AK, BL, CM, DM, EM}. As you can see, the last point in the second list (M) has been 'recycled' three times.
You can also change the default data matching behaviour. For example if you change it to Shortest List, then the component will stop working as soon as the smallest set is depleted: {AK, BL, CM}. In this case the points D and E are completely ignored because no 'sibling' could be found for them in the second set.
A third option is Cross Reference matching, which will create all possible combinations: {AK, AL, AM, BK, BL, BM, CK, CL, CM, DK, DL, DM, EK, EL, EM}.
However the best solution in this particular case is not to muck about with the data matching, but instead Graft your data. Grafting means that all the items in a set are moved into their own little set. Thus, if you graft {A, B, C, D, E}, you actually end up with 5 sets, each containing a single item {A}, {B}, {C}, {D} & {E}. When you combine this new data layout with your second set {K, L, M}, each grafted item will be matched with all the items in the second set, this is after all how Longest List works. So you end up with a data layout that looks like this: {AK, AL, AM}, {BK, BL, BM}, {CK, CL, CM}, {DK, DL, DM} & {EK, EL, EM}, which is very similar to the Cross Reference matching, but retains more of the original layout. I.e., it's not just a huge list of all the lines, they are still five groups of three items each, which is a far more informative layout than Cross Reference would generate.
I'm afraid at this time of night this is the best I can explain it.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…