I tried to generate gyroid surface by using equations. But in grasshopper, what I could have done is just to generate the points from the equation and failed to turn the points in to mesh or surface.
Could it be that I did it wrong from the points generation phase?
I was also inspired by a definition posted a long time ago in the old forum by Vicente Soler.
Warning - this definition is hideously slow (a cube of 20x20x20 cells takes around 30s to solve on my machine), and embarrassingly crude. It was more just a proof of concept to see if it could be done, and would need a lot of optimization before becoming a really useful tool.
I'm posting it here anyway on the chance that someone might find it helpful as a starting point for a faster version. Looking at it again now, I can see that there are quite a few easy small improvements that could be made to avoid recalculating some values, but I think to really get it up to decent speeds there would need to be some sort of octree type iterative approach. So rather than checking the field values for every one of the smallest cells, start with a coarse grid, and only subdivide the cells the surface passes through, then repeat on those smaller cells, until reaching the desired cell size and contour them. Maybe one could even do this through HoopSnake
Daniel Piker
For drawing such implicit functions / level sets / isosurfaces we need a way of contouring a scalar field.
As this is a question that seems to come up fairly frequently, I thought I'd post this definition I made about a year back.
It uses the marching tetrahedra approach, for which I found this page by Paul Bourke very helpful:
http://paulbourke.net/geometry/polygonise/
I was also inspired by a definition posted a long time ago in the old forum by Vicente Soler.
Warning - this definition is hideously slow (a cube of 20x20x20 cells takes around 30s to solve on my machine), and embarrassingly crude. It was more just a proof of concept to see if it could be done, and would need a lot of optimization before becoming a really useful tool.
I'm posting it here anyway on the chance that someone might find it helpful as a starting point for a faster version. Looking at it again now, I can see that there are quite a few easy small improvements that could be made to avoid recalculating some values, but I think to really get it up to decent speeds there would need to be some sort of octree type iterative approach. So rather than checking the field values for every one of the smallest cells, start with a coarse grid, and only subdivide the cells the surface passes through, then repeat on those smaller cells, until reaching the desired cell size and contour them. Maybe one could even do this through HoopSnake
Jul 5, 2011