Java-Gaming.org Hi !
 Featured games (91) games approved by the League of Dukes Games in Showcase (804) Games in Android Showcase (239) games submitted by our members Games in WIP (868) games currently in development
 News: Read the Java Gaming Resources, or peek at the official Java tutorials
Pages: 1 ... 7 8 [9] 10 11 ... 13
 ignore  |  Print
 Java OpenGL Math Library (JOML)  (Read 216104 times) 0 Members and 1 Guest are viewing this topic.
Roquen

JGO Kernel

Medals: 518

 « Reply #240 - Posted 2015-08-14 22:50:10 »

Don't look..that would be cheating: http://www.java-gaming.org/topics/quaternions-comment-from-my-cell/36422/view.html

EDIT: Let's all pretend like the class StrictMath doesn't exist.
theagentd
 « Reply #241 - Posted 2015-08-15 07:06:39 »

I read your slerp derivation stuff, but I can't say I understand it very well. Quaternions are not my strongest side.

- we can get cos(t) from the dot product
- we can get sin(t) from sqrt(1-cos*cos)

... which solves pretty much nothing since we still need sin(tk) and cos(tk). How would you derive those without going through angles?

Myomyomyo.
Roquen

JGO Kernel

Medals: 518

 « Reply #242 - Posted 2015-08-15 13:33:36 »

I haven't bumped that thread since all the new stuff is "in progress"  It'd be nice if you could tell me what you couldn't follow in the part starting from the parameterized equation.  The equations are simple but nasty to look at...text just doesn't work...this is part of the reason I've not completed the lerp vs. slerp analysis stuff.

My "get rid of trig" is ambiguous...I'm intending the say the trig we artificially introduced.

"we still need sin(tk) and cos(tk)", both are positive...so one and a sqrt

"solves pretty much nothing" is a matter of perspective.  Changing acos -> atan2 or atan is a big win.  You need the extra parameter anyway.  There are a number of things that could done with this for further reduction.  (I don't know what HotSpot is currently doing with atan and atan2...x87 or software scalar SSE.)

Changing 3 forward trig functions into 1 and 2 sqrts is a huge win.

Everything is on limited ranges so there are lots of other changes are possible...including sizable speed-ups that don't really effect the error-bound.  That's the ultimate question...what error-bound is acceptable.

All of this is an interesting diversion / mental exercise.  Certainly it's reasonable for a library to want to provide an efficient implementation.  But I've never talked about optimizing slerp...what I did say is that you don't need to use it and the JOML and LibGDX implementations give evidence of this.
theagentd
 « Reply #243 - Posted 2015-08-16 00:47:27 »

I give up.

Myomyomyo.
KaiHH

JGO Kernel

Medals: 796

 « Reply #244 - Posted 2015-08-16 13:45:02 »

I've tried really hard to get to the grips of what is going on here.
And the closest I got was the "Dunning-Kruger effect." Applied to our situation this implies two things:

- you, @Roquen, as someone who is clearly very smart and knowledgeable about those math stuff, assume that we understand it just as well as you do from you providing us with abbreviated, short and ambiguous statements - that sadly fail to communicate their goal/purpose/motives
- us probably not seeing how knowledgeable about that stuff you really are, since for that to see, it would take a certain level of smartness in ourselves that we probably don't possess

But the part that I've not yet figured out throughout the whole conversation is:
What in the name of god is it that you, @Roquen, actually want...

Very explicitly, I want to know the following things:
- what drives you to write the posts that you do; what interests do you pursue with that; so what are your motives
- what is the appeal (in Friedemann Schulz von Thun's speak of the "the four-sides" communication model) that you want to communicate to us. "You should not use this and that" may just be it, but that is not an appeal meant to change something, since the response to that would just be "well, then don't use it!"

There might just be the chance that you, @Roquen, always wanted to show off what a math buff you are (no pun intended!) and like to teach us about that math stuff. If you want to teach it to us, then thank you, @Roquen, for that! But I would request that you take one or two steps back, NOT writing on your cell phone (you shouldn't have done it in the first place), and instead maybe prepare a proper paper/article on the topic on a proper keyboard.
That is because everything else just leads to more and more confusion on the topic at hand and (at least for me) on the motives that drive you to write about it.
theagentd
 « Reply #245 - Posted 2015-08-16 14:38:12 »

I've always seen him as the guy that walks up to a discussion, says "Lol, there's a much better solution to that problem" and then walks off with a smug smile, leaving everyone wondering if they're all stupid or if he's a troll, so I stopped worrying about it since he's not of any help anyway.

Myomyomyo.
Roquen

JGO Kernel

Medals: 518

 « Reply #246 - Posted 2015-08-16 20:44:11 »

Cell or not I always make terse comments.  My reasoning is simple.  The people that actually read what I've written fall into:

2) I get what you've said and the reasoning and either agree or disagree.
3) I'm actually interested but don't follow.

If anyone from 2 or 3 respond then I'm happy to give further information.  If there are no responses then it's a good thing I didn't spent time writing more than I did.  (2) people are happy as is.  (3) people aren't interested enough to write a question.

"Dunning-Kruger effect."  It's always hard to not over or under explain thing...esp since members have a wide range of math background.  See category 2 & 3 above.  (Unless you're saying I'm in idiot in a nice way)  I'm not attempting to get anyone to do any hard math.  I started a slerp derivation before it came up in this thread and I'm going to do the slerp vs. lerp analysis.

"motivation":  challenge people, math skills, how they think about programming or attack problem solving.

"might just be the chance that...always wanted to show off":  illogically.  My tone would be different and I'd demonstrate my knowledge as rapidly as possible rather than attempt to get others to get to the solution themselves.  How could I show off if they were to beat me to the punch?

"NOT writing on your cell phone":  vacation is hard, let's do some math!

"proper paper/article": planning on doing a few basics as noted above...but here's the deal.  Very few will bother to read it.  Those that do and don't follow won't ask any questions.  So really it'll be a waste of time.  I'll bother because just maybe someone will prove me wrong.

Now let me make some observations:
A) How many people have attempted to guess what I'm saying (in a post)?  Zero.
B) How many people have asked a question in an attempt to follow my reasoning?  Zero.
Riven

