Search Results - 广东11选5体育彩票开奖结累查询-『8TBH·COM』下载青蛙彩票网--2023年3月19日6时33分12秒.H5c2a3.rynzzgon4-cc

Blog Post: Masterstudio "Inhabitable Skin" at Institut of Buildings and Energy: Added by Igor Mitrić Lavovski at 4:12pm on September 30, 2016

Topic: Update + Happy Yalda!: t. So here we go! 1. Honeybee is brown and not yellow [stupid!]... As you probably remember Honeybee logo was initially yellow because of my ignorance about Honeybees. With the help of our Honeybee expert, Michalina, now the color is corrected. I promised her to update everyone about this. Below are photos of her working on the honeybee logo and the results of her study. If you think I'm exaggerating by calling her a honeybee expert you better watch this video: Thank you Michalina for the great work! :). I corrected the colors. No yellow anymore. The only yellow arrows represent sun rays and not the honeybee! 2. Yellow or brown, W[here]TH Honeybee is? I know. It has been a long time after I posted the initial video and it is not fun at all to wait for a long time. Here is the good news. If you are following the Facebook page you probably now that the Daylighting components are almost ready. Couple of friends from Grasshopper community and RADIANCE community has been helping me with testing/debugging the components. I still think/hope to release the daylighting components at some point in January before Ladybug gets one year old. There have been multiple changes. I finally feel that the current version of Honeybee is simple enough for non-expert users to start running initial studies and flexible enough for advanced users to run advanced studies. I will post a video soon and walk you through different components. I think I still need more time to modify the energy simulation components so they are not going to be part of the next release. Unfortunately, there are so many ways to set up and run a wrong energy simulation and I really don’t want to add one new GIGO app to the world of simulation. We already have enough of that. Moreover I’m still not quite happy with the workflow. Please bear with me for few more months and then we can all celebrate! I recently tested the idea of connecting Grasshopper to OpenStudio by using OpenStudio API successfully. If nothing else, I really want to release the EnergyPlus components so I can concentrate on Grasshopper > OpenStudio development which I personally think is the best approach. 3. What about wind analysis? I have been asked multiple times that if Ladybug will have a component for wind study. The short answer is YES! I have been working with EFRI-PULSE project during the last year to develop a free and open source web-based CFD simulation platform for outdoor analysis. We had a very good progress so far and our rockstar Stefan recently presented the results of the work at the American Physical Society’s 66th annual DFD meeting and the results looks pretty convincing in comparison to measured data. Here is an image from the presentation. All the credits go to Stefan Gracik and EFRI-PULSE project. The project will go live at some point next year and after that I will release the Butterfly which will let you prepare the model for the CFD simulation and send it to EFRI-PULSE project. I haven’t tried to run the simulations locally yet but I’m considering that as a further development. Here is how the component and the logo looks like right now. 4. Teaching resources It has been almost 11 months from the first public release of Ladybug. I know that I didn't do a good job in providing enough tutorials/teaching materials and I know that I won’t be able to put something comprehensive together soon. Fortunately, ladybug has been flying in multiple schools during the last year. Several design, engineering and consultant firms are using it and it has been thought in several workshops. As I checked with multiple of you, almost everyone told me that they will be happy to share their teaching materials; hence I started the teaching resources page. Please share your materials on the page. They can be in any format and any language. Thanks in advance! I hope you enjoyed/are enjoying/will enjoy the longest night of the year. Happy Yalda! Cheers, -Mostapha …; Added by Mostapha Sadeghipour Roudsari to Ladybug Tools at 3:54pm on December 21, 2013

