Mapping vertex height to color: color_mode options for jit.gl.mesh?
I’m making a patch where I take data from a external device and create a 8×8 cellblock table from it, with data values inside each cell. At the push of a button, I dump the x and y position of each cell, along with the corresponding data point, and send it to a 3 plane matrix (one plane for x, y, and z (data value)). I then send this data to a jit.gl.mesh to be rendered/visualized as a 3D "topography map" where the x and y position of each vertex is set by the x and y planes, and the height of each vertex is set by the z plane (data values plane).Data values can be in the range from 0-127.
What I’m getting right now is something that looks like the image attaceched (with auto_color attribute of jit.gl.mesh set to "ON").
What I want to do now is color each vertex based only on it’s height. In other words, I want to map the values in the Z plane (data values plan) to the RGB value of each vertex, in such a way that the color of a vertex can go through the entire spectrum of colors, depending on the data value (the height of the vertex in the Z plane), which is bound from 0-127. In the end the data should be visualized like a colored topography map (see second attached image, generated by excel).
Does anyone know of a general approach to doing this?
Specifically, I’m also wondering where I can find more information on the color_mode attribute of jit.gl.mesh, because the reference says hardly anything about them, or how to use them.
Can I use a jit.op object to adjust the RGB plane values through an equation based on the Z plane values?
don’t use @auto_colors.
instead create a color matrix for the gl.mesh color input.
you can use a swatch object and the hsl message to set the matrix values. (open the swatch help-file for an example of changing colors by setting the hue with a single dial value).
a scale object can map your z-plane values to the proper hue range.
Using jit.unpack, creating a 3 plane color matrix based on math from the Z values using jit.op, and then using jit.pack and feeding that into the color input (with @auto_colors attribute of jit.gl.mesh set to 0) of jit.gl.mesh allowed me to do this.
So now I am creating a 3 plane color matrix for the RGB values. The G value is a constant 255. As my data point (Z value) goes from 0 -> 63, the R value decreases from 255 -> 0. Then from a Z value of 64 -> 127, the B value increases from 0 -> 255. I am confirming this through jit.print statements, and am seeing varying RGB values where the R and B values range from 0 -> 255 as they should.
I route this newly created RGB matrix into the color input for jit.gl.mesh. This is where the problem comes in. All I am seeing in the rendered image are 2 colors: yellow ( R = 255, G = 255, B = 0) and light blue (R = 0, G = 255, B = 255). So basically, jit.gl.mesh seems to take any non 0 value for R and B, and maximize it to the limit which, for a char data type, is 255. I am expecting to see an image that includes all the colors in between light blue and yellow, which includes many shades of green, but I dont see any green, no matter what I input to the jit.gl.mesh color input. Does anyone know why this might be happening? I am attaching a screenshot below.
Update: Problem is that RGB colors are normally represented as data type char, but I guess the color input of jit.gl.mesh is expecting a float between 0 and 1? At least that’s what I gather from looking at the output of a jit.gl.gridshape (torus) object…
Now I need a method to normalize char data (0 – 255) to float data (0.0 – 1.0). Will update when I find solution.
Update 2: Using a [jit.op @op / @val 255] object to normalize the char values to float seemed to work.
See the images below for the final product. Still doesnt look like the excel file, but I think that would require more data points (a larger matrix).
you can also enable lighting and automatic normals to get a nicer rendering: @lighting_enable 1 @auto_normals 1
Forgot to reply but yes, indeed the rendering is much nice using @lighting_enable 1 @auto_normals 1 Thanks Rob!