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…
imum height of built volume which would not violate the solar access for defined surroundings given filtered sun vectors.
Solar Collection - A complementary 3D envelope which defines the lowest heights from which a new built volume would receive solar access, given a built context and filtered sun vectors.
The new component harnesses ladybug's SunPath tool to determine relevant sun positions based on input from an .epw file. The simulation also takes into account surrounding buildings if provided or a self envelope if omitted, with the goal of adding control and flexibility in conjunction with a more accurate simulation.
A video tutorial is available here - https://www.youtube.com/watch?v=hRtsxgJCVEw
An example file is both attached and accessible through here - https://www.dropbox.com/s/ao11882no95io9x/solarEnvelopeAdvanced_example_file.gh?dl=0
The component takes as an input a filtered list of sun vectors, a base surface which represents the site border and a list of curves, representing the surrounding context
and outputs a point cloud and a polysurface -
which in turn can be closed and further evaluated (On the left - solar collection, on the right - solar rights) -
By Boris Plotnikov and with the assistance and guidance of Prof. Guedi Capeluto, based on SustArc model. The component could not have be alive without the invaluable help of the awesome Chris Mackey and Mostapha Sadeghipour Roudsari in development and integration, also a big thanks is due to Abraham Yezioro for testing and advising on usability.
For further reading it might be worth taking a look at Ralph Knowles's work, e.g -http://www.fau.usp.br/aut5823/Acesso_ao_Sol/Knowles_2003_Solar_Envelope.pdf and G. Capeluto and E. Shaviv's, e.g - http://www.ibpsa.org/proceedings/BS1999/BS99_C-22.pdf the component relies to a great extend on the concepts described there.
Thanks for reading and enjoy!…
rids Surface divisions Panel creation in Rhino Panel morphing and aggregation Panel placement via attractors and colors Panel smoothing with Weaverbird Parametric panel modules TIME 3pm – GMT, London 4pm – Paris, Brussels, Rome, Vienna, Budapest, Bratislava, Warsaw 7pm – Dubai, Abu Dhabi, Baku 6:30pm – Tehran 6pm – Baghdad, Moscow, St Petersburg 5pm – Istanbul, Athens, Helsinki, Cairo, Johannesburg 1pm – Rio de Janeiro, São Paulo, Montevideo 12pm – Buenos Aires, Santiago 10am – Toronto, New York City, Bogota, Lima 9am – Mexico City 7am – Los Angeles ADVANCED SESSIONS (live) The Advanced sessions put the essential knowledge into practical use. The advanced sessions explain specific design strategies, lead you through complex Grasshopper® definitions, show tips and tricks, put plug-ins into use and show you how to connect Grasshopper® to external software and devices. MICHAEL PRYOR Designer, working in the architecture field for four years now on a variety of major built and in construction projects in NYC and China. Co-partner to 3D-Dreaming: Architecture from a digital point of view. Daily user of grasshopper: both in work and exploration, as well as a constant contributor to the grasshopper help forums. Tutor to a variety of digital design and parametric workshops hosted by the Architecture Association with [AY]A Studio, Rese arch, and 3D Dreaming. Creator of the grasshopper tutorial blog [FORMul[a]RCH]. Currently in process of writing his first grasshopper plug in. WEBINARS The rese arch Grasshopper® sessions are unique for their thorough explanation of all the features, which creates a sound foundation for your further individual development or direct use in the practice. The webinars are divided into four groups: Essential, Advanced, Iterative and Architectural. If you are a Rhinoceros 3D or Grasshopper® newcomer, you are advised to take all the Essential sessions before proceeding to the next level. If none of the proposed topics suit your needs or if you require special treatment, you can request a custom-tailored 1on1 session. All sessions are held entirely in English. The webinars are series of on-line live courses for people all over the world. The tutor broadcasts the screen of his computer along with his voice to the connected spectators who can ask questions and comment in real time. This makes webinars similar to live workshops and superior to tutorials.…
Added by Jan Pernecky at 9:39am on January 8, 2015
of computational design and a comprehensive knowledge of cutting-edge technologies in the fields of parametric architecture, robotics, digital manufacturing and 3d printing for the construction industry. The program is a part-time executive format (one week per month during one year) designed for a selected group of architects, engineers, designers and digital artists. DESIGN by DATA is made of courses, fabrication and prototyping workshops, conferences, digital talks and networking events. The program take place in multiple locations in Paris and is a true opportunity to enter the international ecosystem of architectural innovation. A coworking membership and a full fablab access to digital manufacturing machines are included in the program.
..........
PROGRAM
A) ART AND CULTURE IN THE DIGITAL TURN Digital Culture and Liquid Spaces (Yasmine Abbas)
Smart cities and Collective Intelligence (Domenico Di Siena)
Art, Technology and the Creative Process (Eric Vernhes)
Advanced Mesh Modelling and Data Bodies (Andrea Graziano)
Agent Based Tectonics for Architecture (Alessio Erioli)
B) COMPUTATIONAL DESIGN: COMPLEX GEOMETRIES AND OPTIMISATION
Management and Design of Complex Geometries (Olivier Baverel)
Conceptual Structural Design (Romain Mesnil)
Algorithmic Optimization (Cyril Douthe)
Permormance-driven Design (Sébastien Perrault)
C) ADDITIVE MANUFACTURING AND ROBOTIC FABRICATION
Robotics and Industrial Fabrication (Thibault Schwartz )
3d Printing and Material Science (Justin Dirrenberger)
Drones and Aerial Robotics for Environnemental Design and Architecture (Aldo Sollazzo)
Digital Prototyping and Final Project Fabrication (Minh Man Nguyen)
APPLY FOR SEPTEMBER 2016
http://www.enpc.fr/design-by-data…
e chosen to dive into Grasshopper. I’m about 6 months in. If some of my comments are completely off, please take that to mean that a feature is too inaccessible to a newish user rather that it’s just missing, as I may have stated.
One of my primary pain points is this. Things that can be done in other programs are invariably easier in other programs. This is a big enough issue that I doubt there’s an easy solution that an armchair qb like myself can offer up.
The interface:
I’ve used a lot of 3D programs. I’ve never encountered one as difficult as grasshopper. What in other programs is a dialog box, is 8 or 10 components strung together in grasshopper. The wisdom for this I often hear among the grasshopper community is that this allows for parametric design. Yet PTC (Parametric Technology Corp.) has been doing parametric design software since 1985 and has a far cleaner and more intuitive interface. So does SolidWorks, Inventor, CATIA, NX, and a bunch of others.
In the early 2000's, when parametric design software was all the rage, McNeel stated quite strongly the Rhino would remain a direct modeler and would not become a parametric modeler. Trends come. Trends go. And the industry has been swinging back to direct modeling. So McNeel’s decision was probably ok. But I have to wonder if part of McNeel’s reluctance to incorporate some of the tried and proven ideas of other parametric packages doesn't have roots in their earlier declaration to not incorporate parametrics.
A Visual Programming Language:
I read a lot about the awesomeness and flexibility of Grasshopper being a visual programming language. Let’s be clear, this is DOS era speak. I believe GH should continue to have the ability to be extended and massaged with code, as most design programs do. But as long as this is front and center, GH will remain out of reach to the average designer.
Context sensitivity:
There is no reason a program in 2014 should allow me to make decisions that will not work. For example, if a component input is in all cases incompatible with another component's output, I shouldn't be able to connect them.
Sliders:
I hate sliders. I understand them, but I hate ‘em. I think they should be optional. Ya, I know I can r-click on the N of a component and set the integer. It’s a pain, and it gives no feedback. The “N” should turn into the number if set. AAAnd, sliders should be context sensitive. I like that the name of a slider changes when I plug it into something. But if I plug it into something that'll only accept a 1, a 2, or a 3, that slider should self set accordingly. I shouldn't be able to plug in a “50” and have everything after turn red.
Components:
Give components a little “+” or a drawer on the bottom or something that by clicking, opens the component into something akin to a dialog box. This should give access to all of the variables in the component. I shouldn't have to r-click on each thing on a component to do all of the settings.
And this item I’m guessing on. I’m not yet good enough at GH to know if this may have adverse effects. Reverse, Flatten, Graft, etc.; could these be context sensitive? Could some of these items disappear if they are contextually inappropriate or gray out if they're unlikely?
Tighter integration with Rhino:
I'm not entirely certain what this would look like. Currently my work flow entails baking, making a few Rhino edits, and reinserting into GH. I question the whole baking thing, btw. Why isn't it just live geometry? That’s how other parametric apps work. Maybe add more Rhino functionality to GH. GH has no 3D offset. I have to bake, offsetserf, and reinsert the geometry. I’m currently looking at the “Geometry Cache” and “Geometry Pipeline” components to see if they help. But I haven't been able to figure it out. Which leads me to:
Update all of the documentation:
I'm guessing this is an in process thing and you're working toward rolling GH from 0.9.00075 to 1.0. GH was being updated nearly weekly earlier this year. Then it suddenly stopped. If we're talking weeks before a full release, so be it. But if we're looking at something longer, a documentation update would help a lot. Geometry Cache and Geometry Pipeline’s help still read “This is the autogenerated help topic for this object. Developers: override the HtmlHelp_Source() function in the base class to provide custom help.” This does not help. And the Grasshopper Primer 2nd Ed. was written for GH 0.60007.
Grasshopper is fundamentally a 2D program:
I know you'll disagree completely, but I'm sticking to this. How else could an omission like offsetsurf happen? Pretty much every 3D program in existence has this. I’m sure I can probably figure out how to deconstruct the breps, join the curves, loft, trim, and so forth. But does writing an algorithm to do what all other 3D programs do with a dialog box seem reasonable? I'm sure if you go command by command you'll find a ton on such things.
If you look at the vast majority of things done in GH, you'll note that they're mostly either flat or a fundamentally 2D pattern on a warped surface.
I've been working on a part that is a 3D voronoi trimmed to a 3D model. I've been trying to turn the trimmed voronoi into legitimate geometry for over a month without success.
http://www.grasshopper3d.com/profiles/blogs/question-voronoi-3d-continued
I’ve researched it enough to have found many others have had the exact same problem and have not solved it. It’s really not that conceptually difficult. But GH lacks the tools.
Make screen organization easier:
I have a touch of OCD, and I like my GH layout to flow neatly. Allow input/output nodes to be re-ordered. This will allow a reduction in crossed wires. Make the wire positions a bit more editable. I sometimes use a geometry component as a wire anchor to clean things up. Being able to grab a wire and pull it out of the way would be kinda nice.
I think GH has some awesome abilities. I also think accessing those abilities could be significantly easier.
~p…
posicionado como una herramienta abierta no sólo para el modelado 3D sino para el manejo de información. La capacidad de esta herramienta yace más allá de la agrupación de funciones, es a través de su vinculación con distintas plataformas dentro y fuera de Rhino que GH extiende su capacidad y versatilidad en la generación de forma/información. Este curso/taller se enfoca en lograr un control preciso y profundo de GH para extender las capacidades de modelado al establecer puentes con nuevas plataformas de software. INPUT/OUTPUT se adentra en establecer conexiones tanto físicas como digitales aprovechando la flexibilidad y fluidez operativa de Grasshopper.
TEMARIO
Filtrado de elementos
Manejo de listas
Re-acomodo de estructuras de información
Importar, preparar información y exportar
Evaluación interna de resultados
Iteraciones en GH
Conexiones a redes de información
Generación de herramientas auxiliares para informar la toma de decisiones
CONEXIONES
Excel / GH + Spreadsheets
Firefly / GH + Arduino
Ghowl / GH + Information + Networks
WeaverBird / GH + Advanced meshes
Pachube / GH + Real-time information feeds
Kangaroo / GH + Physics
Es requisito traer equipo de cómputo personal con Rhino y Grasshopper.…
it seems that was this. Now all is working fine !
Glad that it worked! But I am still a bit worried. Gismo components only modify the gdal-data/osmconf.ini file and no other MapWinGIS file. So your MapWinGIS installation files should not be compromised. The fact that you did not get the "COM CLSID" error message when running the "Gismo Gismo" component suggests that MapWinGIS has been properly installed. So I wonder if the cause for the permanent "invalid shapes" warning has again something with the fact that your system is again not allowing the MapWinGIS to properly edit the osmconf.ini. Maybe this problem will appear again, and again, and reinstallation of MapWinGIS every time can be somewhat bothersome.
- About the terrain generation, is it possible to have the texture from google or other provider mapped onto the terrain surface from gismo component ? (Same as using the ladybug terrain generator in fact). I try to used the image extracted by ladybug component and then applied it to the gismo terrain but the texture is rotated by 90°.
The issue with the rotation can be solved by swapping/reversing the U,V directions of the terrain surface. A slightly more important issue is that terrain surface generated with Gismo "Terrain Generator" component might have a bit smaller radius than what the radius_ input required. This stems from the fact that the terrain data first needs to be downloaded in geographic coordinate system, and then projected. Some projecting issues may occur at the very edges of the projected terrain, so I had to slightly cut out the very edges of the terrain which results in the actual terrain diameters being slightly shorted in both directions. This means that if you apply the same satellite image from Ladybug "Terrain Generator" component to Gismo "Terrain Generator" component the results may not be the same.I attached below a python component which tries to solve this issue by extending the edges of Gismo "Terrain Generator" terrain, and then cutting them with the cuboid of the exact dimensions as the radius_ input. Have in mind that this extension of the original terrain at its edges is not a correct representation of the actual terrain in that location. But rather just an extension of the isoparameteric curve of the terrain surface. So basically: some 0 to 10% (0 to 10 percent of the width and length) of the terrain around all four edges is not the actual terrain for that location, but rather just its extension.The python component is located at the very right of the definition attached below.
Also, if you would like to use the satellite images from Ladybug "Terrain Generator" component along with "OSM shapes", sometimes you may find slight differences in position of the shapes. This is due to openstreetmap data not being based on Google Maps (that's what Ladybug "Terrain Generator" component is using), but rather on Bing, MapQuest and a few others.
- About the requiredKeys_ input of OSM shapes, I understand what you mean and your advice, but in most cases I use it, the component was working fine even without input. I think it's better to extract all tags, values and keys of the selected area, instead of searching for specific ones as I try to find all data related to what I want after, isn't it ? To check what keys are present on the area also.
Ineed, you are correct.I though you were trying to only create a terrain, 3d buildings and maybe find some school or similar 3d building, for these two locations. The recommendation I mentioned previously is due to shapefiles having a limit (2044) to how many keys it can contain. This requires further testing of some big cities locations with maybe larger radii, which I haven't performed due to my poor PC configuration. But in theory, I imagine that it may happen that a downloaded .osm file may have more than 2044 keys. In that case shapefile will only record 2044 of them, and disregard the others. That was my point.But again 2044 is a lot of keys, and I haven't been checking much this in practice. For example, when I set the radius_ to 1000 meters, and use your "3 Rue de Bretonvilliers Paris" location I get around 350 something keys, which is way below the 2044.Another reason why one should use the requiredKeys_ input is to make the Gismo OSM components run quicker: for example, the upper mentioned 350 something keys will result in 350 values for each branch of the "OSM shapes" component's "values" output.Which means if you have 10 000 shapes, the "OSM shapes" component will have 10 000 branches with 350 items on each branch (values). This can make all Gismo OSM components very heavy, and significantly elongate the calculation process.With requiredKeys_ input you may end up with only a couple of tens of items per each branch.Sorry for the long reply.…
Added by djordje to Gismo at 8:57am on June 11, 2017
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
ectly in grasshopper (drawing a curve on top of a line with different angles), i did the curve shape in rhino and import it into grasshopper.
i'm having a problem where some of the sine curve shape can orient or map onto the triangle surfaces nicely, but some of them do not. whenever i try to orient the shape onto the bottom portion of the icosahedron, the shape becomes 'negative', forcing me to flip the lines before offsetting and patch (i am using loft method) or else it will become a weird loft (image 3).
i have tried several different ways to orient the ones that worked (orient 3d in rhino, rotate 3d etc.) and still could not get them to work.
the reason that i want them to face in the same direction is so that i can use WB thicken and make sure they extrude in the same direction. i have tried to unify the normal faces in grasshopper and still it is not working.
does anyone have any idea why or how can i do this? your help will be greatly appreciated. i am fairly a beginner in GH so if there is any other easier method to do this will also be great :)
…
, National University of Singapore.
An introduction workshop for Rhinoceros 3D and Grasshopper Generative Modeling for Rhino for architectural practices. Workshop goal is to provide basic functional understanding of both Rhinoceros 3D and Grasshopper, to enable participants to build own definitions, and understands existing definitions.
Grasshopper is a Work-in-Progress. Features and procedures are added/changed often. If you are bringing your own laptop, please update to Rhino version 4 service release 8 and Grasshopper version 0.8.0004 which will be use in the workshop.
If you are not sure of your current update, please email to Agnes (agnes.tan@mcneel.com) for assistance.
Speaker: Agnes Tan agnes.tan@mcneel.com
Contact Person: Pinglei ping_lei@nus.edu.sg
Campus map: http://www.nus.edu.sg/campusmap/
Seats Limited.
Registration fee: S$250.00 each person
Mode of payment: Cash or Cash cheque
*Please note exhibition and workshop venues are in different locations.
…