Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (803)
Games in Android Showcase (237)
games submitted by our members
Games in WIP (867)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 6 7 [8] 9 10 ... 13
  ignore  |  Print  
  Java OpenGL Math Library (JOML)  (Read 213973 times)
0 Members and 2 Guests are viewing this topic.
Offline Roquen

JGO Kernel


Medals: 518



« Reply #210 - Posted 2015-08-06 09:06:09 »

Wait.  A bunch of the quaternion operations are backwards.  That's an incredibly awful idea.
Offline KaiHH

JGO Kernel


Medals: 786



« Reply #211 - Posted 2015-08-06 09:42:59 »

I am sorry, but I think you express your points in (vague) ways that make deriving concrete plans for changes, or seeing any benefit or added value, difficult to me.
Do you have a concrete project you want to realize with JOML, and have problems (missing functionality or bugs) that hinder you from using JOML for this?
I am unlikely to change something unless that actually adds value. And by "value" I mean: You (or anyone else) being able to use JOML more effectively and efficiently.
You know, what I observed of frameworks and applications being successful and standing the test of time, is:
- that they derive their design by actual use cases and user needs,
- that they adapt to new or changing requirements quickly and
- that their design is not driven by theoretical considerations of what _could_ be useful or what _might_ be a better design.
There are a few more points than that, such as being easy to comprehend and consistent, all of which I try to target with JOML.
After all, the quality of a design decision is measured by how effectively and efficiently _existing_ use cases can be satisfied, IMO.
Speaking of consistency: Maybe you can hint me to a concrete operation in the quaternion classes that are "backwards" and we can work on fixing that?
Offline Roquen

JGO Kernel


Medals: 518



« Reply #212 - Posted 2015-08-06 12:06:37 »

Quote
..points in (vague) ways..
I need to know which points are vague to be able to clarify.

Quote
- that they derive their design by actual use cases and user needs,
<snip>
..not driven by theoretical considerations...
All of my comments in this thread address actual use cases in a video game context.

I'll address backwards later.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline KaiHH

JGO Kernel


Medals: 786



« Reply #213 - Posted 2015-08-06 12:55:28 »

Okay, let me make the effort and comment on each of your points, which I'd like you to clarify on:

Quote
toString - I assume you want an exact representation - {Float/Double}.toHexString
Why do you assume? The question I would ask is, do YOU want another representation than what is currently done?
The concrete use case and reason why the current solution was chosen, was to have matrices and their columns align for easy sysout and debugger variable inspection debugging, no matter what magnitude a floating point value has.

Quote
rescaling by multiple divides, multiple by recip..the extra rounding step isn't a worry.
What? Who "rescales" by multiple divides and where? And why? Be more concrete! In the best case please point out a concrete line in the sources of JOML that has an issue, so that we can fix it.

Quote
likewise for methods over single types which promoting to doubles...do you really care about the extra rounding steps?
Again, the question is: Do YOU care about how the solution works currently and do YOU have a problem with how it is currently? If not, then this statement is mood.

Quote
compositing of operations which are disallowed transforms for the compiler.
What? Please concrete examples. This is waaaay too vague of a statement than what I can process in my mind Smiley
It does not lead to a concrete desired change.

Quote
arccos and arcsin are always removable.
How? And where? And why?

Quote
you might want to let the various inliners do the work for you.  Smaller classfiles, lower load/link/verify times and the first compile will happen faster (assuming more than one variant is actually used in a project). Examples various normalize() and normalize(..)
Again: what? What is an 'inliner' in the context of your post? What benefit does it add? How is it being used? Questions that must be answered before thinking about a way to solve whatever the problem is that you are addressing.

Quote
although ugly, static methods with manipulate values in a float/double array at offsets.
What is with "static methods"? Do you propose to ADD them? There are already methods to get/put 4x4 matrices into/from a float/double array at an offset.

Quote
2d vectors - maybe abuse the math and include complex number functions (1).
Why? Who would benefit from it in which concrete example?

