Circle Packing
Hello I have been trying to do circle packing in grasshopper for a few days now and i have had no luck. I would want to manually plot a few random points in an area(site). After which would want to move these points closer to each other depending on the radii of each which is controlled by a slider.And then when they are in the required distances from each other i would want to atlast draw a circles that are tangent to each because of the position of the points. I'am new to grasshopper and tried looing at some old threads on circle packing,but they seemed too random. Shankar
Circle Packing
Hello I have been trying to do circle packing in grasshopper for a few days now and i have had no luck. I would want to manually plot a few random points in an area(site). After which would want to move these points closer to each other depending on the radii of each which is controlled by a slider.And then when they are in the required distances from each other i would want to atlast draw a circles that are tangent to each because of the position of the points. I'am new to grasshopper and tried looing at some old threads on circle packing,but they seemed too random. Shankar
Re: Circle Packing
Hi Shankar, Have a look at this blog. http://tobesch.wordpress.com/2008/11/06/circle-packing-with-grasshopper/ regards Evert
Re: Create set of branches from list
Farley, The problem you stated here is very common and I had posted a similar query a while ago. I hope this helps: http://grasshopper3d.googlegroups.com/web/CreatingATreeFromALinearList.jpg?gda=KpI7AVIAAACHnAhpAbFiwGExyoDUnoJs0PvyBAWTWdDzIM1VCF7qYxRegwydofvQiE-vsu83P2Jm9xVh6z2fmU2jvRHjnG4rVeLt2muIgCMmECKmxvZ2j4IeqPHHCwbz-gobneSjMyE From what I can make from your diagram, it seems like you were always using a single button... when you use two, it inevitably creates a tree... and then its just a matter of tweaking the values until it works your way. Just incase you want to avoid the VB route :) S:C
Re: No Multithreading?? :(
Thanks for the info Bob. I didn't realize that you guys had started using OpenMP. Although in most cases, rewriting some of those chunks of code to allow for multithreading might not really offer too much added benefit, I think there are still other places where smaller changes to allow for multithreading could be added. A simple example is something like meshing. If we're meshing more than one object why can't we have each object potentially meshed in its own thread? I think solving fairly basic multithreaded situations like that might be a good place to start and one where there is certainly a good deal of added benefit. Just my two cents from a guy who's not looking at the code and couldn't write it myself ;) Best, Damien On May 14, 12:52 am, Bob McNeel bob.mcn...@gmail.com wrote: The details are not simple... to get your head into the problem, start by reading this article... all of it, along with the discussion. http://www.technologyreview.com/multicore Multicore programming is generally require a major rewrite of big chunks of code. Often for very little improvement. Of course there are exceptions, like raytracing which is already parallelized in most applications include Rhino and Flamingo. There are tools to help. One example is OpenMP. We are using OpenMP in Rhino 5, but my guess is that in most cases where OpenMP helps Rhino is already so fast you won't be able to tell the difference very often. To get your head deep into the topic, pick up a copy of Using OpenMP from MIT Press. On May 13, 8:48 pm, damien_alomar dominos...@gmail.com wrote: I'm not sure what you're hopes were based on, but AFAIK there are no multithreading additions for v5 or Grasshopper. Doesn't really matter what kind of system you have as its something that requires the attention of the Rhino developers and David. Last I asked (many months ago), David said that he attempted to try out some multithreading with GH, but had a lot of problems managing threads and a number of issues with some SDK functions not being thread safe. Unfortunately the response from McNeel on multithreading has been practically non-existent with the only official word being that none of the functions in Rhino lend themselves to multithreading (loose quote there). I personally don't buy that, but I'm just a lay person and that's really a discussion for another thread. Best, Damien On May 13, 5:17 pm, Marc Syp marc@gmail.com wrote: So I installed Rhino 5 today in the hopes that it would allow my GH to multithread, but alas my dual-core still maxes out at 50%... I'm running 32-bit. Is that the problem?? We have 64-bit machines at work but I don't want to go through the lengthy and politically dangerous process of commandeering one of them if I will have the same problem. Will I find a multi-threading solution soon? I find that I am limited in GH only by access to more processing power, and it makes me very sad... :( Marc- Hide quoted text - - Show quoted text -
Re: Circle Packing
Hi Evert, But the script was working with random circles and there are no rules on which circle attaches to which one. Shankar On Thu, May 14, 2009 at 12:09 PM, Evert evertama...@yahoo.com wrote: Hi Shankar, Have a look at this blog. http://tobesch.wordpress.com/2008/11/06/circle-packing-with-grasshopper/ regards Evert
Law Curves.
I am trying to set a number of control curves controling the floor heights of a tower. so the floor heights can sequentially change ( for instance from 1-15th floor --3.5m, from 15-30th -3.5 - 4- 4.5- 4 - 3.5, from 30-45 3.5 - 4 - 5- 4 - 3.5. and so on) does anyone have an example, a link or a tutorial I can look at. Regards Arya
Re: No Multithreading?? :(
Hi Damien, you are right of course, and properly written code ought not give too much problems when called from within a multi-threaded environment. Meshing is indeed an excellent example of potential for multi- threading. It might work on a number of levels: 1) Break the list of objects to mesh into N sublists and assign each sublist to an individual core. This should be reasonably easy to do. 2) Break the polysurface into N sublists of faces, and assign each face array to an individual core. Once they are all finished, the meshing-post-process can start to stitch up all the edges. This is obviously much harder to synchronize, but it would provide performance increase for individual objects. 3) Break the entire meshing algorithm into loose parts, and have each core only focus on a subset of vertices that belong to a single face. This will be very tricky, and its not obvious that there will be a performance increase because of all the logic overhead. The mesher is already written with threading in mind, so we should be able to add this feature without having to rewrite too much code. I made a multi-threading test a while back in an attempt to speed up the Contour command. Essentially assigning each contour section to a new thread. This didn't work because the deep-down nurbs intersection code in Rhino either stores intermediate data in global variables or on the Brep object being intersected. Thus, once you call this BrepBrep Intersection code from within two threads simultaneously, they get confused because they keep overwriting each others intermediate results. We have a lot of those functions in the core which means there's no way we can just start implementing multi- threading command by command. So it's actually much worse than you think. It's not just that we (McNeel) won't go into MT anytime soon, but our 3rd party developers also cannot do so because they have to rely on our non-thread-safe core functions. The good news is that for Rhino5 we've started looking into this and we've actually made some isolated bits and pieces multi-threaded. As we become more comfortable and more experienced with MT, we'll be able to slowly fix all the non-thread-safe functions in the core. No idea how long this will take or if we'll even manage to fix ALL the problems. What does this mean for Grasshopper: Since the order of operations inside in Grasshopper is totally unpredictable (it depends on the network made by the user), I dare not make GH components thread-aware. There are of course parts where threading is possible (preview meshes or grasshopper-only-operations for example), but I've disabled preview-meshing-threads for the time being since there were some odd crashes and I didn't have the courage to debug them. -- David Rutten da...@mcneel.com Robert McNeel Associates On May 14, 2:37 pm, damien_alomar dominos...@gmail.com wrote: Thanks for the info Bob. I didn't realize that you guys had started using OpenMP. Although in most cases, rewriting some of those chunks of code to allow for multithreading might not really offer too much added benefit, I think there are still other places where smaller changes to allow for multithreading could be added. A simple example is something like meshing. If we're meshing more than one object why can't we have each object potentially meshed in its own thread? I think solving fairly basic multithreaded situations like that might be a good place to start and one where there is certainly a good deal of added benefit. Just my two cents from a guy who's not looking at the code and couldn't write it myself ;) Best, Damien On May 14, 12:52 am, Bob McNeel bob.mcn...@gmail.com wrote: The details are not simple... to get your head into the problem, start by reading this article... all of it, along with the discussion. http://www.technologyreview.com/multicore Multicore programming is generally require a major rewrite of big chunks of code. Often for very little improvement. Of course there are exceptions, like raytracing which is already parallelized in most applications include Rhino and Flamingo. There are tools to help. One example is OpenMP. We are using OpenMP in Rhino 5, but my guess is that in most cases where OpenMP helps Rhino is already so fast you won't be able to tell the difference very often. To get your head deep into the topic, pick up a copy of Using OpenMP from MIT Press. On May 13, 8:48 pm, damien_alomar dominos...@gmail.com wrote: I'm not sure what you're hopes were based on, but AFAIK there are no multithreading additions for v5 or Grasshopper. Doesn't really matter what kind of system you have as its something that requires the attention of the Rhino developers and David. Last I asked (many months ago), David said that he attempted to try out some multithreading with GH, but had a lot of problems managing threads and a number of issues with some SDK functions not being
Re: Circle Packing
Hi Shankar, Sorry I did not understand your query! So if the distance between each other of the points with its neighbors is set up by a slider, is this distance going to be the same between all the points? In that case sounds more like a hexagonal grid of points. Can you post a sketch? regards Evert On May 14, 2:30 pm, shankar raco...@gmail.com wrote: Hi Evert, But the script was working with random circles and there are no rules on which circle attaches to which one. Shankar On Thu, May 14, 2009 at 12:09 PM, Evert evertama...@yahoo.com wrote: Hi Shankar, Have a look at this blog. http://tobesch.wordpress.com/2008/11/06/circle-packing-with-grasshopper/ regards Evert
Re: No Multithreading?? :(
I'm a complete laymen when it comes to programming, so this is probably a really stupid suggestion... but doesn't the data tree structure lend itself to multithreading? That is, within a single component, when the calculation initiates, isn't there a way to separate independent calculations/operations done within each path? Take a mass addition component with 4 paths, N=9. Couldn't the component send each path to a separate core? The performance increases for each component would seem to be drastic when you add it all up... but I suppose I'm missing something fairly major because if it were that easy, I'm sure you would have already done it. :P Marc On May 14, 4:37 pm, David Rutten da...@mcneel.com wrote: Hi Damien, you are right of course, and properly written code ought not give too much problems when called from within a multi-threaded environment. Meshing is indeed an excellent example of potential for multi- threading. It might work on a number of levels: 1) Break the list of objects to mesh into N sublists and assign each sublist to an individual core. This should be reasonably easy to do. 2) Break the polysurface into N sublists of faces, and assign each face array to an individual core. Once they are all finished, the meshing-post-process can start to stitch up all the edges. This is obviously much harder to synchronize, but it would provide performance increase for individual objects. 3) Break the entire meshing algorithm into loose parts, and have each core only focus on a subset of vertices that belong to a single face. This will be very tricky, and its not obvious that there will be a performance increase because of all the logic overhead. The mesher is already written with threading in mind, so we should be able to add this feature without having to rewrite too much code. I made a multi-threading test a while back in an attempt to speed up the Contour command. Essentially assigning each contour section to a new thread. This didn't work because the deep-down nurbs intersection code in Rhino either stores intermediate data in global variables or on the Brep object being intersected. Thus, once you call this BrepBrep Intersection code from within two threads simultaneously, they get confused because they keep overwriting each others intermediate results. We have a lot of those functions in the core which means there's no way we can just start implementing multi- threading command by command. So it's actually much worse than you think. It's not just that we (McNeel) won't go into MT anytime soon, but our 3rd party developers also cannot do so because they have to rely on our non-thread-safe core functions. The good news is that for Rhino5 we've started looking into this and we've actually made some isolated bits and pieces multi-threaded. As we become more comfortable and more experienced with MT, we'll be able to slowly fix all the non-thread-safe functions in the core. No idea how long this will take or if we'll even manage to fix ALL the problems. What does this mean for Grasshopper: Since the order of operations inside in Grasshopper is totally unpredictable (it depends on the network made by the user), I dare not make GH components thread-aware. There are of course parts where threading is possible (preview meshes or grasshopper-only-operations for example), but I've disabled preview-meshing-threads for the time being since there were some odd crashes and I didn't have the courage to debug them. -- David Rutten da...@mcneel.com Robert McNeel Associates On May 14, 2:37 pm, damien_alomar dominos...@gmail.com wrote: Thanks for the info Bob. I didn't realize that you guys had started using OpenMP. Although in most cases, rewriting some of those chunks of code to allow for multithreading might not really offer too much added benefit, I think there are still other places where smaller changes to allow for multithreading could be added. A simple example is something like meshing. If we're meshing more than one object why can't we have each object potentially meshed in its own thread? I think solving fairly basic multithreaded situations like that might be a good place to start and one where there is certainly a good deal of added benefit. Just my two cents from a guy who's not looking at the code and couldn't write it myself ;) Best, Damien On May 14, 12:52 am, Bob McNeel bob.mcn...@gmail.com wrote: The details are not simple... to get your head into the problem, start by reading this article... all of it, along with the discussion. http://www.technologyreview.com/multicore Multicore programming is generally require a major rewrite of big chunks of code. Often for very little improvement. Of course there are exceptions, like raytracing which is already parallelized in most applications include Rhino and Flamingo. There are tools to help. One example is OpenMP.
Re: Grasshopper is moving...
I love it. The gallery part is great. On May 13, 7:04 pm, Taylor delete2...@gmail.com wrote: Its great!
Re: Circle Packing
Hi Evert, I want to initially manually place random points (based on function - ex living, dining, kitchen). The i want them to accomodate a certain area ( hence the circle ). I would want them to move in relation to each other ( a toilet isn't going to be related to living - or some other relation). Hence i need to pack with certain rules. An image with a basic sketch I hope i have stated the problem better now. Shankar On Thu, May 14, 2009 at 3:52 PM, Evert evertama...@yahoo.com wrote: Hi Shankar, Sorry I did not understand your query! So if the distance between each other of the points with its neighbors is set up by a slider, is this distance going to be the same between all the points? In that case sounds more like a hexagonal grid of points. Can you post a sketch? regards Evert On May 14, 2:30 pm, shankar raco...@gmail.com wrote: Hi Evert, But the script was working with random circles and there are no rules on which circle attaches to which one. Shankar On Thu, May 14, 2009 at 12:09 PM, Evert evertama...@yahoo.com wrote: Hi Shankar, Have a look at this blog. http://tobesch.wordpress.com/2008/11/06/circle-packing-with-grasshopper/ regards Evert attachment: basic idea.JPG
Re: No Multithreading?? :(
Hi Marc, it's irrelevant. DataTrees or no DataTrees, the problem lies elsewhere. -- David Rutten da...@mcneel.com Robert McNeel Associates On May 14, 5:34 pm, Marc Syp marc@gmail.com wrote: I'm a complete laymen when it comes to programming, so this is probably a really stupid suggestion... but doesn't the data tree structure lend itself to multithreading? That is, within a single component, when the calculation initiates, isn't there a way to separate independent calculations/operations done within each path? Take a mass addition component with 4 paths, N=9. Couldn't the component send each path to a separate core? The performance increases for each component would seem to be drastic when you add it all up... but I suppose I'm missing something fairly major because if it were that easy, I'm sure you would have already done it. :P Marc On May 14, 4:37 pm, David Rutten da...@mcneel.com wrote: Hi Damien, you are right of course, and properly written code ought not give too much problems when called from within a multi-threaded environment. Meshing is indeed an excellent example of potential for multi- threading. It might work on a number of levels: 1) Break the list of objects to mesh into N sublists and assign each sublist to an individual core. This should be reasonably easy to do. 2) Break the polysurface into N sublists of faces, and assign each face array to an individual core. Once they are all finished, the meshing-post-process can start to stitch up all the edges. This is obviously much harder to synchronize, but it would provide performance increase for individual objects. 3) Break the entire meshing algorithm into loose parts, and have each core only focus on a subset of vertices that belong to a single face. This will be very tricky, and its not obvious that there will be a performance increase because of all the logic overhead. The mesher is already written with threading in mind, so we should be able to add this feature without having to rewrite too much code. I made a multi-threading test a while back in an attempt to speed up the Contour command. Essentially assigning each contour section to a new thread. This didn't work because the deep-down nurbs intersection code in Rhino either stores intermediate data in global variables or on the Brep object being intersected. Thus, once you call this BrepBrep Intersection code from within two threads simultaneously, they get confused because they keep overwriting each others intermediate results. We have a lot of those functions in the core which means there's no way we can just start implementing multi- threading command by command. So it's actually much worse than you think. It's not just that we (McNeel) won't go into MT anytime soon, but our 3rd party developers also cannot do so because they have to rely on our non-thread-safe core functions. The good news is that for Rhino5 we've started looking into this and we've actually made some isolated bits and pieces multi-threaded. As we become more comfortable and more experienced with MT, we'll be able to slowly fix all the non-thread-safe functions in the core. No idea how long this will take or if we'll even manage to fix ALL the problems. What does this mean for Grasshopper: Since the order of operations inside in Grasshopper is totally unpredictable (it depends on the network made by the user), I dare not make GH components thread-aware. There are of course parts where threading is possible (preview meshes or grasshopper-only-operations for example), but I've disabled preview-meshing-threads for the time being since there were some odd crashes and I didn't have the courage to debug them. -- David Rutten da...@mcneel.com Robert McNeel Associates On May 14, 2:37 pm, damien_alomar dominos...@gmail.com wrote: Thanks for the info Bob. I didn't realize that you guys had started using OpenMP. Although in most cases, rewriting some of those chunks of code to allow for multithreading might not really offer too much added benefit, I think there are still other places where smaller changes to allow for multithreading could be added. A simple example is something like meshing. If we're meshing more than one object why can't we have each object potentially meshed in its own thread? I think solving fairly basic multithreaded situations like that might be a good place to start and one where there is certainly a good deal of added benefit. Just my two cents from a guy who's not looking at the code and couldn't write it myself ;) Best, Damien On May 14, 12:52 am, Bob McNeel bob.mcn...@gmail.com wrote: The details are not simple... to get your head into the problem, start by reading this article... all of it, along with the discussion. http://www.technologyreview.com/multicore Multicore programming is
Re: Law Curves.
Arya, This should be fairly straight forward. If you'd like to use a law curve then you could have a look at the following example: http://tobesch.wordpress.com/2008/11/25/law-curve-example/ This example has been done in Grasshopper 0.5.0099. Regards, Tobias On May 14, 10:09 am, Arya reacha...@gmail.com wrote: I am trying to set a number of control curves controling the floor heights of a tower. so the floor heights can sequentially change ( for instance from 1-15th floor --3.5m, from 15-30th -3.5 - 4- 4.5- 4 - 3.5, from 30-45 3.5 - 4 - 5- 4 - 3.5. and so on) does anyone have an example, a link or a tutorial I can look at. Regards Arya
Re: poblems with beziers
anyone know how to make a vector from 2points, or even more direct, create a vector from a line in Vb.net??
Re: Gradient Voronoi
Thanks to everybody... I'm working on it Sure I'll have other questions bye On May 13, 7:05 pm, yoon y...@plusplastic.com wrote: Hi I made Grasshopper definition for this one. Try this :http://sac3.blogspot.com/2009/05/grasshopper-polygon-gradiant-voronoi... - Yoon On 5월12일, 오후10시55분, Mr. Muten alessandro.be...@gmail.com wrote: Hi, I'm searching a script of a 2D gradient voronoi like the one see in this site http://sac3.blogspot.com/search/label/Voronoi anyone can help me???
Re: Diagrid Skyscraper Vertical Interval
Ok, sorry but I am new to Grasshopper. How did you make the floors so they are at constant hight from each other? I've been trying to do it by dividing the surface (divide surface on grasshopper) but they are never at a constant distance from each ohter, so i get different floor hights. I've solved it another way but it seams too complicated: I have a surface in rhino and with grasshopper I project onto the surface a series of rectangles that are x distance apart. Any easier way? Thks. On 28 Abr, 18:27, pul golden...@libero.it wrote: thank you! I did exactly as autarchy said. I created some curves aligned with the floors and I lofted them in straight mode in loft options. Then explode it in multiple surfaces and I used that surfaces to generate my diagrid. I putted in the v value 1. It was so simple and I spent one day trying to fix it... On 28 Apr, 15:03, autarchy d...@urbanfuture.org wrote: Dividing a surface works with the U V distance or by parameter along surface so the surface length or CV weightings will vary the alignment. Try creating sections of the surface (that align with the floor slabs - or wherever you need to create the joints) and then divide the curves up to create a series of points that you can use as the diagrid base.
Re: Grasshopper is moving...
Well, as far as graphic desing goes, I find the light green colour used over saturated and also that the green coloured fonts are difficult to read when on a white background... All in all, it gives me a feel of a straight out template based appearance rather than being original As it is usually the case with RMA products, the organisation is sterling! thanks
Re: Grasshopper is moving...
I've made some minor adjustments to the colors. They look different on different monitors. Let us know how it looks now. On May 14, 5:43 pm, dimos dimstog...@gmail.com wrote: Well, as far as graphic desing goes, I find the light green colour used over saturated and also that the green coloured fonts are difficult to read when on a white background... All in all, it gives me a feel of a straight out template based appearance rather than being original As it is usually the case with RMA products, the organisation is sterling! thanks
