ns about them.
It's a direction for Kangaroo I very much intend to continue developing - and I am still getting to grips with the possibilities and experimenting with how different optimization and fairing forces work in combination with one another, so I would value your input and experience.
For those interested in some background reading material -
[1] http://www.cs.caltech.edu/~mmeyer/Research/FairMesh/implicitFairing.pdf
[2] http://mesh.brown.edu/taubin/pdfs/taubin-eg00star.pdf
[3] http://www.pmp-book.org/download/slides/Smoothing.pdf
[4] http://graphics.stanford.edu/courses/cs468-05-fall/slides/daniel_willmore_flow_fall_05.pdf
[5] http://www.evolute.at/technology/scientific-publications.html
[6] http://www.math.tu-berlin.de/~bobenko/recentpapers.html
[7] http://spacesymmetrystructure.wordpress.com/2011/05/18/pseudo-physical-materials/
[8] http://www.evolute.at/technology/scientific-publications/34.html
[9] http://www.evolute.at/software/forum/topic.html?id=18
At the moment the Laplacian smoothing is uniformly weighted, which tends to even out the edge lengths as well as smoothing the form, which is sometimes desirable, and sometimes not. It also tends to significantly shrink meshes when the edges are not fixed.
I plan to try some of the other weighting possibilities, such as Fujiwara or cotangent weighting (see [1] and [3]), as well as other fairing approaches, such as Taubin smoothing [2], Willmore flow[4], and so on. This also has applications in the simulation of bending of thin shells.
Planar quad panels are often desirable, but I'm finding that planarization forces alone are sometimes unstable, or cause undesirable crumpling, so need to be combined with some sort of fairing/smoothing, but the different types have quite different effects, and the balance is sometimes tricky.
There's also the whole issue of meshes which are circular (I posted a demo of circularization on the examples page), or conical (this one still isn't working quite right yet), and their relationship with principal curvature grids and placement of irregular vertices, all of which is rather different when the whole form is up for change, rather than having a fixed target surface [7].
I'm also trying to get to grips with ways of making surfaces of planar hexagons, which need to become concave in regions of negative Gaussian curvature (see this discussion)
and I hope to release soon a component for calculating CP meshes, as described in [8], which I think could have many exciting construction implications.
While there are a number of well developed smoothing algorithms, their main area of application so far seems to be in processing and improving 3D scan data, so using them in design in this way is somewhat new territory. There can be structural, fabrication or performance reasons for certain types of smoothness, but of course the aesthetic reasons are also often important, and I think there are some interesting discussions to be had here about the aesthetics of smoothness.
Anyway, that's enough rambling from me, hopefully something there triggers some discussion - I'm really keen to hear about how all of you envision these tools might be used and developed.
…
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.…
rested in specializing in the field of Computational design.
The workshop will help understand how Grasshopper facilitates during the design process allowing one to Generate, Automate and Manipulate data.
To Register:
http://goo.gl/forms/gvUTyZihVK
Workshop Structure:
Day 01: 16 August 2018
Introduction to Computational Processes in Architecture
Understanding Grasshopper and its relation to Rhino3D
Working with fields and Grids (Supplementary readings for Architectural theory)
Spatial Concepts using Data
Day 02: 17 August 2018
Understanding Data in Grasshopper - LISTS
Managing Data in Grasshopper (Supplementary reading)
Experimentation on Massing and Architectural Forms
Day 03: 18 August 2018
Understanding Data in Grasshopper – Trees
Surface Logics (Supplementary reading)
Design Exercise and Prototyping
Day 04: 20 August 2018
Architectural Skins
Day 05: 21 August 2018
MasterClass Project
Introduction to various types of Digital Fabrications
Prototyping of works during the Workshops
Basic knowledge of Rhino 5 is required to be able to take this training.
CERTIFICATION: All participants will receive a Workshop certificate from Authorized Rhino Trainer.
3D Printing: Prototyping of works during the Workshops
Workshop Tutor:
Kavitha M, an Architect and Computational Designer, 3D Printing Specialist is also the co-founder of INTO Design Research, will head the Computational Process in Architecture using Grasshopper workshop. Graduated from Stadelschule Architecture class with Masters in Advanced Architecture Design, has been researching on teaching methodologies on digital tools and their influence on Design thinking.…
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
tura digital en corte Láser, corte CNC, impresión 3d, y modelado paramétrico.
Este tercer taller enseña los fundamentos del modelado paramétrico y algunas bases de manufactura digital.
PERFIL DEL ALUMNO QUE INGRESA:
Diseñador, Arquitecto, Artista con conocimientos de Rhinoceros interesados en comenza a modelar paramétrico con Grasshopper para fabricación digital básica.
PERFIL DEL ALUMNO QUE EGRESA:
El alumno terminará con los conocimientos y criterios para el desarrollo de piezas o proyectos utilizando fabricación digital, mejorando y agilizando los flujos de trabajo, así como los criterios fundamentales del Modelado Paramétrico -Generativo.
Taller de modelado paramétrico con Grasshopper
Interfase
Manejo de Datos
Data Volátil
Data Persistente
Rangos y dominios
Atractores
Listas y Cull
Modelado por Layer Object
Análisis Básicos
Conexión de Curvas
Superficies
Análisis de Superficies
Panelización Básica
Relaciones con Excel
Modelado generativo
Fechas: del 8 de Febrero al 1º de Marzo
Días: Sábado
Horarios: de 10 am a 3 pm
Sesiones: 4 de 5hrs
Duración: 20 horas
Precio: $3,000.00…
.
For my project I want to make a sphere or spherical-like shape and pack it with circles of varying sizes. The circles all have to touch each other and thus on a point where three circles 'sort of' meet, there can only be three circles. This is shown in the second picture I have attached, a 2D circle packing made by Daniel Piker. So basically what I want to achieve is having the second picture projected on a 3d surface, that I can also edit. Also I would like to be able to change the size and amount of the circles that populate the surface. This means that I would be able to say 'there should be 30 circles with a radius of 2, 40 circles with a radius of 3 and 50 circles with a radius of 4, put them on this particular shape'.
As I've just started the project I haven't done so much research yet. What I have found is for example this Kangaroo definition of circle packing in 2D: http://www.grasshopper3d.com/group/kangaroo/forum/topics/circle-packing-definition?xg_source=activity
It is very beautiful and does exactly what I want to achieve, except that it is in two dimensions. I also have to say that I feel pretty confident working with both Grasshopper and Rhino, but not really with Kangaroo. I have used it a few times but not extensively.
So what I'm wondering is, how could I best approach this project? I looked into the concept of 'circle packing' and I noticed that it can be approached very mathematically. As I am an architecture student I don't know much about the math behind the geometry (although I do think it is very interesting) and thus I'm wondering if I will be able to achieve what I want to achieve. Also, do you think I could best approach the project in Kangaroo and do you think it is realistic for me to think I could finish the project? I'm just trying to see if I'm not going to try to tackle a problem that is very difficult to solve even for skilled mathematicans or something. Sorry for the long and perhaps vague read, but I would be very happy with any sort of input you might have on my problem!
Thanks in advance!
…
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 :)
…
ractor in the next few weeks. I know that Mach3 has a time,r usually on screen4(toolpath screen), that gives really accurate machine estimation as it uses the motor tuning profiles that are in the screen set in use. I know it would be handy right in GH, but maybe lower on the list.
My priority would be on creating some components that could start with your model (preferrably 3d) and extract 2d parts & generate the toolpath from there instead of having to start from a drawn toolpath (your Intl, & Extl offset lines.)
An outline extractor definition is fairly simple to create, but I get hung up on selecting the right surface of the solid part(I just have to manually select the flat side surface with a slider right now). Then the components to define a group of parts to cut out & automatically recognizing inside cuts (cutouts) and outside cuts(outlines) would be next. This would just be a set of components that would precede your definition. (of course I'm talking about 2d at this point.) See attached definition & test file(Rh5)
Surfaces with surface normals, for simultaneous 5 axis would come next/later. Anyway, I just wanted to say thanks for your great work & I hope I'll able to contribute in some manner.
I'm not sure if this is really part of your effort/plan, but I think would be a big time-saver for users.
I also know there's RhinoNest that can pull apart a model & nest pieces on sheets the user defines, but I don't think this has to be that complex.
I'll keep in touch,
Cheers!
-Mike Calvino…
several ways to define 'worth keeping' of course, in my file I tested whether the grid cell centre point was on the surface. I tested this by projecting this center point onto the surface and seeing whether the projection distance was very small or not. If it's very small, the point was on the surface to begin with.
Other possible metrics would be to see if all four corner points are on the surface, or if at least one corner point is on the surface, or.....
Once you know which cells are worth keeping, cull both the cell data and the centre point data. This may give you some empty lists, which is why I cleaned both data streams as well, that is not perhaps necessary, it depends on how the remainder of the file handles the data layout.
I find the 4 corners of each cell with [Curve Discontinuity]. I could also have used [Curve Control Points] but that would have given me 5 points per square as the first and last are repeated since the cell polylines are closed.
Then lower the centre point and connect it with the 4 corners, this gives you the downwards pointing diagonal edges.
The last step is a bit of hack but unfortunately it is very difficult to do it right at the moment. I used the [Proximity 3D] component to find all neighbours within 2.1 units of each lowered centre point. The distance limit means it will only find the correct neighbours, but note I hardcoded the distance limit rather than make it depend on the grid-size, which would have been more flexible.
Because the last step uses a single shot algorithm you end up with duplicate lines at the bottom lattice and also the order of lines is useless.
--
David Rutten
david@mcneel.com
Tirol, Austria…
Added by David Rutten at 2:12am on September 23, 2013
of stuff. Then it works either with ExoW (black mesh) or IntraLattice (blue mesh).
That said ExoW is tricky: occasionally reports engulfing issues and stops playing the game. For instance in this (diagonal) anchor mode and with some U/V random values:
Whilst IntraLattice appears rather less temperamental:
The other def is more complex and works using the Proximity approach that makes more sense with regard random 3d line graphs (as an exercise: Add a gate and use IntraLattice as Plan B).
best
…