being driven by the wii nunchuck... But, here's my issue. I tried it first by having the output from the listener be a 6-digit number... so, I'm using the (CInt(Val(StoredValue))) command and it's writing out 181130... and I can easily split it up selecting the Left(x,3) or Right(x,3)... I first rant that number through a Format("{0:000000}",x) so that even if one of the accx or accy numbers were a 2-digit number (so my overall number would only have 5-digits)... with this Format function... I'm always assured a 6-digit number. And this method works... except...
If the first group of numbers coming in only has 2-digits... So, lets say the accelerometer read out of the first one (accx) is 89. Let's say the accy read out is 119. So, when I run this through the Format function to make it have at least 6 digits, my number now reads 011989. So, if I were to take the first three numbers on the right, my read out would be 989... which is much higher than my expected (60-180 range that is really coming over the Serial Port)... So, I'm back to where I started... in that I need to figure out a better way to split up the data.
Which brings me to your method. I tried it as well... in fact, I added a comma in the serial readout, so the string coming out of the listener reads 89,119. So, I can use your trick to go look for a delimeter and then read to the left and right a certain number of digits... The problem I still have is that the data going into the function is a string, and thus even if I split the 3 digits to the right of the comma out (so, my output says 119)... it's still a string, and my number parameter is still red. In your picture above, was your original 181 130 a number or a string? My guess is that it was understood as a number, because your number parameters at the end are accepting the value. But, in my case... I'm still stuck with the inability to convert a string to a number... Does this make sense? And are their any other workarounds?…
Added by Andy Payne at 9:42am on September 3, 2009
the 'patch' command which I imported from Rhino. The script runs with no errors but the patched surface does not appear in my model.
If anyone can resolve this issue or tell me how I can create such a surface using another method, I will be grateful.
Below is a copy of the script that I am working on:
import rhinoscriptsyntax as rsimport Rhinoimport scriptcontextfrom Rhino.Collections import CurveList
p1 = rs.PointCoordinates("e798e82a-5abb-468e-8c33-c39e1e0d7180")p2 = rs.PointCoordinates("820afac5-c594-42ea-8723-f3646019b0af")p3 = rs.PointCoordinates("41e3c0aa-30ad-466f-b88b-3be98f67a485")p4 = rs.PointCoordinates("3e0857c5-b463-49aa-8549-0b11f847b226")p5 = rs.PointCoordinates("19d946ae-b416-4f9e-939c-ed9e31fbe8e7")p6 = rs.PointCoordinates("65342367-a297-4536-8bff-5935ab500a69")p7 = rs.PointCoordinates("70793197-e1de-4b4b-9be1-38ebb9fe5dd5")p8 = rs.PointCoordinates("4be53db2-98ad-4b8b-80de-1ca055bf63a4")p9 = rs.PointCoordinates("cc58b791-ccb3-41d7-ac2c-2b64f83d0210")p10 = rs.PointCoordinates("bee35659-25ec-42c8-ae3f-65d053cdc6f7")
points1 = p1, p3, p5, p7, p9, p1points2 = p2, p4, p6, p8, p10, p2
c1 = rs.coercecurve(rs.AddLine(p1, p3))c2 = rs.coercecurve(rs.AddLine(p3, p5))c3 = rs.coercecurve(rs.AddLine(p5, p7))c4 = rs.coercecurve(rs.AddLine(p7, p9))c5 = rs.coercecurve(rs.AddLine(p9, p1))
curves = c1, c2, c3, c4, c5
list1 = CurveList(curves)
Srf = Rhino.Geometry.Brep.CreatePatch(list1, 10, 10, 5)…
ould be very happy!
It works with "straight" loft option, but I need it as a smooth loft.
In the GH file you will also see similar lines that can be lofted.... I dont know why.
Thank you very much!
Jakob…
answer further on Friday.
The "ghdoc" variable and rhinoscriptsyntaxThe ghdoc variable is provided by the component if you select it as "target".You might ask yourself: "why do we need it"?Its use comes from the very design of the established RhinoScript library. This library is imperative, which means it is build from a set of procedures or functions that act on various geometrical types. Additionally, there is one level of indirection: most of the time, the user does not work with the geometry itself in the variable, but rather with Guid of geometry that is present in a document. This is exactly what ghdoc is: it is the document that the RhinoScript library always implicitly targets with all AddSomething() calls (for example, AddLine()).
Based on this comment...RhinoScript use within GhPython may be less idealThat comment is from a previous version of this component that did not have the ghdoc yet.With the ghdoc variable, the standard Rhino document target of RhinoScript is replaced, therefore we can use Grasshopper while leaving the Rhino document unchanged. This saves uncountable Undo's, and makes it easy to structure ideas through the definition graph
...is the rhinoscriptsyntax target irrelevant if using solely RhinoCommon classesYes. If you create class instances (objects), you will need to create also your own collection objects to store them (mostly lists, trees). You can imagine the ghdoc as being an alternative to them, just that you do not access data by index (number), but by Guid. So you can use the RhinoScript or the RhinoCommon libraries independently or mix them. The RhinoScript implementation in Rhino is open-source and is all written in RhinoCommon. Also the ghdoc implementation is open-source, and is here.
RhinoScript and/or RhinoCommon objects which are not recognized as valid Grasshopper geometryYes, sure, Grasshopper handles only a portion of all available types. Basically, unhandled types are all the types that do not exists in the 'Params' tab. For example, there is no textdot and no leader, so on line 149 there is a throw statement and all TextDot calls (about line 350) are commented out. When/if Grasshopper one day will support these types, these calls will be implemented.
DataTreeHere is a small sample. However, I think that 80% of the times it is not necessary to program for DataTrees, as the logic itself can be applied per-list and Grasshopper handles list-iteration.
I hope this helps,
- Giulio_______________giulio@mcneel.comMcNeel Europe…
ger at the scale of rooms, walls and atria, but that of cells, grains and vapour droplets. Rather than the flow of people, services, or construction schedules, the focus becomes the flow of light, vapour, molecular vibrations and growth schedules: design from the inside out.
The sg2012 challenge, Material Intensities, is intended to dissolve our notion of the built environment as inert constructions enclosing physically sealed spaces. Spaces and boundaries are abundant with vibration, fluctuating intensities, shifting gradients and flows. The materials that define them are in a continual state of becoming: a dance of energy and information.Material potential is defined by multiple properties: acoustical, chemical, electrical, environmental, magnetic, manufacturing, mechanical, optical, radiological, sensorial, and thermal. The challenge for sg2012 Material Intensities is to consider material economy when creating environments, micro-climates and contexts congenial for social interaction, activities and organisation. This challenge calls for design innovation and dialogue between disciplines and responsibilities.sg2010 Working Prototypes strove to emancipate digital design from the hard drive by moving from the virtual to the actual in wrestling with the tangible world of physical fabrication. sg2011 Building the Invisible focused on informing digital design with real world data. sg2012 Material Intensities strives to energise our digital prototypes and infuse them with material behaviour. They have the potential to become rich simulations informed by the material dynamics, chemical composition, energy flows, force fields and environmental conditions that feed back into the design process.
More information can be found at http://www.smartgeometry.org
sg2012 take place at Rensselaer Polytechnic Institute, Troy, in upstate New York from 19-24 March 2012. The Workshop and Conference will be a gathering of the global community of innovators and pioneers in the fields of architecture, design and engineering.
The event will be in two parts, a four day Workshop 19-22 March, and a public conference beginning with Talkshop 23 March, followed by a Symposium 24 March. The event follows the format of the highly successful preceding events sg2010 Barcelona and sg2011 Copenhagen.…
ort and export from the images below and also from the HELP file of DB in attachments (Page 71: Importing Geometric Data; Page 78-80: Import 3 - D CAD Data). In their HELP file, they mention about "import geometric data".
However, regarding the input of schedules, loads, constructions and etc., DB normally uses "Component " and "Template" (Page 29: Templates And Components; Page 591: Templates; Page 533: Components). "Templates" are databases of typical generic data, including Activity templates, Construction templates, Glazing templates, Facade templates, HVAC templates, Location Templates, and etc. "Component " are databases of individual data items (e.g. a construction type, material, window pane).
Both "Component " and "Template" are allowed to be imported and exported by using "Import / Export library data" command (.ddf format - DB Database File; Page 734: Import Components/Templates, Export Components/Templates). DB also allows us to build up our own libraries of templates and components (Page 731: Library Management; Page 733: Template Library Management).
In order to import both geometric information and other information related to schedules, loads, constructions and etc. from GH to BD, we supposed the following two ways:
1. GH(HB+GB) --> gbXML (both geometric and "Component " and "Template" information) --> DB
This is the way we most prefer. We did see information related to schedules, loads, constructions encoded in the gbXML file generated by GB, but still do not know the reason why DB did not take this information (I also mentioned this in Q6 within the gh file). We assume this might because the gbXML file we create encodes the schedules based on a different template / schema than the one DB expects. We also post this question to the DB forum for help.
(http://www.designbuilder.co.uk/component/option,com_forum/Itemid,25/page,viewtopic/p,13755/#13755)
2. GH(HB+GB) --> gbXML (geometric information only) + .ddf ("Component " and "Template" information only) --> DB
If the first way doesn't work and DB only takes geometric information from the gbXML, then we might think of the other way - generating the .ddf files from GH(HB+GB) to pass the schedule, load and construction information to DB.
I was wondering if it is feasible for HB and GB to have this function? And what is your suggestion to achieve this?
In addition, we notice that DB can export XML files (not gbXML), so we are trying to figure out if DB also accepts / reads the XML file. If so, we might be able to convert the gbXML (with both geometric and schedule information) to XML. What do you think about that?
Thank you again for all your help!
Best,
Ding
DB import
DB export
Template libraries
Component libraries
…
el/aluminum or SS if you are rich). For aluminum and on-site welding you'll need Argon. OK welding destroys galvanic protection ... but who's counting? (besides nothing lasts for ever, he he).
The skin ... well there's no water tightness requirements thus weld (or spot) linear, say, 5/30mm steel "Bright Flats" either across the "top" of a given tube or both sides.
http://steelandtube.co.nz/product/ste/engineering-steels/bright-bar...
http://www.gspsteelprofiles.com/catalogPages/coldDrawingSteel.php?CategoryID=81&ItemID=1431
These 5/30 linear things make us the "niche" (per panel) for the transparent/opaque stuff: Avoid glass in this occasion: use 5/6/8 mm massif polycarbonate that is flexible and can tolerate non planarity rather well (more than probable if the welding is done on site). Keep in mind the sheet size (see link) in order to avoid waste material. Use some fancy Allen/Torx screws visible from behind (WOW) and that's all: case closed.
http://www.plastix.com.au/images/polycarbonate.pdf
http://www.plastics.bayer.com/en/Products/Makrolon.aspx
http://www.glazinginnovations.co.uk/technical-structural-glazing.php
http://www.palram.com/Architecture
http://www.trespa.com/
best, Peter …
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
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
…