try. (but a lot as regards ... other things, he he).
2. For a twisted ziggurat like yours ... well ... we are talking about a ramp (4.5m floor to floor) with reflected length ~80m > meaning that when the smallest (top) floor edge is 20m (~400m2 floor area) we need a ramp that almost fully engulfs the small floor. Of course we can consider, say, a 3.6m floor to floor (doesn't go smaller than this) ... meaning ~60m ramp > Yikes + Yikes. PS: When considering floor thickness .. take into account HVAC stuff as well.
3. Down we go: if we start with a 400m2 small (top) floor ... we soon arrive into paranoid floor sizes: because day lighting considerations (and a million other things) yield result "some" non habitable spaces. Unless you have in mind 3-5 floors resulting a building that looks like a drunken pizza.
4. For more than obvious reasons we need an atrium for that pizza > thus > why don't put the ramps inside (further mimicking the Great Man) and have piece in mind?
5. Segmented (per floor) skin is easily doable with the thing that I've provide to you since it works with ANY collection of surfaces (Lists to speak the GH language).
6. Test the following: create ANY collection of closed (in one direction)/open surfaces, sample them into a List and feed the truss maker > what happens?
Anyway, I'll do it (in The Name of Science, he he) but ... it's highly Academic.
…
ick to the Bezier span option (because this "guarantees" the LESS visual gap when lofting - actually that's a lie but stick to the plan) .
1. If we had ONE pair "suitably" oriented then things could be a bit more easier. But ... there's a bunch of pairs around and IF your pairs are different (in the true sense of the liquid madness, he he) ... well we need a policy:
2. Find either (a) the centroids of (b) the min distance points and define an "axis".
3. Find the ccx pts (case a) or use points from (b) and change the curve seams to these. This yields curves that start/end at some controlled "neighbor" points (critical if your curves are different or "twist" - as pairs - etc etc). This is ALSO critical when you want peace of mind when lofting (or use sweep1) because don''t get for granted what the Loft options component claims by the "adjust seams" thingy.
4. Optionally change the 2nd curve orientation in order to get a clock wise + anti clock wise pair. More on that later (is related with other methods to "fuse" this with that).
5. Define points at each curve using a pair of double values (0-1 if the pair domains are 0-1).
6. Split the curves (get the segments that you want) and define pairs of vectors (at end/start segment pts) that could give us 2 bezier spans.Don't forget to control the vector "lengths".
7. Unite the spans with the segments.
If all the above fail ... well... there's always the Plan B: I could post the C# that does this and several other ways to "fuse" curves plus a curve maker that is rather suitable for your tower adventures.
best …
to problems. If anyone wants to take a look at the attached file "605b-3" and try to help me, that would be awesome.
The way I'm thinking about creating the louvers:
1. Contour the shape (could be any shape, but I attached the one I'm trying to do it to)
2. Divide those contour curves
3. Find the 4 points on those curves that are furthest away from the center of each curve
4. Move those points slightly away from the center of each curve
5. Replace the unmoved points with the moved points
6. Interpolate/NURBS curve through the new list of points
7. Loft the new curves with the original contour curves
I think I'm close, but I'm getting stuck at the end- I thought shifting lists would be the best way to solve my problem, but I'm a little confused as to how grasshopper is organizing the list of new curves and how to match that organization to the original curves.
Attached is an image of where I am stuck. I can only create a surface in the gap that I'm trying to create by the louvers. Either that, or one or two of the curves tends to create a "tornado" looking thing and i can't figure out how to fix it without individually breaking up the list. Is there a way to set all the curve seams to be at the same location in a list?…
he "return" is comment out as shown below?
After restarting Rhino and Grasshopper, I opened the outdoors_airflow demo file, and the first step of creating the case file is ok:
Then the blockMesh component gives the following error: seems I have to manually start OF first..
so, as the error message suggested, I open OF by Start_OF.bat:
Then come back to the blockMesh component, now it can be executed while the OF command line window is also openning:
... and the blockMesh finished successfully:
... so I proceeded to run snappyHexMesh, checkMesh and update fvScheme:
... up to the simpleFoam component, I got the error again:
The warning message 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"
... and the command lines in the readMe! output are pretty long and it is saved in the text file attached here.
So, my questions are:
1. why I have to manually start OF first before I can use the blockMesh component? Should butterfly automatically start OF?
2. what might be the cause of the unsuccessful run of simpleFoam in the end?
Hope you can kindly advise! Thank you!
- Ji
…
not sure why it broke down again).
I have a the following code written in C#:
namespace blahblah.Extensions{
public static class TransformMethods{
public static AxisAngle ToAxisAngleRepresentation (this Transform m){
//Implemented code here
}
}
}
I have several methods to extend Transform struct, in order to convert 4x4 matrices into different formats e.g. axis-angle representation. In this case the return AxisAngle is one of my custom structs. My desire is to script completely in Python from Grasshopper. However I cannot seem to access these extension methods from there.
I have done the following:
1) I compile "blahblah.dll" and place it in my Grasshopper components directory.
2) To test it I use a C# component and reference the dll from "manage assemblies". The C# component automatically adds "using blahblah.Extensions". I feed in a Transform struct called m and am able to call m.ToAxisAngleRepresentation() without errors. Everything is good. (except maybe intellisense doesn't pick it up the method)
3) Next I wish to do the same thing in a Python component. (Here I am still confused about referencing external libraries). I first add my bin/release folder (where blahblah.dll is located) to my sys.path.
4) Next I add clr.AddReference("blahblah.dll")
5) I add the following line:
from blahblah.Extensions import *
which I would assume is equivalent to "using blahblah.Extensions" in the C# component
6) I then test with the following code:
m = Transform()
m.ToAxisAngleRepresentation()
7) I get the following error: Runtime error (MissingMemberException): 'Transform' object has no attribute 'ToAxisAngleRepresentation'
A further question I have with Python components. If I copy my dlls into the Grasshopper component folders. Do I still need to perform steps 3 and 4?
Thanks!
…
hope you'd a Merry one,. 1) I used the Ln component to join vertices between each surface. As I was working with two surfaces I meshed each surface with an equal number of U/V divisions (Vertices) so was able to draw lines between each matching vertex.- ..by "meshed" i assume that meant converting Surfaces with MeshUV\DeMesh?, and from your screenshots thats a substantial number of vertices and therefore lines to draw, well worth it though from the results!, i agree with your answer to 3) that a more automatic solution is required,. 2) Equalizing is correct. When you mesh an object it will create vertices, and you can use these to re-create a mesh between each set of sub-surfaces. You don’t need to Sdivide after meshing. If you check the definition in my second post you should get the idea.- ..thats great news, equalizing vertex numbers is exactly what i need to do since my Blend surface "keyframes" by nature will likely have unequal point counts. However, a) ..when using default Rhino surf's your intruiging def. starting to work for me only after i replaced you "custom" Domain(VB\Python?,let me know) with Deconstruct Domain. then it connected each surf's vertices but did Not produce an intermediate surface or points. b) ..when using my IDENTICAL Blend surf's in your def. with Deconstruct Domain and Merge comp's it then produced intermediate vertices,.see def. screenshots or i can send def's i you like,.I'll also produce the 2nd, Non-identical Blend surf keyframe to test in your def.- 5) please show me which actual Domain etc. components or substitutes to use and how to use them to run your def. successfully? 3) This I am afraid I cannot provide concrete guidance on this. I am sure it is possible by drawing lines then matching vertices based on position relative to the ‘key lines’ however I don’t feel this would be a great solution. Better to create something that is more automatic.- .. agreed, 6) does or will your latest def. contain more automated, vertex correspondence, Ln creation? 4) Yes, you can use grasshopper Brep-join to join your sub-surfaces before you divide. See image below. Alternatively, if you are joining matching sets of sub-surfaces then you can morph each sub-surface with its corresponding sub-surface then join the whole object.- ..perhaps i missed something, but after using Brep > Join on my polysurface SDivide still saw it as subsurfaces instead of a single surface,. If you can upload an image of what you are trying to do I may be able to help more. My work evolved to some degree since I made these posts. I am now generating objects based on time stamped data from excel rather than objects in Rhino.- ..see screenshot "2-Def_shot.JPG" showing my two surf's beside Blended Rhino surfs which i need to do with mine,. How many sets of surfaces are you trying to merge through? It is also possible to morph from 1 to 2, 2 to 3, 3 to 4 …… x-1 to x by using a slider which calculates the range and picks the correct two surfaces to morph. If you need more info let me know and I will write something.- ..that sounds perfect, esp. since the sets of surfaces will be as nearly unlimited as the feature film they're modeled from. Yes, i'd love to learn more info\def's on this subject, thanks,.. I am planning to show some of my work and where my industry (civil engineering) is going with grasshopper based solutions. Will post a link shortly to some of my projects.- ..look forward to that as well, please keep me informed,..
I should be available most of today and days following so really look forward to heard back soon as you've free moments.
Thanks again for the great work as well,
big fan, Jeff…
ce attractors
3- Relation between mathematics and Form
4- Network surface and Paneling
5- Fabrication methods (slice3d, nesting, ...)
6- Structure and Architecture (Millipede)
7-Energy and form
8- Islamic patterns
9- Physics with kangaroo
…
ends to work well for Rhino+Grasshopper as well. There are a couple things to keep in mind though:
1) Rhino and Grasshopper are mostly single-threaded applications. It is true we are trying more and more to multi-thread certain operations, but the time when a high-core-count really makes a difference is a long way off. So, you should care more about the clock-speed of the individual cores in your machine than the sum total. I.e. 2 cores running at 2 GHz each are better than 4 cores running at 1.8GHz each, even though the former will often be marketed as a 4GHz machine and the latter as a 7.2GHz machine.
2) Rhino is an OpenGL application, so video cards that are awesome at DirectX but suck at OpenGL are a bad choice. There's a lot of information out there already about which cards are good and which are not.
3) Grasshopper uses GDI+ to draw its interface and GDI+ is rarely hardware accelerated. Basically, the faster your memory and the faster your individual CPU cores the faster Grasshopper will redraw.
4) Grasshopper should run on Rhino5 64-bit, so if you're getting a new machine make sure you have a fully 64-bit platform and a 64-bit Windows version to go with it. I'd also recommend at least 8GB of fast RAM.
5) If you can spare it, Solid State Hard-drives are faster than old fashioned spinning contraptions.
6) I also highly recommend getting a second screen, so make sure your vid-card is good enough to handle two displays.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 5:47pm on February 20, 2011
...doesn't apply here (in fact it doesn't apply in most AEC related cases) : we need a controlled loop thing (were the stupid part waits the smart part to choose things and/or reject others - that's the computer and you) in order to make a "stepped" evolving solution. This means Anemone/Hoopsnake components that could handle the whole process "interactively" based on gradually evolving/occurring criteria. I'm talking mostly about "Fork" situations that MAY occur - in plain English: columns that "share" the same base/top TS face. Of course N other situations (due to some engineering and/or aesthetics) may happen that prohibit the x "column" formation BUT only because some other columns are already in place. Maybe stuff for Galapagos?
3. This is evident even if this case could be used for non "strict" engineering purposes (like some academic form exploitation and other similar deep space stuff).
4. Αtractors are not available in the TS world (a rather easy/primitive way to influence a given column on a per column basis).
5. The whole process is exponentially heavy for your CPU since from column 1 the top+base+column thing is treated as a single TS.
6. Regardless ..before doing anything ... learn/master how Hoopsnake works and why (the fact that a Greek did that stuff is just collateral damage, he he). Galapagos is not a bad idea to fathom either.
BTW: most unexperienced AEC people believe that 21st century is about BIM (dead before birth). I say that all what should matter is evolving design/solution algorithms.
may the Force (and snakes)...blah blah
…