algorithmic modeling for Rhino

Search Results - 【p26.pw】Googleクイックインデックス社のWebサイトをどうするか.260214075605

Event: DIGITALMED WORKSHOP IV EDITION SMART: INTERACTION BETWEEN PEOPLE /CITIES/ENVIRONMENT: bject of this edition focuses on the investigation of interactions between the environment and the human being, made through objects, mechanisms and architectures able to interact with who makes use of them. The aim of digitalMed IV is drawing a catalogue of projects/prototypes to insert them in an urban context, and to outline new future-cities profile. PURPOSES AND TERMS: The digitalMed Summer School IV edition aims to organize the flows of information, in which the city is absorbed, to adapt projects and to make them useful, no invasives, and suitable to establish an information exchange. The concepts of slow cities and smart cities are directed by all types procedures, from immaterial to materia, from information to the built. This is the iter that we will follow to reinvent the relationship between man, environment and cities. Through learning by-doing educational procedure, participants will acquire not only new metodologies and means, but also concrete cases where testing these ones. In this way, new acquired information won’t remain simple educational exercises, but will be notable elements in the portfolio participants. TOPICS: The planning approach of digitalMed Summer School IV edition will supply to participants all the technic knowledges and theoretical bases in order to work. The first days of workshop will focus on the outline of a shared vocabulary that allows to work from shared meanings. This phase is characterized by subjects occurring in the contemporary architecture such as computational design, digital fabrication and data driven, then systems, like Arduino, which allow the interaction with objects, and fields like permaculture and social innovation that nowadays contribute to the realignment of environment and city’ ideas. The participants will have the opportunity to learn the use of software for the parametric planning, like Grasshopper, and to test interactions between real information and virtual data (and viceversa) through the use of Arduino. PREREQUISITES: The workshop is open both to the students and to the professionals. It needs a basic knowledge of Rhinoceros 3D program. All the participants have to bring their own laptop. The programs for installing will be communicated during the registration act. HOW TO REGISTER: To register to the Summer School DigitalMed 2013 you must send an e-mail to info@medaarch.com, with the object: “Iscrizione DIGITALMED2013”. The mail has to contain: Name; surname; profession; telephone; e-mail. After the reception of the above-mentioned e-mail, the participants will be contacted by phone, as well as by e-mail, to be informed about payment methods Registrations are to be construed when the payment will be effective. DEADLINE: Registrations to the workshop close on July 19 h18:00. INFO: Organizational Segretary digitalMed IV Dott.ssa Francesca Luciano Web site: www.medaarch.com e-mail: info@medaarch.com tel : +39 392 5149075 fb: mediterranean Fab Lab tw: @medfablab …; Added by Francesca Luciano at 7:00am on July 11, 2013

Comment on: Topic 'Mcr influenced by BklLenZ': buckling length considered about the major axis strut buckling bklLen_Z = buckling length considered about the minor axis strut buckling bklLen_LT = buckling length considered in lateral torsional buckling What looks to be the case is: bklLen_y = buckling length considered about the major axis bklLen_z = buckling length considered about the minor axis and lateral torsional buckling bklyLen_LT = buckling length considered for warping in lateral torsional buckling I don't think there is anything intrinsically wrong with the use of bklLen_Z in this way, or the definition of the value used in bklLen_LT, but the name of bklLen_LT suggested something different to me. Background below: M_cr is calculated by a closed form analytical solution to the lateral torsional buckling problem, i.e. it is not a code dependent expression so easy to compare between the code and other documents: The first term in the square root term in the C++ is: SQR(lk_z/lk_LT)*Cw/Iz Which is the square of the ratio of minor axis buckling and lateral torsion buckling effective lengths inputs, multiplied by the ratio of the warping and minor axis bending constants of the section. In SN003b-EN-EU (https://www.steelconstruction.info/File:SN003b.pdf) expression (1) the corresponding term is SQR(k/k_w)*Cw/Iz (In fact SN003b calls Cw 'Iw' but I have substituted above to aid the comparison). Where: k = effective length factor to end rotation on plan. Which is analogous to the minor axis effective length in strut buckling. k_w = effective length to end warping. Usually taken as 1. So Karamba takes the input value of Bkl_LenLT to be the effective length specifically for warping of the section, as: SQR(lk_z/lk_LT) = SQR([k*L]/[k_w*L]) = SQR(k/k_w) (I originally thought it was the effective length for end rotation on plan.) Apart from naming/understanding of how the inputs are used, I could only see a problem with this approach if there were a situation where the minor axis strut buckling effective length was not equal to the effective length for lateral torsional buckling. I could think of the following situations: The lateral restraint force is related to compression in the section. A (rare?) situation could be where the lateral restraint system has sufficient strength to provide lateral restraint against lateral torsional buckling, but not the higher restraint force of strut buckling about the minor axis. This feels like quite a contrived situation and I can't think of a practical example. Where lateral strut buckling restraint is provided to the beam by connection to the web, which is less effective at restraining the top flange against lateral torsional buckling. In this situation you may want/need to define separate a minor axis strut buckling and lateral torsional buckling effective lengths. Where the lateral torsional buckling effective length is the lk_z value in the calculation. This isn't currently possible. Neither of the two situations apply to what I am currently looking at, so now I understand how bklLen_LT is used I can work around that!…; Added by Nick Simpson to Karamba3D at 3:47am on September 19, 2019

