In your PGA library, I guess the e1, e2, e3 basis elements correspond to the YZ, ZX and XY planes (so the planes x=0, y=0, z=0). Is that correct? Is the orientation also correct, e.g. e1 has orientation Y-direction towards Z-direction, e2 Z to X, and e3 X to Y?

And I guess e0 corresponds to the "plane at infinity" (w=0). Is it possible to also assign/visualize an orientation to e0? For example, when I'm looking at e0 along any direction vector (imagining e0 are the "stars" on a "sphere at infinity") does it have a clockwise or counter-clockwise orientation?

I'm porting your code to C#, and I'm trying to add some more comments to the code, but I don't fully understand PGA yet... I'm re-reading Charles Gunns SIGGRAPH paper to get a grip on it.

Maybe I should ask these questions on the bivector.net forum or discord?

Testing an example of blending with Motors of PGA and I got nan as a result. Here is a sample code:

	float W[] = {0.2f,0.1f,0.3f};

	kln::motor M0(kln::translator(10.0f,1.0f,0.0f,0.0f)); 
	kln::motor M1(kln::rotor(3.1416, 1.0f, 0.0, 0.0f));
	kln::motor M2(kln::rotor(1.0472, 0.0f, 1.0f, 0.0f));

        // removing W[0]*kln::log(M0) is OK
	kln::line blendedLine = W[0]*kln::log(M0) + W[1]*kln::log(M1) + W[2]*kln::log(M2) ;

	kln::motor blended_Motor = kln::exp(blendedLine); 
        std::cout << blended_Motor(kln::point(0.0f,0.0f,0.0f)).x()<<std::endl;

It might come from the fact that the log of translator results in an ideal line whereas the log of a motor is a real line in general.

Well. I built the tests without any problem in environment Windows 10 x64 with Microsoft Visual Studio 2019.

By running them some are successfully passed on. For example, sym_test.exe.

However there are problems with klein_test.exe

DJuego

Hi @jeremyong, nice library!

Is branch generally accepted term for a line passing through the origin, or a name you chose? I couldn't find a wider confirmation of the term..

I believe there is a bug in this code:

    motor& KLN_VEC_CALL operator=(translator t) noexcept
    {
        p1_ = _mm_setzero_ps();
        p2_ = t.p2_;
        return *this;
    }

The rotator p1_ should be set to identity instead of zero.

Set CMake project version to 2.3.0 Setting the version of the project will enable creating a CMake package version file.

Add a new option KLEIN_INSTALL. When this option is enabled, then a CMake config-file package will be created during the install step. By default, this option is set to ON for standalone projects. Otherwise, the option is set of OFF.

The header files will be installed into include/klein. Therefore, the include directory of the exported targets should be include (i.e. $<INSTALL_INTERFACE:include>). To distinguish this from the include directories during a build we use the BUILD_INTERFACE generator expression (e.g. $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/public>).

if KLEIN_INSTALL is set to ON, then the targets are installed and the CMake config-file package is created. Other CMake projects can then search for the package using e.g. find_package(Klein 2.3.0).

klein-config.cmake will be executed by other projects when using find_package. Since klein depends on the simde headers, the CMake file will try to find these headers and add them to klein targets include directories.

I get an error while running the CMake configure step in a fresh copy of the repository:

Creating directories for 'simde-populate'
  Performing download step (git clone) for 'simde-populate'
  Cloning into 'simde-src'...
  fatal: reference is not a tree: df63f88a364da6be3963b4924c327b12f88d7748
  CMake Error at simde-subbuild/simde-populate-prefix/tmp/simde-populate-gitclone.cmake:40 (message):
    Failed to checkout tag: 'df63f88a364da6be3963b4924c327b12f88d7748'

Steps to reproduce:

git clone [email protected]:jeremyong/klein.git
cd klein
cmake -B build -S .

Possible fix:

Modifying CMakeLists.txt#L35 from GIT_SHALLOW ON to GIT_SHALLOW OFF solves the issue. I'm not sure if that's the correct approach though.

Hi, I've recently become interested in PGA, and am considering using it in a new Python render engine. Math (especially this kind) is not my strong suit, but the advantages of PGA are compelling .... so I'm trying to wrap this up in a Python lib with an API suited for normal people :)

I'm now a bit stuck and I was hoping you could help. Render engines and 3D modeling tools usually provide 3 kinds of transforms for an object: translations, rotations, and scaling. I understand (more or less) how rotors and translators work, but I have not seen the use of scalors (if that's how you'd call them) anywhere. Is a scaling transform/motor even possible? What about anisotropic scaling?

