-1

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.

Xilo27
  • 15
  • 4
  • I don't know what you mean by "reflect the single value". –  Jan 27 '13 at 03:56
  • I'm not sure what you mean by "ran this method again independently to obtain a series of floats". If I'm not mistaken, that method gives a spherical landscape from slicing and growing/shrinking. What series of floats do you mean, and is there a specific reason you can't just use `Random.nextFloat()`? – Geobits Jan 27 '13 at 03:59
  • @Geobits Essentially, I used that method, than compared all of the offsets together to generate floats from 0.0-1.0 with the same distribution as the land generated via that method (one for each vertex on a sphere). I can't use Random.nextFloat() because that just gives me noise - I need a smooth transition from point to point. – Xilo27 Jan 27 '13 at 04:28
  • @JackManey The most important thing is this: "return similar colors for close values of the single random float." Essentially I have a smooth distribution I like, and I want each element generated from this to have that smooth distribution as well, while seeming relatively independent (from the other elements). – Xilo27 Jan 27 '13 at 04:30
  • @Xilo27 - I still have no idea what you mean by "similar". Edit your question to include some code that illustrates what you mean. –  Jan 27 '13 at 04:33
  • @JackManey Does that last part somewhat explain it? Sorry about not being too clear, this is my first question on StackOverflow so I'm working on the clarity/conciseness. Thanks for everyone's help though! – Xilo27 Jan 27 '13 at 04:57
  • Shouldn't it be `nextInt(256)` otherwise you will never get 255. – Peter Lawrey Jan 27 '13 at 08:52
  • Note that there is Float.floatToIntBits and Float.intBitsToFloat that will give you access to the actual float internal bits, making it easier to XOR the entire float mantissa, without a lot of conversions. (You should note, however, that this will tend to produce synthesized numbers in the same "range" as the original, though, unless you somehow finagle the exponent.) – Hot Licks Jan 27 '13 at 18:28
  • @Lawrey Yes, edited snippet. – Xilo27 Mar 30 '13 at 19:22
  • @Hot Licks Thanks, but it looks like this method works as is. And sorry, I see that this question is too general/only helpful for really one situation/technically not possible, but thanks for everyone's time anyway. – Xilo27 Mar 30 '13 at 19:24
  • Though it looks like, I admit the question wasn't really phrased in this way (that's something I've gotta work on), but [this](http://en.wikipedia.org/wiki/Diffusion_(cryptography)) is what I was looking for: A formal means by which one number relates to another one in a very random manner. Sure, 50% probability is too much, but if I had a function that had, say, 5-10% probability of a given bit swapping when you swapped another one, which each higher bit having lower and lower probability (and had three separate functions for each color), it would create somewhat of what I needed. – Xilo27 Mar 30 '13 at 19:27

3 Answers3

0

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.)

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • On your first point, you're very right, they are contradictory, but is there any processes that would make them seem fairly independent enough, or, more importantly, just allow a wide range of combinations of both values? On your second point: 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. – Xilo27 Jan 27 '13 at 04:34
0

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.

Rob
  • 11,446
  • 7
  • 39
  • 57
  • No, unfortunately smooth distribution isn't exactly what I needed, instead, more of what's explained in the last part of my post (smooth interpolation over a surface). That's an interesting idea on the second part too - but I don't think it'd give an equal distribution of colors, unfortunately X) – Xilo27 Jan 27 '13 at 04:59
  • What does that mean: would not give an equal distribution of colors? If you are independently getting a single random value for each number, the colors should be completely random. You keep saying similar and random. How does that make sense? – Rob Jan 27 '13 at 05:15
  • Never mind, I see what you were saying here too - that would work very well (even maybe interpolating between each color) - but the answer below works more conveniently for what I was looking for. – Xilo27 Mar 30 '13 at 19:32
-1

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.

Hot Licks
  • 47,103
  • 17
  • 93
  • 151
  • Actually, this kinda works! Edited post for solution code snippet. I'm curious if there's a more reliable/fuller distribution way (this only gives me specific colors, not a random distribution of them), but this is a start and will work for most my needs, thanks! – Xilo27 Jan 27 '13 at 05:21