where I could choose the layer and options up front one time, and then expedite the baking process.
The scenario Im in is that I have finished a good script for dividing a surface from a set of referenced XY planes. However, I have about 50-60 surfaces, with 6 bakes each for different component outputs, meaning 200-250 bakes. The computer likely can't do them all at the same time, so that's out of the question. I plan to reference them in one by one (which is fine, i've budgeted the time), but some sort of boolean-bake tool would sure make my life easier.
Thanks!
-BC…
didn't look at it that closely), other than to say tree data structure is helping you and hurting you.
What I did to fix the file was work backwards. Looking at only the left panel you are trying to create 11 total planar surfaces from edge curves (8 curves per surface). That means you should be generating 11 of each type of curve so that you will have 88 total curves when you attempt to join them.
Tree data was in some cases giving you 121 of each type of curve (lists matching with tree structure...) so I worked backwards from your individual curves to flatten the inputs until ending up with only 11 (the expected number) of each type of curve.
…
use for some typical reasons why solar access can be important:
Solar Access for Passive Solar Heating - The conditional statement should request sun vectors for any hours below the balance point of the building (the temperature at which the building starts requiring additional heating). For residences, this can be as high as 18C and for commercial/retail buildings with high internal heat gains, this can be as low as 10C. 16C is around what you might find for some residences with better insulation and is probably the reason why that is chosen in the file.
Solar Access for Outdoor Thermal Comfort - The conditional statement should request sun vectors for any hours below the lower limit of outdoor comfort (UTCI uses 9C for this lower limit).
Solar Access for Health of Plants/Trees in a Park/Garden - This is a bit of the opposite of the other metrics since you want hours of the warmer season. In this case, I usually use solar radiation as the annualHourlyData with the conditional statement and I request hours that are above a certain radiation level (where the plants are benefiting the most). I then use an analysisPeriod to get rid of any months of the year when the trees don't have leaves on them.
Hope this helps,
-Chris…
If I put that function on a new thread I couldnt find a way to update the component later correctly.
What is the bast and probably simple way to run just one function that updates a variable (or it can return one, but I thought that a global one is a bit better) in the background without blocking?
Thanks
T
private static String results = String.Empty;
private static Boolean tDone = false;
protected override void SolveInstance(IGH_DataAccess DA)
{
List<Line> lines = new List<Line>();
if (!DA.GetDataList(0, lines)) { return; }
// can take a lot of time to finish!!
// this updates the global "results" string
DoSomeHardWork(lines);
DA.SetDataList(0, results);
string bb = Convert.ToString(tDone);
DA.SetData(1, bb);
}…
I think there is something wrong with my script. Any ideas to used Surface.Split Method in VB script?
Private Sub RunScript(ByVal S As Surface, ByVal U As Integer, ByVal V As Integer, ByRef Srf As Object) Dim SrfList As New List (Of Surface) Dim uStep As Double = 1 / U Dim vStep As Double = 1 / V
For i As Integer = 0 To U - 1 For j As Integer = 0 To V - 1 Dim USrf As Surface = S.Split(0, uStep * i) Dim VSrf As Surface = USrf.Split(1, vStep * j) SrfList = VSrf Next Next
Srf = SrfList End Sub
Thanks for advance
…
Added by Yasser Hafizs at 8:19am on October 11, 2012
rimeters in the functions.
I am using Rhino5, Grasshopper 0.9.0014, and Kangaroo 96.
I would be grateful if anyone can direct me to the source of the problem.
Thanks
…
Bit Platforms
OOo 3.0,built by Sun, is built for a 32 bit Windows but also runs on 64 bit. To run cli applications on 64 bit one needs to have the 32bit .Net Framework installed (version 3.5 as of OOo 3.0). The application must be built for the x86 platform (see platform switch of csc.exe), otherwise it will not run. If it uses anycpu or x64 then the application will be loaded in a 64 bit process. In order to connect to OOo and creating the bridge, the process must load a couple of dlls from OOo, which are 32 bit dlls. This does not work and a System.BadImageFormatException is thrown.
So, to use the spreadsheet components that use OpenOffice I think you will need Rhino 4.0 or the 32-bit version of Rhino 5.
Did this help?
- Giulio
______________
giulio@mcneel.com
McNeel Europe, Barcelona…