¿Es una buena práctica usar todas las unidades de textura disponibles?

Cuando se aplican múltiples texturas a una malla, como para el mapeo de protuberancias, generalmente se unen las texturas a las primeras unidades de textura fija, por ejemplo: difusa = unidad 0, protuberancia = unidad 1, especular = unidad 2, luego se siguen reutilizando para cada Malla diferente con diferentes texturas. Pero siempre me he preguntado por qué glActiveTextureadmite tantas unidades de textura (en el enlace anterior, dice al menos 80).

Entonces se me ocurrió que una forma posible de administrar texturas es unir texturas distintas a cada unidad disponible y dejarlas habilitadas, simplemente actualizando el índice de muestra uniforme. Eso debería mejorar el rendimiento de representación al reducir el número de interruptores de texturas. Si tiene menos texturas que las unidades máximas de textura, nunca tendrá que desvincular una textura.

¿Es esta práctica estándar en aplicaciones OpenGL en tiempo real (creo que esto también se aplica a D3D)? ¿Y hay implicaciones de rendimiento no obvias al adoptar este enfoque? ¿Sobrecarga de memoria quizás?

El hardware moderno realmente no tiene el concepto de puntos de unión de textura como lo expone OpenGL. Por el contrario, la unidad de sombreado utiliza un descriptor (que es solo un tipo de puntero grueso) que puede abordar cualquier textura siempre que resida en la memoria de video. Esto es lo que hace posible cosas como texturas sin enlaces . Por lo tanto, la gran cantidad de "unidades de textura" disponibles en las implementaciones actuales simplemente está tratando de mover a mano esta parte ahora irrelevante de la API.

Dicho esto, la forma recomendada de implementar lo que está tratando de hacer (evitando volver a unir las texturas) es usar matrices de texturas , que le permiten indexar dinámicamente en un conjunto de texturas en el sombreador, siempre que todas tengan El mismo formato y tamaño. Esta presentación contiene más detalles sobre estas y otras técnicas para reducir la sobrecarga del controlador al renderizar con OpenGL moderno: Aproximación a la sobrecarga del controlador cero