Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (808)
Games in Android Showcase (239)
games submitted by our members
Games in WIP (872)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3 ... 13
  ignore  |  Print  
  Java OpenGL Math Library (JOML)  (Read 218856 times)
0 Members and 1 Guest are viewing this topic.
Offline Neoptolemus
« Posted 2015-02-18 17:05:34 »

Hi everyone,

Since LWJGL 3 removed most of the functionality of the maths library, I thought I'd have a go at creating a Java-based equivalent to the C-based GLM library. Although a conceptual port of the GLM library already exists, I had some issues in getting it to work properly (lots of black screens). The library is fairly bare-bones at the moment, containing the most commonly-used functions, but it should be enough to get people started. I'm happy to take requests to extend it as well if you come across anything missing that you feel would be useful to others.

For reasons of flexibility, every function has an instance and static method (where it makes sense to do so). The instance method modifies the object itself (so myMatrix.transpose() will modify myMatrix directly), and the static method is more in line with what we had in LWJGL 2.9.x where you specify a source and a target matrix (so Matrix4f.transpose(myMatrix, newMatrix) will not modify myMatrix, and stores the results in newMatrix instead).

I've also avoided using local object declarations within the library, with the exception of lookAt which really needs it (at least until I have time to go through it step by step). It makes the code hard to read, but at least you know it's not going to generate hundreds or thousands of collectible objects every frame, depending on what you're doing Smiley

