which are a little annoying to me in the scripting environment I would like to share with you:
- when you type in a command or object type and the pop up composer shows, you can hit return to fill out the command quickly. While doing that when you're adding something in the middle of a line (with some text already present to the right), the rest of the line will be deleted. I think this is something that changed around revision 10 or 11.
- when you type in 'New' it fills itself out to 'NewLineHandling' and with List and DataTree it adds brackets <>. I know hitting the Escape prevents this, but I don't know if there's an easy way to solve this.
- when you're using .item(i) and want to use some of the properties of an object, the pop up composer never shows up (BTW 'item' isn't even an option in those menu's), in order to have a small memory support what those commands are.
I don't know if it's too much to change, but it would a huge improvement. Specially if I have a look at all the people that came about these small issues to me already.
Thanks and keep up the good work!
Jeroen…
d de la Paz 2719 3A - Belgrano.
1 PC por alumno, Aire Acondicionado, Cañon Proyector.
Aranceles
Estudiantes 1 pago de $850 o 2 pagos de $480.-
No Estudiantes 1 pago de $1000+IVA o 2 pagos de $600+IVA.-
Para reservar lugar comunicarse al 4547-3458 o a facundo@rhinoceros.com.ar
Vacantes limitadas.…
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
l use Rhino 4.0 and corresponding GH version, as a result i could not open your Rhino file.
Hence in your definition as i see,
1) Spring Force-1 -Connection has 11 'inter' components. The inter components do not have any input data and hence 'orange'. What are the inputs for 'inter'?
2) Spring Force - 2 -'Connection'has 1 point component. Rest length & Cut off has 'mass addition' data. This force is also orange, could u throw a light on this please?
3) Pull to surface - both forces has no point input, hence it is orange too. could u throw a light on this too please?
4) There are 2 x Cartesian product components not connected to anything.
I realise that partially it could be because i'm using lower version of Rhino. However, ur input will be highly appreciated.
Kind Regards,
Agneesh…
e now contains (40x3x11=)1320 points with a branch structure of {0-39,0-2} i.e
{0;0}
{0;1}
{0;2}
{1;0}
...
{39;2}
with each branch containing 11 points.
I now want to create lines from the points on line {x;0} to {x;1}, {x;1} to {x;2}, and {x;2} to {x;0}, which will give me a triangular grid on each triangle. How do i do this? I think I need to split the tree 40 times to give me 40 single layered trees but I imagine there's a cleverer way of doing this!
This feel like it should be simple, but I;m having trouble working with the double-layered branch structure. Any help would be greatly appreciated!
Thanks,
Matt…
keep the same number of branches.
The way I'm doing it now has the inconvenience of only working for this particular number of branches, and I would like a more general way. Do I need a script or can I solve it with components, path mapper, etc?
-Also, and this one is probably simple but I can't seem to figure it out: I have a tree structure as in fig B, and I want to pick out certain series of branches from it, for example {1;0} to {2;11}. (PathGen seems to only go from {0;0} to a specified item?) So I want to be able to plug in a choice of numbers, and dispatch those branches into separate trees/cull them somehow. What am I missing? In general, I've failed to find a way to pick out all of the "uppermost" level of branches, eg {3;x}.
Any help greatly appreciated!…
the loops haven't even started yet. This is a one time overhead - re-starting the loops after that doesn't have this long delay until you close and re-open the file.
Second, I got some encouraging results rather quickly but then spent WAY TOO MUCH TIME trying to replace the inner loop with a "Fast Loop". These are not well behaved in the sense that they don't respond to <ESC> like the "Classic" loops do so you can't stop them; and I never got the same results as the "Classic", no matter what I tried - but ultimately, I just got too frustrated with "Fast Loop" causing Rhino/GH and my whole laptop to freeze up - VERY BAD!!!!!!!!!!
I re-wired the loops slightly so that the hour used by your 'analysisPeriod' cluster is determined by the 'D0' value inside the inner loop.
I added a "Loop On / Loop Off" switch to stop/start the looping (which was useless with "Fast Loop" - grrr....).
I 'Simplified' the 'D1' output of the inner loop and enabled 'Record data' and 'Output after the last' on the outer loop.
And I got this - four buildings over three hours takes about 20 seconds:
Eleven buildings over three hours takes about one minute.
I'm not sure what will happen when I increase the hours and number of buildings but will try it when I have more time. It might be a good idea to avoid writing to Excel inside the loops and wait for the end results before writing them to an Excel file?
There are more possibilities for re-wiring based on simplifying various outputs but I'm tired of this for now and have other things to do. The exponential slowdown you observed might be due in part to Anemone adding an extra branch path every time it loops; adding 'Simplify' might help this?
P.S. 11 buildings over 13 hours (6am to 6pm) took 5 minutes 38 seconds.…
Added by Joseph Oster at 12:54pm on January 18, 2016
ies+ Kinect Basics+ Video Effects+ DirectX 11 Rendering+ Projection Mapping on Moving Objects+ Controlling flying copters+ Brainwave analysis+ Folding & cutting paper+ Multi-touch gesture recognition+ Multiscreen Setups+ Physics based interactions+ Transformations+ vvvv and the Arduino+ Motor Control+ Industrial robots for creative applications+ Visualizing dance with Motion Bank+ IRIS – Interactive Realtime Image Synthesizer+ vvvv.js+ more online– Symposium & Exhibition –‘The Rules – Examining code as shapeable cosmoplastic material’+ Memo Akten+ Rainer Kohlberger+ Geoffrey Lillemon+ Kyle McDonald+ Julian Oliver+ Rafael Rozendaal+ Elliot Woods+ Patrizia Kommerell & Gabriel Shalom+ Philipp Kleinmichel+ Joanne McNeil+ Andrew Goffey+ Alex McLean+ more artworks from our Open Call still to be announced– Happenings –Let's meet and feel the vibes of 'Creative Coders'+ CreativeApplications.net Panel-Discussion+ Consultation hour with Memo Akten+ A/V Performance Daniel Schwarz & Edisonnoside+ LiveCoding Performance by Alex McLean+ vvvv keynote+ Visitors presentation 'Patcher Kucha'+ Consultation hour Hackerspace Frankfurt+ and final party with a Guy Called Gerald+ Geoffrey Lillemon Artist Talk & Screening+ more online–Venue –Frankfurter Kunstverein…
stributes structural supports for a uniformly loaded domain using e.g. the internal energy of the loaded domain as fitness. Here the uniformly loaded domain is represented by the trimmed surface. My genomes are the support positions (green crosses), which are restricted to a set of predefined grid points. I’m currently using an (i,j)-coordinate indexing for these grid points (illustrated in the viewport just below) as opposed to a sequential , “one-dimensional” numbering (illustrated in the viewport further down).
(i,j)-indexing systemAltenative, sequential indexing system
The support positions are computed by two gene pools; one governing the i-index, Gene List {i}, and one governing the j-index, Gene List {j}, of each support. The value of slider 0 in Gene List {i} is paired with the value of slider 0 in Gene List {j} etc. and the amount of sliders corresponds to the amount of supports. The screen shot below depicts the slider constellation corresponding to the support distribution depicted above. Unfortunately the j-index represented in the sliders needs remapping as the number of j-indices vary for each i-index (horizontal row of grid points). With the current setup I have 12^6 x 9^6 = 1,6 x 10^12 different genomes. If I were to use the sequential, “one-dimensional” numbering, I would only use one gene pool with sliders ranging from 0 to 76 meaning that remapping could be avoided and thereby having only 76^6 = 1,9 x 10^11 different genomes.
So, my current genome setup causes a bunch of issues related to the Evolutionary Solver: Remapping Changing one of the j-index sliders, will not necessarily change the related support position but it will still facilitate another genome to be calculated by the solver. (This problem could be eliminated by using the sequential, “one-dimensional” numbering)
Switching slider values around If the values of e.g. slider 0 were to be switched around with the values of slider 5, this again would yield a new genome but an identical solution. (This problem cannot be eliminated by using the sequential, “one-dimensional” numbering)
Coincident support positions Two or more supports may be located in the same position. (This problem cannot be eliminated by using the sequential, “one-dimensional” numbering)
I find it impossible to imagine the fictive “fitness landscape” of this problem and not only because of the multidimensional genome characteristic but just as much because of these listed, intertwined peculiarities. I’ve tried running the Simulated Annealing Solver as well, but my experience is that the Evolutionary Solver yields better results. To my awareness, the solver uses some kind of topographical proximity searcher. This is why, I think that the solving process itself benefits more from analysing the (i,j)-index system, in which neighbouring grid points hold more uniform topographical information than the sequential, “one-dimensional” numbering, which might have big ID-numbering gaps between neighbours. Have I understood this correctly?
Cheers…
comerciales. Rhino permite comunicar ideas en el desarrollo, investigación, manufactura, marketing y proceso de construcción de un producto o espacio, antes de ser construido y genera documentos constructivos para la elaboración de los mismos. Permite exportar los archivos a las extensiones comerciales más utilizadas en la industria como DXF, DWG, Illustrator y 3ds entre muchos otros. La gran cantidad de extensiones suplen las necesidades especificas para arquitectura, diseño de producto, calzado, joyería, ingeniería, manufactura y visualización fotorealista.
Grasshopper es una extensión de Rhino que permite el modelado paramétrico sin tener conocimientos de programación o matemáticas avanzadas, facilitando el desarrollo de modelos de alta complejidad a partir de formas simples o complejas.
En este taller se cubren los principios de parametrización, analisis, panelización, Corte CNC.
Sesiones: 15 de 3 hrs
Duración: 45 horas
Días: lunes, miércoles y viernes
Horario: de 19:00 hrs a 22:00 hrs
Costo:
Pago único: $4,000 (antes del inicio del taller)
Pago fraccionado: $4,500
Primer pago: $2,000 para reservar tu lugar.
Segundo pago: $1,250 - 26 de septiembre
Tercer pago: $1,250 - 3 de octubre
…