of them. If they were already suggested and deemed impossible, i apologize.First, it would be really cool to have a right-click menu item for any geometry retaining module, that does the following: bakes the geometry, then disconnects all inherited data from the module, and assigns the baked version as locally defined. This is a one-time only thing, of course - it would be cool because if you have a "step-definition", that is, you have clear bottlenecks in your dataflow, and at some point you become satisfied with what you have so far, and only need to manually tweak some stuff to move on, you can discard the "already solved part of your definition. It's just a sort of "casting in stone" of partial results, that helps especially with simple work-defs or helper-defs. You could also call it something kickass like "manual override" or "emergency/hand b(r)ake".Second, if you have a component that outputs to a lot of others, and you want to change it with something else, you usually have to painstakingly reconnect all those wires, and if it doesn't work out, you do it right back or undo until you fingers bleed. Just as there is an extract parameter upstream for locally defined values, a downstream "extend parameter" with one rightclick menu item would make switching between various components easier.
Third, maybe a hot-key that you press and then click on a wire, which creates a "data" component at that point, splitting the wire and effectively allowing you to hijack it.
Lastly, maybe this is a stupid question, but what happened to the "clusters"? I mean i know they ended abruptly because of technical difficulties, but collapsing a group to a single component like that was totally awesome.Oh, and a minor bug repor from the v7.053 - it's not important, but mildly annoying: when you have an embedded graft, flatten, reparam or expression into a plug, the component extends to the left with the nifty little icons, and that looks very nice, but the wires still go in the old place, so at first glance i always think the wires are plugged in wrong. Is it possible to move the plug along with the component icon edge, or at least make those little indicators smaller, so that the error is minimized?
Thanks for your time,Hope i was pertinent
Andrei I.ps: the lolcat component is adorable, but i do believe that overall worldwide grasshopper productivity has dropped by various increments of those 20 sec it takes for it to refresh. Sadly accustomed with the feeling of guilt associated to watching around 50 lolpics refresh, I suggest that every 5 refreshes or so, you get a "stop looking at this and get back to work" message. It is at least a good way to derogate responsibility for tempting people to watch kitty-pics all day. :D…
stand completely (i just don't get the math part...).The code can be found here: http://digitalsubstance.wordpress.com/subcode/
So i decided to make my own definition: a cube deformed by 5 attractors and i was wondering if someone can help me solve the meshing at the end of the definition because when i bake it, it gives me an open mesh and i don't understand why ? Waterfall meshes are not suitable for 3d printing... I don't think i've used the clean, weld, and unify faces in the good order ? Maybe there is a problem with the surfaces ?
Secondly i'm not very proud of the result of my cube because it's so deformed that it is a not a cube anymore... so i was wondering if a square grid of points can be deformed by an attractor but still keeping the straight boundary of the grid ?
I had an idea to make that: i make my points, create the vectors between the grid and the attractor points, calculate the distance between the grid points and the attractors: it gives me a list of distances that i remap to control the strengh of my attractors. On the other side i calculate the distance between the boundary of the grid and the grid points and it gives me a second list of numbers. So i wanna average the two list of numbers in such a way that the closest it is to the attractor it takes the distance from the first list and the further it is from the attractor (so the closest it is from the boundary) it takes the distance from the second list ?? I'm sorry for my bad english but even in french it's little bit hard for me to explain it ;). So what can i do to have a grid attracted by a point without moving the boundary points ??
And please don't tell me to cull the boundary points first, to deform the grid and to rebuild the grid after... it gives an ugly cube face at the end, even with a lot of polishing with weaverbird...
If someone has another idea to achieve that please tell me ;)
The first definition "CleanCubeMeshingHelp"is a little bit heavy so watch out if you have a small laptop (any ideas to make it work faster are welcomed !!)
The second one is the one with the two list of numbers.
Also a last questions: what is and when to use the "blur number", "interpolate data" and Weighted Average" under math utilities ??
Thank you in advance for you answers and i apologize for my lack of vocubulary.…
/www.grasshopper3d.com/forum/topics/vb-vs-c-vs-python
http://www.grasshopper3d.com/forum/topics/which-programming-language-should-i-focus-on-vb-or-python
VB.Net and C#
VB.Net and C# both belong to the ".Net" family of languages, and the things you can do with them in Rhino/Grasshopper are nearly 100% equivalent. Grasshopper itself was written in a combination of VB.Net and C#. Some advantages/comments, in no particular order:
Performance - VB.Net and C# scripts tend to execute faster because they are "Just-in-time" compiled as opposed to interpreted.
Autocomplete - both VB.Net and C# have rich autocomplete functionality in their respective script editor components - significantly more so than the python editor. This can be helpful for beginners since you can "hunt" for methods and properties by just typing a "." after an object name and looking at the list of available methods/properties.
Native Component development - If you eventually want to develop GHA assemblies/plug-ins for grasshopper, as of Rhino 5 you will have to use one of these two languages. However, there are plans to introduce python-based plugins in Rhino 6. Even so, the resources around plug-in development are very rich in the C# and VB.Net environments (with c# seeming to be the more popular of the two).
"Strong Typing" - VB.net to some degree, and C# especially, are less "forgiving" languages than python - they require you to know about the data type of the objects you're operating on. This can sometimes result in more verbose code - as you explicitly convert from type to type - but it also promotes good programming practice and helps make errors more understandable.
.Net ecosystem - using a .Net language means you have access to the thousands of libraries publicly available, and the process of referencing these libraries and making use of them is comparatively straightforward relative to python. More on this in the following section.
Resources/Support - At least as of 2012, VB and C# turned up more results on this forum than python, and I think you'll find slightly more expert-level coders in those languages able to help you here.
Which one between the two? C# or VB.Net? - Personally, I greatly prefer C# - I find it to be cleaner and clearer to use. I also have some programming background in C++/Java/Processing so I found the "C family" approach to be more familiar. As David and Damian point out in some of the posts linked above, C# is more popular than either python or VB.net in the rest of the coding world. However, if you are learning without any prior programming experience you may find VB.net to be a bit easier to learn.
Python
Python is, without a doubt, a beautiful and elegant language, which is probably more than can be said for VB.Net/C#. It is very popular with beginner coders, and its syntax is more readily understandable.
Syntax - Python is beautiful to read and write. Its syntax is very clear and free of extraneous punctuation (for example the ";" line endings in c#). It has many very nice language features that make common tasks more concise, like its loop syntax, list comprehensions, list "map" and "filter."
Multiple ways to talk to Rhino/Grasshopper - Python enables two general approaches to interacting with the Rhino/Grasshopper environment: RhinoCommon and RhinoScriptSyntax. If you have prior experience with Rhinoscript, you may find RhinoScriptSyntax to be preferable - it adapts many of the methods you're familiar with to the python language, and simplifies some tasks. A word of caution though - working with Rhinoscriptsyntax can introduce a performance hit relative to RhinoCommon operations. C# and VB.net by contrast can only work with RhinoCommon.
"Goodies" - The Python environment in Grasshopper has some "special features" that the other languages lack. In particular, the "GHPythonLib" library enables the ability to call most Grasshopper components from within your code, and the ability to easily enable parallel processing to improve performance. (A word of caution though - these two features do not seem to "play well" with each other, there may be bugs causing memory leaks that result in increasingly worse performance with each execution).
Cross-Platform - Unlike C#/VB.net, Python can be used natively in Rhino for Windows and Rhino for Mac.
Direct scripting in Rhino - You can also use Python directly in the Rhino environment without the need for Grasshopper if you desire, using the Rhino Python editor.
IronPython / Ecosystem issues - one frustration / potential downside to working with Python for Rhino/GH is that though there is a vast, amazing ecosystem of external libraries for Python, getting these to install/work properly in the Rhino/GH environment can be a real pain - largely because the language is actually "IronPython," a version of python designed to work closely with the .Net ecosystem. Many popular libraries like numpy and scipy are very challenging to get working in Rhino/GH.
Scripting in other programs - Especially in the AEC industry, Python is a popular scripting language for other applications. Tools like Revit, Dynamo, Blender, and ArcGIS all offer their own Python scripting interface - so learning Python in Rhino/GH can give you a leg up in eventually scripting in these other programs.
Python's Stock is Rising - there are currently a number of efforts to improve the "status" of python within the Rhino/GH ecosystem. The python editor in Rhino 6 has a number of improvements, not least of which is the ability to "compile" add-ons for Grasshopper written in python. I'm sure Giulio can speak to other upcoming improvements.
I hope this summary helps you find the right option for you. Ultimately you can't go wrong; concepts from any of the available scripting languages will make it much easier to learn the next one. In my day to day work I use a combination of both C# and python, where appropriate, and I love them both.
I hope others will feel welcome to chime in on this FAQ and add their own thoughts about advantages/disadvantages of these various options! If you have time, read through some of the other posts linked to at the beginning - there's lots of additional great information there. …
Hi,
I have a similar problem, I tried the solution with Rhino 4sr9 and Rhino 5 (64bit), with the first works fine but the second doesn't work and gives me an errorThanks in advance for your reply
ns, which have a certain distance from the edge of the flat. I have a circuit, but the problem is the missing plane there and also some body. I need help relatively quickly. to the system: I work with Rhino 5 and Grasshopper version 28/09/2012, build 0.9.0014 here schematically the black bar should be flat and gray, the body thereon
…
lly it should not make much of a difference - random number generation is not affected, mutation also is not. crossover is a bit more tricky, I use Simulated Binary Crossover (SBX-20) which was introduced already in 1194:
Deb K., Agrawal R. B.: Simulated Binary Crossover for Continuous Search Space, inIITK/ME/SMD-94027, Convenor, Technical Reports, Indian Institue of Technology, Kanpur, India,November 1994
Abst ract. The success of binary-coded gene t ic algorithms (GA s) inproblems having discrete sear ch sp ace largely depends on the codingused to represent the prob lem variables and on the crossover ope ratorthat propagates buildin g blocks from pare nt strings to childrenst rings . In solving optimization problems having continuous searchspace, binary-co ded GAs discr et ize the search space by using a codingof the problem var iables in binary st rings. However , t he coding of realvaluedvari ables in finit e-length st rings causes a number of difficulties:inability to achieve arbit rary pr ecision in the obtained solution , fixedmapping of problem var iab les, inh eren t Hamming cliff problem associatedwit h binary coding, and processing of Holland 's schemata incont inuous search space. Although a number of real-coded GAs aredevelop ed to solve optimization problems having a cont inuous searchspace, the search powers of these crossover operators are not adequate .In t his paper , t he search power of a crossover operator is defined int erms of the probability of creating an arbitrary child solut ion froma given pair of parent solutions . Motivated by t he success of binarycodedGAs in discret e search space problems , we develop a real-codedcrossover (which we call the simulated binar y crossover , or SBX) operatorwhose search power is similar to that of the single-point crossoverused in binary-coded GAs . Simulation results on a number of realvaluedt est problems of varying difficulty and dimensionality suggestt hat the real-cod ed GAs with t he SBX operator ar e ab le to perform asgood or bet t er than binary-cod ed GAs wit h t he single-po int crossover.SBX is found to be particularly useful in problems having mult ip le optimalsolutions with a narrow global basin an d in prob lems where thelower and upper bo unds of the global optimum are not known a priori.Further , a simulation on a two-var iable blocked function showsthat the real-coded GA with SBX work s as suggested by Goldberg
and in most cases t he performance of real-coded GA with SBX is similarto that of binary GAs with a single-point crossover. Based onth ese encouraging results, this paper suggests a number of extensionsto the present study.
7. ConclusionsIn this paper, a real-coded crossover operator has been develop ed bas ed ont he search characte rist ics of a single-point crossover used in binary -codedGAs. In ord er to define the search power of a crossover operator, a spreadfactor has been introduced as the ratio of the absolute differences of thechildren points to that of the parent points. Thereaft er , the probabilityof creat ing a child point for two given parent points has been derived forthe single-point crossover. Motivat ed by the success of binary-coded GAsin problems wit h discrete sear ch space, a simul ated bin ary crossover (SBX)operator has been develop ed to solve problems having cont inuous searchspace. The SBX operator has search power similar to that of the single-po intcrossover.On a number of t est fun ctions, including De Jong's five te st fun ct ions, ithas been found that real-coded GAs with the SBX operator can overcome anumb er of difficult ies inherent with binary-coded GAs in solving cont inuoussearch space problems-Hamming cliff problem, arbitrary pr ecision problem,and fixed mapped coding problem. In the comparison of real-coded GAs wit ha SBX operator and binary-coded GAs with a single-point crossover ope rat or ,it has been observed that the performance of the former is better than thelatt er on continuous functions and the performance of the former is similarto the lat ter in solving discret e and difficult functions. In comparison withanother real-coded crossover operator (i.e. , BLX-0 .5) suggested elsewhere ,SBX performs better in difficult test functions. It has also been observedthat SBX is particularly useful in problems where the bounds of the optimum
point is not known a priori and wher e there are multi ple optima, of whichone is global.Real-coded GAs wit h t he SBX op erator have also been tried in solvinga two-variab le blocked function (the concept of blocked fun ctions was introducedin [10]). Blocked fun ct ions are difficult for real-coded GAs , becauselocal optimal points block t he progress of search to continue towards t heglobal optimal point . The simulat ion results on t he two-var iable blockedfunction have shown that in most occasions , the sea rch proceeds the way aspr edicted in [10]. Most importantly, it has been observed that the real-codedGAs wit h SBX work similar to that of t he binary-coded GAs wit h single-pointcrossover in overcoming t he barrier of the local peaks and converging to t heglobal bas in. However , it is premature to conclude whether real-coded GAswit h SBX op erator can overcome t he local barriers in higher-dimensionalblocked fun ct ions.These results are encour aging and suggest avenues for further research.Because the SBX ope rat or uses a probability distribut ion for choosing a childpo int , the real-coded GAs wit h SBX are one st ep ahead of the binary-codedGAs in te rms of ach ieving a convergence proof for GAs. With a direct probabilist ic relationship between children and parent points used in t his paper,cues from t he clas sical stochast ic optimization methods can be borrowed toachieve a convergence proof of GAs , or a much closer tie between the classicaloptimization methods and GAs is on t he horizon.
In short, according to the authors my SBX operator using real gene values is as good as older ones specially designed for discrete searches, and better in continuous searches. SBX as far as i know meanwhile is a standard general crossover operator.
But:
- there might be better ones out there i just havent seen yet. please tell me.
- besides tournament selection and mutation, crossover is just one part of the breeding pipeline. also there is the elite management for MOEA which is AT LEAST as important as the breeding itself.
- depending on the problem, there are almost always better specific ways of how to code the mutation and the crossover operators. but octopus is meant to keep it general for the moment - maybe there's a way for an interface to code those things yourself..!?
2) elite size = SPEA-2 archive size, yes. the rate depends on your convergence behaviour i would say. i usually start off with at least half the size of the population, but mostly the same size (as it is hard-coded in the new version, i just realize) is big enough.
4) the non-dominated front is always put into the archive first. if the archive size is exceeded, the least important individual (the significant strategy in SPEA-2) are truncated one by one until the size is reached. if it is smaller, the fittest dominated individuals are put into the elite. the latter happens in the beginning of the run, when the front wasn't discovered well yet.
3) yes it is. this is a custom implementation i figured out myself. however i'm close to have the HypE algorithm working in the new version, which natively has got the possibility to articulate perference relations on sets of solutions.
…
ome work to create a ZScript macro for custom routines, but you can record those in ZBrush and then merely need to edit them into my script, inline, as bulk multiple-lines you just paste in, no problem as long as you strip the ZBrush button definition at the beginning.
ZBrush has a very high initial learning curve because of its non-standard interface. However, it has the world's most powerful quad remeshing and now mesh Booleans too. I needed a replacement for slow and especially non-robust marching cubes (Cocoon/Monolith/Dodo/Aether etc. on Grasshopper) that tended to bog down or blow up. IntraLattice was a step in a good direction but it can't merge fattened lines that merely cross each other with no breaks or that physically overlap on purpose to have many curve on in to a hub. But with $800 ZBrush 4R8, the latest version, that I can create English language ZScripts for, I suddenly have, often in the blink of an eye, or at worst a few seconds, right back into Rhino Grasshopper, a perfectly joined, airtight and smoothed mesh blending of upwards of thousands of input mesh pieces that overlap in ways Rhino will never Boolean union.
There is no complicated installation of anything since it's all done in Python.
The ZBrush program itself pops up while it works, and is then automatically backgrounded to bring you back to Grasshopper. It keeps running though, for fast iterations with no program startup time.
This is a general toolkit to expose myriad very advanced features of ZBrush into being just another Grasshopper plug-in like the rest.
It works by accepting a Grasshopper mesh and writing it to disk as an OBJ file, then incorporates ZBrush settings for a given command into a text format ZScript file, also written to disk from Python based on Grasshopper inputs, then ZBrush is told to run the script via Windows command line, and the exported OBJ output is read back from disk back into a Rhino Grasshopper mesh, in about a hundred lines of code.
Despite a change in mesh definition in Rhinocommon from version 5 to 6, I made it work on both versions.
So far this is only one command, the newly improved mesh Boolean union. It gives quad meshes, but they still look healthy when quickly triangulated in Rhino (as seen on top, above).
The ZBrush ZRemesher is utterly astounding in ability to transform any mesh into a direction following, error free quad mesh that can be converted to NURBS actually, via T-Splines smooth mode. That will be the next port to Grasshopper. I hope architects pick up on this more orderly manner of patterning surfaces than the alien slime of random point Voronoi.
Commercial software has the best code, not open source stuff, so far, so this is serious work to bring world class tools into Grasshopper where we can rapidly prototype computational strategies.
Here is a thread with several examples of ZBrush Boolean union remeshing applied to 3D trusses, compared to both IntraLattice and marching cubes:
http://www.grasshopper3d.com/forum/topics/custom-unit-cell-bug-in-intralattice-plug-in?commentId=2985220%3AComment%3A1828609
The same strategy of generating script files I used to port OpenFlipper, here, for triangle remeshing, which can now be combined with ZBrush Boolean unions of arbitrary assemblies of mesh units:
http://www.grasshopper3d.com/forum/topics/best-uniform-remesher-for-patterning-organic-suraces
UPDATE: I revamped the workflow so now components feed raw ZScript into a sequencer. Then only a single ZScript is assembled and sent to ZBrush so Python never gets ahead of ZBrush (!):
It is easy to DIY roll your own now:
…
Added by Nik Willmore at 6:48am on October 12, 2017
chitects, Asymptote Architecture, Mario Bellini Architects and others to design the paneling systems.
Get a quick introduction to Rhino and Grasshopper.
Learn how to digitally reconstruction data from 3D scanners and even from regular photographs.
Experience how to print 3D models using state of the art machines.
Grant the opportunity to perform basic energy and performance analysis of your designs.
All this will be provided in a comprehensive 5 days workshop to be taught by international experts in the field as well as local researchers.
Organized by AUC American University in Cairo and GMVS Geometric Modeling and Visulization Center
…
Added by Zaghloul4d at 6:48pm on December 22, 2010
horas.
Los datos al contextualizar la fachada serán:
Vehículos (ISD: input social data)
Personas (ISD: input social data)
Edificaciones contiguas: (UI: urban input)
Sol (Radiación e iluminación): (EFI: energetic flow input)
Creación de energía solar y térmica: (ECI: energetic contribution input)
Objetivos específicos:
Cada asistente generará una fachada contextual a esos 5 inputs.
Entenderá la plataforma de Grasshopper
Comprenderá los conceptos de diseño generativo
Usará los conceptos de programación orientada a objetos (POO)
Generará renders y modelos físicos de la fachada (Fabricación digital)
Costos: $3,250 alumnos $4,180 alumnos de posgrado y profesores $4,830 profesionales
Aulas VI salón 6205, ITESM CEM
Informes: (55)-34449396 mexdf@krfr.org bioarchitecturestudio@gmail.com
Para más información visitanos en:
Fachadas ContextualesWorkshop >Fachadas Contextuales< KRFR|SEEDKRFR|SEED Red Internacional de Investigación OR/gan
http://www.bioarchitecturestudio.wordpress.com
…
: August 15 & 16Time: 8:00am - 5:00pmPrice: US$495
Course Description:
This workshop will give students a functional understanding of Grasshopper and generative data driven design. This will allow them to build on this understanding into more advanced projects of their own including design optimization and cutting models on a laser machine. Basic knowledge of Rhino is required.
Details...
Location:McNeel Miami1538 NW 89th CourtDoral, FL 33172United States
Register here!
…