koobas.hobune.stream
The question is answered, right answer was accepted
Random.rotationUniform clarification
In the doc it says:
Random.rotation
Returns a random rotation (Read Only).
Random.rotationUniform
Returns a random rotation with uniform distribution(Read Only).
I'm not sure at 100% that I understand correctly this property. If I generate 10 random rotation with Random.rotation I'll get 10 totally random rotation and it's technically possible (but improbable) that I can get almost the same rotation twice.
If I use Random.rotationUniform, I'll have 10 really distinct rotation.
Right or wrong?
EDIT: My question was probably not enough clear (sorry, english is my second language). You basically said the same thing has I thought.
I run some test to see the difference graphically, but I can't see any difference. I generate random rotation with both method for a vector and the randomUniform is not more uniform. So I'm a bit confuse about this property
On the left is random.rotation and the right is random.rotationUniform
@DarkPixel - great way to sort this out. Go to 5,000 and then inspect the poles. Also explicitly set the seed and run both with the same seed. It may be that under the hood '.random' and '.randomUniform' are the same thing now. But in generating random values, when you see the word 'Uniform' it will refer to an equal probability over a range.
Same seed, different result, it's not the same function. Even at 5000 and 1000 I barely see the difference
Nice job. It is the kind of thing I tend to do when I have a question about Unity.
[Begin Conjecture]
There are good reasons for wanting a Uniform distribution. The original developer who wrote Random.rotation fully intended it to be uniform, but at some point someone figure out that there is a bug/flaw. That, however slight, the distribution is not uniform. The $$anonymous$$m cannot just go in and fix the bug. There is code that depends on the original implementation. What if there exists code for saving a game level saved not the individual positions, but the seed and regenerated the positions using the seed and Random.rotation? So to patch the bug and have a truly uniform distribution for future development, they introduced random.rotationUniform. I don't remember this variable from Unity 3.x.
[End Conjecture]
Hey guys, maybe it's my eyes, but I do see some clustering in the the left samples of 50, 10, 500, and 1000. It's not great but I do see some high and low density areas... It seems to me that because we see 3D models of the spheres using 2D pictures it is rather difficult to distinguish the exact location depth-wise of particular points. And this becomes even more and more difficult as the number of points increases.
So, all in all, if there was a small bug of a statistical nature in the original algorithm, I wouldn't be surprised that it's not very easy to observe in the samples @DarkPixel made. Only if the original bug was big enough, the high density clusters and low density gaps would be easily observable. But come to think of it, if that was the case, then the bug would probably not exist at all, because it would be evident to the developer from sample outputs that something is wrong.
Nice work @DarkPixel in pointing this out, and thanks @robertbu for the explanation!
Wrong. 'Random.rotationUniform' means that all possible rotations have equal probability of occurring. I expect if you tested the original Random.rotation you would find some clustering in the rotation. That is if you use the rotation to rotate a vector and then plotted the tip of each vector, Random.rotationUniform would produce a sphere where the points were generally uniformly distributed. With the Random.rotaition you'd likely see some clusters of points.
@pako - Don't be sorry. $$anonymous$$ultiple answers are a good thing. And even if you see an answer, if you think you have a better one, go for it.
I would assume that the first implementation just generates three random values for the Yaw, Pitch and Roll of the rotation. While this seem random there are multiple combinations of Yaw, Pitch and Roll that will represent the same direction. This means those directions have a increased chance to be generated.
What I'm wondering is how they solved this to make the distribution truly uniform.
I'm late here, but the problem doesn't seem to have been addressed after more than five years now. I mean, nothing official, only guesses.
I don't have much more to say than @robertbu. As he said, Random.rotationUniform doesn't guarantee that different rotations will be drawn, but if I'm correct, does give rotations uniformly distributed on the hypersphere. So one would say, why use Random.rotation ? It's because rotationUniform is likely more demanding, hence Random.rotation sacrifices uniformity to performance.
Problem is it's on a 4 dimensional hypersphere, hence it could be difficult to notice visually. The clusters are probably around the 16 projections of the corners of the unit hypercube on the hypersphere. After some thought, I suppose it could still be seen on a projection of the w = 0 hyperplan (or x = 0, or y = 0, or z = 0), where the clusters would be around the 8 projections of the cube corners on the sphere.
But that's my idea of it and I can't say for sure...
My guess is that rotationUniform works by randomizing the Euler angles, which makes the rotation indeed uniform across all axes, while (non-uniform) rotation works by randomizing the xyzw values, then normalizing the quaternion.
As other commenters already noticed, rotation sacrifices uniformity to performance, because on one hand you have to convert Euler angles to quaternion, and on the other, you have no true guarantee of a proper distribution on a 3D sphere.
Normalization isn't cheap either, so I'm thinking that rotation doesn't even do that, but actually manipulates the values in such a way so that the resulting quaternion is already on a hypersphere, in order to maximize the calculation speed, but the points (being linearly distributed each in its own dimension) likely converge to some hyperplanes (where exactly is beyond me, without further research).
And then I thought about this a little more, and now I'm thinking it's quite the opposite.
It's Euler that is non-uniform, in fact, and this is exactly why we use quaternions in the first place, because with Euler angles it's possible to describe two identical rotations with completely different parameters. Therefore, it leads to non-uniformity (forehead slap).
The other method works with the angle/axis approach, that one should be bias-free.