Quote
slerp/nlerp - let the user pass in the closest pair (forget checking the dot and branch)
What is a "closest pair?" Do you mean the threshold of the dot product after which two quaternions are considered to be amenable to non-spherical linear interpolation?

Quote
nlerp - renormalize instead of normalize.
Where to renormalize and what?

Quote
branching to insure input != output for most types is a model based on when hardware had few registers.
Did you actually measure a performance degradation because of this and experience performance issues?
Offline Riven
Administrator

« JGO Overlord »


Medals: 1371
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #214 - Posted 2015-08-06 13:14:52 »

Going the extra mile... impressive. A disoriented woman once said: being right is fruitless when one fails to convey.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline KaiHH

JGO Kernel


Medals: 786



« Reply #215 - Posted 2015-08-06 13:20:16 »

Yes, the thing is, I do believe that @Roquen has some very good points to say and can propose improvements.
I just want to give some guidance on how that must be, yes - conveyed, for me to understand. Smiley
Offline theagentd
« Reply #216 - Posted 2015-08-06 18:46:00 »

Something I do find a bit unintuitive and "backward" is that some functions seem to return the input for chaining instead of the destination object. For example, Quaternion*.transform(Vector3*) returns the quaternion, not the resulting Vector3. That goes against both LibGDX and LWJGL and is in my opinion less useful than returning the resulting vector.

For example, with LibGDX I did this:
1  
parentOrientation.transform(translation).scl(parentScale).add(parentTranslation);


With JOML, I need to split up the command like this:
1  
2  
parentOrientation.transform(translation); //returns parentOrientation
translation.mul(parentScale).add(parentTranslation);

Myomyomyo.
Offline KaiHH

JGO Kernel


Medals: 786



« Reply #217 - Posted 2015-08-06 18:48:35 »

Yes, this is being discussed currently on GitHub: https://github.com/JOML-CI/JOML/issues/43
and very likely to change in the near future.
Offline theagentd
« Reply #218 - Posted 2015-08-06 18:53:40 »

I hate to bring up this issue again since I fear a shitstorm is going to happen again, but are the with() functions really of any use? They only increase the amount of code you have to write to accomplish the same thing.

1  
2  
3  
parentOrientation.transform(translation); translation.mul(parentScale).add(parentTranslation);

parentOrientation.transform(translation).with(translation).mul(parentScale).add(parentTranslation);


I see no possible use case of it where you can't just replace
with(X).
with just
; X.


EDIT: I'm aware that this use-case will also be made redundant after the always-return-modified-object convention.

Myomyomyo.
Offline Roquen

JGO Kernel


Medals: 518



« Reply #219 - Posted 2015-08-06 23:41:55 »

Remember that I'm stuck with just a cell phone.   I'm looking at your code through a web interface on a cell's screen and typing is less than ideal.

Quote
Quote
toString - I assume you want an exact representation - {Float/Double}.toHexString
Why do you assume? The question I would ask is, do YOU want another representation than what is currently done?
The concrete use case and reason why the current solution was chosen, was to have matrices and their columns align for easy sysout and debugger variable inspection debugging, no matter what magnitude a floating point value has.
What I intended to say was "Assuming that...", the case under that assumption is text based serialization where error-free round trips are a very good thing.

Quote
Quote
rescaling by multiple divides, multiple by recip..the extra rounding step isn't a worry.
What? Who "rescales" by multiple divides and where? And why? Be more concrete! In the best case please point out a concrete line in the sources of JOML that has an issue, so that we can fix it.
Rx = x/K for 'n' x's, fixed K.  Transform into s = (1/k) and multiply by s.  Adds one rounding step and removes 'n-1' long latency operations and replaces with short latency.  Examples include normalization.  To generalize, java cannot logically factor an FP expression and in this case kills sub-expression removal.