Blog Post: Form Finding Strategies_Milano 27>29 Maggio 2014

Added by Arturo Tedeschi at 6:00pm on April 14, 2014

Blog Post: ECOLOGIC PATTERNS | CORSO AVANZATO GRASSHOPPER | ROMA | ISCRIZIONI PROROGATE: ________________________________________________________________________

ECOLOGIC PATTERNS | GRASSHOPPER + PLUG…; Added by Arturo Tedeschi at 8:44am on April 25, 2012

Blog Post: Tong Zi Dan: Tong Zi Dan is a series of generatively designed vases made from dental gypsum.

The initial egg design gets randomly populated by a cloud of points which form…; Added by responsive design studio at 12:54am on January 26, 2013

Blog Post: Join StructureCraft's Computational Design team! - Vancouver, Canada

Come join North America’s premier timber engineering and construction company!

StructureCraft specializes in the structural engineering,…

Added by Lucas Epp at 9:36pm on May 2, 2019

Blog Post: Basic lotto Strategies of 58 Lotto: Is there a method to winning the lottery or is it all a matter of luck? this can be one among the foremost frequent queries asked by those that play the lottery. will having a mathematical system…; Added by Jay Rocket at 2:08am on May 30, 2016

Comment on: Topic 'How to Marshal a variable sized array of ON_3dPoint to C#': _1 = resZ+1; /*if((resX_1)*(resY_1)*(resZ_1) != sizeof(data) / sizeof(data[0])) { *outNum = 0; return NULL; }*/ int sliceXY = (resX_1)*(resY_1); double intervalX = 1.0/resX; double intervalY = 1.0/resY; double intervalZ = 1.0/resZ; ON_BoundingBox box = ON_BoundingBox(*minCorner,*maxCorner); ON_Box refBox = ON_Box(box); //Get corners of a single voxel ON_3dPoint corners[8]; corners[0] = refBox.PointAt(0.0,0.0,0.0); corners[1] = refBox.PointAt(intervalX,0.0,0.0); corners[2] = refBox.PointAt(intervalX,intervalY,0.0); corners[3] = refBox.PointAt(0.0,intervalY,0.0); corners[4] = refBox.PointAt(0.0,0.0,intervalZ); corners[5] = refBox.PointAt(intervalX,0.0,intervalZ); corners[6] = refBox.PointAt(intervalX,intervalY,intervalZ); corners[7] = refBox.PointAt(0.0,intervalY,intervalZ); double d[8]; ON_3dPoint intersectionPoints[16]; int minCornerIndex= 0; vector<ON_3dPoint> pts; for (int z = 0; z < resZ; z++) { for (int y = 0; y < resY; y++) { for (int x = 0; x < resX; x++) { minCornerIndex = z * sliceXY + y * resX_1 + x; d[0] = data[minCornerIndex]; d[1] = data[minCornerIndex + 1]; d[2] = data[minCornerIndex + 1 + resX_1]; d[3] = data[minCornerIndex + resX_1]; d[4] = data[minCornerIndex + sliceXY]; d[5] = data[minCornerIndex + 1 + sliceXY]; d[6] = data[minCornerIndex + 1 + resX_1 + sliceXY]; d[7] = data[minCornerIndex + resX_1 + sliceXY]; ON_3dVector translate = refBox.PointAt(x * intervalX, y * intervalY, z * intervalZ) - corners[0]; int num = VoxelBox::GetFaces(corners, d, iso, intersectionPoints); if (num > 0) { for (int i = 0; i < num; i += 3) { pts.push_back(ON_3dPoint(intersectionPoints[i].x + translate.x, intersectionPoints[i].y + translate.y, intersectionPoints[i].z + translate.z)); pts.push_back(ON_3dPoint(intersectionPoints[i + 1].x + translate.x, intersectionPoints[i + 1].y + translate.y, intersectionPoints[i + 1].z + translate.z)); pts.push_back(ON_3dPoint(intersectionPoints[i + 2].x + translate.x, intersectionPoints[i + 2].y + translate.y, intersectionPoints[i + 2].z + translate.z)); *outNum += 3; } } } } } ON_3dPoint* result = new ON_3dPoint[pts.size()](); for(unsigned int i =0;i<pts.size();i++) { result[i].Set(pts[i].x,pts[i].y,pts[i].z); } return result; } I think it's slow in tow places. 1. using vector<> to hold all the points first, then copy them to the array. 2. in c#, List<double> .ToArray The first time I tested the code in Grasshopper, a warning "can''t find entry point blahblah..." came up. Then I did some google, used extern "C"__declspec(dllexport) and a .DEF file. If more code is added in, updating the .DEF file manually will be annoying. How is RhinoCommon manage all the exported functions? …; Added by Ian Chan at 3:55am on October 27, 2012

