e think. Also, its easier to catch an error because the malicious component simply turns red/orange (in most cases). However, if you are adept at scripting, you are probably very used to recursive looping & conditional evaluation which you miss majorly in GH (it is possible in very limited ways through using series components or comparer components). So an adept scriptor may soon end up switching back to Rhinoscript unless they find the shift from VBscript to VB.net really fast & smooth (which is rare).
GH ofcourse has the advantage of keeping it all 'alive' and changing things with sliders/graphs/image painting, compared to Rhinoscript which is a run-once operation -- so that's where one makes a choice between recursive looping (in RS) & live interactivity (in GH). I'd say RS mostly wins the battle because interactivity is fancy, but recursion can be a necessity.
Now to VB.net. The one barrier I have hit most often with GH is speed. If you were working on a fairly large data set, or doing a number of surface/polysurface/brep operations, you hit the performance ceiling real fast, which is when the interactivity becomes almost useless -- because its nowhere close to real time anymore even if you had 12gb ram. Thus steps in VB.net (A bit of clever scripting can make a really significant difference).
Working a series of geometric operations in a code component is much faster than doing it through native GH components due to the fact that each native component comes with tonnes off error trapping code, preview generation (I think even if you turn it off, its still being computed, only not displayed), etc. while with VB, you can circumvent a lot of that.
If GH were to handle geometry even remotely comparable to what GC/Catia* can do, it would have a long way to go -- I am not sure if that is even the objective. For instance, I am currently working on a tower where all geometry is only meshes and polylines - no degree 3 curves, no surfaces/polysurfaces. This is because if the entire tower is to stay 'alive', Meshes are the lightest option with the amount of geometry being generated. And most of it is through code... there's only the sliders and a couple of other components that are GH native -- and its still in GH due to the interactivity. (I think there's a vast potential with Meshes that GH/Rhino are really not tapping into. There are all the building blocks, but no significant implementation. Giulio's weaverbird plugin is just a small example).
*GC/Catia cost significantly more than Rhino itself, and GH is a free plugin to Rhino. Morever, these softwares were written to be parametric modelling softwares from day1, unlike GH which is an add-on over the RhinoSDK, which was never developed from such a perspective. So a very very unfair comparison there, but GH is becoming so significant that its got a forum of its own -- gaining an almost 'independent software' status. I just hope the McNeel marketing people are not listening :)…
Angeles, which has 12% of the year made comfortable, and Shiraz, Iran, which also has 12% comfortable (assuming default parameters).
Jerusalem also makes sense to me. There is only a maximum possible 9% of the year that is inside the polygon (you'll see this if you set the timeConstant to a very high number). The default strategyPar makes 6% of these hours comfortable and 3% without cool enough temperatures in the previous hours. This seems reasonable to me.
I could be convinced to change the default time constant to 12 hours (instead of 8) as I know that 12 is the default of climate consultant but that seemed really idealized in my opinion. You'll need really high exposed mass and insulation without much internal heat gain to make conditions stable for more than 8 hours in my opinion.
As for the solarHeatCapacity, I get changes when I drop it down to 10 W/m2 or boost it up to 100 W/m2. It's definitely a parameter that operates on an "order of magnitude" scale and little tweaks to it won't change it too much. You can think of this number as representative of a lot of other physical properties: most notably the depth of the space being passively heated and the thermal mass of that space's materials that participate in heat exchange over the time constant. Climate consultant uses a default assumption of 30 W/m2 but, from my calculations, this is likely assuming a space that has a facade to floor area ratio that is greater than 1. If we say that we need to raise the temperature of 10 cm of an exposed concrete floor for passive heating purposes, and we have a facade-to-floor area ratio of 1:
Required solar flux = ((1 facade-to-floor ratio) x (0.1 m3 of concrete) x (2400 kg/m3 concrete density) x (880 J/kg-K concrete specific heat capacity)) / 3600 seconds/hour
This lands you with a required solar flux of 58 W, which is almost twice the 30 W climate consultant default. While me might say that not all 10 cm of concrete participates over the course of a default 8-hour time constant (most of the action is probably within the first 5 cm), we also have to account for things like transmittance of solar though the window, which, for triple pane, is probably only half of the incident solar. So 50 W seemed to be a more reasonable rule of thumb from my perspective, essentially assuming a facade-to-floor ratio of roughly 1 with 5 cm of concrete participating in an 8 hour heat exchange and a little more than half of solar heat getting through a fully glazed window.
Let me know if that makes sense or if you have any suggestions,
-Chris…
e display pipeline @ xx:xx:xx(xxxms)
iThe DrawViewportWires only when loaded!
The DrawViewportMeshes always when the viewport is refreshed!
Any Idea?
Public Overrides Sub DrawViewportWires(ByVal args As Grasshopper.Kernel.IGH_PreviewArgs) ' MyBase.DrawViewportWires(args)-> Disabled because nothing to Display If (Hidden) Then Return
For Each item As Rhino.Geometry.Circle In Circle args.Display.DrawCircle(item, GC, 3) Next
For Each item As Rhino.Display.Text3d In txt
args.Display.Draw3dText(item, GC) Next
End Sub
Public Overrides Sub DrawViewportMeshes(ByVal args As Grasshopper.Kernel.IGH_PreviewArgs) ' MyBase.DrawViewportMeshes(args) -> Disabled because nothing to Display If (Hidden) Then Return
Dim Brep As Rhino.Geometry.Brep Dim M As Rhino.Display.DisplayMaterial
For i As Integer = 0 To Circle.Count Brep = Rhino.Geometry.Brep.CreatePlanarBreps(Circle.Item(i).ToNurbsCurve())(0) M = New Rhino.Display.DisplayMaterial(VC.Item(Math.Min(i, VC.Count - 1))) args.Display.DrawBrepShaded(Brep, M) Next
End Sub
…
to run at full screen. I've gone as far as using an iPad to use as the second monitor via AirDisplay (which actually works really well) but have never been satisfied with any setup that required you to look back and forth as if at a tennis match all day long.
Not long after first using Grasshopper 3+ years ago I've had the desire for a "Live Viewport" component that would allow a live image of the 3d geometry being generated directly in the canvas. Every once in a while I search the forums with the hope of finding a solution, but always come up empty handed. Someday this might exist although for now I have found what might be the next best thing to a native "Live Viewport" component and its enabled with a small app named Sticky Previews. This app uses the task bar preview feature within Windows 7's aero interface to create custom, floating preview windows from any open window currently running. I've only just discovered the app, but it seems to do the trick and has been stable and problem free so far. -- I will post an update if I find out that I might have spoken too soon. The install allows for a 30 day trial and is $15 bucks to purchase. I just found the app and don't know anything about this group that created the app. If you happen to know of them, Id be curious to find out more.
divided windows, cramped and slow;
unified window with floating rhino model preview;
link to the apps webpage;
http://www.ntwind.com/software/sticky-previews.html
Also works with other apps;
and the about me page screen shot;
…
Added by Tyler Selby at 11:25pm on November 26, 2012
serveral questions:the first thing is in c++ i have to implement more methods than in my c# test project.
they are:
int MyGhComponent::MasterParameterIndex::get(){ return 0;}void MyGhComponent::MasterParameterIndex::set(int index){ }bool MyGhComponent::IsValidMasterParameterIndex::get(){ return 1;}
i found no hint for the implementation of that interfaces. could someone tell me that is correct ?OK, it works, but is it well writen ? What is the MasterParameterIndex?
the second "bigger" problem is, i want to have an output of an pointlist.X y Z 1.2 1.3 1.12.1 5.2 9.2...
my first approch was to use a
void MyGhComponent::RegisterOutputParams(GH_Component::GH_OutputParamManager^ pManager){pManager->Register_PointParam("Coordinate", "XYZ", "Node-Coordinate");}
and
void MyGhComponent::SolveInstance(IGH_DataAccess^ DA){Collections::Generic::List<GH_IO::Types::GH_Point3D>^ pnt = gcnew Collections::Generic::List<GH_IO::Types::GH_Point3D>(); for (int i = 0; i < 10; i++) { GH_IO::Types::GH_Point3D^ point = gcnew GH_IO::Types::GH_Point3D(i, i, i); pnt->Add(i); } DA->SetDataList(3, pnt);}
but this exampel doesn't work...i wirte a small workaround and use the following
pManager->Register_DoubleParam("X-Koordinate", "X", "X"); pManager->Register_DoubleParam("Y-Koordinate", "Y", "Y"); pManager->Register_DoubleParam("Z-Koordinate", "Z", "Z"); Collections::Generic::List<double>^ pntx= gcnew Collections::Generic::List<double>(); Collections::Generic::List<double>^ pnty= gcnew Collections::Generic::List<double>(); Collections::Generic::List<double>^ pntz= gcnew Collections::Generic::List<double>(); ... add .. ect.
this workaround do the job, but i want a better soulution. and i know somewhere out there sould be a better solution. i want to use 3D Points directly in GH without list conversation.
so somebody a familiar with c++ / cli ? and could give me some tipps or a soulution ?
the first thing is: what is the right RegisterOutputParams ?
and witch data type is the right ? Point3d doesn't work. so i try GH_IO::Types::GH_Point3D and Rhino::Geometry::Point3d ...
br Friedrich…
rch, september, june.
I did two kind of simulation. The first one - just one hour 10h and then 15:30. The second, 10:00 to 15:30h. I think that's something wrong with the results kWh/m² because the biggest values for radiation, are for winter. And the results simulation 10:00 to 15:30h the result are different too, the biggest values for winter (june), then september, march, and them december (summer)
The results are (kWh/m²)
10:00h 15:30h 10 to15:30h
21/03 0,69 1,15 2,61
21/06 1,14 1,13 3,71
23/09 0,96 0,90 2,79
21/12 1,31 1,22 2,45
I will be very gratiful with your answer I'm using this software to a important academic work, and in my Country Its not commom use this software, I don't know anyone that could help me with this. I'd like to encourage university start to use this kind of software.
Thank you
Camila
…
rent actors to work together in real time on an architectural project.
DixieVR was born from the idea that virtual reality could become a fantastic tool for architecture and architects, not only for virtual tours but for the conception at its very core. Inspired by the efficiency of sandbox games, DixieVR will allow you to build a fully parametric 3D model from scratch in a very intuitive way and to simulate various factors like natural and artificial light, gravity, and more. DixieVR is also multi-user oriented : several people, architects or not, are able to work together in real time on the same 3D model and in the same shared immersive environment !
The project started in the Digital Knowledge department of Paris-Malaquais Architecture School.
The DixieVR Softwares can be found here : dixievr.github.io
// Interoperability
DixieVR deals with .dix files. For more information about this file format, please refer to the Interoperability documentation of DixieVR.
You can use this DixieIO plugin for Grasshopper/Rhinoceros for exchanging data between DixieVR (PC) & DixieViewer (Android).
You can import or export objects at any time inside a DixieVR scene. The Software also come with a library of premade objects that you might find useful. Adding your own premade objects to this library might be a good habit.
If you are hosting a scene, you also have the choice to open a .dix file directly from the main menu, this will load the last scene in which the geometry has been saved.
// Plugin
The DixieVR Plugin can be found in the Extra tab, come with 3 components and a example definition:
Dixie2Gh : Import DixieVR geometry to Grasshopper/Rhinoceros reading a .dix file (up to 1000 beams and/or 750 faces).
G2D_Polylines : Export Grasshopper/Rhinoceros Polylines to DixieVR writing a .dix file (up to 1000 line segments).
G2D_Mesh : Export Grasshopper/Rhinoceros Mesh to DixieVR writing a .dix file (up to 750 triangulated faces).
To install:
In Grasshopper, choose File > Special Folders > Components folder. Place the DixieIO_01.gha file there.
Right-click the file > Properties > make sure there is no "blocked" text.
Restart Rhinoceros or Unload Grasshopper.
// Contact - DixieVR
vr.dixie@gmail.com dixievr.github.io
- Oswald Pfeiffer oswaldpfeiffer.com
- Mathieu Venot mathieuvenot.com…
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
…
ding is not for the faint of heart and is quite a significant understanding. However, I don't know what your dealing with, so that may be the way to go about it.
Your component if its "finished" has to supply some sort of results that are then used downstream. AFAIK there isn't a way to "prevent" down stream components from calculating until your finished. They have to get some sort of information or else they'll just be waiting. Considering how the results of those components are likely to be invalid until the information gets calculated, it may be better off supplying them with nulls until you have some actual information to give them.
Anyway, I think that you should think very closely about the structure of your routine, and specifically how it will interact and update itself. The way I'm thinking about it now is that there really isn't anything that's done in the "solve instance" function if you will. Essentially the "solve instance" function would either A) start the reading of the file if no data is found, or B) output some data if it is found. This is an extreme undersimplification, but the simpler you keep this the more likely this will work. Here are a few more "details", i guess, of how I could see this potentially working...
Thread A - Initial call to Solve Instance function
+ Check and see if there are any results that exist from reading your file - at this point there shouldn't be. These results should be stored in some sort of class variable that is accessible to both threads. It might also be a good idea to have some boolean flag that will also be accessible that represents whether your reading/writing those variables.
+ Fire a function in another thread that begins the read process. Note that you'll likely have to do this through a delegate and an invoke call, but I'm not 100% sure
+ Fill in some null values for the variables you must supply
+ Output the nulls, thus finishing the Solve Instance function
Thread B - File Read Function running in separate thread
+ Open up the file. Note that its probably a good idea just to pass the file path (as a string) between the different threads. Leave the creation of the file/text stream to the one thread that's using it.
+ Perform all the necessary reading from the file
+ Copy all your data to the variables that are accessible to both threads.
+ Expire either the solution on either the component in question or (at last resort) the whole canvas. I know expiring the whole canvas is defenitely possible, but it should be possible to just expire the one component that's doing the reading.
Thread A - "Second" call to Solve Instance after being manually expired
+ Check and see if there are any results that exist from reading your file, which there now should be.
+ Output those shared results
+ Clear the last results (or cache them in some way) so that the next time the Solve Instance function is fired, you don't find any results and reread the file.
I think there are a few variations to this that could happen too, including having a separate function for reading and writing through the data that's called using its own delegate/invoke call to make sure that its extra safe.
If you haven't already, you should really look into event driven programming, delegates, and asyncronous messaging. These are going to be the 3 things that you'll need to have a decent hold on to make sure this things works. Just to let you know, debugging these things can be a bitch.…