algorithmic modeling for Rhino

Search Results - 【p26.pw】GoogleにあなたのWebサイトを迅速にインデックスする方法.260125105255

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

Comment on: Topic 'surface Morph': control points are sufficient. For arcs that its complicated, it all fake checkpoints more vectors. See the results here: http://www.youtube.com/user/rhymone1?feature=mhum#p/a/u/1/7eXiOGvevaA…; Added by Rémy Maurcot at 12:28pm on April 13, 2011

Comment on: Topic '[Q] gradient coloring of text dots (text tags)': u forum.J'apprecie votre page ainsi que l'exemple du composant gha.(je suis la dessus en ce moment). Pour ce qui est de votre exemple je trouve ça trés intéressant.Les ID de départ d'ou provienne t-il, d'un Text dot ou d'un point ? J'aimerais modifier le texte dans rhinoceros et que dans gh le text se mettent à jour.Pour ce qui est de leurs position c'est bien ça que je veux; elle est fixé par lobjet de départ:ID Si je démarre d'un fichier vierge comment injecter les objets comprenant l'ID ? Merci encore de votre intéressement et de vos efforts de traduction. Google Translate: Wooh, good job. I start working with VB script and other, and for now my level is beginner but I'll catch up soon, thanks to you and people on the forum. I appreciate your page and the example of the component gha. (I'm the top now). As for your example I find it very interesting. IDs starting or he comes, a text or a dot point? I would like to change the text in rhinoceros and gh in the text are updated. In terms of their position it is what I want and is set by lobjet starting: ID If I start with a blank file how to inject objects containing the ID? Thank you again for your sharing and your translation efforts.…; Added by Rémy Maurcot at 7:10am on December 23, 2011

Topic: Read this first! How to get help on this forum.: uick answers. Below you will find some suggestions, but don't think of them as rules and especially don't think of them as guarantees. 1. Choose a descriptive title for your post Don't call your question "Help!" or "I have a problem" or "Deadline tonight!", but actually describe the problem you are having. 2. Be succinct but clear in your wording People need to know some details about your problem in order to understand what sort of answers would satisfy you, but nobody cares about how angry your boss or how bad your teacher or how tight your deadline is. Talk about the problem and only the problem. If you don't speak English well, you should probably post in your native language as well as providing a Google Translation of your question. 3. Attach minimal versions of all the relevant files If you have a GH/GHX file you have a question about, attach it to the post. Don't expect that people will recreate a file based on a screen-shot because that's a lot of pointless work. It's also a good idea to remove everything non-essential from a GH file. You can use the 'Internalise Data' menu option to cut everything to the left of a parameter: If you're importing curves or Breps or meshes from Rhino, you can also internalise them so you won't have to post a 3DM file as well as a GH file. If you do attach large files, consider zipping them first. Do not use RAR, Ning doesn't handle it. It is especially a good idea to post files that don't require any non-standard components if at all possible. Not everyone has Kangaroo or Hoopsnake or Geco installed so if your file relies on those components, it might not open correctly elsewhere. 4. Include a detailed image of the GH file if it makes sense If your question is about a specific (group of) components, consider adding a screenshot of the file in the text of the post. You can use the Ctrl+Shift+Q feature in Grasshopper to quickly create nice screenshots with focus rectangles such as this: 5. Include links to online resources if possible If you have a question about Schwarz Minimal surfaces, please link to a website which talks about these. 6. Create new topics rather than continuing old ones It's usually better to start a fresh question, even if there's already a discussion that kinda sorta tangentially touches upon the same issue. Please link to that discussion, but start anew. 7. This is not a 'do my work for me' group Many of us like to help, but it's good to see effort on our part being matched by effort on your part. Questions in the form of 'I need to do X but cannot be bothered to try and learn the software' will (and should) go unanswered. 7b. Similarly, questions in the form of 'How do I quickly recreate this facade that took a team of skilled professionals four months to figure out?' have a very low success rate. -- David Rutten Lead Grasshopper Development Robert McNeel & Associates…; Added by David Rutten at 12:58pm on October 1, 2013