-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/joml #3811
Feature/joml #3811
Conversation
- added transition methods for termath <-> joml - utilities for Floatbuffer - utilites for material
Hooray Jenkins reported success with all tests good! |
1 similar comment
Hooray Jenkins reported success with all tests good! |
Hooray Jenkins reported success with all tests good! |
Hooray Jenkins reported success with all tests good! |
Hooray Jenkins reported success with all tests good! |
Hooray Jenkins reported success with all tests good! |
I tested the performance of this branch and the current develop branch with FlightRecorder. I created a world with default settings in each branch and tested walking and looking around. Although with something this light, the benefits aren't directly seen in the CPU or heap usage, methods relating to vectors definitely run faster. Most notably, in the current develop branch, the method |
Adding to my above review comments: To get the absolute best performance out of JOML, especially with its matrices implementations, it's important to understand an underlying optimization which is unique to JOML: Matrix methods have various overloads and internal implementations of operations, such as multiplying two matrices, that make use of certain matrix properties (identity, orthogonality, affinity, perspective or orthogonal projection, translation-only) when those properties are known. So, when calling EDIT (2019-12-26): Also, while Terasology has chosen to use the DirectX approach of row-vector matrices (with a matrix vector multiplication of |
I think at the moment I'm just looking to have the same functionality between the old termath and this move over. Will have to keep that in mind when we come back to these classes and make sure that we use these methods. There are other secondary libraries such as the bullet wrapper that will need to be considered as we progress. This is a step by step process ensuring that I don't break anything too badly. |
Sure. If you need anything in JOML to ensure feature parity, then please do not hesitate to open an issue at JOML. |
Hooray Jenkins reported success with all tests good! |
Hi, I had a quick look at what it would take to also transform https://github.com/MovingBlocks/TeraBullet away from javax.vecmath towards using JOML. I think in order to reduce the amount of errors in manually transforming the vector calls from vecmath to JOML, an automatic approach (such as via https://github.com/javaparser/javaparser) would be better here, since the whole thing is a very mechanic task. |
Here are some Flight Recorder readings I took of launching Terasology, creating a world with the Core Gameplay preset and the seed "Test", pausing for a few minutes, and then looking and wandering around, in this branch and my biomework branch. Of particular note is the BaseVector3i init() method, which jumps up from being sampled around 0.25% of activity, to being sampled over 6% of activity in this branch. |
@httpdigest there is another repository with a native bullet wrapper using JNI, but there seems to be some performance problems I'll have to look but in the meantime I think I'll look into fixing up terabullet. There is quite a bit of overhead with querying blocks and transitioning vector3 to vecmath. |
@pollend alright, by the way I am evaluating Java 9's java.lang.Math.fma() and it yields a good 20-30% performance increase in all methods I am using it. The JIT is consistently producing nice x86 VFMADD231SS for it instead of VADDSS and VMULSS. All three instructions, VFMADD231SS, VADDSS and VMULSS have a latency of 4-5 cycles each on all somewhat recent x86 architectures, so using VFMADD231SS alone halves the total latency across a single instruction dependency chain. |
Tested this out locally, couldn't spot any obvious critical issues, at least related to this PR :-) Merged and I've submitted #3832 to help us keep track over some related bits until this saga is ready to close. Thank you @pollend and others chiming in! Plus @httpdigest for making it possible in the first place, +1 users for your lib 👍 |
This PR ports the Terasology over to JOML vectors instead of termath. I think I break some of the shading effects with this port because god rays don't work quite correctly. some of the matrices are not functioning how I'm expecting them to or methods with similar parameters and breaking. I would like to add more test to verify the camera more but this is a good first step. I moved the display width and height into lwjldisplay so it should allow more better testing.
LwjglDisplayDevice.java
- Moved display width and height in LWjgl display for testing.JomlUtil.java
- Utility to convert from termath < -- > jomlMaterial.java
- additional joml methods we're added to allow for either joml or termathA lot of small changes with nodes that translates between termath and joml.
problems
mul method in termath takes two vectors multiplies them and sets the original vector. mul in joml takes the current vector multiplies it by the first and uses an optional 3rd to set the vector.
for quaternion angle will offset it by (2pi - angle) if it's greater then 0 and this seems to break camera rotation
god rays don't seem to function correctly
for floatbuffers terasology uses matrices in row - major and not column major so getTransposed it used instead.