Short answer: route norm/cell into [swiz z].

Longer answer: The cell and norm operators will have as many dimensions as there are dims in the matrix/texture coming to the jit.gen/jit.gl.pix's first inlet. So if you are sending the "jit.bfg 3 float32 10 10 10" to the first inlet, then cell, norm etc. will be 3-element vectors. You can pull out individual elements (dims) of the vector using [swiz x], [swiz z] etc. (or [swiz 0], [swiz 2] etc.). And you can pack values into bigger vectors again using [vec] and [concat] operators.

Thanks Graham, but in my test norm->swiz 2 is always 0

So jit.spill is only showing the first slice of the 3rd dimension (the lists should have 27 elements, not 9!). A quick test of swapping the [norm] for [noise] in your patcher verifies that the jit.gl.mesh is only receiving 9 points too -- I think jit.gl.mesh can't handle 3d matrices either.

In general support for 3D matrices in Jitter is much more limited than 2D matrices, unfortunately.

So here's a demo showing that a) jit.gl.mesh is only showing the first two dimensions of the incoming matrix, and b) the norm *is* generating the 3rd axis data as it should:

So Joshua just sent me a patcher that shows how to convert a 3D matrix into a 2D matrix, for use with jit.gl.mesh, jit.spill, etc. Awesome!

However, as noted & demonstrated in https://cycling74.com/forums/3d-matrix-with-jit-gl-multiple it's also probably better to work with a 1D matrix and generate 3D coordinates when needed via a jit.gen or jit.gl.pix.

Wow Graham thank you for your time, and for the last patch to convert 3d into 2d at the end I think you are right it's better to work with 2D matrix