>>2906069I looked at it it some more and I found half the reason why it's reading (and writing) the wrong coordinates. Basically MMM doesn't allow you to have non-square (probably also non-power-of-two) render targets, if you try to set non-coinciding x and y dimensions it'll automatically fit to the nearest square. The shader is trying to render to a 1024x32 texture by default. 1024*32 is 65 thousand, and the config file says that the 32 setting can handle 65 thousand verts, so it makes sense. But it gets resized, so it's writing computations come out wrong. Then the shader is trying to process the data on 1024 by 8 times 32 = 512 textures, one extra pixel per hair "layer". Those also get resized, so reads from them are also off.
The expected render target texture (for either _fur_position.fx or the _normal one) for the render targets should be filling-from-the-top-left solid rows of pixels, each pixel representing a vertex, containing the vertex' normal and the position. But since MMM fits the textures to the nearest square, and the shader tries to write to a coordinate that's row#/VPBUF_HEIGHT of 32 by default, it ends up writing to a, if it's the second row (so index 1), 1/32 which is about y=0.03. If it were a 1024x32 texture, it'd write to the second pixel row. But on a 1024x1024, it ends up writing to pixel row#32. So that's why there's a y offset. It's reading using the same methods of dividing by the VPBUF_HEIGHT constant, which comes out wrong as well.
Fixing it is going to be annoying since the division by height is used in quite a few places all over the shader. I'm gonna do it tomorrow if you don't mind.
But there's one other issue where there's gaps between the x positions of the vertices. It goes 2 pixels, then an empty spot, and repeats until the 20th sequence where there's a single pixel. I'm not sure why that happens. Maybe it's just a vertex that has negative values and thus no real color to show. I won't be sure until I clear the first problem.
