r visual programming tools in the games world. MS's Kodu, looks interesting. Kismet and Visual3d look even more interesting..... mainly because they are more 'interactive' or 'reactive', rather than DAG-based.
Seems like the evolution path for GH-similar apps is:
1. base 3d or CAD app based on C/C++ code.
2. Add scripting language interface
3. Add some kind of visual interface
4. Add graph sorting / propagation engine
5. Re-jig base 3d or CADD app to make managed/interpreted scripts run faster, multi-threaded.
6. Add dynamic typed language, DLR stuff
6. ....
6. Add constraints solver...?
7. Rebuild CAD display engine to be procedural at the GPU level?
Seems like there are available tools for converting scripts into some kind of flowchart. There are even visual debuggers. MS even has something called the 'Debugger Canvas'. Spreadsheet constraints.
Seems like the time is ripe for lots of new apps like GH.
…
l design.
2/ Optimization
2.1/ in prefabrication
2.2/ combinatorial
2.3/ approach comparisons (i.e. deterministic vs stochastic)
2.4/ share your research
2.5/ ... etc. the list goes on and on
3/ Share you design rationale and how computation fits in
4/ Need help with this problem...
5/ Challenges and workshops announcements
6/ CD News
7/ Share computational design projects under construction or built (akin to skyscrapercity)
8/ and so many other categories and sub-categories...
Just my first thoughts. That breakdown in optimization is just an example. Maybe 'sections' is an old-school way of seeing things, I just wanted to share some thoughts on the kind of content I look forward to seeing. It can be pragmatic topics, but also theoretical, and allow folks to share their projects and research. Some categories are specific, others broad. I suppose I'm interested in community building with regards to computational design. I think SmartGeometry attempted to accomplish this at some point in the past, to some degree. However their focus appears to be in the workshops and challenges.
I recall the silly flame wars that the CG industry had 20 years ago (lame). I'd avoid that, even if it meant forbidding the mention of any specific software in certain areas or in the entire forum. Which would be tricky, but the endless flame wars and silly comparisons were such a waste of everyone's time in CG.
Without dwelling on this too much yet, I think that the software specific questions belong in software specific forums. If we already had a common language for computational design, you'd just need to add the right description as a meta-tag to any Dynamo or Grasshopper forum post, and you'd be able to find analogous solutions in either forum effortlessly, right?
The Dynamo and Grasshopper forums lack design-centric content. The emphasis is generally on the tools and workflow. Computational design is hybrid in essence, it involves both design and computer programming (be it visual or textual). We could really use a forum for knowledge exchange where the expectation is that both are discussed with equal status.
I disagree that such a forum ought to exclude professional programmers. It should include professional programmers whom have an interest in design, and also include professional designers whom have an interest in computer programming, and everyone in between, and enthusiasts, and artists whom are curious about algorithms as a creative medium, and academics, and students, and etc etc. As long as there is rich content and activity on design as well, not only the computational bit, then the crowd will be diverse and we'll all have more to learn from one another.…
er" logic but it miss when comes the copy or offset.
Here is my following logic
Take the square of 25 m x 12 m ; make it a surface
I divide it in "blades" of 20 cm
I take the edges of the "blades",
I divide this edges in 40 points (or equivalent) (A)
I identify my curves (curves) which are on the floors, which are curves (B)
First i do this "test" :
for each crossroad between A and B, i make a circle of X cm (slider) of diameter and the rule is the following :
* In this circle, the future movement of my A curve must be at Z = 0
Second step :
for each next point, i have to : leave a copy on Z = 0 and rise the second one for a heigh of Y cm (slider) from the ground.
the next (W = slider to chose every each number of point, i decide to do the following point) point, which is a little bit farer from the previous point, must duplicate the same height of Y ; and also be copied to Y + Y cm.
There is a Z number (slider) which is the max height possible for these points, which mean that the next point must be at this very same level except ... The third step scenario.
The purpose is to be able to have flat area, like step in a stairway.
Third step :
The grasshopper must test if the A points are between two or more "area at Z = 0". Why ?
The goal is to obtain something like screen "side view" if there are two starting points at Z = 0.
Which also mean that if there is an odd number of points, the remaining odd number must be at the top of the "stairs"
At this point of the grasshopper, we might be able to obtain, thanks to the sliders the "staircase form" regarding :
- The size of the test circle between A and B curves
- The "footstep" of each points (height)
- The number of points before a "copy of the point + the next footstep rise"
- The max heigh possible for all the point off B curves
And at this moment i have a new problem in my logic. You will get my idea, but it might be wrong as well...
Therefore, and after that, we should be able to link every point by a straight line.
To fillet with P (angle) a line with the following one
To join all the line of a same B curve
To cut it at the center of each circle at Z = 0 (the crossroad of A and B)
To offset it with Q (distance)
To rise a line from the center of each circle at Z = 0
To cut the extra part of each Offset"ed" curve to get an offset curve "aligned in Z" with the original one.
To create loft the original and offset"ed" one
To extrude the surface to a distance of R
And grasshopper "should be done" because, i will duplicate it for the ceiling, reverse the form with a -Z vector to the Y value and modifie my Z in Z' to modify my max height
Could you help me ?
…
ow the steps of the successful run when step 1.2 is bypassed (note that the and OpenFOAM session is open in the background while running the Butterfly demo file):
1. create wind tunnel, and use different parameters of (4,4) for _globalRefLevel_ as suggested by Theodoro in this post
2. run blockMesh:
3. run snappyHexMesh:
4. run checkMesh:
5. connect the case from checkMesh to simpleFOAM and run the simulation:
6. the simulation converged at 1865 iteration, but the results visualization part has some problem:
7. so I revised this part according to suggestions from Hagit:
8. and the results can be visualized for P and U values:
The GH file used for the successful run shown above is attached here.
Now, the following is the error I got when the case from the update fvScheme component is used for simpleFOAM simulation:
the warning message on the simpleFOAM component is:
1. Solution exception: --> OpenFOAM command Failed!#0 Foam::error::printStack(Foam::Ostream&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #1 Foam::sigFpe::sigHandler(int) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #2 ? in "/lib64/libc.so.6" #3 double Foam::sumProd<double>(Foam::UList<double> const&, Foam::UList<double> const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #4 Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #5 Foam::GAMGSolver::solveCoarsestLevel(Foam::Field<double>&, Foam::Field<double> const&) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #6 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMatrix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #7 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #8 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so" #9 Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #10 Foam::fvMatrix<double>::solve() in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #11 ? in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #12 __libc_start_main in "/lib64/libc.so.6" #13 ? in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam"
The error message from the readMe! output node is attached below as a text file.
Hope you can kindly advise what the important steps or parameters I might have missed here. I assume it might be related to OpenFOAM rather than with the Butterfly workflow...
Thank you very much!
- Ji
…
rested in specializing in the field of Computational design.
The workshop will help understand how Grasshopper facilitates during the design process allowing one to Generate, Automate and Manipulate data.
To Register:
http://goo.gl/forms/gvUTyZihVK
Workshop Structure:
Day 01: 16 August 2018
Introduction to Computational Processes in Architecture
Understanding Grasshopper and its relation to Rhino3D
Working with fields and Grids (Supplementary readings for Architectural theory)
Spatial Concepts using Data
Day 02: 17 August 2018
Understanding Data in Grasshopper - LISTS
Managing Data in Grasshopper (Supplementary reading)
Experimentation on Massing and Architectural Forms
Day 03: 18 August 2018
Understanding Data in Grasshopper – Trees
Surface Logics (Supplementary reading)
Design Exercise and Prototyping
Day 04: 20 August 2018
Architectural Skins
Day 05: 21 August 2018
MasterClass Project
Introduction to various types of Digital Fabrications
Prototyping of works during the Workshops
Basic knowledge of Rhino 5 is required to be able to take this training.
CERTIFICATION: All participants will receive a Workshop certificate from Authorized Rhino Trainer.
3D Printing: Prototyping of works during the Workshops
Workshop Tutor:
Kavitha M, an Architect and Computational Designer, 3D Printing Specialist is also the co-founder of INTO Design Research, will head the Computational Process in Architecture using Grasshopper workshop. Graduated from Stadelschule Architecture class with Masters in Advanced Architecture Design, has been researching on teaching methodologies on digital tools and their influence on Design thinking.…
A repository of generic or complex examples.
Example 01: Attractor Values
ND_001_AttractorValues.gh
Example 02: Curve Values
ND_002_CurveValues.gh
Example 03: Point Attractor
ND_003_PointAttract
f objects with the main ring body, and that cannot be done in parallel since you are modifying the item once at a time, algorithmically.
The original example of a cylinder and sphere are textbook failures of the Rhino 5 dumb algorithm, since that combination features kissing surfaces that confuse Rhino about where they are intersecting since really in tolerance values they are overlapping along a ribbon instead of a sharp line.
Normally you would slightly move or rescale one of the pair to create a single loop intersection curve that doesn't wander around in jerky fashion trying to combine two surfaces that fail to actually plunge through one another.
Your main Boolean union is 116 prongs with a ring base, and that's slow because Rhino bogs down as the model gets more an more complicated with each internal step, I imagine.
The speed is not all that slow either, only 21 seconds for the Booleans themselves.
If you turn of Grasshopper preview meshing via the toolbar menu it should be significantly faster while you are tweaking the design.
To troubleshoot the slow Boolean, I went into Rhino and tried merely splitting the ring body with the prongs and that itself was just about as slow as the Boolean union, so Rhino is not being badass about it. Then I exploded the ring body and tried splitting just that with the prongs and it was *much* faster to operate on just that single surface! The black box reveals itself a bit.
In kind, splitting the prongs with that single surface was about the same speed as splitting it with the whole ring body, so no speed gain there.
But, to speed up your script, since we *cannot* in fact use parallel processing, we can instead manually create that prong surface by doing our own splits and using Grasshopper's natural order of parts, hopefully consistent, to get rid of the junk.
That prong surface is item 4 of an exploded object.
So I will mutually split them and tease out the good parts from the junk and then rejoin the parts, no Boolean union component needed.
First, I went into your prong cluster and removed the capping, so I have merely an open revolution surface instead of a polysurface, letting me access the surface trim command after quickly finding the BrepBrep intersection curves between the prongs and the single ring surface.
For that Boolean union step I'm down from 11 seconds to 4 seconds, but confusingly we added a second to the Boolean difference that follows:
It's fast since we are manually selecting junk instead of Rhino having to sort which is which, I imagine.
We still have a slow Boolean subtraction of the gems and holes from the finished ring body.
That's not simple so will remain slow and cannot be parallel processed since again there's a single main ring body being modified in each step, and nor are there simple pairs of split object to select from manually to discard junk.
…