Prevención del error SHRT_MAX

Regolero escribió:¿Ahora que hay que coger la calculadora para hacer props?

tiene pinta de que sí

Solo a mí. A ti no te haría falta, los cálculos te salen automáticamente. Recuerda las clases que le diste a Sirlancelot en los tiempos de jueces de Águilas

Tengo que pedir mis más sinceras disculpas

Mucho me temo que a pesar de toda la información expuesta (que consideraba verídica), hay modelos que pese a reducirse en menos de 65534 vértices, vuelven con el error del SHRT_MAX. Eso sí, se trata de modelos que tienen, como mínimo, más de 200.000 vértices, o sea que puede que afecte en contados casos.

Me he pasado buena parte de la noche intentando dar con una solución, ya que parece que incluso está relacionado con el tema de las texturas y materiales del modelo. Para mi desgracia, las distintas guías de Blender y Python que afloran información sobre el tema se meten con códigos y más códigos, que a mí, con mis nulos conocimientos de programación, se me resisten. Se me dio una casualidad con un modelo que convertí inicialmente por grupos (regotruco 2.0) y funcionó, pero al ver su peso de texturas (110 MB) lo convertí a textura unificada (20 MB) y aun repitiendo el proceso anterior, me saltó el error.

Las últimas informaciones que llegué a atestiguar ayer mencionan el tema de la imagen y el formato "ushort" que tiene un límite de 65534. Lo que no sé es qué demonios significa esa cifra, pero no sé si es relacionado con vértices, edges o faces. Hay reportes que mencionan la profundidad en bits de los archivos de textura, una excesiva resolución, etc, etc. No sé si es que hay demasiados vértices asociados a la misma textura o si ésta ha sido codificada con más valores de los que permite el formato "ushort", que tampoco sé lo que es.

Mi última prueba trata con pasar la textura unificada a un archivo .jpeg a una profundidad de 256 bits, e ir probando en cada formato de imagen hasta dar con una solución, pero no sé por dónde atajar. Lo que está claro es que existen el formato "ushort" y un "límite de 65534". También, como apuntan otros medios, el error se cita en el formato del modelo.

Lo que sí puedo decir, al margen de todo esto, es que sigue siendo posible de resolver a través de crear más empties (el regotruco 2.0), por lo que no es que no tenga solución. Sin embargo, esperaba dar con una guía respecto a cuántos grupos son necesarios crear para que el modelo no salte error, y pese a que pensé haber encontrado esta guía en el último vídeo expuesto, me temo que el error nos la ha vuelto a jugar.

Esto significa que puede ser que la información de este hilo, tanto para bien como para mal, no sirva Pero es un buen punto de partida que espero que pueda servir para algo

Pues nada..., debo casi descartar que el shrt max tenga que ver con los vértices. Por todas las consideraciones, creo que tiene que ver con la textura. Hubo un modelo que no dio error al exportarlo convencionalmente, y que me dio el SHRT_MAX al hacerlo con la textura unificada.

Así pues, he buscado y rebuscado información entre bits de imagen (recomiendan no poner el 32 bit float, yo qué sé qué es), diferencias entre textura, imagen y material, cómo intentar hacer un bake, etc etc. Nos queda reductor de polígonos o dividir en más grupos. Así que el vídeo de este hilo me parece que queda descatalogado hasta que consiga dar con una solución, pero me temo que trabajamos en una versión tan antigua que es más difícil acceder a explicaciones y posibles soluciones

Iba a compartir los enlaces de donde extraje la información relevante, por si pudiera servir en un futuro, pero han volado de mi navegador

En uno de ellos, mencionaba algo así como el bit de la imagen. Decía que si era de 8 bit estaba en torno a -126 a 126 (Creo), y que si era de 16 tenía un límite superior de 65534. O sea, que todo está relacionado.

Hay errores de Blender tipo SHRTMAX que mencionan estos dígitos. Uno de ellos es el de ubyte format requires 0 < number < 126. Luego está otro de 255, y así. Curioso es que en un mismo modelo que da el SHRT_MAX, salta un error tipo "1 , 2 , 3 hhh" cuando lo exporto con el regotruco 1.0, y el SHRT_MAX cuando es el regotruco 2.0.

Total, que pensando que tendría que ver la textura, he estado mirando la forma de poder editar los bits de la imagen y que el Blender permita exportar. Estoy unificando las texturas, como siempre, y luego ajustando los bits en el paint.net.

Por otro lado, otra de las carencias del unificador de texturas hace que el modelo pierda mucha calidad incluso en el Blender, por lo que en lugar de compilar las imágenes en una, estoy intentando hacer un 'Bake', que en Blender se traduce en copiar. Existe la forma de hacer un 'merge' o fusionar todas las imágenes en una, según el Blender, que no es el script que nosotros hemos utilizado. El problema es que al fusionar las imágenes en una, no se conservan los UV (mapeados). O sea, que estoy buscando la forma de poder sobrescribir el UV para aplicárselo a una nueva imagen que fusione las anteriores y que en el bit y resolución adecuados permita mejorar la calidad. Esta es mi comedura de cabeza

PD: Aunque lo mencionemos como solución, realmente no estamos solucionando el error, solo previniendo o sorteando que ocurra. Solucionarlo implicaría entrar en el script y en comandos para conseguirlo, lo que lamentablemente ni siquiera me propongo indagar

Leyendo más información sobre el tema, ya por pura desesperación tecleando en Google "límite de 65534 en Blender", sale especificado nuestro querido SHRT_MAX. Y aunque parece guardar relación con la textura, vuelve a citar el contador de vértices.

Por un lado, parece que el problema está en 65534 vértices con mapeo, que es un límite para guardar un MESH con texturas de 8 bit. No soy informático ni nada parecido, por lo que me disculpo por explicar tan mal las cosas. Pero parece que la cosa está en eso, en un límite de 65534 vértices por modelo. Del mismo modo, ahora estoy leyendo que el contador que tiene el programa (Blender en nuestro caso) es impreciso a la hora de contar vértices, y que perfectamente puede contar los 'Faces' como vértices también. Por eso, en modelos donde coincida que tenemos menos de 65.534 vértices pero una tremenda cantidad de faces o edges, es posible que de algún modo se superpongan o se cuenten en la suma, y por eso sigue saltando el error.

Parece que Unity, otro programa, una vez detecta que el modelo excede esta cantidad de vértices lo divide automáticamente en dos meshes. A este paso, casi resulta más fácil abrir el mod en ese programa para que lo divida en el número de partes correspondiente

No sé cómo puedo reducir los triangulitos, faces y edges en el Blender.

Aquí dejo la fuente: https://forum.unity.com/threads/meshes-may-not-have-more-than-65535-vertices-at-the-moment-or-is-it-triangles.170030/