Topic: Angophora tree trunk. Generate 3~5 "random" points around the perimeter of a shape with a minimum distance apart; each point a small, random distance away from original shape's perimeter.: But not just any gum tree. The angophora, no less: Why? Because I like nature, that's why. Every time I see new designs –especially architectural designs– it worries me that the natural environment is being taken over. Not just that, but even the new materials used in all product designs has to come from nature as well [read: mines]. So. People are forgetting that we still need trees and I believe that if someone sees a beautiful [read: established] tree in their architectural plans, they are going to be much more likely to build around it and not cut it down. That alone would no doubt increase the value of the house. My thinking is that current tree models suck. They look unnatural and I think I know why. They're not random or organic enough. They're not detailed enough. That's basically my 'rationale' for this project. Just look at how different all of these tree trunks are! So I am not being paid for this project. It's a personal project of mine. I'm just worried about the trunk shape for now — I'll worry about all the leaves... when I get to that. I am a grasshopper beginner. Please keep that in mind. I am also fairly hopeless at traditional programming, but I find the visual approach of grasshopper much easier to grasp. So unfortunately I have gotten stuck and need some help, even just a clue, as to how to proceed. That said, here is my current progress: About a year ago, I started modelling with straight trunks using pipe sections, to see if I could get a very basic "tree" shape. And to see if I could join the segments together. Yes it works but it looks hopeless as you can imagine. Then I stopped for a long while. Now I'm back at it, hoping to improve a lot more. I have already made one basic vertical nurbs curve with tangents at either end as the main "trunk". I tried creating two ellipses at each end of the main trunk/curve and lofting between them but it omitted the main curve/rail. So it ended up being an elliptical trunk with straight sides which of course still didn't look right. Then I divided the first main curve up into a number of segments. I think that is a better approach. I have taken the parameters of the curve at each segment (probably the tangent, but I am unsure what the exact parameter is) and used that to form a basic angled plane at each segment/division. I have been able to draw ellipses at each segment and rotate them onto the plane. I was going to loft it together later on. A Curved loft with elliptical cross-sections looks much better than straight a pipe does, but still looks too unnatural. I quickly realised that tree trunks are not elliptical, but rather, shaped more like 'kidneys'. The next step was to create >3 points on each of those planes (spaced fairly evenly around the ellipse so as not to create a really funky/unwanted shape). Maybe it would be better to model with a triangle or other polygon instead of an ellipse. I haven't got that far yet... because here is where I am getting stuck. I managed to find a way of getting three roughly 'triangular' points along each that ellipse. I also managed to create three nurbs cuves in the Z direction which intersected those three points, a bit like three seams down the side of the tree trunk, but couldn't figure out how to loft it all together. I think it was the wrong approach anyway... I'd rather try to create a bunch of nurbs curves at each of the XY planes so as to get more control of the shape. What I am trying to do now is create three roughly triangular-spaced points on a basic ellipse through which I can then draw a simple nurbs curve (think like a cross section of the trunk). I would then like to add some XY-only randomness to the positions of those points. Not Z randomness, otherwise the trunk is going to get messed/kinked up. That's probably very important. Then I would like to loft those nurbs curvs at each XY plane together forming the basic tree trunk, which also tapers based on some other variable (a non-linear factor, not simply distance from ground plane, perhaps something else?). I have attached the GH file. I am also open to suggestions if you have a better way of solving a problem. I would like to retain control over a lot of factor such as number of branches, spacing, average branch length, etc. My main contrsaints are that the entire thing has to be somewhat random and non-linear. …; Added by leslie dean brown at 12:13am on December 27, 2016

Comment on: Topic 'DataTree(of object) > GH_Structure(of ?)': 3. receiver gets data from sender via input (0) < the data here may be changed in the meantime, for instance if its a double then I would like to add 1 to it. 4. receiver sends data to sender's input(2) 5. go to 1. VS 2013 studio project folder SENDER Public Class loopStart Inherits GH_Component Dim cnt As Integer Friend Property counter() As Integer Get Return cnt End Get Set(value As Integer) cnt = value End Set End Property Dim iData As New GH_Structure(Of IGH_Goo) Friend Property startData() As GH_Structure(Of IGH_Goo) Get Return iData End Get Set(value As GH_Structure(Of IGH_Goo)) iData = value End Set End Property Public Sub New() MyBase.New("loopStart", "loopStart", "Start the loop with this one.", "Extra", "Extra") End Sub Public Overrides ReadOnly Property ComponentGuid() As System.Guid Get Return New Guid("bdf1b60d-6757-422b-9d2d-08257996a88c") End Get End Property Protected Overrides Sub RegisterInputParams(ByVal pManager As Grasshopper.Kernel.GH_Component.GH_InputParamManager) pManager.AddGenericParameter("Data", "dIn", "Data to loop", GH_ParamAccess.tree) pManager.AddIntegerParameter("Steps", "S", "Number of loops", GH_ParamAccess.item) pManager.AddGenericParameter("<X>", "<X>", "Please leave this one alone, don't input anything.", GH_ParamAccess.tree) pManager.Param(2).Optional = True End Sub Protected Overrides Sub RegisterOutputParams(ByVal pManager As Grasshopper.Kernel.GH_Component.GH_OutputParamManager) pManager.AddGenericParameter("Data", "dOut", "Data to loop", GH_ParamAccess.tree) End Sub Public Overrides Sub CreateAttributes() m_attributes = New loopStartAttributes(Me) End Sub Protected Overrides Sub SolveInstance(ByVal DA As Grasshopper.Kernel.IGH_DataAccess) Dim numLoop As Integer DA.GetData(1, numLoop) Dim loopDt As New Grasshopper.Kernel.Data.GH_Structure(Of IGH_Goo) If cnt = 0 Then Me.startData.Clear() DA.GetDataTree(0, Me.startData) loopDt = startData.Duplicate DA.SetDataTree(0, loopDt) End If If cnt < numLoop - 1 And cnt > 0 Then DA.GetDataTree(2, loopDt) DA.SetDataTree(0, loopDt) Me.ExpireSolution(True) Else DA.GetDataTree(2, loopDt) DA.SetDataTree(0, loopDt) End If cnt += 1 End Sub End Class RECEIVER Public Class loopEnd Inherits GH_Component Dim aData As New GH_Structure(Of IGH_Goo) Friend Property anyData() As GH_Structure(Of IGH_Goo) Get Return aData End Get Set(value As GH_Structure(Of IGH_Goo)) aData = value End Set End Property Public Sub New() MyBase.New("loopEnd", "loopEnd", "End the loop with this one.", "Extra", "Extra") End Sub Public Overrides ReadOnly Property ComponentGuid() As System.Guid Get Return New Guid("3ffa3b66-8160-4ab3-87c9-356b2c17aadd") End Get End Property Protected Overrides Sub RegisterInputParams(ByVal pManager As Grasshopper.Kernel.GH_Component.GH_InputParamManager) pManager.AddGenericParameter("Data", "dIn", "Data to loop", GH_ParamAccess.tree) End Sub Protected Overrides Sub RegisterOutputParams(ByVal pManager As Grasshopper.Kernel.GH_Component.GH_OutputParamManager) pManager.AddGenericParameter("Data", "dOut", "Data after the loop", GH_ParamAccess.tree) End Sub Protected Overrides Sub SolveInstance(ByVal DA As Grasshopper.Kernel.IGH_DataAccess) Me.aData.Clear() DA.GetDataTree(0, Me.aData) runner() DA.SetDataTree(0, Me.aData) End Sub Sub runner() Dim doc As GH_document = Grasshopper.Instances.ActiveCanvas.Document Dim docl As list(Of iGH_DocumentObject) = (doc.Objects) For i As Integer = 0 To docl.count - 1 Step 1 Dim comp As Object = docl(i) If comp.NickName = "loopStart" Then Dim compp As IGH_Param = comp.Params.input(2) compp.VolatileData.Clear() compp.AddVolatileDataTree(anyData) Exit For End If Next End Sub End Class …; Added by Mateusz Zwierzycki at 2:47pm on November 28, 2013

