oks like the design in the following images:
Concept Images:
Shape:
Design_Request.pdf CR_tower_shape.ghdiagrid.gh
Shape Routine:
Diagrid Routine:
Example and Inspiration:http://www.solaripedia.com/images/large/4226.jpg
Goals:
The goal is to create a grasshopper routine that recreates a modifiable design concept as shown in the concept images. The following parameters should be modifiable
1) The size and elevation of all the basic triangles, circles and the ellipse.
2) The elevation and shape of the opening and the shape and size of the three legs.
3) The shape of the crown. The angle of the tilted ellipse.
4) The loft shape between the edges.
5) The grid size (U,V) of the diagrid.
6) The size of the 2 pipes used for the structure.
Rhino Grasshopper Workflow:
I attempted Boolean difference of a solid (Brep) and the surface in question to create the opening in the surface as shown above but that did not work. What should i do to recreate the concept in grasshopper ? I would appreciate any feedback and advice. Thank you very much !
-Christoph AKA Stoph
…
le] demo):
1. A transformation Matrix is a 4*4 collection of 16 values that "deform" 3d things according the values in the cells. The orthodox way is to deploy "cells" left to right and top to bottom. Rhino does the opposite (why?) hence we need the transpose method.
2. Since "translate" and "perspective" are "symmetrical" the transpose boolean toggle (within the C#) "flips" rows with columns ... so we get perspective or move.
3. When in perspective "mode" the vanishing points are computed internally within a min/max limit (per X/Y/Z axis) thus avoiding the usual havoc with "extreme" perspective angles (very common "glitz" in pretty much every CAD app - CATIA excluded). Vanishing points (and limits) are oriented with respect the pos/neg value of a given control slider.
Note: slider values are percentages between min/max (mode: perspective) and/or actual values*100 (mode: move).
4.In order to start mastering the whole thing: don't change anything: just play with these 4 sliders selected:
5. The 123 sardine cans challenge: even with DeusExMachine = true (see inside C#: that one redirects the transformation per BrepFace and then joins the breps instead of applying it on a brep basis)... odd things (and/or invalid breps) occur ... thus what is required in order to make things working 100% ??.
he, he
best, Lord of Darkness …
trying to develop it for my own project.
http://www.grasshopper3d.com/forum/topics/shortest-walk-tapered-branching-script?xg_source=activity&id=2985220%3ATopic%3A1450323&page=2#comments
On this page, he shared few 3D coral difinitions and especially interested in first and second one.
First one( bunny like 3D coral) - posted on February 2, 2016 at 9:43pm
Second one( sofa like 3D coral) - posted on February 6, 2016 at 3:16am
I followed these instructions, succeeded to build Tetgen, placed the built files in C drive directory and tried to run the definition. Then some WindowsError came out as follows which I don't know how to fix.
My working environment is;
OS is Windows 7 Ultimate 64 bit.
Rhino is version 5, 64 bit.
Grashoppper is version 0.9.0076, the latest version at this moment.
It would be great if I can have some help advice / comment.
I appreciate for your attention.
…
find my initial files, reports and errors (Running E+ simulation on the initial setup took hours and ended up with numerous errors)
I got a number of questions and would appreciate if you could answer them:
1- I have duplicated zones using "Honeybee Move". Is this the correct way to duplicate zones and if yes, should I rename all surfaces afterwards? I have renamed zones but not surfaces (The tower has 40 floors = 10 x typical group of 4 floors)
2- Should I convert all curvilinear objects to faceted geometry (or only windows and window-walls should be flat)?
3- In the next stage, I will add a second skin as the outer facade. Spiral structural elements (insulated thermal mass) are between interior and exterior areas, partly exposed to the sun. Should I split both interior and exterior zones to subtract these elements, and then solve the adjacencies?
4- To simplify the procedure and make it faster, I may simulate only 4 floors. Is it possible to force-hide the top roof and the lowest floor from the sun and other environmental factors? If yes, how? and do you know how much accuracy in the results would be lost in this case? 5- The outer skin would be all in glass, therefore in reality, the direct sun will affect the inner skin and the structural elements. I read somewhere that in HB+E+ simulations, direct sun turns to diffuse after passing the first layer of glass. Is that true? If yes, how can I make the inner skin exposed to direct sun in the simulation? Thank you very much for your time.
Best,
Aryan
…
when the trimmed shapes (red) are small enough, they just dissapear.
Then, the main shape (green) appears again, but as a trimmed shape (red).
I tested it with other elements, like Solid Difference. It performs pretty well, but I just need the trimmed shapes (red) that are above the trimming shape (blue), and with Solid Difference, the collision also happens inside the trimming shape (blue), and that´s not what I am looking for.
Attached some pictures of what I mean. I hope I made myself clear.
Any suggestions?.
Thanks a lot!
1- Good performance
2- Good performance (Without trimming shape)
3- Left side shows the cut on the main shape, but fail to show the trimmed shape (red)
4- Same on the right side
5- It shows everything but in red colour, as a trimmed shape
…
t sure about my decision.
Let's take a look at the method <createPopulation>:
public static List<List<Point3d>> createPopulation(List<Point3d> cP, int populationCount)
{
List<List<Point3d>> Population = new List<List<Point3d>>(); // 1
for(int i = 0; i < populationCount; i++) //2
{
List<Point3d> individual = cP.ToList(); // 3
Population.Add(individual); // 4
System.Security.Cryptography.RNGCryptoServiceProvider provider = new System.Security.Cryptography.RNGCryptoServiceProvider();
int n = Population[i].Count;
while (n > 0)
{
byte[] box = new byte[1];
do provider.GetBytes(box); // 5
while (!(box[0] < n * (Byte.MaxValue / n)));
int k = (box[0] % n);
n--;
Point3d value = Population[i][k];
Population[i][k] = Population[i][n];
Population[i][n] = value;
}
}
In my algorithm there are lots of declarations like: List<Point3d> = new List<Point3d>(); or Random r = new Random(); these are constant time O(1) right?
i = 0 executes once; i < populationCount executes (N+1) times; i++ N times
this executes M times? because every point needs to be added individually?
this one I don't really know; at msdn it is stated: If P:System.Collections.Generic.List`1.Count is less than P:System.Collections.Generic.List`1.Capacity, this method is an O(1) operation. If the capacity needs to be increased to accommodate the new element, this method becomes an O(n) operation, where n is P:System.Collections.Generic.List`1.Count. Shouldn't it be O(N), because I am adding every individual separately?
can't find any statements about this one either, I am guessing it should be of constant time O(1), because just one random number is being generated?
…
hat, in accordance with this stable release, I have posted an updated version of this outdoor microclimate map example to the same link:
http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Outdoor_Microclimate_Map
1. You will see that, in the new file, I now have a single component that is able to turn a zone into a "ground zone" (similar to a plenum). To clarify, both the plenum and ground zone components set all of the loads of the zone to 0 (no internal heat gain). So this means that any of the characteristics of the default office program will be negated. From your comments, Grasshope, it seems that you understand that the reason why I have a ground zone defined in this model is to account for the variation in ground surface temperatures that can occur with different objects casting shade onto the ground. Therefore, the key property that defines this zone is the construction of the top surfaces, which is now changed based on a number that you input into the Ground Zone component.
2. You are correct in understanding the need for both "set zone construction" components in the old file. Because of the zone's position below the Rhino model origin, the walls and floor are defined as underground surfaces and so I need the extra "Set EP Ground Construction" component. Admittedly, the constructions on the underground surfaces should have a minimal effect on the modeling of the surface temperature above the zone (the roof construction is most important) but it made sense to me that results would be more accurate by setting all of the constructions of the zone to the ground material. The current Ground Zone component ensures that all surfaces of the zone are assigned the ground material construction. It also ensures that all walls and floor surfaces have a ground boundary condition regardless of where they sit in relation to the rhino model origin.
3. The distFromFlrOrSrf input can take either a number representing the distance from the floor of zones at which you would like to build a microclimate map or any surface on which you would like to see temperature variation. So the input is flexible and allow you to both build micro-climate maps quickly or take a longer time building them with more customization. For a visual of what you can do by inputting surfaces into this component, see this thermal animation of a section through a building that I designed for my thesis:
https://www.youtube.com/watch?v=WJz1Eojph8E&list=PLruLh1AdY-Sj3ehUTSfKa1IHPSiuJU52A&index=3
For an example of a file using a numerical input for the microclimate map, see here:
http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Indoor_Microclimate_Map
4. The component has since been renamed (sometime in early July) to be called "Honeybee_Microclimate Map Analysis". Originally, I developed the component to help me understand thermal diversity within zones but realized after building it out that the same method could be used to give deeper understandings of the outdoor environment. So, at present, it can do both indoor and outdoor microclimate maps. The only shortcoming at present is that the outdoor microclimate map uses EnergyPlus's oversimplified means of accounting for outdoor wind (a simple wind profile that does nto account for obstructions). This shortcoming will be addressed once the first stable release of butterfly is out or I manage to work in components into LB that use the botlzman lattice particle collision method to approximate outdoor wind speeds. Other than this shortcoming, you can trust that all results you are getting from these components are to a high degree of accuracy (meaning that all air temperature and MRT values are accurate).
5. Thanks for pointing this out. This is a mistake in my labeling of the file names and I will fix this before the end of today. When you use the workflow with the PMV recipe, these values are actual PMV/PPD values. When you use the Adaptive comfort recipe, these values are "degrees from neutral temperature" and "Comfortable Or Not" values. When you use the workflow with the UTCI recipe, these values are also "degrees from neutral temperature" and "Comfortable Or Not" values but they are different for UTCI than they are for the adaptive model. Specifically, the neutral temperature and comfort zone for UTCI is defined to be the same as it is in this publication:
https://www.ipma.pt/en/enciclopedia/amb.atmosfera/index.bioclima/index.html?page=utci.xml
Hope this helps and let me know if you have any more questions,
-Chris…
ahams's question about how shades are accounted for in the simulation/thermal map and Theodore's thought that just accounting for shades in the E+ run was sufficient. I think that it may be clearest to explain what is going on with this infographic:
As the graphic shows, the thermal maps are made from 4 key types of inputs. The radiant temperature map is formed through a consideration of both the temperature of the surfaces surrounding the occupants and the direct solar radiation that might fall onto the occupants through un-shaded windows. The first surface temperature effect is easily computable from your Energy simulation results and the HBZone geometry. However, the second is calculated by seeing how sun vectors pass through the windows of the zones and uses the SolarCal method of the CBE team (http://escholarship.org/uc/item/89m1h2dg) to compute an MRT delta resulting from solar radiation. This delta is then added to the initial values computed through surface temperature view factor. When you do not connect up your shading brep geometry, internal furniture breps, or outdoor context geometry that might block sun to the additionalShading input, the thermal map will assume that sun can pass unobstructed through the window or through indoor furniture to fall onto occupants. It is important to stress that the EnergyPlus simulation does not count for blind geometry or internal furniture as actual geometry. Just as numerical abstractions of surface area and material properties. So we need you to plug in the actual geometry of these things when we compute the MRT delta resulting from sun falling directly onto people.
Next, to clear up the definition of window transmissivity. The important thing to clarify here is that, whether it refers to the tranmittance of glass or to the amount of sun coming through a fine screen of blinds, the value is multiplied by the radiation falling on the occupant and thus has a direct correlation to the MRT Delta from sun falling on occupants. So, if you set transmissivity to zero, the sun falling on the occupants will not be considered in the calculation and, if you set the transmissivity to 1, the assumption is that there is no window (or the window glass is 100% clear). So, Abraham, your definition of it as a coefficient is appropriate.
Normally, I would just recommend that you leave this value at the default 0.7, which corresponds to the transmittance of the default glass material in Honeybee. However, there are 4 cases in which you might consider changing it:
1) You are not using the default Honeybee glazing material, in which case, you should change the transmissivity to be equal to this new value.
2) You have a lot of really small blind/shade geometries and you do not want the view factor component to take several minutes to trace sun vectors through the detailed shade geometry and so you are ok with using just a simple abstraction instead of plugging shade breps into the additionaShading. In this case, you might try to estimate the average percentage of radiation coming through the blind geometry (maybe with some simple Ladybug radiation studies or with your intuition about the amount of sun blocked by the shades). You will then multiply this by the tranmissivity of your glass and this will be the value that you input to the component.
3) Your blinds for your Honeybee simulation are dynamic, in which case, plugging shade breps into additionalShading is not going to work because the component will assume that those shades are always there. In this case, you should be plugging a list of 8760 values into the transmissivity that correspond to when the shades are pulled. When the blinds are completely up, the value should be the tranmittance of your window and, when they are down, the value should be the window tranmittance multiplied by the fraction of light coming through the shades.
4) You have shades/blinds but they are transparent or are not completely opaque. The additionalShading_ input assumes that all shade geometry is opaque and so you cannot use it to account for such shades. Accordingly, you will need to account for it through the tranmissivity.
In the future, I may try to pull more information about blinds and glass properties off of the HBzones inside the view factor component but, for now and for the next few months, the above describes how it works.
Theodore, for curved geometry, I think that your safest bet is going to be planarizing the Rhino geometry before you turn it into a HBZone (so you just divide the curved surface into a few vertical planar panes of glass that approximate the curve well enough). This is essentially what the runSimulation component does for you automatically (it meshes the geometry as you see here: https://www.youtube.com/watch?v=nMQ2Pau4q6c&index=12&list=PLruLh1AdY-SgW4uDtNSMLeiUmA8YXEHT_). If I were to figure out a way to incorporate shades in this automatic meshing workflow, your EnergyPlus simulation would take a very long time to run and I am not even sure if the result will be that accurate with the way E+ abstracts shades. So I don't think that it's really worth it over just planarizing the geometry yourself.
Lastly, I won't be able to figure out the problem with your current run Theodore, unless I get the GH file from you. Make sure that you are using all up-to-date components.
-Chris…