st between those two applications. But as soon as every frame is re-calculated I noticed that intersection function is very slow. It is actually so slow, that maximum number of polygons to play with is only 10 or less.
Could you help me to find a faster solution for my script?
calculation of intersection lines;
//////////////////////////////////////////////////////////////////////////////////////////
import ghpythonlib.components as ghcompimport rhinoscriptsyntax as rsdef ctr(crv): pts = ghcomp.Explode(crv)[1] pts = ghcomp.CullDuplicates(pts,0.001)[0] return ghcomp.Average(pts)pts = []lines = []ctr_c1 = ctr(C1)for crv in C2: if ctr(crv) != ctr_c1: int = ghcomp.CurveXCurve(C1, crv)[0] if int: [pts.append(x) for x in int] lines.append(rs.AddLine(int[0],int[1]))
/////////////////////////////////////////////////////////////////////////////////////////////
The overall description of the script:
a)Processing+ghowl is used for moving objects and physics
b)python script (slowest part) calculates intersection lines
c)intersected parts of polygons are rotated in 90 degrees.
I have attached grasshopper and processing files. (processing is not necessary to test the script)
Thank you in advance,
Pereas.
…
width of the other letter
find the intersecting shape with Solid Intersection
re-orient final shape
This process sometimes breaks when a letter has one or more "holes" in it (eg: B, O, R). When this happens, the Solid Intersection component experiences an error and says "Boolean intersection set is empty". I don't know what that means.
I have tried the quick-fixes of flattening and grafting to no avail.
Could somebody shed some light on this issue?
I have internalized the letters into the attached GH def, but am also attaching the illustrator file that I'm using.…
e any affect, but that's way too slow if 90% of the GH program is initialization and creation of source geometry to then simply alter a bit or array here and there. When I use Python directly to change output values that I plug into former slider inputs, again no new solution is triggered at all so I'd have to recalculate the entire Grasshopper program which is simply not how Grasshopper normally works. How do I actually emulate a human changing a slider value one slider at a time in a way that makes Grasshopper behave normally so that only downstream flow is affected in an efficient way?
An related example would be if you have several separate programs in a Grasshopper page and you wanted to only change one of them without triggering full recalculation of them all.
At this point it's almost like a Windows mouse scripting utility is needed but if I need to do combinatorial combinations of all possible slider values, that seems quite thorny too unless I set up a pre-arranged array of values that could then simply be incremented "manually" followed by a right click to bake and then typing commands into Rhino to save to a file. UGH. That would be quite difficult to pull off since I need to control file names, but it's what I seem to need.
I'm using Python since it avoids thorny Grasshopper schemes and it allows me to access Rhino to save baked objects files.…
ving a copy of the surface in the original position. Second, and more frustrating, not all of the surfaces orient properly. A few lay flat but then rotate 90 degrees horizontally.
Any help or insights would be greatly appreciated!
Images and files are below.
grasshopper screenshot 1gh%20problem%20part%201.png
grasshopper screenshot 2gh%20problem%20part%202.png
grasshopper file slat%20wall%20C2.gh…
but as one would imagine after 6 or so 'animals' it gets so large that the machine starts to crawl :/
88% of the resources come from the permutation script, my guess is that if the permutation were calculated on the fly with the counter(the engine) it wont have to pre-compile the list which would be much faster...
If anyone has an idea im all ears....
I attached the file (re-written in C#) …
ASTER than iterating through a larger list of Breps to get the same result. Simply because there are far fewer 'SUnion' operations - even though the unions are more complex (and slower) in phase two.
Same code but organized a little better, with separate X & Y controls so the grids in both phases don't have to be square. This is 3 X 3 in phase one and again in phase two; 81 "points" in ~17 seconds. That compares to 49 seconds using a single 'suLoop' or standard 'SUnion' (they are the same, though 'suLoop' appears able to handle a far larger number of Breps).
…
Added by Joseph Oster at 10:49am on March 23, 2017
the various digital design methods and technologies that they employ in their design workflow, highlighted at various scales through their recent work.
Organizers and Moderators:
Andrew Haas, Program Co-Director, Architectural Association Visiting School New York
Alfonso Oliva, Associate/Director, LERA Consulting Structural Engineers
Speakers:
Luc Wilson, Senior Associate Principal and Director, KPF Urban Interface
Dan Levine, Associate Director, Solutions Engineering – United Technologies (UTC)
Jan Leenknegt, Architect and BIM Manager, Bjarke Ingels Group (BIG)
Introductions by AIANY Technology Committee Co-Chairs:
Michael Brotherton, AIA, VP of Operations, Situ Fabrication LLC
Alexandra Pollock, AIA, LEED AP BD+C, Director of Design Technology, Senior Associate, FX Collaborative
–
Due to building security requirements, a state-issued photo ID or valid passport is required to obtain building entry. Advanced registration is required.
This event is free and open to the public. Refreshments and pizza will be served.…
Added by Andrew Haas at 10:46am on October 30, 2018
ells on nurbs surfaces. It references GH_IO.dll, Grasshopper.dll and Rhinocommon.dll.
Custom Class : GS_Mesh
Custom Type : GHType_GSMesh : GH_Goo<GSMesh>
Custom Parameter : GHParam_GSMesh : GH_Param<GHType_GSMesh>
Now, i'm developing a set of structural analysis components to relax gridshells. Those components are grouped in a new project called "Marsupilami".
Naturally my components would eat GS_Mesh objects and relax them. My project references GH_IO.dll, Grasshopper.dll, Rhinocommon.dll and Gridshell.dll.
But I can't build my code because I get the following error, where I try to instantiate a GHType_GSMesh object :
Errorr 3 The type 'Grasshopper.Kernel.Types.GH_Goo`1<T0>' is defined in an assembly that is not referenced. You must add a reference to assembly 'Grasshopper, Version=1.0.0.20, Culture=neutral, PublicKeyToken=null'. C:\Documents and Settings\l.dupeloux.TESS\Mes documents\Dropbox\Dev\Marsupilami\1 - visual studio\Marsupilami\GHComponents\GHComponent_GSMeshRelax.cs 97 13 Marsupilami
I've checked many times but the assembly seems to be referenced in both projects (local copy = false) in the required version (1.0.0.20).
Do you have any idea how to solve this problem ?
Many Thanks
Lionel
…