Quote
Quote
likewise for methods over single types which promoting to doubles...do you really care about the extra rounding steps?
Again, the question is: Do YOU care about how the solution works currently and do YOU have a problem with how it is currently? If not, then this statement is mood.
I think the real question is do you or your potential users care?  But back on topic. Take Quaternionf.setAxisAngle, it's promoting three values to doubles, performing a multiply on each and converting the three back to float.  One less rounding step for 5 extra operations and adding two to the dependency chain (which is doubling it).

Quote
Quote
compositing of operations which are disallowed transforms for the compiler.
What? Please concrete examples. This is waaaay too vague of a statement than what I can process in my mind Smiley
It does not lead to a concrete desired change.
Java doesn't allow relaxing of FP so the only transforms it can perform on a FP expression is one that returns the same result. (some minor exceptions, but not interesting here).  Like that it cannot factorize (as above) it also cannot re-associate.

a+1+1 != a+2
a+b+c != a+c+b
a*b*c != b*c*a

There appear to be numerous examples of this.  Like terms a*b*c and d*b*c are computed.  b*c cannot be computed once.

Quote
Quote
arccos and arcsin are always removable.
How? And where? And why?
How = trig identities...worst case atan2. 
Where = search for Math.acos
Why = asin/acos are hard to approximate (read slow) in comparison to atan/atan2 and very frequently disappears. 

atan, atan2 & sqrt are compiler intrinsics...asin/acos are not.

Additionally they kinda suck.  The suck because an error of 1-ulp can make them go BOOM!  Like say 'w' of a quaternion is +/-(1+ulp(1)) angle returns NaN. Input is from dotting two nearly co-linear vectors...BOOM!

Quote
Quote
you might want to let the various inliners do the work for you.  Smaller classfiles, lower load/link/verify times and the first compile will happen faster (assuming more than one variant is actually used in a project). Examples various normalize() and normalize(..)
Again: what? What is an 'inliner' in the context of your post? What benefit does it add? How is it being used? Questions that must be answered before thinking about a way to solve whatever the problem is that you are addressing.
What = HotSpot's inlining functionality (I think I did a write-up somewhere)

Quote
Quote
although ugly, static methods with manipulate values in a float/double array at offsets.
What is with "static methods"? Do you propose to ADD them? There are already methods to get/put 4x4 matrices into/from a float/double array at an offset.
All input and output is in flat arrays from offsets.

Quote
Quote
2d vectors - maybe abuse the math and include complex number functions (1).
Why? Who would benefit from it in which concrete example?
http://www.java-gaming.org/topics/complex-number-cookbook/28991/view.html
http://www.java-gaming.org/topics/vectors-what-s-the-point/24307/view.html

So animation systems, simulations, geometry, increased performance by not using trig & inverse trig.  All kinds of good stuff.

Quote
Quote
slerp/nlerp - let the user pass in the closest pair (forget checking the dot and branch)
What is a "closest pair?" Do you mean the threshold of the dot product after which two quaternions are considered to be amenable to non-spherical linear interpolation?
I'm suggesting that the contract should be that two input should be of unit length and their dot product >= 0.  For a given pair of input, the slerp or nlerp will run many times...they caller can figure out the closest pair once and supply that. 

For 'nlerp' the dot product and the branch go away.  That a drastic complexity decrease.

Quote
Quote
nlerp - renormalize instead of normalize.
Where to renormalize and what?
Come on.  I'm taking a f**k load of time to answer your questions on stupid small screen.  nlerp is only a couple of lines of code (and if you take my suggestion above it'll be cut in half).  What do you mean by "what" and "where"?  How many calls to normalize is there in function?  ONE!  Assuming you don't understand what I mean by "renormalize":  the magnitude of lerp will be on [1,.707].  1 step of Newton is sufficient.

Quote
Quote
branching to insure input != output for most types is a model based on when hardware had few registers.
Did you actually measure a performance degradation because of this and experience performance issues?
No.  I don't need to.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline theagentd
« Reply #220 - Posted 2015-08-07 00:41:53 »

