Kotlin port of OpenGL Mathematics (GLM), a header only C++ mathematics library for graphics software based on the OpenGL Shading Language (GLSL) specifications.

Hi, I'm not sure if this is a by-product of Kotlin but is there a technical reason why the usual functions like glm::frustum are dependent on an Instance instead of just being a static method of the generated class?

This makes passing the functions around themselves somewhat tedious/infeasible as they need to be invoked on an instance of the glm class.

Specifically I am trying to call these methods from clojure where the usability is even more impacted by the methods not being static. I can get around this by writing a few macros, but I would rather not add another layer of indirection.

This PR rebases jdk8 onto master and changes the github actions JDK version to 8.

Please note that the rebase leaves a non-linear commit history: let me know if you'd like a merge instead.

The gradle linking example

dependencies {
      implementation 'com.github.kotlin-graphics.glm:glm:<version>'
  }

seems to be incorrect. Only such option- com.github.kotlin-graphics:glm:<version> worked for me

I was quite excited to give this project a try in my small Kotlin/JS + WebGL side-project and I discovered very late that it depends on java.* APIs.

I'm aware of issue #6, but an important first step before implementing multiplatform support, in my opinion, could be mentioning current state in the readme clearly.

Just tried to rebuild my project using the latest glm snapshot. However, it seems to fail:

implementation 'com.github.kotlin-graphics:glm:-SNAPSHOT'

Could not resolve all files for configuration ':compileClasspath'.
   > Could not resolve com.github.kotlin-graphics:glm:-SNAPSHOT.
     Required by:
         project :
      > Could not resolve com.github.kotlin-graphics:glm:-SNAPSHOT.
         > Could not parse POM https://jitpack.io/com/github/kotlin-graphics/glm/-SNAPSHOT/glm--8dae70c16a-1.pom
            > Could not find kx.platform:source:0.2.0.
              Searched in the following locations:
                - https://oss.sonatype.org/content/repositories/snapshots/kx/platform/source/0.2.0/source-0.2.0.pom
                - https://oss.sonatype.org/content/repositories/snapshots/kx/platform/source/0.2.0/source-0.2.0.jar
                - https://repo.maven.apache.org/maven2/kx/platform/source/0.2.0/source-0.2.0.pom
                - https://repo.maven.apache.org/maven2/kx/platform/source/0.2.0/source-0.2.0.jar
                - https://jitpack.io/kx/platform/source/0.2.0/source-0.2.0.pom
                - https://jitpack.io/kx/platform/source/0.2.0/source-0.2.0.jar

reverting to implementation 'com.github.kotlin-graphics:glm:9cb1ce84bf' fixes the issue.

When trying to use the get() function of the Vec2i a NoSuchMethodError gets thrown. When calling them directly a NoSuchFieldError appears.

private val creator=LevelCreator(Game.resolution[0].toFloat(), Game.resolution[1].toFloat(),14,8,0f,0f)

https://github.com/Mitti30/BreakoutOpenGL

Hi, i wanted to use your library with clojure and came across this disscusion #5 . It looked reasonably easy so i made a small script to get all functions and place them in the Clojure class you created. I don't know kotlin and did not have the time to setup/learn it, so it must contain some unnecessary functions or typos, but maybe it's a first draft.

Since v0.10 the gradle implementation for jitpack changed. This PR updates the dependency example in the readme accordingly to prevent confusion during the initial setup process.

glm calculates vec3 * quat as : https://github.com/g-truc/glm/blob/23e0701c0483283440d4d1bcd17eb7070fa8eb75/glm/detail/type_quat.inl#L352-L356

	template<typename T, qualifier Q>
	GLM_FUNC_QUALIFIER GLM_CONSTEXPR vec<3, T, Q> operator*(vec<3, T, Q> const& v, qua<T, Q> const& q)
	{
		return glm::inverse(q) * v;
	}

        template<typename T, qualifier Q>
	GLM_FUNC_QUALIFIER qua<T, Q> inverse(qua<T, Q> const& q)
	{
		return conjugate(q) / dot(q, q);
	}

