My 2 cents on standards:
Something I try to keep in mind is to minimize how customized and “personal” my code formatting and my IDE is. There are people who when they started programming they immediately started to customize their IDE to make the code formatting look how they personally prefer, moved around menus, etc. By the time they’ve become decent programmers, their formatting has so many quirks and their IDE is such a Frankenstein that other (even very good programmers) have trouble understanding their code at first. Setting up the project environment in the IDE is a nightmare due to all the finicky settings they changed. Moving to a new computer or updating their IDE breaks everything and not even the person him/herself can remember all the settings they changed. This can be a huge problem when you try to read other people’s code as you’re not used to their formatting/style. Working with others become difficult due to the clashing styles, so debugging is more difficult. Hell, any kind of communication with other people involving code becomes more difficult because you’re essentially coding in this homemade dialect. This is especially important if you have intentions to work with programming. At work your personal preferences don’t matter. It’s much more important to adhere to the style of the existing code, no matter how weird it is to you, for the sake of maintainability and coherence. Also, the less quirks you have the easier it is to switch workstations.
The same goes to some extent for JOML. JOML was born and designed to solve the problems of previous math libraries, and it did so splendidly. Compared to LibGDX/LWJGL/others, it has: no garbage, no native dependencies, tiny library, better performance, double precision versions of classes and more features in general. There really isn’t much you can improve in it anymore, but if there is KaiHH is very accommodating and helpful with answering requests and spitballing ideas. You’re welcome to write your own math library for the learning experience; I was pretty much doing that myself before JOML came around. Saying that “JOML solves your problems already” may not be immediately helpful, but the JOML source is right there and available to anyone. I’m not sure what exactly you were asking about, so this may not be a spot-on response to what you were annoyed about. The tie-in here with standards is that the more people that use JOML the more mature the project will get as any remaining bugs will be fixed and quirks evened out. The “standard” here is beneficial to pretty much everyone, as it also lets us help each other more easily. It’s true that it means that a lot of people can use these classes without knowing the gory details of linear algebra and perspective projection math though, but if learning that is your main goal then maybe a Java game development forum is no the best place to ask in the first place.
To expand on my response to the topic at hand, face culling: Your technique may be more flexible, but also affects performance negatively. Face culling is generally implemented in hardware and only depends on the winding of the vertices after projection. A backface polygon therefore only has to go through the vertex shader (and geometry shader if you have one), and is then immediately discarded. Pretty much all hardware can enable face culling without any overhead whatsoever since it’s handled in fixed-functionality hardware that would simply be disabled if the feature is disabled. In contrast, your discard-based solution makes all triangles go through the rasterizer and finally runs a fragment shader for each of the pixels. In addition, fragment shaders that call discard() interferes with other hardware-based optimizations, semi-disabling early depth/stencil testing and hierarchical depth buffers used most discrete graphics cards.
