JOML | A Java math library for OpenGL rendering calculations | Math library

You are currently not including the runtime natives jar files of LWJGL into your fat jar file.

So, you don't need to add any JVM arguments like -Djava.library.path or -Dorg.lwjgl.librarypath but merely must make sure that the "natives-linux" dependencies/jar files are in the classpath when you run the jar.

One way to achieve this in your case is by not only iterating over the compile-time dependencies but over the runtime dependencies in your jar task to also collect those and add them to the fat jar file that you build, because you definitely will need them at runtime.

So, change this line:

There are 2 mistakes in your code:

First: you try to update 2 axis at once. Doing this will cause the model to scale as it rotates.

Second: you don't use 1.0f when defining what axis you want to rotate. This aswell causes the model to scale.

The way Matrix4f.rotate(float angleInRadiants, Vector3f(x, y, z)) works is it will rotate the axis specified in the the vector by the specified angleInRadians.

This is the correct way to rotate both axis:

The presented build.gradle file is not a complete build.gradle file, lacking the "implementation" configuration. If you simply copied the snippet generated by lwjgl.org/customize then this would not give you a complete working build.gradle file. You still have to include some Gradle plugin such as "application" that will make the "implementation" configuration available.

So, in order to fix this, add the following at the very top of your build.gradle file:

It does not matter whether you transform your Euler angles into a matrix or a quaternion or whatever representation: As long as you use Euler angles to represent an orientation, Gimbal Lock is unavoidable.

So, in order to avoid Gimbal Lock from happening, you must discard using Euler Angles and stay with one representation for an orientation (like a 3x3 matrix or a quaternion) and apply delta changes to them, instead of trying to represent a full orientation as three Euler angles. So, whenever you - let's say - rotate the object a few degrees around a certain axis, you apply that delta change or orientation to the matrix/quaternion.

Since you are using JOML, you can massively simplify your whole setup.

Let's assume that:

• projectilePosition is the position of the projectile,
• targetPosition is the position the projectile is flying at/towards, and
• cameraPosition is the position of the "camera" (which we ultimately want the projectile to face)

We will also assume that the local coordinate system of the projectile is such that its +X axis points along the projectile's path (like how you depicted it) and the +Z axis points away from the projectile towards the viewer when the viewer is "facing" the projectile. So, the projectile itself is defined as a quad on the XY plane within its own local coordinate system.

What we must do now is create a basis transformation that will effectively transform the projectile such that its X axis points towards the "target" and its Z axis points "as best as we can" towards the camera.

This is very reminiscent of what we know as the "lookAt" transformation in OpenGL. And in fact, we are just going to use that. However, since the common "lookAt" is the inverse of what we wanted to do, we will also just invert it.

So, all in all, your complete model matrix/transformation for a single projectile will look like this (in JOML):

Moreover it is not possible to move it by the offset vector any longer. I don't really understand why.

It is certainly possible to move your object by changing offset. You just set it up in a way that offset is now in pixels (relative to an assumed 1280x720 viewport size, which might or might not be the exact pixel size of your viewport). So if without the projection matrix, an offset of 1 meant to move half the viewport width (which is 2 in NDC), and offset of 1 now means just 1/1280 of the viewport width.

Try something like

One way to determine what section of your terrain should be culled is to use a quadtree (for a heightmap) or an octree (for a voxel map). Basically, you divide your terrain into little chunks that then get divided further accordingly. You can then test if these chunks are in your viewing frustum and cull them if necessary. This technique was already discussed in great detail:

• Efficient (and well explained) implementation of a Quadtree for 2D collision detection
• https://www.rastertek.com/tertut05.html
• https://gamedev.stackexchange.com/questions/15697/quadtree-terrain-splitting-i-dont-get-it

I saw some websites saying to use GL_DYNAMIC_DRAW instead of GL_STATIC_DRAW, but I did not understand it.

These are usage hints to OpenGL on how the data will be accessed so the implementation has the ability to apply certain optimizations on how to store/use it.

usage is a hint to the GL implementation as to how a buffer object's data store will be accessed. This enables the GL implementation to make more intelligent decisions that may significantly impact buffer object performance. (https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glBufferData.xhtml)

Please note that these are only indications, no restrictions:

It does not, however, constrain the actual usage of the data store.

Because you will likely update your VBO's and IBO's constantly (see culling) and only want to draw them GL_DYNAMIC_DRAW would be a good choice:

The data store contents will be modified repeatedly (because of culling) and used many times. The data store contents are modified by the application and used as the source for GL drawing and image specification commands.

as I have googled that it can affect the performance of the game

Well, it will cost some performance to cull your terrain but in the end, it will likely gain performance because many vertices (triangles) can be discarded. This performance gain may grow with larger terrains.

You are trying to compile LWJGL 2 code here. All the imports that it cannot find pertain to the verison 2 of LWJGL. The current version that you can get from the mentioned lwjgl site is 3 and version 3 is incompatible with version 2.

Either explicitly download LWJGL 2 from e.g. http://legacy.lwjgl.org/ or rewrite your code to work with LWJGL 3.

If you go the LWJGL 2 route, though, please note that it hasn't been actively maintained anymore for more than 6 years now.