The library currently covers:

    - Float and double precision 3x3 and 4x4 matrices and 2/3 component Vectors
    - Quaternions
    - Surface mathematics (calculating the normal, tangent, binormal)
    - Camera mathematics (including versions of GLM's perspective, ortho and lookAt methods)
    - Transformation utilities (such as generating a transformation matrix from supplied location, rotation and scale)

I'll add to the library over time, but if you have any other requests then drop me a PM or reply to this thread. You can download the source and the library here:

Java OpenGL Math Library

Feel free to use the code however you want. Modify it, use it as a base, copy/paste bits, anything you like Smiley Hope someone finds this useful!


Commit History:

25th February 2015
  * Kai has started adding double-precision alternatives to the float-based Matrix and Vector classes
  * Added MatrixUtils for creating commonly-used matrices like the model matrix

18th February 2015
  * New SurfaceMath class. Currently allows you to calculate the normal, tangent and binormal of a surface
  * Surfaces are defined by 3 vertices and, in the case of the tangent and binormal, their corresponding UV coordinates
  * Removed the normal method from Vector3f as SurfaceMath is a better home for it.
  * New Vector2f class for 2D calculations

17th February 2015
  * Added Quaternion.lookAt to generate a rotation towards at point B from point A (Thanks to SHC for suggesting it)
  * Method allows for specification of the forward and up Vectors, or to use the defaults

16th February 2015
  * Added Quaternion class for handling rotations

11th February 2015
   * Fixed an issue with lookAt (thanks to Kai for the fix)

10th February 2015
   * Added static alias-unsafe methods (mulFast, invertFast, transposeFast) which only work if the source and target matrices are different objects
   * Added overloads for most static methods to take a FloatBuffer as the destination and write into it directly
   * Removed the call to rewind() from the store() instance method in Matrix4f
   * Re-wrote lookAt to remove local Vector3fs (only local primitive floats are used). The code is now almost totally illegible but initial testing suggests it works
   * Some other minor optimisations (such as removing calls to set() from methods that don't require it)

9th February 2015
   * Added alias safety, thanks Kai for pointing that one out

8th February 2015
   * Initial Build
Offline Roquen

JGO Kernel


Medals: 518



« Reply #1 - Posted 2015-02-18 21:21:38 »

Never, ever support degrees.  The idea of degrees is that it takes the sun exactly 360 days to travel around the earth.  And that's exactly how useful they are.
Offline quew8

JGO Knight


Medals: 53



« Reply #2 - Posted 2015-02-20 09:19:23 »

The idea of degrees is that it takes the sun exactly 360 days to travel around the earth.  And that's exactly how useful they are.

And it doesn't even do that.

But degrees have a use in that they are what people know about. They are what people learn about and hence what most of us think about intuitively with angles. So why not have a degrees to radians method so that people can use their intuitive knowledge in, for example, initial conditions. Yes you should discourage people from using degrees but you shouldn't prevent them entirely.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen

JGO Kernel


Medals: 518



« Reply #3 - Posted 2015-02-20 10:52:37 »

You're missing my point.  If any user wants to manipulate degrees AT RUNTIME PROCESSING for some reason...they can but it's their responsibility to do the conversion themselves.  And "degrees" is more natural is mostly myth.  That's only true for very large angles.  Burdening a library with extra useless functionality doesn't meaningfully help anyone.

Note everyone would agree if some library had:  getDistanceMeters, getDistanceFeet, getDistanceYards, getDistanceMiles, getDistanceInHoursForAEuropeanLadenSwallowToFly.  Yo, just do one.
Offline pjt33

« JGO Spiffy Duke »


Medals: 40
Projects: 4
Exp: 7 years



« Reply #4 - Posted 2015-02-20 11:13:31 »

So why not have a degrees to radians method so that people can use their intuitive knowledge in, for example, initial conditions.

Because that's included already in java.lang.Math, and one shouldn't duplicate core library functions like that.
Offline Spasi
« Reply #5 - Posted 2015-02-20 11:17:26 »

Relevant post on angles.
Offline Roquen

JGO Kernel


Medals: 518



« Reply #6 - Posted 2015-02-20 12:18:07 »

Additionally angles are usefully avoidable in the first place.
Offline quew8

JGO Knight


Medals: 53



« Reply #7 - Posted 2015-02-20 21:33:03 »

Additionally angles are usefully avoidable in the first place.

Yes. Vectors, matrices, quaternions are all better than angles in every respect. Certainly for a computer. As with most complex things in maths, learning about them is the hard part but once you have, then they make things so much more simple and general case.

And "degrees" is more natural is mostly myth.  That's only true for very large angles.

I disagree. Certainly most people would be fine with pi/3, pi/2, pi etc. but once you go to more complex multiples than that then you have to think about it to figure out how big the angle actually is. Or at least I do. And I am studying engineering which is practically maths. I wouldn't be surprised if they dropped you marks if you tried to solve a problem in degrees instead of radians.
Offline HeroesGraveDev

JGO Kernel


Medals: 383
Projects: 11
Exp: 4 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #8 - Posted 2015-02-20 21:37:27 »

Then there's the argument of whether radians should be expressed in terms of pi or tau.
And if we use matrices we have to work out whether we're using row- or column-major.

It would be much easier if people could agree on one standard.

Offline Neoptolemus
« Reply #9 - Posted 2015-02-20 22:01:10 »

Hi guys, sorry for the delay in responding, it has been a busy couple of days.

Thanks for the feedback to all of you, I have to admit that I don't come from a mathematical background so I'm kind of learning as I go along. So would you recommend removing the functions to do with degrees and radians as well and work only with vectors? I originally included them as I wanted this library to be accessible to all, but since I'm planning to work on some higher level utility functions at some point I suppose it doesn't matter if the the lower level library imposes a best practice approach.

With regards to the matrices, I appreciate that some people prefer column-major and others row-major (was a pain in the arse when doing research since they often didn't indicate what they were working in). I've chosen column-major since that's how OpenGL prefers it and it means it doesn't have to do any transposition, hopefully my comments make this very clear.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #10 - Posted 2015-02-20 22:10:56 »

less pain when you have both versions (column and row major) around (like glm does) Smiley
Offline Sickan
« Reply #11 - Posted 2015-02-22 23:29:18 »

Thank you so much for this! This makes OpenGL programming so much more convenient Cheesy
Offline Neoptolemus
« Reply #12 - Posted 2015-02-27 10:01:58 »

Quick update. I've changed the link on the first post to point to the new repository location, which is at:

https://github.com/JOML-CI/Java-OpenGL-Math-Library

This is the new working repository, so if you're using the library then make sure you visit this to ensure you have the latest version Wink

I have added some more bits and pieces including a MatrixUtils class which currently provides a quick and easy way to generate a transformation (or model) matrix using a supplied position and scale Vector, and a Quaternion rotation.

Kai over at the LWJGL forums has also started producing double-precision versions of the Vector and Matrix classes.
Offline Roquen

JGO Kernel


Medals: 518



« Reply #13 - Posted 2015-02-27 11:27:09 »

Doubles are for serious computing.
Offline theagentd
« Reply #14 - Posted 2015-02-27 14:53:17 »

Doubles are for serious computing.
Or, you know, a large range of values.

Myomyomyo.
Offline Roquen

JGO Kernel


Medals: 518



« Reply #15 - Posted 2015-02-27 15:01:35 »

For tools...sure.  There are existing libraries.  Runtime:  You don't need doubles.

(EDIT: the extra precision is more often the interesting part...not the wider range)
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #16 - Posted 2015-02-27 15:38:05 »

hide your errors better Wink
Offline theagentd
« Reply #17 - Posted 2015-02-27 17:52:19 »

For tools...sure.  There are existing libraries.  Runtime:  You don't need doubles.

(EDIT: the extra precision is more often the interesting part...not the wider range)
By large range of values, I meant that you might have relatively large values (= a wider range of values) but you still need high precision, so we're basically saying the same thing.

Myomyomyo.
Offline Roquen

JGO Kernel


Medals: 518



« Reply #18 - Posted 2015-02-27 18:46:02 »

No.  They are different.  Give a common (not strawman) example.  I'll freely admit that examples do exist, but they are uncommon needs in terms of a game runtime.

WRT: error -- ok, but you're just hiding the problem.
Offline KaiHH

JGO Kernel


Medals: 820



« Reply #19 - Posted 2015-02-27 22:41:56 »

You might need doubles for a big planet. Wink
There, each vertex (on a chunked lod patch) could be displaced by a noise function, which is a function of the world-space position.
Now, the interesting thing about doubles is not the wide range (magnitude) of values, but, as others stated here, the precision.
And yes, there is a difference.
Higher precision means you can have very large magnitudes (but magnitudes really do not matter with IEEE 754, because you can normalize) and still have small differences between them.
Like you can differentiate between the large (in magnitude) values 100000000.0002 and 100000000.0001. But, no matter how you normalize these values, you still have two non-zero digits at both ends of a long list of zeroes, no matter where the decimal separator is. So in IEEE 754 you need a big mantissa for that. Smiley
Or in other words, you need a small ULP (unit in the last place).
Yes, of course during rendering, single-precision would be used by translating each terrain lod patch with model-space origin (0, 0) within the vertex shader into its view-space position.
So, the need for double-precision during rendering would be eliminated by subtracting the camera world-space position by each lod patch world-space position, which will give lod patch view-space position.
And here, you would not need both magnitude and low ulp, because as magnitude increases (distance to camera) then also precision (ulp) is less relevant.
But I agree that this might be uncommon for games.
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #20 - Posted 2015-02-27 23:42:25 »

i think it's much simpler : double = deeper zoom into that mandelbrot.
Offline Roquen

JGO Kernel


Medals: 518



« Reply #21 - Posted 2015-02-28 08:11:30 »

big planet:  all spheres (assuming the planet is modeled as a sphere) are equivalent to the unit sphere.  So not an example..size doesn't matter.

deep zoom on the m-set: I totally forgot about this totally common game runtime example, but there's no complex number support in the library.
Offline KaiHH

JGO Kernel


Medals: 820



« Reply #22 - Posted 2015-02-28 09:50:47 »

big planet:  all spheres (assuming the planet is modeled as a sphere) are equivalent to the unit sphere.  So not an example..size doesn't matter.
In theory you are right. But in the context of IEEE 754 where we have discretized floating point values, you are not. Smiley
Here, the equivalency breaks.
A planet - even with a 2D-parameterization of space (longitude-latitude, two angles) - is exactly equivalent to mandelbrot, with all the same problems involved. And that problem is: with any fixed-length (in number of bits, that is) numerical representation like IEEE 754, there is no and cannot be any parameterization of the surface of a sphere (any sphere) that lets you reach every point on the sphere. You can only advance on the sphere surface in discretized steps.
As you said rightly, size does not matter, but precision does!
So, simply put: you cannot increase the size of your planet indefinitely (or normalize it back again to unit size indefinitely) while still keeping the same unit of length say 1mm and still want 1mm resolution of small notches and rocks and hills on your planet.
So, because magnitude does not matter, it all depends on the order of magnitude you choose as your basic unit of length. Of course, if you choose 1 meter instead of 1 mm you can scale down the sphere by another factor of 1,000 while still retaining the desired precision (namely now 1 meter).

EDIT: Plus: I did not make this up as a contrived text-book example. It exists in real-world. A big world, by the way Smiley
Offline princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #23 - Posted 2015-02-28 10:59:23 »

Swinging wildly off topic here Smiley

Is this math library for OpenGL rendering or for pure mathematics? Aim for one or the other, or get either a poor fit for both or an overcomplicated library with loads of overloading.

Cas Smiley

Offline KaiHH

JGO Kernel


Medals: 820



« Reply #24 - Posted 2015-02-28 11:29:23 »

Yes, you are right about the library. It shouldn't be overweighted.
I for myself do not envision any rendering-related stuff in there.
No dependencies to JOGL or LWJGL or routines to build yourself a voxel game more easily. Wink
Just basic linear algebra in the style of javax.vecmath (i.e. allocation-free and with some little method overload conveniences).
The library is however suited for being integrated into a graphical application, because every such application needs linear algebra all over the place, be it just for a container for three-dimensional vectors.
Offline Roquen

JGO Kernel


Medals: 518



« Reply #25 - Posted 2015-02-28 11:37:54 »

You guys are hitting the nail on the head.  It's impossible to zoom forever on a chaotic map...it's a problem of precision.  It's easy to zoom forever on noise...it's a problem of scale.
Offline KaiHH

JGO Kernel


Medals: 820



« Reply #26 - Posted 2015-02-28 11:51:02 »

Essentially yes Smiley
And to be exact here, it depends a bit what you mean by noise and how the noise value is correlated to space.
If your noise is a function of a parameterization of space (e.g. position on the sphere; or position on any manifold, like a simple plane) then you have precision problems there, too, as you "zoom in."
Like I said above, with fixed-length numbers (32-bit or 64-bit or any bitness) there is no way to reach every (mathematically every) point - in terms of your chosen parameterization - on a manifold/surface.
Therefore, as you zoom-in more and more into your function (like mandelbrot) you reach the point where one ulp is the size of a pixel, at which point you see the discretization.
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #27 - Posted 2015-02-28 17:58:59 »

i always use 4x4 double matrices on the cpu - hides matrix drift in a place which is never reached. one annoying problem solved. Smiley
Offline Neoptolemus
« Reply #28 - Posted 2015-02-28 21:27:07 »

Swinging wildly off topic here Smiley

Is this math library for OpenGL rendering or for pure mathematics? Aim for one or the other, or get either a poor fit for both or an overcomplicated library with loads of overloading.

Cas Smiley

The library is intended to be just pure mathematics, albeit with a focus on the kind of maths used in 2D/3D rendering. I've intentionally avoided any dependency on another library including JOGL or LWJGL, the only concession I've made to OpenGL is to have the matrices column-major. I believe a library should have a very specific purpose, as you said nobody likes having to dig through a huge sprawling library which most people only need 10% of.

I've also started including some handy shortcuts for common calculations like transformation (model) matrices, perspective and projection matrices etc. This is less an intention to start producing higher level methods than simply to provide the fastest possible route from A to B for the most common kind of calculations where even a small speed increase can offer noticable improvements.

I do intend at some point to produce a library containing more "gamey" elements like a camera class and so on, but that will be completely separate.
Offline Roquen

JGO Kernel


Medals: 518



« Reply #29 - Posted 2015-02-28 22:28:35 »

@ KaiHH: Again no, it doesn't really matter what definition of noise you choice.  The problem is independent of scale.  In fact that's pretty much whole the point.  To keep it simple take any isotropic noise in 2D.  Apply any random composed transform (rotation, scaling, translation) of the plane and all results are self-similar.  

Moving to the simplest example would be 1D fbm.  You can zoom for an infinite amount of time with little precision and a little bit of memory.  Infinite here means uncountable..the machine running the simulation will die long before the simulation breaks.

Oh and because an infinite 2D plane can be mapped to a unit 3-sphere does not imply that mappings of the 3-sphere are equivalent to the m-set.

And all of this is very far from commonly needed in a game runtime.
Pages: [1] 2 3 ... 13
  ignore  |  Print  
 
 

 
Riven (847 views)
2019-09-04 15:33:17

hadezbladez (5791 views)
2018-11-16 13:46:03

hadezbladez (2603 views)
2018-11-16 13:41:33

hadezbladez (6207 views)
2018-11-16 13:35:35

hadezbladez (1499 views)
2018-11-16 13:32:03

EgonOlsen (4734 views)
2018-06-10 19:43:48

EgonOlsen (5792 views)
2018-06-10 19:43:44

EgonOlsen (3276 views)
2018-06-10 19:43:20

DesertCoockie (4175 views)
2018-05-13 18:23:11

nelsongames (5501 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!