me work I was doing on DP on GH. Here are my conclusions:
- As Rhino is not a constraint-based modeller, assembly design without plugins(RhinoWorks or else) is just not possible. So as long as constraints will not be present in rhino... no constraints, no AEC.
- The list management that GH offers is 10 000 time more efficient and user friendly. So a good point would be to link all the list management tools with GH-like interface. In fact, for all operations that are not concerning assembly (wireframe generation for example), GH is way ahead in terms of speed IF you're not dealing with geodesic curves or parallels on surface, eventually boolean operations, that are really a weakness of Rhino in terms of precision and stability. You can also do amazing synchronised attributes datatrees quite easily in GH, that you can then synchronise via Excel with a massive product based on Catia without problem. It can easily save you a few days of work.
- Rhino does not handle pre-computation of the geometry without loading effectively that geometry, so you will not be able today to work on a product bigger than 2Gb (maybe 3) in rhino in any way, even on rhino v5 64 with 16Gb of Ram. With the constraint stuff, I really think it is the second bad point about rhino.
- As Jon said, I think Rhino has to be understood as a sketch-oriented application for the construction (this is not pejorative, that's what I personnaly prefere) in a sense that its usefulness is to allow research of design possibilities, that you can of course link afterwards with what you want, but too much basic options are missing to rhino to be really viable for AEC. I personnaly don't want to see geometrical sets to appear in rhino, it is absolutely useless considering grasshopper evolution towards clusters for exemple.
After that, in purely technical terms I would say that:
1) Possible, partially already working --> Clusters (waiting for updates)/nested definitions + SQL for attributes management on several working definitions.
2) --> I think there are two ideas here: a) exporting some dead geometry in an arborescence of files (can be done quite easily with LocalCode but it will remain dead. You can also create a definition based on dead geometry and update this geometry using the geometry cache. Of course if this geometry is automatically exported via LocalCode from a precedent definition, when you update the upper definitions then the modification is repercuted on all your model. Personnaly I think it is best not to do it in rhino. b) otherwise, it is just synchronisation of public attributes attached to existing parts/products, as I described previously.
3) Geometry Cache. You can also auto-loop you file using loading/unloading input geometry of your desifnition with LocalCode and some VB.
But maybe I am wrong on some points of course.
Best,
Thibault.
…
ng in Grasshopper?
As a general recommendation for developers in Grasshopper who are writing a part of their library which is performance-sensitive (please note: often the performance sensitive part is very limited) is to write it in C#, or maybe even C, or maybe even assembly :). Of course, the closer to the machine you will be, the easier it will be to harness all minimal optimizations. However, there is always a compromise between "getting things done" and "making them best" and this boundary is not very easy to catch, right?
If you want to have significant speed improvements for numerical calculations, I would at least recommend developing with C# in a compiled component using Visual Studio or SharpDevelop. The reason is: in order to provide the line number of possible errors, Grasshopper compiles C# scripts in debug mode! They will be much less optimized than what is possible even with today's technology. This does not preclude keeping the project open-source, if that is one of your goals.
Regarding the actual list:
1) Yes, the implied loop will probably be slower than just a simple for loop. This is because Grasshopper code has to keep track of more things than the ones you could be considering with your knowledge of of your very-special case. However, a factor of 10 is simply not acceptable and is likely a symptom of something else. In fact, I think I remember fixing a bug around that in Rhino WIP. However, it appears to be still slower also there. I've added a bugtracking item here.
2) If you are able to do all casts that are involved, and do them as Grasshopper does, please write that code that way. For example, if you supply a curve to an input with number hint, Grasshopper computes the length of the curve. There will have to be an "if" that checks if the input is a curve somewhere (or some similar construct). This aid for designers is what slows down the hint input.
3) Grasshopper has to keep side effects at bay. For example, components B and C are both connected to outputs of A. If you edit data in component B, and that data came from A you of course expect that data to be unchanged in C. This means that, for even lists of numbers, Grasshopper has to perform a deep copy of the output for each input. Otherwise, what happens if B sorts the list and C finds the index of the smallest number? This could be improved if GH components had some way of flagging themselves as non-data-mutating (constant). The fact that, by supplying special types, Grasshopper has no way of performing copies will likely speed things up. But be aware of possibly very annoying side effects creeping in if data is not immutable. Another option is performing the copy "optimally", just where you need it, because you know where your data is used. This is not information that is available to GH at present.
Does this help?
Thanks again for your input,
Giulio--Giulio Piacentinofor Robert McNeel & Associatesgiulio@mcneel.com…
ints. Anyway this is made for AEC purposes (wavy roofs/envelopes and the likes) and is classified as internal (but I could provide a "light" version).
To give you a very rough idea: C# rebuilds first any input list of nurbs > then samples the control points in a tree > then excludes (or not) the "peripheral" points (case: closed in U/V surfaces) > then "picks" some of them according a rather vast variety of options (~30) > then modifies these either individually (that's only possible with code and it's a bit tricky) or via any collection of push/pull attractors or randomly or ... > then "joins" the 2 sets together (modified + unmodified) > and finally does the new nurbs. Only 456 lines of code that one.
With regard the Dark Side: C# would be my recommendation (P is ala mode, mind) for a vast variety of reasons (less than 10% of them are GH related).
If you decide to cross the Rubicon:
How to go to hell (and stay there) in just 123 easy steps:
Step 1: get the cookies
The bible PlanA: C# In depth (Jon Skeet).
The bible PlanB: C# Step by step (John Sharp).
The bible PlanC: C# 5.0 (J/B Albahari) > my favorite
The reference: C# Language specs ECMA-334
The candidates:
C# Fundamentals (Nakov/Kolev & Co)
C# Head First (Stellman/Greene)
C# Language (Jones)
Step 2: read the cookies (computer OFF)
Step 3: re-read the cookies (computer OFF)
...
Step 121: open computer
Step 122: get the 30 steps to heaven (i.e. hell)
Step 123: shut down computer > change occupation/planet
May The Force (the Dark Option) be with you.
…
es at the beginning. But as I make changes to the input (or just hit the recompute button) the time it takes to execute increases. This has happened to me with other scripts I've written with the python component. Why does this happen? And how do I fix it? Does python hold onto data from one execution to the next? The only solution I have found is to relaunch Rhino. Even if I copy the component into a fresh grasshopper canvas, the computation time does not return to original.
The images below illustrate the time increase. I simply hit the recompute button between each pass. All inputs remain the same the whole time. There are 6400 curves being projected. I will say that with fewer curves, the increase in time is nonexistent or perceivable. (I have 24 GB RAM and it is did not even reach 50% of usage during the tests)
My python code:
import ghpythonlib.components as ghcompimport ghpythonlib.parallel
def project (tempc): tempresult=ghcomp.Project(tempc,B,D) return tempresult
a=ghpythonlib.parallel.run(project,C,True)
I have attached the GH file with the inputs internalized if anyone wants to try for themselves.
Pass 1= 444ms
Pass 5= 610ms
Pass 10= 908ms
Pass 15= 1.2s
Pass 20= 1.4s
…
Added by Lawrence Yun at 3:19pm on December 10, 2014
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…
arq, que se celebrará entre el 28 de Enero y el 1 de Febrero de 2013 en el Colegio de Arquitectos de Granada.
El taller está destinado a arquitectos, artistas y diseñadores, tanto como profesionales, como estudiantes de grado y posgrado, que, sin necesidad de haber tenido ningún contacto previo con entornos de programación o herramientas informáticas de dibujo paramétrico o generativo, están interesados en probar y experimentar con las opciones que nos pueden ofrecer a los diseñadores.
El taller está dividido en tres bloques:
Curso intensivo: del 28 de Enero al 30 de Febrero, en horario de mañana, de 10 a 14. Taller de proyectos: del 28 de Enero al 30 de Febrero, por la tarde, de 16 a 20; y el 31 de Febrero, durante todo el día.
Presentaciones: viernes 1 de Febrero, mañana y tarde.
Utilizaremos Grasshopper, el editor algorítmico asociado al software de modelado tridimensional y dibujo Rhinoceros, por su facilidad de aprendizaje, al tratarse de un entorno gráfico, facilidad de adquisición, al ser gratuito y haber disponible una versión de prueba de Rhinoceros también gratuita, y amplia difusión en los últimos años. Y lo emplearemos tanto como modelador, como conector entre otros softwares y varias disciplinas. Por este motivo, también utilizaremos algunos de sus plug-ins, como Geco, para análisis ambiental, Elk, para enlazarlo con OpenStreetMap o Kangaroo, para simulación de sistemas físicos.
Lo único que necesitas es un ordenador portátil (si no pudieras conseguir), hacer el ingreso con el importe correspondiente y mandarnos tus datos y el recibo bancario del ingreso a smartlabgranada@gmail.com. Puedes ver los detalles en el apartado de Inscripción. El resto del material, tanto software como hardware, lo ponemos nosotros.
Nuestro acercamiento a estas herramientas es entusiasta acerca del potencial creativo que pueden ofrecer a diseñadores y artistas, pero también crítico y especulativo. Nos alejamos tanto de una posición puramente formalista, como del estricto funcionalismo, a los que desde los últimos años frecuentemente se ha asociado a esta disciplina.…
Added by Miguel Vidal at 8:42am on January 19, 2013
and where the decimal place should be.
The reason it only shows the first 5 numbers that make up 1,000,000 is because anything smaller than 100 is considered insignificant when talking about 1 million. Think of it like this if 1 million represents an Olympic size swimming pool then 10 would represent the volume of a full tank of petrol for an average family car. You would have to stand there for an extremely long time to fill up the pool from a petrol pump.
It's important to know that these insignificant digits are still there for the purpose of calculations but are just not being displayed.
There are times when you may want to display these numbers in a format that makes more sense, for these occasions we can use the Format() function.
Format() Function
For versions BEFORE 0.9.0001 the VB Format Function is available through the Expression Components found on the Math Tab > Script Panel
Either by using the F input* or the Expressions Editor found on the Context Menu you can apply a format mask to the x input.
* except FxN
Anatomy of the formatting function above:
Format(..............................) <-- VB function
Format("........................."....) <-- Display String
Format("{0....................}"....) <-- Place Holder for first variable
Format("{0:0.000000000}"...) <-- Format Mask for 9 decimal places
Format("{0:0.000000000}", x) <-- Variable
This can be applied to points and their components:
For versions AFTER 0.9.0001 there is a dedicated Format Component or you can use the Expressions Components successor Evaluate.
For more information on the tags used in the Format Function see these links.
Standard formatting tags Custom formatting tags
WARNING:
If you format a number to be displayed in this way it becomes a string and will no longer have the complete Real number available for calculations. Always use the input to the format function for further requirements in calculations.…
ntrol points in Rhino.
Also, I forgot to mention in part 1 that when doing the directional subdivision, depending on how you drew your input mesh, there is a chance that it gets divided in the wrong direction, and you end up with something like this:
Which is not what we want.
The simple way to fix this is with the MeshTurn component, which rotates the direction of each face by one side:
Now we can use physical relaxation to smooth our mesh. In this example I show a simple tensile relaxation, so it will be negatively curved, but the same principles can be applied to all sorts of surfaces by using different combinations of forces.
The definition for the relaxation is attached below.
There are 3 main groups of forces used:
Planarization
For the mesh to be able to unroll properly into flat strips, we want each of the thin rectangles to be flat.
Springs
I already showed how the WarpWeft splitting can be used to assign different strengths to control the shape of a mesh here. Now because of the uneven subdivision we have very different numbers of edges in each direction, so the strengths have to account for this. Depending on the level of subdivision used and the shape you want to achieve, you may need to set the Weft stiffness to be 10 to 100 times that of the Warp.
Edge Smoothing
Because our subdivided mesh has square ends, we might not want to simply anchor the boundary, so I've shown how we can force them to become more circular, while still staying in place. Each boundary curve gets pulled onto its best fit plane, while also applying bending to round it out, and springs to keep it from shrinking.
(This part could also be achieved in other ways, such as pulling the boundary vertices to a curve)
When we run this relaxation, the shape should smooth out to something like this:
Play with the tensions and boundaries until you are happy with the result, wait for it to stop moving, then stop the timer. (Remember it is very important to always stop the timer once the relaxation has finished, before continuing working with the output, as otherwise Grasshopper becomes very slow, because Kangaroo is constantly resolving, even if no movement is visible).
If you want to try other shapes than tensile surfaces, you could also use forces such as bending, laplacian smoothing, or pulling to some target surface to control the form.
Next - Part 3 splitting and unrolling
…