Comment on: Topic 'Hexagonal planar surface on sphere': URBS cup surface, and boy oh boy did it ever work more uniformly than using 3D orb cutters on a 3D cup. Different sized spheres return the *same* hex grid only less and less raised up as the spheres get very large. My first question is whether these are different in character or just in Z scaling, so if I rescale them all to the same Z thickness, after extracting only the relief structure via Boolean union and splitting...and they are only *slightly* different in character, which means mere Z re-scaling of a single moderate ball size relief is an appropriate cheat to avoid slow Boolean union re-making each relief Z scale with different sized balls. The one on the right is a very shallow relief scaled up to the same Z thickness as the pure sphere one on the left. And really, we will be mostly scaling *down* from a thicker master surface so that will attenuate any weirdness in the curvature. Indeed, I see no difference, so it makes sense to only archive the thickest one so we can control the full range of thicknesses, all the way to nearly flat bulbs. Here is the thickest one, just before the balls lose holes between them, scaled down compared to a shallow one made with huge balls to start with: Now we just use Rhino Flow Along Surface or the Grasshopper Jackalope plug-in Sporf to morph this flat system onto our lathe form. With Rhino history for the Flow Along Surface step I can rescale the original in Z and wait twenty seconds to see the update: There are sad edge artifacts that will require some strategy to retain or later delete a whole row: Maybe add more geometry to later delete or make a solid to hold stuff together? So vastly decreasing the cell count and changing grid direction to match your cup: The edges came out fine on this one, happily. The isocurve count has been increased by the Flow Along Surface command: It can't be filleted yet since the joint where the cup NURBS surface has a joint now leaves feathery edges, so I went back and duplicated the border of the flat array, offset and lofted to make a protecting surface: But that gave crazy artifacts: I'm just going to use symmetry to fill in the joint with good faces that are not having to be joined as two halves. I had to turn my Rhino units tolerance down from a silly 0.0001 to 0.01 units to get a good re-join, but it still won't fillet without leaving holes. SO LET'S FILLET THE FLAT THING. Same problem but a bit faster, and actually repairable manually. Rhino 5 is buggy as hell with core commands, damn it. This is not world class behavior. Let's try it in Rhino 6 WIP, our great hope of the future: nope, the same. I had to simply manually copy the missing pieces from where it did work, which at least is easy to do in flatland. Now I get a cup: This can *all* be done quickly in Rhino without Grasshopper, and Rhino affords you fast cage editing of the original flat array that Grasshopper cannot yet do. You just need to use Analyze Direction to be able to swap UV directions of the source or target and flip the source surface to achieve concave vs. convex patterns. Grasshopper doesn't even have a fillet (multiple) edges component so there's not a lot of advantage to having some super slow parametric system via Grasshopper. It's not like you'll be able to see the changes fast enough to tweak a design.…; Added by Nik Willmore at 7:48pm on April 4, 2016

