Question

If I have a set of random floats (0.0f - 1.0f) around a sphere (or even on a 2D grid would work too), each of which only differ by about 0.1f from their neighbors, is there a way to transform these floats into, say Colors, each of which's RGB values also only differ by about 0.1f from their neighbors in a way that has (essentially) equal possibility of getting any color (so some colors aren't biased over others)?

The method I'm using is this, where after each vertices' final offset is complete I scale all of the offsets down to float values from 0.0 to 1.0, where these float values still reflect the initial distribution of values. I could post code snippets if it'd help, or they're in the edits if you're just curious.

Here's a potential answer, thanks Hot Licks! Something that gave a little more even distribution might be nice, though. Still, it's a start (and kinda cool on it's own), yes thanks!

Random randomGen = new Random();

int randomOne = randomGen.nextInt(256);
int randomTwo = randomGen.nextInt(256);
int randomThree = randomGen.nextInt(256);

float offsets[] = new float[vertices.length];

... // Calcuate the offsets via the method described in that article (code is in the edits if you're curious)

for(int i = 0; i < vertices.length; i++)
{
    float randomFloat = offsets[i];

    float r = (float)((int)(offsets[i]*255.0) ^ randomOne)/255.0f;
    float b = (float)((int)(offsets[i]*255.0) ^ randomTwo)/255.0f;
    float g = (float)((int)(offsets[i]*255.0) ^ randomThree)/255.0f;
}

edit: Removed much of the extra stuff and got to the meat of the question. You can see edits if you're curious about code snippets or other related info, but this is really the bulk what I'm asking.

edit edit: Added (partial) solution code snippet.

Was it helpful?

Solution 3

I don't know what you need in terms of distribution, but I'd consider something like XORing the fraction bit patterns of successive random numbers together, or possibly just XORing the random number with 10 fixed random patterns.

But I suspect this would only work if you were dealing with a uniform distribution.

OTHER TIPS

Um, I think what you want is nextGaussian().

The other option would be, to take a page out of the Categories playbook, to view the colors as representing a spot on a spectrum, then you fetch a single random and find the corresponding color in one operation. So let's say for the sake of argument you make 100 colors from RGB values where the first is R:256 G:0 B:0 through R:0 G:0 B:256. If there were 100, then you get your random #, and say it's .56, you go and get the 56th # in the array.

Is there a way that I could turn that single float value into n float values, each of which would be (essentially) unrelated to each other and reflect this same distribution?

No. The requirements are contradictory.

If you take a single float value and generate N other floats from it in a deterministic fashion, then they are going to be related by definition. And also highly predictable ... given the first value.

The only thing I can think of is to try to find a cheaper random number generator. (For instance, it would be a mistake to use a SecureRandom generator ... if that is what you are currently doing.)


The key here on the randomness is that generating random numbers isn't the problem (I'm using a very quick random number generator), it's generating them in a smooth like distribution on a sphere, so speeding it up isn't really an option I think without reducing distribution quality. My random method is very optimized, it's just slow by nature.

Well I still think that the answer is the same ... unless you can find some way to speed up the "distribution around the sphere" problem. (Obviously, you could exploit rotational symmetry ... but equally obviously, that would give manifestly non-random results.)

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top