h. For a while I have been thinking about the possibility of gpu computing for leveraging computation but I am still scratching the surface mostly. I know its a kind of hot topic in scientific computing. and I know there is a community of parallel programming with python... but that's more down the line of my development...
anyways, I ended up just sorting all the points by their z value.
So I have been able to use the vertex to extract color gradient and draw lines aligned to the vertex normals. However the normals at the edges of the slabs I get diagonal normals, and they seem to be somewhat inconsistent. I would need to either round them up to a certain angle or cull them out... not sure how to do this right now.
and I feel there should be a convenient way to organize and branch points by what faces, mesh, or close curve they are included. and I found this thread where I can test points by their surface inclusion. I have never used the "D" output of surface evaluate but this might work.
Well anyhow the fun begins - facade design!
I want to detail rainscreen panels and offset them where there is more radiation falling over the course of the year.
I also want the southern facade to work like a solar chimney (in the lower half, like a climbing solar chimney) that channels hot air building up the facade from the sun all the way to the roof, and pull air cross the interior out of vents. So I need to further divide the facade surface breps to fixed rainscreens and operable shades.
my goal is to move the information over to detail and specificate to revit. and this would make a good occasion to test out the brand new mantis shrimp. I hope I can run revit + dynamo and this analysis together :)
So I think I might be at the end of this particular thread - the answer to the RAM bottleneck is - DOWNSIZE YOUR SAMPLES!
…
ives that have been shared so far.
Intersect Shouldn't Punt When Encountering Areas of Intersection
Several posts talk about how Booleans are really just shortcut implementations of the Intersect/Trim/Split/Join (ITSJ) design pattern. Agreed. I realized this when trying to understand and resolve my first Boolean related problem. So when I broken down my characterization to the 4 component steps, I found is that it was the Intersect operation that was generating an erroneous (read: incomplete) set of intersection curves. I posted my findings along with a possible solution in an email to McNeel tech support and in this Rhino discussion an edited version of which I’ve quoted again below. But the only response I received from McNeel was that I shouldn't expect any changes in the product that improves Booleans.
The unexpected behavior I've been having with Rhino, and by extension Grasshopper, is that the current implementation of the Rhino Intersect command is generating an incomplete network of curves when given 2 surfaces having regions that are (almost) coincident. When Intersect determines that there's no single curve able to represent the intersection in those areas, but rather an area of intersection, Intersect erroneously doesn't generate any curve to represent that portion of the intersection — which is mathematically incorrect. This decision to "punt" in these situations renders the generated results to not be useful for subsequent steps of the ITSJ design pattern. Rather than not including these areas of intersection in the network of curves, Intersect should generate any non-kinky, non-looping curve(s) through a region of intersection that connects with all other intersection curves adjacent to the region. Any valid curve is far more useful — and mathematically correct — than no curve through these regions.
Informative and Detailed Error Reporting Will Save Users’ Time
A number of users feel as I do that the error information available when an operation fails is insufficient.
The Rhino Learning Curve Is Fractally Steep
While some responses have suggested that I’m just too new to Rhino, a number of long-time Rhino users have said that they are continually “learning” the product's idiosyncrasies, and expect that they will never really know what the product will do every time. What they’ve learned from their years of experience is how to hack their designs to work around Rhino’s quirks.
I conclude from these stories that, sure, I’m green, but that I, all of us, are destine to be forever “green” because the current development methodology results in a product that can never really be understood.
Wow.
In his reply above @Paul N Jeffies said…
One thing that's important to understand when using Rhino for this kind of thing is that Rhino does not have a particularly meaningful conception of a 'solid object' - solids are defined simply as a collection of (infinitely thin) NURBS surfaces joined together with no gaps between. That's part of the reason for the problems with booleans in Rhino, but it also means that you don't really need boolean operations since you can do everything by exploding the polysurface and using the Intersect/Trim/Split commands on the individual surfaces to build up the boundary surfaces you want, then rejoin into a solid afterwards.
As a software architect with ~40 years of tech experience, I would again suggest that the root cause of the product's unknowability is the lack of rigor so far exhibited in defining the layers of abstraction. If proper rigor were applied, then, from a user’s perspective, a solid really would be a solid. The proper way to reduce a solid to a set of adjacent surfaces would be to use a function like ExplodeSolid, and to get a set of curves from a surface we would have to use ExplodeSurface, and so on. So rigor doesn’t prohibit users from pulling back the curtain, but rather empowers the core development team to enforce encapsulation at the current layer of abstraction — whether point, curve, surface, solid, or whatever.
The Solution Begins With Changing The Conversation
With all this said, I don’t believe that Rhino is fatally flawed or impossible to fix. I also don't believe that the resulting loss of productivity is the users' fault. I do believe though that the first step is for all, McNeel and users, to name the condition, raise this as a high priority, work collaboratively to define a corrected abstraction stack, and add appropriate rigor to the implementation of the next major release.
About a month ago I spent about 1/2 hour searching through the Rhino discussions for topics related to The Boolean Problem. I found literally 100's of posting, with many noops like I am now saying they were giving up and going to another tool because Rhino’s learning curve was too steep. Yes, filleting and trimming are two other big Rhino problems that I believe have similar roots. Yet I wonder whether these deep-seated challenges could, in fact, be overcome — by first changing the conversation.
I’d again ask what other, more experienced users think.
- Bob…
Added by neobobkrause at 2:49pm on October 4, 2016
that aren't relevant anymore or if there are any I missed please let me know. Maybe we can get a list like this in a better place as well.
Thank you.
Right Mouse - When wiring, plugs wire into multiple inputs.Shift+Click - Pick component aggregate.Shift+Clicking - Place component aggregate.Alt+Left - Click Split canvas tool.Ctrl+Q - Preview toggle.Ctrl+E - Enable toggle.Ctrl+Left - Navigate upstream.Ctrl+Right - Navigate downstream.Ctrl+M - Mesh Edge display toggle.Ctrl+1 - No previewCtrl+2 - Wireframe preview.Ctrl+3 - ShadedCtrl+Alt+Shift+Click - Save image of canvas.Ctrl+Alt and Shift+Ctrl+Alt - Highlights components on the canvas and component palette.Ctrl+Shift - Rewire component input/output.Double Click - Find/SearchAlt+Drag - Copy component on canvas.Ctrl+Tab - Document cycling.Ctrl+Shift+P - PreferencesCtrl+N - New fileCtrl+O - Open fileCtrl+S - Save file.Ctrl+Shift+S - Save as.Ctrl+Alt+S - Save backup.Ctrl+W - Close open document.Ctrl+Z - Undo copy.Ctrl+Y - RedoCtrl+X - CutCtrl+C - CopyCtrl+P - PasteCtrl+Alt+V - Paste in placeCtrl+Shift+V - Paste in centerCtrl+A - Select allCtrl+D - DeselectCtrl+Shift+I - Invert SelectionCtrl+Shift+A - Grow SelectionCtrl+Shift+Left Arrow - Grow UpstreamCtrl+Shift+Right Arrow - Grow DownstreamCtrl+Left Arrow - Shift upstreamCtrl+Right Arrow - Shift downstreamCtrl+G - Group selectionF3 - FindF4 - CreateF5 - RecomputeCtrl+B - Send to backCtrl+F - Bring to frontCtrl+Shift+B - Move backwardsCtrl+Shift+F - Move forwardsInsert - Bake selectedCtrl+Q - Toggle previewCtrl+E - Toggle enabled selected
…
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
termedio a avanzado.
2013 | mayo 22, 23, 24 y 25. 20 Hrs.
Horario: 18:00 – 22.00 Jueves, Viernes y Sábado de 8:00 a 15: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 para la generación de estructuras con metabolismos contextualizados.
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 sus restricciones, dimensión paramétrica y él proceso dinámico del diseño: Estimulamos el pensamiento relacional para la construcción de Diseño y Arquitectura de alto desempeño.
Resultados:
Los participantes con éste entrenamiento obtendrán las siguientes fundamentos.
· Generar aplicaciones orientadas al análisis, la optimización, documentación del diseño y fabricación.
Palabras clave:
Diseño Computacional, Scripting, Rhinoceros 5.0 + Grasshopper, Parametrización, Análisis, Galapagos, Genetic Solver, Optimización, 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.…
s my code, so I decided to write a new simple component refreshing all time at 300 ms interval and the problem came up again. The code provoking the display exceptions and images with the erros are listed below.
----------------------------------------------------------------------------------------------
using System;using System.Drawing;using Grasshopper.Kernel;using FirstComp.Properties;using System.Timers;namespace FirstComp{ public class FirstCompGH : GH_Component { private Timer myTimer = new Timer(300); //3 veces por segundo private Random rand = new Random(DateTime.Now.Millisecond); public FirstCompGH() : base("Nombre", "Abreviado", "Descripcion", "Categoría", "SubCat") { myTimer.Elapsed += new ElapsedEventHandler(MainLoop); myTimer.Start(); } protected override void RegisterInputParams(GH_Component.GH_InputParamManager pManager) { pManager.Register_DoubleParam("Op A", "A", "Primer parámetro de la operación",0.0); pManager.Register_DoubleParam("Op B", "B", "Segundo parámetro de la operación",0.0); } protected override void RegisterOutputParams(GH_Component.GH_OutputParamManager pManager) { pManager.Register_DoubleParam("Suma", "S", "Resultado de la suma"); pManager.Register_DoubleParam("Resta", "R", "Resultado de la resta"); pManager.Register_DoubleParam("Mult", "M", "Resultado de la multiplicación"); pManager.Register_DoubleParam("Div", "D", "Resultado de la división"); } protected override void SolveInstance(IGH_DataAccess DA) { // Variables para contener los datos de entrada // Le podemos asignar algunos valores iniciales. double opA = double.NaN, opB = double.NaN; // El objeto DA recupera los datos de la entrada. // Si no hay datos de entrada abortamos. if (!DA.GetData(0, ref opA)) { return; } if (!DA.GetData(1, ref opB)) { return; } opA += rand.Next(1,10); opB += rand.Next(1,10); // Ahora realizamos las operaciones matemáticas DA.SetData(0, (opA + opB)); DA.SetData(1, (opA - opB)); DA.SetData(2, (opA * opB)); if (opB != 0) //Rhino.RhinoMath.ZeroTolerance DA.SetData(3, (opA/opB)); else { AddRuntimeMessage(GH_RuntimeMessageLevel.Error, "Error de división por cero"); return; } } public override Guid ComponentGuid { get { return new Guid("44BEA3FE-7CB8-42fe-AEC9-BE5F6EE424E8");} } protected void MainLoop(object source, ElapsedEventArgs e) { this.ExpireSolution(true); } protected override Bitmap Internal_Icon_24x24 { get { return Resources.icono; } } }}
-------------------------------------------------------------------------------------------------
Images showing errors.
I can't figure out what is causing these errors.
Best Regards
Ernesto
…
j
1
c
e
h
k
2
f
-------------------------------------------------------------------------------------------------
To these...
0;0
0;1
0
a
i
------------------------------------------------------------
0;0
0;1
0;2
0
b
g
j
1
c
h
k
------------------------------------------------------------
0;0
0
d
1
e
2
f
------------------------------------------------------------
Thanx……
will work slightly different from before. Sorry about breaking this, but it proved impossible to improve the selection logic with the fairly ambiguous notation that was implemented already.
Not every change is breaking though and I hope that most simple matching rules will work as before. There will be a McNeel webinar on Wednesday the 6th of November where I discuss the new selection rules (as well as path mapping syntax and relative offsets within one or more data trees). This will be a pretty hard-core webinar aimed at expert users. The event will be recorded so you can always go and watch it later. I figured I'd briefly explain the new selection rules on Ning before I release the update though.
-------------------------------------------------------------------------------
Imagine we have the following data tree, containing a bunch of textual characters:
{0;0} = [a,e,i,o,u,y] {0;1} = [ä,ë,ê,ï,î,ö,ô,õ,ü,û,ÿ,ý] {1;0} = [b,c,d,f,g,h,j,k,l,m,n,p,q,r,s,t,v,w,x,z] {1;1} = [ç,ĉ,č,ĝ,ř,š,ş,ž]
There are a total of four branches {0;0}, {0;1}, {1;0} and {1;1}. The first branch contains all the vowels that are part of the standard English alphabet. The second branch contains all non-standard vowels and branches three and four contain the standard and non-standard consonants respectively.
So what if we want to select from this tree only the standard vowels? Basically include everything in the first branch and disregard everything else. We can use the [Tree Split] component with a selection rule to achieve this:
{0;0}
This selection rule hard-codes the number zero in both tree path locations. It doesn't define an item index rule, so all items in {0;0} will be selected.
If we want all the vowels (both standard and non-standard), then we have several options:
{0;?} = select all branches that start with 0
{0;(0,1)} = select all branches that start with 0 and end in either 0 or 1
{0;(0 to 1)} = ......................................... and end in the range 0 to 1.
Conversely, selecting all standard vowels and consonants while disregarding all non-standard character can be achieved with rules as follows:
{?;0}
{(0,1);0}
{(0 to 1);0}
It is also possible to select items from each branch in addition to limiting the selection to specific branches. In this case another rule stated in square brackets needs to be appended:
{0;?}[0 to 2]
The above rule will select the first three vowels from the standard and the non-standard lists.
Basically, rules work in a very consistent way, but there are some syntax conventions you need to know. The first thing to realize is that every individual piece of data in a data-tree can be uniquely and unambiguously identified by a collection of integers. One integer describes its index within the branch and the others are used to identify the branch within the tree. As a result a rule for selection items always looks the same:
{A;B;C;...;Z}[i] where A, B, C, Z and i represent rules.
It's very similar to the Path Mapper syntax except it uses square brackets instead of parenthesis for the index (the Path Mapper will follow suit soon, but that won't be a breaking change). You always have to define the path selector rule in between curly brackets. You can supply any number of rules as long as you separate them with semi-colons.
The index rule is optional, but -when provided- it has to be encased in square brackets after the path selection rule(s).
The following rule notations are allowed:
* Any number of integers in a path
? Any single integer
6 Any specific integer
!6 Anything except a specific integer
(2,6,7) Any one of the specific integers in this group.
!(2,6,7) Anything except one of the integers in this group.
(2 to 20) Any integer in this range (including both 2 and 20).
!(2 to 20) Any integer outside this range.
(0,2,...) Any integer part of this infinite sequence. Sequences have to be at least two integers long, and every subsequent integer has to be bigger than the previous one (sorry, that may be a temporary limitation, don't know yet).
(0,2,...,48) Any integer part of this finite sequence. You can optionally provide a single sequence limit after the three dots.
!(3,5,...) Any integer not part of this infinite sequence. The sequence doesn't extend to the left, only towards the right. So this rule would select the numbers 0, 1, 2, 4, 6, 8, 10, 12 and all remaining even numbers.
!(7,10,21,...,425) Any integer not part of this finite sequence.
Furthermore, it is possible to combine two or more rules using the boolean and/or operators. If you want to select the first five items in every list of a datatree and also the items 7, 12 and 42, then the selection rule would look as follows:
{*}[(0 to 4) or (6,11,41)]
The asterisk allows you to include all branches, no matter what their paths looks like.
It is at present not possible to use the parenthesis to define rule precedence, rules are always evaluated from left to right. It is at present also not possible to use negative integers to identify items from the end of a list.
If you want to know more, join the Webinar on Wednesday!
--
David Rutten
david@mcneel.com
Seattle, WA…
Added by David Rutten at 8:57pm on November 3, 2013
are doing):
It's supposed to be an ARCHITECTURAL TAILGATING PAVILION,I had no idea what tailgating was at first,but apparently before the games(basketball,football...) or sometimes even during the games,people bring a canopy with themselves usually with a truck and start drinking,barbecuing,and watching the game under that!so as this semester's project,we want to design a pavilion instead of the ordinary cheesy canopy:D
The questions involved in the design of this tailgating pavilion are:
-it better have something with texas tech university but it's not really necessary!
-time management (installation and de-installation)
-having it into pieces that fit in the truck
-using new digital methods will be welcomed ( for example instead of having the typical television there,we can propose something like what zaha hadid did in the chanel pavilion,I guess she is projecting stuff on one of the wall panels(see the picture below))
-it should cover an area between 200-500 square-feet (20-50 sqm)(it's only for a few people(family and friends).
-the base surface that I provided in the rhino file is not what it will look like,I just made that to test the grasshopper definitions on it.so the shape of this tiny pavilion should try to devide the area into different zones to provide a scenario(oh they cook the food here,serve it there,and watch the game on the other side),so it could be a single volume or maybe a combination of different volumes ,Site placement design expressing content and messages rather than acting as a ‘container' or as the professor explained:
"It may comprise a single volume, or a number of smaller volumes, with internal spaces for few people gathering events and a possible dining - seating zone. Fifty per cent of the volume must be in the open air, not fully enclosed and be planned as to function also as an additional exhibition space as well as providing for a possible food outlet.
Capable of hosting small to medium-sized events and delivery of a retail, food and/or drink offer by sponsor partners.Mobility: designed to be erected in short time, plan to be used for one day only, and de installed by end of the day."
-at first I started with a voronoi shape on surface,but when I thought it through I saw that it's gonna be hard to assemble it when it comes to the physical fabrication,so I decided to use the triangles and try to kinda represent the voronoi pattern,not actually using it.
-the most important thing after coming up with the actual surface and volume for the pavilion is the joints.The material we should use is plastic!we can use the hot wirecutter to cut foam(that limits us to use a ruled surface for each of the modules),then we can either use the vacuum to get the shape and then use it to make molds(resin,glassfiber mold),actually I just got an email from our professor explaining that"Maximum table reach for a large modul is ~ 2050 mm or 1/2 of 13'-1/1/2" diameter. So a 8'x4' panel could be worked upon within the working space radius."
we can even use the foam as composite with the resin-fiberglass and not necessarily detach them.
I provided here some pdfs,for pavilions using plastic,the PE sheets seem interesting but I am not sure how to bend them exactly.(it is still considered using plastic,we dont have to necessarly use the instructions on how to use plastic that I explained above)(the first pdf provides good examples of plastic,and the second one has some example of joints"
-I am also wondering if I need to use any structure analysis plugins,to see if the shell will actually work and not fall apart in real life) ( I am not sure what plugins I can use for that since I am really new to grasshopper)
-also I am not sure what to do about the openings on the surface,I feel like maybe some of the modules shouldnt have openings(because of the sun,rain and also the dark needed in order to watch TV in the " TV area".and also for providing a more organic cool shape,and have differentiation in pattern like the first photo I provided in this discussion,which is also because those panel are smaller,and I tried to control the opening sizes with an attractor point so maybe later I can use the attractor points to control the opening sizes for the different zones"
I guess I never talked this much in my life,but I wanted to thoroughly explain what I nee to do,which was not bad for putting my thoughts together:D hehe:))
and as you can see I want to do alot with the small knowledge that I already have:(
hopefully I can make some modules with plastic,foam and/or resin composites showing the joints,and then maybe design a smaller area than the pavilion and make a tiny physical shelter,lol
…