Topic: ARCHITECTURE LIVE (EMPA - electronic music parametric architecture): and export the geometry out to VVVV to render it LIVE! RawRRRR. In this case, a digital audio workstation Ableton Live, a leading industrial standard in contemporary music production. the good news is that VVVV and ableton live lite is both free. https://www.ableton.com/en/products/live-lite/ i am not trying to use ipad as a controller for grasshoppper. I wanted to work with a timeline (similar to MAYA or Ableton or any other DAW(digital audio workstation)) inside grasshopper in an intuitive way. Currently there is no way of SEQUENCING your definition the way you want to see that i know of. no more combersome export import workflows... i dont need hyperrealistic renderings most of the time. so much time invested in googling the right way to import, export ... mesh settings...this workflow works for some, for some not ...that workflow works if ... and still you cannot render it live nor change sequence of instruction WHILE THE VIDEO is played. and I think no one wants to present rhinoceros viewport. BUT vvvv veiwport is different. it is used for VJing and many custom audio visual installation for events, done professionally. you can see an example of how sound and visuals come together from this post, using only VVVV and ableton. http://vvvv.org/documentation/meso-amstel-pulse I propose a NEW method. make a definition, wire it to ableton, draw in some midi notes, and see it thru VVVV LIVE while you sequence the animation the WAY YOU WANT TO BE SEEN DURING YOUR PRESENTATION FROM THE BEGINNING, make a whole set of sequences in ableton, go back change some notes in ableton and the whole sequence will change RIGHT INFRONT of you. yes, you can just add some sound anywhere in the process. or take the sound waves (sqaure, saw, whateve) or take the audio and influence geometric parameters using custom patches via vvvv. I cannot even begin to tell you how sophisticated digital audio sound design technology got last ten year.. this is just one example which isn't even that advanced in todays standard in sound design ( and the famous producers would say its not about the tools at all.) http://www.youtube.com/watch?v=Iwz32bEgV8o I just want to point out that grasshopper shares the same interface with VVVV (1998) and maxforlive, a plug in inside ableton. audio mulch is yet another one that shares this interface of plugging components to each other and allows users to create their own sound instruments. vvvv is built based on vb, i believe. so current wish list is ... 1) grasshopper recieves a sequence of commands from ableton DONE thanks to sebastian's OSCglue vvvv patch and this one http://vvvv.org/contribution/vvvv-and-grasshopper-demo-with-ghowl-udp after this is done, its a matter of trimming and splitting the incoming string. 2) translate numeric oscillation from ableton to change GH values video below shows what the controll interface of both values (numbers) and the midi notes look like. https://vimeo.com/19743303 3) midi note in = toggle GH component (this one could be tricky) for this... i am thinking it would be great if ...it is possible to make "midi learn" function in grasshopper where one can DROP IN A COMPONENT LIKE GALAPAGOS OR TIMER and assign the component to a signal in, in this case a midi note. there are total 128 midi notes (http://www.midimountain.com/midi/midi_note_numbers.html) and this is only for one channel. there are infinite channels in ableton. I usually use 16. I have already figured out a way to send string into grasshopper from ableton live. but problem is, how for grasshopper to listen, not just take it in, and interpret midi and cc value changes ( usually runs from 0 to 128) and perform certain actions. Basically what I am trying to achieve is this : some time passes then a parameter is set to change from value 0 to 50, for example. then some time passes again, then another parameter becomes "previewed", then baked. I have seen some examples of hoopsnake but I couldn't tell that you can really control the values in a clear x and y graph where x is time and y is the value. but this woud be considered a basic feature of modulation and automation in music production. NVM, its been DONE by Mr Heumann. https://vimeo.com/39730831 4) send points, lines, surfaces and meshes back out to VVVV 5) render it using VVVV and play with enormous collection of components in VVVV..its been around since 1998 for the sake of awesomeness. this kind of a digital operation-hardware connection is usually whats done in digital music production solutions. I did look into midi controller - grasshopper work, and I know its been done, but that has obvious limitations of not being precise. and it only takes 0 o 128. I am thinking that midi can be useful for this because then I can program very precise and complex sequence with ease from music production software like ableton live. This is an ongoing design research for a performative exhibition due in Bochum, Germany, this January. I will post definition if I get somewhere. A good place to start for me is the nesting sliders by Monique . http://www.grasshopper3d.com/forum/topics/nesting-sliders …; Added by yj at 1:33pm on November 14, 2012

