Search Results - 22选5河南福彩网-『2TBH·COM』大乐透2017039名家预测汇总--2023年3月19日7时33分39秒.H5c2a3.pacyzgv9k

Blog Post: Parametric Urbanism: 15 Basic Parameters In Urban Design

This list is not comprehensive but a starting point for any planning project.

In a successfully designed …

Added by Mr. Gudjon Thor Erlendsson at 7:52am on April 15, 2020

Comment on: Topic 'Réseau sur surface': peuvent se diviser une surface avec ne importe quel motif imaginable. 3. Ici, je fournir un moyen de le faire via Lunchbox ... cela fonctionne mais il est fixe et donc nous avons besoin de jouer avec des arbres de données afin de créer le motif approprié par cas. 4. L'autre composante est un joint C # qui fait beaucoup de choses autres que de diviser ne importe quelle collection de points avec de nombreux modèles (voir le modèle ANDRE que je ai fait pour vous). 5. Vous devez décomposer une polysurface en morceaux afin de travailler sur les subdivisions. 6. Je donne une autre définition ainsi que pourrait agir comme un tutoriel sur la façon de traiter des ensembles de points via des composants de GH standards et des méthodes classiques. Avertissez si tous ceux-ci apparaissent floue pour vous: Si oui, je pourrais écrire une définition utilisant des composants de GH classiques - mais vous perdrez les variations de motifs de division. mieux, Peter …; Added by peter fotiadis at 10:15am on March 19, 2015