Comment on: Topic '30 steps to heaven (i.e. hell)': efied when confronted by your elevated thinking and ability. I (rather obviously) fully support your position, however I think the upset expressed by individuals on this post is valid. They are not on your level. They never will be. They probably won't ever need to be. And that's why you run your own business (let's use American Sniper analogy: you're the sheepdog) and they're the sheep - they're skilled people, but require a safe environment within which they can work. Without them you wouldn't be able to run a successful business. Without you they wouldn't have jobs. It's a symbiotic relationship; and please, anyone reading this, I'm not saying this to be provocative, it's just the way the world goes round. Think about the leaders of Google, Apple, Tesla, then re-read the above; it should provide solace to anyone struggling to accept that there are minds out there far greater than their own. Anyone with real experience in office will know that Peter is making an irrefutably valid point; any building project, even remotely advanced - and like Peter I am making my argument strictly from the perspective of real-world design and delivery of a building project - requires a robust tool to deliver. Utilisation of a computational design tool will invariably warrant some sort of intervention to that tool that supports the needs of the project, namely: coding. I have argued before that without this intervention the designer is then restricted to "prepackaged components that could potentially kill off a novel design solution". That said, the use of GH natively for such endeavours will always suffer this fate, not unless the scheme utilising the tool is largely simplistic. It is not an AEC tool. The paradigm shift in the AEC industries to BIM means Rhino and GH are going to be defunct if they fail to evolve. I'm confident they will, but clearly these tools will never be primary design tools. Dynamo is an interesting one to bring up; I predicted a while back that GH was the "Betamax of the parametric world". The fact that Dynamo plugs into Revit seamlessly and that increasingly, Revit is taking a stranglehold on the market, means that there may be some truth in my prediction. Admittedly, it still has a long way to go before Dynamo or Revit is anywhere near Rhino/GH. A surface modeller with a brilliant algorithm editor (ie GH) has its uses, but ultimately it could find itself wiped out by the prevalence of BIM authoring tools, the associated government legislation, and the desire to utilise modern technology for design realisation. Grasshopper is a tool geared largely towards students - it's colourful, pretty, engaging, "easy to use" (a fallacy up there with man-made climate change - ask the sheepdog if you don't understand why) and has successfully opened up a whole new world to a generation of designers (rue the twisty towers, voronoi, hexagonal cladding, circle packing and 'wallaby'). But equally when these students graduate - as Peter points out - they then use GH for live project work and therein lies the problem. Of course this doesn't cover all cases, but nevertheless, a failure to understand the demands of professional practice - a disregard to broadening ones horizons - has the potential to lead to a catastrophic brain-drain for the built environment and engineering. Why not embrace the opinions of others (Peters) who have identified this and wish to enlighten? But then this forum never has been democratic, I know it all too well; any opinion at odds to the collective mass gets shunned, accused of 'trolling', and vilified. In conclusion, Grasshopper can only be used for project delivery with the aid of coding. I closely observe many (only decent) building projects that have used GH for project delivery and it's the same recurring theme: coding to bridge the GH shortfalls and get the job done. Visual programming by itself is intrinsically flawed, after all why is GH programmed with code? This is the point Peter is making and one which he feels is important to convey; coding is a requisite for anyone seriously looking to implement GH as part of a real-world work-flow for building design and delivery. That's the truth of it. Now, best run before the GH fanboi mob comes after me - it's been a while and I'm sure they're thirsty...…; Added by AnewGHy at 4:25pm on February 16, 2015

