Nuevas posibilidades

[Josep]

Hola,

Evidentemente 3ds Max es el programa líder para el desarrollo de juegos a nivel profesional.

El hecho que se utilice o no para crear productos para MSTS depende de varios factores: su dominio (conocimiento del programa), y herramientas para exportar.

En el caso de MSTS, existe el programa gratuito GMAX, que es una versión reducidísima de 3DS MAX, pero suficientemente buena para desarrollar "addons". Como ejemplo, solamente comentar que en el mundo de Flight Simulator los modelos generados con gmax suelen ser superiores en detalles y afinamiento global que modelos desarrollados con otros programas.

Por ejemplo: los reyes me han traído un "addon" comercial -si, si, de compra...- llamado PMDG 737 NG 600/700 y que por ahora es lo que me ha proporcionado más satisfacción como experimentado usuario de simuladores de vuelo. Pues bien, uno de los slogans de la parte trasera de la caja es "preciso y realístico modelo exterior desarrollado en GMAX"...

Resumiedo: si GMAX es una herramienta muy valorada en el tema de "addons", ¿qué será de su "padre" 3DS MAX?

El "problema" lo tengo por ahora en la capacidad de exportación de 3DS MAX a MSTS, que es muy limitada. Solamente puedo exportar el modelo realizado con 3DS MAX a GMAX a través de formato 3DS (antiguo y obsoleto, ya que era el nativo de 3D Studio para MS-DOS).

Si bien funciona (pidiendo que max respete los mapeados existentes al convertir en malla), debemos luego "soldar" los vértices en zonas de cambio de mapeado en Gmax, para suavizar aristas. (Si alguien tiene el modelo de la Renfe 340 -ex 4000- podrá observar este tema, que tengo solucionado soldando vértices para la nueva versión de la locomotora).

No he probado otros caminos, que en su momento planteó Gizmo (dónde estará...saludos!), a través de exportadores de otros juegos.

En todo caso, me encuentro limitado con este tema, ya que 3DS MAX 7 incorpora el trabajo con texturas Directx (.DDS), así como otras herramientas que hace tiempo que intento implementar para MSTS:

- "tostado" de materiales (Render a textura): si añado iluminación en 3DS MAX, puedo substituir las texturas originales con las mismas más el impacto lumínico. Esto sería ideal para dar volumen (a nivel de textura) a determinadas partes de la locomotora.

- texturas de relieve según las normales: nuevo procediiento de "tostado" de texturas, en las que el relieve 3D que existe en un modelo es substituido por el "render" a textura con el impacto del relieve. Resumiendo: que si tengo miles de tornillos hechos en 3D, el proceso sustituye la geometría con un bitmap con el mismo impacto visual. Difícil de explicar, pero si a alguien le interesa, pongo capturas del tema (típico ejemplo: caparazón de tortuga que el relieve 3D en malla queda substituido por una imagen fruto del "render", quedando una mínima malla con un impacto visual altísimo).

Un nuevo camino de trabajo me ha aparecido con lo que se ha profundizado en el post http://www.trensim.com/foro/viewtopic.php?t=3922 al "descubrir" las posibilidades de la ya para mí imprescindible herramienta de conversión de texturas AceIt.

Efectivamente, AceIt permite exportar a .ACE texturas tipo .DDS, que son las que puedo implementar ahora en 3DS MAX 7...(si digo texturas esto supone también las que pueda generar con los procesos arriba mencionados...). Aunque la salida de estos procesos también puede ser en otros formatos, la posibilidad de exportar en formato .DDS e incorporarlo a MSTS me tiene intrigado...

Una captura de 3DS MAX 7 con el módulo abierto de exportación de textura (cualquiera que tenga, ya sea previamente existente en formato .tga o bien como resultado de un cálculo) con las posibilidades de salida del formato .DDS

Camino a conseguir: que el formato .3DS guarde estas nuevas implementaciones en la malla al exportar el modelo en este formato.

Para profundizar: si MSTS admite alguna otra implementación no documentada de texturas -aquello de que no se acabó de completar, y ahí está, como fue el caso de los brillos...- y podemos trabajar con formatos DTX diferentes al 1...

En otro post cuento més sobre DXT1, DXT2, DXT3, DXT4 y DXT5, y sus posibilidades.

Por si sirve a alguien...

Josep

[javierfl]

Hazme callar si digo tonterías, porque de este tema soy un lego total. Me imagino que lo que señalo a continuación ya lo conoces y lo usas y por lo tanto olvídalo en este caso.

En el proceso de exportación que estamos desarrollando, uno de los problemas básicos es que Gmax acepte los ficheros 3ds creados con Canvas, y que una vez aceptados lo haga de la manera más completa posible, que no pierda mapeados, suavizados y demás.

Después de varias pruebas yo uso el Autodesk .3DS Model Importer de Chris Cookson. No sé quien me dio la pista de este plugin y si es conocido o no. No es precisamente nuevo, ya que su versión actual 1.1 es de 2001, pero funciona muy bien, al menos para lo que yo preciso. Se puede bajar de http://www.scriptspot.com/Main_Scripts.asp?BrowseType=I/O&Sort=Popularity&ST=-1&SearchField=&Page=1

