erning how to do that on a sphere.
So I know already all the different approches of how to get a relaxed voronoi pattern on a free-form open surface, but still don't know how to obtain the same elegant effect on a sphere (or an ellipsoid closed surface, whatever), or how to relax the facet dome cells.
Andrew stated on his site that he used kangaroo for this project, so the Spore Lamp consists in my opinion either of a relaxed voronoi 3d diagram (b-rep, b-rep intersection) on a sphere the cells of which have been planarized later on, or more likely it is a sort of relaxed facet dome.
The trick is to:
1. obtain a nicely-balanced voronoish diagram (or facet dome cells) on a sphere
2. keep each cell/polyline planar (or force them with kangaroo to be planar) in order to move scale and loft them later on.
Here is what I have by now.(files: matsys spore lamp attempt)
That's the closest appearance that I got so far (simple move scale and loft of facet dome cells with the amount of transformations being proportional to the power of the initial cell area: bigger cell = bigger opening etc.) - with no relaxation of the diagram. But it's obviously not the same thing as the matsys design.
Here are some of my attempts of facet dome relaxation, but well, it's certainly still not the right approach, and most importantly I don't know how to keep or force the cells to be planar after the relaxation.
1. pulling vertices to a sphere - no anchor points. That obviously doesn't make sense at all, but the relaxation without anchor points gives at the beginning a pattern that is closer to what I am looking for. (files: relaxation 01)
2. pulling vertices to a sphere - two faces of the initial facet dome anchored (files: relaxation 02)
3. pulling vertices to the initial geometry (facet dome) no anchor points (files: relaxation 03)
The cell pattern of the lamp kinda looks like this:
You can find it here: http://www.grasshopper3d.com/forum/topics/kangaroo-0-095-releasedgroupUrl=kangaroo&x=1&groupId=2985220%3AGroup%3A120977&id=2985220%3ATopic%3A972434&page=2#comments
Done with Plankton (of course without the "gradient increase" appearance), but in fact not, I took a look at Daniel Parker's Plankton example files, and it's not quite the same thing. Also the cells aren't planar...
The last problem is that during the relaxation attempts that I did, the biggest initial cells became enormous, and it's not like that in the elegant project by Andrew Kudless, that I'd like to achieve.
So to sum up:
Goal no 1: Obtain an elegant voronoi /facet dome cell pattern on a sphere (or an ellipsoid surface, whatever).
Goal no 2: How to keep the cells planar in order to be able to loft them later, obtain those pyramidal forms, and assemble easily
Have you got any ideas? Or maybe there's a completely different approach to that?
Cheers, and thanks in advance…
ch has a vertex in each of the vertices of the polyline. But, when I try to create the mesh using the Mesh Brep component, I get a simplified mesh, where the extra vertices in the edges of the polyline have disappeared. I think it is easier to understand what I am trying to say with the following screenshots:
Polyline:
Mesh created with the rhino command:
Mesh created using grasshopper:
The last mesh has less faces, as the Mesh Brep component gets rid of the extra vertices that define the polyline.
Any suggestions?
Thanks,
Diego…
imeBinder.CSharpArgumentInfo.Create'
Is it possible to solve this issue?
using System;
using IronPython.Hosting;
using IronPython.Runtime;
using Microsoft.Scripting;
using Microsoft.Scripting.Hosting;
using Microsoft.CSharp;
namespace Bob.Meshes {
public class pythonFromCShapr {
ScriptEngine engine = Python.CreateEngine();
public pythonFromCShapr() {
}
public void something() {
dynamic scope = engine.CreateScope();
scope.Add = new Func<int, int, int>((x, y) => x + y);
Console.WriteLine( scope.Add(2, 3));
}
}
}…
le and grasshopper timer to simplify simulation control. Double click the main Kangaroo component to open this remote. There are buttons for Stop(reset), Play, Pause, and Step (moves the simulation forward one iteration).
Line-line force - allows interaction between line segments - they are treated as rigid cylinders. As with springs, there are settings for offset and rest distance, so this can be used to simulate colliding rods, and also for keeping cylinders tangent to one another (can be used for reciprocal structures).
Gear simulator - collision between curves in a plane, can be used for various mechanical simulations - cams, gears, rack and pinions etc.
Developablize force - adjusts vertices of a mesh locally, to make angles around each interior vertex sum to 2*Pi, so the mesh can be unfolded to a flat sheet without stretching.
Volume dependent pressure force - allows you to set a rest volume for a mesh instead of just a fixed pressure. When combined with Laplacian smoothing for area minimization, this can be used to optimize for CMC (constant-mean-curvature) surfaces. It will also work on open meshes.
Translation lock - maintains a fixed relationship between a pair of points. This can be used to enforce periodic boundary conditions for TPMS.
Equalize angles force - given a set of angles (defined by 3 points each), this tries to adjust them all to become equal.
Mirror symmetry force - can be used to minimize curvature variation, and optimize for higher order curve continuity. It can also be used for simulating torsional resistance in curved rods.
True minimal surface relaxation - Laplacian smoothing force now includes an option for cotangent weighting, which optimizes for zero mean curvature, unlike spring based methods, or uniform weighted Laplacian smoothing which only roughly approximate this.
Fast sphere collide - allows much faster collision detection between large numbers of spheres. By placing these spheres at the vertices, this can also be used for collision between meshes.
Force-density element - an experimental one, more on this later
Projected-force - adjusts its strength so the component of the force in a given direction stays constant.
New mesh tools:
WarpWeft - sorts the edges of a quad mesh into warp and weft directions. This can be used to assign them different stiffness in fabric form-finding.
Checkerboard - sort the faces of a mesh into 2 lists so that 2 faces of the same colour are never adjacent.
MeshDirection - sorts the vertices of a quad mesh to give it a sort of u-v directionality
Refine Strips - subdivision in one direction only - can be used to generate developable strips
Stripper - separates out the strips of quads from a larger mesh
Unroller - unfolds a quad strip to flat without stretching
MeshMap - maps points from one mesh to another (can be used together with circle-packing to generate conformal mappings)
Reciprocal structure - generates starting geometry for a reciprocal structure from any input mesh (using the Plankton mesh library *Note* If you already have the Plankton components installed, you will need to update to version 0.3.0, which is available from here)
ReMesher - adjusts the connectivity of a mesh by flipping, splitting and collapsing edges to make all edge lengths closer to a target value
Diagonalize - creates a new face for every edge of the original mesh. Can be used on quad meshes to easily convert to a diagrid.
Refine - simple non-smoothing subdivision, splitting quads into 4 quads, and triangles into 4 triangles
QuadDivide - subdivide quads by any number squared, not just powers of 4
Corners - finds the corner vertices of a quad mesh
ByParent - simple quad subdivision, keeping the output grouped by parent face.
User objects:
The download comes with an increased collection of user objects to simplify setting up common simulation types - Including a simple to use origami simulator, a reciprocal structure generator, and a tool to generate compact circle packings from a CP mesh.
General:
Geometry input now accepts polylines and straight curves.
Hinges can now be fold completely flat in both directions.
Various other minor bug fixes and speed improvements (including much faster removeDuplicatePoints/Lines components)
*****
I've not yet updated all the documentation and example files to reflect this new version, but over time I will keep posting here with new demos and explanation of all these new features. I'll try and add a few new examples each week. Vote in the comments below if there is a feature mentioned above that you're particularly keen to hear more about soon.
No doubt there are still some bugs to be discovered. If something isn't working the way you expect or want it to, please post in this forum (ideally with a description or sketch of what you think should be happening, and a clear description of what happens instead and any error messages).
There are also some more new features that weren't quite ready to make it into this release, but are on the way shortly...
Kangaroo remains completely free, for personal, academic, and commercial use. I'm always interested to hear about projects done using it, and suggestions for improvements or additions.
Daniel
…
ger work.
Be aware, this release breaks file-forwards compatibility. You will not be able to open gh and ghx files saved with 0.8.0050 on previous versions, though of course you should be able to open old files without problems. If this is not the case, please yell loudly.
If you're having trouble loading Grasshopper, note that you must have the latest Microsoft C++ Runtimes installed on your machine. They can be downloaded from the microsoft website.
The new release can be downloaded from the usual location.
Here's a list of changes, additions and fixes since 0.8.0013:
File format forwards compatibility has been broken. You will not be able to open files saved with 0.8.0050 on earlier versions.
This release contains many breaking changes and GHA libraries compiled for older version may not work anymore.
Grasshopper Binary files (*.gh) are now saved as compressed data.
Grasshopper Binary files (*.gh) are now the default format.
Support for ancient versions of the Text Panel (still called Post-It from back then) has been removed.
Support for ancient versions of the Path Mapper (still called Path Lexer from back then) has been removed.
Placeholders for ancient versions of the Graph Mapper have been removed.
Gradient input parameters now show state tag icons (Reversed, Flatten etc.).
Geometry Cache name changes are now updated on every key press.
Geometry Cache name changes can now be cancelled with Escape.
Geometry Cache name changes can now be undone.
Mesh|Mesh intersection component now uses a different algorithm. The old behaviour is still available from the component menu.
Warning and Error balloons are now drawn as part of a Canvas Widget and will no longer show up in the Hi-Res image export.
Galapagos now accepts multiple fitness values. The true fitness will be the average of the collection.
Galapagos wires are drawn much fainter when the Galapagos object is unselected.
Medium fast redraw mode in Galapagos now immediately redraws instead of at the end of each generation.
Redesigned all Grasshopper file format icons and added larger size icons for high-dpi explorer views.
Redesigned the Most Recently Used files menu, it should now display much quicker.
Compass widget has been rewritten in an attempt to increase display performance.
Added preferences section for Compass widget.
Added preferences section for Align widget.
Added preferences section for Default Preview colours.
Added preferences section for Document Preview colours.
Added preferences section for the Most Recently Used files menu.
The Area component now accepts Breps, Meshes and Planar Closed Curves.
The Area Centroid component now accepts Breps, Meshes and Planar Closed Curves.
The Volume component now accepts Breps and Meshes.
The Volume Centroid component now accepts Breps and Meshes.
Added Merge Faces component (Surface.Util panel).
Added a Mesh Smooth component (Mesh.Util panel).
Added a Curve Seam component (Curve.Util panel).
Added Interpolate Curve With Tangents component (Curve.Spline dropdown).
Added GrasshopperFolders command to open Settings, Components and UserObject folders without loading the core plugin.
The window that reports on certain Loading Errors now has a Copy button.
Added Simplify post-process filter to parameters (in addition to Reverse, Flatten and Graft).
Parameter post processes (Reverse, Flatten, Graft & Simplify) can now also be assigned to output parameters.
Version History window now has formatting (not happy with this, I'm working on something better).
The Process Info window is gone.
Main menu has been redesigned.
Canvas toolbar has been redesigned.
Canvas context menu has been replaced by a Radial Menu.
Canvas now has a radial menu which will pop up on Middle Mouse Button clicks.
It's possible to switch between Radial and Legacy menus in the Preferences (Interface.Canvas section).
'Save As Copy' feature has been replaced by 'Save Backup' which is a GUI-less save including date+time stamp.
Added a 'Show in Folder' item to the File menu.
AutoSave settings are no longer available from the File menu, you now need to use the Preferences.
Selection shifts now also modify the view so you can use Ctrl+Left and Ctrl+Right to navigate up and downstream.
Mesh Edge display can now be toggled with Ctrl+M.
Preview modes now have shortcuts (Ctrl+1 = no preview, Ctrl+2 = wireframe, Ctrl+3 = shaded).
Solution States now have a default name.
Data Viewer window now responds to all required events.
Data Viewer window can now handle input and output parameters as well.
Canvas Navigation pane can now be dragged using the icon in the upper left corner.
The Persistent Data Editor has been redesigned.
It's now possible to select multiple items in the Persistent Data Editor list and edit their properties.
It's now possible to drag multiple items at the same time in the Persistent Data Editor list.
Item addition to the Persistent Data Editor is much improved.
The Persistent Data Editor is now non-modal.
The Canvas would remain black upon maximizing the Rhino window, this is fixed.
Sliders would cause multiple updates under certain conditions, this is fixed.
Digit Scrollers would cause multiple updates under certain conditions, this is fixed.
Pipes were inside out. This is fixed.
The curve component would not adjust invalid nurbs degrees, this is fixed.
Curves referencing Brep edges failed to load, this is fixed.
Points referencing Brep edges failed to load, this is fixed.
Referenced dlls in the VB/C# components sometimes resulted in invalid imports statements, this is fixed.
Pasting geometry in Rhino would cause a recompute of the Grasshopper solution, this is fixed.
Importing a file into the Rhino document would cause a recompute of the Grasshopper solution, this is fixed.
Galapagos would trigger superfluous solutions, this is fixed.
Mesh Solid Difference had a wrong name and description, this is fixed.
Several menu items were not greyed out despite not being usable, this is fixed.
The position and size of the Grasshopper window failed to get stored on Rhino shutdown, this is fixed.
The Persistent Data Editor would crash on parameters that did not support data proxies, this is fixed.
I'll add some additional information regarding some of the new UI features in subsequent posts.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
rmation?" I know that this can already be accomplished using the brilliant Kangaroo plugin, but I wanted a simpler and faster (yet still accurate) single component that could replicate this unique curve using a variety of inputs: the length of the rod/wire, the width/distance between the endpoints, the height of the bend, and the tangent angle at the start. I also wanted make the unknowns (such as height if only length and width are known) easily accessible for plugging into additional components.
The resulting script, being an all-in-one solution, is somewhat unwieldy, but it could easily be broken down into smaller components (custom .gha's which I don't have the ability to code). If someone wants to tackle this, please do! I'm not an expert coder by any means, and as this was only my second time diving into Grasshopper scripting, if the script seems somewhat strange, that's probably why. I did try to comment the code pretty well though. Here's the full description:
--------------------------------------------------
DESCRIPTION: This beast creates the so-called 'elastica curve', the shape a long, thin rod or wire makes when it is bent elastically (i.e. not permanently). In this case, force is assumed to only be applied horizontally (which would be in line with the rod at rest) and both ends are assumed to be pinned or hinged meaning they are free to rotate (as opposed to clamped, when the end tangent angle is fixed, usually horizontally). An interesting finding is that it doesn't matter what the material or cross-sectional area is, as long as they're uniform along the entire length. Everything makes the same shape when bent as long as it doesn't cross the threshold from elastic to plastic (permanent) deformation (I don't bother to find that limit here, but can be found if the yield stress for a material is known).
Key to the formulas used in this script are elliptic integrals, specifically K(m), the complete elliptic integral of the first kind, and E(m), the complete elliptic integral of the second kind. There was a lot of confusion over the 'm' and 'k' parameters for these functions, as some people use them interchangeably, but they are not the same. m = k^2 (thus k = Sqrt(m)). I try to use the 'm' parameter exclusively to avoid this confusion. Note that there is a unique 'm' parameter for every configuration/shape of the elastica curve.
This script tries to find that unique 'm' parameter based on the inputs. The algorithm starts with a test version of m, evaluates an expression, say 2*E(m)/K(m)-1, then compares the result to what it should be (in this case, a known width/length ratio). Iterate until the correct m is found. Once we have m, we can then calculate all of the other unknowns, then find points that lie on that curve, then interpolate those points for the actual curve. You can also use Wolfram|Alpha as I did to find the m parameter based on the equations in this script (example here: http://tiny.cc/t4tpbx for when say width=45.2 and length=67.1).
Other notes:
* This script works with negative values for width, which will creat a self-intersecting curve (as it should). The curvature of the elastica starts to break down around m=0.95 (~154°), but this script will continue to work until M_MAX, m=0.993 (~169°). If you wish to ignore self-intersecting curves, set ignoreSelfIntersecting to True
* When the only known values are length and height, it is actually possible for certain ratios of height to length to have two valid m values (thus 2 possible widths and angles). This script will return them both.
* Only the first two valid parameters (of the required ones) will be used, meaning if all four are connected (length, width or a PtB, height, and angle), this script will only use length and width (or a PtB).
* Depending on the magnitude of your inputs (say if they're really small, like if length < 10), you might have to increase the constant ROUNDTO at the bottom
REFERENCES: {1} "The elastic rod" by M.E. Pacheco Q. & E. Pina, http://www.scielo.org.mx/pdf/rmfe/v53n2/v53n2a8.pdf {2} "An experiment in nonlinear beam theory" by A. Valiente, http://www.deepdyve.com/lp/doc/I3lwnxdfGz {3} "Snap buckling, writhing and Loop formation In twisted rods" by V.G.A. GOSS, http://myweb.lsbu.ac.uk/~gossga/thesisFinal.pdf {4} "Theory of Elastic Stability" by Stephen Timoshenko, http://www.scribd.com/doc/50402462/Timoshenko-Theory-of-Elastic-Stability (start on p. 76)
INPUT: PtA - First anchor point (required) PtB - Second anchor point (optional, though 2 out of the 4--length, width, height, angle--need to be specified) [note that PtB can be the same as PtA (meaning width would be zero)] [also note that if a different width is additionally specified that's not equal to the distance between PtA and PtB, then the end point will not equal PtB anymore] Pln - Plane of the bent rod/wire, which bends up in the +y direction. The line between PtA and PtB (if specified) must be parallel to the x-axis of this plane
** 2 of the following 4 need to be specified ** Len - Length of the rod/wire, which needs to be > 0 Wid - Width between the endpoints of the curve [note: if PtB is specified in addition, and distance between PtA and PtB <> width, the end point will be relocated Ht - Height of the bent rod/wire (when negative, curve will bend downward, relative to the input plane, instead) Ang - Inner departure angle or tangent angle (in radians) at the ends of the bent rod/wire. Set up so as width approaches length (thus height approaches zero), angle approaches zero
* Following variables only needed for optional calculating of bending force, not for shape of curve. E - Young's modulus (modulus of elasticity) in GPa (=N/m^2) (material-specific. for example, 7075 aluminum is roughly 71.7 GPa) I - Second moment of area (or area moment of inertia) in m^4 (cross-section-specific. for example, a hollow rod would have I = pi * (outer_diameter^4 - inner_diameter^4) / 32 Note: E*I is also known as flexural rigidity or bending stiffness
OUTPUT: out - only for debugging messages Pts - the list of points that approximate the shape of the elastica Crv - the 3rd-degree curve interpolated from those points (with accurate start & end tangents) L - the length of the rod/wire W - the distance (width) between the endpoints of the rod/wire H - the height of the bent rod/wire A - the tangent angle at the (start) end of the rod/wire F - the force needed to hold the rod/wire in a specific shape (based on the material properties & cross-section) **be sure your units for 'I' match your units for the rest of your inputs (length, width, etc.). Also note that the critical buckling load (force) that makes the rod/wire start to bend can be found at height=0
THANKS TO: Mårten Nettelbladt (thegeometryofbending.blogspot.com) Daniel Piker (Kangaroo plugin) David Rutten (Grasshopper guru) Euler & Bernoulli (the O.G.'s)
--------------------------------------------------
Edit: More on the math behind this here.
Cheers,
Will
…
Added by Will McElwain at 4:08pm on February 26, 2014
curve or locus] of a segment AB, in English. The set of all the points from which a segment, AB, is seen under a fixed given angle.
When you construct l'arc capable —by using compass— you obviously need to find the centre of this arc. This can be easily done in GH in many ways by using some trigonometry (e.g. see previous —great— solutions). Whole circles instead of arcs provide supplementary isoptics —β-isoptic and (180º-β)-isoptic—. Coherent normals let you work in any plane.
Or you could just construct β-isoptics of AB by using tangent at A (or B). I mean [Arc SED] component.
If you want the true β-isoptic —the set of all the points— you should use {+β, -β} degrees (2 sides; 2 solutions; 2 arcs), but slider in [-180, +180] degrees provides full range of signed solutions. Orthoptic is provided by ±90º. Notice that ±180º isoptic is just AB segment itself, and 0º isoptic should be the segment outside AB —(-∞, A] U [B, +∞)—. [Radians] component is avoidable.
More compact versions can be achieved by using [F3] component. You can choose among different expressions the one you like the most as long as performs counter clockwise rotation of vector AB, by 180-β degrees, around A; or equivalent. [Panel] is totally avoidable.
Solutions in XY plane —projection; z = 0—, no matter A or B, are easy too. Just be sure about the curve you want to find the intersection with —Curve; your wall— being contained in XY plane.
A few self-explanatory examples showing features.
1 & 5 1st ver. (Supplementary isoptics) (ArcCapableTrigNormals_def_Bel.png)
2 & 6 2nd ver. (SED) (ArcCapableSED_def_Bel.png)
3 & 7 3rd ver. (SED + F3) (ArcCapableSEDF3_def_Bel.png)
4 & 8 4th ver. (SED + F3, Projection) (ArcCapableSEDProjInt_def_Bel.png)
If you want to be compact, 7 could be your best choice. If you prefer orientation robustness, 5. Etcetera.
I hope these versions will help you to compact/visualize; let me know any feedback.
Calculate where 2 points [A & B] meet at a specific angle is just find the geometrical locus called arco capaz in Spanish, arc capable in French (l'isoptique d'un segment de droite) or isoptic [curve or locus]
of a segment AB, in English. The set of all the points from which a segment,
AB, is seen under a fixed given angle.…
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.
…