X and Z directions in 3D PGA swapped (cheat sheet and README.md)?

[joha2]

First of all: Great project! Your siggraph19 talk together with this project helped me a lot in understanding geometric algebras and in particular their application to computer graphics!

When I tried to follow the calculations, I saw two things in the cheat sheet (line definition for 3D PGA) as well as in the README.md file in Section R*(3,0,1) which I don't understand: First in the README.md file there is a line: var origin=1e123, EX=-1e012, EY=1e013, EZ=-1e023; From my calculations I just took three planes which are perpendicular to each other and are expected to intersect in the point (x, y, z): p1 = e1 - x e0, p2 = e2 - y e0, p3 = e3 - z e0 then I calculated the wedge product between all these to get the intersection point: p1 wedge p2 wedge p3 = e123 - x e023 - y e103 - z e120 This contradicts with the definition shown in the README.md file from above in which e.g. EX = e012 which is in my calculation the z direction.

The second point is: For the line definition I just intersected (e.g. for the X direction) the planes perpendicular to y and z: py = e2 pz = e3 => py wedge pz = e23 whereas in the line definition is written line = ... d e12 + ..., which also contradicts (if d is supposed to be the X component).

So did I do some calculation error? Or is this a typo? Thanks for your help and keep up the good work!

Best wishes Johannes

[skydog23]

Hi @joha2, I can address the second question, regarding the line. The formula on the 3D cheat sheet involves the norm of a line. The full specification of a line involves six coordinates: ae01+be02+ce03 + de12+ee31+fe23, but since the norm formula only involves the final three coordinates and we had limited space, we left the first three out. What these six "Pluecker" coordinates mean: the (x,y,z) direction vector is given by (f,e,d) (notice the reverse order!). The line (0,0,0,d,e,f) is a line through the origin with direction (f,e,d); (a,b,c,d,e,f) is a translation of this line in the plane perpendicular to (a,b,c), preserving the direction. I've just looked in the course notes and noticed that I don't find an explanation of these Pluecker coordinates. If that's true, then I will certainly add such a discussion, and thanks for bringing this to my attention. --Charles Gunn

[joha2]

Hey @skydog23! Thanks for your fast response! So for the second question: If I understood correctly, this means that just the written form in the cheat sheet for the line is in a different order than from what one would expect in cartesian coordinates? And that is to be compatible with the "Pluecker" form? So, simplify spoken, just my last assumption ("d is supposed to be the X component") is wrong, isn't it? I didn't check the course notes thoroughly on this, since I just observed that the order of the elements seems not to fit.

Another question comes to my mind, while typing: From the part 2 of the talk I took away that PGA simplifies also the generation of product geometry like a torus. Apart from the simplification to calculate with geometric entities via PGA, is there a trick to perform the rendering of this geometry via OpenGL (i.e. translating it into rendering ready triangle/quad forms with PGA maths), or does one have to do it the hard way (i.e. collecting all triangles with their appropriate vertexes in the right orientation and render them)? The ganja.js source is a bit difficult for me to understand due to my lack of experience with OpenGL as well as ES6. A short hint in the right direction would be very helpful :-)

Best wishes Johannes

[skydog23]

@joha2 : Yes, you're right, if you break up the 6D Pluecker coordinates for lines generated by wedging two planes together into two 3-vectors (e01,e02,e03) and (e12, e31, e23), then the second vector (that gives the direction of the line) is in (z,y,x) order.

I'll also take a stab at your first question, regarding "EX=-1e012". That does appear to me to be a typo in README.md. The EX and EZ have been swapped. If you look at the previous example in the README.md file (with the algebra (2,0,1)) then the assignments are correct: var origin = 1e12, EX=-1e02, EY=1e01;. That is, when dealing with points, the important index is the one that is missing. In e012, that's 3, which corresponds to the z-coordinate.

Regarding your new question regarding rendering a torus in PGA, that is definitely something that the code author @enkimute (Steven De Keninck) is better qualified to answer.

[joha2]

Hey @skydog23 ! Thank you for the fast response and your confirmation, see #86 . For the rendering questions, maybe it is the best to ask in the forum of bivector.net, isn't it?

Best wishes Johannes

[enkimute]

Hi @joha2,

