able and it needs to know how to convert itself from/to other types of data.
Let's say that you have a simple data type that combines a point and an integer:
public struct PointIndexData
{
public Point3d Point;
public int Index;
}
It doesn't really matter whether it's a class or a struct. Once you have your data type you can 'wrap' it up in goo in order to make it Grasshopper compliant:
public class PointIndexGHData : GH_Goo<PointIndexData>
{
//...
}
At this point you'll need to implement the 5 abstract methods that are not implemented by GH_Goo<T>. They might look something like this:
public class PointIndexGHData : GH_Goo<PointIndexData>{ public override IGH_Goo Duplicate() { PointIndexGHData dup = new PointIndexGHData(); dup.Value = Value; return dup; }
public override bool IsValid { get { return Value.Index >= 0; } }
public override string ToString() { return string.Format("{0} [{1}]", Value.Point, Value.Index); }
public override string TypeDescription { get { return "Points and Integers, living in perfect harmony"; } }
public override string TypeName { get { return "IndexPoint"; } }}
You'll probably also want to override the CastFrom and CastTo methods so that your data can easily be used by any component which takes in simple points or integers, and -in this case- you want your data to also implement the Grasshopper.Kernel.IGH_PreviewData interface as this data can -and should- be displayed in the Rhino viewports.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
com/forum/topics/kangaroo-matters-relaxing...
For a simplified version of the lost data issue use the modified def attached.
Note:
1. In this case GH stored some data (3 out of 5 nurbs). Notice that the internalized info is dimmed (but "null" is the final output).
2. Image sampler suffers as well - here using a recent photo of me (+ my cat) as a test ("save in file = on" it doesn't work in pretty much all the cases).
If the sampler could work you should see this:
3. Imagine storing captured images in various directories and creating a GH def using some images from, say, directory "capture screens 17".
In some occasions Image sampler stores correctly the image file name ... but mess things as regards the donor directory:
Here's a typical example with image files stored and directory name "replaced":
…
your fully glazed building). Once a person looks away from the glazed building, they no longer experience glare. If you know the view that someone will have looking at your building, Honeybee has a large number of tools that will give you real and reliable numbers for glare.
I know that you are planning to use a different method here but I point out the above just to be clear that you are not necessarily sure that people will experience glare if you are just looking at the times of the year when direct sun will be bouncing off of the glass building onto another building. However, I can see this as a good starting point to assess the hours where there is a risk of glare in the building where light is being bounced to.
With that preamble out of the way, I can say that you are using a version of Ladybug that is 6 months old and I have updated your file for you. To update your components and to be sure that the file below works correctly, you should re-download the user objects from the main Ladybug page and drag them onto your canvas.
If you want to look at sunrays for a whole year, I would keep your number of test points low by increasing your grid size (I think 5 should suit your purposes). Also, you should only set the number of bounces to 1 as you are only really concerned about the one bounce off of the glass building. With these two things done, you can then hook up an analysis period and have it do bounces for every sun-up hour of the period an not take for ever to calculate on your machine. Perhaps an easier way to do this would be to take a sun-up hour for every month instead of a full analysis period, as I have done in your attached file.
Finally, you need to make the last bounce length long enough to intersect the neighboring building (I increased it to 15 meters). Then you can use the native grasshopper components to count the number of intersections.
You can see this all in this file:
https://www.dropbox.com/s/poe7i1zwut2fjg6/Glarescript19sept_CWM.gh?dl=0…
ll pop-up a message saying what it's happening inside that "A" slot, as i'm doing in the screenshot above.
"Similar" component is automatically converting his inputs into numbers (if it wasn't able to do it, it would be displayed an error).
If you compare the lists, you can see that the conversion from point to number is not very helpful at this moment (this specific conversion is the distance from the point to the world 0, or the length of the vector equivalent to the point, same thing).
2- Grasshopper lists-components managing.
A generic component in grasshopper behave different to what you are expecting.
What is happening here is somehow like this:
The component "Similar" (but it work like this in a lot of other components, if not all) take the first element in list "A" and combine it with the first element in list "B",
the second element in list "A" and combine it with the second element in list "B",
the third element in list "A" and combine it with the third element in list "B",
4th in A with 4th in B,
then, as the list B is shorter then list A (4vs33 elements), grasshopper repeat the last element in list B until the end of list A.
What you want to do after with that true/false list?
And how can you compare point with a 5% tolerance? Depending of their coordinates?
Or you want to remove every point in list A that is similar to at least one point in list B... ?
These are simple operations, and there are so many way to achieve any result.
If you can explain to what you are aiming for, it will be the best to help you.
:D
…
go and sulk in the corner, my C# is non existent, although i am making progress on python unfortunately slower than my grasshopper.
Attached is a typical relatively simple planar grillage model for a bridge form that is common in Australia/NZ/Asia. The analysis package has a good graphical interface, however i am looking at replicating the process ideally with GH. I am getting there.
There are a few constraints in the use of a super T, the precast mould is governed by two critical dimensions:
1. from the beams soffit to the underside of the precast flange, normally Depth -75 or 100mm. Depths that are common are 1200/1500/1800.
2.The real sweet spot dimension is the 1027mm dimension to the outside of the webs, this is a constraint
The actual shapes of the prestressed beams are governened by AS5100:5 Appendix H (from memory)
In my definition I included the super T cross section which is parametric.
The other definition is where I have got to with the grillage.
I am a little one dimensional: point-line-surface-volume. I think I am getting to grips with manageing data i lists.
My ulimate aim is to:
generate basic geometry in gh, the type of analysis will be a space frame or FE, these analysis types require different geometries imported to a structural analysis package
ideally utilise IFC, for materials, 2D, 3D drawings and project documentation
At the moment I am looking to generate all of my gemetry in GH, that seems to generate a lot of doubled up geometry. Deconstruct Brep may become my favourite.
A little excesive is the inclined members spilt into the same no. of points at the grillage length.
again thanks for you time, oh! took a a few minutes to work out how to plug your def's in.
kenyon
…
Added by Kenyon Graham at 7:57pm on December 3, 2015
t'd be great.
I am trying in Rhino 5 and would like to understand where to get the documentation and get the feel for the differences.
Also, do you write such scripts directly in the component? Or elsewhere? How can one debug them?
Thank you for your help.
Option ExplicitCall Main()Sub Main() Dim arrObjects, arrMP, i Dim offsetSize offsetSize = 1 arrObjects = Rhino.GetObjects("Select curves to offset") If IsArray(arrObjects) Then For i = 0 To UBound(arrObjects) arrMP = Rhino.CurveAreaCentroid(arrObjects(i)) If IsArray(arrMP) Then Dim arrNewobject, strGroup, grpName arrNewobject = Rhino.OffsetCurve(arrObjects(i), arrMP(0), offsetSize, ,2) Rhino.AddLayer("offset") Rhino.ObjectLayer arrObjects(i),"offset" Rhino.ObjectLayer arrNewobject,"offset" strGroup = Rhino.AddGroup Rhino.AddObjectsToGroup arrObjects(i), strGroup Rhino.AddObjectsToGroup arrNewobject, strGroup End If Next End If End Sub
…
rera de Arquitectura CEM | presenta la cordial invitación al Curso de Diseño Computacional a realizarse en nuestros laboratorios de Arquitectura y Diseño Industrial del Campus Estado de México.
Fecha: jueves 21, viernes 22 de 18: a 22:00 Hrs y sábado 23 de 8:00 a 15:00 Hrs febrero 2013. 15 Horas.
El taller está orientado a estudiantes y profesionales de la Arquitectura, Arte, el Diseño e Ingeniería.
COSTO:
Alumnos Tec o EXATEC con una cuota de $2000.00 pesos.* Estudiantes EXTERNOS y profesores TEC $3000.00*, Estudiantes de posgrado externos $3800.00* y Profesionales externos $4250.00 pesos.*
OBJETIVO GENERAL:
Alfabetización sobre lectura y escritura de herramientas computacionales para el desarrollo de la Arquitectura, Diseño e Ingeniería.
Objetivos específicos:
1. Comprenderá los conceptos metodológicos del Diseño Computacional y generativo.
2. Aplicará las metodologías en el diseño, análisis y despiece de una cubierta (celosía, muro, losa, fachada o mobiliario) con base en un espacio existente en el campus.
3. Desarrollará los conceptos de programación orientada a objetos (POO Intermedia)
4. Generará algoritmos y análisis en Grasshopper sobre el ejemplo de praxis.
5. Desarrollo de documentación y presentación de resultados.
6. Fabricación del objeto, escala por definir.
Requisitos: Conocimiento de alguna plataforma CAD/CAM/CAE.
Profesor:
Arq. David Hernández Melgarejo.
http://bioarchitecturestudio.wordpress.com
Mayor información:
Kathrin Schröter, Dipl.-Ing./Arch. (D)
Directora de la Carrera de Arquitectura e Ingeniería Civil
Escuela de Diseño, Ingeniería y Arquitectura
Campus Estado de México
TEC DE MONTERREY
Tel.: (52/55) 5864 5555 Ext. 5685 o 5750
Enlace intercampus:80.236.5685
Fax: (52/55) 5864 5319
kschroter@itesm.mx
www.itesm.mx
…
si à faire le tri avec Grasshopper et l'outil Points in Brep, comme je pensais. Je suis passé d'environ 400 000 points à uniquement 20 000 points autour de mes 3 rails. C'est très efficace (mais un peu dangereux avec tous ces points).
J'ai interdit au composant CircleFit de faire un cercle, s'il n'y a pas au moins 5 points présents sur la section. Car lorsqu'il y a seulement 3 ou 4 points, il suffit qu'il y en ait un pour que le cercle soit faux, alors qu'au delà, le cercle a plus de chance d'être "bon".
J'ai également créé des "Pipe" (créés à partir de portions de l'axe) au lieu des "Box » de sélection des points pour éviter de sélection trop de points que ne serait pas des points du rail.
J'ai ensuite créé des « panel » pour la moyenne des distances en X et en Y et la moyenne des distances centre à centre.
Tout cela fonctionne bien avec un axe et un tuyau. Mais maintenant j'essaie d'appliquer ça à plusieurs rails en même temps. Je crois avoir compris qu'il faut créer des « path » dans l'imput manager, et faire correspondre le « path » de l'axe et celui du Tuyau.
Dans mon exemple j’ai mis 3 courbes et 21 sections. Au moment où j'utilise les boîtes pour créer les portions des axes, il crée 63 « sous-path » de 1 courbe alors qu'il faudrait qu'il crée 3 "paths" de 21 courbes, enfin si j'ai bien compris.
Car une fois qu’il a créé les points à l’intérieur des « Pipe », il doit les projeter sur les plans correspondant. Et c’est là que le problème se voit. Il ne fait pas correspondre les points à projeter et les plans.
Je vous envoie la version à une courbe et un tuyau (c’est la v5 avec un fichier rhino ou la courbe d'axe est "bakée" pour pouvoir faire un zoom sur la zone plus rapidement) et je vous envoie également, celle avec 3 courbes et 3 tuyaux. Sachant qu’il faudra également attribuer un rayon pour un des tuyaux et un autre rayon pour les deux autres.
Tout ça est bien compliqué, j’espère que je ne vous embête pas trop.
Merci d’avance.…
a and we'll stop adding new stuff. At this point the Grasshopper version will be rolled to 1.0 Beta 1 and we'll keep on fixing serious bugs, resulting in Grasshopper 1.0 Beta 2 etc. etc. until the product is stable enough to be treated as a commercially viable product.
This does not mean Grasshopper will no longer be free. Robert McNeel & Associates (who develop and own the copyrights to Grasshopper) haven't decided yet whether or not to sell Grasshopper or whether to keep it as a free plug-in for Rhino customers.
As soon as Grasshopper 1.0 goes into beta, all development (apart from the odd bug-fix) stops and we start typing on Grasshopper 2.0. It will probably be a few months until the first 2.0 WIP version is released but basically the whole process starts over.
What are we looking to accomplish for 1.0 and which things are planned for 2.0 and beyond? The only major feature still missing in 1.0 is the Remote Control Panel. This feature was removed at some point and has been partially rewritten since then. Once it's finished, we consider the 1.0 feature set to be complete.
To be honest we've made very few concrete plans yet concerning 2.0, however it's clear that some things need to be at least seriously considered and researched. Here follows a list in no particular order:
Documentation System. This is one of the things we know we're going to do as we've already started. The Grasshopper help system will need to be rewritten and a lot of help topics need to be typed up. We have a pretty good idea what it is we want to accomplish with the new help and how we're going to go about it.
Vocabulary. Along with new documentation we'll critically analyse the current terminology and vocabulary of Grasshopper. We'll probably come up with glossaries and style sheets. We want to use words that are —at best— self documenting and —at worst— non ambiguous.
SDK and core library cleanup/improvement. Grasshopper was the first large scale product I ever developed and a lot of mistakes were made in the SDK design. A lot of functions and classes have been marked obsolete over time and many operations are not properly bottlenecked. I also want to add a lot more events so it's easier for code to keep close tabs on what's going on at any given moment.
GUI platform. At the moment Grasshopper is pure .NET winforms using GDI+ for all the interface drawing. There are certain performance issues with using large GDI+ surfaces and certain limitations on what we can and cannot draw. We will be investigating other graphics pipelines such as WPF, OpenGL, DirectX, OpenTK and whatever else seems promising.
Multi-threading. It is clear that some components are embarrassingly parallel, and since almost every single laptop and desktop has at least 4 cores these days it would be a shame not to use them. We will investigate what it takes to implement multi-threading as a standard feature.
Large file support. Grasshopper becomes awkward to use when a document contains more than a hundred or so components. We need to both improve the interface to provide methods for layering or grouping sub-algorithms and also add ways to reduce memory and computational overhead.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Illuminants like "A" or "D65" are spectral power distributions that are defined (as per CIE S 014-2/E:2006) for wavelengths ranging from 300nm to 830nm.
For example, CIE Illuminants A,B and C are defined as :
And D65 is defined as :
For illuminance and luminance calculations, the radiation from such illuminants are converted to Lux or Candela/sq.m by weighing them against the Photopic Luminous Efficiency function (also called as V-lambda):
The equation (1) used for this purpose is
Where y corresponds to the V-lambda function and J corresponds to an illuminant like "D65" or "A".
So, why is all this relevant? Honeybee/Radiance also use a similar method for calculation of luminous flux, illuminance and luminance. However, in the case of Honeybee/Radiance the lighting calculations are limited only 3 (R,G,B) channels (and not the 300nm to 830nm). So the equation (1) from above becomes something like:
F = 47.4*R+120*G+11.6*B
Where (R,G,B) refers to the spectral power of the radiation and the numbers (47.4,120,11.6) relate to the V-lambda function. So, the bottom line is that an accurate representation of CIE illuminants is not possible inside Radiance/Honeybee as the spectral information is severely restricted. Some studies have proposed using Radiance with more than 3 channels. For example: http://link.springer.com/article/10.3758%2FBRM.40.1.304 . However, such attempts have been limited. What is possible with Radiance/Honeybee is to create a fairly accurate representation of brightness of the sky. Although, I can explain that too, I would suggest that you try this link first: http://www.bozzograo.net/radiance/index.php?module=FAQ&func=dis...
By the way, which CIE document are you referring to for CIE sky definitions ?…