What is the fastest way to generate a CFrame of random orientation?

[asadefa]

Given:

local Rand = Random.new(SomeSeed)

Would this be faster:

local Frame = CFrame.Angles(Rand:NextNumber(-math.pi, math.pi), Rand:NextNumber(-math.pi, math.pi), Rand:NextNumber(-math.pi, math.pi))

Or this:

local Frame = CFrame.lookAt(Vector3.zero, Rand:NextUnitVector())

Or some unbeknownst to me 3rd way (please share)?

As a side note, do you know if Rand:NextUnitVector() or Vector3.new(math.random()-0.5, math.random()-0.5, math.random()-0.5)*2 is faster, even though the former is more accurate?

[SubtotalAnt8185]

I feel like the first would be faster. However, I’m ready to be proven wrong.

[DasKairo (Cairo)]

Probably the first one as a guess.

---

Small Thing:

You can use math.random() without any arguments which will generate a random number with decimals. While being the “fastest”, It is however limited to numbers below 1, which would have an Angle Below 60 in Radians.

[asadefa]

There is a niche reason I am using Random instead of math.random(). Visual effects, such as a custom explosion, should be handled on the client only. So I use FireAllClients() from a RemoteEvent. But I want all clients to see exactly the same thing, even though no one would probably notice or care. So I pass a seed from the server with which the clients generate identical visual effects.

[DasKairo (Cairo)]

I am not Suggesting that you should use math.random, I’m saying that you could, but you are limited to a certain amount

(I mean, I am, and Im not)

[SubtotalAnt8185]

math.randomseed exists though. However, I don’t know if it’s faster.

[asadefa]

Oh, so I could just call math.randomseed() with the seed sent by the server in OnClientEvent, instead of using Random.new, would that work as expected?

[JarodOfOrbiter]

It’s really important in programming to be able to run these sorts of tests yourself. The odds are slim that anyone here will have tested it already. Occasionally you’ll get a CS major who chimes in with what sounds like an educated response, but often as not they’re wrong for whatever reason such as oddities with how Lua and C interact.

@asadefa

even though the former is more accurate?

I’m not sure if this is what you mean or not, but I’m going to say it anyways because your wording is a little vague and future readers may benefit from the knowledge. NextUnitVector exists to avoid the bias towards the poles that the first method creates.

CFrame.Angles method

NextUnitVector method

Reference thread

I’ll go run some benchmarks since I’m already in Studio, but I do want to re-emphasize how important it is to be able to run benchmarks yourself. You’d be done within 5 minutes instead of waiting an hour for some guesses and speculations.

Here are the results from a benchmark with 10,000 iterations each.

Stick with the NextUnitVector approach.

[SubtotalAnt8185]

What if they were combined? For example, it used CFrame.Angles but it used the unit vector numbers converted to radians.

[JarodOfOrbiter]

You’d run into bias towards the poles again.