Lo que dices del formato .DDS suena interesantisimo, y aunque el acceso al 3ds Max es tan difícil por su elevadísimo precio, por favor tennos al corriente.

Saludos:

Javier.-

[Josep]

Javier,

Gracias por la información. Probaré este conversor, aunque creo que no sea mejor que el exportador .3ds del propio 3DS Max. Aunque nunca se sabe...

Por otro lado, utilidades que convirten a .DDS hay varias, utilizadas sobretodo para Flight Simulator. Buscaré algunas, a ver si pueden ser útiles. Lo comento, porque AceIt admite conversión de .DDS a .ACE, y no sé si podemos ganar algo...aprovechando este nuevo camino

Finalmente, comentar que estoy trabajando en la conversión de apha premultiplicado y no premultipicado, a ver si se gana algo (lo dudo, per por probar...).

Os adjunto una tabla con la explicación de todos los formatos posibles de .DDS

---------------------------------------------------------------------------
Formatos .DDS
---------------------------------------------------------------------------

A8 R8 G8 B8—32 bits por pixel: 8 bits para cada canal RGB y 8 bits para el canal alpha. Resultado: imagen de 16.777.216 colores, con 256 posibilidades de transparencia. (Comparativamente, típico .TGA de 32 bits).

A1 R5 G5 B5—16 bits por pixel: 5 bits para cada canal RGB, y 1 bit para el canal alpha. Resultado: imagen de 32.768 colores, con 1 sola posibilidad de transparencia. (Usado en MSTS).

A4 R4 G4 B4—16 bits por pixel: 4 bits para cada canal RGB, y 4 bits para el canal alpha. Resultado: imagen de 4.096 colores, con 16 posibilidades de transparencia. (Usado en MSTS).

R8 G8 B8—24 bits por pixel: 8 bits para cada canal RGB y sin canal alpha. Resultado: imagen de 16.777.216 colores, sin posibilidades de transparencia. (Comparativamente, típico .BMP).

R5 G6 B5—16 bits por pixel: 5 bits para los canales R y B, 6 bits para el canal G; sin canal alpha. Resultado: imagen de 65.536 colores, sin posibilidades de transparencia.

A2 R10 G10 B10—32 bits por pixel: 10 bits para cada canal RGB y 2 bits para el canal alpha. Resultado: imagen de 1.073.741.824 colores (mil millones...), con 4 posibilidades de transparencia. (Para postproducción y efectos, ya que se ha establecido un límite teórico de visión del ojo humano de 16.777.216 colores).

X8 R8 G8 B8—32 bits por pixel: 8 bits para cada canal RGB, 8 bits no usados (utilizables seguramente para diferentes tipos de mapas, como reflexión, relieve, normales, brillo...) y sin canal alpha. Resultado: imagen de 16.777.216 colores, sin posibilidades de transparencia, con posibilidad de canales adicionales (por ejemplo, uno de brillo con 256 posibles combinaciones, o bien uno de relieve con 256 valores diferentes). Observación: la posibilidad de añadir canales es un comentario mío, ya que el formato establece el canal X como no usado. Estoy profundizando en este aspecto.

X1 R5 G5 B5—16 bits por pixel: 5 bits para cada canal RGB, 1 bit no usado y sin canal alpha. Resultado: imagen de 32.768 colores, con una sola posibilidad de canal no usado y sin posibilidad de transparencia. (Usado en MSTS).

R3 G3 B2—8 bits por pixel: 3 bits para los canales R y G, 2 bits para el canal B; sin canal alpha. Resultado: imagen de 256 colores, sin posibilidades de transparencia.

A8 R3 G3 B2—16 bits por pixel: 3 bits para los canales R y G, 2 bits para el canal B; 8 bits para el canal alpha. Resultado: imagen de 256 colores, con 256 posibilidades de transparencia.

X4 R4 G4 B4—16 bits por pixel: 4 bits para cada canal RGB, y 4 bits no usados. Resultado: imagen de 4.096 colores, con 16 posibilidades en canal no usado y sin posibilidades de transparencia.

A16 B16 G16 R16—64 bits por pixel: 16 bits para cada canal RGB y 16 bits para el canal alpha. Resultado: imagen llamada de 64 bits, con 281.474.976.710.656 colores (más de 281 billones!!!), con 65.536 posibilidades de transparencia.(Para postproducción y efectos, ya que se ha establecido un límite teórico de visión del ojo humano de 16.777.216 colores).

DXT1—Formato comprimido con 1-bit alpha. (Usado en MSTS)
DXT2—Formato comprimido con 4-bit de alpha premultiplicado (es decir, alpha no en canal aparte sino el valor para cada canal RGB).
DXT3—Formato comprimido con 4-bit alpha, no premultiplicado.
DXT4—Formato comprimido con interpolación de alpha premultiplicado.
DXT5—Formato comprimido con interpolación de alpha no premultiplicado.