Thanks for the kind words (and thanks @skydog23 for your quick response). To address the rendering question, there are several ways to approach this. The easiest starting point is to indeed sample the motor-generator at regular intervals, generating vertex positions (by applying the motor to the origin), and normals (by applying the motor to an infinite point), and proceeding as usual in your vertex shader. (which is what ganja.js does now)

Alternatively, compute or mesh shaders could be used to generate the geometry on the fly, or instead of storing position/normal/tangent, one could opt to store a dual quaternion instead.

I'm investigating some of the advantages/prerequisites/applications for each of these methods and hope to have a new paper out on that soon.

Cheers,

Steven.

[joha2]

Hey @enkimute ! Thank you for your immediate response, the nice hints, and for merging my pull request! I'm eager to read that paper :smile_cat: Please give me a ping when the paper is available online :D Since all questions of this issue are clear I will close it. Thanks again for your help @enkimute and @skydog23 .

Best wishes Johannes

[joha2]

Hey @enkimute and @skydog23 sorry for reviving old issues.

I played around a bit with 3D PGA and it turned out that it was quite difficult for me to understand how to interpret the Pluecker-form of the line bivectors. After lots of wikipedia "research", I saw that the components e01, e02, e03 contain exactly the "moment" of a line (I for myself could not interpret the quantities arising there after checking it for a plane intersection and a point pair. I didn't even know that such quantity exist, but it seems similar to the angular momentum in physics, but I hadn't expected it in this geometrical context). Further at wikipedia they wrote that "moment" and direction of a line alone - as appearing in the Pluecker form - determine it not uniquely, but together in a sense of a homogenious coordinate pair (d:m).

But this does not help, when you search for a starting point to draw it. For me it took quite a time to figure out that the projection (line|e123)*line gives you a valid starting point.

Maybe for others quite new to this matter, it would be useful to comment on that somewhere. All other primitives are more or less straight forward to interpret (and draw), but lines bothered me a few days. Am I right, that a bivector is only an actual line iff bivector wedge bivector = 0?

Thanks for your help! Best wishes Johannes

[enkimute]

Hi Johannes,

Spot on - this is called the Plücker condition. If a bivector is non-simple it represents a screw axis.

Cheers,

Steven.

[joha2]

Hey @enkimute thanks for your fast response! Ah yeah, I read about it in the course notes. Could a screw axis be represented graphically in any sense?

Best wishes Johannes

[enkimute]

Yes it's a line of which the points don't stay in place, but the line does.(short answer, on phone)

Cheers,

Steven

On Sat, May 23, 2020, 20:54 joha2 notifications@github.com wrote:

Hey @enkimute https://github.com/enkimute thanks for your fast response! Ah yeah, I read about it in the course notes. Could a screw axis be represented graphically in any sense?

Best wishes Johannes

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/enkimute/ganja.js/issues/85#issuecomment-633117019, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLHMI2PYCSV3A7LBRPL2WTRTALVPANCNFSM4NDEBELA .

[joha2]

Short, but very fast answer :smile: So it's more or less like a spiral?

[enkimute]

Exactly (with a zero radius but that's hard to visualize)

Steven

On Sat, May 23, 2020, 21:01 joha2 notifications@github.com wrote:

Short, but very fast answer 😄 So it's more or less like a spiral?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/enkimute/ganja.js/issues/85#issuecomment-633118258, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLHMI7OB4FTP2RGKNK7XCTRTAMPZANCNFSM4NDEBELA .

[skydog23]

@joha2 If a bivector is not a line, then it is the sum of two skew (non-intersecting) lines -- and you can choose this pair of lines in infinitely many ways. By choosing this pair carefully you can see which screw motion the bivector represents. That choice is described in the course notes in Sec. 8.1.3: you end up with the axis (the invariant line) of the rotation part of the screw motion plus an ideal line which is the axis of the translational part of the screw motion. The screw motion can be obtained either by first performing the rotation and then the translation or first the translation and then the rotation -- they commute. Of course the axis has to be "perpendicular" to this ideal line (like a vertical line is perpendicular to the horizon line). All this can be precisely described in terms of Pluecker coordinates. I leave it as an exercise:-)

[joha2]

@enkimute and @skydog23 thanks for your fast and thorough responses. This sheds some light on the whole matter for me :smile: Maybe I come back in the future when there are other problems arising. :-)

BTW: Do you plan to publish any general results for higher dimensions, too? I am also interested in this stuff.