o está dirigido a estudiantes de arquitectura y diseño de interiores, recién titulados y profesionales interesados en el software o que necesiten conocer las herramientas básicas de las que dispone el programa en los diferentes ámbitos y cómo enfocarlas a arquitectura.
Descripción:El contenido del curso enseñará a utilizar el programa de diseño Rhinoceros 3D aplicando su metodología de trabajo en el campo de la arquitectura, básandose además de la creación de pequeños elementos paramétricos para controlar el diseño y acabar renderizando las geometrías 3d con V-Ray para Rhino.
El curso consta de 3 módulos de 12h de duración cada uno (que pueden realizarse juntos o por separado) en los cuales se profundizará en herramientas de Rhino, Grasshopper y V-Ray a medida que se realizan casos prácticos sobre proyectos arquitectónicos.Se pretende establecer un sistema de trabajo eficiente desde el inicio del modelado hasta la posterior creación de imágenes para documentación del proyecto.
Módulo Rhinoceros Arquitectura:• Conceptos básicos e interfaz de usuario Rhino• Introducción al sistema cartesiano en Rhino• Clases de complejidad de geometría• Importación/exportación de archivos compatibles• Topología NURBS• Trabajo con Sólidos• Estrategias básicas de Superficies• Introducción a Superficies Avanzadas
Módulo Grasshopper:• Conceptos básicos e interfaz de usuario Grasshopper• Introducción a parámetros base y componentes• Matemáticas y trigonometría como herramientas de diseño• Matemáticas aplicadas a creación de Geometría• Introducción a listas simples• Análisis de Superficies y Curvas• Dominios de Superficies y Curvas• Panelado de superficies• Manejo de listas y componentes relacionados• Modificación de panelados en función de atractores• Exportación/Importación de información a Grasshopper
Módulo V-Ray para Rhinoceros:• Conceptos básicos e interfaz de usuario V-Ray• Vistas guardadas• Materiales V-Ray• Materiales, creación y edición• Iluminación (Global Illumination, Sunlight, Lights)• Cámara Física vs Cámara default• Canales de Render• Postprocesado básico de canales
Detalles:Instructores: Alba Armengol Gasull y Oriol Carrasco (SMD Arquitectes)Idioma: CastellanoHorario: 22 JULIO al 26 JULIO 2013 // 10.00 – 14.00 / 16.00 – 20.00Organizadores: SMDLugar: SMD lab, c/Lepant 242 Local 11, 08013 Barcelona (map)
Software:Rhinoceros 5Grasshopper 0.9.00.56V-Ray 1.5 for RhinoAdobe Photoshop CS5Links de versiones de evaluación de los Softwares serán facilitadas a todos los asistentes. Se usará unica y exclusivamente la versión de Rhino para PC. Se ruega a los participantes traer su propio ordenador portátil.
Registro:Modalidad de precio reducido por tres módulos 275€Posibilidad de realizar módulos por separado 99€…
east make all our algorithms thread-safe, so they can all be called from multiple threads, this is the first step towards multi-threading.
But multi-threading is not just something you switch on or off, it's an approach. Let's take the meshing of Breps for example. Let's assume that at some point one or more breps are added to the document. The wireframes of these breps can be drawn immediately, but the shading meshes need to be calculated first. How do we go about doing this? Allow me to enumerate some obvious solutions:
We put everything on hold and compute all meshes, one at a time. Then, when we're done we'll yield control back to the Rhino window so that key presses and mouse events can once again be processed. This is the simplest of all solutions and also the worst from the users point of view.
We allow the views to be redrawn, mouse events and key presses to be handled, but we perform the meshing in a background thread. I.e. whatever processor cycles are left over from regular use are now put to work on computing meshes. Once we're done computing these meshes we can start drawing the shaded breps. This is a lot better as it doesn't block the UI, but it also means that for a while (potentially a very long time) our breps will not be shaded in the viewport. This approach is already a lot harder from a programming perspective because you now have multiple threads all with access to the same Breps in memory and you need to make sure that they don't start to perform conflicting operations. Rhino already does this (and has been doing for a long time) on a lot of commands, otherwise you wouldn't be able to abort meshing/intersections/booleans etc. with an Escape press.
So we can compute the meshes on the UI-thread or on a background thread. How about using our multiple cores to speed up the process? Again, there are several ways in which this can be achieved:
Say we have a quad-core machine, i.e. four processors at our disposal. We could choose to assign the meshing of the first brep to the first processor, the second brep to the second processor, the third brep to the third processor and so on. Once a processor is done with the meshing of a specific brep, we'll give it the next brep to mesh until we're done meshing all the breps. This is a good solution when multiple breps need to be meshed at once, but it doesn't help at all if we only need to compute the mesh for a single brep, which is of course a very common case in Rhino.
To go a level deeper, we need to start adding multi-threading to the mesher itself. Let's say that the mesher is set up in such a way that it will assign each face of the brep to a new core, then -once all faces have been meshed- it will stitch together the partial meshes into a single large mesh. Now we've sped up the meshing of breps with multiple faces, but not individual surfaces.
We can of course go deeper still. Perhaps there is some operation that is repeated over and over during the meshing of a single face. We could also choose to multi-thread this operation, thus speeding up the meshing of all surfaces and breps.
All of the above approaches are possible, some are very difficult, some are actually not possible if we're not allowed to break the SDK. A further problem is that there's overhead involved with multi-threading. Very few operations will actually become 4 times faster if you distribute the work across 4 cores. Often one core will simply take longer than the other 3, often the partial results need to be aggregated which takes additional cycles and/or memory. What this means is that if you were to apply all of the above methods (multi-thread the meshing of individual faces, multi-thread the meshing of breps with multiple faces and multi-thread the meshing of multiple breps) you're probably worse off than you were before.
--
David Rutten
david@mcneel.com
Poprad, Slovakia
* an example would be the z-sorting of objects in viewport prior to repainting, which is a step performed on every redraw as far as I know.…
e current data should be turned to be original data, is that right?there are 3 cases.
what do this components effect the performance after if i turn the component to be flatten and graft and to connect to other component?
{, is that0}
{0;0}
{0;0;0}
{0;0;0;0}
{0;0;0;0;0}
{0;0;0;0;0;0}…
t. So here we go!
1. Honeybee is brown and not yellow [stupid!]...
As you probably remember Honeybee logo was initially yellow because of my ignorance about Honeybees. With the help of our Honeybee expert, Michalina, now the color is corrected. I promised her to update everyone about this. Below are photos of her working on the honeybee logo and the results of her study.
If you think I'm exaggerating by calling her a honeybee expert you better watch this video:
Thank you Michalina for the great work! :). I corrected the colors. No yellow anymore. The only yellow arrows represent sun rays and not the honeybee!
2. Yellow or brown, W[here]TH Honeybee is?
I know. It has been a long time after I posted the initial video and it is not fun at all to wait for a long time. Here is the good news. If you are following the Facebook page you probably now that the Daylighting components are almost ready.
Couple of friends from Grasshopper community and RADIANCE community has been helping me with testing/debugging the components. I still think/hope to release the daylighting components at some point in January before Ladybug gets one year old.
There have been multiple changes. I finally feel that the current version of Honeybee is simple enough for non-expert users to start running initial studies and flexible enough for advanced users to run advanced studies. I will post a video soon and walk you through different components.
I think I still need more time to modify the energy simulation components so they are not going to be part of the next release. Unfortunately, there are so many ways to set up and run a wrong energy simulation and I really don’t want to add one new GIGO app to the world of simulation. We already have enough of that. Moreover I’m still not quite happy with the workflow. Please bear with me for few more months and then we can all celebrate!
I recently tested the idea of connecting Grasshopper to OpenStudio by using OpenStudio API successfully. If nothing else, I really want to release the EnergyPlus components so I can concentrate on Grasshopper > OpenStudio development which I personally think is the best approach.
3. What about wind analysis?
I have been asked multiple times that if Ladybug will have a component for wind study. The short answer is YES! I have been working with EFRI-PULSE project during the last year to develop a free and open source web-based CFD simulation platform for outdoor analysis.
We had a very good progress so far and our rockstar Stefan recently presented the results of the work at the American Physical Society’s 66th annual DFD meeting and the results looks pretty convincing in comparison to measured data. Here is an image from the presentation. All the credits go to Stefan Gracik and EFRI-PULSE project.
The project will go live at some point next year and after that I will release the Butterfly which will let you prepare the model for the CFD simulation and send it to EFRI-PULSE project. I haven’t tried to run the simulations locally yet but I’m considering that as a further development. Here is how the component and the logo looks like right now.
4. Teaching resources
It has been almost 11 months from the first public release of Ladybug. I know that I didn't do a good job in providing enough tutorials/teaching materials and I know that I won’t be able to put something comprehensive together soon.
Fortunately, ladybug has been flying in multiple schools during the last year. Several design, engineering and consultant firms are using it and it has been thought in several workshops. As I checked with multiple of you, almost everyone told me that they will be happy to share their teaching materials; hence I started the teaching resources page. Please share your materials on the page. They can be in any format and any language. Thanks in advance!
I hope you enjoyed/are enjoying/will enjoy the longest night of the year. Happy Yalda!
Cheers,
-Mostapha
…
mesh by an infinite plane
Namespace: Rhino.GeometryAssembly: RhinoCommon (in RhinoCommon.dll) Version: 5.0.15006.0 (5.0.20693.0)
Syntax
C#
public Mesh[] Split( Plane plane )
Visual Basic
Public Function Split ( _ plane As Plane _ ) As Mesh()
Parameters
plane
Type: Rhino.Geometry..::..Plane[Missing <param name="plane"/> documentation for "M:Rhino.Geometry.Mesh.Split(Rhino.Geometry.Plane)"]
Return Value
[Missing <returns> documentation for "M:Rhino.Geometry.Mesh.Split(Rhino.Geometry.Plane)"]
See Also
Mesh Class
Rhino.Geometry Namespace
Last updated 3 June 2011 - Robert McNeel and Associates
Send comments on this topic to steve@mcneel.com
Report wishes and bugs: https://github.com/mcneel/rhinocommon/issues
Is this the function?
I have a VB component with this:
a = rhino.Geometry.Mesh.CreateBooleanSplit(x, y)
but this is a boolean split, so I have only one mesh, with the intersection. I would like to have several splitted meshes.
Thank you in advance again.
…
ndard length elements without any cutting, and using only simple connections, such as cable ties or scaffold swivel couplers.
To summarize the approach I present here:
Design an initial shape
Remesh this form so that the edges are all roughly the length of the tubes we will use to build the structure
Rotate and extend the edges of this mesh to create the crossings
Apply a relaxation to optimize the positions of the tubes for tangency
demo_reciprocal_structures.gh
Initial form
In this example I show how to apply this system to a simple sphere. You can replace this with any arbitrary shape. It can be open or closed, and have any topology.
Remeshing
The new ReMesher component takes an input mesh, and a target edge length, and iteratively flips/splits/collapses edges in order to achieve a triangulated mesh of roughly equal edge lengths.
Press the Reset button to initialize, then hold down the F5 key on your keyboard to run several iterations until it has stabilized. (F5 just recomputes the solution, and this can be a quick alternative to using a timer)
Once the remeshing is complete, bake the result into Rhino and reference it into the next part of the definition (I recommend doing this rather than connecting it directly, so that you don't accidentally alter the mesh and recompute everything downstream later).
Alternatively you can create your mesh manually, or using other techniques.
Rotate and Extend
We generate the crossings using an approach similar to that described by Tomohiro Tachi for tensegrity structures here:
http://www.tsg.ne.jp/TT/cg/FreeformTensegrityTachiAAG2012.pdf
Using the 'Reciprocal' component found in the Kangaroo mesh tab, each edge is rotated about an axis through its midpoint and normal to the surface, then extended slightly so that they cross over.
By changing the angle you can change whether the fans are triangular or hexagonal, and clockwise or counter-clockwise.
Choose values for the angle and scaling so that the lines extend beyond where they cross, but not so far that they clash with the other edges.
Note that each rod has 4 crossings with its surrounding rods.
There are multiple possibilities for the over/under pattern at each 'fan', and which one is used affects the curvature:
A nice effect of creating the pre-optimization geometry by rotating and extending mesh edges in this way is that the correct over/under pattern for each fan gets generated automatically.
Optimization for tangency
We now have an approximate reciprocal structure, where the lines are the centrelines of our rods, but the distances between them where they cross vary, so we would not actually be able to easily connect the rods in this configuration.
To attach the rods to form a structure, we want them to be tangent to one another. A pair of cylinders is tangent if the shortest line between their centrelines is equal to the sum of their radii:
Achieving tangency between all crossed rods in the structure is a tricky problem - if we move any one pair of rods to be tangent, we usually break the tangency between other pairs, and because there are many closed loops, we cannot simply start with one and solve them in order.
Therefore we use a dynamic relaxation approach, where forces are used to solve all the tangency constraints simultaneously, and over a number of iterations it converges to a solution where they are all met. The latest Kangaroo includes a line-line force, which can be used to pull and push pairs of lines so that they are a certain distance apart. Each rod is treated as a rigid body, so forces applied along its length will cause it to move and rotate.
The reciprocal component uses Plankton to find the indices of which lines in the list cross, which are then fed into the force for Kangaroo. We also use springs to keep each line the same length.
If the input is good, when we run the relaxation (by double clicking Kangaroo and pressing play), the rods should move only a little. We can see whether tangency has been achieved by looking at the shortest distance between the centerlines of the crossing rods. When this is twice the rod radius, they are tangent. Wait for it to solve to the desired degree of accuracy (there's no need to wait for 1000ths of a millimeter), and then press pause on the Kangaroo controller and bake the result.
The radius you choose for the pipes, curvature of the form and length of the edges all affect the result, and at this stage you may need to tweak these input values to get a final result you are happy with. If you find the rods are not reaching a stable solution but are sliding completely off each other, you might want to try adding weak AnchorSprings to the endpoints of the lines, to keep them from drifting too far from their original positions.
For previewing the geometry during relaxation I have used the handy Mesh Pipe component from Mateusz Zwierzycki, as it is much faster than using actual surface pipes.
To actually build this, you then need to extract the distances along each rod at which the crossings occur, and whether it crosses over or under, mark the rods accordingly, and assemble (If there is interest I will also clean up and post the definition for extracting this information). While this technique doesn't require much equipment, it does need good coordination and numbering!
There is also a ReciprocalStructure user object component that can be found in the Kangaroo utilities tab, which attempts to apply steps 3 and 4 automatically. However, by using the full definition you have more control and possibility to troubleshoot if any part isn't working.
The approach described here was first tested and refined at the 2013 Salerno Structural Geometry workshop, lead by Gennaro Senatore and myself, where we built a small pavilion using this technique with PVC tubes and cable ties. Big thanks to all the participants!
Finally - this is all very experimental work, and there are still many unanswered questions, and a lot of scope for further development of such structures. I think in particular - which of the relative degrees of freedom between pairs of rods are constrained by the connection (sliding along their length, bending, and twisting) and how this affects the structural behaviour would be interesting to examine further.
Steps 3 and 4 of the approach presented above would also work with quad meshes, which would have different stability characteristics.
There is also the issue of deformation of the rods - as the procedure described here solves only the geometric question of how to make perfectly rigid straight cylinders tangent. The approach could potentially be extended to adjust for, or make use of the flexibility of the rods.
I hope this is useful to somebody. Please let me know if you do have a go at building something using this.
Any further discussion on these topics is welcome!
Further reading on reciprocal structures:
http://vbn.aau.dk/files/65339229/Three_dimensional_Reciprocal_Structures_Morphology_Concepts_Generative_Rules.pdf
http://www3.ntu.edu.sg/home/cwfu/papers/recipframe/
http://albertopugnale.wordpress.com/2013/04/05/form-finding-of-reciprocal-structures-with-grasshopper-and-galapagos/
…
me logic produced by running the 2-d voronoi component.
From a given set of polylines we can extract the centers and this can drive both the voronoi component as well as provide the XYZ drill points for the cnc. The definition has a variety of different options. You need Lunchbox, Weaverbird, and Starling. I can't tell you how amazing these 3 tools are from a design perspective. They are extremely powerful so if you don't have these you must install them asap. You can get the tools at http://www.food4rhino.com/
This definition works by first choosing a grid type, next you choose voronoi type, and subdivision type. From the voronoi type list you can choose basic (just grid), truncation (uses truncation calculated via the image sampler), truncation dual (uses the dual of the truncated image based grid), and subdivision (takes the basic grid type and uses different subdivision shcemes). Each of these provide different patterns of polylines from which we can extract our drilling points. I am rather proud of this definition since the overall idea is one which is so simple it's easy to overlook - the idea that drilling with a ball end mill makes voronoi plots. Now when you combine that with all of these amazing tools it can go off right quick. The nice thing is the paatern you see on screen is the pattern that gets made by drilling wysiwyg cnc patterns.
VORONIO_DRILLing.gh
Here are some on screen patterns in process in the following order truncation, basic, subdivision:
here is a video moving over a machined example:
…
or a couple of thingies.
Pattern.gh
I defined parametrically a triangle which I then smoothed out to become more like a blob shape. After that I created a pretty simple pattern that I had in my mind (costed me a lot of time to make this in GH) and finally wanted to rotate each element as it goes higher . The dispatching part seems to be working pretty slow, so it might need an optimization, but I’m still happy with the result as it shows exactly what I wanted, so this is a minor issue in my case.
I then decided to try tessellating my extrusions. You’ll see the voronoi script which is a blob-group in the same Pattern.gh:
I had an idea of something and started the code from scratch, then decided to watch tutorials and implement the code shown there. I somehow coped to combine my code with this in the tutorials, but since my knowledge of Grasshopper is zero to basic my code seems to be very unoptimized and lagging.. When dragging the sliders, it takes a lot of time to compute the changes, although, I’m working on a 24gigs 6th gen i7 machine. It might also need optimization.
Here comes the first tricky part that I couldn’t sort out in an elegant way neither in Grasshopper nor in Rhino. I want a smooth transition between the wall and the ceiling, so that the voronoi tessellation doesn’t get interrupted. If I was to do it in Rhino I’d make a curve with a filleted edge which I’d then revolve/sweep along a rail.
Pattern.gh:
Second thing is – I’ve defined a shape which I want to rotate at a certain degree as it goes higher, however, I don’t have the knowledge to make this happen automatically and just copy the script over and over again. Is there a chance to somehow “loop” the code and parametrically define the degree of rotation and amount of units in the loop?
Next thing is I want to somehow be able to rotate each “6-storey-building” dependently on its surrounding buildings, so that their “terraces” never overlap. I’m using quotes, since they’re still some silly shapes that have nothing to do with buildings and terraces. The principle has to be something like gear wheels or the so-called rack wheels . There has to be some pace which I could set parametrically, but I’m still unsure how to do that in Grasshopper.
The pre-last thing is that I want to control the height of each “building” based on let’s say a topography. I presume this could be done somehow with height maps or some gradient mapper connected to curvature analysis. Not really sure how something like this would work, but I’ve seen such codes that control height depending on a variable.
The last one is more or less similar to the previous. I want to be able to “dissolve” the pattern that I initially created and make it irregular. I suppose this could be done with attractor curve, but again this is just a guess. Please note that this is a top view and the shapes on the upper-left corner have got more "wings" which means there is more floors in the according building. Let's say the buildings in the upper-left corner are 6-7 floors high, in the middle are 4-5 and to the right they're only 3 floors high.
Sorry for that many questions in a single thread. Please let me know if I have to split them in separate threads. All this information is needed for learning purposes. I’m now preparing myself for my bachelor thesis and try as much things as I could, so that I’ll be ready for the final stage of my bachelor’s degree.
Many thanks in advance! Cheers!…
ger work.
Be aware, this release breaks file-forwards compatibility. You will not be able to open gh and ghx files saved with 0.8.0050 on previous versions, though of course you should be able to open old files without problems. If this is not the case, please yell loudly.
If you're having trouble loading Grasshopper, note that you must have the latest Microsoft C++ Runtimes installed on your machine. They can be downloaded from the microsoft website.
The new release can be downloaded from the usual location.
Here's a list of changes, additions and fixes since 0.8.0013:
File format forwards compatibility has been broken. You will not be able to open files saved with 0.8.0050 on earlier versions.
This release contains many breaking changes and GHA libraries compiled for older version may not work anymore.
Grasshopper Binary files (*.gh) are now saved as compressed data.
Grasshopper Binary files (*.gh) are now the default format.
Support for ancient versions of the Text Panel (still called Post-It from back then) has been removed.
Support for ancient versions of the Path Mapper (still called Path Lexer from back then) has been removed.
Placeholders for ancient versions of the Graph Mapper have been removed.
Gradient input parameters now show state tag icons (Reversed, Flatten etc.).
Geometry Cache name changes are now updated on every key press.
Geometry Cache name changes can now be cancelled with Escape.
Geometry Cache name changes can now be undone.
Mesh|Mesh intersection component now uses a different algorithm. The old behaviour is still available from the component menu.
Warning and Error balloons are now drawn as part of a Canvas Widget and will no longer show up in the Hi-Res image export.
Galapagos now accepts multiple fitness values. The true fitness will be the average of the collection.
Galapagos wires are drawn much fainter when the Galapagos object is unselected.
Medium fast redraw mode in Galapagos now immediately redraws instead of at the end of each generation.
Redesigned all Grasshopper file format icons and added larger size icons for high-dpi explorer views.
Redesigned the Most Recently Used files menu, it should now display much quicker.
Compass widget has been rewritten in an attempt to increase display performance.
Added preferences section for Compass widget.
Added preferences section for Align widget.
Added preferences section for Default Preview colours.
Added preferences section for Document Preview colours.
Added preferences section for the Most Recently Used files menu.
The Area component now accepts Breps, Meshes and Planar Closed Curves.
The Area Centroid component now accepts Breps, Meshes and Planar Closed Curves.
The Volume component now accepts Breps and Meshes.
The Volume Centroid component now accepts Breps and Meshes.
Added Merge Faces component (Surface.Util panel).
Added a Mesh Smooth component (Mesh.Util panel).
Added a Curve Seam component (Curve.Util panel).
Added Interpolate Curve With Tangents component (Curve.Spline dropdown).
Added GrasshopperFolders command to open Settings, Components and UserObject folders without loading the core plugin.
The window that reports on certain Loading Errors now has a Copy button.
Added Simplify post-process filter to parameters (in addition to Reverse, Flatten and Graft).
Parameter post processes (Reverse, Flatten, Graft & Simplify) can now also be assigned to output parameters.
Version History window now has formatting (not happy with this, I'm working on something better).
The Process Info window is gone.
Main menu has been redesigned.
Canvas toolbar has been redesigned.
Canvas context menu has been replaced by a Radial Menu.
Canvas now has a radial menu which will pop up on Middle Mouse Button clicks.
It's possible to switch between Radial and Legacy menus in the Preferences (Interface.Canvas section).
'Save As Copy' feature has been replaced by 'Save Backup' which is a GUI-less save including date+time stamp.
Added a 'Show in Folder' item to the File menu.
AutoSave settings are no longer available from the File menu, you now need to use the Preferences.
Selection shifts now also modify the view so you can use Ctrl+Left and Ctrl+Right to navigate up and downstream.
Mesh Edge display can now be toggled with Ctrl+M.
Preview modes now have shortcuts (Ctrl+1 = no preview, Ctrl+2 = wireframe, Ctrl+3 = shaded).
Solution States now have a default name.
Data Viewer window now responds to all required events.
Data Viewer window can now handle input and output parameters as well.
Canvas Navigation pane can now be dragged using the icon in the upper left corner.
The Persistent Data Editor has been redesigned.
It's now possible to select multiple items in the Persistent Data Editor list and edit their properties.
It's now possible to drag multiple items at the same time in the Persistent Data Editor list.
Item addition to the Persistent Data Editor is much improved.
The Persistent Data Editor is now non-modal.
The Canvas would remain black upon maximizing the Rhino window, this is fixed.
Sliders would cause multiple updates under certain conditions, this is fixed.
Digit Scrollers would cause multiple updates under certain conditions, this is fixed.
Pipes were inside out. This is fixed.
The curve component would not adjust invalid nurbs degrees, this is fixed.
Curves referencing Brep edges failed to load, this is fixed.
Points referencing Brep edges failed to load, this is fixed.
Referenced dlls in the VB/C# components sometimes resulted in invalid imports statements, this is fixed.
Pasting geometry in Rhino would cause a recompute of the Grasshopper solution, this is fixed.
Importing a file into the Rhino document would cause a recompute of the Grasshopper solution, this is fixed.
Galapagos would trigger superfluous solutions, this is fixed.
Mesh Solid Difference had a wrong name and description, this is fixed.
Several menu items were not greyed out despite not being usable, this is fixed.
The position and size of the Grasshopper window failed to get stored on Rhino shutdown, this is fixed.
The Persistent Data Editor would crash on parameters that did not support data proxies, this is fixed.
I'll add some additional information regarding some of the new UI features in subsequent posts.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…