ssimilating components from a large definition into a single custom scripted component (eventually to be made into a GHA).
As of now I have 6 identical components in a chain (one after the other) which have several inputs and outputs. Some inputs are from the same user-defined sources and some are outputs from the previous component in the chain. My goal was to combine them all into a single scripted component - which I've done - but the amount of time it takes to process the solution is huge (compared to having them all chained in a row).
When chained, each component only take 50 or 60 ms to compute (300-360 ms total). When all crammed into one component, it can take several seconds (this also depends on the amount of inputs, though).
My theory is that I've just done something less efficient / more stupid than the best scripting practices would call for (since it's a relatively new realm for me) - So this is what I ask: Is there a better way to script what I have scripted? I don't want to complicate things by posting my few hundred lines of code, so I'll simplify:
To combine these previously disparate scripted components, I:
Create a class with various properties: (I am using a class because I have several data types -planes, points, numbers- that I want to output as the result of a function)
Class exampleClass
public aProp
public bProp
public cProp
etc...
create a function with 6 inputs (which is basically exactly the same as a single scripted component):
exampleFunction(a,b,c,d,e,f)
inside the function solve for 6 variables based on inputs
aVar = some math
bVar = some more math
cVar = even more math
etc...
At the end of the function create an instance of exampleClass (and set properties equal to variables solved for in the function)
classInstance = exampleClass
classInstance.aProp = aVar
classInstance.bProp = bVar
classInstance.bProp = bVar
etc...
Finally set the return value of the function equal to the instance of the class
exampleFunction = classInstance
So that's the setup. Now I want to run the function 6 times so I do something like:
dim funtion01 = exampleFunction(a0,b0,c0,d0,e0,f0)
dim funtion02 = exampleFunction(a1,b1,c1,d1,e1,f1)
dim funtion03 = exampleFunction(a2,b2,c2,d2,e2,f2)
dim funtion04 = exampleFunction(a3,b3,c3,d3,e3,f3)
dim funtion05 = exampleFunction(a4,b4,c4,d4,e4,f4)
dim funtion06 = exampleFunction(a5,b5,c5,d5,e5,f5)
So that's it. Now I can access any of the results from any of the 6 functions.
This works exactly the way I'd like it to, but it takes many times longer to calculate than when this whole script is broken up into separate components (360 ms total vs. 3.4 seconds in one script).
Any ideas why this may be? Should I do something different to achieve the same desired result?
Thanks in advance, I hope that wasn't overly confusing.
-Brian Harms…
ulting topography, I just wanted it to be reasonably close so it looked appropriate as context. That sort of drives the rest of it (OSM).
Even though the earth is not truly a sphere, I treat it as one for the purposes of calculating distances in Elk. So the first step for both the SRTM and OSM translations is to figure out the length of one degree and use that number against the coordinates to determine the position in the XY plane.
Latitude:
The circumference of a circle is 2πr. The circumference of the earth is about 6371000m so you get about 40 million meters for the circumference. Further convert that to a distance per degree and you get around 111,194m or 364,812'. (PI * EarthRadius) / 180 gives you the degree length in meters and multiplying it by Y was just scaling it to feet. Since circumference is 2πr, another way to write the formula would be (2 * PI * EarthRadius) / 360.
Longitude:
Longitudinal lines converge at the poles so their distance at the equator is the same as latitude (111,194m per degree), but converges to 0 as it gets closer to either pole. Technically this means that the farther away from the equator you go the points should be slightly closer together. I'm just getting an average distance for the points, so I get the median latitude degree in order to determine the radius of the earth sphere at that distance.
Then you subtract the lower end of the domains from the CSV's longitude and latitude, and then multiply the resulting decimal number by the calculated lengths for a degree in longitude and latitude and those numbers are combined to be the X and Y coordinates of the points.
Hope this helps.
-Tim…
dMAC.gh license requesting utility now allows you to generate an automatic email embedding your data.
Robot Library:• New IRB4400(60) robot preset.• New IRB6400Rex(200) robot preset.• New IRB6620(150) robot preset.• New IRBT6004 track preset. • New Track Creator component.
Base Pack:• The Inverse Kinematics Solver now handles inputs for track positioners (linear external axis).• The Inverse Kinematics Solver now handles flip overrides to access alternative configurations of the elbow, of the wrist, or both.• New control in the right-click menu of the Inverse Kinematics Solver allowing to change the threshold for large reorientation analysis.• The Rapid Generator was outputing wrong confdata for axis with a rotation between +270 and +360°, this is solved.• The Rapid Generator was outputing wrong local rotation values for targets when a Work Object was used under certain conditions, this is solved.• The Rapid Generator is now outputing the declaration of the Work Object when it is different than WObj0.• New controls in the right-click menu of the RAPID Generator allowing to set custom precisions for coordinates and rotation values to be used in the code, in order to optimize the size of the program. • New control in the right-click menu of the RAPID Generator allowing to force the formating of the output for multi-robot setups.• New Track Position Solver component.• New External Axis Manager component.• New Signals Manager component.• New Flip Value List component.
Communication Pack:• The HAL To Controller component now allows to manage Digital Outputs (DO) and simulated Digital Inputs (DI) signals in real-time.• The OSC To HAL component is now compatible with remote digital signal management. • The OSC To HAL component is now automatically detecting the device (iPhone or iPad) you are using.• The TouchOSC layout has a new Digital I/Os management menu (2*15 channels on the iPad, 2*6 channels on the iPhone).…
izing strength/spring stiffness and even the unit of your 3DM file setting.
sometimes the same pattern that can be planarized in one file would stop working once something else is modified. and sometimes the force can't even planarize one single cell.
I think you can find some idea from the following post:
http://www.grasshopper3d.com/forum/topics/planar-polygons-by-using-kangaroo
'Reply by Daniel Piker on December 17, 2013 at 10:25am
Making the faces of a polygonal mesh planar is not always possible without dramatically changing the shape of either the polygons or the surface.
When the target surface has only positive Gaussian curvature it makes things somewhat easier, but the surface in your file also has regions of negative Gaussian curvature.
To approximate a surface of negative curvature with a discrete mesh, we need the angles around some of the vertices to sum to less than 360°. This is impossible to do in a mesh with 3 hexagons around each vertex without making some of these hexagons non-convex.
There are a few possible approaches, but I would say how to automatically cover an arbitrary surface with nicely shaped planar hexagons is still an unsolved problem.'
I have uploaded some test files for you to look at. …
inue our emergency aid efforts for Israel’s wounded soldiers during this war, as well as prepare for the aid needed after, we remain hopeful for peaceful days ahead. We pray for a swift recovery for all those injured and for the safe return of the missing and abducted individuals.
Beit Halochem is working closely with the Ministry of Defense to ensure all those who have been recently wounded are supported, visited and welcomed into the ranks of our Beit Halochem family.
A special 24-7 help line has been established for members experiencing emotional distress and trauma. “Check in calls” have been initiated to over 10,700 members living in Israel’s south and families are being assisted to evacuate from their homes near the Gaza border.
Beit Halochem needs your help in these difficult days. We call upon you, our friends in the USA, to support and honor our brave heroes in Israel.
With Your Help, We Can Make A Difference
It happens with lightning speed. There’s no time to think or react. A bullet whizzes through the air. A bomb explodes.
Everything goes black. After the initial silence, sirens scream, medics spring into action, helicopters whir overhead. And a young person, often barely 18, is
rushed to hospital. It is the way of life for soldiers in the Israel Defense Forces and for all Israelis. It is the nightmare they face every day.
After the surgeries and painful treatments, it is Beit Halochem that takes over – to heal, provide therapies, offer a comforting shoulder, lift a broken spirit. Your donations are needed to help support the ongoing rehabilitation of Israel’s Disabled Veterans. You can give them hope for recovery when you make a donation in honor or memory of a loved one. You may wish to use the following giving levels as a guide: $36 – $72 – $100 – $180 – $360 – $500 – $1000 – $1800 – $3600.
In the United States, FIDV–Beit Halochem, a not-for-profit, tax exempt [501(c)(3)], organization is the only authorized institution whose purpose is to facilitate the rehabilitation of disabled Israeli veterans at the state-of-the-art Beit Halochem centers in Israel, which for many become a kind of second home.
Contact -:
FIDV-Beit Halochem
1133 Broadway, Suite 318
New York, NY 10010
Tel: 212.689.3220
info@fidv.org
https://fidv.org/donate/…
思った感じになりません。
balls の代わりにplanarカーブを直接入れてみましたがエラーが出ます。
ファンクションにしてみたところ、forループので作った数値が反映されていません。
ファンクションのインスタンス?を出力していないと思い上記のようにしましたがエラーが出てしまいます。
以上の事から自分の認識が正しいのかよくわからなくなりました・・・
python自体の深いところをわかっているわけではないので余計こんがらがりました。
そこで、for b in ballsはどのような条件または使い方であれば使えるのでしょうか?
そして、上記のように別のオブジェクトに対しての使い方はどのようにすればできるのでしょうか?
2:同じファンクション内のdist = rs.Distance(self.pos,b.pos)についてですが
この文章も for b in balls によってbはBallのインスタンスであると定義?されたためb.posがbの位置であると分かるのでしょうか?
pythonは定義しなくても動いてしまうのでどのような時に使えるのか文章見ただけではよくわかりません・・・
大変細かいことかもしれませんが、よりpythonをしっかりと理解するためにも、どなたかわかる方ご教授いただけると幸いです。…
to do once I figured out how you use only a small portion of each of my generated curves to make the 360 degree Loft surface. I had a huge AHA! moment when I realized the complete Loft surface really only needs a small portion of the generated curves rotated around to form a closed (except for top & bottom) surface. That is a major new insight for me and I appreciate you pointing it out.
I also tweaked the Twist angle parameter a bit so the resulting positive and negative Twist surfaces, when combined, yielded a result that was closer to my original shape. This is when I discovered something very interesting.
When I baked/exported the result using just one of the 2 twisted surfaces I got an STL file that had no errors, that 3D Builder was able to simplify from a 37 MB file to a 3 MB file, and that sliced A-OK. But, when I combined the left and right twisted surfaces, I was back with my same set of problems: the exported STL file had many errors, could not be fixed, and did not slice properly.
I went back to my original layout that uses the complete set of generated curves to create the Loft surface and found I got exactly the same results - using only one twisted surface worked fine, but nothing worked when the left and right twisted surfaces were combined. By nothing I mean I tried all the standard methods (GH Join and Sunion, Rhino Solid/Union, Join, etc.) What I think this means is that the Loft surface behaves the same, and apparently is the same, regardless if it is generated by rotating strips or by using complete closed curves.
Furthermore, I am guessing the problems with the combined/exported STL file made from both left and right twisted surfaces has to do with overlapping/coincident parts of each one - like the top & bottom planar surfaces and some of the wiggly parts.
If I am correct about this then it suggests to me that there is some sort of glitch in Rhino's STL Export function. This is surprising to me since I though an STL file only paid attention to the external shape of thngs,and did not know or care about any inside stuff. Of course this is all conjecture on my part, but at least for now seems it will be impossible for me to actually print the double-twisted geometry.…
Added by Birk Binnard at 3:52pm on September 23, 2016
he process. The last one is there because fixing it would cause another problem, which we feel is more serious. Solutions may well be forthcoming in the future though.
1. Grasshopper curves and points are drawn more towards the camera than they really are. This is a conscious decision. Often Rhino geometry and Grasshopper geometry exist in the same place. If we would draw the Grasshopper preview in place, then there's no telling whether you'd see the Rhino curve or the Grasshopper curve. We feel it's important that you always see the Grasshopper curve on top. This is why we draw all curves and points slightly towards the camera. However we don't do this for meshes. This results in something akin to the image below. The eye represents the location of the viewport camera, the shaded box represents the actual location of the geometry and all the thick black lines represent the edges of the geometry moved towards the camera. As you can see, the red lines will be visible, even though they should be behind the shaded box. This effect can get very strong when the camera is close to some geometry relative to the size of the boundingbox of all geometry.
2. Wires behind the camera are sometimes visible. This is a bug I don't know how to solve. We'll get around to it eventually. When an object is behind the camera the display transform sometimes makes it visible in front of the camera in some weird inverted perspective mode.
3. Meshes are not z-sorted prior to display. This means that the order in which they are drawn is not back-to-front, but fairly arbitrary. This means that a transparent mesh may appear to punch a hole in the mesh behind it. If this is annoying you to no end, you can use Ctrl+F on the Grasshopper components that contain the meshes that are punching holes and then press F5 to recompute. The draw order should now be different. Of course sometimes it will only 'fix' it for a specific camera angle.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…