aching my skill set here, but bare with me.
I want to create an animated facade of squares which rotate depending on a sequence of grey-scale images. I've got pretty far thanks to many discussions here, but have hit a blank with exporting my animated model to 3ds max.
Here's my GH script - it's a botch of 3 or 4 various things incorporating centipede at the start and end to get the animation.
All good and it works! It produces animations which I can sequence for presentations too thanks to it's bmp export, which is sort of a side-product.
What I have a problem is that the OBJs it produces error wildly when imported to max. eg in rhino it looks like
But when I've imported them to max it looks like
and as it animates it just gets longer and smaller.
NOW I reckon it might be because my model in grasshopper is 100 separate geometries and it'd like it to be a single one - but I've not achieved that.
Does anyone have any ideas how to solve this? My end result I would like to look like this rendered still from max, but animated.
Thankyou all! This also uses Firefly, so you might need that installed to see how my file works.
…
Added by chris parrott at 10:34am on September 11, 2015
t ''Morph'' turns Red saying ''Cannot morph from a degenerate box'' (image 2),
that's because every curve generates a box (image 3).
After what i check the Option ''Union'' box to make only one box for all the curves (image 4).
However, the result is aleatory and not accurate at all ... :/ (see image 6).I know you are developing Pufferfish and not ''Morph'' component, but recently you publish on instagram a video where i believe you could morph and Twist with success a collection of curves (please see image 7 and 8)...If you could give me a hint how that can be achieved, it would be awesome.(Piping/Meshing the curves with very small diameter will perhaps work and help for visualisation purposes, but i actually just need morphing Raw curves for fabrication purposes).Hope to read you very soon...Ghali,…
nd improvements. Many of the new features and components announced in the last release have become stable and have emerged from their WIP section. Additionally, after two years of work, we are happy to announce that we finally have full support of an OpenStudio connection within Honeybee, which has ushered in a whole host of new features, notably the modelling of detailed HVAC systems. As always you can download the new release from Food4Rhino. Make sure to remove the older version of Ladybug and Honeybee and update your scripts.
LADYBUG
1 - Solar Hot Water Components Out of WIP
After much beta-testing, bug-fixing, and general development, all of the Photovoltaic and Solar Hot Water components are now fully out of WIP! The main component is based on a Chengchu Yan's publication. Components have been added to Ladybug thanks to the efforts of Chengchu Yan and Djordje Spasic.. See Djorje’s original release post of the solar hot water components for more information on the components that just made it out of WIP.
2 - New Terrain Shading Mask Released in WIP
In addition to Djordje’s prolific addition of renewable energy components, he has also contributed a widely-useful component to generate terrain shading masks, which account for the shading of surrounding mountains/terrain in simulations. While initially added to assist the solar radiation radiation and renewable energy components, the component will undergo development to optimize it for energy and daylight simulations over the next few months. Another new component called Horizon Angles can be used to visualize and export horizon angles. You can test them out now by accessing them in the WIP section. For more information, see Djordje’s release post on the GH forum here.
3 - New Mesh Selector Component
After realizing that the Optimal Shade Creator component has applications to a whole range of analyses, it has now been re-branded as the Mesh Selector and has been optimized to work easily with these many analyses. Specifically, the component selects out the portion of a mesh that meets a given threshold. This can be the portion of a shade benefit analysis meeting a certain level of shade desirability, the portion of a radiation study meeting a certain level of fulx, the portion of a daylight analysis meeting a certain lux threshold, and much more!
4 - Solar Adjusted Temperature Now Includes Long Wave Radiation
Thanks to a question asked by Aymeric and a number of clarifications made by Djordje Spasic, the Solar Adjusted Temperature component now includes the ability to account for long-wave radiative loss to the sky in addition to it original capability to account for short wave radiation from the sun. As such, the component now includes all capabilities of similar outdoor comfort tools such as RayMan. The addition of this capability is also paralleled by the addition of a new horizontalInfraredRadiation output on the ImportEPW component. See the updated solar adjusted example file hereto see how to use the component properly.
5 - Support for both Log and Power Law Wind Profiles
In preparation for the future release of the Butterfly CFD-modelling insect, the Ladybug Wind Profile component now includes the option of either power law or log law wind profiles, which are both used extensively in CFD studies. Thanks goes to Theodoros Galanos for providing the formulas!
6 - New Radiant Asymmetry Comfort Components
Prompted by a suggestion from Christian Kongsgaard, Ladybug now includes components to calculate radiant asymmetry discomfort! For examples of how to use the components see this example file for spatial analysis of radiant asymmetry discomfort and this example for temporal analysis.
7 - Pedestrian Wind Comfort Component Released in WIP
In preparation for the impending release of the butterfly CFD-modelling insect, Djordje Spasic with assistance from Liam Harrington has contributed a component to evaluate outdoor discomfort and pedestrian safety. The component identifies if certain areas around the building are suitable for sitting, building entrances-exits, window shopping... based on its wind microclimate. Dangerous areas due to high wind speeds are also identified.You can check it out now in the WIP section.
HONEYBEE
1 - New HVAC Systems and Full OpenStudio Support
After a significant amount of development on the part of the OpenStudio team and two years of effort on the part of LB+HB developers, we (finally!) have full support for an OpenStudio connection within Honeybee. By this, we mean that any energy simulation property that can be assigned to a HBZone will be taken into account in the simulation run by the OpenStudio component. The connection to OpenStudio has brought with it several new capabilities. Most notably, you can now assign full HVAC systems and receive energy results in units of electricity and fuel instead of simple heating and cooling loads. This Honeybee release includes 14 built-in HVAC template systems that can be assigned to the zones, each of which can be customized:
0. Ideal Air Loads 1. PTAC | Residential 2. PTHP | Residential 3. Packaged Single Zone - AC 4. Packaged Single Zone - HP 5. Packaged VAV w/ Reheat 6. Packaged VAV w/ PFP Boxes 7. VAV w/ Reheat 8. VAV w/ PFP Boxes 9. Warm Air Furnace - Gas Fired 10.Warm Air Furnace - Electric 11.Fan Coil Units + DOAS 12.Active Chilled Beams + DOAS 13.Radiant Floors + DOAS 14.VRF + DOAS
Systems 1-10 are ASHRAE Baseline systems that represent much of what has been added to building stock over the last few decades while systems 11-14 are systems that are commonly being installed today to reduce energy use. Here is an example file showing how to assign these systems in Honeybee and interpret the results and here is an example showing how to customize the HVAC system specifications to a wide variety of cases. To run the file, you will need to have OpenStudio installed and you can download and install OpenStudio from here.
In addition to these template systems within Honeybee, the OpenStudio interface includes hundreds of HVAC components to build your own custom HVAC systems. OpenStudio also has a growing number of user-contributed HVAC system templates that have been integrated into a set of scripts called "Measures" that you can apply to your OpenStudio model within the OpenStudio interface. You can find these system templates by searching for them in the building components library. Here is a good tutorial video on how to apply measures to your model within the OpenStudio interface. Honeybee includes a component that runs these measures from Grasshopper (without having to use the OpenStudio interface), which you can see a demo video of here. However, this component is currently in WIP as OpenStudio team is still tweaking the file structure of measures and it is fairly safe to estimate that, by the next stable release of Honeybee, we will have full support of OpenStudio measures within GH.
2 - Phasing Out IDF Exporter
With the connection to OpenStudio now fully established, this release marks the start of a transition away from exporting directly to EnergyPlus and the beginning of Honeybee development that capitalizes on OpenStudio’s development. As such THIS WILL BE THE LAST STABLE RELEASE THAT INCLUDES THE HONEYBEE_RUN ENERGY SIMULATION COMPONENT.
The Export to OpenStudio component currently does everything that the Run Energy Simulation component does and, as such, it is intended that all GH definitions using the Run Energy Simulation component should replace it with the OpenStudio component. You can use the same Read EP Result components to import the results from the OpenStudio component and you can also use the same Energy Sim Par/Generate EP Output components to customize the parameters of the simulation. The only effective difference between the two components is that the OpenStudio component enables the modeling of HVAC and exports the HBZones to an .osm file before converting it to an EnergyPlus .idf.
For the sake of complete clarity, we should state that OpenStudio is simply an interface for EnergyPlus and, as such, the same calculation engine is under the hood of both the Export to OpenStudio component and the Run Energy Simulation component. At present, you should get matching energy simulation results between the Run Energy Simulation component and a run of the same zones with the OpenStudio component (using an ideal air system HVAC).
All of this is to say that you should convert your GH definitions that use the Run Energy Simulation component to have the OpenStudio component and this release is the best time to do it (while the two components are supported equally). Additionally, with this version of Honeybee you will no longer need to install EnergyPlus before using Honeybee and you will only need to install OpenStudio (which includes EnergyPlus in the install).
3 - New Schedule Generation Components
Thanks to the efforts of Antonello Di Nunzio, we now have 2 new components that ease the creation of schedule-generation in Honeybee. The new components make use of the native Grasshopper “Gener Pool” component to give a set of sliders for each hour of the day. Additionally, Antonello has included an annual schedule component that contains a dictionary of all holidays of every nearly every nation (phew!). Finally, this annual schedule component can output schedules in the text format recognized by EnergyPlus, which allows them to be written directly into the IDF instead of a separate CSV file. This will significantly reduce the size of files needed to run simulations and can even reduce the number of components on your canvas that are needed to add custom schedules. For more information, see Antonello’s explanatory images here and Antonello's example file here. You can also see a full example file of how to apply the schedules to energy simulations here.
4 - EnergyPlus Lookup Folder, Re-run OSM/IDF, and Read Result Dictionary
With the new capabilities of OpenStudio, we have also added a number of components to assist with managing all of the files that you get from the simulation. In particular, Abraham Yezioro has added a Lookup EnergyPlus Folder component that functions very similarly to the Lookup Daylight Folder component. This way, you can run an Energy simulation once and explore the results separately. Furthermore, we have added components to Re-Run OpenStudio .osm files or EnergyPlus .idf files within Grasshopper. These components are particularly useful if you edit these .osm or .idf files outside of Honeybee and want to re-run them to analyze their results in Grasshopper. Lastly, a component has been added to parse the .rdd (or Result Data Dictionary) file that EnergyPlus produces, enabling you to see all of the possible outputs that you can request from a given simulation.
5 - Electric Lighting Components Out of WIP
After Sarith Subramaniam’s initial components to model electric lights with Radiance in the last release, we are happy to report that they have been fully tested and are out of WIP. Improvements include support for all types of light fixture geometries and the ability to use the components in a more “Grasshoppery” list-like fashion. See Sarith’s original release post for more information and several example files showing how to use the components can be found here. 1 , 2 , 3 .
6 - Improvements to THERM Components
A number of bug fixes and improvements have been made to the THERM components in order to make their application more flexible and smooth. Special thanks is due to Derin Yilmaz , Mel King , Farnaz , Ben (@benmo1) , and Abraham Yezioro for all of the great feedback in the process of improving these components.
7 - HBObject Transform Components
After some demand for components that can ease the generation of buildings with modular zone types, two components to transform HBObjects with all of their properties have been added to the 00 | Honeybee section. The components allow you to produce copies of zones that are translated or rotated from the original position.
8 - Comfort Maps Supports PET and Integration of CFD Results
Thanks to the addition of the ‘Physiological Equivalent Temperature’ (PET) component by Djordje Spasic in the last stable release, it is now possible to make comfort maps of PET with Honeybee. PET is particularly helpful for evaluating OUTDOOR comfort with detailed wind fields at a high spatial resolution. As such, the new PET recipe has also been optimized for integration with CFD results. The windSpeed_ input can now accept the file path to a .csv file that is organized with 8760 values in each column and a number of columns that correspond to the number of test points. Components to generate this csv from Butterfly CFD results will be coming in later releases. Stay tuned!
As always let us know your comments and suggestions.
Enjoy!Ladybug Analysis Tools Development Team
…
t file** - ply file with just x,y,z locations. I got it from a 3d scanner. Here is how first few lines of file looks like - ply format ascii 1.0 comment VCGLIB generated element vertex 6183 property float x property float y property float z end_header -32.3271 -43.9859 11.5124 -32.0631 -43.983 11.4945 12.9266 -44.4913 28.2031 13.1701 -44.4918 28.2568 13.4138 -44.4892 28.2531 13.6581 -44.4834 28.1941 13.9012 -44.4851 28.2684 ... ... ... In case you need the data - please email me on **nisha.m234@gmail.com**. **Algorithm:** I am trying to find principal curvatures for extracting the ridges and valleys. The steps I am following is: 1. Take a point x 2. Find its k nearest neighbors. I used k from 3 to 20. 3. average the k nearest neighbors => gives (_x, _y, _z) 4. compute covariance matrix 5. Now I take eigen values and eigen vectors of this covariance matrix 6. I get u, v and n here from eigen vectors. u is a vector corresponding to largest eigen value v corresponding to 2nd largest n is 3rd smallest vector corresponding to smallest eigen value 7. Then for transforming the point(x,y,z) I compute matrix T T = [ui ] [u ] [x - _x] [vi ] = [v ] x [y - _y] [ni ] [n ] [z - _z] 8. for each i of the k nearest neighbors:<br> [ n1 ] [u1*u1 u1*v1 v1*v1] [ a ]<br> [ n2 ] = [u2*u2 u2*v2 v2*v2] [ b ] <br> [... ] [ ... ... ... ] [ c ] <br> [ nk ] [uk*uk uk*vk vk*vk]<br> Solve this for a, b and c with least squares 9. this equations will give me a,b,c 10. now I compute eigen values of matrix [a b b a ] 11. This will give me 2 eigen values. one is Kmin and another Kmax. **My Problem:** The output is no where close to finding the correct Ridges and Valleys. I am totally Stuck and frustrated. I am not sure where exactly I am getting it wrong. I think the normal's are not computed correctly. But I am not sure. I am very new to graphics programming and so this maths, normals, shaders go way above my head. Any help will be appreciated. **PLEASE PLEASE HELP!!** **Resources:** I am using Visual Studio 2010 + Eigen Library + ANN Library. **Other Options used** I tried using MeshLab. I used ball pivoting triangles remeshing in MeshLab and then applied the polkadot3d shader. If correctly identifies the ridges and valleys. But I am not able to code it. **My Function:** //the function outputs to ply file void getEigen() { int nPts; // actual number of data points ANNpointArray dataPts; // data points ANNpoint queryPt; // query point ANNidxArray nnIdx;// near neighbor indices ANNdistArray dists; // near neighbor distances ANNkd_tree* kdTree; // search structure //for k = 25 and esp = 2, seems to got few ridges queryPt = annAllocPt(dim); // allocate query point dataPts = annAllocPts(maxPts, dim); // allocate data points nnIdx = new ANNidx[k]; // allocate near neigh indices dists = new ANNdist[k]; // allocate near neighbor dists nPts = 0; // read data points ifstream dataStream; dataStream.open(inputFile, ios::in);// open data file dataIn = &dataStream; ifstream queryStream; queryStream.open("input/query.
pts", ios::in);// open data file queryIn = &queryStream; while (nPts < maxPts && readPt(*dataIn, dataPts[nPts])) nPts++; kdTree = new ANNkd_tree( // build search structure dataPts, // the data points nPts, // number of points dim); // dimension of space while (readPt(*queryIn, queryPt)) // read query points { kdTree->annkSearch( // search queryPt, // query point k, // number of near neighbors nnIdx, // nearest neighbors (returned) dists, // distance (returned) eps); // error bound double x = queryPt[0]; double y = queryPt[1]; double z = queryPt[2]; double _x = 0.0; double _y = 0.0; double _z = 0.0; #pragma region Compute covariance matrix for (int i = 0; i < k; i++) { _x += dataPts[nnIdx[i]][0]; _y += dataPts[nnIdx[i]][1]; _z += dataPts[nnIdx[i]][2]; } _x = _x/k; _y = _y/k; _z = _z/k; double A[3][3] = {0,0,0,0,0,0,0,0,0}; for (int i = 0; i < k; i++) { double X = dataPts[nnIdx[i]][0]; double Y = dataPts[nnIdx[i]][1]; double Z = dataPts[nnIdx[i]][2]; A[0][0] += (X-_x) * (X-_x); A[0][1] += (X-_x) * (Y-_y); A[0][2] += (X-_x) * (Z-_z); A[1][0] += (Y-_y) * (X-_x); A[1][1] += (Y-_y) * (Y-_y); A[1][2] += (Y-_y) * (Z-_z); A[2][0] += (Z-_z) * (X-_x); A[2][1] += (Z-_z) * (Y-_y); A[2][2] += (Z-_z) * (Z-_z); } MatrixXd C(3,3); C <<A[0][0]/k, A[0][1]/k, A[0][2]/k, A[1][0]/k, A[1][1]/k, A[1][2]/k, A[2][0]/k, A[2][1]/k, A[2][2]/k; #pragma endregion EigenSolver<MatrixXd> es(C); MatrixXd Eval = es.eigenvalues().real().asDiagonal(); MatrixXd Evec = es.eigenvectors().real(); MatrixXd u,v,n; double a = Eval.row(0).col(0).value(); double b = Eval.row(1).col(1).value(); double c = Eval.row(2).col(2).value(); #pragma region SET U V N if(a>b && a>c) { u = Evec.row(0); if(b>c) { v = Eval.row(1); n = Eval.row(2);} else { v = Eval.row(2); n = Eval.row(1);} } else if(b>a && b>c) { u = Evec.row(1); if(a>c) { v = Eval.row(0); n = Eval.row(2);} else { v = Eval.row(2); n = Eval.row(0);} } else { u = Eval.row(2); if(a>b) { v = Eval.row(0); n = Eval.row(1);} else { v = Eval.row(1); n = Eval.row(0);} } #pragma endregion MatrixXd O(3,3); O <<u, v, n; MatrixXd UV(k,3); VectorXd N(k,1); for( int i=0; i<k; i++) { double x = dataPts[nnIdx[i]][0];; double y = dataPts[nnIdx[i]][1];; double z = dataPts[nnIdx[i]][2];; MatrixXd X(3,1); X << x-_x, y-_y, z-_z; MatrixXd T = O * X; double ui = T.row(0).col(0).value(); double vi = T.row(1).col(0).value(); double ni = T.row(2).col(0).value(); UV.row(i) << ui * ui, ui * vi, vi * vi; N.row(i) << ni; } Vector3d S = UV.colPivHouseholderQr().solve(N); MatrixXd II(2,2); II << S.row(0).value(), S.row(1).value(), S.row(1).value(), S.row(2).value(); EigenSolver<MatrixXd> es2(II); MatrixXd Eval2 = es2.eigenvalues().real().asDiagonal(); MatrixXd Evec2 = es2.eigenvectors().real(); double kmin, kmax; if(Eval2.row(0).col(0).value() < Eval2.row(1).col(1).value()) { kmin = Eval2.row(0).col(0).value(); kmax = Eval2.row(1).col(1).value(); } else { kmax = Eval2.row(0).col(0).value(); kmin = Eval2.row(1).col(1).value(); } double thresh = 0.0020078; if (kmin < thresh && kmax > thresh ) cout << x << " " << y << " " << z << " " << 255 << " " << 0 << " " << 0 << endl; else cout << x << " " << y << " " << z << " " << 255 << " " << 255 << " " << 255 << endl; } delete [] nnIdx; delete [] dists; delete kdTree; annClose(); } Thanks, NISHA…
ntación en distintos procesos del Diseño. Se abordaran los conceptos basicos y la metodologia para abordar problemas de diseño a traves del desarrollo de Herramientas Algorítmicas mediante un proceso de programacion visual.
Como nuestras herramientas de trabajo se utilizara Rhinoceros+Grasshopper+Wea verBird
Instructor: Leonardo Nuevo Arenas[Complex Geometry]
Fechas: 5 y 6 de Noviembre 2011
Lugar: Sebastian Bach 5411, Col. La Estancia, Zapopan Jalisco.http://g.co/maps/nc7g6
Cupo: Limitado a 10 plazas
Costo:
Profesionistas: $3,300.00
Estudiantes: $2,800.00
Fecha limite de pago: Viernes 28 de Octubre
Importante:
Los participantes deberán traer su propia Laptop con todo el software y actualizaciones (originales o versiones de demostración oficiales) previamente instaladas. (Se fijara una fecha unos días antes para revisar que todos los equipos estén en orden y listos para trabajar). Si planeas venir de fuera de la ciudad contactanos y te pondremos en contacto con otras personas que también vayan a hacerlo para en caso de desearlo puedan compartir su lugar de estancia.
Contacto:
Complex Geometry
Leo[33 3956 9209]
[nuarle@msn.com]
FARA.Architectural Lab
Aye[33 1050 3482]
[ayeritza.fara@gmail.com]
Para hacer tu pago via deposito o transferencia electronica:
Banamex
No. Cta. 6035264
Sucursal. 0644
CLABE interbancaria: 002671064460352648
Beneficiario: Leonardo Nuevo Arenas
Al hacer el movimiento bancario favor de enviarnos el comprobante (scanner del boucher o captura de pantalla de la transferencia) a los correos de contacto que aparecen mas arriba.
http://cgeometry.blogspot.com/…
mething? I think it would be very useful to have a mapping of light intensity over the field of view of the used camera, and possibly and option to overlay it on the luminance mapping. It would in a very visual way provide information about contrast and glare.
Doesn't the falsecolor option already do that for luminance mappings? If not can you post an image/screenshot of such a mapping from Dialux/AGI32 or any other software.
4. It's just a shoebox type simulation. 11x11 luminaires pointing down to simple materials. The default elapsed time was 3m40s. I have found the _RadParameters component meanwhile, and got it down to 0m30s. I have noticed that the simulation doesn't tax multiple cpu threads completely, most of the time cpu is at 25% during execution.
The under-utlization of CPUs is a known issue with Radiance (the calculation engine) on Windows based systems. Unfortunately there isn't much that can be done about it at the moment.
5. Is it possible to map different degrees of translucency, diffuse color, absorptance, reflectance, etc..., by means of a bitmap image, expression, or other?
6. There is a feature that I consider absolutely necessary (and I haven't found it yet), which is the emitting surface feature, with the ability to stipulate homogeneous intensity with luminance values (in cd/m^2) or flux; and by mapped distribution of intensities or luminances (in cd or cd/m^2).
By emitting surface I don't mean just a flat rectangular plane, such as an area light. It would be absolutely amazing! to perform photometric analysis on irregular and convoluted shapes and the light falling on neighbouring surfaces. 3DS Max with MentalRay provides similar functionality, but without the power of GH + HB.
In the image below, the HB logo is assigned as a texture to a glass which then creates a pattern of that on the wall when daylight falls on it.
ln the image below the light from the Batman logo illumninates the scene.
The images above were Rendered with Radiance. While these things are possible with Radiance, and therefore HB, the reason why they aren't incorporated into the code is that these effects are not "physically based" and are not rooted in reality. Radiance is arguably the most intensively tested and validated lighting simulation software in the world. However, once we start applying such "magic" to it, the results from it are no longer reliable and therefore no different from other photorealistic engines such as V-ray, Mental-Ray etc. …
greatly appreciate it!!
You can write the number of the question and write your answer next to it, example:
1) a
2) c
3) a) Washington University in St. Louis
4) 2 weeks (1week+1week shipping)
5) 130
6) b
7) b
The survey questions are as follows:
1)
Did you 3D print before?
5)
How much did it cost (in dollars)?
a.
Yes, for a school project
a.
Between 20 & 50
b.
Yes, for a personal project
b.
Between 50 & 80
c.
Between 80 & 120
2)
Print size
d.
Please specify if otherwise: _____ dollars
a.
Between 2 & 6 cubic inches
b.
Between 6 & 12 cubic inches
6)
Do you think the price was expensive?
c.
Between 12 & 20 cubic inches
a.
Not at all
d.
Please specify if otherwise: ____cubic inches
b.
A little bit expensive
c.
Very expensive
3)
Where did you print your object?
a.
School
7)
Were you satisfied with the printed object?
b.
Outside school: _________________
a.
Yes, it was a great print without problems
b.
Not bad, some issues
4)
How long did it take to print?
c.
I was not satisfied, very bad quality
a.
___ days
b.
___ weeks
Thank you very much to all!!
PS: If you did many 3D prints, you can post multiple answers.
Wassef…
is set up to manipulate strings into an STL file that is quite different from how Grasshopper defines meshes, in that an STL seems to define each face by XYZ points, Grasshopper wants a single list of all vertex points and then has an allied lists of topological connectivity according to vertex number, so for now I just hacked it to spit out points minus so many duplicates it generates for STL:
Right now it has an internal 3D trigonometric function I added input sliders to control, that creates surfaces that look a lot like molecular orbitals.
So how do I make a mesh? I failed to make a single mesh face from each STL face since AddMesh seems to want a list, so I tried making a single list and matching it with a simple ((1,2,3),(4,5,6),(7,8,9)...) array of connectivity but it hasn't worked yet since the STL list of vertices has duplicates that won't work for Grasshopper and removing the duplicates scrambles the connectivity relation.
After some work on this and seeing the output, I figure I could just randomly populate the mathematical function with points instead, unless it really gives a better mesh result than other routines. I'm not sure what to do with it yet, even if I get the mesh figured out.
import rhinoscriptsyntaximport RhinoPOINTS_CONTAINER =[]POINTS = []class Vector: # struct XYZ def __init__(self,x,y,z): self.x=x self.y=y self.z=z def __str__(self): return str(self.x)+" "+str(self.y)+" "+str(self.z) class Gridcell: # struct GRIDCELL def __init__(self,p,n,val): self.p = p # p=[8] self.n = n # n=[8] self.val = val # val=[8] class Triangle: # struct TRIANGLE def __init__(self,p1,p2,p3): self.p = [p1, p2, p3] # vertices # HACK TO GRAB VERTICES FOR PYTHON OUTPUT POINTS_CONTAINER.append( (p1.x,p1.y,p1.z) ) POINTS_CONTAINER.append( (p2.x,p2.y,p2.z) ) POINTS_CONTAINER.append( (p3.x,p3.y,p3.z) )# return a 3d list of values def readdata(f=lambda x,y,z:x*x+y*y+z*z,size=5.0,steps=11): m=int(steps/2) ki = [] for i in range(steps): kj = [] for j in range(steps): kd=[] for k in range(steps): kd.append(f(size*(i-m)/m,size*(j-m)/m,size*(k-m)/m)) kj.append(kd) ki.append(kj) return ki from math import sin,cos,exp,atan2 def lobes(x,y,z): try: theta = atan2(x,y) # sin t = o except: theta = 0 try: phi = atan2(z,y) except: phi = 0 r = x*x+y*y+z*z ct=cos(PARAMETER_A * theta) cp=cos(PARAMETER_B * phi) return ct*ct*cp*cp*exp(-r/10) def main(): data = readdata(lobes,10,40) isolevel = 0.1 #print(data) triangles=[] for i in range(len(data)-1): for j in range(len(data[i])-1): for k in range(len(data[i][j])-1): p=[None]*8 val=[None]*8 #print(i,j,k) p[0]=Vector(i,j,k) val[0] = data[i][j][k] p[1]=Vector(i+1,j,k) val[1] = data[i+1][j][k] p[2]=Vector(i+1,j+1,k) val[2] = data[i+1][j+1][k] p[3]=Vector(i,j+1,k) val[3] = data[i][j+1][k] p[4]=Vector(i,j,k+1) val[4] = data[i][j][k+1] p[5]=Vector(i+1,j,k+1) val[5] = data[i+1][j][k+1] p[6]=Vector(i+1,j+1,k+1) val[6] = data[i+1][j+1][k+1] p[7]=Vector(i,j+1,k+1) val[7] = data[i][j+1][k+1] grid=Gridcell(p,[],val) triangles.extend(PolygoniseTri(grid,isolevel,0,2,3,7)) triangles.extend(PolygoniseTri(grid,isolevel,0,2,6,7)) triangles.extend(PolygoniseTri(grid,isolevel,0,4,6,7)) triangles.extend(PolygoniseTri(grid,isolevel,0,6,1,2)) triangles.extend(PolygoniseTri(grid,isolevel,0,6,1,4)) triangles.extend(PolygoniseTri(grid,isolevel,5,6,1,4)) def t000F(g, iso, v0, v1, v2, v3): return [] def t0E01(g, iso, v0, v1, v2, v3): return [Triangle( VertexInterp(iso,g.p[v0],g.p[v1],g.val[v0],g.val[v1]), VertexInterp(iso,g.p[v0],g.p[v2],g.val[v0],g.val[v2]), VertexInterp(iso,g.p[v0],g.p[v3],g.val[v0],g.val[v3])) ] def t0D02(g, iso, v0, v1, v2, v3): return [Triangle( VertexInterp(iso,g.p[v1],g.p[v0],g.val[v1],g.val[v0]), VertexInterp(iso,g.p[v1],g.p[v3],g.val[v1],g.val[v3]), VertexInterp(iso,g.p[v1],g.p[v2],g.val[v1],g.val[v2])) ] def t0C03(g, iso, v0, v1, v2, v3): tri=Triangle( VertexInterp(iso,g.p[v0],g.p[v3],g.val[v0],g.val[v3]), VertexInterp(iso,g.p[v0],g.p[v2],g.val[v0],g.val[v2]), VertexInterp(iso,g.p[v1],g.p[v3],g.val[v1],g.val[v3])) return [tri,Triangle( tri.p[2], VertexInterp(iso,g.p[v1],g.p[v2],g.val[v1],g.val[v2]), tri.p[1]) ] def t0B04(g, iso, v0, v1, v2, v3): return [Triangle( VertexInterp(iso,g.p[v2],g.p[v0],g.val[v2],g.val[v0]), VertexInterp(iso,g.p[v2],g.p[v1],g.val[v2],g.val[v1]), VertexInterp(iso,g.p[v2],g.p[v3],g.val[v2],g.val[v3])) ] def t0A05(g, iso, v0, v1, v2, v3): tri = Triangle( VertexInterp(iso,g.p[v0],g.p[v1],g.val[v0],g.val[v1]), VertexInterp(iso,g.p[v2],g.p[v3],g.val[v2],g.val[v3]), VertexInterp(iso,g.p[v0],g.p[v3],g.val[v0],g.val[v3])) return [tri,Triangle( tri.p[0], VertexInterp(iso,g.p[v1],g.p[v2],g.val[v1],g.val[v2]), tri.p[1]) ] def t0906(g, iso, v0, v1, v2, v3): tri=Triangle( VertexInterp(iso,g.p[v0],g.p[v1],g.val[v0],g.val[v1]), VertexInterp(iso,g.p[v1],g.p[v3],g.val[v1],g.val[v3]), VertexInterp(iso,g.p[v2],g.p[v3],g.val[v2],g.val[v3])) return [tri, Triangle( tri.p[0], VertexInterp(iso,g.p[v0],g.p[v2],g.val[v0],g.val[v2]), tri.p[2]) ] def t0708(g, iso, v0, v1, v2, v3): return [Triangle( VertexInterp(iso,g.p[v3],g.p[v0],g.val[v3],g.val[v0]), VertexInterp(iso,g.p[v3],g.p[v2],g.val[v3],g.val[v2]), VertexInterp(iso,g.p[v3],g.p[v1],g.val[v3],g.val[v1])) ] trianglefs = {7:t0708,8:t0708,9:t0906,6:t0906,10:t0A05,5:t0A05,11:t0B04,4:t0B04,12:t0C03,3:t0C03,13:t0D02,2:t0D02,14:t0E01,1:t0E01,0:t000F,15:t000F} def PolygoniseTri(g, iso, v0, v1, v2, v3): triangles = [] # Determine which of the 16 cases we have given which vertices # are above or below the isosurface triindex = 0; if g.val[v0] < iso: triindex |= 1 if g.val[v1] < iso: triindex |= 2 if g.val[v2] < iso: triindex |= 4 if g.val[v3] < iso: triindex |= 8 return trianglefs[triindex](g, iso, v0, v1, v2, v3) def VertexInterp(isolevel,p1,p2,valp1,valp2): if abs(isolevel-valp1) < 0.00001 : return(p1); if abs(isolevel-valp2) < 0.00001 : return(p2); if abs(valp1-valp2) < 0.00001 : return(p1); mu = (isolevel - valp1) / (valp2 - valp1) return Vector(p1.x + mu * (p2.x - p1.x), p1.y + mu * (p2.y - p1.y), p1.z + mu * (p2.z - p1.z)) if __name__ == "__main__": main() # GRASSHOPPER PYTHON OUTPUTPOINTS = rhinoscriptsyntax.AddPoints(POINTS_CONTAINER)POINTS = rhinoscriptsyntax.CullDuplicatePoints(POINTS)…
nd B) daylight autonomy for a single room. A and B are therefore the conflicting objectives, and are connected to the O of octopus component. The geometry iterated is that of a window, on one of the rooms' facades.
I have a grasshopper definition that iterates the window by changing:
1. Window height
2. Window sill height
3. Window width
4. Window position from one side of the wall
1,2,3,4 are therefore the genes. A combination of these genes is a complete window, which is the chromoshome, that i will from now on call solution. All genes are connected to the G of octopus component.
Now regarding the octopus settings, i have these questions so that i can properly calibrate the settings (mutarion rate, crossover rate etc):
1.In the beginning of the octopus simulation, how many are the random solutions generated? (By random i mean totally random, not resulting solutions from mutation or crossover of previous solutions, i am talking about the very first generation). Is this number connected to the population size? Is it 6? How is it defined by octopus? Can somebody control it?
2.The first generation finishes when the number of "individuals to be evaluated" is reached. Then octopus jumps to the second generation. To do so, it keeps a specific number of solutions of the first generation, the so called elite. What is the number of these elite? Is it elitism x population size?
3.The SPEA2 original paper describes step wise the algorithm loop. During the loop, a number of solutions is stored in the elite domain, and from that domain, a number of solutions is used for mating. There are therefore two numbers, one that defines the number of solutions to enter the elite domain, and one that defines the number of solutions to be inserted in the mating pool. In octopus i only see elitism as a setting, which i am guessing is what defines the number of solutions to enter the elite domain. Is that true? How do i define the number of solutions to be copied in the mating pool, where mutation and crossover will occur? This number should be called tournament size, but i can't seem to find it..
4.Why is it that DURING one generation, the number of "individuals to be evaluated" can decrease? Is it because octopus finds out that there are no more possible solutions? (i am using discrete values for the genes)
5.The gene of window width, represented by a grasshopper slider, has 4 possible values: 0,1,2,3. Assuming that the mutation rate is 0.5. Does this mean that mutation of the gene can happen to an extent of 0.5 x 4 = 2? Meaning that the slider position can change for 0 to 2 or from 3 to 1 etc?
6.The mutation probability is dictating whether or not a gene will be mutated, or whether or not the whole solution will be mutated? So for instance, with a mutation probability of 0.5, does it mean that 2 out of the 4 genes are going to be mutated, or 2 out of 4 solutions is going to be mutated. If its the second case, then how is mutation divided between the different genes? Meaning, which of the 4 genes is going to get mutated? Is it random? Is it for all 4 genes?
7.Crossover can occur between 2 subsequent solutions. Crossover rate dictates whether or not crossover will take place? If so, then, assuming that it was chosen for crossover to take place between 2 solutions, which of the genes are going to be exchanged. I mean how many, out of the 4 genes (height, sill height, width, position). Is it random?
8.After clarifying the previous 7 questions, i can run a simulation. Then, is there an indicative number that i can be monitoring, to see that no more generations are required? I know that a good pareto has to be short, with a lot of solutions and with a uniform distribution. But is there a specific number output somewhere, that can inform me that a good pareto has more or less been generated? If there is such indicator...
Thank you all,
i hope this can help others as well,
Iason
…
ng is deciding how and where to store your data. If you're writing textual code using any one of a huge number of programming languages there are a lot of different options, each with its own benefits and drawbacks. Sometimes you just need to store a single data point. At other times you may need a list of exactly one hundred data points. At other times still circumstances may demand a list of a variable number of data points.
In programming jargon, lists and arrays are typically used to store an ordered collection of data points, where each item is directly accessible. Bags and hash sets are examples of unordered data storage. These storage mechanisms do not have a concept of which data comes first and which next, but they are much better at searching the data set for specific values. Stacks and queues are ordered data structures where only the youngest or oldest data points are accessible respectively. These are popular structures for code designed to create and execute schedules. Linked lists are chains of consecutive data points, where each point knows only about its direct neighbours. As a result, it's a lot of work to find the one-millionth point in a linked list, but it's incredibly efficient to insert or remove points from the middle of the chain. Dictionaries store data in the form of key-value pairs, allowing one to index complicated data points using simple lookup codes.
The above is a just a small sampling of popular data storage mechanisms, there are many, many others. From multidimensional arrays to SQL databases. From readonly collections to concurrent k-dTrees. It takes a fair amount of knowledge and practice to be able to navigate this bewildering sea of options and pick the best suited storage mechanism for any particular problem. We did not wish to confront our users with this plethora of programmatic principles, and instead decided to offer only a single data storage mechanism.*
Data storage in Grasshopper
In order to see what mechanism would be optimal for Grasshopper, it is necessary to first list the different possible ways in which components may wish to access and store data, and also how families of data points flow through a Grasshopper network, often acquiring more complexity over time.
A lot of components operate on individual values and also output individual values as results. This is the simplest category, let's call it 1:1 (pronounced as "one to one", indicating a mapping from single inputs to single outputs). Two examples of 1:1 components are Subtraction and Construct Point. Subtraction takes two arguments on the left (A and B), and outputs the difference (A-B) to the right. Even when the component is called upon to calculate the difference between two collections of 12 million values each, at any one time it only cares about three values; A, B and the difference between the two. Similarly, Construct Point takes three separate numbers as input arguments and combines them to form a single xyz point.
Another common category of components create lists of data from single input values. We'll refer to these components as 1:N. Range and Divide Curve are oft used examples in this category. Range takes a single numeric domain and a single integer, but it outputs a list of numbers that divide the domain into the specified number of steps. Similarly, Divide Curve requires a single curve and a division count, but it outputs several lists of data, where the length of each list is a function of the division count.
The opposite behaviour also occurs. Common N:1 components are Polyline and Loft, both of which consume a list of points and curves respectively, yet output only a single curve or surface.
Lastly (in the list category), N:N components are also available. A fair number of components operate on lists of data and also output lists of data. Sort and Reverse List are examples of N:N components you will almost certainly encounter when using Grasshopper. It is true that N:N components mostly fall into the data management category, in the sense that they are mostly employed to change the way data is stored, rather than to create entirely new data, but they are common and important nonetheless.
A rare few components are even more complex than 1:N, N:1, or N:N, in that they are not content to operate on or output single lists of data points. The Divide Surface and Square Grid components want to output not just lists of points, but several lists of points, each of which represents a single row or column in a grid. We can refer to these components as 1:N' or N':1 or N:N' or ... depending on how the inputs and outputs are defined.
The above listing of data mapping categories encapsulate all components that ship with Grasshopper, though they do not necessarily minister to all imaginable mappings. However in the spirit of getting on with the software it was decided that a data structure that could handle individual values, lists of values, and lists of lists of values would solve at least 99% of the then existing problems and was thus considered to be a 'good thing'.
Data storage as the outcome of a process
If the problems of 1:N' mappings only occurred in those few components to do with grids, it would probably not warrant support for lists-of-lists in the core data structure. However, 1:N' or N:N' mappings can be the result of the concatenation of two or more 1:N components. Consider the following case: A collection of three polysurfaces (a box, a capped cylinder, and a triangular prism) is imported from Rhino into Grasshopper. The shapes are all exploded into their separate faces, resulting in 6 faces for the box, 3 for the cylinder, and 5 for the prism. Across each face, a collection of isocurves is drawn, resembling a hatching. Ultimately, each isocurve is divided into equally spaced points.
This is not an unreasonably elaborate case, but it already shows how shockingly quickly layers of complexity are introduced into the data as it flows from the left to the right side of the network.
It's no good ending up with a single huge list containing all the points. The data structure we use must be detailed enough to allow us to select from it any logical subset. This means that the ultimate data structure must contain a record of all the mappings that were applied from start to finish. It must be possible to select all the points that are associated with the second polysurface, but not the first or third. It must also be possible to select all points that are associated with the first face of each polysurface, but not any subsequent faces. Or a selection which includes only the fourth point of each division and no others.
The only way such selection sets can be defined, is if the data structure contains a record of the "history" of each data point. I.e. for every point we must be able to figure out which original shape it came from (the cube, the cylinder or the prism), which of the exploded faces it is associated with, which isocurve on that face was involved and the index of the point within the curve division family.
A flexible mechanism for variable history records.
The storage constraints mentioned so far (to wit, the requirement of storing individual values, lists of values, and lists of lists of values), combined with the relational constraints (to wit, the ability to measure the relatedness of various lists within the entire collection) lead us to Data Trees. The data structure we chose is certainly not the only imaginable solution to this problem, and due to its terse notation can appear fairly obtuse to the untrained eye. However since data trees only employ non-negative integers to identify both lists and items within lists, the structure is very amenable to simple arithmetic operations, which makes the structure very pliable from an algorithmic point of view.
A data tree is an ordered collection of lists. Each list is associated with a path, which serves as the identifier of that list. This means that two lists in the same tree cannot have the same path. A path is a collection of one or more non-negative integers. Path notation employs curly brackets and semi-colons as separators. The simplest path contains only the number zero and is written as: {0}. More complicated paths containing more elements are written as: {2;4;6}. Just as a path identifies a list within the tree, an index identifies a data point within a list. An index is always a single, non-negative integer. Indices are written inside square brackets and appended to path notation, in order to fully identify a single piece of data within an entire data tree: {2,4,6}[10].
Since both path elements and indices are zero-based (we start counting at zero, not one), there is a slight disconnect between the ordinality and the cardinality of numbers within data trees. The first element equals index 0, the second element can be found at index 1, the third element maps to index 2, and so on and so forth. This means that the "Eleventh point of the seventh isocurve of the fifth face of the third polysurface" will be written as {2;4;6}[10]. The first path element corresponds with the oldest mapping that occurred within the file, and each subsequent element represents a more recent operation. In this sense the path elements can be likened to taxonomic identifiers. The species {Animalia;Mammalia;Hominidea;Homo} and {Animalia;Mammalia;Hominidea;Pan} are more closely related to each other than to {Animalia;Mammalia; Cervidea;Rangifer}** because they share more codes at the start of their classification. Similarly, the paths {2;4;4} and {2;4;6} are more closely related to each other than they are to {2;3;5}.
The messy reality of data trees.
Although you may agree with me that in theory the data tree approach is solid, you may still get frustrated at the rate at which data trees grow more complex. Often Grasshopper will choose to add additional elements to the paths in a tree where none in fact is needed, resulting in paths that all share a lot of zeroes in certain places. For example a data tree might contain the paths:
{0;0;0;0;0}
{0;0;0;0;1}
{0;0;0;0;2}
{0;0;0;0;3}
{0;0;1;0;0}
{0;0;1;0;1}
{0;0;1;0;2}
{0;0;1;0;3}
instead of the far more economical:
{0;0}
{0;1}
{0;2}
{0;3}
{1;0}
{1;1}
{1;2}
{1;3}
The reason all these zeroes are added is because we value consistency over economics. It doesn't matter whether a component actually outputs more than one list, if the component belongs to the 1:N, 1:N', or N:N' groups, it will always add an extra integer to all the paths, because some day in the future, when the inputs change, it may need that extra integer to keep its lists untangled. We feel it's bad behaviour for the topology of a data tree to be subject to the topical values in that tree. Any component which relies on a specific topology will no longer work when that topology changes, and that should happen as seldom as possible.
Conclusion
Although data trees can be difficult to work with and probably cause more confusion than any other part of Grasshopper, they seem to work well in the majority of cases and we haven't been able to come up with a better solution. That's not to say we never will, but data trees are here to stay for the foreseeable future.
* This is not something we hit on immediately. The very first versions of Grasshopper only allowed for the storage of a single data point per parameter, making operations like [Loft] or [Divide Curve] impossible. Later versions allowed for a single list per parameter, which was still insufficient for all but the most simple algorithms.
** I'm skipping a lot of taxonometric classifications here to keep it simple.…
Added by David Rutten at 2:22pm on January 20, 2015