I'd like to pre-calculate the constant coefficients for a 4x3 matrix in C-Script, and transfer these values to a vertex shader script. Reading the release notes, it looks like I can just do this using Material skills 1..4, 5..8, and entity skills 41..44. Is this the only way of achieving my objective, or have I misread the release notes?

If possible, I'd like to have the flexibility of adding additional precalculated constant values in order to minimise the amount of calculation carried out within the shader script itself.

I can add a user var array that you can use for a precalculated matrix. What you you want to use this matrix for, and would it be better to have one global matrix, or a separate precalculated matrix per material?

I have developed a time of day sky simulation, using rough approximations of Rayleigh and Mie scattering plus a pollution variable. All of this can be expressed as the coefficients of a 4x3 matrix. However, the calculations of these coefficients is somewhat complicated, and would probably bring a shader down to a crawl. I'd therefore like to calculate these coefficients outside the shader script on a much longer refresh time.

The vector that goes with these coefficients is dependent on various powers of a sky hemisphere vertex/sun position distance and will have to be calculated within the vertex shader routine. The m4x3 result will be output to the rgb values for each vertex. (I hope that this explaination is not too condensed or obscure!).

As you will see from the above, I'm not actually using material data at this stage, its a pure vertex shader. That said, I'd like to add a cloud simulation at a later stage when material data/pixel shaders would probably have to be used.

Ok, I'll add a 4x4 matrix to the material properties.

Thanks! Would it be too much to ask for both a general purpose 4x4 global matrix, as well as a material one? The shader articles I've read push towards offloading as much as possible onto the cpu leaving only essential calculations for the shader. From my inexperienced viewpoint there would seem to be some value in maximising the ability to transfer pre-calculated data to the shader routine.

For example, given the use made of Perlin noise in many shaders, it could be useful to have a noise generator in C-Script (even better as pre-built code), and a route to transfer data subsets to the shader.

I guess this is still to come in a future beta release, or have I misread the release notes again!

I guess you must have misread almost all of it, then...

Thanks!
I obviously did something crazy the last time I updated the beta, and I was running with the out of date version. No wonder I couldn't see anything new!