'N' Amount of Distinct Colors

[Insane2757]

Here is an interesting problem to think about:

You need to generate 'N' distinct colors using a makeColor(int r, int g, int b) function, where N is some integer greater than 0. If you are unfamiliar with the above makeCol function, check out this page (http://www.allegro.cc/manual/api/truecolor-pixel-formats/makecol). The colors have to be distinct enough so that by visual inspection by the player, they can tell the difference between any of them.

Any ideas?

[Google]

[Sim9]

Hmm, maybe something like this?

Visualize a three dimensional cube. Each axis is a color, and goes from 0 to 1. Subdivide the cube until you have enough verticies for each color required, and then use the vertex positions for each unique color.

I'm not familiar enough with color theory to know if that would work, though.

[Walrii]

My idea.

Picture a color wheel. The actual circle, not the crappy mspaint color box.

To generate "n" colors just pick "n" points equidistant from each other on the color wheel. Instant set of colors.

Bonus: For alternating colors (e.g. color j and j+1), make j slightly darker and j+1 slightly brighter.

Will that work?

Also, I still cannot understand Sim's post. A 3D cube? Each axis is a color? Aren't there like a million colors? Therefore a million axises / dimensions? I think Sim is actively trying to work in some sort of cube / hypercube reference.

[orothain]

My idea.

Also, I still cannot understand Sim's post. A 3D cube? Each axis is a color? Aren't there like a million colors? Therefore a million axises / dimensions? I think Sim is actively trying to work in some sort of cube / hypercube reference.

I think Sim9 was referring to the Red, Green, Blue color model (http://en.wikipedia.org/wiki/RGB), with one axis for each of these colors... so three dimensions (a cube).

[Insane2757]

Picture a color wheel. The actual circle, not the crappy mspaint color box.

To generate "n" colors just pick "n" points equidistant from each other on the color wheel. Instant set of colors.
...
Will that work?
I thought about it. This idea could work if you assembled regular polygons (http://en.wikipedia.org/wiki/Regular_polygon#Regular_convex_polygons) of the correct order. IE: If n = 6, then you would place a equilateral hexagon. Then you would select the colors from which the polygon's vertices would lie. That's really neat, Walrii.

What is interesting in this approach is that you can see as the regular polygon gets rounder, the colors will become less distinct, which you can use as a measure that when you get to, oh let's teach Archive something, icosagons (http://mathworld.wolfram.com/Icosagon.html), which have 20 sides, the colors would start to become similar (if not before that point).

Also, I still cannot understand Sim's post. A 3D cube? Each axis is a color? Aren't there like a million colors? Therefore a million axises / dimensions? I think Sim is actively trying to work in some sort of cube / hypercube reference.
I think Sim9 was referring to the Red, Green, Blue color model (http://en.wikipedia.org/wiki/RGB), with one axis for each of these colors... so three dimensions (a cube).

Yes, I think that was what he was referring to.

Visualize a three dimensional cube. Each axis is a color, and goes from 0 to 1. Subdivide the cube until you have enough verticies for each color required, and then use the vertex positions for each unique color.

I understand this if what you mean by "vertex positions" is the coordinates of one of the corners. ;) I assume that you would just halve the cube into smaller cubes until we have n (or n+1) amount of cubes?

[Travis]

A color cube would be the easiest to represent. You'd just have to take (log_2(n))/3 subdivisions [rounded up] of each R, G, & B to arrive at your colors.

1 color would need 0 subdivisions - you'd just have (1, 1, 1) for your RGB value
8 colors would need 1 subdivision
64 colors would need 2 subdivisions
etc.

What Sim was basically describing is something like an oct-tree color cube. For any n < 8^x, you would just want to round up to that x'th subdivision to have all of your colors.

The trick, I suppose, is choosing which colors to use... you're guaranteed a certain level of fidelity between the colors, but what if you wind up using mostly green colors? Then one room would just be a greener shade of... green.

It's up to you. The color cube would be easiest, though.

[Walrii]

icosagon

A color cube would be the easiest to represent. You'd just have to take (log_2(n))/3 subdivisions [rounded up] of each R, G, & B to arrive at your colors.

1 color would need 0 subdivisions - you'd just have (1, 1, 1) for your RGB value
8 colors would need 1 subdivision
64 colors would need 2 subdivisions
etc.

What Sim was basically describing is something like an oct-tree color cube. For any n < 8^x, you would just want to round up to that x'th subdivision to have all of your colors.

The trick, I suppose, is choosing which colors to use... you're guaranteed a certain level of fidelity between the colors, but what if you wind up using mostly green colors? Then one room would just be a greener shade of... green.

1) How in the world did you know of that word?

2) English plix?