edit: if there's a better place to ask questions like these, please let me know, and I'll move the question there instead

class plane final {
...
    [[nodiscard]] plane normalized() const noexcept
    {
        plane out;
        out.normalize();
        return out;
    }
...
};

is missing an assignment. Should be:

class plane final {
...
    [[nodiscard]] plane normalized() const noexcept
    {
        plane out = *this;
        out.normalize();
        return out;
    }
...
};

I noticed that Klein doesn't have a multivector class (besides the one in the parser for testing).

Did you pick all the operators in such a way that a multivector is never an output?

If so, there must be things that cannot be done with Klein, or, maybe multi vectors are not needed for practical tasks?

Thanks again.

I hate breaking compatibility. Especially frequently. This issue is my attempt to explain what the issue is, what I’m doing to fix it, and what assurances can be afforded about API breakages in the future.

First, the issues:

1. On some compilers, inheritance is causing subclasses of entity to be passed on the stack instead of in registers.
2. On some compilers, branch optimization limits are being hit causing certain loops over constexpr variables to not get optimized out at runtime.

For Klein whose primary goal is realtime PGA, both of these problems are unacceptable. As a result, the entity base class needs to go. This will have the following consequences:

1. Implicit conversions using the entity as a medium will go away. All conversions will be explicit
2. Because of (1), most operators will move to separate headers (one per operation) to avoid circular dependencies while maintaining type safety
3. All the underlying implementation structure will remain the same.

As for testing, I have vetted that the changes outlined above solve all the issues mentioned and checked assembly/perf against all major compilers. All that remains is to finalize the implementation. The internal SSE code does not need to be changed as it is just the “outer shell” that has this problem. Personally, I much prefer the new API, but it is nevertheless a breaking change. As a result, Klein will get a 2.0 label despite the 1.0 being released relatively recently.

Feel free to comment with suggestions or feedback below.

There's plenty of warnings (at least when compliling under vs, i'd assume clang will print those as well). This PR adds explicit casts to fix this issue.

There was a simple typo in the description of a point to a plane. The product should have been (p dot P)p where p is the plane, P is the point. In the description, the math is correct, except for the labeling of the second term in the geometric product.

Hi!

I am using vcpkg to manage dependencies on a project and I was wondering if I could use vcpkg to include klein in my project.

So I wrote a port file and made some changes to klein's CMakeLists.txt so that it creates a config package when running CMake install. Packages created this way can be included in other CMake projects by using:

find_package(klein 2.3.0 REQUIRED) // Version 2.3.0 is used as an example here
target_link_libraries(app PRIVATE klein::klein) // Other available targets are klein::klein_cxx11 and klein::klein_sse42

I was wondering if you would find these changes interesting and worth adding to the project. The changes can be seen in create-config-package.zip. I can open a pull request with the changes if you are interested.

I am working with Microsoft Visual Studio 2019 16.6.1 in Windows 10 x64 environment.

Well. There seems to be some problem in the numerical accuracy of Euler's new angle conversion feature.

For instance; When I convert, for example, roll=90º ,pitch=90º, yaw=0º to rotor, I get in rotor: roll=0º, pitch=89.972º, yaw=0º.I find a noticeable difference between 90º and 89,972º (0.028º) that can build up too quickly.

#include <klein/public/klein/klein.hpp>

#include <cmath>
#include <iostream>

const float M_PI = 3.141592653589793238462643383279502884; /* pi */

int main()
{
	float roll_1 = 90.0;
	float pitch_1 = 90.0;
	float yaw_1 = 0.0;

	std::cout << "INPUT: roll: " << roll_1 << " pitch: " << pitch_1 << " yaw: " << yaw_1 << std::endl;

	kln::euler_angles ea_1;
	ea_1.roll = roll_1 * (M_PI / 180.0f);
	ea_1.yaw = yaw_1 * (M_PI / 180.0f);
	ea_1.pitch = pitch_1 * (M_PI / 180.0f);

	kln::rotor r;
	r = kln::rotor(ea_1);
	kln::euler_angles ea_2 = r.as_euler_angles();
	
	float roll_2 = ea_2.roll * (180.0f / M_PI);
	float yaw_2 = ea_2.yaw * (180.0f / M_PI);
	float pitch_2 = ea_2.pitch * (180.0f / M_PI);

	std::cout << "OUTPUT: roll: " << roll_2 << " pitch: " << pitch_2 << " yaw: " << yaw_2 << std::endl;
	return 0;
}

I get:

INPUT: roll: 90 pitch: 90 yaw: 0
OUTPUT: roll: 0 pitch: 89.972 yaw: 0

DJuego