whole design intent, but this is what Inventor is good at. The way it packages bits of 'scripted' components into 'little models' that can be stored and re-assembled is central to MCAD working.
The Inventor model shown is almost 5 years old. We don't model like that any more, however it does offer a good idea of general MCAD modeling approaches.
iParts is useful in certain situations, it could've been useful in the above model, its usefulness is often in function of the quantity of variants/configurations.
So much is scripted in GH, maybe it should also be possible to script/define/constrain/assist the placement/gluing of the results?
...
Starting point: I think we are talking across purposes. AFAIK, the solving sequence of GH's scripted components is fixed. It won't do circular dependencies... without a fight. The inter-component dependencies not 'managed' like constraints solvers do for MCAD apps.
Components and assemblies are individual files in MCAD.
Placement of these within assemblies in MCAD is a product of matrix transforms and persistent constraints. There is no bi-directional link, the link is unidirectional (downflow only), because of the use of proxies.
Consequently, scripting the placement of components is irrelevant in GH, unless you decide that each component needs to be contained in its own separate file.
This also brings up the point that generating components and assemblies in MCAD is not as straightforward. In iParts and iAssemblies, each configuration needs to be generated as a "child" (the individual file needs to be created for each child) before those children can be used elsewhere.
You notice the dilemma, if you generate 100 parts, and then you realize you only need 20, you've created 80 extra parts which you have no need for, thus generating wasteful data that may cause file management issues later on.
GH remains in a transient world, and when you decide to bake geometry (if you need to at all), you can do that in one Rhino file, and save it as the state of the design at that given moment. Very convenient for design, though unacceptable for most non-digital manufacturing methods, which greatly limits Rhino's use for manufacturing unless you combine it with an MCAD app.
One of the reasons why the distributed file approach makes perfect sense in MCAD, is that in industry you deal with a finite set of objects. Generative tools are usually not a requirement. Most mechanical engineers, product engineers and machinists would never have any use for that.
The other thing that MCAD apps like Inventor have, is the 'structured' interface that offers up all that setting out information like the coordinate systems, work planes, parameters etc in a concise fashion in the 'history tree'. This will translate into user speed. GH's canvas is a bit more freeform. I suppose the info is all there and linked, so a bit of re-jigging is easy. Also, see how T-Flex can even embed sliders and other parameter input boxes into the model itself. Pretty handy/fast to understand, which also means more speed.
True. As long as you keep the browser pane/specification tree organized and easy to query.
:)
Would love to understand what you did by sketching.
I'll start by showing what was done years ago in the Inventor model, and then share with you what I did in GH, but in another post.
Let's use one of the beams as an example:
We can isolate this component for clarity.
Notice that I've highlighted the sectional sketch with dimensions, and the point of reference, which is in relation to the CL of the column which the beam bears on. The orientation and location of the beam is already set by underlying geometry.
Here's a perspective view of the same:
The extent of the beam was also driven by reference geometry, 2 planes offset from the beam's XY plane, driven by parameters from another underlying file which serves as a parameter container:
Reference axes and points are present for all other components, here are some of them:
It starts getting cluttered if you see the reference planes as well:
Is I mentioned earlier, over time we've found better ways to define and associate geometry, parameters, manage design change, improving the efficiency of parametric models. But this model is a fair representation of a basic modeling approach, and since an Inventor-GH comparison is like comparing apples and oranges anyways, this model can be used to understand the differences and similarities, for those interested.
I haven't even gotten to your latest post yet, I will eventually.…
Added by Santiago Diaz at 10:36am on February 26, 2011
he picture (4).
Previously, I had a problem with generating intersections between the two directions of the beams, but a colleague helped me by extending beams, so there was no problem with lines of intersection. But this solution has generated curl (5) at the highest vertex geometry, which I ignored in order to repair it before printing, perhaps this mean my problem with my beam spread properly. Only when the beams is 19, does not jump no problem, but I still can not distribute them properly.
(1)
(2)
(3)
(4)
(5)
I tried to show as simply as possible by removing or signing my code in GHX file.
Thank you in advance for your help
…
: Castellano
Horarios
Básico - miércoles
18.30 - 21.30 h
Avanzado - miércoles
15.00 - 18.00 h
Una vez finalizado el curso, el alumno podrá solicitar un diploma acreditativo del mismo.
Normativa: http://daetsam.aq.upm.es/servicios/cursos/informacion
Información cursos: http://daetsam.aq.upm.es/servicios/cursos/primavera2014
Métodos de pago: http://daetsam.aq.upm.es/noticias/2014/02/16/cursos-primavera-2014-aplicaciones-informaticas-e-idiomas
…
xamine triangle AOC: OX bisects angle AOC.
3. Since we know the angle AOC (equal to A'O'C, which we can derive from the projector's known settings) we can also construct point O" (by intersecting two arches on any plane).
4. If we revolve this point (O") around segment AC we get a collection of possible locations of O
5. Repeat steps 2-4 for the other triangle (BOD) and we get the second possible set of locations (a circle revolving around DB
6. Intersect the two circles and we get O
I tested this and it works. However I'm still looking for a more elegant, solution. The best thing would be to do it all in a scripting component.…
o change a light bulb?
A. None. They all fear change!
Every single time Windows has brought out a significant update everyone I have ever met has greeted it with disdain, yet I couldn't imagine using the interface to windows 95 again... and I certainly couldn't imagine going back to using Explicit History again.
Personally I try to embrace the changes, but I often find that for a few of them several weeks will go by before I hate it or love it... and then give feedback.
I think air your view on specifics and you will get a lot of discussion from both sides of the equation so don't be afraid to speak up about it.…
ining the group that created the PRC software, but since our KRC-1 is very old (WIN 95) there may be some compatibility issues, and the cost to join that group is a little steep for me right now, so i'd rather not pay for membership until I know their software will work for me.
Having said that, what's the best way to get started learning this process? Has anyone else out there been using the PRC and could give me some tips?
I'd like to be able to machine reliefs and full-3d sculptures with my Kuka. I've been doing the reliefs on a CNC router.
After looking at the PRC in Grasshopper, it's my understanding that generating toolpaths involves using the surfaces of objects. My biggest mental block is that I don't understand how to generate the toolpaths for multi-sided objects (like a full 3D, in-the-round sculpture). I've tried searching for how to create toolpaths in Grasshopper without the PRC, and it is possible, but it's still too big of a jump for a very inexperienced user like myself.
I'm looking to this forum for initial advice, as there's only one person I can email about the PRC for that advice unless I pay up. Thanks for any help!…
ectural project, the efficiency of design communication and the control of information-flow are as important as the creativity of ideas. In response to the concurrent digital evolution emerging in the architectural industry world-wide, the Faculty of Architecture at The University of Hong Kong will host a two week intensive summer program named Digital Practice.Led by professors from The University of Hong Kong, as well as invited practitioners with expertise in practice of cutting edge digital techniques, the program offers participants opportunities to experience applications of computational tools during different stages of an architectural project, i.e. concept design, form finding and optimization, delivery, management and communication of design information under the team-based working environment. By learning advanced computational techniques through case studies in the context of Hong Kong, participants are expected to go beyond the conventional perception of technology, considering users and tools as a feedback-based entity instead of a dichotomy. The program, which is taught in English, includes a series of evening lectures related delivered by teaching staff and invited local architects.對於高品質的建築專案,創意之外,專案過程中高效的設計資訊管理和交流成為項目設計深化和實施必不可少的環節。今天,數字化技術不但改變了建築師的繪圖工具,影響了設計的過程,而且提供了工程建造和管理實施的更有效、更高效的手段。針對建築的數位化演進,香港大學建築學院將於2011年暑假期間,在香港大學建築學院舉辦“數位化實踐”國際研習班。在香港大學建築學院教授及有著相關豐富經驗的外聘實踐建築師的指導下,學員將有機會體驗在專案的不同階段(如概念設計、設計形式的生成、優化,設計資訊的管理和交流),如何有效地應用各種運算智慧化技術(從設計的數位化生成和建築資訊類比到物理模型),提升設計實施的品質,增加設計團隊對於方案的控制。我們將挑戰對於“技術”的傳統認知,即相對於使用者它不僅是工具,更是與使用者互動的媒介,二者形成一個有機的合體。研習班期間會安排系列講座,展現數位化技術在實踐工程中的廣泛應用。…
perienced with grasshopper, but so far I've managed to combine the following:
Giulio Piacentino's "Catenary arch from height" script
Pirouz Nourian's "Mobius" script (Obtained from a friend)
End Result:
Here's where I'm stuck: I want the mobius twist to revolve around the midpoint of the arch, but the script uses the input values to determine the endpoints, resulting in a weird sinuous shape when viewed from above. Also, the secondary end points (generated by the mobius script, determining the width of the surface) are generated by default along the z axis, resulting in an arch that only touches the "ground" at two points. I attempted to work around this issue by trying to force the zHeight parameter to correspond with the y axis (thus rotating the arch 90 degrees so it would lay "flat"), but the script interprets the third point as a value and not as an actual point to bisect. I thought this might be an issue with the C# component that I obtained from Giulio Piacentino's script, so I attempted to tinker around with the source code. Unfortunately, I'm not fluent in C# so I only managed to mess everything up (I've since recovered the code from the cache). Anybody got some ideas? -BC …
e BIOS as i noticed that i was required to do so. This is the progress i made. Now the file "do something". It takes about 4 minutes in the blockMesh component, so something is happening. But at the end of the 4 minutes i get the same error as before. Tried to run the start_OF.bat externally, but no use either.
Those are the snapshots of both of them:
Be patient ... and bear with me. Sorry for bothering with this ... and thanks,
-A.
P.S. There is a chance it is related to the firewall of my university, or some other security issue for those trying to apply virtual machines/hosting.
I'll try at home in the evening.
A more detailed image of the shell running the batch file manually:
…