« JGO Overlord »

Medals: 1371
Projects: 4
Exp: 16 years

 « Reply #247 - Posted 2015-08-16 21:28:22 »

KaiHH != Zero.

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

JGO Kernel

Medals: 796

 « Reply #248 - Posted 2015-08-16 21:29:28 »

Quote
Unless you're saying I'm in idiot in a nice way
I am not saying that.

Quote
I'm not attempting to get anyone to do any hard math. I started a slerp derivation before it came up in this thread and I'm going to do the slerp vs. lerp analysis.
That's good. Okay, now I think I get the picture. You try to (let's say) intersperse information and ways of solving a specific problem, and your thoughts can then be taken by people and developed further and asked about if they like, or not. That's of course okay.

Quote
My tone would be different and I'd demonstrate my knowledge as rapidly as possible rather than attempt to get others to get to the solution themselves. How could I show off if they were to beat me to the punch?
Could be. Not that I impute that to you, but people always find ways to still somehow "show off" in a convoluted way that allows preserving their ego not being "beaten up." And your tone at times is already pretty non-diplomatic, provocative and "smart-alec" (had to look that word up, don't know if it's right )

Quote
A) How many people have attempted to guess what I'm saying (in a post)?  Zero.
That observation I cannot share. @theagentd and I went to some lengths in trying to understand what you were saying and then gave up.

But if someone is being perceived like @theagentd layed out, then something is clearly wrong somehow. I think the reason might be that the JGO platform is about getting specific and readily applicable help for an expressed problem. And then maybe the intersperse of information about how something should "not" be done in a specific way is just somewhat "orthogonal" to what people expect. Which is: a direct solution.
I think that is the reason why your posts are sometimes perceived as you wanting to teach someone about something that does not directly lead to a solution of the problem, or that - as I pointed out - does not state the actual goal/desired outcome of what you're trying to say.
Riven

« JGO Overlord »

Medals: 1371
Projects: 4
Exp: 16 years

 « Reply #249 - Posted 2015-08-16 22:05:17 »

I think we can generalize the statement made by KaiHH, and observe that pointing out problems whilst not intelligibly explaining a solution, does not work in the majority of social contexts. Only in rigid hierarchies such communication can potentially be considered helpful or motivating, but even then it is frowned upon, and usually used as a last resort.

