Los problemas de ancho de banda se reducirán principalmente al tamaño y la cantidad de texturas y la complejidad de los objetos que está tratando de renderizar. La optimización en esta área no es muy diferente de los medios 2D en concepto, y hay toneladas de herramientas para la compresión de texturas y la simplificación de modelos (probablemente integrados en lo que sea que use para crearlos en primer lugar).
Dependiendo de lo que esté creando, puede aprovechar la generación de procedimientos del lado del cliente como una especie de mecanismo de compresión. Si puede expresar algo (como una textura o un mapa de altura del terreno) como un algoritmo, puede transmitirlo casi gratis. Por ejemplo, si quisiera darle a algo una textura de mármol, podría usar funciones de ruido de perlin bien documentadas para generarlo en el lado del cliente, en cuyo punto la textura de 256 × 256 tiene exactamente el mismo costo de ancho de banda que 4092 × 4092 (o superior). También debe tener en cuenta las limitaciones de WebGL en cuanto al número y tamaño de la textura, el recuento uniforme y los vértices máximos en una escena, pero probablemente tendrá un cuello de botella en el ancho de banda antes de la capacidad técnica a menos que esté usando mucho la generación de procedimientos.
En cuanto a la usabilidad, hay algunos problemas importantes:
- ¿Dónde almacena sus archivos de desarrollo web?
- ¿Cómo se crean interfaces planas para sitios web?
- ¿Cuál es el mejor agregador que proporciona noticias basadas en temas seleccionados por el usuario? (Preferiblemente no use Google)
- ¿Cuál es el mejor marco web para crear un back office de juegos con MongoDB?
- Web Marketing: ¿Qué necesito para llevar mi aplicación web al siguiente nivel?
Primero, es posible que las máquinas cliente no tengan la potencia de la GPU para representar escenas complejas a velocidades de fotogramas utilizables (por ejemplo, computadoras portátiles de gama baja, dispositivos móviles). Para agravar ese problema es que, a diferencia del 3D nativo, realmente no se puede consultar un contexto WebGL por su potencia o capacidades de GPU. Esto se hizo por razones de privacidad y seguridad, por lo que no fue posible tomar huellas digitales de los usuarios en función de la información de su GPU. Por lo tanto, es difícil saber en qué está renderizando y es difícil predecir si su escena se ejecutará lo suficientemente rápido como para ser utilizable. Puede optar por el enfoque de mínimo común denominador aquí, que es extremadamente limitado, o intentar usar un sistema LOD que amplíe gradualmente los detalles hasta que las tasas de fotogramas caigan por debajo de un umbral objetivo. Eso, a su vez, le costará más ancho de banda y creará más complejidad de código (lea: errores).
El segundo problema de usabilidad es que la compatibilidad con la pantalla táctil es difícil de obtener en 3D, y no hay una gran cantidad de código enlatado para ayudarte a lograrlo. El tercer problema es que los navegadores más antiguos pueden no ser totalmente compatibles con WebGL. Por lo tanto, necesita un respaldo 2D para admitirlos, y puede decidir forzar un respaldo 2D en dispositivos móviles también para evitar problemas de rendimiento y UX.
No puedo decirle específicamente cómo CL3VER aborda estos problemas, pero eso sería algo sobre lo que querría leer antes de tomar una decisión. Hay otras opciones, como ThreeJS y Unity, que pueden tener diferentes compensaciones.
