.OpenNURBS.OnCurve' can not be converted to 'Table 1 dimension (s) RMA.OpenNURBS.OnBrep'. (Line 83)
Message d'origine:
Après essai:VB Scipt:rhUtil.RhinoSweep1(x, y)X OncurveY OncurveError: Une valeur de type 'RMA.OpenNURBS.OnCurve' ne peut pas être convertie en 'RMA.Rhino.MArgsRhinoSweep1'. (line 83)Error: Une valeur de type 'RMA.OpenNURBS.OnCurve' ne peut pas être convertie en 'Tableau à 1 dimension(s) de RMA.OpenNURBS.OnBrep'. (line 83)…
Added by Rémy Maurcot at 2:25pm on December 16, 2010
), my script is triangulating slabs by drawing line in a crossreference way. This part was "easy"
What I want to do now is to link those slabs together
ie : if a slab is a surface AxBxCxDx
I want to link A1 to A2, B1 to B2, C1 to C2 etc.
I know it's a simple question of restructuring the tree in my Pshift component, so that I can use the line component with shortest list, and link each of those points.
Any ideas on how to fix that?
Thank you
Simon…
A low-resolution work. Real time motion capture display made with an 11x8 (88) pixels iPad matrix using Grasshopper + Firefly + Pure Data + TouchOSC for iPad.
hreads where Thread I solves object A1 and Thread II solves object A2. As soon as A1 is completed, Thread I can move on to object B1 and as soon as A2 completes, Thread II can move on to object B3 (whichever comes first). When both A1 and A2 are complete, we can spawn a new thread (III) to take care of object B2.
If B2 completes before B3, then Thread III will terminate. If B3 completes before B2, then Thread II terminates. Whichever thread is last will pick up execution of object C3. And so on and so forth.
This sort of threading is actually not guaranteed to help much though, as it is likely that the bottleneck components in the network will still need to be handled by a single thread.
A more efficient solution would be to divvy up the execution per component to multiple threads. If you're trying to compute the Curve Closest Point for 10,000 points and your machine contains 4 cores, then we can assign 2,500 points to the first core, 2,500 points to the second core etc.
This approach will actually work when there's only a few bottleneck components and it also means the order in which components are solved is no longer important.
An even more fine-grained approach to threading would be to make the Curve Closest Point function in the Rhino SDK threaded. There's a lot of looping going on in any given Curve CP computation so the curve could be broken up into loose spans where each span is solved by a different core. Then the partial results get consolidated once all threads finish.
The benefit here is that it would be multi-core for everyone, not just Grasshopper components.
The bad news: Some functions in Rhino are not thread-safe. Meaning that data structures such as NurbsCurves cannot be modified from multiple threads at once as it will compromise their validity. You might well end up with invalid curves and quite possible weird crashes. In very bad cases it might even be that a specific function in our SDK can only be running once, so even if you were to duplicate the curve it would still not work.
Until our SDK is thread-safe there can be no global threading in Grasshopper. I don't know where we're headed with this, but I do know that we've started using some threaded algorithms in the display as of Rhino5, so it seems we're at least getting our feet wet.
--
David Rutten
david@mcneel.com
Seattle, WA…
Added by David Rutten at 5:47pm on November 17, 2010
Hi Tom, I made a solution for your diagrid tower, based on the curves of the primer page 84 curves. If that is also what your mesh is based on (or somethin similar), this will work nicely.
pe and its surface.
However, I don't have that much knowledge about both grasshopper and Mathematica.. I mean I can only make assumptions and think about relations of certain functions but that's all.
If you can help me on this, I would appreciate it so much.
You can see a screenshot of the code and model of the demonstration from mathematica in attachment.
And here is the mathematica code;
Manipulate[ Module[{\[CurlyEpsilon] = 10^-6, c1 = Tan[a1], c2 = Tan[a2], c3 = Tan[a3], c4 = Tan[a4], c5 = Tan[a5], c6 = Tan[a6]}, ContourPlot3D[ Evaluate[ c6 Sin[3 x] Sin[2 y] Sin[z] + c4 Sin[2 x] Sin[3 y] Sin[z] + c5 Sin[3 x] Sin[y] Sin[2 z] + c2 Sin[x] Sin[3 y] Sin[2 z] + c3 Sin[2 x] Sin[y] Sin[3 z] + c1 Sin[x] Sin[2 y] Sin[3 z] == 0], {x, \[CurlyEpsilon], Pi - \[CurlyEpsilon]}, {y, \[CurlyEpsilon], Pi - \[CurlyEpsilon]}, {z, \[CurlyEpsilon], Pi - \[CurlyEpsilon]}, Mesh -> False, ImageSize -> {400, 400}, Boxed -> False, Axes -> False, NormalsFunction -> "Average", PlotPoints -> ControlActive[10, 30], PerformanceGoal -> "Speed"]], {{a1, 1, "\!\(\*SubscriptBox[\(\[Alpha]\), \(1\)]\)"}, -Pi/2 - 0.01, Pi/2 + 0.01, ImageSize -> Tiny}, {{a2, 1, "\!\(\*SubscriptBox[\(\[Alpha]\), \(2\)]\)"}, -Pi/2 - 0.01, Pi/2 + 0.01, ImageSize -> Tiny}, {{a3, 1, "\!\(\*SubscriptBox[\(\[Alpha]\), \(3\)]\)"}, -Pi/2 - 0.01, Pi/2 + 0.01, ImageSize -> Tiny}, {{a4, 1, "\!\(\*SubscriptBox[\(\[Alpha]\), \(4\)]\)"}, -Pi/2 - 0.01, Pi/2 + 0.01, ImageSize -> Tiny}, {{a5, 1, "\!\(\*SubscriptBox[\(\[Alpha]\), \(5\)]\)"}, -Pi/2 - 0.01, Pi/2 + 0.01, ImageSize -> Tiny}, {{a6, 1, "\!\(\*SubscriptBox[\(\[Alpha]\), \(6\)]\)"}, -Pi/2 - 0.01, Pi/2 + 0.01, ImageSize -> Tiny}, AutorunSequencing -> {1, 3, 5}, ControlPlacement -> Left]…
the original curve has area A1 and it is scaled by a factor b, then the resulting curve has area A1*b^2. The difference between these areas is your target A2, so we need to solve for the factor b. This is sqrt(1-(A2/A1)) and will be different for each curve. Then we can loft the external and internal curves, cap, and subtract to get the final solid. It's then verified by slicing with normal planes and calculating the areas of the cross sections.
.…