Topic: How could I divide a tree with branches of different sizes to multiple trees with the branches of the same size?: j 1 c e h k 2 f ------------------------------------------------------------------------------------------------- To these... 0;0 0;1 0 a i ------------------------------------------------------------ 0;0 0;1 0;2 0 b g j 1 c h k ------------------------------------------------------------ 0;0 0 d 1 e 2 f ------------------------------------------------------------ Thanx……; Added by sadegh at 9:52pm on June 15, 2015

Comment on: Topic 'Pain Points in Grasshopper': e a fundamental failure on my part. On the other hand, Grasshopper isn't supposed to be on a par with most other 3D programs. It is emphatically not meant for manual/direct modelling. If you would normally tackle a problem by drawing geometry by hand, Grasshopper is not (and should never be advertised as) a good alternative. I get that. That’s why that 3D shape I’m trying to apply the voronoi to was done in NX. I do wonder where the GUI metaphor GH uses comes from. It reminds me of LabVIEW. "What in other programs is a dialog box, is 8 or 10 components strung together in grasshopper. The wisdom for this I often hear among the grasshopper community is that this allows for parametric design." Grasshopper ships with about 1000 components (rounded to the nearest power of ten). I'm adding more all the time, either because new functionality has been exposed in the Rhino SDK or because a certain component makes a lot of sense to a lot of people. Adding pre-canned components that do the same as '8 or 10 components strung together' for the heck of it will balloon the total number of components everyone has to deal with. If you find yourself using the same 8 to 10 components together all the time, then please mention it on this forum. A lot of the currently existing components have been added because someone asked for it. It’s not the primary components that catalyzed this thought but rather the secondary components. I was toying with a component today (twist from jackalope) that made use of three toggle components. The things they controlled are checkboxes in other apps. Take a look at this jpg. Ignore differences; I did 'em quickly. GH required 19 components to do what SW did with 4 commands. Note the difference in screen real estate. As an aside, I really hate SolidWorks (SW). But going forward, I’ll use it as an example because it’s what most people are familiar with. "[...] has a far cleaner and more intuitive interface. So does SolidWorks, Inventor, CATIA, NX, and a bunch of others." Again, GH was not designed to be an alternative to these sort of modellers. I don't like referring to GH as 'parameteric' as that term has been co-opted by relational modellers. I prefer to use 'algorithmic' instead. The idea behind parameteric seems to be that one models by hand, but every click exists within a context, and when the context changes the software figures out where to move the click to. The idea behind algorithmic is that you don't model by hand. I agree, and disagree. I believe parametric applies equally to GH AND SW, NX, and so forth, while algorithmic is unique to GH (and GC and Dynamo I think). Thus I understand why you prefer the term. I too tend to not like referring to GH as a parametric modeler for the same reason. But I think it oversimplifies it to say parametric modelers move the clicks. SW tracks clicks the same way GH does; GH holds that information in geometry components while SW holds it in a feature in the feature tree. In both GH and SW edits to the base geometry will drive a recalculation, but more commonly, it’s an edit to input data, beit equations or just plain numbers, that drive a recalculation. I understand the difference in these programs. What brought me to GH is that it can create a visual dialog that standard modelers can’t. But as I've grown more comfortable with it I’ve come to realize that the GUI of GH and the GUI of other parametric modelers, while looking completely different, are surprisingly interchangeable. Do not misconstrue that I’m suggesting that GH should replace it’s GUI with SW’s. I’m not. I refrain from suggesting anything specific. I only suggest that you allow yourself to think radically. This is not to say there is no value in the parametric approach. Obviously it is a winning strategy and many people love to use it. We have considered adding some features to GH that would make manual modelling less of a chore and we would still very much like to do so. However this is such a large chunk of work that we have to be very careful about investing the time. Before I start down this road I want to make sure that the choice I'm making is not 'lame-ass algorithmic modeller with some lame-ass parametrics tacked on' vs. 'kick-ass algorithmic modeller with no parametrics tacked on'. Given a choice, I'd pick kick-ass algorithmic modeller with no parametrics tacked on. 2. Visual Programming. I'm not exactly sure I understand your grievance here, but I suspect I agree. The visual part is front and centre at the moment and it should remain there. However we need to improve upon it and at the same time give programmers more tools to achieve what they want. I'll admit, this is a bit tough to explain. As I've re-read my own comment, I think it was partly a precursor to the context sensitivity point and touched upon other stated points. This now touches upon my own ignorance about GH’s target market. Are you moving toward a highly specialized tool for programmers and/or mathematicians, or is the intent to create a tool that most designers can master? If it’s the former, rock on. You’re doing great. If it’s the latter, I’m one of the more technically sophisticated designers I know and I’m lost most of the time when using GH. GH allows the same freedom as a command line editor. You can do whatever you like, and it’ll work or not. And you won’t know why it works or doesn't until you start becoming a bit of an expert and can actually decipher the gibberish in a panel component. I often feel GH has the ease of use of DOS with a badass video card in front. Please indulge my bit of storytelling. Early 3D modelers, CATIA, Unigraphics, and Pro-Engineer, were unbelievably difficult to use. Yet no one ever complained. The pain of entry was immense. But once you made it past the pain threshold, the salary you could command was very well worth it. And the fewer the people who knew how to use it, the more money you could demand. So in a sense, their lack of usability was a desirable feature among those who’d figured it out. Then SolidWorks came along. It could only do a fraction of what the others did, but it was a fraction of the cost, it did most of what you needed, and anyone could figure it out. There was even a manual on how to use it. (Craziness!) Within a few short years, the big three all had to change their names (V5, NX, and Wildfire (now Creo)) and change the way they do things. All are now significantly easier to use. I can tell that the amount of development time that’s gone into GH is immense and I believe the functionality is genius. I also believe it’s ease of use could be greatly improved. Having re-read my original comments, I think it sounded a bit snotty. For that I apologize. 3. Context sensitivity. "There is no reason a program in 2014 should allow me to make decisions that will not work. For example, if a component input is in all cases incompatible with another component's output, I shouldn't be able to connect them." Unfortunately it's not as simple as that. Whether or not a conversion between two data types makes sense is often dependent on the actual values. If you plug a list of curves into a Line component, none of them may be convertible. Should I therefore not allow this connection to be made? What if there is a single curve that could be converted to a line? What if you want to make the connection now, but only later plan to add some convertible curves to the data? What you made the connection back when it was valid, but now it's no longer valid, wouldn't it be weird if there was a connection you couldn't make again? I've started work on GH2 and one of the first things I'm writing now is the new data-conversion logic. The goal [...] is to not just try and convert type A into type B, but include information about what sort of conversion was needed (straightforward, exotic, far-fetched. etc.) and information regarding why that type was assigned. You are right that under some conditions, we can be sure that a conversion will always fail. For example connecting a Boolean output with a Curve input. But even there my preferred solution is to tell people why that doesn't make sense rather than not allowing it in the first place. You bring up both interesting points and limits to my understanding of coding. I’ve reached the point in my learning of GH where I’m just getting into figuring out the sets tab (and so far I’m not doing too well). I often find myself wondering “Is all of this manual conditioning of the data really necessary? Doesn’t most software perform this kind of stuff invisibly?” I’d love to be right and see it go away, but I could easily be wrong. I’ve been wrong before. 5. Components. "Give components a little “+” or a drawer on the bottom or something that by clicking, opens the component into something akin to a dialog box. This should give access to all of the variables in the component. I shouldn't have to r-click on each thing on a component to do all of the settings." I was thinking of just zooming in on a component would eventually provide easier ways to access settings and data. I kinda like this. It’s a continuation of what you’re currently doing with things like the panel component. "Could some of these items disappear if they are contextually inappropriate or gray out if they're unlikely?" It's almost impossible for me to know whether these things are 'unlikely' in any given situation. There are probably some cases where a suggestion along the lines of "Hey, this component is about to run 40,524 times. It seems like it would make sense to Graft the 'P' input." would be useful. 6. Integration. "Why isn't it just live geometry?" This is an unfortunate side-effect of the way the Rhino SDK was designed. Pumping all my geometry through the Rhino document would severely impact performance and memory usage. It also complicates the matter to an almost impossible degree as any command and plugin running in Rhino now has access to 'my' geometry. "Maybe add more Rhino functionality to GH. GH has no 3D offset." That's the plan moving forward. A lot of algorithms in Rhino (Make2D, FilletEdge, Shelling, BlendSrf, the list goes on) are not available as part of the public SDK. The Rhino development team is going to try and rectify this for Rhino6 and beyond. As soon as these functions become available I'll start adding them to GH (provided they make sense of course). On the whole I agree that integration needs a lot of work, and it's work that has to happen on both sides of the isle. You work for McNeel yet you seem to speak of them as a separate entity. Is this to say that there are technical reasons GH can only access things through the Rhino SDK? I’d think you would have complete access to all Rhino API’s. I hope it’s not a fiefdom issue, but it happens. 7. Documentation. Absolutely. Development for GH1 has slowed because I'm now working on GH2. We decided that GH1 is 'feature complete', basically to avoid feature creep. GH2 is a ground-up rewrite so it will take a long time until something is ready for testing. During this time, minor additions and of course bug fixes will be available for GH1, but on a much lower frequency. Documentation is woefully inadequate at present. The primer is being updated (and the new version looks great), but for GH2 we're planning a completely new help system. People have been hired to provide the content. With a bit of luck and a lot of work this will be one of the main selling points of GH2. It begs the question that I have to ask. When is GH1.0 scheduled to launch? And if you need another person to proofread the current draft of new primer. patrick@girgen.com I can’t believe wikipedia has an entry for feature creep. And I can’t believe you included it. It made me giggle. Thanks. 8. 2D-ness. "I know you'll disagree completely, but I'm sticking to this. How else could an omission like offsetsurf happen?" I don't fully disagree. A lot of geometry is either flat or happens inside surfaces. The reason there's no shelling (I'm assuming that's what you meant, there are two Offset Surface components in GH) is because (a) it's a very new feature in Rhino and doesn't work too well yet and (b) as a result of that isn't available to plugins. I believe it’s been helpful for me to have figured this out. I recently completed a GH course at a local Community College and have done a bunch of online tutorials. The first real project I decided to tackle has turned out to be one of the more difficult things to try. It’s the source of the questions I posted. (Thanks for pointing out that they were posted in the wrong spot. I re-posted to the discussions board.) I just can't seem to figure out how to turn the voronoi into legitimate geometry. I've seen this exact question posted a few times, but it’s never been successfully answered. What I'm showing here is far more angular than I’m hoping for. The mesh is too fine for weaverbird to have much of an effect. And I haven't cracked re-meshing. Btw, in product design, meshes are to be avoided like the plague. Embracing them remains difficult. As for offsetsurf, in Rhino, if you do an offsetsurf to a solid body, it executes it on all sides creating another neatly trimmed body thats either larger or smaller than the original. This is how every other app I know of works. GH’s offsetsurf creates a bunch of unjoined faces spaced away from the original brep. A common technique for 3D voronois (Yes, I hit the voronoi overuse easter egg) is to find the center of each cell and scale them by this center. If you think about it, this creates a different distance from the face of the scaled cell to the face of the original cell for every face. As I've mentioned, this project is giving me serious headaches. Don't get me wrong, I appreciate the feedback, I really do, but I want to be honest and open about my own plans and where they might conflict with your wishes. Grasshopper is being used far beyond the boundaries of what we expected and it's clear that there are major shortcomings that must be addressed before too long. We didn't get it right with the first version, I don't expect we'll get it completely right with the second version but if we can improve upon the -say- five biggest drawbacks (performance, documentation, organisation, plugin management and no mac version) I'll be a happy puppy. -- David Rutten Thank you for taking the time to reply David. Often we feel that posting such things is send it into the empty ether. I’m very glad that this was not the case. And thank you for all of the work you've put into GH. If you found any of my input overly harsh or ill-mannered, I apologise. It was not my intent. I'm generally not the ranting sort. If I hadn't intended to provide possibly useful input, I wouldn't have written. Cheers Patrick Girgen Ps. Any pointers on how to get a bit further on the above project would be greatly appreciated. …; Added by PGirgen at 3:38am on August 3, 2014

