Mapping vertex height to color: color_mode options for

    Feb 24 2014 | 8:07 pm
    Hi all,
    I'm making a patch where I take data from a external device and create a 8x8 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 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 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, 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?

    • Feb 24 2014 | 9:11 pm
      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.
    • Feb 25 2014 | 1:25 am
      Thanks Rob! 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 set to 0) of 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 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, 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 color input. Does anyone know why this might be happening? I am attaching a screenshot below. Thanks!
    • Feb 25 2014 | 2:08 am
      Update: Problem is that RGB colors are normally represented as data type char, but I guess the color input of is expecting a float between 0 and 1? At least that's what I gather from looking at the output of a (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).
    • Feb 25 2014 | 7:03 pm
      you can also enable lighting and automatic normals to get a nicer rendering: @lighting_enable 1 @auto_normals 1
    • Jun 17 2014 | 12:04 am
      Forgot to reply but yes, indeed the rendering is much nice using @lighting_enable 1 @auto_normals 1 Thanks Rob!