Illuminants like "A" or "D65" are spectral power distributions that are defined (as per CIE S 014-2/E:2006) for wavelengths ranging from 300nm to 830nm.
For example, CIE Illuminants A,B and C are defined as :
And D65 is defined as :
For illuminance and luminance calculations, the radiation from such illuminants are converted to Lux or Candela/sq.m by weighing them against the Photopic Luminous Efficiency function (also called as V-lambda):
The equation (1) used for this purpose is
Where y corresponds to the V-lambda function and J corresponds to an illuminant like "D65" or "A".
So, why is all this relevant? Honeybee/Radiance also use a similar method for calculation of luminous flux, illuminance and luminance. However, in the case of Honeybee/Radiance the lighting calculations are limited only 3 (R,G,B) channels (and not the 300nm to 830nm). So the equation (1) from above becomes something like:
F = 47.4*R+120*G+11.6*B
Where (R,G,B) refers to the spectral power of the radiation and the numbers (47.4,120,11.6) relate to the V-lambda function. So, the bottom line is that an accurate representation of CIE illuminants is not possible inside Radiance/Honeybee as the spectral information is severely restricted. Some studies have proposed using Radiance with more than 3 channels. For example: http://link.springer.com/article/10.3758%2FBRM.40.1.304 . However, such attempts have been limited. What is possible with Radiance/Honeybee is to create a fairly accurate representation of brightness of the sky. Although, I can explain that too, I would suggest that you try this link first: http://www.bozzograo.net/radiance/index.php?module=FAQ&func=dis...
By the way, which CIE document are you referring to for CIE sky definitions ?…
p others facing similar issues. 1) Letting Grasshopper perform the "implied" loop can be substantially slower than making the loop yourself inside the Python script. This is understandable, however the strangest thing is that it is MUCH slower if the definition has been saved than when it has not (by about a factor of 10)! 2) Setting type hints seems to be slower than inputting data with "No Type Hint". This depends a bit on which type is being input, but this seems to be fairly consistent. In the attached example by about a factor of 3. I suppose this is understandable, but not exactly ideal. 3) Outputtings lists with many items will often take longer than the actual computation performed by the script. I suppose this is more of a Grasshopper thing. My workaround has been to wrap the list in a Python list and pass this along as an item, which will be ALOT faster with large lists (this was crucial to both the Tower and ShapeOP where we pass around large amounts of constraints).
4) Calling certain RhinoCommon methods appear to be randomly much more expensive than using the C# scripting component. For instance, when iterating over a mesh's vertices and calling Mesh.Vertices.GetConnectedVertices() the elapsed time sum of these calls seem to be comprised of only a few vertices which randomly change every time the script is run. The amount of vertices differ on different machines, but the pattern remain consistent. I'm not sure if these bottlenecks are just examples of me being dumb, if so I hope you can enlighten me to the errors of my ways :) Attached some screenshots of an unsaved/saved definition which demonstrates the described issues. Also please find the gh definition attached. Best, Anders Edit: Logged this on Github here. Update: Added point 4), new screenshot and file demonstrating this behaviour.
System: Rhino Version 5 SR11 64-bit (5.11.50226.17195, 02/26/2015) Grasshopper 0.9.0073 GHPython 0.6.0.3 Laptop …
is also takes place in own system. However, this action can be also carried out successfully by a foreign reference, if this considers the focused system as own. Hence, these two criteria are considered in my reflexions, to make your criticism handier for me.
First the question must be put up, how is it in your case? Of friendly manner you answer this question perpetually with the statement that you are not a partial of the system of the architecture.
Furthermore the question would be appropriate, whether an external reference (eg CAD) determined architecture. This can be answered with no, because determining and influencing are different things.
Because you stress now your criticism as a foreign criticism, within the architecture the assuption must be put up, that this criticism is not unusual new on the one hand (because this condition were also in other times like that, and presumably also always so remain) and further more a lack of goodwill in your criticism comes to light, which perhaps distinguishes an external reference.
Based on your critique, it would be also desirable in the system of the architecture if the academic rules become satisfyingly followed, even if this is no guarantor for good academic works. Nevertheless, there is an aspect which at least tolerates the evident lack in the Interdiziplinarität of the architecture. This is the classical and still valid determination of the architecture, presumably regulates not only the actions of the architects, but also those who want to become it.
Many who stand in your criticism (the students, as well as the teachers, ... ), live in the awareness that architecture is a profession that combines as many areas around the topic of Building, and the architect is even only one dilettante among the external specialists. In this determination dilettantism is revalued rather positively, because this state the architects enables to assess the facets of a complicated building project better and to form thereby the whole result positively. To be a good architect, you should have circumspect specialists around yourself. And exactly this knows the system of the architecture, because "THE ARCHITECT" helps himself with the logic of other systems (to repair on the one hand his own deficits), and to create an artificial complexity, which ultimately aims to be the complexity of human beeing.
Here "THE ARCHITECTS" becomes a quality-spoken, which currently seems the external reference (CAD, BIM) would like to take claim for themselves.
........
If would not thought about it, this might be helpful:http://www.amazon.com/The-Alphabet-Algorithm-Writing-Architecture/dp/0262515806/ref=sr_1_1?ie=UTF8&qid=1376920450&sr=8-1&keywords=mario+carpo"Finally, I’d like to restate my criticisms in general terms. If we are serious about moving architecture and urbanism away from purely artistic considerations and into a more rational arena, there has never been a better time than now. All of us have access to immense computational power which can be applied to problems that have been —until quite recently— intractable. But of course the garbage-in-garbage-out adage holds true; computation can be used to generate large amounts of complexity, but complexity does not equal worth. The only time when it makes sense to invoke computation in the design process is when there is some relevant data that needs to be computed" (David Rutton)I want to make it short, and just ask a few questions, and hope that the following questions are relevant also for you, and not be considered outside your system. i think that the weighting to such questions seem to be more valuable, not for the architects.1. What is wrong from a pure artistic intention?2. What is any sense in purely architectural discourse?3. strictly looked, can be determined sense generally in a purely architectural discourse?4. What is purely architectural discourse?5. What is Funktionalismus or Rationalismus without philosophical support? 6. Would not be the pure functional fulfilment empty ? 7. Would be not a critical position on the promise of purely rational algorithms applied?…
na cubierta o una estructura sigue en pie; presentar el router cnc en el evento depende del ejercicio práctico, para mayores informes no duden en escribir a luzyextura@gmail.com o a las oficinas de Bishon en Querétaro
_______________________________________________________
Workshop de arquitectura paramétrica mediante procesos digitales.
El temario incluye aspectos básicos y medios del modelado en Rhino, tanto de dibujo como de objetos en 3D, y las funciones de Grasshopper como una herramienta para el diseño paramétrico.
Al finalizar el curso, los asistentes serán capaces de manejar Rhinoceros y Grasshopper en un nivel medio, también comprenderán todas las herramientas básicas y el estilo de trabajo.
Además del contenido teórico se incluye un ejercicio práctico, que consiste en la producción de un modelo 3D, abarcando desde las ideas generadoras, el diseño, dibujo de piezas para su fabricación y construcción final.
El workshop tiene dos semanas de duración, con un horario de 8 am a 3 pm, el costo para estudiantes es de $4590, para la comunidad en general $4900. 35% descuento antes del 22 de julio
Informes bishion@mail.com, luzytextura@gmail.com.
Teléfono en Querétaro 4422 75 2863
Teléfono en la Ciudad de México 04455 4381 3302…
essarily architectural. As you can guess from the tone of my previous response, I finished with school and had a hard time finding a job that focused on the technologies I delt with all through undergrad and grad. During grad school I was working with ASGvis (the makers of V-Ray) so I got exposed to the software side of things both on the support/management side and the development side. Now I'm off on my own doing development projects like RhinoHair, a few others, and some custom plugins for clients. Not necessarily what I thought I'd be doing after grad school, but I'm certainly enjoying it more than the "standard" practice of architecture.
I definitely understand "creating" a program. I did both my undergrad and grad at Catholic U here in DC, and although there was some ground work laid in regards to fabrication, I was one of only two or three students spearheading a lot of the scripting/GH/parametric stuff and some of the topics that go along with them (algorithmic design, adaptive systems, advanced geometry). One thing that was incredibly helpful for me was to pair up with the most advanced and forward thinking professor(s) that you can and take their studios, electives, and/or help out with their research. I was lucky enough to pair with a professor who had been at MIT and really encouraged me to explore my interests and sharpen my technicial skills.
It might also be a good idea to stick your head in some other departments, probably the math and engineering ones, or even biology and economics if there are some forward thinking professors. Talk to some people and get a different perspective on things. When I went to the ACADIA conference in 2008 it really opened my eyes to some of the potential influence from those different arenas.
Fabrication wise, I'd really try to focus more on milling (3 axis is fairly standard, 5 axis if you can get access) than 3d printing. Printing is a lot of fun, but ultimately we're not printing buildings (yet), so some of the milling processes will be much more valuble. If your school doesn't have those kind of facilities on campus (either in the Arch dept or engineering or something), then contact a local fabricator and see if you can work together somehow or someway. You'd be surprised and how many fabricators are interested in talking to architects.…
Added by Damien Alomar at 3:13pm on February 8, 2010
ign to every location in the space is the result of the fall-off equation. F/D² in the Metaball componenty, where D is the distance from the point to the location you're measuring and F is the scaling factor:
3) You repeat this for all the points, giving you a collection of revolved hyperbola:
4) Add the elevations for all hyperbolas together, just a simple A+B+C process:
5) You intersect this final landscape with a horizontal plane. The elevation of this plane corresponds with the iso-surface value. If we do it for a bunch of planes, you get the following result:
6) The interior of each slice represents the metaball, or rather the boundary of each slice:
That is the theory anyway, in order to actually get a speedy result the algorithm approaches the problem from a very different angle, but the result should be the same shape.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
he strip at the connection point. In fact, maybe try making the mesh along the whole strip symmetrical by splitting each rectangle into 4 triangles instead of just 2.
With just one spring between the 2 strips you have an elastic connection between their positions, but no constraint on their rotations.
I would suggest using some bending forces like this:
where the red squares represent a bending force between their 2 adjacent edges, with a rest angle of pi/2
This gives some resistance on 5 of the 6 degrees of freedom between the 2 strips, but leaves them free to rotate about the axis of the bolt, which I presume is what you want.
Alternatively, if you want the strips to actually lie on each other without any spacing, you could model it like this:
where the yellow line is a spring connected to both strips at one end and free at the other.
and there are still 4 perpendicular bending forces between this line and each strip.
This gives a hard constraint on the 3 translational degrees of freedom, elastic resistance on 2 of the rotational dofs and free on the last 1.
I hope this helps, let me know if you have any problems modelling this in Kangaroo.
As I've mentioned before - I am working on giving each node 6 degrees of freedom, which would mean you could model each strip as just a polyline, and specify directly the rotational constraints between any pair of particles.
…
Rhino plugins to work in the mac version. As I understand it, what is holding up the GH making it over (fully) to the mac version is its dependence on the graphics libraries for Windows. There is no easy direct translation here, so, this is still under development. There is info spotted around the forum, you just need to dig deep enough to find it, and see that there is development of GH for Mac, but still, we should not hold our breath as there are significant hurdles to overcome. These hurdles are just technical, and should have a solution. Below are some references that point to the graphics issue I am discussing as well as a list from David where he does state that he is working on the Mac version.
Another positive note is that in Rhino 6, GH will be along for the ride...meaning (as I understand it) that we will not need to download GH after installation, it will be part of the Rhino install. I think this is a positive note as it means that GH will be more associated with the default Rhino experience, an experience which should carry over to the Mac version.
So, to sum up:
1. GH for Mac will probably happen.
2. Seems all of the code that does not depend on the graphic part (the logic in the components, Rhinocommon) already works in the mac.
3. Other Rhino plugins are already making their way to the Mac.
4. GH is becoming part of the default Rhino experience, and should probably carry over to the Mac experience.
5. Don't hold your breath. When it will happen is not under anyone's control necessarily. The solution needs to be practical in order for it to be rolled out.
My $0.02.
References:
http://www.grasshopper3d.com/forum/topics/partial-developer-absence?commentId=2985220%3AComment%3A929795&xg_source=activity
http://www.grasshopper3d.com/forum/topics/grasshopper-for-mac-update?xg_source=activity…
...hmm... points across the facade edges are not included (or may be some) and thus the whole thing is the art of pointless.
2. See the 1a unfinished part ... that defines internal boundaries for that purpose - then you need to create points across the edges, random reduce them and merging the list with the other points...blah blah.
3. That way each facade could yield structural members that touch the edges (where the biggest HEB/columns are expected to be). Obviously nodes are shared between facades with a common edge - the best logical approach for obvious real-life reasons.
4. The whole approach is stupid : here we need some Hoop snake "loop" control (that could take into account the critical connection angle constrain) in order to achieve a "progressive" deployment of the diagonal members in order to satisfy structural requirements and ... hmm...aesthetics. Free espresso for everyone is an added bonus.
5. Bottom to top design mentality is urgently required here: mastermind some 3d conceptual arrangement of nodes keeping in mind ... well...just 345,67 different real-life factors (but you could combine insulation and fireproofing if you use my favorite material: Foamglas - name with with one "s"). That way you can define the critical deployment planes : i.e. diagonal rigidity members, some facade aluminum system and floor main perimeter I-Beams MUST be in different planes.
I'll be back with a more stupid version of that thing.
may the Force ...blah blah
…
ncluded 3) using a freaky thing that "makes" Planes in order to do ramps (spot the Vodka option = Mobius + antigraviity OFF).
Don't touch the freaky things: for the moment just go and play with this palatable portion (GH components, nothing to fear he he):
depending on choice in gates: Paranoid (Mobius "shifted in Z")
sane (using corrected Planes):
not so sane:
What we have learned so far? Well ramps (and most of other things) ... it's about Planes (coordinate systems) you know.
Again: this is for fun/demo ONLY. I'll prepare a dedicated def for your case soon.
have fun, be brave
…