I would like to create a mesh based on ellipsoid curvature curves.
First I was wondering to get curvature lines and intersect in u and v directions. But I believe there is some specific way to create a mesh of this form.
Could someone point me where to start?
I searching for only one form - ellipsoid similar to subdivision in these references
Probably not the route you want to go, but these look like oblate elliptical coordinates, and the âisocurvesâ come from setting various parameters to constants. You âcouldâ generate these curves as polylines for ranges of parameters, explode them and then use Weaverbirdâs Mesh from Lines. Easy for me to say, of course.
For the continuous case I believe what you show are confocal quadrics.
For the discrete version though, according to the paper by Simon Schleicher et al that your first figure comes from, to get the planar quad mesh discretization there with the touching incircles, they used the quasiisothermic mesh layout approach of Sechelmann et al, as described in this paper.
The touching incircle energy described in that paper is actually something I added as part of the latest Kangaroo release.
Hereâs an example of applying it to an ellipsoid: isothermic_ellipsoid.gh (17.4 KB)
Could you please shine some light on the attached trial to get the isothermic goal working? isothermic_v1.gh (24.7 KB)
The mesh edges are currently approximately following principal curvature directions. Even when the goal has a relatively small, close to negligible, strength compared to other control goals, the mesh seems to âexplodeâ nonetheless. How may I properly setup the workflow? Thanks!
For the isothermic goal to work, the initial mesh needs to be either fairly good to start with, or quite free (in terms of fixed corners/boundaries, or pulling onto surfaces).
If a grid is fully aligned with principal curvature directions, there canât ever be any odd valence irregular vertices. It seems these isothermic meshes can sometimes still work with some, but lots of automatic quad meshers give an output with too many valence 3 and 5s, which tend to cause problems.
Also, at the moment, when the angle of the quads goes beyond some limit, the isothermic goal can become unstable. I think I can fix this to make it stable for a wider angle range, or at least to switch itself off when the limit is passed.
Isothermic meshes have fairly square quads (since each quad has an incircle, and a rectangle cannot have an incircle). So if the aspect ratio of the initial grid isnât good, and the boundaries are fixed, it might not be able to reach a good solution.
Leaving the boundary free can make it much easier to get to an isothermic grid on a freeform curved surface. One way to do this is if you can extend your surface far enough beyond all the boundaries of the region you want, to allow the grid boundary to slide around.
Iâve also got a new goal, which Iâll post tomorrow, that pulls the points of a grid onto a surface, but also
lets points slide off the edge of the surface, so you can avoid having to create this extended target surface.
I took your mesh and cut out some of the more problematic areas, released the corners and boundaries, and applied that goal I mentioned above that lets points slide off the edges, and this is what happens: TT_reply.gh (41.4 KB)
If you let it slide around a while it finds a more natural orientation on the surface, and then you can slowly increase the strength of the isothermic goal to enforce that constraint exactly
I thought the aspect ratio of the faces in the initial mesh was not too terrible, but was not thinking about the valences and how odd ones may be causing the issue. I was under the impression that by following the curvature directions, it would actually help to find the direction of the quad edges, hence I put together a adhoc script to find a mesh that is made up of quad faces that roughly align with those directions of a given surface; attached is the portion of the script that @ThomasE also asked about above (isothermic_v1_pre.gh (77.9 KB)). The internalized curves are found using the method Tom Jankowski shared in the comment section of this post. The network is meshed with Weaverbirdâs Mesh from Lines and then relaxed using K2 and the resultant mesh was what I first shared yesterday.
Might you have any advice on perhaps combining the two workflow instead of separating them into two solver instances? (Also, what is the Range input doing in the slideoff goal?) I was thinking that I could probably just project/pull a square grid onto the initial mesh and let the isothermic goal finds the natural orientations, but am not getting a meaningful result so far (it seems like the initial mesh after your adjustments is still performing better than just a simple square grid?): isothermic_v2.gh (41.5 KB)
The âRangeâ input in the SlideOff goal is the maximum search distance. For each point in the goal, if it is within this range of the target mesh, and its closest point on the mesh is not on the boundary of the mesh, it gets pulled towards that point.
Optimising the quad mesh geometry at the same time as generating the connectivity would indeed be great. Fully automatic high quality quad meshing remains a tough problem, and it is often necessary to manually design the mesh a bit to get a good result.
Looking at how you generate your initial mesh, it seems a large part of the problem is that the curvature field does not match the boundaries of your surface, yet you are forcing the grid to.
Also as I mentioned above, to match a principal curvature field, only even valence irregular vertices are allowable, but this process is creating several valence 3 and 5 vertices that shouldnât be there. It looks from the lines youâve traced there that the only irregular vertex that should really be there is that valence 6 towards the top left (and possibly another 6 in the top right corner, though that might end up outside the boundary).
What Iâd do here is create a coarse quad version of that initial mesh manually informed by this curvature field, then subdivide before optimising.
Thank you very much, Daniel.
This is particularly illuminating for me:
Does this imply that if the field, or the subdivision, simultaneously approximately aligns with the curvature and also the boundary, it would be an ideal starting geometry?
Regarding the workflow to obtain a curvature aligned quad mesh as a prerequisite though, is there anything youâd change from what was shown?
If the input surface has its principal curvature directions matching its boundaries, then great - that makes things easier.
Frequently though we have to deal with geometry where this isnât the case, meaning a planar quad mesh canât possibly align with both the boundary and the curvature field, since they conflict.
For instance - this patch of a cylinder - it would be impossible to make a planar quad mesh aligning with the boundary, since it is diagonal to the curvature directions:
In these cases it is better to make a mesh matching the curvature directions, but extending beyond the boundaries. It wonât be possible to have full quads meeting the boundary, but you can sometimes still shift the vertices a little to make it node out cleanly with triangular half quads.
That makes a lot of sense - Enabling the finding of a solution by first extending the geometry is something that I havenât really been thinking about or am used to, so the approaches have been limited; thanks a lot again for all the explanations!
I would like to ask about circle packing in quads.
When circle packed mesh has a quad dual mesh with also packed circles? Is it always a case: when a quad mesh have incircles and its dual has incircles too, or it happens for certain cases.
I am asking this because I looking for a quad mesh offset, that has planar lattice.
For these S-Isothermic meshes (each quad has an incircle, and the points of tangency of these incircles match between adjacent quads), in the plane, you can always draw a circle through the points of tangency around a vertex to form another circle packing (shown in red below).
You can also apply Möbius transformations to these meshes in the plane, so that they instead lie tangent to a sphere, and the red circles stay tangent.
However, I believe that these are the only cases where the points of tangency also lie on circles like this - for S-Isothermic meshes in general, each quad still has an incircle, but the points of tangency only lie on a common sphere, not on the same plane.
Unfortunately conical meshes are not preserved by Möbius transformations.
Circular meshes are though.
(because Möbius transformations take circles to circles, and preserve angles)
Circular meshes also have an offset mesh, with constant vertex-vertex distance(in contrast with the face-face offset with conical meshes).
So far I only added tools for face-face offsets from conical meshes, but it should be possible to add vertex-vertex offsets too (just need to calculate the correct normal). There is also a way to convert between circular and conical meshes with a sort of dual operation using reflections about the edges, and I was planning to add a tool for this at some point.
Iâll also try and post some examples for conical meshes. At the moment this is probably the easiest route (depending what kind of surfaces this is on, and what offsets or support structures you need)
Here are a couple of examples with the Conicalize goal.
Note that (unlike the CyclicQuad and Isothermic goals) this goal doesnât ensure planarity on its own - you need to add a Planarize goal too. This is because there are some applications where it is useful to apply the angle condition for conical meshes but on non planar quads (in particular, asymptotic gridshells).
Also shown here is the face-face offset mesh component generating torsion free beam layouts.
One shows something you can sculpt by dragging points around, while the other pulls the mesh onto a target surface. With both you start with the conical/planar strength low while shaping, and slide it all the way up at the end. The offset component will give strange results before the mesh is properly conical. conical_demo_pull.gh (21.7 KB) conical_demo.gh (52.0 KB)
âŠand hereâs a similar example with a circular mesh, also including generation of the vertex-vertex offset mesh: circular_mesh_demo.gh (21.3 KB)
(I realised that for V-V offset, the standard Weaverbird offset works)