De todos estos formatos, los admitidos -en principio- por MSTS (y en formato .ACE) son los subrayados.

Josep

[Transcantabrico]

Una pregunta que no me quedo claro y yo en esto esto de texturas estoy un poco verde, aunque evolucionando.

Mas o menos el repintado de aviones del FS lo tengo pillao, ya me salen unos buenos repaints ... cosa que me está animando a ir traspasando conocimientos al TS, pero la duda que me viene quizas sea un poco teletubby:

Sé que los archivos que tenemos en uno y en otro son diferentes, pero partiendo si queremos de la misma base (TGA´s y PSD´s) pero trabajando para poder usarlas con los juegos con 2 utilidades distintas, por un lado el DXTmp para el FS exportando a .bmp con compresion DXT1 y por el otro con el TGAtools a .ace con ALPHA.

El "intringulis" que tengo es que segun leo en el TS podemos combinar las 2 herramientas para poder meterle texturas con una calidad bastante alta como pueden ser las del FS y tener unos modelos mucho más currados, aprovechando en este caso una herramienta mastodóntica de diseño como es el 3D Studio. Pero en este caso nos encontramos que en el trabajo de exportacion de 3D Studio a Gmax las cosas no cuadran, cosa que tambien puede constatar Caracolas en el mismo proceso pero desde otra herramienta (menos potente en 3d´s) como es el Autocad.

Y una cosilla a Josep, con un curso de 40 horas de 3D Studio que nivel de conocimiento del programa puedo llegar a alcanzar?. Añadir que en el PMDG lo bueno no está en el modelo, que es sobresaliente, está en la cabina , verdad

Gracias

[Josep]

Transcantabrico,

Quizá deba unificar en un post algunos datos sobre el tema texturas, para facilitar la comprensión. De hecho, este post viene de http://www.trensim.com/foro/viewtopic.php?t=3922 , y sin él quizá no se entienda.

De hecho, y resumiendo, la herramienta AceIt permite un ajuste de colores con DXT1 y con un bit de canal alpha impensable con otras herramientas que utilizábamos hasta ahora. Esto, con Max, gmax, TSM, Canvas...o el programa que sea que permita exportar los modelos a MSTS.

Gmax, TSM y Canvas tienen un módulo de exportación de los modelos a MSTS.

De hecho se importan a Gmax ficheros .3ds -generados con 3DS MAX u otros procesos con otros programas- para allí terminar de realizar los ajustes finales (con modelos provinientes de MAX, soldando vértices en zonas de límites de mapeado y texturas para suavizar aristas) y exportar el modelo a MSTS con LOD's y jerarquías alpha correctas.

Las texturas van aparte, claro. Se debe convertir el fichero .TGA o .BMP al formato .ACE, e insisto en la necesidad de abandonar el Tgatool2 de toda la vida y utilizar el AceIt.

AceIt puede importar ficheros de tipo .DDS y exportarlos a .ACE. Ahí es donde intento experimentar si la conversión de un .TGA de 32 bits -con canal alpha- pueda ser convertido en DDS e implementado en MSTS como un DXT2 o DXT3, no como un DXT1.

Este post (insisto en que creo que haré un post-resumen de lo hasta ahora trabajado en estos temas de conversión) es una continuación de la línea de trabajo relacionada con MSTS en la que me encuentro ahora.

¿Se podrá pasar a DXT2 o DTX3 (no pido más...)? Lo dudo, pero quizá en el camino podamos encontrar equilibrios interesantes. Si te apetece, lo vamos trabajando...

Por otro lado, efectivamente hay modelos que no son de pago para Flight Simulator que son excelentes, incluso comparando con modelos de pago.

Pero algunos modelos como el que menciono de PMDG, hablan de gmax como herramienta de desarrollo de calidad para modelos 3D. Si bien -como comentas- el modelo 3D del Boeing 737 es excelente, efectivamente hay modelos que no son de pago para Flight Simulator que son también excelentes.

Y ahora en Off Topic: el valor de este add-on está en el tema de los instrumentos y FMC, tienes razón. Alucinante, al menos para mí (y eso que llevo más de una década con simuladores...).

No puedo dejar de mostrar -insisto, en OFF TOPIC- algunas capturas de este modelo, así como sus pantallas.

(La pantalla donde se ve una vista frontal de los instrumentos, estoy siguiendo el SID Senia2E de salida de LEBL hacia LEMD por Senia UW96 TERSA. Uséase, utilizando la salida instrumental publicada llamada Senia2E del aeropuerto de Barcelona/El Prat con destino a Madrid/Barajas siguiendo la aerovía llamada UW96 desde la intersección Senia hasta la intersección Tersa, en espera del STAR o procedimiento de llegada a Barajas, que me asignará el controlador aéreo. Los SID's y STAR's que sigo son los publicados por AIS AENA, o sea, los reales...).

Os adjunto -OFF TOPIC- unas capturas.

Josep