use an attractor curve to adjust curves that are being lofted to create a "wavey" surface. I've attached a picture to show the end result. Right now i create all the curves and then loft them together to create a surface which could then have a rib definition applied to it, and it works, my problem is that this project is for a 80' section of wall with ribs that would be a few inches apart, so that is a ton of curves i have to change everytime i want to adjust the overall shape. So is it possible to have an attractor curve that instead of adjusting the spacing of shapes in plane with the curve, would create high points or low points perpendicular to the curve? Hopefully that makes some sense, i'm having trouble finding the words to explain it, the attached pictures should help.
Any advice on how to do this would be great. I hate being that guy but this project came up last minute and it seemed like something the Grasshopper help save a ton of time in as far as adjustments go.
Thanks,
Kyle
…
h kangaroo and have found one project that illustrates my idea exactly...
https://vimeo.com/88002087
So far my best attempt has been to use a gridded surface in which the lines of the grid are springs, with a rest length at 80% of their initial length. (call this grid A) This is to simulate as if the material has been stretched 120% of its resting dimensions.
I have been trying to anchor the springs to a secondary grid (Grid B, curves that will be deposited onto the material) at the points of intersection with grid A.
I am not sure if this is the best approach, maybe soapfilm would be better? although i require the boundary (grid B) to adapt also...
Any advice or attempts to explain how Taichi Kuma has done this in his video would be greatly appreciated.
Thanks…
A: Who created it? / Copyright?
B: Anyone have a larger resolution copy of this image (or a vector so I can do a large resize).
Long and short - I'm an artist and I'd like to make a quilt out of that image. I need a decent resolution copy of it so I can do a huge resize and get a 76" x 80" crop out of it. I've tried resizing it in Photoshop, but by the time it's large enough, the quality has dropped below what is usable for my needs.
Thanks in advance! I totally understand I'm relying on the kindness of strangers here. (Also if this is inappropriate to post - please delete. Thank you)
Michael…
st for the quality of the mesh.
Actually, convergence is much more than simply having low residuals. You can have a wrong solution with very low residuals. Usually, it is a combined process of both run time information on residuals and having an idea or expectation of what the simulation results should be. Another way of assessing convergence is if the residual values have been stable (within a very small limit, e.g. 1E-5) for more than a certain number of iterations (e.g. 1000). We are planning to provide run-time residual plots in Butterfly, hopefully soon. These plots can help keeping an eye on the solution.
You could try as a test if you want to switch to a blend of first and second order (by swapping upwind with linearUpwind in the fvSchemes)
.
Concerning mesh quality there are a number of ways, some of which are a bit advanced for this post and for BF's current capabilities. The best way to start is by refining the background mesh (i.e. the blockMesh). You can do that by assigning more cells to the x, y and z directions in the blockMesh component. However, make sure you increase the max global cells. I would suggest you monitor the output of the blockMesh in order to know the total number of cells there. Your max global cells has to be higher than that for SHM to even work. I'd suggest 2x to start with. Ofc all that requires a bit of trial and error depending on the case at hand.
Hope this helps!
Kind regards,
Theodore.…
wing exception will be thrown:
Message: Cannot import name minimum_edge_cut
Traceback:line 60, in <module>, "C:\Program Files\Rhinoceros 5 (64-bit)\Plug-ins\IronPython\Lib\site-packages\networkx\algorithms\__init__.py"line 21, in <module>, "C:\Program Files\Rhinoceros 5 (64-bit)\Plug-ins\IronPython\Lib\site-packages\networkx\generators\classic.py"line 5, in <module>, "C:\Program Files\Rhinoceros 5 (64-bit)\Plug-ins\IronPython\Lib\site-packages\networkx\generators\__init__.py"line 84, in <module>, "C:\Program Files\Rhinoceros 5 (64-bit)\Plug-ins\IronPython\Lib\site-packages\networkx\__init__.py"
I would inform you that I have also copied the Networkx library into "C:\Program Files\Rhinoceros 5 (64-bit)\Plug-ins\IronPython\Lib\site-packages\" and have specified this directory in "Python Options->Files->Module Search Paths" so that Rhino/Grasshopper knows where to access this library.
Could you please help me how can I sort this out?
Any comment is highly appreciated.
Shayan…
ort and export from the images below and also from the HELP file of DB in attachments (Page 71: Importing Geometric Data; Page 78-80: Import 3 - D CAD Data). In their HELP file, they mention about "import geometric data".
However, regarding the input of schedules, loads, constructions and etc., DB normally uses "Component " and "Template" (Page 29: Templates And Components; Page 591: Templates; Page 533: Components). "Templates" are databases of typical generic data, including Activity templates, Construction templates, Glazing templates, Facade templates, HVAC templates, Location Templates, and etc. "Component " are databases of individual data items (e.g. a construction type, material, window pane).
Both "Component " and "Template" are allowed to be imported and exported by using "Import / Export library data" command (.ddf format - DB Database File; Page 734: Import Components/Templates, Export Components/Templates). DB also allows us to build up our own libraries of templates and components (Page 731: Library Management; Page 733: Template Library Management).
In order to import both geometric information and other information related to schedules, loads, constructions and etc. from GH to BD, we supposed the following two ways:
1. GH(HB+GB) --> gbXML (both geometric and "Component " and "Template" information) --> DB
This is the way we most prefer. We did see information related to schedules, loads, constructions encoded in the gbXML file generated by GB, but still do not know the reason why DB did not take this information (I also mentioned this in Q6 within the gh file). We assume this might because the gbXML file we create encodes the schedules based on a different template / schema than the one DB expects. We also post this question to the DB forum for help.
(http://www.designbuilder.co.uk/component/option,com_forum/Itemid,25/page,viewtopic/p,13755/#13755)
2. GH(HB+GB) --> gbXML (geometric information only) + .ddf ("Component " and "Template" information only) --> DB
If the first way doesn't work and DB only takes geometric information from the gbXML, then we might think of the other way - generating the .ddf files from GH(HB+GB) to pass the schedule, load and construction information to DB.
I was wondering if it is feasible for HB and GB to have this function? And what is your suggestion to achieve this?
In addition, we notice that DB can export XML files (not gbXML), so we are trying to figure out if DB also accepts / reads the XML file. If so, we might be able to convert the gbXML (with both geometric and schedule information) to XML. What do you think about that?
Thank you again for all your help!
Best,
Ding
DB import
DB export
Template libraries
Component libraries
…
y using the Honeybee_Update Honeybee component.
The video below (best viewed in full-screen mode) provides an idea of what these components are capable of being used for:
The video below shows how these components can be used in an existing Honeybee project (for additional links please open this video in youtube):
I have uploaded two examples as Hydra files that show how these components can be used for grid-point and image-based simulations:
Example1 : Grid Point Calculations
Example2: Image based simulation
Finally, a more esoteric application is demonstrated in this video:
These components are still in the beta-testing stage. Some of the limitations of the components are:
1. Only Type C photometry IES files are supported at present.
2. Rhino is likely to get sluggish if there are too many luminaires (i.e. light fixtures) present in a scene.
3. Due to the spectral limitations of the ray-tracing software (RADIANCE), simulations involving color mixing might not be physically realizable.
Additional details about photometric and spectral calculations are probably an overkill for this forum. However, I'd be glad to answer any related questions. Please report any bugs or request new features either on this forum or on Github.
Mostapha, Leland Curtis, Reinhardt Swart and Dr. Richard Mistrick provided valuable inputs during the development of these components.
Thanks,
Sarith
Update 16th January 2017:
An example with some new components and bug fixes since the initial release announcement can be found here
…
see in my bottom post image there is only one isocurve showing in U and V.
In Grasshopper there's no surface rebuild? Well, the same old Grasshopper Patch command will let you specify spans I guess, to make a surface from a planar curve, but it won't work for things with holes since they will just fill in!
You can recreate a surface painfully by untrimming, adding many UV points, rebuilding from those points, then retrimming with the original surface info, but the retrimming simply fails.
If you make a planar surface from a curve in Rhino, you end up with utterly no point editability:
No wonder my CreatePatch tests were a failure. The starting surface could not be distorted except in the extreme case of moving four corner points!
I have no idea how to successfully rebuild a surface akin to the Rhino rebuild command. It's great to be able to prototype in Grasshopper, but with Python I can rebuild easily ( http://4.rhino3d.com/5/rhinocommon/?topic=html/M_Rhino_Geometry_Surface_Rebuild.htm ;), so I guess I should start a collection, like peter, of little script components for prototyping with.…
Added by Nik Willmore at 6:18am on February 26, 2016
milar once its default data managment techniques are exceeded thus forcing a new address index to be inserted. Its all just so unnecessarily particular and finickity.
If addresses are added when forced to, why not just have that as the default behaviour in the first place? Its not so much 'one size fits all' as postulated previously, but more one size fits 80% of cases and in the remaining 20% of cases you're going to be a slave to your definition as constant manual management will be required just to control the thing.
My final point:
circle with points should have a list address of {0}
multiple circles with points should have list address of {0;0}
multiple circles in multiple locations with points should have list address of {0;0;0} etc
I really dont see how that is any less consistent for highly complex data strucutres. To any rational individual this is predicable and follows a logic. What advantage is there in fixing the address at {0;0} yet still allow for new address sequences to be added firther down stream? Logic is the key thing to keep in mind here, not peculiar nuances only the initiated can ever be aware of.…
cle
the 'Shape' is copied to all points
shapes are rotated randomly, plus or minus 'Angle' maximum
'Shape In Brep (ShapeIn)' is used to cull shapes that aren't within the circle
'Fast Loop' begins using 'MCX' (Multiple Curves Intersection)
first shape is added to 'D1' output and shapes intersecting it are culled
results minus first shape are passed to 'D0' of 'FastLoopEnd'
loop repeats until 'D0' list is empty
'D1' results are scaled down slightly (0.75) to leave more space around them
'Explode' results and return only the curved part, ignoring the base line that closes the shape
…
Added by Joseph Oster at 11:01pm on March 17, 2017