this really make sense. (But didn´t happen on this way with my results)
I did table and graphic (with numbers results for colors variations – red to blue) to expose better what is my point.
Looking radiation roses, the sequence - September, June, December and March (my results to 10:00h) is similar what happened to direct radiation.
The sequence March, December, June and September, is similar what happened with diffuse radiance. (My results to 15:30h)
Then the period 10:00 to 15:30h is similar to the graphics diffuse radiance too.
So I’m thinking what’s happening with my results, has more relation with radiation diffuse or direct (radiation roses), then with sun position. Because on this way March and September would be similar radiation. Do you agree? Is it correctly?
If this argument proceed, I did not found any theory that says that on the morning has more direct radiance or in the evening has more diffuse radiance. Do you know where these climate information are taken? To know if are reliable!
Thank you very much
…
ich appears in the video is related to "set iterations number" in your example?
2. only works the first example in your GHX def... the other get crashed when compiling into mesh component take a look on the screenshot, maybe its problem with GH version? i'm usin 8.051
3. The sliders that controls the "# of iterations" it has range 0 to 99999 but on my computer it only works from 0 to 15 ... that's correct???
thank you in advance!
…
shopper and rhino files and tried messing with them to get a feel of the components. Now, in that file, the component ssiBeam is used, which I'm assuming is likened to the current version's ggSAPFrame? Now, in the old file, I went and created a section property with the new gg component and used it for the truss you had in there with no problems, but when I try to do the same thing for a file of mine that uses the ggSAPFrame component, the sections don't "extrude" right (for lack of a better way of putting it), and the section properties do not get baked into SAP when I use the ggSAPBake component (the element centerlines bake fine). Am i missing something here? Does the baking perhaps fail or go haywire if I don't have supports, or all elements of the structure baking at once (I started with just a few to try to get a feel for it). Any light you could shed on this would be great, thanks for all the help so far.
Matt…
ocessed once Grasshopper is done with whatever it's doing now.
3) Grasshopper tells the Slider object that the mouse moved and the slider works out the new value as implied by the new cursor position.
4) The slider then expires itself and its dependencies ([VB Step 1] in this case, but there can be any number of dependent objects).
5) When [VB Step 1] is expired by the slider, it will in turn expire its dependencies (VB Step 2), and so on, recursively until all indirect dependencies of the slider have been expired.
6) When the expiration shockwave has subsided, runtime control is returned to the slider object, which tells the parent document that stuff has changed and that a new solution is much sought after.
7) The Document class then iterates over all its objects (they are stored in View order, not from left to right), solving each one in turn. (Assuming the object needs solving, but since in your example ALL objects will be expired by a slider change, I shall assume that here).
8) It's hard to tell which object will get triggered first. You'd have to superimpose them in order to see which one is visually the bottom-most object, but let's assume for purposes of completeness that it's the [VB Step 1] object which is solved first.
9) [VB Step 1] is triggered by the document, which causes it to collect all the input data.
10) The input parameter [x] is asked to collect all its data, which in turn will trigger the Slider to solve itself (it got expired in step 4 remember?). This is not a tricky operation, it merely copies the slider value into the slider data structure and shouts "DONE!".
11) [x] then collects the number, stores it into its own data structure and returns priority to the [VB Step 1] object.
12) [VB Step 1] now has sufficient data to get started, so it will trigger the script inside of it. When the script completes, the component is all ready and it will tell the parent document it can move on to the next object (the iteration loop from step 7).
13) Let us assume that the slider object is next on the list, but since it has already been solved (it was solved because [VB Step 1] needed the value) it can be skipped right away, which leaves us with the last object in the document which is still unsolved.
14) [VB Step 2] will be triggered by the document in very much the same way as [VB Step 1] was triggered in step 9. It will also start by collecting all input data.
15) Since all the input data for [VB Step 2] is either defined locally or provided by an object which has already been solved, this process is now swift and simple.
16) Upon collecting all data and running the user script, the component will surrender priority and the document becomes active again.
17) The document triggers a redraw of the Grasshopper Canvas and the Rhino viewports and then surrenders priority again and so on and so forth all the way up the hierarchy until Grasshopper becomes idle again.
[end boring]
Pretty involved for a small 3-component setup, but there you have it.
To answer somewhat more directly your questions:
- The order in which objects are solved is the same as the order in which they are drawn. This is only the case at present, this behaviour may change in the future.
- Adding a delay will not solve anything, since the execution of all components is serial, not parallel. Adding a delay simply means putting everything on hold for N milliseconds.
- [VB Step 1] MUST be solved prior to [VB Step 2] because otherwise there'd be no data to travel from [GO] to [Activate]. The only tricky part here is that sometimes [VB Step 1] will be solved as part of the process of [VB Step 2], while at other times it may be solved purely on its own merits. This should not make a difference to you as it does not affect the order in which your scripts are called.
--
The Man from Scene 24…
Added by David Rutten at 4:43pm on December 10, 2009
mbre de 9:00 am a 8:00 pm Este taller está dirigido principalmente a arquitectos y diseñadores interesados en el aprendizaje del diseño paramétrico y generativo aplicados a la generación y racionalización de geometrías complejas para su implementación en diferentes procesos de diseño. En el curso se abordarán los conceptos básicos y metodología para hacer frente a diversas problemáticas del diseño mediante el desarrollo de herramientas algorítmicas a través de un lenguaje de programación visual y el desarrollo de esquemas de fabricación digital. No se requieren conocimientos previos de Rhinoceros 3D ni de programación, conocimientos previos de CAD deseables. Estudiantes: 2,500 MXN Profesionales: 3,000 MXN
CONCURSO DE RENDERS - BECA DEL 100% - Parametric & Generative Architecture & Design Grasshopper Workshop.
- Publica tu render en www.facebook.com/3dmetrica - El render con más likes será el ganador. - Fecha límite de votaciones 15 de septiembre del 2012.
Informes e Inscripciones: workshop@3dmetrica.com 04455 28790084 www.3dmetrica.com www.facebook.com/3dmetrica
…
ugh information (whether coming from environmental analysis or any kind of database), extracting and managing informations for construction processes all require an understanding of data structures in order to build seamless design-to-construction pipelines. Through visual scripting in Grasshopper (Generative modeling plug-in for Rhinoceros) participants will learn how to build and develop parametric data structures (from basic simple lists to complex data trees), data-driven geometry and envelopes and how to extract relevant informations from such models for construction processes. Participants will also develop a personal envelope project and its full design-to-construction pipeline. [.]TopicsTheory: - Lecture: “Data Obsession” – computational designer as a new professional profile and the role of information and complexity in contemporary architectureTechnique: - Software interface - Components - Lists & Data Tree: management, manipulation, visualization - Geometry generation from data stream - Base exercises (Box morph, Image sampler, Floor sections, Attractor field, Multisection Pipe, Paneling) - Advanced exercise: Data-reactive component – data-reactive tessellation on NURBS surface. Data coming from environmental analysis or spreadsheet table - Advanced exercise: Data extraction from previous tessellation, visualization and storage in spreadsheets. - Advanced exercise: geometry optimization for construction[.]Software & skills:Basic modeling skills in Rhino are required. Participants should bring their own laptop with pre-installed software (software download links will be given after subscription).[.]Tutors:Alessio Erioli + Andrea Graziano – Co-de-iT (GH & design tutors).[.]Venue:The workshop venue will be:Polycollege WienJohannagasse 21050 Wienhttp://www.vhs.at/johannagasse.html[.]Calendar & Timetable:The workshop will have the following timetable throughout all the 4 days: 9:00-13:00 lesson+tutoring 14:00-17:00 lesson+tutoring[.]Subscription fees:For participants who register before 30/08/2012 we offer a EARLY BIRD feesE.B. – educational* : € 320 + VAT E.B. – professional: € 390 + VATafter 30/08/2012 will be in place the STANDARD fees:STANDARD fees – educational* : € 390 + VAT STANDARD fees – professional: € 490 + VAT* students, teachers, researchers & PhD (proof of status required).The deadline for registration is 06/09/2012; The workshop has a maximum of 30 places available and will be activated with a minimum number of 15 partecipants.[.]Application:To register please fill this FORM and send it via e-mail to:3ddreaming@gmail.com or ck@kkkc.at[.] Organized by:This workshop is organized by Co-de-iT in collaboration with:3d-dreaming.com – Architecture from a digital point of viewKKKC – Mediaware trading GmbH…
nfusing.
Problem 01: the requested in-put of 'CroSecs' from 'OptiCroSec' component, based on introduction of itself, "a list of preferable structural thickness", and the algorithm will automatically find the sufficient number as the beam thickness. BUT, when I plugged 3 ranges, 1 to 15 CM, 2 to 15 CM, 5 to 15CM, the algorithm will always choose the finest number as the beam thickness, which turns out the beam thickness is, 1CM, 2CM, 5CM. 5CM in reality 'maybe' correct, but I just cannot image 1 and 2 CM beam will work. That`s very confusing.
Problem 02: the 'MaxDisp' from 'OptiCroSec' component, no matter how I slide the number, shape will remain still always. what is the fucntion of this input, should it be like a control to deformation of the shape?
Thanks in advance for any insight you can give!!
I attached 2 images to show the problem 01, and in the file rhino and gh, i marked out the problem part with red panels.
Best wishes,
Lei
…
e once > be a happy bunny > stay away > ...
2. I've already explained why this 90 (or whatever) > 15 (or whatever) happens ... but ... er ... due to some communication "noise" (he he) I've added a flag that does smart (distinct) and stupid (!distinct) stuff. Visually inspect both ways and enjoy the art of pointless.
3. This wish of yours (duplicates) ... er ... hmm ... are you after fabricating data? (BTW: this is The Noblest of Arts, he he).
Lord of Darkness
…
errors:
When I made my surfaces, I created a separate surface at each intersection. For example, Wall A intersects Wall B and I created Wall C which represents the intersection of the zone. Wall C was assigned as its own surface in the assemblage of zones.
1. The simulation has not run correctly because of this severe error: ** Severe ** GetSurfaceData: Potential "OtherZoneSurface" is not matched correctly:
2. The simulation has not run correctly because of this severe error: ** Severe ** GetSurfaceData: Construction AIR WALL of interzone surface DH_EAST_2/3 does not have the same number of layers as the construction EXTERIOR FLOOR of adjacent surface DH_FLOOR3. The simulation has not run correctly because of this severe error: ** Severe ** GetSurfaceData: Adjacent Surface not found: DH_FLOOR_SRFP_0 adjacent to surface DH_EAST_2/3_DUP_DUP_SRFP_0
…
ad something to do with total internal reflection. Since Radiance is a stochastic ray tracing engine, there will always be some rays that undergo total internal reflection.
I once had an online discussion with Greg Ward about this. I am pasting the relevant excerpt below:
Is there a way to debug or track a rendering processes during runtime ie to know if it will render at all ? Secondly, is there a likelihood of something like total internal reflection happening and light rays not escaping ?
Sarith (Sep 30 '15)
1
The progress reports are the best way to make sure that the renderings are progressing, which they seemed to be doing until they got killed. Even in cases where total internal reflection prevents rays escaping, the tracing will hit some limit (either -lw or -lr and setting both to 0 will give an error) to prevent an infinite loop. Believe me, if there were any infinite loops in Radiance, people would be complaining about it!
GregWard (Sep 30 '15)
So even though the calculations don't go till infinity, they might consume(or demand) more resources than available. Although the glass primitive in Radiance is also a dielectric, it isn't as resource intensive as it is assumed to be very thin and therefore optimized. Trans is another material which seems to be resource hungry.
…