The normalization optimization is a pretty good idea. It's safe to assume that multiplies are much cheaper than divides when it comes to floats and doubles, so calculating 1/length and multiplying all 3 components by that value is faster than dividing them by length. LibGDX does this. This applies to all normalization JOML does.

Concerning a*b*c != d*b*c: This is because Java strictly follows the ordering. a*b*c = (a*b)*c while d*b*c = (d*b)*c, so in this case the compiler can't first calculate b*c and then reuse the result for both calculations. The lesson to take home is that if you want a value to be guaranteed to only be computed once, you should manually calculate it in a temporary variable.

Concerning the branch to avoid local variables, it sounds like a bad idea. I tried commenting out one or the other in my skeleton animation test and there was no difference in performance. It just makes the code harder to read and maintain IMO.

Also, I believe mul4x3 can be optimized quite a bit.

Red = 0.0, blue = 1.0.
                     m00 * right.m00 + m10 * right.m01 + m20 * right.m02 + m30 * right.m03,
                     m01 * right.m00 + m11 * right.m01 + m21 * right.m02 + m31 * right.m03,
                     m02 * right.m00 + m12 * right.m01 + m22 * right.m02 + m32 * right.m03,
                     m03 * right.m00 + m13 * right.m01 + m23 * right.m02 + m33 * right.m03,
                     m00 * right.m10 + m10 * right.m11 + m20 * right.m12 + m30 * right.m13,
                     m01 * right.m10 + m11 * right.m11 + m21 * right.m12 + m31 * right.m13,
                     m02 * right.m10 + m12 * right.m11 + m22 * right.m12 + m32 * right.m13,
                     m03 * right.m10 + m13 * right.m11 + m23 * right.m12 + m33 * right.m13,
                     m00 * right.m20 + m10 * right.m21 + m20 * right.m22 + m30 * right.m23,
                     m01 * right.m20 + m11 * right.m21 + m21 * right.m22 + m31 * right.m23,
                     m02 * right.m20 + m12 * right.m21 + m22 * right.m22 + m32 * right.m23,
                     m03 * right.m20 + m13 * right.m21 + m23 * right.m22 + m33 * right.m23,
                     m00 * right.m30 + m10 * right.m31 + m20 * right.m32 + m30 * right.m33,
                     m01 * right.m30 + m11 * right.m31 + m21 * right.m32 + m31 * right.m33,
                     m02 * right.m30 + m12 * right.m31 + m22 * right.m32 + m32 * right.m33,
                     m03 * right.m30 + m13 * right.m31 + m23 * right.m32 + m33 * right.m33


Optimized:
                     m00 * right.m00 + m10 * right.m01 + m20 * right.m02,
                     m01 * right.m00 + m11 * right.m01 + m21 * right.m02,
                     m02 * right.m00 + m12 * right.m01 + m22 * right.m02,
                     0,
                     m00 * right.m10 + m10 * right.m11 + m20 * right.m12,
                     m01 * right.m10 + m11 * right.m11 + m21 * right.m12,
                     m02 * right.m10 + m12 * right.m11 + m22 * right.m12 ,
                     0,
                     m00 * right.m20 + m10 * right.m21 + m20 * right.m22 ,
                     m01 * right.m20 + m11 * right.m21 + m21 * right.m22,
                     m02 * right.m20 + m12 * right.m21 + m22 * right.m22,
                     0,
                     m00 * right.m30 + m10 * right.m31 + m20 * right.m32 + m30,
                     m01 * right.m30 + m11 * right.m31 + m21 * right.m32 + m31,
                     m02 * right.m30 + m12 * right.m31 + m22 * right.m32 + m32,
                     1



Performance (translationRotateScale + matrix multiplication):

LibGDX: 12 466k bones.
JOML mul(): 28 450k bones.
JOML optimized mul4x3(): 38 260k bones.