Comment on: Topic 'Point Deform that can move brep's control Points': lass BrepDeform Inherits GH_Component Public Reslist As New List(Of String) Public Sub New() MyBase.New("BrepDeform", "Deform", _ "移动物件的控制点" & vbCrLf & "(Move the control Point to change a object)", "SEG", "Modify") End Sub Public Overrides ReadOnly Property ComponentGuid As System.Guid Get Return New Guid("8226e0ea-ed6b-47c2-8a24-244f044152d8") End Get End Property Protected Overrides ReadOnly Property Internal_Icon_24x24() As System.Drawing.Bitmap Get Return My.Resources.SEG_BrepDeform End Get End Property Protected Overrides Sub RegisterInputParams(ByVal pManager As GH_Component.GH_InputParamManager) ' pManager.AddTextParameter("Guid", "Id", "将要被替换的犀牛物件" & vbCrLf & "(RhinoObjects that will be replaced)", GH_ParamAccess.item) 'Dim guidParam As New Param_Guid pManager.AddParameter(New Param_Guid, "Guid", "Id", "将要被替换的犀牛物件" & vbCrLf & "(RhinoObjects that will be replaced)", GH_ParamAccess.item) pManager.AddPointParameter("ControlPoint3d", "C", "控制点的位置" & vbCrLf & "(Control Point's location)", GH_ParamAccess.item) pManager.AddPointParameter("NewPoint3d", "P", "新控制点的位置" & vbCrLf & "(New Control Point's location)", GH_ParamAccess.item) pManager.AddNumberParameter("Tolerace", "T", "输入点与物件实际控制点对比的精度" & vbCrLf & "(Tolerace for the Control Point match)", GH_ParamAccess.item, 0.1) pManager.AddBooleanParameter("BlMove", "M", "如果是True则进行移动" & vbCrLf & "(If true Perform the Move)", GH_ParamAccess.item, False) End Sub Protected Overrides Sub RegisterOutputParams(ByVal pManager As Kernel.GH_Component.GH_OutputParamManager) pManager.AddTextParameter("Result", "RG", "结果列表" & vbCrLf & "(Result)", GH_ParamAccess.list) End Sub Public Overrides ReadOnly Property Exposure As GH_Exposure Get Return GH_Exposure.primary End Get End Property Protected Overrides Sub SolveInstance(ByVal DA As Kernel.IGH_DataAccess) If Banner.astrict.showmessage Then Return Dim Ids As Guid = Guid.Empty 'Dim Ids As String = String.Empty Dim tpt As Point3d = Point3d.Unset, opt As Point3d = Point3d.Unset Dim tolar As Double = 0.1 Dim blMove As Boolean = False If Not DA.GetData(0, Ids) Then Return If Not DA.GetData(1, opt) Then Return If Not DA.GetData(2, tpt) Then Return If Not DA.GetData(3, tolar) Then Return If Not DA.GetData(4, blMove) Then Return If Not blMove Then GoTo line1 Reslist.Add(Now & "_未替换！(Replace failed!)") Else Reslist.Clear() ' Grasshopper.Instances.ActiveCanvas.ModifiersEnabled = False End If ' rt.AddRange(docobjlist.Select(Function(geoobj As RhinoObject) GH_Convert.ObjRefToGeometry(New ObjRef(geoobj.Id)))) 'Private Checked(5) As Boolean, Namestr() As String = {"Point", "Curve", "Brep", "Mesh", "TextDot", "TextEntity"} Try Dim rh As RhinoDoc = Rhino.RhinoDoc.ActiveDoc Dim rhobj As RhinoObject = rh.Objects.Find(Ids) ' Dim rhobj As RhinoObject = rh.Objects.Find(New Guid(Ids)) Dim bobj As BrepObject = CType(rhobj, BrepObject) RhinoApp.RunScript("Cancel", False) RhinoApp.RunScript("Cancel", False) bobj.Select(True) RhinoApp.RunScript("_SolidPtOn", False) Dim gobjs As GripObject() = bobj.GetGrips ' rh.Views.RedrawEnabled = False For Each grpobj As GripObject In gobjs If grpobj.CurrentLocation.DistanceTo(opt) < tolar Then grpobj.Select(True) Dim CurrentPln As Plane = RhinoDoc.ActiveDoc.Views.ActiveView.ActiveViewport.ConstructionPlane Dim tropt As New Point3d(opt), trtpt As New Point3d(tpt) tropt.Transform(Transform.PlaneToPlane(Plane.WorldXY, CurrentPln)) trtpt.Transform(Transform.PlaneToPlane(Plane.WorldXY, CurrentPln)) Dim movestr As String = "_move " + String.Format("{0},{1},{2} ", tropt.X, tropt.Y, tropt.Z) + String.Format("{0},{1},{2} _Cancel _Cancel", trtpt.X, trtpt.Y, trtpt.Z) RhinoApp.RunScript(movestr, True) grpobj.Select(False) End If Next 'RhinoApp.RunScript("Cancel", False) 'RhinoApp.RunScript("Cancel", False) '' rh.Views.RedrawEnabled = True Reslist.Add(Now & "_替换成功！(Replace Success!)") Catch ex As Exception Reslist.Add(Now & "_替换失败！(Replace failed!)" & vbCrLf & ex.Message) End Try ' Grasshopper.Instances.ActiveCanvas.ModifiersEnabled = True line1: DA.SetDataList(0, Reslist) End Sub 'Private Sub Testt_PingDocument(sender As IGH_DocumentObject, e As GH_PingDocumentEventArgs) Handles Me.PingDocument ' Dim Mbool = Aggregate bcbool In Checked Into cb = Any(bcbool) ' If Not Mbool Then ' Checked(0) = True ' Message = Namestr(0) ' Order = 0 ' End If 'End Sub End Class The picture below shows the two question. Question One I must use data dam, or the component can't batch deal the brep. I don't know why, I have You can give me a solution to make it working normal not using the data dam Question Two I can not uset the Button component, If I use it, the gh canvas will die with some mouse event--. I have see this problem before in this forum,but there is no solution and explain. I want to know why and How to solve it. I don't know if I have made my question clear,if not give a message. Thank you! Thank you all. The gh test file and 3dm test file in the upload files. …; Added by huaxiamengqing at 2:02am on June 8, 2015

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: Initial Documentation of Thermal Maps: ing the maps to the broader community. At the moment, there are just a few known issues left that I have to fix for complex geometric cases but they should run smoothly for most energy models that you generate with Honeybee. Within the next month, I will be clearing up these last issues and, by the end of the month, there will be an updated youtube tutorial playlist on the comfort tools and how to use them. In the meantime, there's an updated example file (http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Indoor_Microclimate_Map) and I wanted to get you all excited with some images and animations coming out of the design part of my thesis. I also wanted to post some documentation of all of the previous research that has made these climate maps possible and give out some much deserved thanks. To begin, this image gives you a sense of how the thermal maps are made by integrating several streams of data for EnergyPlus: (https://drive.google.com/file/d/0Bz2PwDvkjovJaTMtWDRHMExvLUk/view?usp=sharing) To get you excited, this youtube playlist has a whole bunch of time-lapse thermal animations that a lot of you should enjoy: https://www.youtube.com/playlist?list=PLruLh1AdY-Sj3ehUTSfKa1IHPSiuJU52A To give a brief summary of what you are looking at in the playlist, there are two proposed designs for completely passive co-habitation spaces in New York and Los Angeles. These diagrams explain the Los Angeles design: (https://drive.google.com/file/d/0Bz2PwDvkjovJM0JkM0tLZ1kxUmc/view?usp=sharing) And this video gives you and idea of how it thermally performs: These diagrams explain the New York design: (https://drive.google.com/file/d/0Bz2PwDvkjovJS1BZVVZiTWF4MXM/view?usp=sharing) And this video shows you the thermal performance: Now to credit all of the awesome people that have made the creation of these thermal maps possible: 1) As any HB user knows, the open source engines and libraries under the hood of HB are EnergyPlus and OpenStudio and the incredible thermal richness of these maps would not have been possible without these DoE teams creating such a robust modeler so a big credit is definitely due to them. 2) Many of the initial ideas for these thermal maps come from an MIT Masters thesis that was completed a few years ago by Amanda Webb called "cMap". Even though these cMaps were only taking into account surface temperature from E+, it was the viewing of her radiant temperature maps that initially touched-off the series of events that led to my thesis so a great credit is due to her. You can find her thesis here (http://dspace.mit.edu/handle/1721.1/72870). 3) Since the thesis of A. Webb, there were two key developments that made the high resolution of the current maps believable as a good approximation of the actual thermal environment of a building. The first is a PhD thesis by Alejandra Menchaca (also conducted here at MIT) that developed a computationally fast way of estimating sub-zone air temperature stratification. The method, which works simply by weighing the heat gain in a room against the incoming airflow was validated by many CFD simulations over the course of Alejandra's thesis. You can find here final thesis document here (http://dspace.mit.edu/handle/1721.1/74907). 4) The other main development since the A. Webb thesis that made the radiant map much more accurate is a fast means of estimating the radiant temperature increase felt by an occupant sitting in the sun. This method was developed by some awesome scientists at the UC Berkeley Center for the Built Environment (CBE) Including Tyler Hoyt, who has been particularly helpful to me by supporting the CBE's Github page. The original paper on this fast means of estimating the solar temperature delta can be found here (http://escholarship.org/uc/item/89m1h2dg) although they should have an official publication in a journal soon. 5) The ASHRAE comfort models under the hood of LB+HB all are derived from the javascript of the CBE comfort tool (http://smap.cbe.berkeley.edu/comforttool). A huge chunk of credit definitely goes to this group and I encourage any other researchers who are getting deep into comfort to check the code resources on their github page (https://github.com/CenterForTheBuiltEnvironment/comfort_tool). 6) And, last but not least, a huge share of credit is due to Mostapha and all members of the LB+HB community. It is because of resources and help that Mostapha initially gave me that I learned how to code in the first place and the knowledge of a community that would use the things that I developed was, by fa,r the biggest motivation throughout this thesis and all of my LB efforts. Thank you all and stay awesome, -Chris…; Added by Chris Mackey to Ladybug Tools at 6:26pm on May 16, 2015

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

Topic: Butterfly beta release for Grasshopper and Dynamo: ly has finally metamorphosed to have all known major bugs fixed and is ready to be used by a larger number of people in our community. Butterfly is powered by OpenFOAM, which is a validated and open-source engine for Computational Fluid Dynamics (CFD). Primarily, Butterfly assists with exporting geometry and other input parameters from the CAD + scripting interface to the OpenFOAM engine. The Grasshopper plugin supports live results visualization that updates as the CFD simulation iterates. The Dynamo plugin supports results visualization once the analysis is over or paused. For installation instructions and guidance on getting started, check out the Butterfly wiki page. There, you can find step-by-step installation directions and tutorial videos. There also 3 YouTube playlists for getting you started with installing OpenFOAM for Windows and using Butterfly for Grasshopper and Butterfly for Dynamo. Similar to other ladybug tools, Butterfly uses an external validated engine (in this case, OpenFOAM) and you need to install it first to get the insect up-and-running. However, unlike Radiance and EnergyPlus, OpenFOAM doesn’t have a native installation for Windows and it requires Linux to run. Accordingly, the current version of “OpenFOAM for Windows” uses a technology called docker to run a Linux virtual machine on your system, inside which OpenFOAM operates. While this sounds complicated, the good news is that all of this setup has been packaged into the installer for “OpenFOAM for Windows.” So running this installer with all its defaults should give you everything you need. The bad news is that the installation can fail if you don’t check your Windows system properly beforehand or don’t follow every step carefully afterwards. You will also need to run Rhino, Revit, and OpenFOAM as an administrator to ensure Butterfly works properly (by right-clicking each launcher for the program and selecting “Run As Administrator"). This said, if you follow the steps carefully, you should have no issues with the installation. You can find some of the issues that people faced during the alpha testing and the solutions to them here. Butterfly is the first plugin that is fully developed based on the structure that I discussed before which consists of a core library and [+] libraries for specific software (in this case Grasshopper and Dynamo). We hope this structure to extend ladybug tools to more platforms by re-using the current code. We will provide a better documentation with more details on this matter in the near future but for now you can use the API for butterfly, butterfly_grasshopper and butterfly_dynamo for customizing or extending the current development. Finally, having access to a powerful CFD engine from inside parametric/generative modeling environments is a great power and as Spider-Man or Uncle Ben once said: “with great power comes great responsibility!” We believe in learning by doing and we don’t expect you to be a CFD expert to get started with butterfly however we expect you to educate yourself along the way. If you have never used OpenFOAM before here is a great presentation to get started. We also highly recommend checking out the official OpenFOAM User Guide that goes through most of its functionality. Finally, we have also collected a number of other learning resources on this page that can be a good starting point. We understand that you will have questions about the plugins which you can post to this forum or Dynamo discussion forum however CFD related issues and questions should be posted to CFD Online. I like to thank everyone who have helped us with the development and testing during the last year or so, and special thank to Theodore who single-handedly educated me through the process of migrating to OpenFOAM and developing butterfly. Butterfly wasn’t possible without Theodore! As always let us know about your comments and suggestions. Happy flying the butterfly! Happy Spring! …; Added by Mostapha Sadeghipour Roudsari to Ladybug Tools at 11:06am on March 20, 2017

Comment on: Topic 'Pain Points in Grasshopper': r." I'm sorry to hear that, I take the interface and ease-of-use rather seriously so this sounds like 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."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."[...] 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.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'. 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. 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 this time around 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. Sliders."I think they should be optional."They are optional."The “N” should turn into the number if set."What if you assign more than one integer? I think I'd rather see a component with inputs 'N', 'P' and 'X' rather than '5', '8' and '35.7', but I concede that is a personal preference."But if I plug it into something that'll only accept a 1, a 2, or a 3, that slider should self set accordingly."Agreed. 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."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. 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. 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. 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. Organisation.Agreed. We need to come up with better ways to organise, document, version, share and simplify GH files. GH1 UI is ok for small projects (<100 components) but can't handle more complexity. 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 david@mcneel.com…; Added by David Rutten at 2:11am on August 2, 2014

Search Results - 22选5河南福彩网-『2TBH·COM』大乐透2017039名家预测汇总--2023年3月19日7时33分39秒.H5c2a3.pacyzgv9k

About

Translate

Search

Photos

SubD metaball

SubD metaball

Lines to Building

Spiral Stair

Offset Intersection

Videos

Rhino SubD - Metaball 3D

Lines to Building

Spiral Stair

Offset Intersection

Random Metaball 2d Pattern - Rhino Grasshopper

Dispatch & Patch