skin-related flags for views/materials

Hi,

I wonder if the performance can be speeded up if it is known, that for a particular view 1) no textures are rendered (e.g. a depth-view) and/or 2) only a subset of skins should be set, e.g. only the diffuse texture (e.g. for generating reflection cubemaps or such).

If I want to do a Z-prepass and I have e.g. a mesh with several hires textures, I could imagine that the depthmap is generated faster if there were a "NOSKINS" flag for views (or materials) that supresses the setting of textures. If so, you could also render such a complex model with one drawcall, too.

In other scenarios, I could also imagine a positive sideeffect if the engine knows that all other skins except skin1 should be not set (skipped), because we only need the diffuse texture. If there were NOSKIN1, NOSKIN2, NOSKIN3 flags or such, this can be achieved.

What do you think?

If only a subset of skins is rendered, the unused skins are not loaded anyway. So performance can not be improved here. If however the shader does not render textures, they are still loaded, so it's theoretically possible to prevent this for improving performance. This won't work for a dept view, though, as the normal view would still need the textures.

I meant that if a subset has 4 skins I need e.g only the first one. In the case of a depth view, I could imagine a two-pass approach in which all textures of objects of the solid pass are supressed (and therefore, multi-subset objects are rendered in one drawcall) and in the second pass, all translucent pass objects with alphatesting on the alphachannel of the first skin are rendered.

That would be great! I suggest a NOSKINS flag which works for views and materials

If and only if you need a normal view and you use normal maps but in that case one could benefit from SKIN1, SKIN2, SKIN3 and SKIN4 flags, which can be used to enforce certain skins as exception from the NOSKINS flag per subset.

Imagine a view that renders the depth and the normalmapped vertex normals to a G-buffer. Lets say the normalmap is stored on skin2 and the alpha of the surface is stored in the B-channel of the normalmap (which is unususal but lets assume that). The ideal setup were to supress all textures of all models except skin2. So, I would create a view and set view->flags |= (NOSKINS | SKIN2), so that only skin2 per subset is set (inside the shader I would assume then that it is entskin1, because it is the only and therefore first skin).

Is that plausible? I am not sure but I guess so...

I am pretty sure that the engine knows which skins are used in a shader, so maybe based on that information one could do some optimizations, maybe if it just means to change some variable or something, this could make sense, but other than this I don´t think it will usually be a big improvement.
But the possibility to query the textures used in a shader kinda removes the need for SKINX flags, doesn´t it?
Disable writing into the color channels however is a big improvement in my experience, but should already be possible by disabling it in the shader?
What I would however like to see a lot, is a way to render into a depth texture, which is especially for shadows very usefull, as it will only require writing the depth, allows to use the slope scale bias thingy, which from my experience works pretty good and most hardware has some extensions to do 4 samples in one (fetch4, AMD) or in case of NVIDIA there is free 2x2 pcf with bilinear filtering or something.

On another note (and I know I am spamming the forum with it... :P), I would love to see DirectX 11 support, which thanks to multithreading solves the issue with DirectX calls taking too much time (in I think GPU Pro, there even is an article on how to fake similar behaviour with DirectX9, by pushing commands into a command buffer, which is than processed in a second thread and they claim it to be a big improvement). But there are also some amazing additions to the HLSL language and of course the shader pipeline (like rendering a depth cubemap for point lights in one pass, thanks to geometry shaders).