112 vs 63 mul/adds

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
    public Matrix4f mul4x3(Matrix4f right, Matrix4f dest) {
        dest.set(m00 * right.m00 + m10 * right.m01 + m20 * right.m02,
                 m01 * right.m00 + m11 * right.m01 + m21 * right.m02,
                 m02 * right.m00 + m12 * right.m01 + m22 * right.m02,
                 0,
                 m00 * right.m10 + m10 * right.m11 + m20 * right.m12,
                 m01 * right.m10 + m11 * right.m11 + m21 * right.m12,
                 m02 * right.m10 + m12 * right.m11 + m22 * right.m12 ,
                 0,
                 m00 * right.m20 + m10 * right.m21 + m20 * right.m22 ,
                 m01 * right.m20 + m11 * right.m21 + m21 * right.m22,
                 m02 * right.m20 + m12 * right.m21 + m22 * right.m22,
                 0,
                 m00 * right.m30 + m10 * right.m31 + m20 * right.m32 + m30,
                 m01 * right.m30 + m11 * right.m31 + m21 * right.m32 + m31,
                 m02 * right.m30 + m12 * right.m31 + m22 * right.m32 + m32,
                 1);
        return this;
    }

Myomyomyo.
Offline KaiHH

JGO Kernel


Medals: 786



« Reply #221 - Posted 2015-08-07 08:08:13 »

Also, I believe mul4x3 can be optimized quite a bit.
If you read the JavaDocs, it says that it assumes the *right* matrix to be 4x3. I did this because it could happen and is likely that you would first build a projection matrix and then concatenate a 4x3-only matrix on that. If that is not the case and you never concatenate your full projectionview matrix using mul4x3 we can change that, so that also the left matrix is assumed to be 4x3.

EDIT: I introduced a new Matrix4.mul4x3r, which behaves like the current/old mul4x3 by only assuming that the last row of 'right' is (0, 0, 0, 1). The new version of Matrix4.mul4x3 has your proposed changes, by assuming that both 'this' and 'right' have (0, 0, 0, 1) as last row.
Offline theagentd
« Reply #222 - Posted 2015-08-07 12:35:47 »

Awesome! The usefulness of a 4x3 multiplication lies in skeleton animation, where both the inverse bindpose matrix and the bone transformation matrix are are both "matrices without projection, and calculating bones for a single skeleton is probably heavier than all projection and view matrices you calculate each frame, so it is much more important to optimize it.

Myomyomyo.
Offline KaiHH

JGO Kernel


Medals: 786



« Reply #223 - Posted 2015-08-07 12:56:13 »

... and calculating bones for a single skeleton is probably heavier than all projection and view matrices you calculate each frame, so it is much more important to optimize it.
Yes, of course. I totally agree.
So basically, it's always: "Tell me what the hot path of your code is, and then let's optimize JOML on that." Smiley

Also, thanks @Roquen, for your input. At least I saw that using multiplying by the reciproce could in theory be better than dividing all the time. Wink
I implemented that.
Additionally, I finally came to changing the contract of each method to now return 'dest', or in general "the parameter being manipulated."
And then I finally removed those 'with()' methods, since with the introduction of the recent changes, those are even more unnecessary.
But you have to admit, if not they provided any functional benefit to JOML, they did satisfy some sociological aspect of allowing people to bond together and vent their wrath on them. Wink

So, if you use the Maven infrastructure (Maven, Gradle, Ivy, ...) then please now use 1.4.3-SNAPSHOT.
Offline theagentd
« Reply #224 - Posted 2015-08-07 14:20:09 »

I cannot medal-slap you hard enough, KaiHH.

Myomyomyo.
Offline princec

« JGO Spiffy Duke »


Medals: 1136
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #225 - Posted 2015-08-07 14:27:43 »

For what it's worth I'll be switching from gdx vecmath to JOML too for my game libraries (largely as a result of @theagentd working on our engine code). So keep up the good work Wink

Cas Smiley

Offline KaiHH

JGO Kernel


Medals: 786



