That’s great. As for contributors - I hadn’t given it much thought yet, but it could be good. Is there any particular aspect you’d be interested in collaborating on?
I’ve already worked on a couple of projects using implicits and I think a solid library for Rhino/Grasshopper is absolutely necessary. In my last project (called PicoGH) I used OpenVDB / PicoGK as the backend kernel because it comes with meshing and some other useful stuff. This project does lack a lot of the features that you’ve implemented here, specifically the field visualisation, using custom SDF equations, etc, but I think what could be really neat is having the heavy computational stuff and meshing handled by OpenVDB as another option, since its pretty fast.
What are your future goals with this library?
I’d love to show you some of the stuff I’ve got in development if you wanted to reach out to me, toby.wilkinson339@gmail.com
3 Likes
Cannot get it to work here.
I install from Package manager Isopod 1.0.4.1 Restart Rhino, Open grasshopper. I see the Isopod tab. Try to open the example files and get this:
I press Download and Install
I restart Rhino. Open Grasshopper, try to open example file get the same error:
Tried uninstalling and going through the same steps but the same issue persist.
What am I doing wrong?
interesting stuff! great work @DanielPiker !
I also did some implicit surface meshing in 3ds MAX back in 2009 . it is actually good candidate for mass parallel computing as each voxel can be resolved independently . I will look into it if I get time.
2 Likes
Is it possible, using Isopod or otherwise, to create a lattice structure that follows the shape of an object, rather than just being orthogonal (?)
So take the mesh in the attached file… rather than the lattice filling the bounding box of the shape and being trimmed to the shape’s boundary, create a lattice that is morphed to flow along the shape? Controlling the density of the lattice along the shape so it could be denser in the middle or ends?
MeshLatticeFollowShape.gh (24.1 KB)
2 Likes
Hi @siemen, sorry for the late reply. Did you get it working in the end? Which version of Rhino are you running?
1 Like
@martynjhogg Yes, indeed.
Making lattices or other infill that follows the directions of some boundary shape instead of simply being trimmed by it is an interesting topic. It’s still an open area of research that nobody has really fully solved. There are a number of different approaches possible, but they each have their limitations.
If we have (or can create) uv parameters for the boundary (either as a NURBS surface, or with mesh texture coordinates), these can be used as a mapping for any implicit (such as a TPMS etc), because we can take u and v of the closest point as x and y, and height above the surface as z, then evaluate our input function at that xyz.
This approach works okay near the surface, but breaks down as you go deeper inside thick volumes though. It also gets very heavy to calculate because of all the closest point parameter queries.
In theory you could tackle mapping deeper inside with a full volumetric parametrization (like a hexahedral mesh with uvw coordinates at each vertex), but creating good volumetric parametrizations for arbitrary shapes is a very hard problem in itself (hexahedral meshing is hard already, and when you want not just the mesh but also a parametrization, it gets even harder). I’m not aware of anyone using these for mapping implicits.
We also need to consider that (for both surface or volume based parametrization), only some TPMS are compatible, depending on the continuity type of the mapping.
For instance, a cell of the Schwarz P surface can meet another cell with a perpendicular parametrization, but if you do this with a Gyroid, you get a discontinuity.
For any parametrization based method, there’s also the question of how it compares to an explicit technique. If you’re working with something where you can get a good parametrization, I think in many cases it would be more efficient to do something like explicitly box morphing your unit cell.
The spinodoids I wrote about earlier are one way of avoiding the problems of parametrization, and let you create aligned structures simply from directions provided at a few points. What’s more, with these you can locally vary the scaling independently of the direction, which is impossible with parametrization.
Another approach is to generate Delaunay tetrahedral meshes and thicken the edges of this (or its dual Voronoi) into struts. This avoids the arbitrary trimming of simply taking a world aligned TPMS and chopping it, but of course it also loses the directionality.
Yet another one that might be interesting to try would be to take a curve and make the mapping based on frames at the closest point. It might be significantly lighter than doing a full surface uv type mapping.
4 Likes
I didn’t get it to work and was running 8.10 while trying.
Do you have the COFF loading option off?
Thanks so much for making this @DanielPiker , really amazing plugin. Already solved the issue of multipipe deforming input radii as well as so many other applications!
3 Likes
SmoothUnionMulti k factor.gh (248.3 KB)
Hi Daniel.
SmoothUnion and SmoothUnionMulti, both have the “k” factor that we can use as pseudo-radius for the pseudo-fillet created be the smoothing… correct? (somehow)
To obtain similar results that “k” value must be really different from the single A+B compared the the “sum/multi” version… there is a logic behind to anticipate the result and so set up a correct value or… ?
1 Like
Hi Riccardo,
First to give a simple answer - to get similar results, use k * 1 for the multi version, and k * 4 for the pairwise version.
For the smooth union operators I found Inigo Quilez’s page here very helpful.
There are a number of different ways to do smooth unions, each with their own pros and cons.
I’ve made implementations of most of the ones one that page - I’ll share a file tomorrow, just need to update it to use the current version.
SmoothUnionMulti uses exponential blending (which lends itself well to lists of fields), while the pairwise version uses polynomial.
I wanted to not make the interface too confusing, but maybe an option to choose the blending type on the smooth booleans could be good.
I should probably also include the normalisation of the smoothing factor, so they don’t need such different values when switching blend types.
It’s a bit different from normal surface modelling in that fillets with curvature continuity and higher becomes easy, even for complex situations where fillets overlap, but conversely something like a pure rolling ball fillet with constant radius becomes hard.
One other thing to note about these is that all these blending modes as given on that page except for circular do not have a finite local range outside of which they have exactly zero effect - though they fall off so the blending becomes effectively zero far enough from the join. Potentially though any of them could be combined with a bump function like in the spinodoid example to keep their effect bounded within a fixed range.
4 Likes
I for one greatly appreciate being able to see the source.
Thanks.
1 Like
As mentioned in my last post - here’s a comparison of all 8 blend types from that page:
blend_types.gh (15.1 KB)
The differences are quite subtle, and I think for most purposes exponential is fine, but having these options may come in handy in future.
3 Likes
Thanks for the link! I were studying those now but your blend types script came faster than my understanding.
Do you know if there is a way to tackle this problem?
A couple of “half tube” (but my final fields are more complex)
At different heights the top one is smooth:
but at the same height, the k factor creates a “bump”:
a k factor of 0 removes the bump, but also the smoothing:
isopod boolean tests 016.gh (106.2 KB)
a weak workaround i found is to multiply the planes fields, but that means many other multiplications down the road.
I would do the highest plane intersection for the last operation, but I have not a stable order of those “half tube” fields, and they might intersect each-other in many places with different heights.
Similar concept, unwanted bumps:
isopod boolean tests 017.gh (167.5 KB)
(In this case the fields are from meshes, so far less control over the situation, it’s just an example, my real situation is more similar to the case above, with compound fields…)
3 Likes
I had been looking at this paper, which describes a blend that I think is closer to what you are after, by weighting between a blend and a clean union depending on the angle between the gradients:
I’ll have a go at implementing this soon
9 Likes
As always, super interesting paper!
You bring so much knowledge, Daniel!
I’m having a brain fart reading all of that.
I understand that:
- the paper is in english
- the images suggests a lot!
Fields currently only hold/output the value, a double type number. (Is this correct?)
By how are currently fields, I’m not sure how to get gradients.
Either I’ll shift the field a bit in X Y and Z, but this seems a lot of repeated calculations = stupid.
Or by creating 3 additional fields for the X,Y,Z components of the gradients, but this still seems a lot of work for the final “engine”…
Needing vectors (gradients), probably it would be best to just start from the primitive geometries and do all the work inside a single component, which will again output a simple value field… so while it compute the closest point we can have the distance value and the vector at the same time, and apply those operators described in the paper…
How much far I’ve got it? 
I’ll try too.
2 Likes
You’re along the right lines.
I would probably implement their gradient based blend inside a single custom field component, so there’s no need to be passing vector fields along GH wires here.
There’s already a method to get the normal vector of any Isopod scalar field at any point, which is just a unitized gradient (not sure if that paper needs the magnitude of the gradient - if so it’s simple enough to add a method for the non-unitized version).
Here’s an example of calling that within a field to get a new field which is the angle between the normals of 2 input fields:
normals_angle.gh (22.6 KB)
2 Likes
Oh wait your IField class already have a .NormalAt method!?
So this assumption of mine:
is wrong!
I can’t “explore” isopod methods because I am not receiving any tooltips about Isopod.gha and its library…
.NormalAt … everything is already there to implement the other operators!
1 Like
Some experimental sculpting with ellipsoids
This uses a new ellipsoid primitive, which is defined by a plane and 3 radii, but rather than have separate inputs for each of these it takes a box or extrusion as input and uses the orientation and dimensions of this.
To speed up modelling I set up a Rhino file with geometry pipelines, so you can just copy paste boxes to add new ellipsoids without having to switch to Grasshopper and reference each time:
Ellipsoid_sculpt.gh (18.0 KB)
Ellipsoid_sculpt.3dm (216.7 KB)
Layer A is for ellipsoids you want one copy of in the model, Layer B is for ellipsoids that you also want a copy of mirrored about the Y axis.
Layers C and D are similar, but blended with a lower smoothing factor (I found it helpful to have high smoothing for the combining of the large base shapes, and lower smoothing for smaller details).
When moving the boxes around with the gumball, I found it helpful to have it set to
Align To Object.For horizontal scaling it can also help to relocate the gumball for the box so that it lies on the midpoint of an edge instead of the default corner location (you can relocate from the gumball menu accessed by clicking its white circle).
This lets you make adjustments to the horizontal scale without breaking symmetry.
It takes a bit of adjustment as a way of modelling, and there’s certainly room for improvement in the workflow, but I find it quite nice to sculpt in a more clay-like way without having to think about patch layout or topology as you go*, and being able to adjust earlier parts at any time.
*and you can always quadremesh to subd at the end, or do manual patch layout and pull that onto the isosurface
Useful for early stage shape development? Fun? What do you think?
14 Likes