That is glm::inverse(q) * v; which can be expanded as conjugate(q) / dot(q, q) * v; However Vec3 * Quat is implemented in: https://github.com/kotlin-graphics/glm/blob/5b0f3461ebe0c1a3a752b1b9a174c09fb7e4b5f4/src/main/kotlin/glm_/quat/quat_operators.kt#L61-L77

Where line 62 val dot = dot(a, a) should be val dot = dot(b, b) which calculates the dot product of a quaternion and then is used to calculate the inverse of the quaternion.

I'm using your library in my project. My project's build.gradle originally looked like:

blahblah...

ext {
    ...
    glmVersion = 'v0.9.9.0-build-13'
}

repositories {
    jcenter()
    mavenCentral()
    maven { url 'https://jitpack.io' }
}

dependencies {
    ...
    implementation "com.github.kotlin-graphics.glm:glm:$glmVersion"
}

Then when I run gradlew build or gradlew run, gradle fails to download lwjgl and emits an error that it can't find 3.2.2-SNAPSHOT version of lwjgl. After reading your library's build.gradle, I found that you are using oss.sonatype.org for downloading lwjgl. So I added that repository to my project's build.gradle like the following code:

repositories {
    jcenter()
    mavenCentral()
    maven { url 'https://jitpack.io' }
    maven { url 'https://oss.sonatype.org/content/repositories/snapshots/' }
}

And gradle works well now.

So I think that you should mention in README.md that the users should try this method if gradle emits lwjgl dependency error.

Thanks.

First, I'd like to thank you for creating a port of glm. I'd love to use it in my project and I'm very glad that you've put an effort to create this pure-Kotlin port.

Would you consider improving the documentation about getting the library? In my experience, picking a library looks like this: first I verify if this is the library I'm looking for, then I copy the Gradle snippet, typically from the top of the readme. In case of kotlin-graphics/glm, there's only a link pointing to kotlin-graphics/mary's readme, which is some kind of an analysis, which is not really helpful for people who look for three magical lines of Gradle script (which is, 95% of people).

So, I'm getting some dilemmas right now and I'd like to hear some feedbacks

I finally recently implemented inline classes into native pointer management in kool (I was eager to do it, but always postponed because of other priorities)

Where you basically can do something like:

val intPtr = IntPtr(x) // x is a valid, already allocated area of memory
intPtr[1] = 5
val r = intPtr[0]

all for free, offsets are set accordingly to the pointer type

Now I already used that in the vkk playground (tmp branch) and I went for expliciteness, so write(adr: Adr) or write(stack: MemoryStack) to write the current struct at the given memory address or in the given MemoryStack. On the other side, constructor(ptr: BytePtr)s and read/native { } methods to read from native memory.

Here in glm, there was only some raw simple methods

// Vec2
    infix fun to(ptr: Ptr) {
        memPutFloat(ptr, x)
        memPutFloat(ptr + Float.BYTES, y)
    }

// Vec2 companion object
fun fromPointer(ptr: Ptr) = Vec2(memGetFloat(ptr), memGetFloat(ptr + Float.BYTES))

I'm planning to expand this area, by providing a constructor

constructor(ptr: FloatPtr) : this( { i -> ptr[i] } )

calling the corresponding functional programming constructor

This will work for all the vector and matrices, except the vectors using Longs (Vec1l, Vec2l, Vec3l and Vec4l), because they have the convenience constructor accepting just one Long, whose signature will clash with construct(ptr: LongPtr). In this cases, I'll keep the convenience constructor and renounce to the pointer one.

I'm incline to accept this small incoherence for these vectors type and provide a static method for those.

This is my first dilemma.

Second issue is the naming. At the begin I thought to go with to for writing and from for reading into an existing class (constructor otherwise).

But a part of me is pushing for explicit read and write methods.

What do you think, guys?

I want to use this library in a multiplatform application. Since the bulk of this library is written in pure Kotlin, going multiplatform would be fairly trivial. The only possible issue I can think of is that JitPack may not work with it, breaking current users. Would need to setup build for all platforms to publish to Bintray or Maven central.