« Reply #226 - Posted 2015-08-07 14:35:02 »

Glad to hear!
Please keep feeding me with info on what your use cases are; either on GitHub or here - though personally I prefer having a traceable issue on GitHub over a post on JGO.
The more people make use of JOML, the better it can become.
Offline theagentd
« Reply #227 - Posted 2015-08-07 14:38:51 »

By the way, I forgot to mention it earlier, but the 48--->68 FPS increase I got from JOML included calculating all physics, model matrices and camera matrices at double precision. The physics were noticeably slower (10-20% longer CPU time) due to this. Double precision did help a lot with motion blur inaccuracies during slow-motion (difference between two positions scaled up by a large number) and also reduced model and camera jitter a lot. This led to less motion blur and anti-aliasing reprojection artifacts in the scene.

EDIT: Skeleton animation was of course done at float precision.

Myomyomyo.
Offline pitbuller
« Reply #228 - Posted 2015-08-07 20:43:48 »

By the way, I forgot to mention it earlier, but the 48--->68 FPS increase I got from JOML included calculating all physics, model matrices and camera matrices at double precision. The physics were noticeably slower (10-20% longer CPU time) due to this. Double precision did help a lot with motion blur inaccuracies during slow-motion (difference between two positions scaled up by a large number) and also reduced model and camera jitter a lot. This led to less motion blur and anti-aliasing reprojection artifacts in the scene.

