algorithmic modeling for Rhino
Around 3 years ago I wrote an essay on my blog about what I called rheotomic surfaces - a type of surface I had developed related to fluid flow and electrostatics, and a technique for their generation using complex numbers.
Since then I have received a lot of questions from people interested in the details of exactly how these surfaces and their associated curvilinear orthogonal grids were generated.
Now I've packaged it up into a Grasshopper object with an easy interface, and am releasing it publicly so anyone can experiment with this tool.
(See this video for an example of it in action)
When the idea of using the streamlines of a flow to generate a surface first occurred to me, I thought the way to go about this would be to integrate a 2d vector field from various seed points and then move these lines vertically and loft between them - but after a lot of head scratching and experimentation, I was amazed to discover that it is actually possible to skip that step altogether.
In this technique, the surface is generated first, by moving the points of a mesh vertically from the complex plane according to the scalar values of their real and imaginary components, to generate 2 separate meshes. One of these meshes gives the rheotomic surfaces described in my essay, with helicoid shaped regions near the sources and sinks, and its contours are the streamlines of the flow (hence the name). The other mesh has sharp funnel shaped regions, and its contours give the equipotentials of the flow, orthogonal to the streamlines.
One of the advantages this technique has over vector field integration methods is that there is no problem of choosing seed points for streamline placement, and nice even spacing happens automatically. We also avoid the difficulties with cumulative error common to such methods.
By multiplying by other complex factors it is also possible to generate lines at specific angles to the streamline/equipotential directions and create various grid types.
Also because of the mesh contouring technique, these are actual vector curves being created, not just pixel based mappings.
Because the complex logarithm function is multivalued, dealing with the mesh in a way that avoids a sudden jump at the branch cuts does require a bit of special treatment, and it is not quite a straightforward height map, but I found that it is possible to avoid the usual techniques for contouring a 3d scalar field.
This definition outputs both the curves and the meshes. The meshes produced are singly periodic - you can make copies vertically shifted by 2*Pi to get a continuously spiralling surface, and if you also shift them by 1*Pi you get the other half of the helicoids, and it can all be joined into a complete and smooth surface.
So enjoy, I hope you find some interesting and original ways of using and developing this. Please do remember to attribute properly - a lot of effort has gone into this, but I'm freely sharing it in the hope that will be respected.
I've chosen not to compile or obfuscate anything, so you can easily pull it apart and see how it is all working. The original essay linked to at the start contains some suggestions of further reading if you want to learn more about complex numbers and flows.
The file: Rheotomic_Surfaces.gh
Released under the creative commons attribution share alike license 3.0
Comment
hey daniel!
great work!
I tried to download the file but somehow i canot open the file in grasshopper. I curently have version 080066, would you have any idea why this is happening?
thanx alot!
Excellent!
Good idea Michael - I could also throw in a few of the other bits and pieces I've done over the last few years - DLA, 4Drotations, inversion... Expect a 'bonus' tab in the next Kangaroo release!
Very nice, I wonder why not just toss it in with kangaroo as a bonus? Thanks for it.
Hi Panhao, thanks for pointing this out. The problem arises if a source/sink lies exactly on a mesh vertex, because complex Log(0) is undefined (it's like asking the longitude of the North Pole), and returns NaN. It should be reasonably simple to put in a check to avoid this.
There are probably a few other minor bugs too. A couple I've noticed and should fix:
- not working if 2 charges of the same sign lie in the same horizontal row of the mesh (this causes a sort of double jump in the surface, which would need an extra condition to allow for)
- not working in the actual mesh square containing a source/sink - ie the part on the axis of the helicoid.
As for the equivalent in 3d - it's a really interesting question and one I've often considered. I'll write a full post about it soon. In 3d it makes more sense to look at singularities which are lines (vortex filaments) instead of points. As Hamilton found though - there is no nice equivalent of complex numbers in 3d. However, if you jump to 4 dimensions... (to be continued)
Sorry, I fond our algorithm might be the same.We choose the same way to solve the 'jump' of mesh vertex where the image shows. And this method has a bug. If the position of the points where the lines come from are too close to the mesh vertex.The mesh component wound not work. In short if Ur mesh size was 40*40 the mesh component would be red.
I'd like to pass my script(*.ghx file) to you.Could you leave a email or MSN.Mine is 4812ph@163.com
Of course the algorithm come from the website U mentioned below.I use 300*300 iso box to simulate the pixel.The process is similar to 2D metaballs.
I fond a 3D type of flowline in Ur blog many months ago.(http://spacesymmetrystructure.wordpress.com/page/2/
where my friends and I click every week.)
It seems possible to use 100*100*100 iso box to generate the 3D version.But the equation of the z axis makes me confused.
Hi Panhao,
Yes, in this definition you will see that most of the components are there to give the user control of all the different options. Sure, the surface generation part is mathematical and can be done in just a few lines of code, but the point here was to make something lots of people can easily engage with.
But if you've found a nicer way of generating this, then I'd certainly be interested to see what you've done differently. You say you translated some processing code - was it the one from bitcraft I linked to below ?
The difference is that I use iso web to generate the polylines.As a result the lines can't get too close to the source point where I put some big,heavy circles.
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson. Powered by
You need to be a member of Grasshopper to add comments!