To paraphrase myself from an earlier reply: being correct is meaningless when you cannot convince people that you are correct. You have to descent all the way down to the level of whoever you're trying to convince.

I will probably split all this off into it's own thread, once things settle down, so we can focus on JOML again, soon.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Spasi
 « Reply #250 - Posted 2015-08-16 22:18:24 »

I actually appreciate Roquen's attempt to get people thinking. I've had him highlighted since Riven implemented that feature, he always has something interesting to say. But yes, his short/vague replies can be frustrating many times.

Anyway, I'm a practical guy and don't have time for derivations. What Roquen's replies made me think was: if there's anything interesting to be said about slerp, someone has said it already. So I used google: Understanding Slerp, Then Not Using It and Slerping Clock Cycles were the interesting hits. Everything you need to know about slerp is in there.

I ported the id code to Java. First of all JOML has a bug: it doesn't check the dot sign and doesn't flip the second sine based on that. This results in interpolation in the wrong direction (not the shortest one). Benchmark results (ns/slerp):

 1  2  3  4 `JOML: 324ns  id: 363ns (reference)  id: 149ns (optimized)  id:  47ns (approximated)`
KaiHH

JGO Kernel

Medals: 796

 « Reply #251 - Posted 2015-08-16 22:27:50 »

Then would you care to pleeeaaase make a Pull Request or post your already available and apparently benchmarked Java code here for JOML to benefit from that?
Spasi
 « Reply #252 - Posted 2015-08-16 22:38:57 »

Sure: http://pastebin.java-gaming.org/8d63d9f28331f

You should be able to use slerpOptimized in JOML as is, just rename the variables to match the original and remove the C-style declarations at the top (hate that).

The approximated version should have decent quality, but I'm not sure if/how you want it in JOML.
KaiHH

JGO Kernel

Medals: 796

 « Reply #253 - Posted 2015-08-16 22:47:32 »

Awesome. Thank you! And also thanks for spotting the bug with the current implementation.
I would include the "optimized" version then, since that does not seem to make any strong assumptions on the input parameters.
To decide on whether the approximated version should also be included I would probably want to ask the users of JOML, whether anyone here feels the need for that?
Also, maybe we can have guards/branches that first test whether the approximation is applicable - the angle being in [0..PI/2] (provided of course that the branching itself would not introduce a high overhead).
Spasi
 « Reply #254 - Posted 2015-08-16 22:59:03 »

Also, maybe we can have guards/branches that first test whether the approximation is applicable - the angle being in [0..PI/2]

The approximation is always applicable, by definition: "Both parameters to the arc tangent function are always positive". That is, omega is always an angle in the first quadrant.
Roquen

JGO Kernel

Medals: 518

 « Reply #255 - Posted 2015-08-16 23:00:27 »

KaiHH != Zero.
Oh yeah?  Must be losing my memory...age and all.

Riven:  The answer isn't interesting...it's trivia.  It's someone finding or fumbling their way toward the answer that's interesting.

Ok. I've said slerp isn't interesting for runtime (add in the implied when it's statistical significant).  I've attempted to point in the right direction by saying the two implementations help demonstrate that.  I didn't imply their were buggy (actually I haven't even looked).  So what's left is a couple of lines of code.  Specifically they break the domain into two parts and slerp for the larger angle range and (n)lerp for the smaller.

They use dot results of .9 and .95 for the partition.  Big deal right?  For small angles the arc and coord are very close.

acos(.9) = .31756
acos(.95) = .451027

Yeah small angles.  Oh wait..that's radians, let's do degrees: 18.1949, 25.8419.  Humm...these are kinda smallish angles.  Oh and there's the half/double angle relationship, so in 3D they're: 36.3897 and 51.6839.  Ok..not so small.  In percentages that's 20.2165 and 28.7133 percent of the whole domain.

So if typical animation data is feeding these routines random input then we'd lerp at about those rates.  But in all raw animation data I've ever run across, the distribute is more exponential than uniform and peak "energy" is closer to zero then to these cutoff points.  And when the angle's aren't small enough in the raw data, subdivide.  If you add to this that you want to do constant velocity between points to keep the code simple and fast...that's more subdivisions you're gonna need to mimic non-constant AV.

