Issues and Errors in OCTO surface

[3DLIRIOUS]

First, thank you for compiling this excellent catalog and dataset! It is super helpful to have all of this information in a central location. I have implemented the equations described in the catalog in Curv, an open source solid modeling language that uses SDFs and implicit equations to describe shapes. I would be happy to contribute this library to the dataset if you are interested. I was able to duplicate the images in Section 3 of the catalog (although some appeared rotated compared to the catalog images), with the exception of the OCTO surface. This caused me to dig into the source materials, and I discovered an error in the catalog, and perhaps in the source materials as well. However, these errors do not seem to account for the differences I am seeing rendering these in Curv compared to the source materials.

For reference, here are the relevant equations from the source materials identified in the catalog:

Wohlgemuth et al. (2001)

Hsieh and Valdevit (2020)

Hoffman et al. (2003b) (the original source is gone, but thank goodness for the Internet Archive)

Using Eq. 20 from the catalog A(CxCy+CyCz+CzCx) + B(Cx+Cy+Cz) + C(CxCyCz) + t0 = t we can produce a table similar to Table 10 in the catalog, which we will call Issue Table 1:

and Table 10 for comparison:

Two issues seem apparent. First, there appears to be an error in the catalog Table 10 for the last equation, namely that the coefficients B and C appear swapped compared to the source (cells highlighted in yellow). Second, Hsieh and Valdevit (2020) seem to have done something similar, swapping the B & C terms compared to their cited source Wohlgemuth et al. (2001), as well as changing the level set t0 significantly.

Here are what the original source equations in Issue Table 1 above look like when rendered in Curv, color coded to the source cells in the table:

Only the last surface (blue) appears correct. In the first (yellow), it is obvious that the level set is much too high, so the shape is quite clipped. For the 2nd and 3rd surfaces, their corners seem so large that they are merging on the edges.

For comparison, I set the t0 of the first equation to the same as the second equation, namely 0.25. For the 2nd & 3rd, I flipped the sign of the B coefficient, as it seems that this should be positive to reduce the corner size. Here is the modified table, Issue Table 2, with the modified cells highlighted in yellow:

Here is what those modified equations look like as rendered in Curv. The shapes appear much closer to what is expected.

Here is what my parametric version of the OCTO equations looks like in the tpms.curv library:

tpms_octo_para =
    let tpms_octo_para_func {d, level, a, b, c, t0} =
        make_shape {
            dist[x,y,z,_] = a*(cos(tau/d.[x]*x)*cos(tau/d.[y]*y)
                            + cos(tau/d.[y]*y)*cos(tau/d.[z]*z)
                            + cos(tau/d.[z]*z)*cos(tau/d.[x]*x))
                            + b*(cos(tau/d.[x]*x) + cos(tau/d.[y]*y) + cos(tau/d.[z]*z))
                            + c*cos(tau/d.[x]*x)*cos(tau/d.[y]*y)*cos(tau/d.[z]*z)
                            + t0
                            - level
                            ;
            is_3d = true;
        };
    in make_shape {
        ... tpms_octo_para_func {d:[1, 1, 1], level:0, a:4, b:1, c:-2.8, t0:1.5},
        call : tpms_octo_para_func,
    };

These are called as such, e.g. in tpms_octo_visualization.curv:

tpms1a = tpms_octo_para {d:unit_cell, level:level_set, a:0.6, b:0, c:-0.4, t0:-1}; // 2.8 Wohlgemuth et al. (2001)
tpms2a = tpms_octo_para {d:unit_cell, level:level_set, a:0.6, b:-0.4, c:0, t0:0.25}; // 2.8 Hsieh and Valdevit (2020)
tpms3a = tpms_octo_para {d:unit_cell, level:level_set, a:4, b:-3, c:0, t0:2.4}; // 2.8 Hoffman et al. (2003b)
tpms4a = tpms_octo_para {d:unit_cell, level:level_set, a:4, b:1, c:-2.8, t0:1.5}; // 2.8 Hoffman et al. (2003b)

I am puzzled as to why others seem to have been able to plot the equations in Issue Table 1, errors and all, yet these are rendering quite differently in Curv. The other 26 equations appear to render correctly in Curv, so it seems unlikely to me to be some sort of error with Curv itself, but it's possible.

Attached are the following files so that you can duplicate my results: tpms_curv.zip

• tpms.curv - the TPMS library
• tpms_visualization.curv - example file to visualize the shapes in the tpms.curv library. It attempts to duplicate the images in Section 3 of the catalog.
• tpms_octo_visualization.curv - this generates the shapes pictured above using the parametric OCTO equation.

