Color is 3 int. The most precision you can get with normalized data is 255 values , so 1/255. But you can treat vertex color as a regular map channel without converting to 0-255 colors and losing information, as i explained in the other thread. Looks like fbx uses floats and not 0-255 colors so it retains the correct informations.
just looking at the docs, colors are described as floats not ints, but because of reasons they get resampled to the 255 range all the time.. and they suggest to use a point4 value instead - which probably doesnt really help in your case. Maybe you can store that information in an additional uv channel?
Ah you're right, i can set and get vertex color as floats. So nevermind what i said . There shouldn't be any loss in conversion. Unless the exporting format is remapping as int.
Oh wow, ya you guys are right. The accuracy is maintained even though it clamps it to 255. I was just resampling the colour instead of actually calling a getVertColor haha O___O
And also can confirm that FBX retains the full float value as well. Perfect, thanks for your help!
Replies
Does this thread help ?
http://polycount.com/discussion/185330/struggling-to-bake-local-position-to-vertex-color-in-maxscript-mcp-for-blendshapes-in-unity
https://github.com/apras/Unity-VertexTextureFetchAnimation
Color is 3 int. The most precision you can get with normalized data is 255 values , so 1/255.
But you can treat vertex color as a regular map channel without converting to 0-255 colors and losing information, as i explained in the other thread. Looks like fbx uses floats and not 0-255 colors so it retains the correct informations.
color from maxscript reference:
http://docs.autodesk.com/3DSMAX/15/ENU/MAXScript-Help/index.html?url=files/GUID-D8DBE1AA-F3D7-4708-93FA-7C28845A1C03.htm,topicNumber=d30e158728
There shouldn't be any loss in conversion. Unless the exporting format is remapping as int.
And also can confirm that FBX retains the full float value as well. Perfect, thanks for your help!