to control which part is allowed to connect to other parts and how. We will first look at the basics of defining rules, and then how to use the rule generator to create them automatically. Finally we will look at how to use connection types to allow more control on the final aggregation.
Video topics:
- Rules introduction: 00:27
- Rules basics: 4:25
- Using the rules generator: 13:22
- Using rule types: 16:58
Download the tutorial files here: https://bit.ly/wasp101_003
Watch the full playlist: https://www.youtube.com/playlist?list=PLCn3-_9Z4-E5A0EFluiMldlEbDufMiN1g
---
Download Wasp at: https://www.food4rhino.com/app/wasp
Wasp Newsletter: https://mailchi.mp/e0ccee5c4e32/wasp_newsletter
Source Code: https://github.com/ar0551/Wasp…
r visual programming tools in the games world. MS's Kodu, looks interesting. Kismet and Visual3d look even more interesting..... mainly because they are more 'interactive' or 'reactive', rather than DAG-based.
Seems like the evolution path for GH-similar apps is:
1. base 3d or CAD app based on C/C++ code.
2. Add scripting language interface
3. Add some kind of visual interface
4. Add graph sorting / propagation engine
5. Re-jig base 3d or CADD app to make managed/interpreted scripts run faster, multi-threaded.
6. Add dynamic typed language, DLR stuff
6. ....
6. Add constraints solver...?
7. Rebuild CAD display engine to be procedural at the GPU level?
Seems like there are available tools for converting scripts into some kind of flowchart. There are even visual debuggers. MS even has something called the 'Debugger Canvas'. Spreadsheet constraints.
Seems like the time is ripe for lots of new apps like GH.
…
y serve as a demo to you.
That said building regulations is a paramount factor (they vary according country).
In general and if the star body is mono-block (say: concrete) ... I would strongly suggest to use real-life "objects" as parts and orient them properly (steps. handrails et all). If the stair is an assembly this is utterly paramount.
But if you work with some feature driven BIM app (Revit, AECOSim etc) there's some automation available (100% useless in 1:1 detailed studies).…
onstrates the following:
1. The definition's functionality employing HumanUI for the custom user interface.
2. Color based segmentation in manual and auto modes.
3. The evaluation of the definition's ability to handle different point cloud data sets.
This definition performs color based segmentation in two modes.
A manual mode, that implements the Delta-E CIE 2000 color difference formula, for targeted feature detection. An auto mode, that employs a simple RGB Color Range algorithm for quicker preliminary results.
RGB to XYZ to CIELab conversion and Delta-E scripts were based on Colormine's project code from github. Results have been compared and verified with the results of http://colormine.org/color-converter and http://colormine.org/delta-e-calculator/Cie2000.
Each stored class is charted and can be accessed through the UI, as shown at 2:30, where Delta-E CIE 2000, in CieLab color space, output results were found to be in perceptive conformity with human eyes, far superior to the preliminary RGB implementation.
Initial definition versions could process highly subsampled clouds in acceptable timings. Further research showed that employing the multithread processing of Volvox components, bundling the Delta E formula with the RGB to CIE lab color conversion script, per color segmentation calculations for a one million points point cloud would go down from 23 (c# script component) and 8 (vb script component) seconds to approx. 1 second (volvox script cloud component), thus allowing the segmentation of less subsampled point clouds.
I would like to thank Heumann A. and Zwierzycki M. who provided direct support with HumanUI and Volvox. Also Grasshopper3d forum users Maher S. and Segeren P., who contributed with Rhino viewport manipulation scripts.
More on Volvox:
http://papers.cumincad.org/cgi-bin/works/Show?_id=ecaade2016_171&sort=DEFAULT&search=ecaade%20volvox&hits=2629
http://www.food4rhino.com/app/volvox
http://duraark.eu/
HumanUI:
http://www.food4rhino.com/app/human-ui?page=1&ufh=&etx=
ColorMine:
https://github.com/THEjoezack/ColorMine…
ess more memory on 64 bits. So you can load larger files and generate more data.
Every time you store something in memory it has to be stored at a specific location. We call this location an address. The first thing you store can be stored at address 0*. If that thing requires a total of 18 bytes, then addresses 0 through 17 are used up. The next thing you store can then be stored at address 18. And so on and so forth. At some point you run out of addresses and when that happens there is no more room to store any new data and there is thus nothing more that your app can do and that's usually when Windows shoots the application in the head and buries the remains behind the chemical sheds.
The total number of unique addresses that can be represented by a 32-bit integer is 4,294,967,295 (4 GigaByte). However Windows only allows a 32-bit app to access 2GB, or potentially 3GB if a special switch is set. A 64-bit application is allowed to use 64-bit integers to identify memory addresses, which means the highest possible address is now 18,446,744,073,709,551,616 (or 18.45 ExaBytes). Basically, as long as you have RAM to back you up, a 64-bit application will not run out of memory. Of course it may still become prohibitively slow as a lot of data requires a lot of computation and 64-bitness does absolutely nothing to make things go faster.
--
David Rutten
david@mcneel.com
Vienna, Austria
* Not true in reality, Windows will already use up some of the available memory just to load the application.…
Added by David Rutten at 1:39pm on November 2, 2012
wing2D
Imports System.Reflection
Imports System.Collections
Imports System.Collections.Generic
Imports Microsoft.VisualBasic
Imports RMA.OpenNURBS
Imports RMA.Rhino
Imports Grasshopper.Kernel.Types
Class Grasshopper_Custom_Script
#Region "members"
Private app As MRhinoApp
Private doc As MRhinoDoc
Public P, C As System.Object
#End Region
Sub RunScript(ByVal x_range As OnInterval, ByVal y_range As OnInterval, ByVal attractors As List(Of On3dPoint), ByVal factor As Double)
'''
If (attractors.Count = 0) Then Return
If (factor <= 0.0) Then Return
Dim Rnd As New Random(123456)
Dim failed As Int32 = 0
Dim Pts As New List(Of On3dPoint)
Dim Rad As New List(Of Double)
Dim Crc As New List(Of OnCircle)
Do
If (failed > 100) Then Exit Do
Dim x As Double = x_range.ParameterAt(Rnd.NextDouble())
Dim y As Double = y_range.ParameterAt(Rnd.NextDouble())
Dim pt As New On3dPoint(x, y, 0.0)
If (IsTaken(pt, Pts, Rad)) Then
failed += 1
Continue Do
End If
failed = 0
Dim d As Double
Dim i As Int32 = NearestAttractor(pt, attractors, d)
Dim radius As Double = factor * (Math.Pow(d, 0.8) + 0.5)
Pts.Add(pt)
Rad.Add(radius)
Crc.Add(New OnCircle(pt, radius))
Loop
P = Pts
C = Crc
'''
End Sub
#Region "Additional methods and Type declarations"
#End Region
End Class
Hope you can see an error :)…
ts (Rhino 6 and everything that came after the plugin itself was written).When I tested it, it had some issues with a large number of lines and if parameters weren't carefully tuned it failed to produce consistent meshes.If some of you has time and skills on their hands, there is the source code available on GitHub (link is in the description). For personal use, time ago I updated a definition by David Stasiuk to make nodes and beams, based on 3D Convex Hull component. You can still find it here:https://www.grasshopper3d.com/xn/detail/2985220:Comment:1745216Warning: in Rhino 6 the Starling Convex Hull component doesn't seem to work well, you can use the 3D Convex Hull from the MeshEdit plugin instead (https://www.food4rhino.com/app/meshedit - just substitute the 3D Convex Hull component in the definition and it should work fine).…
ter proofing and er ... the obvious).
However the "assembly" must comply with some part naming system as found in BIM apps (my core app is AECOSim) and obviously with CSI type of specs and the likes. I fact I have a complete "app" that does this ... but (a) is strictly internal, (b) is written for AECOSim/Generative Components by yours truly.
Graphics is also a serious issue and especially combined ones: for instance imagine someone naive enough to use polystyrene [hence the vapor barrier] to do this type of disastrous roofing (meaning that DP is one thing, water absorption is another animal much much more important than DP itself > polystyrene absorbs all the condensate > Armageddon > Adios Amigos):
By combined I mean this "typical" scenario as well:
…
s are carried over solely via code even for tasks related with K2 (for a vast variety of reasons mostly related with "communications" to/from other CAD apps used in a real-life BIM driven AEC pipeline [where GH plays a small role]).
If 2 is OK with you, drop a word.…
can use cross reference component (search on forum for more info on this).
For intersection part you can use BullAnt plugin: http://www.food4rhino.com/app/bullant or you can use "split surface" between your surfaces and all the curves but it is a lot more slower...
for the attractor thing i dont understand what you want, but once you get your close polylines, you can get "control points" and use some attractor tutorial on that and then reconstruct those polylines.
…