Comment on: Topic 'Pain Points in Grasshopper': hat aren’t completely there. BIM will have to continue to evolve some more if their supporters want to get to realize the promise that still is. I can’t say much about PLM, but I would say that both BIM and PLM should be considered in future developments of GH and Rhino. David has said several times that some GH limitations regarding geometry and data structures (central to interoperability) are actually Rhino limitations. So, I wouldn’t put so much pressure on David for this, or at least I would distribute the pressure also on the core Rhino development team. Talking about Rhino vs. GH geometry, there is one (1) wish I have: support for extrusion geometry. GH already inputs extrusion elements from Rhino, but they are converted to breps. Is not a bad thing per se. The problem is when you need to bake several breps that make the Rhino file to weight several hundred MB. When these breps are actually prismatic, extrusion-like solids, is a shame that they aren’t stored as Rhino V5’s extrusion geometry in a file of just a couple of MB (I overcame this once with an inelegant RhinoScript that wasn’t good for other people). This was one of RhinoBIM’s main arguments. We can develop a structural model made of I-beams in GH using the Extrude components. We should be able to bake them as extrusions. That would also work for urban models with thousands of prismatic massing buildings (e.g. extruded footprints). Even GH’s boxes are baked as breps! Baking boxes as extrusions could be practical for voxelated or Minecraft-like models. (2) Collaborative network support. Maybe with worksession handling, or something that aloud project team members to work on a single definition or in external references or something alike. I know there is another Rhino limitation on this, but maybe clusters are already going in that direction? And maybe on the plug-ins domain: (3) Remote control panel that could be really “remote”, like from other computer or device. There is an old Android App for that, but is not only a matter of updating. I mean, it would be great to control a slider with the accelerometer of an Android phone, but to have that on an iPhone will require another development team. If GH could support networks, a remote counterpart of a RCP plug-in could be developed as a cross-platform web app. I don’t know if you can access accelerometer functionality through HTML5 already, but for now, asking a client (or an spectator or any stakeholder for that matter) to control your sliders from gestures of his/her own phone would be awesome (maybe Firefly will fill that hole?). (4) GIS support. GH already imports .shp files. Meerkat can even access the database, but what about writing to shapefiles or generating our own with databases processed/generated in GH? (5) SketchUp support. Not only starchitects and corporations are using GH in the AEC. There are a lot of small firms, freelancers and students interested. Most of them use SketchUp for 3D modeling (not CATIA, neither Revit). Yes, you can import/export .skp from Rhino, but if GH could support nested block at bake time (also mentioned by others), it could write .skp files with complex relations of blocks (that are called components in SketchUp) and nested groups, going beyond what Rhino can export. (6) Read/Write other formats. There are some challenges with proprietary formats that are not completely supported by Rhino, but they’re still a lot of open formats that are relevant to the fields of GH users, like stl and ply for 3D-printing. It could be nice to write mesh colors to a ply for 3D-printing a colored prototype based on GH colors. There are others, like IGES, STEP, COLLADA, etc. and 2D, like svg, odg and pdf. Some of them could offer special formatting options like custom data that the format supports but nobody uses just because is impractical to access this from direct modeling environments (but not from visual programming). --Ernesto…; Added by Ernesto Bueno at 3:00am on July 31, 2014