new Color(r,g,b) dont work

I have problem changing material color on gameobjects;
here what is generated:

here is output in console:
(my suggestion is) So values are correct, but they dont apply on material correctly?

here is what color is actually on material:

that one which gets color(yellow, cyan)
are also junk

Any help is appreciated!

    void DrawMap()
    {
        size = new Vector3((bottomLeft.transform.position.x - upperRight.transform.position.x), (bottomLeft.transform.position.y - upperRight.transform.position.y));

        for (int i = 0; i < (int)Mathf.Abs(size.x) / gridStep; i++)
        {
            for (int j = 0; j < (int)Mathf.Abs(size.y) / gridStep; j++)
            {
                //Color color = new Color(map[i, j], map[i, j], map[i, j], 255);
                Color color = new Color(Random.Range(0, 255), Random.Range(0, 255), Random.Range(0, 255));
              
                Vector3 pos = new Vector3(bottomLeft.position.x + i * gridStep + gridStep / 2, bottomLeft.position.y + j * gridStep + gridStep / 2);

                GameObject other = (GameObject)Instantiate(cube, pos, Quaternion.identity);
                other.GetComponent<Renderer>().material.color = color;
                Debug.Log(other.GetComponent<Renderer>().material.color.ToString());
            }
        }
    }

ok, solved.
Color inputs are from 0 to 1. not 0 -255

Note, there are 2 color structs in Unity.

Color:

Uses a float to represent a percentage of each component color (0 to 1)

and
Color32:

Uses a byte to represent the value of each component color (0 to 255)

They are not interchangeable directly, but can be converted between each other easily (there is a Color32 → Color implicit conversion method defined).

I honestly don’t know why they have 2 colour structs. ‘Color’ ends up being 4 times the size in memory than it would really need to be. I don’t believe unity supports anything with anything greater than 32-bit colour… or does it?

1 Like

They had Color originally; maybe they were planning on supporting more than 32-bit color if hardware ever moved in that direction, and figured a normalized value was the simplest way to future-proof things. However since that hasn’t happened (probably due to display technology remaining stubbornly terrible), they later implemented Color32 because of memory and speed reasons. They kept Color for backwards compatibility.

–Eric