eñadores, y creativos interesados en el aprendizaje de metodos avanzados de generación y racionalización de geometría compleja, y su implementación en distintas etapas del proceso de diseño.
Se abordaran los conceptos básicos para hacer frente a diversas problemas de diseño a través de la implementación de una serie de plataformas computacionales con el objetivo de construir un flujo de trabajo que permita optimizar proyectos de diversa escala y explorar esquemas geometricos complejos de manera rápida y eficiente.A lo largo del 6 dias trabajaremos con la plataforma de Modelado 3d Rhinoceros, el entorno de programación visual de Grasshopper y el motor de Renderizado de Vray.Estudiantes: $4,500.00Profesionistas: $5,500.00info+inscripciones:workshop@complexgeometry.com[044] 33 3956 9209[044] 33 1410 8975[044] 81 1916 8657
…
merely automates finding clear intersections between pairs of objects and then splits the objects along those intersection *curves*, deletes the trims, then joins the remains, and cycles on. But within the confusing Rhino Settings tolerance value, wherever surfaces actually just sort of come closely together, there *is* *no* clear intersection curve. So it bugs out and stops working EVERY time you try more than a dozen or two spheres.
Some software can do this by switching to volumetric pixels (voxels). $9K-$30K Geomagic Freeform is an example of this. It also fails sometimes, often due to memory issues, as you can imagine since it needs to fill all inner space of each sphere definition with 3D pixels.
Materialize Magics for $16K can often handle such Booleans well. It will take a seeming lifetime to figure out such often pirate software kludges though.
One thing you can try though is to simply drape a mesh or NURBS plane onto the top of your spheres.
There's a well known *reason* your Booleans are failing. Nobody here has yet even hinted at it:
The main reason is that Rhino/Grasshopper developers don't care about the human element. The math exists to make this work very fast, every time. It just has to join things *right*, incorporating human knowledge of kissing surfaces, instead of acting stupidly, like some pocket calculator. But that would involve hacks that make 99% of complex Booleans work instead of 10%, and we can't have that since it will be SLOWER for the other 1% that just happen to have no nearly kissing or really kissing surfaces.
You could also use the new Cocoon plugin to do a surface *around* your structures, with a given radius of extension beyond the spheres, then offset that surface back the same radius. That is 100% robust, but won't offer quite as sharp of intersections, more rounded, like most everybody wants anyway.
You can *test* Boolean failures, by running a Grasshopper intersection command, to see the intersection curves, and zoom in to see how badly many of them are, all knotted, or twisted, or even with gaps, often with gaps.
It's a math problem nobody at McNeel wants to solve, sorry.
Just write a check for $25K and spend six months taking notes, like I did, and you can merge your simple spheres finally.…
Added by Nik Willmore at 6:33pm on October 20, 2015
s.
Yes, I see the issue now. Good catch!I am a bit reluctant to add a new input, as I would have to add it to the "OSM Shapes" component too. Both "OSM Search" and "OSM Shapes" components have more inputs than outputs, so I was kind of more keen to add another output (titleOriginPt), then input. This output can then be used to move the title with Grasshopper "Orient" component.
It's useful to say that: If a terrain has been added to the groundTerrain_ input of the "OSM Search" component, then the title would go below the terrain, which makes it more readable I guess.Let's see how this issue goes, maybe in the end more people will ask for adding a titleOriginPt_ input as well.
For the same thing (not sure about this) maybe a legend with colors for the filtered building types, assuming you can search for more than one at the same time.
This is a very good suggestion! At the moment it is not possible to search for more than one OSM object. I understand the importance of having such feature, but this would require from me to rewrite the "OSM Search" component. Maybe it can be a little less time consuming if a new additional component will be created. So one would have to copy an "OSM Search" component for each type of the OSM object he/she wants to search for, and then outputs from all those "OSM Search" components will drain into the upper mentioned new component which will make a colored legend for each OSM object. Just a suggestion.However there is one issue with all this OSM objects search, that I haven't mentioned: OpenStreetMap data can store amenities of the same type on different shapeType_. For example, in find_hotels.gh we are using shapeType_ = 0 (2d polygons), we make 3d shapes from them, and then we search among those 3d shapes.However, if one sets the shapeType_ to 2 (points) one will also find hotels among the points.It may take a more knowledgeable OpenStreetMap user to explain this, but in general: if a hotel occupies all floors of the building, then it would be found the way we did it in find_hotels.gh (shapeType_ = 0). But if a hotel does not occupy all floors, or a user who mapped the hotel was not certain whether it did occupy the whole building or not, then a hotel would be mapped as a single point. I assume this will be the point of hotel's entrance, but I may be wrong on this.I attached an example file below which shows this.So if there's going to be a new component created: which will map hotels, restaurants, bars... or other buildings types with a legend of some sort, then this aspect needs to be taken into consideration. It can probably be fixed with some sort of point inclusion (in a polygon). Let's see.It's definitively another very valuable suggestion!!…
Added by djordje to Gismo at 5:26pm on March 2, 2017
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…
noceros 3D, en caso de aprobar satisfactoriamente el examen, se les otorga un reconocimiento avalado por el CMJ y la Secretaría del Trabajo. Este workshop va dirigido principalmente a estudiantes de arquitectura; sin embargo, ya que la parametrización es una herramienta que abarca diferentes ámbitos del diseño, se pueden integrar estudiantes de diseño industrial, artistas o estudiantes que tengan relación con lo gráfico y lo formal. Al finalizar el curso, los asistentes serán capaces de manejar Rhinoceros y Grasshopper en un nivel medio, con el objetivo de que el alumno pueda continuar aprendiendo con alguno de nuestros workshops subsiguientes o de manera autodidacta.
Las personas inscritas deben tener conocimientos básicos de geometría y de preferencia utilizar algún programa de dibujo en 2D o modelación en 3d. Rhino.GetMe Rigid // Enfocado a construir un objeto de diseño parametrizado a cualquier escala, el workshop se divide en tres módulos: Módulo 1 // Rhinoceros 3D // Una sesión de cinco horas. Módulo 2 //Grasshopper // Una sesión de cinco horas. Módulo 3 // Ejercicios prácticos /Tres sesiones de diez horas c/u. Es necesario traer el equipo necesario para trabajar, se cuenta con equipos en caso de que algún alumno no cuente con laptop pero son limitados, por favor avísanos a la brevedad si lo requieres. Se les recomienda que traigan dispositivos de almacenamiento en caso de que necesitemos compartir información.
El costo del Workshop es de $6500.00 para profesionales y $5000 pesos para estudiantes.
Pre-venta únicamente para estudiantes, hasta el día viernes 29 de junio, con un costo de $3500.00 pesos.
El cupo del evento es limitado puedes apartar tu lugar y terminar de liquidar antes del 29 de junio en pre-venta, antes del 6 de junio en admisión general.
Para hacer tu registro al workshop por favor envía un correo a workshop@transformalab.com incluyendo:
Nombre
Universidad u oficina de procedencia
Teléfono móvil
En el caso de estudiantes por favor incluyan una copia escaneada de su Constancia de Estudios para hacer válido su descuento.
Una vez recibida su información se les enviará un correo con la información necesaria para realizar su pago mediante depósito bancario, y posteriormente un mail de confirmación de su participación en el Workshop.
www.transformalab.com…
tors: R.G.D.E tutors Mostafa R. A. Khalifa, Architect (PhD - UNICAM - Italy)
Assistants: Nagham Baitawy - Architect - Jordan
Ahmed Hassan - Architect & TA - Egypt
deadline registration August, 25th , 2013
http://grasshopperworkshopamman.blogspot.com/ introduction: This workshop will introduce basic and advanced notions of Grasshopper and the methodology of parametric design and algorithmic modeling and its usage in Architecture, design, landscape, and urban scale. It is intended for professionals and students with a minimum experience in 3D Modeling.
…
sent a 3D shape without any ambiguity. If the shape you're trying to convey falls outside the scope of existing standards, then it can't be done, but this is a problem of standards, not an intrinsic shortcoming of pencils.
[...] with the computer theoretically acting as a decision maker.
The computer makes no decisions on it's own. It's a fully deterministic machine, meaning that any output is the result of applying a set of rules to some pre-existing data. Humans make the rules. At no point can you blame the computer for coming up with a bad answer, it's always some human who is responsible.
[...] it seems to often be split between Computerization, and Computation.
I'm willing to concede there exist cases that are unambiguously one or the other, but there's a gradient in between these two extremes, they are not separate categories. If I draw a box by specifying the 8 corner points as XYZ coordinates then computation can be said not to be involved. If I draw a box by specifying 2 opposite corners then the computer has to compute the other 6 coordinates and we're already on our way towards the other extreme. If I draw a box by specifying a width, height and a required volume, more computation is needed. If I specify a box by a width, a volume and the requirement is doesn't cast too much shadow on some other shape, more computation is needed. At what point do we say "now it qualifies as computation/solving"?
--
David Rutten
david@mcneel.com…
Added by David Rutten at 7:22am on November 28, 2013
hes or surfaces on this: it's the nature/topology of your design that dictates that approach):
This C# only (as usual) collection of scripts works in 2 phases:
Phase A: Gets points in 3d space (NOT internalized in order to alter them manually) and creates a mesh. Depending of your search distance (actually: radius) the mesh is variable. If you bypass phase A (feed the 2nd C# with some other mesh of yours) then the mesh is triangulated automatically.
Phase B: Gets the mesh and creates your "tri-breps" in a DataTree where first dimension branches are indexed as the mesh faces (Note: "tri-breps" are not joined to a closed brep for speed).
PS: An auxiliary 3rd C# gives you an indication about the size of mesh edges in order to enter proper offset (where offset means offset of the tri-mesh edges) values.
PS: If you overdone with values > faces are excluded (and the equivalent tri-breps are NOT created):
PS: if you enter possible/doable offsets > all faces play ball:
best, Peter (Load Rhino file first)
…
hem and mine with some axis more in 3d space):
To tell you the truth you need a lot of other "constrains" for your nodes since they are shaped (I can easily guess the "method" used) by "fusion" and not connected via some ball type (MEANING: that the clearance between adapters should comply to a second constrain AFTER clash matters are addressed: this is one line of code more into that C#).
So ... I'll thy to translate the C# into components (but is 100 times easier to work with code than with these ... er ... mysterious/cryptic GH components, he he).
more soon…
ponents at all (C# , that is). Obviously this is a no-no > the wrong thing to do > back to the drawing board.
In the mean time get these 2 that are related with the issue (but how? I have no idea, he he).
The flatten (get the flying laundry back in a "stationary" state, he he) is challenging because ... if you change some mysterious things it turns ultra paranoid.
The other (intro to 3d grids) has a broad "repertoire" depending on your choices (and it doesn't comply with your grid inputs all the times - blame AI, he he):
…