.
Today we have gone live, and the plugin is available on Food4Rhino. You will find an installer package, sample files, and a demo video on getting started:
http://www.food4rhino.com/project/human-ui
Visit the Bitbucket Repo and poke around in the code:
https://bitbucket.org/andheum/humanui
Check out today's coverage in Architect Magazine:
http://www.architectmagazine.com/technology/nbbj-releases-human-ui-to-bring-parametric-modeling-to-the-masses_o
Finally join our group and ask any questions or post any comments here:
http://www.grasshopper3d.com/group/human-ui
See below for detailed description!
----------------------------------
Human UI
Primary Development by:
Lead Developer: Andrew Heumann / andheum / @andrewheumann
Product Manager: Marc Syp / marcsyp / @mpsyp
Contributing Developer: Nate Holland / nateholland / @_NateHolland
Gone are the days of faking a user interface by laying out sliders and text panels and hiding wires on the Grasshopper canvas. Human UI interfaces are entirely separate from the Grasshopper canvas and leverage the power of Windows Presentation Foundation (WPF), a graphical subsystem for rendering user interfaces in the Windows environment.
OLD NEW
In other words: Human UI makes your GH definition feel like a Windows app. Create tabbed views, dynamic sliders, pulldown menus, checkboxes, and even 3D viewports and web browsers that look great and make sense to anyone--including designers and clients with no understanding of Grasshopper.
Human UI has been in development at NBBJ for over a year, as part of a larger NBBJ Design Computation initiative to deliver our tools internally as Products -- with fully automated installation, managed dependencies, analytics, documentation, and “magical” user experience. Human UI has been a huge component of the user experience part of this puzzle, and we are excited to share it with the larger Grasshopper community so that others can benefit from it and contribute to its development.
The initial release of Human UI is accompanied by a few simple examples to get you started, but we have developed sophisticated user interfaces with these tools at NBBJ and will slowly be rolling out more advanced examples. We also look forward to opening up the development to the community and seeing what new features and paradigms we can add.
Download the plugin at Food4Rhino and get started building Custom UIs for Grasshopper right away! We are happy to answer any questions or field discussion in the dedicated Grasshopper Group. Please join us!
Join the Grasshopper Group
http://www.grasshopper3d.com/group/human-ui
Download the plugin + sample files
http://www.food4rhino.com/project/human-ui
Visit the Bitbucket Repo
https://bitbucket.org/andheum/humanui
We look forward to seeing where this project takes you, please share your projects made with Human UI!
Sincerely,
Design Computation Leadership Team, NBBJ
…
nter the programming world and tinker more complex, interactive solutions. We will also explore advanced programming paradigms. There is no class official programming language, as both C# and Vb.Net are possible on the participant’s side, and all examples will be provided in both C# and Vb.Net. Additionally, we will see how to get started writing full .Net plug-ins. Finally, we will have time to explore user’s own proposals on the third day.
Day 1 Morning: programming introduction in .Net
• The Grasshopper scripting components. Choosing a .Net language. Language developments
• Variables declaration, assignment and utilization. Operators. Methods [functions]. Calls
• Classes: declaration and instancing. Constructors. Importing a namespace. On3dPoints, OnLines
• Arrays declaration and usage. Lists. Adding to arrays and lists, advantages and opportunities.
Afternoon: patterns
• About OOP (object oriented programming) as opposed to procedural programming. Discussion
• Example of OOP good code reuse: sorting points by coordinates using the .Net SDK classes
• Lists as input parameters. Trees as input parameters. Usage and limitations
• Finding resources: on the net with website that can help getting started and troubleshoot. And books
Day 2 Morning: extending Grasshopper functionality with our definitions
• Store data between updates. The use of fields [globals, or static locals]
• Examples on how to use stored data between updates: a simple agents simulation
• Baking geometry with scripting directly into the Rhino document. Baking with names
• Passing custom types from a scripted component to another one. Our own code reusability
• Rendering an animation from Grasshopper. How to get started and final results
Afternoon: customizing our tools
• Our Rhino plug-in with Visual Studio C# [Vb.Net] Express Edition & wizard. Parametric mesher
• Writing a custom Grasshopper component: hacking an exporter for our data to Excel
Day 3 All day: personal project
• Rehearsal on any example from the first two days. A project that you want to start on your own, being it a Rhinoceros plug-in, a Grasshopper assembly or a script. Example might be to send data through network with UDP to Processing
MINIMUM REQUIREMENTS
A good foundation of Grasshopper visual programming is mandatory. You will need a level which corresponds to the Grasshopper 101 course outline. Examples of things that will not be covered in this course are: sorting document spheres by diameter, paneling of a surface with grasshopper components. You are expected to already know these from the Grasshopper course.…
Introduzione a Grasshopper", il primo manuale su Grasshopper.
.
I corsi PLUG IT nascono dalla volontà di promuovere le nuove tecnologie digitali di supporto alla progettazione e condividere il know-how maturato attraverso ricerca, collaborazione con i più importanti studi di architettura e pubblicazioni internazionali.
.
Verranno introdotte le nozioni base di Grasshopper approfondendo le metodologie della progettazione parametrica e le tecniche di modellazione algoritmica per la generazione di forme complesse. Il corso è rivolto a studenti e professionisti con esperienza minima nella modellazione 3D e si articolerà in lezioni teoriche ed esercitazioni.
. Argomenti trattati:
- Introduzione alla progettazione parametrica: teoria, esempi, casi studio - Grasshopper: concetti base, logica algoritmica, interfaccia grafica - Nozioni fondamentali: componenti, connessioni, data flow
- Funzioni matematiche e logiche, serie, gestione dei dati - Analisi e definizione di curve e superfici
- Definizione di griglie e pattern complessi - Trasformazioni geometriche, paneling - Attrattori, image sampler
- Data tree: gestione di dati complessi - Digital fabrication: teoria ed esempi - Nesting: scomposizione di oggetti tridimensionali in sezioni piane per macchine CNC
.
Verrà rilasciato un attestato finale.
.
Ulteriori info e programma completo su: www.arturotedeschi.com e su www.samilolab.it…
greatly appreciate it!!
You can write the number of the question and write your answer next to it, example:
1) a
2) c
3) a) Washington University in St. Louis
4) 2 weeks (1week+1week shipping)
5) 130
6) b
7) b
The survey questions are as follows:
1)
Did you 3D print before?
5)
How much did it cost (in dollars)?
a.
Yes, for a school project
a.
Between 20 & 50
b.
Yes, for a personal project
b.
Between 50 & 80
c.
Between 80 & 120
2)
Print size
d.
Please specify if otherwise: _____ dollars
a.
Between 2 & 6 cubic inches
b.
Between 6 & 12 cubic inches
6)
Do you think the price was expensive?
c.
Between 12 & 20 cubic inches
a.
Not at all
d.
Please specify if otherwise: ____cubic inches
b.
A little bit expensive
c.
Very expensive
3)
Where did you print your object?
a.
School
7)
Were you satisfied with the printed object?
b.
Outside school: _________________
a.
Yes, it was a great print without problems
b.
Not bad, some issues
4)
How long did it take to print?
c.
I was not satisfied, very bad quality
a.
___ days
b.
___ weeks
Thank you very much to all!!
PS: If you did many 3D prints, you can post multiple answers.
Wassef…
whole design intent, but this is what Inventor is good at. The way it packages bits of 'scripted' components into 'little models' that can be stored and re-assembled is central to MCAD working.
The Inventor model shown is almost 5 years old. We don't model like that any more, however it does offer a good idea of general MCAD modeling approaches.
iParts is useful in certain situations, it could've been useful in the above model, its usefulness is often in function of the quantity of variants/configurations.
So much is scripted in GH, maybe it should also be possible to script/define/constrain/assist the placement/gluing of the results?
...
Starting point: I think we are talking across purposes. AFAIK, the solving sequence of GH's scripted components is fixed. It won't do circular dependencies... without a fight. The inter-component dependencies not 'managed' like constraints solvers do for MCAD apps.
Components and assemblies are individual files in MCAD.
Placement of these within assemblies in MCAD is a product of matrix transforms and persistent constraints. There is no bi-directional link, the link is unidirectional (downflow only), because of the use of proxies.
Consequently, scripting the placement of components is irrelevant in GH, unless you decide that each component needs to be contained in its own separate file.
This also brings up the point that generating components and assemblies in MCAD is not as straightforward. In iParts and iAssemblies, each configuration needs to be generated as a "child" (the individual file needs to be created for each child) before those children can be used elsewhere.
You notice the dilemma, if you generate 100 parts, and then you realize you only need 20, you've created 80 extra parts which you have no need for, thus generating wasteful data that may cause file management issues later on.
GH remains in a transient world, and when you decide to bake geometry (if you need to at all), you can do that in one Rhino file, and save it as the state of the design at that given moment. Very convenient for design, though unacceptable for most non-digital manufacturing methods, which greatly limits Rhino's use for manufacturing unless you combine it with an MCAD app.
One of the reasons why the distributed file approach makes perfect sense in MCAD, is that in industry you deal with a finite set of objects. Generative tools are usually not a requirement. Most mechanical engineers, product engineers and machinists would never have any use for that.
The other thing that MCAD apps like Inventor have, is the 'structured' interface that offers up all that setting out information like the coordinate systems, work planes, parameters etc in a concise fashion in the 'history tree'. This will translate into user speed. GH's canvas is a bit more freeform. I suppose the info is all there and linked, so a bit of re-jigging is easy. Also, see how T-Flex can even embed sliders and other parameter input boxes into the model itself. Pretty handy/fast to understand, which also means more speed.
True. As long as you keep the browser pane/specification tree organized and easy to query.
:)
Would love to understand what you did by sketching.
I'll start by showing what was done years ago in the Inventor model, and then share with you what I did in GH, but in another post.
Let's use one of the beams as an example:
We can isolate this component for clarity.
Notice that I've highlighted the sectional sketch with dimensions, and the point of reference, which is in relation to the CL of the column which the beam bears on. The orientation and location of the beam is already set by underlying geometry.
Here's a perspective view of the same:
The extent of the beam was also driven by reference geometry, 2 planes offset from the beam's XY plane, driven by parameters from another underlying file which serves as a parameter container:
Reference axes and points are present for all other components, here are some of them:
It starts getting cluttered if you see the reference planes as well:
Is I mentioned earlier, over time we've found better ways to define and associate geometry, parameters, manage design change, improving the efficiency of parametric models. But this model is a fair representation of a basic modeling approach, and since an Inventor-GH comparison is like comparing apples and oranges anyways, this model can be used to understand the differences and similarities, for those interested.
I haven't even gotten to your latest post yet, I will eventually.…
Added by Santiago Diaz at 10:36am on February 26, 2011
he picture (4).
Previously, I had a problem with generating intersections between the two directions of the beams, but a colleague helped me by extending beams, so there was no problem with lines of intersection. But this solution has generated curl (5) at the highest vertex geometry, which I ignored in order to repair it before printing, perhaps this mean my problem with my beam spread properly. Only when the beams is 19, does not jump no problem, but I still can not distribute them properly.
(1)
(2)
(3)
(4)
(5)
I tried to show as simply as possible by removing or signing my code in GHX file.
Thank you in advance for your help
…
perienced with grasshopper, but so far I've managed to combine the following:
Giulio Piacentino's "Catenary arch from height" script
Pirouz Nourian's "Mobius" script (Obtained from a friend)
End Result:
Here's where I'm stuck: I want the mobius twist to revolve around the midpoint of the arch, but the script uses the input values to determine the endpoints, resulting in a weird sinuous shape when viewed from above. Also, the secondary end points (generated by the mobius script, determining the width of the surface) are generated by default along the z axis, resulting in an arch that only touches the "ground" at two points. I attempted to work around this issue by trying to force the zHeight parameter to correspond with the y axis (thus rotating the arch 90 degrees so it would lay "flat"), but the script interprets the third point as a value and not as an actual point to bisect. I thought this might be an issue with the C# component that I obtained from Giulio Piacentino's script, so I attempted to tinker around with the source code. Unfortunately, I'm not fluent in C# so I only managed to mess everything up (I've since recovered the code from the cache). Anybody got some ideas? -BC …
s levels of detail by subdividing a 6 sided cube mesh and projecting its vertices according to a referenced height map. This is one of the standard conventions for building full sizes planets. At the lowest level (0) the mesh planet is made of 6 pieces(each 32x32 resolution). The next level down (1) is made of 24 pieces... 6 divided by 4 = 24. Level (2) is 96 quads etc etc. The script will generate each quad at its sub-division level and compare edge vertices to neighboring quads. It will then make sure any shared vertices are in fact at the same projected vector. This ensures a planet quad with edge vertices that match.
The problems comes in texturing each quad.
If I build the quad as a nurb surface from points I can place the texture easily because each surface UV maps squarely to my texture map (which is also square).
If I build the quad as a mesh I cannot just apply the square texture to the mesh UVs. This is because when you unwrap the UVs from a mesh they will not unwrap like a nurb surface's UVs. Therefore to get the correct mapping I would have to manipulate each UV back to an evenly aligned array (which is 1024 points in a 32x32 resolution UV). Maya and blender have 'relax uv' and 'align UV' functions but they don't do the trick and manual corrections are out of the question. So why not skip the mesh method and use the nurb method?
I did this and there is a trade off. The nurb will accept the material texture I want with no other work on my end but when I export the object as an .obj rhino creates its own mesh to describe the nurb(with various unsatisfactory setting options). This works great up to a point because at some level the interpreted mesh will have vertices that do no match at the edges, ie .. creating visible seams in the mesh. The picture below is the nearly seamless planet at LOD(1) made of 24 quads, each with 32x32 vertice resolution and a 512x512 jpg texture running in Unity3d 5. It works but at close level there are seams. This will be resolved simply by having the next LOD(x) instantiate before getting close enough to see the seam but at core nerd level I want the seamless mesh.
So, I can make the seamless mesh but I can not realistically texture map it. I can also make the nurb surface from points and texture it at the expense of the edge vertices matching. I am at the split in the road but I want to have my cake and eat it too. Thoughts, comments, trolls...?
Thanks for reading =)
Footnote: For you pros I am not using seamless noise across the map I am using grasshopper to sew up my otherwise non perfect edges.
Other programs in the pipeline:
-WorldMachine 2
-Wilbur
-Photoshop
-Unity3d…
rves/holes. However, the Kangaroo script itself is prone to locking up so it seems like it might take forever. You can even double click stop the timer from the Windows task bar, I hadn't noticed that before:
You have to use that or right click disable the timer since even with the Reset toggle button input set to True the timer itself locks up the script a bit when you are changing things around.
Just setting the min/max numbers both to a desired mesh size gives a uniform mesh:
Oh weird, it's about if the timer is right click set to so small an interval that it gets ahead of Kangaroo! When you see how long each cycle is taking with the Display > Canvas Widgets > Profiler you just set the timer for above that and the interface comes back into being responsive. It only takes a few Kangaroo cycles to do the inflation, so a full second timer interval is even workable.
A finer mesh:
It's funny running it so slow since it overinflates at first, bulging out, before it equilibrates.
You have control over inflation pressure and mesh stiffness, for a variety of effects.
This is a good system once I realized the timer needed to be mellowed out.
What made it work was the fast custom meshing since a normal mesh is awful and MeshMachine wouldn't work with sharp corner holes at all, breaking out of the boundary even if I fixed curves or vertices or did the equivalent with NURBS surfaces instead of a starting mesh.
There is an initiation time for Kangaroo that doesn't show up on its Profiler time that happens even with the timer off.
There are some fine areas that can't inflate with a reasonable mesh setting:
Worth playing with but no match for ArtCAM since it suffers odd delays in between working fast. If I could get better 2D meshes, that were more adaptive it would be better, but MeshMachine is one of the only re-meshers I know and it's broken for even mildly sharp hole features.
Ah, how about a crude mesh that is then subdivided, guaranteeing inner vertices everywhere? Sort of works, but is still too dense. Way too dense to even do anything. The subdivision triangulates the quads, vastly increasing the mesh wire density. Better just to make a finer initial mesh with plenty of quads.…
Added by Nik Willmore at 12:57am on February 21, 2016
thing that MicroStation does (or doesn't). The eternal debate between us is that they focus to the so called BIM aspect of things (and obviously on interoperability matters - that said IFC2*4 is" implemented" in certain Bentley verticals like BA and others) whilst I'm after assembly/component puzzles (and on that matter ... MS ...hmm... to put it politely is not exactly CATIA and/or NX, he he).
On the other hand this paranoid obsession with Level/Layer driven CAD (I hate it) defines a red thick line between CAD and MCAD - because the most intelligent importer can't emulate the way that Siemens NX/CATIA classifies objects - and without control power means nothing.
On the other hand Microstation V9 (...soon) has interesting scripting capabilities (think Modo rather Generative Components) ... meaning that Grasshopper could work there in a rather nice way. I think that I must talk for that to Ray (he recently ditched the ancient legacy MS render engine in favor for the Luxology/Nexus engine). Ray still is negative to buy Act3D mind (hope that you know the mother of visual scripting - the Quest3D VR thing).
On the other hand - within the broad AEC aspect - things these days are different (especially in fast developing countries the likes of UAE, Saudi Arabia, certain ex USSR "democracies" etc etc). Studies are outsourced even at Preliminary Design stage to various sub-contractors (they undertake the Study completion per discipline as well). This means that N separate groups doing M aspects of the whole ... meaning entropy^(N*M) - that's chaos in plain English.
With this in mind I'm quite (a lot) skeptical about the practical meaning of the whole exchange thing in AEC - at least with regard the countries mentioned (not to mention that several portions of a modern AEC thing are made via MCAD apps - chaos^chaos.
I'll back with more focused issues on that matter.
But the big question is: Grasshopper of Generative Components? Well...let's talk serious SS bikes instead: think a Ducati 1198 and a BMW S1000RR (I have them both): which is "best"? The thing is that not always the best bunny is the fasted bunny and not always the fasted bunny is the best bunny.
Cheers,
Peter
…