Full Version: MoI embedded inside CPython 3.91?

Show messages:  1-19  20-39  40-44

Over a 1cm scale:
12 patches almost fit in a unit cube, but not quite.
Pairs of patches, e.g. netP1 and netP2 join up well, with horn to horn distance of 1cm, but the two vertices are off from the corners of the unit cube by ~0.0167468cm.
After line_line these two vertices, the 3rd vertex is about .023733cm short of the center of the cube.
Patch(P1+P2) does not quite adjoin patch(P3+p4), etc.
Will check number of decimals of point coordinates tomorrow.
- Brian

---

The equations in the gyroid paper involve .real and .imag extraction of real number from complex number.
The term e(power(i*theta) = cos(theta) + i*sin(theta) also must have .real and .imag applied at some point.
The paper ignores this, or has typo omitting when to apply this. I am trying some permutations...

Maybe doing the D and P surfaces will help with understanding. Cos(0) = 1, and i*Sin(PI/2) = i, so only a sign change is possible.
- Brian

---

I have been over and over the equations, and also have made python code for the P and D minimal surfaces. None of the wavy triangular-ish surface nets is quite right. The numbers are mostly complex. I now suspect that the mpmath asin or ellipf functions are faulty???
Maybe it is "branch cuts"?
May try mathematica...
- Brian

---

Very promising:
https://pypi.org/project/wolframclient/
https://reference.wolfram.com/language/WolframClientForPython/
Would still need to rent or buy mathematica...
- Brian

---

The Gandy/Klinowski paper appears to have an incorrect formula for the Z coordinate, or my Python program was doing something wrong.
Correcting the modulus squared to (97+0.24484) - 56 * mp.sqrt(3) seems to correct the problem, and all of the 12 patches meet up "perfectly".

Attached are the 12 python scripts for producing the 12 patches of a gyroid boundary surface.
The 12 scripts are the same, except for the ending 3 lines defining X, Y, and Z.
Input is gDomain.csv, created in MoI with SavePointNetwork script
Outputs are gNetP1.csv, gNetP2.csv, ...gNetP12.csv, placed in Desktop. (Adjust paths)
The 12 gNet__.csv files are input to a network of 22 curves in MoI, with the ImportPointNetwork script, run 12 times.
The 12 networks quickly individually Network to 12 surfaces.
The 12 surfaces quickly join to the gyroid boundary surface.

Next to be done is described in Table 2 of the paper, some mirrors and translations.
Eight boundary surfaces make up a triply periodic face-centered cubic unit cell of the G surface. This should be easy to accomplish in MoI.

- Brian

Attachments:
GyroidMarch2_07.7z
gyroidPatch3_2_2021.zip

---

Bounding Cell of the Schwarz Diamond TPMS.
This consists of 6 patches from python program dPatch6, which form a "Pinwheel".
A cplane was placed at the center of the Pinwheel, with the Z circle axis indicator moved to the point shown, at the midpoint of the front upper cube edge.
A mirror was done from said center.

It is hard to grasp all of the mirrors and rotations, etc...

Yet to be done:
4 bounding cells make an octant (1/8).
8 octants make a face centered unit cell of the D surface.

The pipeDomain file is the MoI created initial .csv file, used for both D and P surfaces. Created from a planar .3dm grid network, half of the gDomain grid network.
The 6 dPatch python scripts turn the pipeDomain.csv into 6 point network .csv files for ImportPointNetwork script back into MoI network of curves.

- Brian

Attachments:
dPatchPythonScriptsAndPipeDomain.zip
SchwarzD_March01BoundingCell_6patch_times2_05.zip

---

The boundary cell of the Schwarz-P minimal surface is made up of 6 patches from Python.
The pair of parch surfaces from net Patch pair (P1 plus P2), are revolved along line from pinwheel center to a cube edge middle.
The new pair of surfaces is then axis rotated 120 and -120 degrees, with line from M1 through M7, centered on pinwheel centerpoint.

Not done yet:
It is easy to see how 8 boundary patches create the 6 holed unit cell of the P surface.

- Brian

Attachments:
P_D_PatchFeb2021.zip
SchwarzP_BoundaryCell.7z

---

Forming the Gyroid unit cell from 8 of the 12 patch boundary cells:

Table 2 of the Gyroid paper of Gandy & Klinowski can be understood in terms of 4X4 homogeneous transformation matrices, and also in terms of MoI mirror and move commands acting upon boundary patch surface O1 which consists of 12 basic patches. Surface O1 is represented by all of the points (xprime, yprime, zprime) on its surface. Dropping the prime from the name, one generic point (x, y, z, 1) written in homogeneous coordinates as a column vector, {(x, y, z, 1)T, transposed}, is sufficient to create all of the matrices and corresponding Mirrors, (reflections), and Moves (translations), to build the complete unit cell of a Gyroid.

The move distance unit 'eta' is 1, and the distances moved are 0, 1, -1, or 2 units, along the various axes. The final cube is 2 units on a side.

O1 is located in quadrant 1, with the cube enclosing it aligned with the 3 positive xyz-axes, with lower left corner at the origin.

O2 corresponds to [(-x+2), (-y+1), z, 1]

The corresponding composite matrix, cM01, is: (remember zero indexing.)
row 0: -1 0 0 2
row 1: 0 -1 0 1
row 2: 0 0 1 0
row 3: 0 0 0 1

In Top View:
In row0, the "-1" (and position) denotes mirror in yz plane. For this mirror, select the origin for the 1st point, and select another point, on the y axis, for the 2nd point. The "2" (and position) denotes the Move in the +x direction, of 2 units.

Still in Top View:
In row1, the "-1" (and position) denotes mirror in the xz plane. For this mirror, select the origin for the 1st point, and select another point, on the x axis, for the 2nd point. The "1" (and position) denotes the Move in the +y direction, of 1 unit.

The composite matrix cM01 can be broken down into 2 matrices.
O2 = cM01 * O1 = moveM * mirror_yzM * mirror_xzM * O1.
The correspodiing MoI commands applied to surface O1 are:
mirror_xz, then to result: mirror_yz, then to result: move (2, 1, 0) units.
In this case, the three operations can be applied in any order (???)
(Note that for the Schwarz D surface, (some of) the matrices are rotation, reflection, then move, where order DOES make a difference.)

With practice, certain key row column locations in the 4X4 matrices are recognized for the mirror, and move results. Schwarz D rotations are a bit harder...

Next up is to see if the nodeeditor Mirror will work properly, or not.
Then build a nodeeditor program with Frames, macros for various mirrors, and moves, etc., for G, D, and P surfaces.
Also to do, decompose the 12 steps of Table 1 for the Gyroid fundamental patch, into matrices and nodeeditor program.

For rotations, with a D boundary patch aligned with xyz-axes, the rotations are PI/2, so the cosine matrix entries are zero, and the sine entries are +1. And reflections are xy, yz, and/or xz planes.

- Brian

---

The Gyroid_fcc_UnitCell node builds the face-centered-cubic unit cell of a Gyroid.
The node recapitulates Table 2 of the paper.

The Input is the 12 member Gyroid boundary surface, with default color style "default".
(GyroidMarch2.3dm file.)

The input could alternatively be said surface, offset a small amount, to one side, or both sides.
The 12 individual network curve fundamental gyroid patches can be easily individually networked and offset. (The whole boundary does not offset, but the individual fundamental offsets can be joined.)

Color styles were used for input "Get By Style", because the individual outputs can be set to colors other than the input style. Get By Name could be used, but THERE IS NO OBJECT NAME CHANGE node in nodeeditor AFAIK, so the source fundamental patch is not isolated.

- Brian

Next up is to make a node for Table 1 of the paper, 1 fundamental patch to 12 patch Boundary gyroid patch. This would only need one Python generated basic fundamental patch 1, not 12 Python programs.

Schward D and P tables are yet to be turned into nodes.

Attachments:
Gyroid_fcc_UnitCell.zip

---

For Table 1, the beginning fundamental patch will be Patch0, rather than Patch1. The python code will use the x,y,z point outputs, rather than the X,Y,Z point outputs.
(Note that python X = the papers xprime, etc.)
Application of zeta = 1/sqrt(2), which is sine or cosine of 45 degrees = PI/4, and move of eta = n*(1/4) will be done by gyroidTable1.nod program (still being created).
P0 ===> P1
P0 ===> P2
P0 ===> P3, etc.
It seems that a mirror in the Plane_(Y=Z), X, will be needed for P3. Note that this is NOT the YZ plane, rather it is the plane which includes the x-axis, and is 45 degrees between the Y and Z axes.
A Macro, believed to be correct, partly by trial and error, is attached.

- Brian

Attachments:
Macro_Plane(Y_equals_Z)X.zip

---

gPatchP0_01.3dm is a new network of curves for fundamental gyroid patch P0, via Python math and .css files, without zeta rotation of 45 degrees, and without eta move of n/4. (zeta and eta, greek letters, are defined in Table 1. The typesetter got zeta mixed up with another greek letter.)

GyroidBoundaryFrom_gPatchP0_02_3dm.7z is the nodeeditor program which uses P0 to produce P1 and P2, in MoI, with Table 1 Transformations. (rotate, mirror, move). The node permits quick variations in the +/- rotation degrees, the mirror plane(s), and the move amounts.
Nodes for P3...P12 have not yet been done. The sign of both 45 degree rotations had to be reversed from the angle figured out.

MatrixMultiply4.zip is an Excel 365 program to multipy matrices with number entries, to assist in decomposing each composite matrix for each line entry in Table 1.

Each composite matrix is created manually from the [x, y, z,1] (transposed) vector.
A symbolic matrix multiplier in Excel would be helpful...

- Brian

ps The node program has a macro for the XY plane/frame for mirror can be exported, and a copy placed in the macro folder of nodeeditor.
gPatchP0 network can be networked to a surface. The surface can be offset a little, if desired. The net, or the surface(s) can be input to the node program to yield P1 and P2, etc.

EDIT: Updated .node program and Excel 365 programs are in post 31.

Attachments:
gPatchP0_01.7z
GyroidBoundaryFrom_gPatchP0_02_3dm.7z
MatrixMultiply4.7z

---

Patch P3 and P4 successfully created from P0, with nodeeditor program.
So far, each successive patch has used an additional MoI command / Matrix.

Excel 365 matrix math with numbers is great.
Doing matrix "symbolic" math, like .707*z would require some involved programming... Web searches are not much help.

Decomposing a matrix composed of multiple unknown matrices for revolve and mirror is not so easy, and can have multiple, different, correct solutions.
Some mirror mirror ... operations can be done with rotations & ? ... somehow.
Web search results are too simple or too complicated...Some are for elementary school, and some for mathematicians.

Only 8 more patches to figure out...

Edit: Different symmetry operations to create Patch P3 and P4 were created. See post 33.

Attachments:
MatrixMultiply1234.7z

---

After much study and failed transformations, Table 1 is finally turned into a node, to produce the gyroid boundary patch from pre-fundamental patch P0 to P1.
P1 transforms into P2, and the remaining 10 patches. Must write it up. I think clockwise 90 degree rotations and ccw 90 degree rotations are inconsistant with respect to x, y, and z axes and +/- 90 degrees?
It also helps to think in terms of world axes.

- Brian

---

A concise node program to create the 12 patch gyroid boundary patch is complete. Use of some Macros makes the wiring look much better.
The Inversion center permits half of the 12 patches to be simply inversions of the other 6 patches. A simple inversion macro is included in one of the macros, which can be added to the symmetry operations repertoire.
The initial patch P0, created in Python is attached. Either the netP0, or the surfaceP0 may be used, or both, as input to the node program. The surface P0 could be extruded a bit, if desired.
When a rotation axis is pointed at the observer, for a Clockwise rotation of 90 degrees, use +90 for the Euler angle in the rotate node. This is contrary to the right hand rule and contrary to the convention that CCW rotation is positive.
The symmetry operations of Table 1 are complete. It took a long time to figure out how the symmetry operations work. The symmetry operations apply to the MoI World axes. To create say P3 from P1, notice that xprime equation of P1 needs to be negated with an initial mirror with yz plane. Then rotate about MoI x axis clockwise, by +90 degrees. This shifts (rotates) zPrime equations of P1 to yPrime equations of P3. Then rotate about MoI y axis by +90 degrees clockwise. This shifts (rotates) the old yPrime equations of P1 to the xPrime equations of P3, and the old xPrime equations of P1 to the zPrime equations of P3.
The last step is a simple move (translation) of n*eta = n*(1/4). In summary, it seems to be a lot easier to "rotate" the equations of table 1 from P1 to P3 and P11, and invert to P5, P7, and P9, and similarly from P2 to P4 and P12, and invert to P6, P8, and P10, rather than try to decompose matrices.
The new SetName node belongs in the nodeeditor extensions folder.

- Brian

Attachments:
GyroidPatch_P0_to_BoundaryPatch12.zip
GyroidPreFundamentalPatchP0.7z

---

I have been reading forum posts about shellExecute, and reading lots of google searches, with very limited results, and poor understanding.

# In Windows 10, the line of code below, following these comments, will open a python window from the MoI command box.
# Note that python 3.9.2 is already installed in the path shown.
# Note that it is necessary that \ are doubled in the path, and path must be correct.
# In MoI4, press Tab, and paste the line of code into the MoI command box and press enter.
# Code:
moi.filesystem.shellExecute( 'C:\\Users\\orcha\\AppData\\Local\\Programs\\Python\\Python39\\python.exe' )

# This Code works too:
moi.filesystem.shellExecute( 'C:\\Users\\orcha\\AppData\\Local\\Programs\\Python\\Python39\\python' )

# In Windows 10, the line of code below, following these comments, will open Rhino7 from the MoI command box.
# Note that Rhino7 is already installed in the path shown.
# Note that it is necessary that \ are doubled in the path, and path must be correct.
# In MoI4, press Tab, and paste the line of code into the MoI command box.
# Code:
moi.filesystem.shellExecute( "C:\\Program Files\\Rhino 7\\System\\Rhino.exe" )

Michaels Example code works:
var res = moi.filesystem.shellExecute( 'cmd /c dir c:\\', '', true );
if ( res.output ) moi.ui.alert( res.output );

So far, I have been unable to pass any python code or arguments, nor will the following code do anything:
var res = moi.filesystem.shellExecute( 'C:\\Users\\orcha\\AppData\\Local\\Programs\\Python\\Python39\\python sys.stdout.write("I am a test")', '', true );
if ( res.output ) moi.ui.alert( res.output );

I guess Windows stdout is different from python stdout?

(Still reading google searches...)

- Brian

---

Hi Brian, does it behave any better if you pass the parameters as the second argument to moi.filesystem.shellExecute() ?

Something like this:

var res = moi.filesystem.shellExecute( 'C:\\Users\\orcha\\AppData\\Local\\Programs\\Python\\Python39\\python', 'sys.stdout.write("I am a test")', true );
if ( res.output ) moi.ui.alert( res.output );

- Michael

---

Michael, thank you for having a look.
Nothing happens with your suggestion.

Your posts to Shane https://moi3d.com/forum/index.php?webtag=MOI&msg=9890.40 reminds me of this link:

https://memyselfandpython.wordpress.com/2018/01/14/opening-python-programs-in-command-prompt-windows-and-open-txt/
It looks like I can run python program through windows CMD...?

Still learning a lot.

- Brian

So is the RhinoPasteFromMoi.py program run in Rhino7? or MoI, or ?

---

Hi Brian,

Are you 100% certain that your path and filename to python is correct?

Because your path here does not target a file with an .exe file extension:

> C:\\Users\\orcha\\AppData\\Local\\Programs\\Python\\Python39\\python

re:
> So is the RhinoPasteFromMoi.py program run in Rhino7? or MoI, or ?

That's for running in Rhino, if copy from MoI and paste into Rhino is not working.

- Michael

---

Hi Michael,
I'm 99.9% sure that the path to python.exe is correct. (Never 100% sure:-)

For Windows 10:
(Also refered to as command prompt), the command interpreter, Cmd.exe has 10 parameters, 9 of which are "switches":
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/cmd

A Windows 7 version which might be helpful:
https://sourcedaddy.com/windows-7/using-cmd-switches.html

/c is a switch

I take it that moi.filesystem.shellExecute(...) is running the Windows 10 shellexecute?
(Or some Mac equivalent...?)

The Command Prompt in Windows provides access to over 280 commands:
https://www.lifewire.com/list-of-command-prompt-commands-4092302

- Brian

Also interesting:
https://stackoverflow.com/questions/48437377/cmd-commands-in-shellexecute
Previous link, links to:
https://www.codeproject.com/Articles/5163375/Tiny-CMD

---

MAYBE?: I found some possible code at this "stocks and bonds program" site:
https://forum.amibroker.com/t/can-we-run-a-python-script-using-shellexecute/6125

ShellExecute("C:\\Program Files\\AmiBroker\\YOURPYTHONFILE_v1.py","","",0);

Have to try them out tonight.

I believe/guess Windows 10 already has path to python.exe, so just need to add the testProgram.py???

- Brian

SheBang talk, Windows and OS X:
https://automatetheboringstuff.com/appendixb/

Also see:
http://www.amibroker.com/guide/afl/shellexecute.html

Well, my theory is that some of this is relevant to using shellExecute from the MoI command window. (???)

One more link for now:
https://docs.microsoft.com/en-us/windows/win32/shell/shell-shellexecute
(There is some JScript/ Javascript code, plus an example.)

I think that what I am trying to do is to run some python code from MoI, or Nodeeditor, to apply Math to e.g. gyroid wdomain point(curve) network csv file, which is currently done manually.

---

Show messages:  1-19  20-39  40-44