Really? With passing I mean I bind a texture to one of the channels (glActiveTextureARB( channelNum ). If I let a (cg) shader explicit refer to "TEXUNIT16" or higher, it crashes AFAIK. Tried that on a ~1.5 year old nVidia card btw. Correct me if I'm wrong, but the table you showed is the maximum number of texture-reads within a shader program, not the amount of active textures right?
On current hardware it goes up to about 160, see here.
Ifso, that still means I'm limited to 16 different textures when rendering (instanced) objects...
Well, it doesn't really matter. I assume instancing only makes sense if you have a lot of the same objects. Which is usually not the case for my maps and their contents. Although plants or floor-junk could share the same material(texture-set) to minimize the switches, then gets sorted on VBO instead and render in packs with instancing. A chair that appears 4 times probably doesn't benefit much from instancing, so I keep it sorted on material instead.
You said binding-time is nearly the same. Could be, but the main difference is that I only have to fill the constant-buffer once, while with traditional parameters, I have to pass the parameters each time I apply a shader. Example, I have a material "wood1a". It uses 2 textures, and has a specularColor float4 vector. When I apply "wood1a", I have to bind 2 textures, and pass vector. Each time again. Thousands of passings happen each render-cycle currently.
Asides from global dynamic stuff like the cameraposition or lightcolor, those parameters never change though, so isn't it just possible (in OpenGL) to create a buffer that contains *all* static parameters, and upload it once? So I don't have to pass them anymore? I red somewhere such a buffer (in DirectX) has 4096 floats or vectors. Dunno if that is enough to store all numeric parameters from all materials I have, but it is quite a lot. As you showed, I could then do something like:
- float4 parameter1 = cbuffer[ material_offsetIndex + 0 ];
- float4 parameter2 = cbuffer[ material_offsetIndex + 1 ];
- Use the parameters, whatever they are
Then I only have to bind that cbuffer once, and pass the "material_offsetIndex" parameter for each different material. Would that make sense (if possible at all)?
I'm a slow learner, but that gives a better understanding. There are plenty of MSAA demo's so I should look there. And hopefully a demo that uses the masking/coverage technique. Faulty ordering doesn't matter as long as the viewer doesn't really see it... which I doubt with foliage. I guess it only works properly for "black-white" transparency (a metal fence for example) and not for translucent surfaces such as glass). But that's ok for grass and the likes.
I still wonder though how edges will look when using it in a deferred rendering pipeline. Averaging colors is not a problem, but normals, and especially positions/depth creates weird results. I could only let the (near) opaque pixels write normals/depth, but that gives a blocky edge when applying a light on it, right?
- Thanks again for the explanation!!