You can download a precompiled Windows version of Curv which can run these files. This is also linked from my repository.

[jwf23]

Thanks for reaching out and for providing such a detailed write-up! It took me a really long time to wrap my head around what was going on, because like you, I wasn't able to find anything wrong with your work in Curv, and I scrutinized my work also to see if I had done something wrong and I couldn't seem to find anything. I was finally able to dedicate most of yesterday and this morning to staring at these implicit fields and I finally found an answer!

TLDR: We are generating the same fields/lattices but inverted and offset by a half period in x, y, and z.

What I found is that in my nTop blocks I got the exact same result that you did in Curv when using the coefficients in Issue Table 1 if I flipped the sign of the B and C terms in each equation. This made no sense to me until I started looking at the fields generated by each of the three terms separately and I found something interesting.

Figure 1. Zero level sets of (from left to right), the “A”, “B”, and “C” terms visualized separately in nTopology. The light gray sides of the surfaces are “outward” facing and the very dark gray sides are “inward facing.

The “A” term generates a sort of 3D checkerboard like grid of identical "puffy" cubes with centers at middle of the unit cell, as well as the corners (i.e., offset by half a period in x, y, and z). So, there is no difference between a unit cell centered at (0,0,0) or (P/2, P/2, P/2) with just this term.

So here is why this works out in such a way that it caused all this confusion, the “B” term (which is the same as the P surface equation) and the “C” term (which is the same as the F surface equation) are both congruent with a half period translation in x, y, and z. So, a unit cell of one or both of these terms centered at (P/2, P/2, P/2) is the exact inverse of a unit cell from the same terms at (0,0,0).

I was able to confirm this in Curv by setting num_cells = 2 in tpms_octo_visualization.curv and the red, green and light blue unit cells that looked wrong when num_cells = 1 now look correct (in a 2x2x2 cell grid) and the dark blue cells now look off.

The good news is that the issues appear to be on our end, and I believe your work is correct. For our current database contents, I plan to go back through and redo my analysis comparing the below sets of coefficients to the model exported from Surface Evolver to decide what equation gives the best fit of the geometry of the TPMS. I think it would be great to include this in the catalog to make these interesting structures more accessible. I hadn't heard of Curv before, I like that it is free and open, so I'll definitely be checking them out!

<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

A | B | C | t0 | Source -- | -- | -- | -- | -- 0.6 | 0 | -0.4 | 0.25 | Wohlgemuth et al. (2001) 0.6 | 0.4 | 0 | 0.25 | Hsieh and Valdevit (2020) 4 | 3 | 0 | 2.4 | Hoffman et al. (2003b) 4 | 1 | -2.8 | 1.5 | Hoffman et al. (2003b) 4 | 2.8 | -1 | 1.5 | My incorrect transcription of Hoffman et al.

I'm going to leave this issue open until I've had a chance to perform the analysis and determine the goodness of fit for the different equations which might change which equation we recommend in the summary table for the OCTO surface. Let me know if you have any questions or thoughts on my approach!

Joey Fisher

[3DLIRIOUS]

Thank you so much for looking into this and discovering the root cause! Unfortunately this looks like a rookie mistake on my end. To visualize the unit cell in Curv, I intersected the infinite surface with a size [ 1, 1, 1] box. However, by default, Curv creates the box axis-aligned, so it's boundaries are [ -0.5, 0.5 ] in each direction. I now realize that your unit cell was size [ 0, 1 ] in each axis, so there is the source of the half period offset! To correct this, I've added a move statement to the box to move it so the corner is at the origin, and also added show_axes to confirm that the unit cell is located correctly, e.g.: tpms1a_surf `intersection` (box (num_cells*unit_cell) >> move (num_cells*unit_cell/2)) >> show_axes

With this correction, here's what the Issue Table 1 coefficients looks like rendered in Curv. The red and green now look correct, while the blue is offset.

And here's what my "corrected" Issue Table 2 looks like with the [0, 1] unit cell. Now everything is offset a half period.

Since it looks like the original equations were mostly correct after all, I might suggest that you take a look at the original coefficients for the red and green equations instead of my version with the flipped signs, e.g.

A	B	C	t0	Source
0.6	0	-0.4	0.25	Wohlgemuth et al. (2001)
0.6	-0.4	0	0.25	Hsieh and Valdevit (2020)
4	-3	0	2.4	Hoffman et al. (2003b)
4	1	-2.8	1.5	Hoffman et al. (2003b)
4	2.8	-1	1.5	Incorrect transcription of Hoffman et al.

I'll update my library to whichever variant you decide to recommend!