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…
difference consists of.
An Evolutionary Solver/Genetic Algorithm is an implementation of Metaheuristics. Metaheuristics tend to be flexible solvers, applicable to a wide variety of problems, fairly easy to implement, but slow. Other examples of Metaheuristic algorithms would be Random Search, Scatter Search, Simulated Annealing and do on. These algorithms are often modelled on physical or biological processes.
Simulated Annealing for example simulates the physical process of annealing (who'd have thunk it), which is basically the slow cooling of a material which allows it to settle into a crystalline lattice, i.e. a low energy distribution of all the atoms. I'm currently adding an SA solver to Galapagos, and in fact just yesterday managed to get the first successful run: http://www.youtube.com/watch?v=VWtYLv-4oP0
Metaheuristics are especially useful for those cases where little is known about the problem ahead of time. If the problem search-space is mathematically well defined (differentiable, especially), then you can use more targeted algorithms such as the Newton-Raphson method, Pareto-search or Uphill search. You can still use these methods on non-differentiable search-spaces, but it involves sampling the local region to death to get an estimate of the differential. This can be a very costly enterprise, especially in high dimensional search-spaces. In a two-dimensional search-space you'll need 3 to get a lame estimate and 4 to get a halfway decent estimate and 8 to get a good estimate. In three-dimensional search space you already need 26 samples, and the number of samples grows exponentially with higher dimensions.
If you have a specific problem you're trying to solve, Metaheuristics are probably not the best solution, even though they may be easiest to program. Rhino uses something akin to Newton-Raphson for certain problems and that's fast enough to run in real-time.
Divide-and-Conquer algorithms are also quite popular. Sometimes they are called Binary-Search or Tree-Search algorithms as well. Their basic premise is to sample the search-space at a few intervals (but enough to capture the needed detail), then find two neighbours with promising values and sample again in between these two. Then repeat. Each new iteration typically doubles accuracy, which is great because then you only need ~30 ~40 iterations to get an answer as good as possible with double-precision floating point accuracy. However not all problems lend themselves well to this sort of search and in higher dimensions it starts getting slow with disconcerting alacrity.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 1:54am on August 15, 2011
user to understand. RhinoScript is a generally more straightforward and easy to use. You can think of it as a translation of RhinoCommon so that you don't have to write all the technical stuff.
In your first line you've said "import rhinoscriptsyntax as rs". To see the methods you can call from this library you can go to the help menu and choose 'Help for Rhinoscript'. It will show you a searchable window of all the the options you have. This is much easier for new users to learn than looking at the RhinoCommon SDK.
If you search the help file for 'BoundingBox' you'll get the screen capture below:
At the bottom you can see an example of how to use it. In your case you would replace the following lines:
2/ boxA=brepA.GetBoundingBox((0,0,0,)) --> boxA = rs.BoundingBox(brepA)
3/ boxB=brepB.GetBoundingBox((0,0,0,)) --> boxB = rs.BoundingBox(brepB)
The script you have written uses elements of both RhinoScript and RhinoCommonSDK. I would suggest you might start just using RhinoScript. See below, I have re-written the first 8 lines of your script using just RhinoScript:
import rhinoscriptsyntax as rs
#Get BoundingBox from breps.BoundingBoxA = rs.BoundingBox(brepA) #Returns list of eight corner points.BoundingBoxB = rs.BoundingBox(brepB)
#Get centre point of RhinoScript BoundingBox (which is a list of eight points).boxA = rs.AddBox(BoundingBoxA) #Generate box from corner pointsptA = rs.SurfaceVolumeCentroid(boxA) #Get Volumetric Centroid of boxboxB = rs.AddBox(BoundingBoxB) ptB = rs.SurfaceVolumeCentroid(boxB)
For reference the following will achieve the same thing using RhinoCommon, fewer lines, but more technical. There are a few other quirks as well, for example you have to explictly tell the python component what kind of object 'brepA' is. See below for example of same script in RhinoCommon:
import Rhino as rh
centerPtA = brepA.GetBoundingBox(rh.Geometry.Plane.WorldXY).CentercenterPtB = brepB.GetBoundingBox(rh.Geometry.Plane.WorldXY).Center
I'm not sure what you are trying to achieve overall and your loop doesn't make a lot of sense to me but I hope that clarifies some of the differences between the two libraries you can use.
Regards,
M…
own use and added the command line port LPT1 port dump.
I found a couple of strange things in your code:
# Changes the model units to inches, but does not scale model.rs.UnitSystem(unit_system=8, scale=False)
Why did you change the model units here? HPGL units are 40 per mm (which is also 1016 per inch) staying in mm units in your model will be fine if your step scaling in right.
And doing this seems strange for a cutting program:
allCurves = rs.ObjectsByType(4)for curve in allCurves: if (rs.CurveDegree(curve) == 2 or rs.CurveDegree(curve) == 3) and rs.IsPolyCurve(curve): rs.ExplodeCurves(curve, True)allCurves = rs.ObjectsByType(4)
Cutting usually needs a closed curve to produce a nice clean removable piece from the material. Your approach results in a bunch of line/curve segments instead of closed polycurves/polylines. As this simulation shows the 'O's and 'R' are cut as a collection of curve segments - not closed polycurves:
I just removed this step from the code.
As this simulation shows every part of the font is cut in one cut action - exactly what I needed:
I saw your RVB code on the RhinoScript site too - was way more detailed than I needed - my vinyl cutter only has one 'pen' - the cutting blade. I just needed a really basic way of getting polycurves into HPGL format and firing it out to a printer port.
Thanks for your help on this little project - I'm very stoked at the result! Let me know if I can help with your cutter project.
Cheers
DK…
to a rationalized integer format for use in the grasshopper definition . I don't want to convert the information permanently, but have been looking for an elegant method for converting the datetime string as needed so that it can interface within a grasshopper definition.
What I am trying to do is create a process for working with the timestamp included alongside sensor data I pull from Cosm. The data feed is formatted like this; <current_value at="2012-07-25T05:24:44.601988Z">77.68</current_value> and the Time paramater seems to easily understand the datetime string to read 2012-07-25T05:24:44.601988 as Wednesday, 25 July 2012 (05:24:44) so I plan on keeping the string as is when stored in a local mySQL database I have setup, but want to make sure I am not setting myself up for major headaches down the road.
I asked about converting the date time string to an integer to allow me to find time spans and generate a series of time stamps in an efficient way for creating a batch/ iterative process for requesting additional sets of data based on a query comparison of what gaps are left to fill in along a timeline of data points.
At the moment, I think a conversion to an integer is my best bet. (ref; Excel Date Time Code Id love to be able to feed in a date into a math component, add 08:00:00 and for it to result with a time 8 hours later than the first. I also have a string manipulation method working also, but have yet to really test it beyond what I have shown in the screenshot below.
I currently have these batches stream from Cosm.com into Grasshopper via a xml parser component (either the one found in Andy Payne's Firefly set, or the one included in gHowl.) From there I sort/ extract the data points and their respective time stamps and feed these data points into a mySQL database I've setup with Nathan Miller's Slingshot components. With the points in a local SQL database, I can then begin to integrate the use of database queries into definitions and retrieve data points based on sensor value Booleans rather than being restricted to time spans, (which is the only way to request historical data from Cosm's site)
I've been debating on if I should convert all the time information to an integer before writing it to the SQL database so GH can work with the data, or if I should keep the time code as a string and create a couple of conversation component clusters to translate the information each time it needs to be processed or manipulated in GH. I'd prefer to keep things in the date time string because the database can handle it without a problem, GH sort of handles it in one translation direction and allows me to avoid conversion that Id have to explain to others if they were to access the database in their own grasshopper definition or from another application.…
st variety of papers (mostly related with LIDAR airborne sampled clouds) ... but ... hmm ... no code (other than some "abstract" algos that may (or may not) work). Reason? A very hot cake that one these days: from reverse engineering to DARPA founded future defense systems and up to cruse missiles pattern recognition algos.
The solution (obviously doable only via code) is the so called flat hard clustering ... were points are sampled into clusters based on the coPlanarity "rule". For large amounts recursive octTrees (an oriented box divided in 8 "partitions") subdivisions are used and then pts are processed in parallel (and then clusters are re-evaluated in order to "absorb" other clusters with same plane A,B,C,D vars etc etc).
See what's happening in a very carefully made test point collection:
3.7 ms and the "ideal" clustering (7 search loops VS the max 42M theoretical threshold):
Depending on the pts "preparation" ... a considerable more time/search loops is required ... and ... well ... also "valid" clusters (4 points and up) made:
So "ideally" speaking in your case:
1. Mesh faces center points (or alternatively: mesh vertices) are sampled into a pts collection .
2. Hard flat coPlanarity clustering is attempted yielding pts/planes in equivalent DataTrees.
3. Planar Breps are made with respect the planes (like the black things captured above) and sampled, say, into a breps List.
4. The method Brep[] solids = Brep.CreateSolid(breps); is used for attempting to create your desired "engulfing" brep. This method is very slow mind (other waaaay faster approaches also available).
…
that both the ASHRAE and European Adaptive models were derived from surveys of awake occupants. While the topic has not been investigated as well as it should be, the few adaptive-style surveys of sleeping occupants that have been conducted show that people tend to desire significantly cooler temperatures when they are sleeping as opposed to when they are awake.
Notably, Chapter 8 of Humphrey's recently-published book on Adaptive Comfort (https://books.google.com/books?id=lOZzCgAAQBAJ&printsec=frontcover&dq=Adaptive+Thermal+Comfort+Foundations+and+analysis&hl=en&sa=X&ved=0ahUKEwi6npqSi__KAhUJMj4KHf7SCXMQ6AEIKjAA#v=onepage&q=Adaptive%20Thermal%20Comfort%20Foundations%20and%20analysis&f=false) provides some interesting insights into this. In a 1973 survey, Humphreys found that the quality of sleep started to deteriorate at temperatures above 24-26C regardless of the time of year and that there was no clearly-determinable lower limit to comfortable sleeping temperatures (in other words, people were fine at 12C if they were given enough blankets). He surveyed only British occupants who were sleeping in traditional beds with mattresses and a wide range of blankets. This is important because the nature of the findings is such that the comfort temperatures would be very different if the survey participants had been sleeping in a hammock or in closer contact with the ground (both popular practices for a number of cultures living in warmer climates). Traditional mattresses cut the ability to radiate body heat in half as compared to a standing human body and I would venture a guess that this is a big reason why much cooler temperatures are desired while sleeping on mattresses as opposed to standing awake/uptight.
So for your case, if you want to account for a time of the day that occupants are sleeping on mattresses, I would change the comfort temperature for this these hours down to 24C. Otherwise, if you are trying to show the comfortable hours of awake people in your space, your current 100% comfortable nighttime hours are a better estimate. I have also noticed that nighttime temperatures become comfortable in extreme weeks of hot/dry climates. This is what is happening in this extreme week simulation of Los Angeles' San Fernando Valley here:
https://www.youtube.com/watch?v=WJz1Eojph8E&index=3&list=PLruLh1AdY-Sj3ehUTSfKa1IHPSiuJU52A
I will put in the ability to set custom values for comfort temperatures into the Adaptive Comfort Recipe soon so that you can test out a 'sleeping comfort temperature' if you would like. I have created a github issue for it here:
https://github.com/mostaphaRoudsari/Honeybee/issues/486
I was not so convinced by Nicol's argument about humidity on those pages as I was when I saw the correlations of both operative temperature and effective temperature to surveyed comfort votes in real buildings. Humphreys shows these correlations on page 106 of the book I linked to above. Notably, the correlation of Effective Temperature to comfort votes (0.257) is slightly worse than the correlation of just Operative Temperature (0.265). In other words, trying to account for humidity actually weakened the predictive power of the metric. This difference in correlation is not so great as for me to discount an Adaptive comfort model based on Effective temperature (as deDear once proposed). However, the correlations of PMV (0.213) and SET (0.185) to comfort votes are so poor that I now use the PMV model only with great caution.
This reason for the decreased importance of humidity may be multi-faceted, whether it's Nicol's explanation or another. Still, the data suggests that we are probably better off ignoring humidity when forecasting comfort and should only consider it when evaluating conditions of extreme heat stress where people's primary loss of heat is through sweating.
-Chris…
hopper) and High Definition visualizations (V-Ray) and exploring its scientific innovations supporting the users' platform philosophical ideas.
SESSIONS: 5 sessions of 8 hours (40 hours total)
E-MAIL: educacion@chconsultores.net
REGISTRATION: (55) 56 62 57 93
TECHNICAL INFO: 044 (55) 31 22 71 83
INSTRUCTORS: Have past experience working at Gehry Technologies, and participated at studios with Eric Owen Moss and Tom Wiscombe at SCI-Arc (Southern California Institute of Architecture).
Day 1: Introduction to MAYA tools, 3D exercise start.
Day 2: Continue 3D exercise.
Day 3: Original 3D architecture design.
Day 4: Grasshopper optional application on 3D architecture design.
Day 5: V-Ray Application on 3D architecture design.
30 DAY TRIAL SOFTWARE DOWNLOAD:MAYA 2012: http://www.autodesk.com/products/autodesk-maya/free-triaRHINO 4: http://s3.amazonaws.com/files.na.mcneel.com/rhino/4.0/2011-02-11/eval/rh40eval_en_20110211.exe3DS MAX 2010: http://www.autodesk.com/products/autodesk-3ds-max/free-trialVRAY FOR 3DS MAX: http://www.vray.com/vray_for_3ds_max/demo/thankyou.shtml#thankyouPHOTOSHOP e ILLUSTRATOR: https://creative.adobe.com/apps?trial=PHSP&promoid=JZXPS
www.helenico.edu.mx
www.scifi-architecture.com/#!workshops/c1wua
LIKE US ON: www.facebook.com/scifiarchitecture
…
he "return" is comment out as shown below?
After restarting Rhino and Grasshopper, I opened the outdoors_airflow demo file, and the first step of creating the case file is ok:
Then the blockMesh component gives the following error: seems I have to manually start OF first..
so, as the error message suggested, I open OF by Start_OF.bat:
Then come back to the blockMesh component, now it can be executed while the OF command line window is also openning:
... and the blockMesh finished successfully:
... so I proceeded to run snappyHexMesh, checkMesh and update fvScheme:
... up to the simpleFoam component, I got the error again:
The warning message is:
1. Solution exception: --> OpenFOAM command Failed!#0 Foam::error::printStack(Foam::Ostream&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #1 Foam::sigFpe::sigHandler(int) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #2 ? in "/lib64/libc.so.6" #3 double Foam::sumProd<double>(Foam::UList<double> const&, Foam::UList<double> const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #4 Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #5 Foam::GAMGSolver::solveCoarsestLevel(Foam::Field<double>&, Foam::Field<double> const&) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #6 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMatrix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #7 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #8 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so" #9 Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #10 Foam::fvMatrix<double>::solve() in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #11 ? in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #12 __libc_start_main in "/lib64/libc.so.6" #13 ? in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam"
... and the command lines in the readMe! output are pretty long and it is saved in the text file attached here.
So, my questions are:
1. why I have to manually start OF first before I can use the blockMesh component? Should butterfly automatically start OF?
2. what might be the cause of the unsuccessful run of simpleFoam in the end?
Hope you can kindly advise! Thank you!
- Ji
…
an run. GH2 still uses the Rhino SDK for the geometry functionality, so curve offsets, meshing, brep intersections etc. will run exactly as fast as they do now.
However even in the absence of a working version of GH2 which can be profiled, we can still discuss some of the major aspects of performance:
Preview display. Each GH solution involves a redraw of all the Rhino viewports at the end (unless is preview is switched off, which I imagine is exceedingly rare). For simple GH files, the viewport redraw takes far more time than the solution. Rhino6 has a completely rewritten display pipeline using more modern APIs so we should see a speed-up here in the future, be it GH1 or GH2 or GHx.
Canvas display. Each GH solution involves a redraw of the Grasshopper canvas. If the canvas shows a lot of bitmaps or intricate geometry (lots or text, dense graphs, etc.) this can take a significant amount of time. GH2 will use Eto instead of GDI+ as a UI platform. Eto can be both faster and slower than GDI, depending on what's being drawn. It is particularly fast when drawing images, not so much when drawing lots of lines. There is a little room for improvement here and I intend to take full advantage of that.
Preview meshing. Grasshopper uses standard Rhino mesher to generate preview meshes. If a GH file generates lots of breps, a large amount of time will be required to create the preview meshes. The new display improvements in Rhino6 will allow us to get away with previewing some types of geometry without the need to mesh them first, and I imagine some effort will be spend in the near future to improve the Rhino mesher as well.
Data casting. Most component code operates on standard framework and RhinoCommon types (bool, int, string, Point3d, Curve, Brep, ...), however Grasshopper stores and transfers data wrapped up in IGH_Goo derived types. This means that every time a component 'does it's thing', data needs to be converted from one type into another, and then back again. This involves type-checking and often type instantiation. This stuff is fast, but it's overhead nonetheless and can take significant amount of processor cycles when there's lots of data. GH2 no longer does this, it stores and transfers the types directly as they are. There will still be some overhead left, but hopefully a lot less.
Computation. GH1 is a single-threaded application. When a component operates on a large collection of data, each iteration waits for the next. GH2 will be parallel, meaning components will be invoked on multiple threads, each thread focusing only on part of the data. Then all the results need to be merged back into a single data tree. On my 8-core machine (4 physical cores, each with 2 logical cores) I've been getting performance speed-ups of 4~6 times when using my multi-threading code. I wish it was 8, but clearly there is some overhead involved here as well.This will not help to speed up a single very complicated solid boolean operation, but if you're offsetting 800 curves, then each thread can be assigned 100 curves and the time it takes will set by whatever thread takes the longest.
Algorithms. If a specific component is slow, there may be things we can do to speed it up. Either improve the Rhino SDK, or improve the GH code. Depends on the component in question.
When all's said and done, I'd love to see a 10x speed increase for GH2 over GH1 for simplish stuff, and I shall get very cross if it's anything less than 5x.…