orking in Grasshoper v0.9.00xx (I tried, 9.0010 and 9.0014)
If I try this code
------------------------------------------------------------------------------
System.Globalization.CultureInfo oldCI = new System.Globalization.CultureInfo("en-US");
Object objExcel;
objExcel = System.Runtime.InteropServices.Marshal.GetActiveObject("Excel.Application");
objExcel.Cells(2, 1).Value = "titleA";
------------------------------------------------------------------------------
I see, the message
" Error: 'object' does not contain a definition for 'Worksheets' (line 95) "
Line 95 is the last one < objExcel.Cells(2, 1).Value = "titleA"; >
I've also tried,
Microsoft.Office.Interop.Excel.Application xlApp;xlApp = (Microsoft.Office.Interop.Excel.Application) System.Runtime.InteropServices.Marshal.GetActiveObject("Excel.Application");
But GH C# says
Error: The type or namespace name 'Office' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?) (line 89)
What did I wrong??
…
tion the points of each panel. Using .Branch(i) I can, in a loop, retrieve the element from the tree I have input.
My problem is when I want to OUTPUT a tree, I got stuck with the ArgymentTypeException telling me that the tree type expected and what I am feeding into it are not consistent:
Runtime error (ArgumentTypeException): expected IEnumerable[LineCurve], got LineCurve
So I can manage to export the elements flatten into a list but not as a tree. How can I do in this scenario (and in general with different types of geometries)? What is IEnumerable about?
Thanks a Lot!
V.
This is the script:
import rhinoscriptsyntax as rsimport clrclr.AddReference("Grasshopper")from Grasshopper.Kernel.Data import GH_Pathfrom Grasshopper import DataTreeimport Rhino
b = []
tree = DataTree[Rhino.Geometry.LineCurve]()
for i in range(0,y): a = (x.Branch(i)) branchList = x.Branch(i) branchPath = x.Path(i) line = rs.AddLine(a[0],a[2]) b.append(line) tree.AddRange(rs.coercecurve(line),branchPath)
…
reover, i enter the panel to "manually" write the rest of the values, but it doesn't allow for any extra lines, it looks like it is full. I tried different values, and it seems it can paste all 8760 values only if they are one-digit numbers. Anyone know why? P.S. they are pasted from excel.
2. The "Create CSV Schedules" doesn't function or i am doing something wrong. I want to have a list of 8760 values, that correspond to whether the heating system is on or not for every hour of the year. So i have a multi-line panel of values of either 1 or 0. I connect that multi-line panel to the "values" input of the "Create CSV Schedules" component as shown in the snapshot, but it seems that the values (1 or 0) are considered as Temperature values, because the annual heating output in kWh is too low. That happens even though the default unit is "dimensionless''. Did i do something wrong?
3. I am inputting a setpoint temperature in "Set EP Thresholds" component, and from the results i get, i am guessing it is a setpoint temperature according to the room air temperature. I would like to have that setpoint according to the operative temperature, so when i set it to 21, that means that the heating turns on when the operative temperature drops below 21, is this possible?…
Added by Iason Bournas at 10:49am on February 4, 2016
Hooke’s Law;
ε = ΔL / L
in which ΔL is determined by taking the difference between ‘preferable’ and old length. In the attached simplified model this works fine (TEST). However, in the more complex RF model, also attached, this doesn’t work.
All deformed lines in the model should be linear or as straight as possible after the ‘form finding’ procedure. The right eccentricity length should be found by shortening / lengthening of all lines / beams. I’m trying to accomplish this using different beam stiffness’s. Is this the right approach? Or do you have another idea how I can accomplish the optimized eccentricity line lengths and fix the model using Karamba?
Regards,
Tom GodthelpThe RF model
…
ge, and some times I managed to get the drape to "fall through" a sphere.So I figured there must be some factors to consider for it to be "stable", the density of the points but also the density of the collision-mesh.
I found out the primitive sphere just work excellently well for colliding with just about anything, but from there it is all downhill. I started with a cylinder next because it seemed such a fitting shape for a pulley simulation, however, points fell right through whatever the density of the points in the line. When subdividing the cylinder however, it seems to work perfectly. My thoughts were that since the cylinders have vertices only on the sides, a line would not hit any mesh points? (is that even required?)Anyway so I'm not sure that was it, but I was happy that it worked.
Now a pulley in my case also needs sides, to keep the line from slipping off if angled. I made a custom surface that was meshed, but regardless of the density, nothing would collide with it.So I made one in 3dsmax, a nice elegant mesh topology, same result, just fell through.Then I recalled the spheres working so excellently, so I made one with a sphere in the middle and two bigger ones to the side which were a bit squashed in 1-axis. This worked perfectly with a line going over it with only vertical loads. As soon as any horizontal load was applied, it would slip in between two spheres.I realized a brilliant thing to do was to use a torus and run the wire through that, always works! I used a component I think from lunchbox, that makes a torus, but meshing it resulting in zero collisions.The thoughts went a bit crazy here but led me to my best one so far, again I introduced the damn spheres because magically they seem to be the only thing working consistently well so far. So I made a circle and populated it with spheres and then mesh unioned them. This works pretty well, except when moving it sometimes, it suddenly loses it's ability to collide somehow.So to me, the whole process has been more like alchemy than science, funny but frustrating too. What were your experiences? Does someone know what are the actual parameters that make it work? The inner workings? Why does it sometimes refuse to collide?I recognize the 'slipping/fallin halfway through' vs. 'refusing to collide', the first seems to be a density issue, the other I have no clue.
Any help, insight, greatly appreciated.…
ched.
I'm fairly well versed at using python in Rhino both with rhinoscriptsyntax and RhinoCommon, but I'm hitting a wall with using it in GH.
In the example definition a line is added to the rhino doc, but when run (toggled true), the line doesn't become actual geometry in the file. Also, when i try baking the python object, nothing happens, which i assume is because there isn't actually any geometry assigned to come out of the python object's outputs. I can, however, add the line by baking from the line parameter object itself (but the GUID of this line in rhino is not the same as what the python object print says it should be). I guess im confused because the info-graphic in the above post suggests that adding real, selectable Rhino.docobjects can be done through python scripting.
So my first question is this: Is it possible to script the baking process from the python object itself or is baking completely under the control of the GH plugin? Is "baking" the only way to get real, editable geometry out of GH?
My second question relates to the application of these principles:
I have a GH definition set up to generate some geometry based on RhinoDoc geometry whose GUIDS I have stored in an excel file (i can send you the definition if you'd like, but the problem should be comprehensible enough without it). I want to step through different sets of this geometry and bake the results. Basically, i want to bake one set of driving geometry, increment an index variable to choose the next set from the excel file, and bake again, etc. I could do this by setting up a slider and a "bake" button, but I would like to be able to automate the process.
I have tried setting up a python object to do something like this:
for i in range(15):
#set output a to i and feed this to select a list item
#set output b to True to trigger a bake object
As you can probably guess the output of the python object just ends up at a=15 and b=true and bakes the last set of geometry but none of the rest. Why is this, and is it possible to gain more precise control over the state of the solution and baking from the python scripting object?
In addition, how do the rhinoscriptsyntax methods affect things in the different scriptcontexts of rhino_doc and ghdoc?…
is created for each point (25 paths, N=1 for each) which is feed into [Pull Point] for the pull geometry [G].
Correspondingly for the 4 source points a branch is created for each point and duplicated 25 times (4 paths, N=25 for each). This tree then needs to be inverted with [Path Mapper] so the structure will correspond to the format of the pull geometry. The mapping {A;B;C}(i) > {i}(B) produces (25 paths, N=4 for each) the structure to feed into the search point [P].
The [Pull Point] boolean toggle [C] needs to get set to False to obtain all the distances between all search and pull points (4 x 25 = 100 values).
Simultaneously there is also an index being created to correspond to the list of the 4 source points. This index is the integers 0 to 3 which are branched and inverted similar to the source points (25 paths, N=4 for each).
The distance output [D] from [Pull Point] is then sorted synchronously with the source point index for each branch. From the following screengrab branch {0;0} corresponds to a point in the 5 x 5 grid and the shortest distance between that point and a referenced source point index is 5.261. The index of the referenced source point is 3.
For each following sorted branch the first sorted index value will correspond to the closest source point (first [List Item] shown). This index value is then used to select from the original list of duplicated and inverted points and this is done for each of the 25 branches (second List Item shown).
Draw a line or whatever an away we go!…
cause of this I haven't understood your C# blocks correctly.
Maybe this will help, until Giulio or some other expert arrive:
import Systemimport Rhinoimport clrPC = Rhino.Geometry.PointCloud()PC.AddRange(Pts)n = Vector3d.ZAxisif VP == None: BBox = PC.GetBoundingBox(False) BoundingB = Rhino.Geometry.Box(BBox) VP = BoundingB.PointAt(0.5, 0.5, 0.5) VP.Z = BoundingB.Z.T1 * 100NP = clr.StrongBox[Rhino.Geometry.Plane]()Dev = clr.StrongBox[System.Double]()Normals = []for point in Pts: Neighbors = [pt for pt in Pts if (V>= V.DistanceTo(point)) and (V.DistanceTo(point) < D)] Plane.FitPlaneToPoints(Neighbors, NP, Dev) if Dev > MD: n = NP.Normal if n*(VP-point) > 0: Normals.append(n) else: Normals.append(-n)A = Normals
On SharpDevelop, I tried using it for VB.NET to Python some time ago, and was not satisfied with results (maybe something changed from 3.1 version). Be sure to put your C# code in a class before trying to convert it.
Also, it would be nice if you would edit your initial post (upper right angle -> Options -> Edit discussion) and change the topic category (move it to the VB, C# and Python Coding category). Thanks.…
lane.WorldXY when making "parts" ... especially if these are used for defining instance definitions (blocks in plain English).
Notify if you need the proper/"pro" way to do that using ONE object transformed N times instead of cloning the object (the "window frame") N times: this is what the Orient component does and this is the reason that is so slow (Blocks boost performance by a factor of 100 making the def almost a "real-time" one). Note: Morph Methods work only against Geometry Base types ... thus this approach is useless when non linear transformations are in the pipe line.
Notify if you need a "variation" for twisted towers (there ... the disabled Morph component MAY serve the scope [but it's the totally wrong way to do it in real-life]).
This:
is a rather "compact" way to "skip" randomly items from trees (whilst maintaining the structure: examine the paths ...
... AFTER the massacre to see it in action ["some" paths are MIA, he he]). The components that you've mention work on Lists.
This:
does some things not available as native components.
…
rimitive way to do business) imposes serious limitations with regard the topology of the line graph on duty. I do hope that you understand what I'm talking about. DO NOT use this attached against graphs made via proximity 3d and the likes.
2. No clash detection (via trigonometry) is included. Either instance definitions.
3. No values check function is included: this is a rather complex thing when we do real-life "geodetic" trusses.
4. For the critical part: the linkage ... well you have 3 choices (see comments inside). Modelling a parametric linkage in GH/Rhino is 100% out of question. The only thing that you can do is use one as instance definition and put it in a myriad of places. DO NOT attempt to do that the classic way (Orient component).
5. Go to the model shops ask for a big radio controlled car/buggy and observe what a mini ball pivot linkage is (the red freaky thingy):
May the Force (the dark option) be with you.
Suggestion: abandon ship.
best, Lord of Darkness…