Comment on: Topic 'Discrete genome - Elite size - Display settings?': lly it should not make much of a difference - random number generation is not affected, mutation also is not. crossover is a bit more tricky, I use Simulated Binary Crossover (SBX-20) which was introduced already in 1194: Deb K., Agrawal R. B.: Simulated Binary Crossover for Continuous Search Space, inIITK/ME/SMD-94027, Convenor, Technical Reports, Indian Institue of Technology, Kanpur, India,November 1994 Abst ract. The success of binary-coded gene t ic algorithms (GA s) inproblems having discrete sear ch sp ace largely depends on the codingused to represent the prob lem variables and on the crossover ope ratorthat propagates buildin g blocks from pare nt strings to childrenst rings . In solving optimization problems having continuous searchspace, binary-co ded GAs discr et ize the search space by using a codingof the problem var iables in binary st rings. However , t he coding of realvaluedvari ables in finit e-length st rings causes a number of difficulties:inability to achieve arbit rary pr ecision in the obtained solution , fixedmapping of problem var iab les, inh eren t Hamming cliff problem associatedwit h binary coding, and processing of Holland 's schemata incont inuous search space. Although a number of real-coded GAs aredevelop ed to solve optimization problems having a cont inuous searchspace, the search powers of these crossover operators are not adequate .In t his paper , t he search power of a crossover operator is defined int erms of the probability of creating an arbitrary child solut ion froma given pair of parent solutions . Motivated by t he success of binarycodedGAs in discret e search space problems , we develop a real-codedcrossover (which we call the simulated binar y crossover , or SBX) operatorwhose search power is similar to that of the single-point crossoverused in binary-coded GAs . Simulation results on a number of realvaluedt est problems of varying difficulty and dimensionality suggestt hat the real-cod ed GAs with t he SBX operator ar e ab le to perform asgood or bet t er than binary-cod ed GAs wit h t he single-po int crossover.SBX is found to be particularly useful in problems having mult ip le optimalsolutions with a narrow global basin an d in prob lems where thelower and upper bo unds of the global optimum are not known a priori.Further , a simulation on a two-var iable blocked function showsthat the real-coded GA with SBX work s as suggested by Goldberg and in most cases t he performance of real-coded GA with SBX is similarto that of binary GAs with a single-point crossover. Based onth ese encouraging results, this paper suggests a number of extensionsto the present study. 7. ConclusionsIn this paper, a real-coded crossover operator has been develop ed bas ed ont he search characte rist ics of a single-point crossover used in binary -codedGAs. In ord er to define the search power of a crossover operator, a spreadfactor has been introduced as the ratio of the absolute differences of thechildren points to that of the parent points. Thereaft er , the probabilityof creat ing a child point for two given parent points has been derived forthe single-point crossover. Motivat ed by the success of binary-coded GAsin problems wit h discrete sear ch space, a simul ated bin ary crossover (SBX)operator has been develop ed to solve problems having cont inuous searchspace. The SBX operator has search power similar to that of the single-po intcrossover.On a number of t est fun ctions, including De Jong's five te st fun ct ions, ithas been found that real-coded GAs with the SBX operator can overcome anumb er of difficult ies inherent with binary-coded GAs in solving cont inuoussearch space problems-Hamming cliff problem, arbitrary pr ecision problem,and fixed mapped coding problem. In the comparison of real-coded GAs wit ha SBX operator and binary-coded GAs with a single-point crossover ope rat or ,it has been observed that the performance of the former is better than thelatt er on continuous functions and the performance of the former is similarto the lat ter in solving discret e and difficult functions. In comparison withanother real-coded crossover operator (i.e. , BLX-0 .5) suggested elsewhere ,SBX performs better in difficult test functions. It has also been observedthat SBX is particularly useful in problems where the bounds of the optimum point is not known a priori and wher e there are multi ple optima, of whichone is global.Real-coded GAs wit h t he SBX op erator have also been tried in solvinga two-variab le blocked function (the concept of blocked fun ctions was introducedin [10]). Blocked fun ct ions are difficult for real-coded GAs , becauselocal optimal points block t he progress of search to continue towards t heglobal optimal point . The simulat ion results on t he two-var iable blockedfunction have shown that in most occasions , the sea rch proceeds the way aspr edicted in [10]. Most importantly, it has been observed that the real-codedGAs wit h SBX work similar to that of t he binary-coded GAs wit h single-pointcrossover in overcoming t he barrier of the local peaks and converging to t heglobal bas in. However , it is premature to conclude whether real-coded GAswit h SBX op erator can overcome t he local barriers in higher-dimensionalblocked fun ct ions.These results are encour aging and suggest avenues for further research.Because the SBX ope rat or uses a probability distribut ion for choosing a childpo int , the real-coded GAs wit h SBX are one st ep ahead of the binary-codedGAs in te rms of ach ieving a convergence proof for GAs. With a direct probabilist ic relationship between children and parent points used in t his paper,cues from t he clas sical stochast ic optimization methods can be borrowed toachieve a convergence proof of GAs , or a much closer tie between the classicaloptimization methods and GAs is on t he horizon. In short, according to the authors my SBX operator using real gene values is as good as older ones specially designed for discrete searches, and better in continuous searches. SBX as far as i know meanwhile is a standard general crossover operator. But: - there might be better ones out there i just havent seen yet. please tell me. - besides tournament selection and mutation, crossover is just one part of the breeding pipeline. also there is the elite management for MOEA which is AT LEAST as important as the breeding itself. - depending on the problem, there are almost always better specific ways of how to code the mutation and the crossover operators. but octopus is meant to keep it general for the moment - maybe there's a way for an interface to code those things yourself..!? 2) elite size = SPEA-2 archive size, yes. the rate depends on your convergence behaviour i would say. i usually start off with at least half the size of the population, but mostly the same size (as it is hard-coded in the new version, i just realize) is big enough. 4) the non-dominated front is always put into the archive first. if the archive size is exceeded, the least important individual (the significant strategy in SPEA-2) are truncated one by one until the size is reached. if it is smaller, the fittest dominated individuals are put into the elite. the latter happens in the beginning of the run, when the front wasn't discovered well yet. 3) yes it is. this is a custom implementation i figured out myself. however i'm close to have the HypE algorithm working in the new version, which natively has got the possibility to articulate perference relations on sets of solutions. …; Added by Robert Vier to Octopus at 1:59pm on June 8, 2013