This project is read-only.

Lowering multitexture mem requirements

Nov 8, 2007 at 9:28 PM
Would it be possible to pass the terrain texture map to the shader and in the pixel shader load it into a float3 as a sampler? If so I wouldn't need to store the multitexture weights inside every vertex. This would lower memory requirements for the vertex buffer, but as the cost of an extra texture lookup in the shader.
Nov 8, 2007 at 9:55 PM
I'm not entirely sure what you're asking.
Nov 8, 2007 at 10:41 PM
Right now, for multi-texturing/terrain painting I give every vertex a RGB value in a vector3, you'll see this in VertexTerrain. This allows the shader to determine the color of the pixel based on 3 textures.

I was wondering if I could pass the RGB values for the terrain in through a texture sampler instead of in each vertex. This would allow us to not only lower the memory requirements, but would allow full texture splatting resolution at ANY Lod.

I'm fairly certain this will work, and am excited to try it.
Nov 8, 2007 at 11:04 PM
You mean something like this?

sampler blendCoeffs = ...;
 
sampler ground1 = ...;
sampler ground2 = ...;
sampler ground3 = ...;
 
float4 PixelShader(...) : COLOR0
{
    float4 blendWeights = tex2D(blendCoeffs, input.texCoords);
    return (blendWeights.x * tex2D(ground1, input.texCoords)) + (blendWeights.y * tex2D(ground2, input.texCoords)) + (blendWeights.z * tex2D(ground3, input.texCoords));
}

Thats definitely do-able. It would give a little memory savings, depending on what resolution of texture you use.
Nov 9, 2007 at 12:37 AM
Edited Nov 9, 2007 at 1:29 AM
Pretty much, yes. I did a test, and used a single pixel wide brush and drew my name into the terrain texture map. The only time it was legible was at full LOD, otherwise I lost the vertices that held the information for those single pixels when the LOD skipped over them. I believe if we use the method we're talking about now we won't lose any texture map information, which will result in a nice looking terrain even with a slightly lower LOD.
Nov 9, 2007 at 6:40 AM
Success!

Not only did it work, but I realized we don't even need to pass in texture coordinates at all because the texture coordinates are being calculated within the shader. This means we are now only needing to pass position and normal. The entire buffer is down to 74mb now. However the program still uses too much RAM. Not sure why. Task manager puts it around 250mb, but the CLR says it finishes around 110mb.
Nov 9, 2007 at 8:34 AM
If you submit a patch we could all have a look at it, Though be aware that Xna uses a lot of mem too and there isn't anything we can do about that. You need a profiler if you are going to do some meaningful analysis, CLR Profiler is free and gives you the info you should need.
Nov 9, 2007 at 1:27 PM
It could be the CLR hanging on to the memory it originally allocated in case the program needs it again. It's possible that the 250 meg figure is your peak memory usage during startup. Even through the working set is less than 100 meg when running, the CLR could be hanging on to the rest if it sees that's not really a lot of contention for the memory.

Though, like Sturm said, profiling is the only way to know for sure what's going on.