1. Lofting - I want to loft one set of polygons to another resized set which have been moved a set distance. I then hope to remove these volumes from the extruded hexagons
2. When offsetting, some polygons seems to have done so in a different direction. Is there a way to force this direction on all geometry?
3. Image sampling - I hope to have the image sampler control the inner polygons (to be apertures openings) however how can I get the gradient image I have used to fit to the base surface?
4. Edit the face of the hexagons - I have attached an image of how I would like to manipulate the hexagonal blocks. The aim is to catch the sunlight
5. Does anybody know how to get these hexagons to sit together better rather than trial and error like i have done at the moment.
If anyone has a better way of generating this kind of facade then i'd really appreciate the advice. I have considered panelling but wouldn't know how to get all these factors to work i.e. getting the hexagonal blocks to sit right together, getting the apertures to the change according to the image panel etc.
Thanks for even taking the time to read this, and if anyone has any ideas on any of the points above, please let me know!!
Kind regards
Marc…
I upgraded Grasshopper to 0.9.0076 and I went through the steps again. I figured out that it crashes when I add GHpython to Grasshopper. Older versions of GHpython gave the same results.
Any ideas?
Thanks :)
........................................................
Original discussion 18.4.17
Hi all,
I installed Ladybug as it is explained in this link ( http://james-ramsden.com/installing-honeybee-for-grasshopper/ ) but when I use any component, from Ladybug or Honeybee tool, Rhino crashes!
I have Win10-64 bit, Rhino 5, GH 0.9.0069. and I installed: 1. GHPaython that is compatible with GH copy I have (0.5.99 Coding location - For Grasshopper 0.9.0061) 2017-Feb-13. I also made sure to unblock the file. 2. Daysim to this destination. C:/DAYSIM/ 3. This copy of Radiance, (radiance-5.0.a.12-win64.exe) to this destination C:/RADIANCE 4. Latest release of EnergyPlus (8.7.0)
Can I get some help?
Thanks in advanced. :)
Best,
Hussein Abohamida.
…
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…
e following inputs:
| title: The title of the new Rhino view.
| projection: A basic projection type.
| position: A position.
| floating: true if the view floats; false if it is docked.
| Returns: The newly constructed Rhino view; or null on error.
However when I try to use it python gives an error:
Add() takes exactly 5 arguments (4 given)
I've figured out that it wants me to give it also the "self" argument:
Add(self: ViewTable, title: str, projection: DefinedViewportProjection, position: Rectangle, floating: bool)
However I have no idea what to give as a first argument.
Here is the code if it helps:
import Rhino.DocObjects.Tables as tables
import Rhino
import System
tables.ViewTable.Add("Testi",Rhino.Display.DefinedViewportProjection.Perspective,
System.Drawing.Rectangle(0,0,100, 100),True)
Thanks from your help in advance!
-Matti Pirinen…
Added by Matti Pirinen at 3:08pm on December 8, 2015
omly distributed pointcloud, a clearly discernable hyperplanes pattern emerged from the combination of three Random components, each outputting a list to feed the three spatial coordinate. The three random components share the same Domain and Number inputs, but the Seeds are unique. When the seeds are three consecutive numbers [n] [n+1] [n+2] , the resulting points are arranged in three coplanar groups. As the third seed increases while the first two are fixed, the number of hyperplanes planes linearly increases by steps of 2.
[n] [n+1] [n+2] > 3
[n] [n+1] [n+3] > 5
[n] [n+1] [n+4] > 7
...
By swapping random coordinate lists in the Point3D inputs, the planes rotate around the average value of all the XYZ point coordinates. Still not having digged into Linear Congruential Generators, yet definetevely interesting the order emerging from (pseudo) randomness.
I attach screenshots of a test with the following input parameters:Domain: -10 to 10Number: 10000Seeds: 0,1,2
Best,
Marco
…
rconnecting-lines-winthin-a-circle?commentId=2985220%3AComment%3A869729
Here's the challenge:
I've based it on my recent attempts to learn GH by repeating problems posted on the forum. I find most of the solutions aren't really parametric and only work under one set of conditions which really defeats the purpose and this forms part of the challenge. Solve this post:
http://www.grasshopper3d.com/forum/topics/move-an-object-until-a-constant-value-is-reached
Summary of problem:
1. A set of lines with a constrained length in static positions around a variable radii circular base
2. The top circle constrains the end point of the lines and can rotate and also change its radii, thus 'pulling' the line end points in its direction(s)
3. The top will therefore 'sink' as the rotation occurs or either radii change due to the mechanics of the constraints
Rules:
1. Must work parametrically, i.e. not break when inputs change
2. 1 Hour to solve it
3. Use as few components as possible (clustering is cheating!)
4. Scripting not allowed
5. Must solve as efficiently as possible
…
proxy). However I decided to use the Human plug-in and scatter them as block instances, this allows me to add some reference lines in a different layer to have a better visual reference of the proxies, and have a lighter work environment in Rhino. (If you have the blocks on a layer and the proxies inside in a different layer, the proxies will render even if their layer is off and they are not showing in the viewport)
The definition has two parts: the bottom part scatters 3 grass primitives on a circle surface and is mostly an updated version of Manuel's definition, I hope he doesn't mind (you can replace the circle with any surface if you want a small patch of grass), you then bake this geometry, create one or several proxies in Rhino and create the blocks; the top part scatters a block on either a Surface, Brep or Mesh.
The definition populates the base surface/brep/mesh with points, then offsets the edges with the circle radius and pulls the points outside that boundary to it, so the circles don't fall outside the surface. (this part was the one that gave most troubles and it still fails sometimes, maybe someone could help me with that)
It also autoflips the normals if they're not up, and aligns the X axis of the target planes to a set direction (so you can have some wind or gravity effect if you want).
I used, and you probably need to make it work: Rhino 5 sr11 64bits, V-ray 2.0, grasshopper 0.9.0076, and Human (3-17-2014)
In my examples I scattered 3 blocks each with its own material, but you can have proxies with multiple materials.
If you make your own grass primitives don't forget to map the textures before scattering.
I'm posting some example renders and sharing the vray materials and proxies I used (I was experimenting with vray2sidedmats and a second diffuse layer with yellow noise mapped to world coordinates)
I'd like some help to get some cooler and different ideas for grass materials and proxies.
If you get some bugs let me know...
Eduardo
…
Added by Eduardo A at 11:54am on September 14, 2015
) membrFP.Faces[0], // start/quide surface: going from DC to NY via LA uSpans, // obvious vSpans, // obvious true, // trim outer loop. Fails in most of cases. NOTE: inner loops ARE NOT treated false, // tangency 1.0, // point spacing patchFlexibility, // flexibility: use a generous value around 50 surfPullFactor, // surface pull factor (this needs some investigation) fixedges, // get 4 false values you stupid method, like that? 0.2); // tolerance - be generous: we are talking about tissues here not NASA sourced things
Do you know of a generic container in Rhincommon I can store geometry form meshes, breps and curves to points? That's what I seem to need to get around the IEnumerable error.
I have to figure out how to format the Boolean array in Python. Ah, parenthesis worked!
P = Rhino.Geometry.Brep.CreatePatch(CURVES_CONTAINER, Starting_Surface[0], 10, 10, True, False, 10, 30, 0, (False, False, False, False), 1)
At long last, only to find out it won't work right, as in no setting of flexibility will affect it at all?!
Tolerance has a sudden crazy effect if I turn it way up, like a piece of paper bending up opposite corners and it no long is trimmed, but flexibility is dead. I used your same values and same curves for everything. Yes, all the curves are participating, if I bake them and move them around.
My Patch is broken. Weird. Is there magic with the starting surface? I made a naive assumption just a plane would do. Yet you seem to be using your simple CreatePatch results for this?
Ah, the second CreatePatch command type that takes only a surface gives the same thing, nearly. You need a starting surface at all?! They said you could now leave that out as of Rhino SR10 by using Null, but Null or Nothing gives an error. How do I make a null? In Python it's None, as in just entering None into the Rhinocommon command or assigning a variable to None.
Now I have a patch!
But your's is more expressive, more crazy, like your starting surface is greatly influencing it to have extremely extended feet, whereas mine works like a normal patch, as if you were trying to smooth over things. And indeed your surface pull slider makes it more obvious you chose a specific starting surface attached to one of the curves. My starting planes had no such effect, earlier.
With such a starting surface to bias the results I get the same thing finally, indeed, good to know what that does, I never knew from using the command in Rhino.
Why did my use of a plane shut this down so badly though?! Crazy command.
I've enclose a working script for the record.…
Added by Nik Willmore at 12:47am on February 26, 2016
ntroduces a set of components for creating angular and distance dimensions. These components are not entirely finished yet, especially baking is still a bit rough in places. Also note that a new Tab has been added and some components have been moved from their old position into this new tab.
GH1 Beta 5 was never officially released, though it was the default download for a while. Look in the Grasshopper Version History for a detailed list of changes over time.
List of changes:
A new Display tab has been created for components that show stuff, rather than do stuff.
[Blend Colours] component has been hidden, we recommend [Interpolate Data] instead.
[Point List] and [Point Order] components have superceded the original [Point List] component.
[List Item] retrieval performance is now much better for large amounts of indices.
Added [Linear Dimension] component (Display.Dimensions panel).
Added [Aligned Dimension] component (Display.Dimensions panel).
Added [Line Dimension] component (Display.Dimensions panel).
Added [Marker Dimension] component (Display.Dimensions panel).
Added [Angular Dimension] component (Display.Dimensions panel).
Added [Arc Dimension] component (Display.Dimensions panel).
Added [Circular Dimension] component (Display.Dimensions dropdown).
Added [Serial Dimemension] component (Display.Dimensions dropdown).
Scribble objects no longer rotate by default when dragged.
Scribble objects can now be realistically dragged by holding SHIFT.
Fixes:
Persistent Data stored in generic parameters would sometimes fail to deserialize, this is fixed.
--
David Rutten
david@mcneel.com…