KaiHH

JGO Kernel

Medals: 796

 « Reply #256 - Posted 2015-08-16 23:10:31 »

Okay, I am actually interested in what you want to say - please note that.
So please explain in more detail what you mean/want to change and while doing this, please use simpler language and no words like "energy", "cutoff points", "raw data", "subdivide".
Roquen

JGO Kernel

Medals: 518

 « Reply #257 - Posted 2015-08-16 23:25:08 »

Pesky kids, posting while I'm trying to fumbling one out.  As an aside Jonathan Blow now advises to never do anything other than nlerp...Fabian Giesen (aka rygorous) and Casey Muratori as well.  That's the animation systems of a few thousand video games.

You know what about be interesting?  theagentd collecting and give histogram from wsw.

@KaiHH: Some of the routines I mentioned much earlier are related to all of this.  I'll toss some java versions together when I have some time.
BurntPizza

« JGO Bitwise Duke »

Medals: 486
Exp: 7 years

 « Reply #258 - Posted 2015-08-16 23:25:42 »

He's saying (correct me if I'm wrong) that in practice most calls to slerp tend to be small angles (and if they aren't, you would want to subdivide those angles in your animations), and thus reduce to nlerp, so slerp is not necessary.
Roquen

JGO Kernel

Medals: 518

 « Reply #259 - Posted 2015-08-16 23:34:27 »

That id version (looking at paper) is missing some of the optimizations talked about earlier in this thread.

@BurntPizza: yeap..at conversion or set-up time.
KaiHH

JGO Kernel

Medals: 796

 « Reply #260 - Posted 2015-08-16 23:43:37 »

What are those missing optimizations, then?
And what do you mean by "conversion" or "set-up" time?
(dragging information out of your nose again )
Roquen

JGO Kernel

Medals: 518

 « Reply #261 - Posted 2015-08-17 00:01:27 »

The id paper is doing two forward trig..one is enough.  It'll be in my derivation when I complete it (the info is in recent posts).  Conversion and/or set-up time is the application's problem...you don't have to worry about it.

(EDIT: The split the id version is using is odd as well.  It's so small it'd be better to remove it and add a small number to prevent the NaN)
theagentd
 « Reply #262 - Posted 2015-08-17 01:09:32 »

Looks like I missed all the fun.

You know what about be interesting?  theagentd collecting and give histogram from wsw.
I'm on vacation, and the laptop I was borrowing had its charger block cable bit off by a rabbit. If I find a new one tomorrow I'll see what I can do. What exactly are you interested in? Timings of different slerp implementations?

He's saying (correct me if I'm wrong) that in practice most calls to slerp tend to be small angles (and if they aren't, you would want to subdivide those angles in your animations), and thus reduce to nlerp, so slerp is not necessary.
This is true, and most of the time my animations would hit the fast nlerp path of LibGDX's implementation. However, there is one big exception: animation transitions. WSW supports smoothly interpolating between two arbitrary animation frames. We use that to ensure smooth transitions between idle and walk animations, and during those smooth constant velocity motion is preferable.

I think Roquen was describing the same thing, but it should be possible to implement a binary search nlerp that calculates the midpoint between the two quaternions using nlerp repeatedly until the angle is small enough to produce accurate results with nlerp. Even a 179 degree slerp should be solvable with 5 passes, resulting in a ~12 degree lerp at the end, each iteration only requiring 4 additions and a normalization. I will try that tomorrow.

Myomyomyo.
BurntPizza

« JGO Bitwise Duke »

Medals: 486
Exp: 7 years

 « Reply #263 - Posted 2015-08-17 01:13:27 »

What exactly are you interested in? Timings of different slerp implementations?

The angles being slerp'd, I believe. Experimental evidence for 'most angles are small.'
theagentd
 « Reply #264 - Posted 2015-08-17 01:20:11 »

What exactly are you interested in? Timings of different slerp implementations?

The angles being slerp'd, I believe. Experimental evidence for 'most angles are small.'
Ah, right. Sure, I can do that.

Myomyomyo.
Roquen

JGO Kernel

Medals: 518

 « Reply #265 - Posted 2015-08-17 03:06:39 »

Yeah the angles, but evidence that small angles are naturally occurring to be more precise.  I'll note that significantly increasing the data set of animation data isn't very important since the data's going to move into cache at each processing step.

Also as mention earlier you could just integrate instead (if fixed time step & constant av per data point)

q = dq * q

but attempt to extend to second order isn't worthwhile.  Updating q as well dq when moving to the next data point is a good idea (compounding errors on q)

"However, there is one big exception:" This is what I was calling pose blending much earlier, and yes you can divide and conquer that problem.

Another option is to use a hybrid method (q0=start, q1=end):

lerp(q0, q1, f(t))

or:

result = s0(t)q0 + s1(t)q1.

The angular error between slerp and lerp for all angle rapid approaches a constant shaped function (just varies in scale).
Roquen

JGO Kernel

Medals: 518

 « Reply #266 - Posted 2015-08-17 03:16:29 »

I can get why people get annoyed when I'm terse...but in addition to the points I made above about the reader's level of interest:  There's always too f**king much to be said.

The most important thing about all of this kind of nonsense boils down to how much you care about being able to match your desired angular velocity.

theagentd
 « Reply #267 - Posted 2015-08-18 02:56:41 »

Histogram raw data: http://pastebin.com/R05EY7kn
Still no laptop. SkyAphid was nice enough to generate it. I'd make a graph, but Apple.

Edit: To clarify:
<dot value> = <slerp occurances>

EDIT2:

Myomyomyo.
Roquen

JGO Kernel

Medals: 518

 « Reply #268 - Posted 2015-08-18 09:16:30 »

A slight cleaning pass on the raw data.  Folded negative and positive (they represent the same bin) and reversed order to show from the smallest angle to largest.

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

Forward cumulative as rates: http://www.java-gaming.org/?action=pastebin&id=133

the first three values are: 0.48974302, 0.77403533, 0.8223283.  This means ~49% are in first bin, ~77.4 are in first two, ~82.2 in the first three, etc.
theagentd
 « Reply #269 - Posted 2015-08-18 10:55:03 »

Folded negative and positive (they represent the same bin)

Huuuhhhhh... is that how it works??? Could you explain why? Not using proofs and weird mathematical annotation, but intuition?

The reason why it confuses me is that the dot product returns the cosine of the angle, between the quaternions, right? In that case, if dot=0, then the quaternions are "perpendicular" to each other, there's a 90 degree angle between them. Going further to dot<0 would just mean that the angle increases even more, with dot=-1 the orientations pointing away from each other? How could those two be equal?

Googled a bit. So if I negate all quaternion components I end up with the same rotation as before. Does that not mean that the nlerp of JOML is flawed as it most certainly will take the "long" way around if one of the arguments is negated like that?

Myomyomyo.
Pages: 1 ... 7 8 [9] 10 11 ... 13
 ignore  |  Print

 Riven (581 views) 2019-09-04 15:33:17 hadezbladez (5510 views) 2018-11-16 13:46:03 hadezbladez (2402 views) 2018-11-16 13:41:33 hadezbladez (5772 views) 2018-11-16 13:35:35 hadezbladez (1223 views) 2018-11-16 13:32:03 EgonOlsen (4661 views) 2018-06-10 19:43:48 EgonOlsen (5682 views) 2018-06-10 19:43:44 EgonOlsen (3198 views) 2018-06-10 19:43:20 DesertCoockie (4095 views) 2018-05-13 18:23:11 nelsongames (5115 views) 2018-04-24 18:15:36
 princec 10x Ali-RS 6x VaTTeRGeR 5x KaiHH 5x mudlee 5x philfrei 5x elect 4x Rain8 3x SteveSmith 2x hansolo_ 2x gouessej 2x ral0r2 1x saocrinn 1x Akazan 1x bullen 1x Apo 1x
 A NON-ideal modular configuration for Eclipse with JavaFXby philfrei2019-12-19 19:35:12Java Gaming Resourcesby philfrei2019-05-14 16:15:13Deployment and Packagingby philfrei2019-05-08 15:15:36Deployment and Packagingby philfrei2019-05-08 15:13:34Deployment and Packagingby philfrei2019-02-17 20:25:53Deployment and Packagingby mudlee2018-08-22 18:09:50Java Gaming Resourcesby gouessej2018-08-22 08:19:41Deployment and Packagingby gouessej2018-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