l coarse mesh
Subdividing this mesh into strips of thin quads
Relaxing/Planarizing this mesh
Splitting and Unrolling
In this post I deal with the first 2 of these stages.
You can download the example definition here:
developable_strips_tutorial.gh
Drawing the initial mesh
To begin with we need a simple quad mesh. This can be modelled manually in Rhino, and only needs to use enough quads to give the topology and very rough form. No need to worry too much about the exact geometry or dimensions at this point, as we will refine and alter it as we go.
One very important thing that we do need to bear in mind though is that all internal vertices must have even valence (I covered this a bit in the earlier post here).
So for example, this is bad:
(because the highlighted vertex is surrounded by 5 faces)
While this is good (and can still be relaxed to the same shape):
(the top and bottom vertices have valence 8, and the vertices between the arms have valence 4)
With a little practice it should be possible to convert any mesh into one that meets this condition.
The reasons why we need this condition should become more clear in the later steps.
First subdivision
This is where we choose how many strips we want our final model to have, by applying a few rounds of subdivision using the Refine component (you could also use Weaverbird here):
Sorting the face directions
While quad meshes do not carry the same information about u/v directions as a NURBS surface, the individual faces do have a sort of direction given by their vertex ordering. However, these face directions are usually not consistently arranged, especially after subdivision.
The Kangaroo MeshDirection component attempts* to orient all the faces in a mesh so that they match with their neighbours.
For example, before sorting, if we draw a line from the midpoint of the first edge of each face to the midpt of its opposite edge, we might get something like this:
Whereas after sorting, we should get something like this:
*note that I say it attempts to orient the faces consistently. In some cases no valid solution exists, for instance if 3 or 5 faces meet around a vertex, hence the requirement mentioned at the start for even valence vertices.
Directional Subdivision
Now that we have consistent face directions across the mesh, we can apply further subdivision, but this time in one direction only. So we go from roughly square quads to thin rectangles. The idea is that as we apply higher levels of this directional subdivision, the final relaxed result goes towards something semi-discrete. A NURBS surface is fully continuous, and a mesh is fully discrete (made up of separate facets), while this strip model will be smooth in one direction and faceted in the other.
Go to part 2 for the next step of the process
…
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…
user to understand. RhinoScript is a generally more straightforward and easy to use. You can think of it as a translation of RhinoCommon so that you don't have to write all the technical stuff.
In your first line you've said "import rhinoscriptsyntax as rs". To see the methods you can call from this library you can go to the help menu and choose 'Help for Rhinoscript'. It will show you a searchable window of all the the options you have. This is much easier for new users to learn than looking at the RhinoCommon SDK.
If you search the help file for 'BoundingBox' you'll get the screen capture below:
At the bottom you can see an example of how to use it. In your case you would replace the following lines:
2/ boxA=brepA.GetBoundingBox((0,0,0,)) --> boxA = rs.BoundingBox(brepA)
3/ boxB=brepB.GetBoundingBox((0,0,0,)) --> boxB = rs.BoundingBox(brepB)
The script you have written uses elements of both RhinoScript and RhinoCommonSDK. I would suggest you might start just using RhinoScript. See below, I have re-written the first 8 lines of your script using just RhinoScript:
import rhinoscriptsyntax as rs
#Get BoundingBox from breps.BoundingBoxA = rs.BoundingBox(brepA) #Returns list of eight corner points.BoundingBoxB = rs.BoundingBox(brepB)
#Get centre point of RhinoScript BoundingBox (which is a list of eight points).boxA = rs.AddBox(BoundingBoxA) #Generate box from corner pointsptA = rs.SurfaceVolumeCentroid(boxA) #Get Volumetric Centroid of boxboxB = rs.AddBox(BoundingBoxB) ptB = rs.SurfaceVolumeCentroid(boxB)
For reference the following will achieve the same thing using RhinoCommon, fewer lines, but more technical. There are a few other quirks as well, for example you have to explictly tell the python component what kind of object 'brepA' is. See below for example of same script in RhinoCommon:
import Rhino as rh
centerPtA = brepA.GetBoundingBox(rh.Geometry.Plane.WorldXY).CentercenterPtB = brepB.GetBoundingBox(rh.Geometry.Plane.WorldXY).Center
I'm not sure what you are trying to achieve overall and your loop doesn't make a lot of sense to me but I hope that clarifies some of the differences between the two libraries you can use.
Regards,
M…
own use and added the command line port LPT1 port dump.
I found a couple of strange things in your code:
# Changes the model units to inches, but does not scale model.rs.UnitSystem(unit_system=8, scale=False)
Why did you change the model units here? HPGL units are 40 per mm (which is also 1016 per inch) staying in mm units in your model will be fine if your step scaling in right.
And doing this seems strange for a cutting program:
allCurves = rs.ObjectsByType(4)for curve in allCurves: if (rs.CurveDegree(curve) == 2 or rs.CurveDegree(curve) == 3) and rs.IsPolyCurve(curve): rs.ExplodeCurves(curve, True)allCurves = rs.ObjectsByType(4)
Cutting usually needs a closed curve to produce a nice clean removable piece from the material. Your approach results in a bunch of line/curve segments instead of closed polycurves/polylines. As this simulation shows the 'O's and 'R' are cut as a collection of curve segments - not closed polycurves:
I just removed this step from the code.
As this simulation shows every part of the font is cut in one cut action - exactly what I needed:
I saw your RVB code on the RhinoScript site too - was way more detailed than I needed - my vinyl cutter only has one 'pen' - the cutting blade. I just needed a really basic way of getting polycurves into HPGL format and firing it out to a printer port.
Thanks for your help on this little project - I'm very stoked at the result! Let me know if I can help with your cutter project.
Cheers
DK…
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,…
ino:
Go to "Windows Control Panel", then "Programs and Features", then find "Rhinoceros 5 (64-bit)" and "Rhinoceros", select and "Repaire".
Permalink Reply by Heath on August 14, 2013 at 1:13pm
I got it to work, thanks.
Permalink Reply by Akche MacEshwa on August 22, 2013 at 8:20pm
Right click the .rhi file and open it with rhino execution wizard which is located in Rhino directory. Good luck.
…
Added by Adam Donner at 5:38pm on September 19, 2013
ace Syntax." eCAADe 2013 18 (2013): 357.
http://www.sss9.or.kr/paperpdf/mmd/sss9_2013_ref048_p.pdf
The measure Entropy is newer. I hereby explain it (from my PhD dissertation):
Entropy values, as described in (Hillier & Hanson, The Social Logic of Space, 1984) and specified in (Turner A. , “Depthmap: A Program to Perform Visibility Graph Analysis, 2007), intuitively describe the difficulty of getting to other spaces from a certain space. In other words, the higher the entropy value, the more difficult it is to reach other spaces from that space and vice-versa. We compute the spatial entropy of the node as using the point depth set:
(11)
“The term is the maximum depth from vertex and is the frequency of point depth *d* from the vertex” (ibid). Technically, we compute it using the function below, which itself uses some outputs and by-products from previous calculations:
Algorithm 4: Entropy Computation
Given the graph (adjacency lists), Depths as List of List of integer, DepthMap as Dictionary of integer
Initialize Entropies as List(double)
For node as integer in range [0, |V|)
integer How_Many_of_D=0
double S_node=0
For depth as integer in range [1, Depths[node].Max()]
How_Many_of_D=DepthMap.Branch[(node,depth)].Count
double frequency= How_Many_of_D/|V|
S_node = S_node - frequency * Math.Log(frequency, 2)
Next
Entropies [node] = S_node
Next
…
2013 | mayo 30, 31 y 1 de junio. 15 Hrs.
Horario: 18:00 – 22.00 Jueves, Viernes y Sábado de 8:00 a 16:00 Hrs. Instructor_ Arch. David Hernández Melgarejo.
http://bioarchitecturestudio.wordpress.com
Objetivos:
El curso está dirigido a cada diseñador, ingeniero o arquitecto que quiere obtener una sólida base en modelado generativo y paramétrico dentro del flujo de trabajo en Rhinoceros.
En el curso se explorarán y construirán estructuras en el espacio paramétrico, incorporando entidades geométricas (Curvas, Superficies, Puntos, etc…) y usando patrones algorítmicos.
Cada paso será soportado con ejercicios que gradualmente incrementarán su complejidad.
El alumno aprenderá cómo trabajar con asociación geométrica y parámetros. Para perfeccionar asociación geométrica – asociación entre partes, asociación dinámica – las formas geométricas son generadas al seguir la conexión lógica entre la parte geométrica y su restricción, dimensión paramétrica y él proceso dinámico del diseño: en pocas palabras estimulamos el pensamiento relacional.
Resultados:
Los participantes con éste entrenamiento obtendrán las siguientes fundamentos.
· Construir, modificar, depurar y correr aplicaciones de Grasshopper.
· Comprender el editor gráfico algorítmico y sus patrones usando grupos y cables conectores.
· Trabajar con dimensiones dinámicas, parámetros y listas.
· Generar aplicaciones orientadas a la documentación del diseño y la fabricación.
Palabras clave:
Diseño Computacional, Scripting, Rhinoceros 5.0 + Grasshopper, Parametrización, Análisis, Fabricación Digital.
Para mayor información:
MArch. Kathrin Schröter. E-mail: kschroter@itesm.mx
Dirección de Arquitectura. Oficinas de Aulas 1, segundo piso.…
st variety of papers (mostly related with LIDAR airborne sampled clouds) ... but ... hmm ... no code (other than some "abstract" algos that may (or may not) work). Reason? A very hot cake that one these days: from reverse engineering to DARPA founded future defense systems and up to cruse missiles pattern recognition algos.
The solution (obviously doable only via code) is the so called flat hard clustering ... were points are sampled into clusters based on the coPlanarity "rule". For large amounts recursive octTrees (an oriented box divided in 8 "partitions") subdivisions are used and then pts are processed in parallel (and then clusters are re-evaluated in order to "absorb" other clusters with same plane A,B,C,D vars etc etc).
See what's happening in a very carefully made test point collection:
3.7 ms and the "ideal" clustering (7 search loops VS the max 42M theoretical threshold):
Depending on the pts "preparation" ... a considerable more time/search loops is required ... and ... well ... also "valid" clusters (4 points and up) made:
So "ideally" speaking in your case:
1. Mesh faces center points (or alternatively: mesh vertices) are sampled into a pts collection .
2. Hard flat coPlanarity clustering is attempted yielding pts/planes in equivalent DataTrees.
3. Planar Breps are made with respect the planes (like the black things captured above) and sampled, say, into a breps List.
4. The method Brep[] solids = Brep.CreateSolid(breps); is used for attempting to create your desired "engulfing" brep. This method is very slow mind (other waaaay faster approaches also available).
…
that both the ASHRAE and European Adaptive models were derived from surveys of awake occupants. While the topic has not been investigated as well as it should be, the few adaptive-style surveys of sleeping occupants that have been conducted show that people tend to desire significantly cooler temperatures when they are sleeping as opposed to when they are awake.
Notably, Chapter 8 of Humphrey's recently-published book on Adaptive Comfort (https://books.google.com/books?id=lOZzCgAAQBAJ&printsec=frontcover&dq=Adaptive+Thermal+Comfort+Foundations+and+analysis&hl=en&sa=X&ved=0ahUKEwi6npqSi__KAhUJMj4KHf7SCXMQ6AEIKjAA#v=onepage&q=Adaptive%20Thermal%20Comfort%20Foundations%20and%20analysis&f=false) provides some interesting insights into this. In a 1973 survey, Humphreys found that the quality of sleep started to deteriorate at temperatures above 24-26C regardless of the time of year and that there was no clearly-determinable lower limit to comfortable sleeping temperatures (in other words, people were fine at 12C if they were given enough blankets). He surveyed only British occupants who were sleeping in traditional beds with mattresses and a wide range of blankets. This is important because the nature of the findings is such that the comfort temperatures would be very different if the survey participants had been sleeping in a hammock or in closer contact with the ground (both popular practices for a number of cultures living in warmer climates). Traditional mattresses cut the ability to radiate body heat in half as compared to a standing human body and I would venture a guess that this is a big reason why much cooler temperatures are desired while sleeping on mattresses as opposed to standing awake/uptight.
So for your case, if you want to account for a time of the day that occupants are sleeping on mattresses, I would change the comfort temperature for this these hours down to 24C. Otherwise, if you are trying to show the comfortable hours of awake people in your space, your current 100% comfortable nighttime hours are a better estimate. I have also noticed that nighttime temperatures become comfortable in extreme weeks of hot/dry climates. This is what is happening in this extreme week simulation of Los Angeles' San Fernando Valley here:
https://www.youtube.com/watch?v=WJz1Eojph8E&index=3&list=PLruLh1AdY-Sj3ehUTSfKa1IHPSiuJU52A
I will put in the ability to set custom values for comfort temperatures into the Adaptive Comfort Recipe soon so that you can test out a 'sleeping comfort temperature' if you would like. I have created a github issue for it here:
https://github.com/mostaphaRoudsari/Honeybee/issues/486
I was not so convinced by Nicol's argument about humidity on those pages as I was when I saw the correlations of both operative temperature and effective temperature to surveyed comfort votes in real buildings. Humphreys shows these correlations on page 106 of the book I linked to above. Notably, the correlation of Effective Temperature to comfort votes (0.257) is slightly worse than the correlation of just Operative Temperature (0.265). In other words, trying to account for humidity actually weakened the predictive power of the metric. This difference in correlation is not so great as for me to discount an Adaptive comfort model based on Effective temperature (as deDear once proposed). However, the correlations of PMV (0.213) and SET (0.185) to comfort votes are so poor that I now use the PMV model only with great caution.
This reason for the decreased importance of humidity may be multi-faceted, whether it's Nicol's explanation or another. Still, the data suggests that we are probably better off ignoring humidity when forecasting comfort and should only consider it when evaluating conditions of extreme heat stress where people's primary loss of heat is through sweating.
-Chris…