EDIT: Skeleton animation was of course done at float precision.
How you are doing motion blurring? Sounds bit odd that you would ever have precision issues with it. I just use last frame mvp matrices which are always exact.(if object wasn't visible on previous frame I use current matrices which is not problem for temporal AA and hardly problem for motion blur.). Actual motion vectors are scaled from difference vectors using frame time and camera shutter time.
Offline theagentd
« Reply #229 - Posted 2015-08-07 21:08:45 »

I had problems with motion vectors stuttering during slow motion. With time running 1/20th as fast, the difference between in positions between each frame was minimal and the motion vectors are scaled up based on 1.0/timeStep to compensate. This amplifies floating point errors in the object and view matrices enough to cause seemingly stationary objects to get long enough motion vectors to cause motion blur to kick in. Running at a high resolution further increased the floating point errors. Computing object physics, object matrices and camera matrices with double precision and only convert them to floats when uploading them to OpenGL solves this.

Myomyomyo.
Offline pitbuller
« Reply #230 - Posted 2015-08-08 08:25:36 »

I had problems with motion vectors stuttering during slow motion. With time running 1/20th as fast, the difference between in positions between each frame was minimal and the motion vectors are scaled up based on 1.0/timeStep to compensate. This amplifies floating point errors in the object and view matrices enough to cause seemingly stationary objects to get long enough motion vectors to cause motion blur to kick in. Running at a high resolution further increased the floating point errors. Computing object physics, object matrices and camera matrices with double precision and only convert them to floats when uploading them to OpenGL solves this.

This isn't motion blur anymore. Camera based motion blur is based on shutter speed. For Hardland I chosed shutter speed to be 1 /100 s. So with 60fps framerate I scale motion vectors with (1/100) / (1/60) = 0.6. If framerate dips lower scaling value just goes smaller. For realistic motion blur you never can't have longer shutter time than frame rate.
if you crank up motion blur with slow motion it might be cool effect but it's not actually motion blur effect anymore.
Offline KaiHH

JGO Kernel


Medals: 786



« Reply #231 - Posted 2015-08-08 17:54:27 »

JOML 1.5.0 (and its siblings 'mini' and '2d') is now on Maven Central, containing all the recent changes.
It can be used with Maven, Gradle and Ivy right away now.
(it takes some hours for the search.maven.org/ online site to pick the new version up)
Offline theagentd
« Reply #232 - Posted 2015-08-08 21:06:51 »

You're right, the motion blur length depends on how long the shutter is open, which obviously can't be longer than the frame time of the virtual "camera" you have, but I find it more important to keep the motion blur independent of framerate (like you do too). The slow-mo is a stylish effect, yeah, so there's really no point in trying to justify it. I also noticed reduced jittering of objects and the camera (which follows one of the objects). Simply put, the matrices had much higher precision, limited only by the 32-bit float precision they were uploaded in to OpenGL instead of suffering precision issues during calculations.

Myomyomyo.
Offline Roquen

JGO Kernel


Medals: 518



« Reply #233 - Posted 2015-08-14 08:31:42 »

I'll be back from vacation soon so I'll be able to be extra annoying (and maybe I'll complete that write-up that I started).  I just too a closer look at the updated slerp.  Remember how I said this is a function you never need to call?  (It's only use should be for reference implementations for error validation)  The current version of slerp validates my point.  (I'm being vague on purpose...do the math.  Only trig is needed here.)
Offline theagentd
« Reply #234 - Posted 2015-08-14 19:09:39 »

I took a look at the new slerp() implementation for the first time and compared it with the LibGDX implementation. Although they seem to be very similar, I think the LibGDX one is more... "elegant". It basically sets itself up for nlerp first, and if the dot product is below a certain threshold it modifies the coefficients to do a proper slerp instead. That only requires one if-statement and keeps the code minimal IMO.

http://www.java-gaming.org/?action=pastebin&id=1326

I'll be back from vacation soon so I'll be able to be extra annoying (and maybe I'll complete that write-up that I started).  I just too a closer look at the updated slerp.  Remember how I said this is a function you never need to call?  (It's only use should be for reference implementations for error validation)  The current version of slerp validates my point.  (I'm being vague on purpose...do the math.  Only trig is needed here.)
I tried to apply some basic trig identities to optimize it, but I didn't think it was possible to derive sin(a*x) from cos(x) without going through angles. At first I couldn't figure out how to derive sin(a*x) and sin((1-a)*x), but then I read your excellent response and managed to figure it out in minutes! Just kidding, your response was as useful as usual. Seems like at best you can replace the sin(x) calculation with sqrt(1 - cos*cos) to get rid of a sin(x) which should be a little faster.

Myomyomyo.
Offline Roquen

JGO Kernel


Medals: 518



« Reply #235 - Posted 2015-08-14 19:34:31 »

I'm writing up the derivation of slerp in the other thread...all the important parts are semi stubbed out there.  What happens to sin((1-a)*x) should be obvious.

Forget that part...how does this implementation of slerp help show than slerp isn't useful (other than for ground truth testing).
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #236 - Posted 2015-08-14 21:01:13 »

ease of use ?

anyway, here's my slerp version which is somewhat ported from GLM, which actually looks almost like agents version.

http://pastebin.java-gaming.org/e8d638d2f3813

Offline Roquen

JGO Kernel


Medals: 518



« Reply #237 - Posted 2015-08-14 21:19:08 »

I am being illogical about the slerp derivation since I think that it's obvious. In the other thread I am building from scratch so I'll give some points about starting  from the common equation.  If you're only interested in minimal paths...which you always are...add to that q and -q represent the same rotation, then the dot is on [0,1],  So the relative angle is on [0, Pi/2].  Not negative because that direction comes relative information. So cos of angle is dot, the sine from the root.  Use all of that for atan.  For the parameterized angles...expand the the sum of angles and complete the derivation.  
Offline Roquen

JGO Kernel


Medals: 518



« Reply #238 - Posted 2015-08-14 21:25:10 »

ease of use ?
If by that you mean performance doesn't matter and I am lazy... that is always reasonable.
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #239 - Posted 2015-08-14 21:54:51 »

yes, or clarity, ease of reading.

but you're right, that's if you do not have too many of them around - sometimes 0.001 ms is not much time Smiley

*edit* which other thread ?
Pages: 1 ... 6 7 [8] 9 10 ... 13
  ignore  |  Print  
 
 

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

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

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

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

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

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

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

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

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

nelsongames (4708 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!