The long tomorrow

¿Cómo decidimos qué nos gusta y qué no? ¿Empleamos criterios objetivos? ¿ciencia? ¿Algún tipo de proceso estadístico? Llevo quizá demasiado tiempo centrándome únicamente en los aspectos industriales de la creación de videojuegos y en la vida que se deriva de intentarlo. Sin embargo, tras la compra de cualquier producto tiene que haber un placer derivado. Entiendo que el sujeto habitual adquiere bienes precisamente por el hecho de ser buenos. En última instancia ha de derivarse un placer, un valor para el sujeto.

Imagino un sujeto, llamémoslo Alice, entra en una tienda y como le encantan las noveletas de misterio va derecha a la sección. Agún criterio tendrá que emplear para escoger un libro sobre otro. Debe priorizar. Incluso en el caso de que pueda adquirir absolutamente todas las obras escritas jamás, no podrá leerlas por falta de tiempo y, de nuevo, debe escoger qué leer y qué ojear y, por definición: qué abandonar.

Únicamente veo dos opciones si es la primera vez: escoger al azar ó pedir consejo[2]. Empleando inducción llegamos a la conclusión obvia de que el primer lector de novelas de misterio tuvo que escoger al azar[3] Pretendo llegar a un punto sencillo con todo esto: sea como fuere necesitas un criterio, o bien construir uno propio, o bien elaborarlo a base de préstamos. En este punto podría embarrancarme en el discurso contra la crítica (sobre todo la de videojuegos) pero no tengo la menor gana. Me estoy acercando a una anécdota personal que teje a partes iguales cursilería y sabiduría yedai acerca de la vida.

Como probablemente resulte obvio a estas alturas intento probar la mayor cantidad de videojuegos que puedo. Hace un par de años tuve la oportunidad de jugar Rez en Dreamcast y PS2 y me gustó mucho; es natural que me alegrase mucho al saber que Q? lanzaban una versión para 360, titulada RezHD. La bajé de inmediato. Qué desilusión. El juego era [es] idéntico a cómo lo recordaba, animaciones, gráficos, … resumiendo: el mismo. Sin embargo faltaba algo.

Rez no apareció en mi vida por casualidad: me lo recomendó un amigo. He comprobado algo interesante con las recomendaciones. Nunca es tu producto. Par mí siempre será ese-videojuego-que-me-recomendó-Enveloop. Así que arranco la versión de 360, llevo jugando un rato y me quedo algo frío. El juego es espectacular, qué coño. Está muy bien. Sin embargo no funciona.

Este detalle me dejó desconcertado. De alguna manera Rez, o mejor, algunas recomendaciones, están tan relacionadas con los recomendantes que no se entienden las unas sin los otros. Sobra decir que desde que me mudé de Compostela tengo muy complicado coincidir con Enveloop. De algún modo ambos conceptos se han asociado Rez-Enveloop. A mi me parece tierno.

Siguiendo esta línea y viendo en qué medida haber coincidido con según qué gente es producto de la más pura casualidad me asalta la duda de hasta qué punto somos señores de nuestros gustos. No me gusta el recurso fácil de decir que somos víctimas de la casualidad, … estamos sujetos a nuestras circunstancias, … blah blah blah. Quiero creer (y creo) que tenemos un cierto grado de control sobre qué vamos a hacer con nuestra vida y esto incluye también, qué decidimos que nos gusta y qué no.

Y para acabar de formar el chiste está el hecho innegable de que hay objetos, grupos musicales, juegos, libros que están unidos a personas, a situaciones a hechos.

*** Coda

La 360 es un ordenador canijo. ¿Recordáis cuando se puso de moda que los frikis-alpha tuviesen barebones? Apuesto a que sí ^_^. Creo que se puede decir que un usuario que tenga una 360 y esté jugando únicamente a Live Arcade, oyendo música y viendo algún que otro vídeo no tiene una consola de videojuegos sino directamente uno de aquellos chismes canijos y con aspecto de baulito de tesoros de niñas pequeñas[1].

–
1. Salvo por los leds azules, claro está.
2. Los resúmenes en las sobrecubiertas están sobrevalorados, amigos.
3. Bajo la premisa de que los libros de misterio existieron siempre, ¡LOL!

MEL es el lenguanje embebido de referencia en Maya (hasta la versión 8.5). A veces resulta algo imbricado pero lleva tanto tiempo entre nosotros que hay muchos recursos para aprender a usarlo entre otros:

Ejemplos prácticos de MEL

además de algunos gurús (David gould) y de sus inevitables obras de referencia, sí el famoso libro de Maya que tiene Mayas en la portada. Quite smart, ray’? Y que es absolutamente burreable, por cierto.

Circula un chiste por el entorno profesional que siempre me ha gustado mucho: “Hagas lo que hagas terminará siendo como UNIX”

Salvo que tengas el autocontrol de un Dalai-lama- ninja tus aplicaciones tenderán a crecer, abarcarán nuevos casos de uso, ampliarán sus abstracciones, crecerán y crecerán. Antes de lo que esperas alguien sugerirá que sería muy interesante emplear la web como front-end[1] y de ahí, … bueno, de ahí hay un paso a que otro comente que sería cojonudo emplear la lógica pero únicamente en modo batch, ¿para qué carajo emplear un front-end cuando sabes perfectamente qué tienes que hacer? Y, claro, puesto que no se pueden prever todos los casos, antes o después aparece un lenguaje embebido de script.

Durante bastante tiempo, un par de años quizá, el lenguaje de script por excelencia en mi pequeño rincón de internet era lua. Sin embargo los tiempos cambian, el pelo se cae y las mudanzas se sucenden y, poco a poco, la serpiente crece y se convierte en un python!

En mi curro actual me toca pelearme con Maya. Para los que no sigan muy atentamente el mundo del 3D en producción de cine he de comentar un par de cosas. Para empezar el software que se emplea es titánico y la integración con sistemas brutal. Para que nos hagamos una idea, tienen varios TBs de almacenamiento y un departamento de programación que incluye unas 10 personas[2], algunas de ellas, íntegramente dedicadas a desarrollar extensiones para el propio software. Las necesidades son tan abiertas, tan impredecibles, tan generales, que desde Autodesk (digamos Alias) se han limitado a construir un UNIX especializado en fabricar gráficos.

Como es natural en semejante tinglado no podía faltar un buen lenguaje de script: python, por supuesto. Entre otras muchas cosas, como volver a tratar con compañeros, formar parte de un proyecto más ambicioso y tener alguna posibilidad de éxito, este trabajo me está permitiendo volver hacia python y a desarrollos algo más pequeños.

Por cierto, todavía no he salido por Salamanca, salvo para un par de cañas de media semana. Nada de pinchos. Nada de jamón. Sólo un poco de frío, algo de lluvia y bastantes ladrillos. Dejadme decir que la ciudad tiene un cierto aire a la Zaragoza de los años 70, no sé si sabéis a qué me refiero. Un cierto aire a Camino de las Torres. Por otro lado el piso que hemos encontrado va estando cada vez más habitable, lo que siempre es agradable al terminar una de esas jornadas maratonianas de “tresdeseros”.

–
1. Lo que probablemente es una buena idea. Y es también una buena idea largarse de esa empresa en justo ese momento
2. Y no estoy contando sistemas, por una vez los sistemas los lleva otro: ¡YEAH!

Me han pasado muchas cosas durante estas últimas semanas que merecen comentario. Quizá las tres más importantes son:

1. Termino mi trabajo en Vigo. No más programación para móviles por el momento. Ha sido un curioso reencuentro con Java y sus delicias, pero ya tengo bastante por ahora.

2. Abandonamos Galicia. También dejamos Santiago. Aquellos que tuvieron la oportunidad de ir y no acudieron ya no van a tener más oportunidades: sí eso va por tí.

3. Cambio de gremio. Tangencialmente. Abandono el terreno de los videojuegos para trabajar directamente en producción 3D en películas. A ver cómo funciona todo esto.

Galicia, y Santiago en particular, es un sitio fantástico. Teniendo en cuenta que Zaragoza está rodeada por los Monegros y más allá hay unas buenas montañas, el paisaje gallego de colinas suaves y vegetación inevitable resulta más que agradable. Unido a unas condiciones de vida y una gastronomía benignas es un sitio fantástico donde pasar una buena temporada.

Os dejo una foto de Ponte Maceira, incluso Google ha encontrado que tiene cierto encanto ^_^

Y relacionado con el cambio de gremio incorporo también una fantástica mudanza. Estamos buscando casa frenéticamente en Salamanca (lo que garantiza nuevas aventuras abracadabrantes a cargo de caseros e inmobiliarias)

Como en cualquier cambio de curro, los primeros contactos con la empresa receptora son motivo de chanceo vario. De entre las muchas cosas que nos llevamos en nuestro contacto inicial os dejo una fotito de las cubiertas y tejados de la catedral de Salamanca. Otro lugar bonito al que acudir si se tiene posiblidad.

Tan pronto como se estabilice un poco mi ir y venir de casa en casa y anuncio en anuncio (y Telefónica o quién demonios sea me dé internet) volveré a los artículos técnicos etc.

Baste decir que he estado probando un poco el trabajo de Pixologic, ZBrush 3.1. Y que me ha dejado más que sorprendido. Resulta impresionante verlo en marcha y recomiendo cualquiera de estos vídeos para convencerse de la potencia tremenda de la herramienta.

PD: Durante la primera semana de Diciembre nos dimos una pequeña escapadita hacia Alemania, podéis ver las fotos en el flickr de eldiablesodelacarretera.

¿Qué demonios es un halo? No lo sé, ¿a quién leches le importa? Tampoco lo tengo claro. Sin embargo ha llegado, por un azahar del destino, por un rebote, por una casualidad digna de un poeta prerromano, una copia de la caja de coleccionista del juego. No os voy a hablar de sus cualidades como zuuter en primera persona, que las tiene, ni de sus pequeños detalles, voy a dejar que de eso se encargue Yahtzee con su video-review-destructiva-de-Halo3.

Y ahora al tajo: forge, vídeo, y otros delirios. El jueguito tiene un feature, menor. Las partidas que echas quedan grabadas en vídeo automáticamente. No. No es exacto. El engine vuelca todas las acciones que está llevando a cabo y las deposita en un ficherito. Una sesión de diez minutos de juego cabe en aproximadamente mega y medio[1]. Y, aprovechando esta independencia del video te permiten sacar el punto de vista del jefe maestro y pasearte por el escenario. Puedes, efectivamente, ponerte en la piel de los desdichados grunts que masacras a cada paso que das en el Hálito-3. Y aquí voy acercándome al tema.

Obviamente si el jefe maestro fuese Chuck Norris nada de esto habría pasado. Los Spartans son algo nenazas al fin y al cabo.

Una vez sacas el punto de vista del personaje principal te das cuenta muy rápidamente de cómo funcionan las tripas del juego. Hagamos una prueba: uno de los objetos es un arma posicional que provoca ceguera si estás muy cerca. Convenientemente lo llaman bengala[2]. Bien, dispara la bengala cerca de una pared o mejor aún, tírala a la maldita pared. Una vez la tienes ahí, flanqueas la pared y te acercas por el otro lado. Sigues igual de deslumbrado pero estás mirando una pared y no una bengala. Descarto la posibilidad de que los chicos de Bungie no sepan física. Saben y mucha. Pero estas cosas son muy difíciles de programar en tiempo real sin que el juego se vaya, directamente al carajo.

La posibilidad de grabar las partidas, y, aún mejor, de editar niveles a tu gusto, exponen el juego. Los escudos esféricos hexagonales, uno de los detalles más bonitos del juego son un truquito de render muy efectivo. Para verlo en detalle, desde cualquier ángulo, creas un nivel, metes uno de esos escudos, metes al jefe maestro en él y luego, deteniendo el tiempo y con la cámara libre te deleitas en cada artefacto, cada efecto de raytracing fingido, cada pequeño trampantojo.

Aprovechando la cámara libre se pueden observar muchos trucos clásicos del género: dispárale a una pared y acerca la cámara, verás el cambio del nivel de detalle y el material filtrado de los boquetes que las armas dejan sobre las superficies. Aléjala un poco y el cambio es claro. Espera unos segundos y la superficie se regenerará poco a poco cuando el boquete sea reclamado por el pool-de-boquetes. Cuando estás fuera del jefe maestro puedes ver el efecto tan extraño que hace la armadura al recibir daño, una suerte de nube de rayos amarillentos, algo pobres.

Con el modo de edición de niveles, ver la intención del diseñador es razonablemente sencillo y muy instructivo si se examina con cuidado.

Quizá y, para terminar, exista otra gran herramienta de diseño / MOD: Valve’s hammer. Desde donde pueden accederse a las animaciones, los scripts, y el porrón de herramientas que Valve distribuye con cada copia de su serie Half-Life2. Siempre llama la atención que una gran compañía dedique esfuerzo y dinero a producir herramientas para fuera de casa. Sin embargo, con los años, se ha formado un fuerte y saludable grupito de Modders y creadores de escenarios.

Bungie ha dado un impulso a los editores en el mundo de las consolas. El trabajo con las capturas en vídeo es sencillamente excepcional. Tanto para examinar en detalle cómo rendean, cómo sombrean, cómo iluminan, como para buscar las diferencias en los niveles de juegos de consola y de PC, Forge, es una excelente herramienta.

PD: aprovecho el cierre para comentar por aquí que Epic ha publicado la versión de Gears para PC-de-gama-ridículamente-alta.

–
1. Esto tiene varias implicaciones, para empezar tendrás que grabar tus partidas en un DVD-grabador, o un HD - grabador, o un VHS (no sé si alguno de vosotros tiene uno ya) para que otra persona sin una copia del Halo3 vea tus partiditas ¡Los chicos de Bungie son listos!
2. He visto traducir grunt por gruñidos. Que nadie se sorprenda cuando en mitad del juego alguien le grita al jefe maestro: ¡buena baja, jefe! ¿pero de qué hablan? ¿Cómo han descubierto que llevo fingiendo dolor de espalda desde hace medio año!?

Existe la tendencia entre los programadores que se dedican a los videojuegos, de considerarse poco menos que top-guns del desarrollo. Tiene bastante gracia ya que visto en la distancia, la tecnología en desarrollo de juegos no avanza tanto. No negaré que es un trabajo muy especializado y sí tiene una componente importante de presión y fechas de entrega draconianas. Claro que cualquiera que haya empezado en una consultoría desde los puestos de programador nos da sopas con honda a cualquiera que se dedique a esto de los jueguitos.

Dicho en plan titular, vista por separado, la gestión de los datos del World of Warcraft es mucho más impresionante que su render, incluso que la carga (sin tiempos de carga) del mapa, según se avanza por él. Según me han ido contando Blizzard se sostiene encima de unos soberbios montajes de Oracle, no quiero ni imaginarme lo que costarán los seguros al año, ni lo que cobrarán esos aburridos programadores de bases de datos, que resulta que están haciendo el juego.

Una vez he lanzado este canto a la igualdad y la concordia entre las distintas familias de programadores, dejad que os diga en qué se distingue un programador de videojuegos de un desarrollador de aplicaciones serias. En los detalles. En los malditos y minúsculos detalles. En que cuando alguien pulse ahí se oiga click y el menú se desplace con una hermosa fluidez. En que los reflejos del jefe maestro sobre el agua sean físicamente correctos. En que la velocidad que el joystick transmite al personaje siga una curva de Hermite. Y lo que es aún peor: el programador de videojuegos fogueado se distingue del verde precisamente en la cantidad de detalles que puede anticipar a la producción y con los que prepara su código.

Qué semana más rarita ha salido en esta parte del mundo mundial. Sólo un par de detalles para poner en situación al incauto lector:

Portal

Esta semana me he lanzao a la piscina y he comprado The Orange Box. Tened cuidad si os da la ventolera de ir a un centro-mail, mail-center, mail-foobar o como leches se llame ahora el garito. Un dependiente normal de esas cadenas no va a saber qué venderos si pedís “la caja naranja”, no sabe si hay que pagar o no para jugar en Steam (no, no hay que pagar), … en fin, no conoce el género que tiene y probablemente le importe un huevo.

Mi primer contacto con Portal fue a través de Yahtzee Croshaw, en su columna de video-crítica-animada semanal en The Escapist Magazine: conocida por el simpático nombre de Zero Punctuation [1] Como cabe imaginar a tenor del nombre, el tipo no se anda por las ramas: masacra cada juego que pilla. Llevo unos meses bastante mosqueado con la critica de videojuego en general y probablemente será carne de artículo más pronto que tarde. Hay que ver sus videos siempre hasta el final y no perderse la delirante sección de disculpas que tiene al final, donde pueden encontrarse maravillas como perdi mi corazón por un soldado del espacio.

No creo que tenga que decir que Portal es fabuloso. O quizá sí: Portal es fabuloso. ¡Larga vida al companion cube!

Bluetooth

Y ahora hablemos un poco de trabajo ^_^. A causa de un problemilla con el servidor de cauterized.net [2] No he podido destilar mis penurias profesionales por este canal. Lamentablemente para todos, ahora vuelve a ser posible darlos la lata con todo esto ¡yipes! La versión ultra-resumida de todo esto es que me ha tocado montar un prototipo capaz de comunicar un teléfono móvil con un PC a través de bluetooth y luego, enganchar el PC a internet. De algún modo la idea es darle a un usuario la capacidad de conectar servicios web a su teléfono a través del PC.

Por supuesto, todo el tinglado tiene que funcionar desde el terminal más churrero de Nokia (ie: Series 40) hasta en sus zapatófonos más rutilantes. Mejor no hablar de otras compañías porque los Motorolas que yo conozco dan por saco desde que los enciendes hasta que los tiras a una pecera llena de calimocho, sólo para desembalar tu viejo y querido 8310; podría mencionar los Sony-Ericsson, unas peacho-máquinas que me han sorprendido mucho.

Y debéis entender que no estoy hablando como usuario, no me quejo del color de los botones, ni de los efectos de sonido, ni de las malditas animaciones de transición entre elementos del menú: dejemos que eso lo hagan los lUsers. No. Únicamente hablo de la maldita programación en Java, sí ya sabéis:
write once debug everywhere! El mismo instalable no funciona igual en dos dispositivos. Y no estoy hablando de nada en particular. Un condenado juego 2D basado en sprites totalmente estandar en su programación Java NO FUNCIONA en un Motorola. Peta. Pasa. Se despelota en tu jeta. Y eso, jode. Por supuesto si la implementación de java en lo tocante a pixel-blitting difiere mejor ni imaginar qué pasará en zonas más dependientes aún del hardware (pongamos la cámara[3]) ó el Bluetooth[4]

Pero no todo son quejas por los teléfonos móviles, no ¡También tengo para los PC! De entrada a nadie en mi oficina se le ocurrió la maravillosa idea de desarrollar todo este tinglado en Linux. Eso redujo en algo mis penurias. Sin embargo no he dejado de sorprenderme por lo complicado que es trabajar con Bluetooth sobre un PC. Aunque no pude dedicarle demasiado tiempo, no he encontrado un modo de acceder desde ningún lenguaje a capa alguna de bluetooth. C++ ó C# ni siquiera por VB.

Así que tuve que buscar una vueltilla al asunto, para empezar, tenía que crear un servicio bluetooth al que el teléfono pudiese conectarse. Eso es posible hacerlo empleando un puerto serie de tipo servidor en el PC. Incluso en este punto hay dificultades ya que el driver que viene de serie con XP-SP2 es particular, digamos es especial. En la oficina tuvimos que reinstalar el bluetooth unas 15 veces hasta dar con los drivers de Belkin, probablemente heredados de un Win-2K o cualquier cosa de ese estilo. Mucho más completos y con un comportamiento mejor.

El puerto serie creado espera dos conexiones: por un lado se conecta la aplicacion en PC y por el otro el teléfono. Puesto que todo el resto del código lo tengo desarrollado en Java no me pareció una buena idea emplear otro lenguaje de programación y seguí por el mismo camino. Sin embargo Java y los puertos serie tienen una relación delicada, con un poco de suerte encontré RXTX. Biblioteca que empleo para conectar a puertos serie con bastante buen resultado.

Después vienen toda una catarata de pegas e inconvenientes. Los dispositivos deben estar emparejados y el puerto serie creado en el PC es un servicio. Lo que implica que puede desactivarse, anularse, borrarse, etc. Por si esto fuera poco además no depende de la aplicación que debe buscar cada vez los números de puerto. Una vez está en marcha es bonito ver la conexión. No me imagino a un usuario dando todos los minúsculos y minuciosos pasos que hay que dar para llegar a conectar ambos dispositivos.

Al final todo el montaje se apoya en un protocolo muy sencillo por paquetes de tamaño fijo. Donde cada paquete va armado con un checksum y varios números de serie. Esta capa de comunicaciones es la misma que empleo durante las etapas multiplayer del juego. Así que hurra por el desacoplamiento. Es, en realidad, la segunda vez que tengo que programar una pila completa de comunicaciones. Siempre es bonito y muchas veces complicado. Se trata de una aplicación naturalmente paralela. Aún es más: tiene que ser paralela o los bloqueos de esperas la pondrán de rodillas.

En lo tocante a multi-thread los teléfonos se comportan razonablemente bien siempre que uno no se dedique a crear y destruir constantemente hilos. Probablemente ese es el gran problema del sonido, necesitan un hilo propio y la implementación natural de “crear bajo demanda” resulta cara en memoria, en fragmentación y es terriblemente lenta.

En fin, espero que las webs de los proyectos estén arriba pronto para poder engancharlas desde estas páginas y que podais reiros conmigo de todo el montaje. Buena semana.

–
1. Os dejo el link a su videocrítica de The Orange Box. Tiene ya bastantes y todas merecen la pena. Yo tengo que verlas tres o cuatro veces para terminar de entender qué dice en muchas ocasiones. Merece la pena, porque es de los pocos críticos que conoce que no se toma demasiado en serio el negocio ^_^
2. Gracias por repararlo, os echábamos de menos
3. Algunos teléfonos tienen cámara pero no es controlable por Java, especialmente en los Serie 40, otros fingen que tienes control y luego no te devuelven imagen alguna, los foros de los fabricantes están llenos de amargas críticas al respecto.
4. Rechinar de dientes cada vez que pronuncio esa palabreja.

Esta semana no ha sido la mejor, por así decirlo, ni en mi curro (a pesar de avances importantes en recortar los consumos de memoria, tanto globalmente como dinámicamente) ni en desarrollos en casa. Sin embargo una nueva utilidad ha aparecido en mi radar: la extensión Subversion para el visual studio: ankhsvn. La estoy probando un poco y ha funcionado bien. No creo que llegue al nivelazo de la integración con sourcesafe, pero para entornos híbridos o con sistemas basados en unix puede ser útil.

Un pequeño resumen de la semana incluye:

1. Hemos probado el modo multiplayer de Guitar Hero 2 y terminar convencido de que no está mal, aunque el diseño de niveles no está pensado para jugar dos personas.

2. Mi DS ha vuelto a la vida y he probado el Metroid Fusion. Me ha llamado mucho la atención, junto al Castlevania: harmony of dissonance. Si alguno dispone de una DS ó una GBA hará bien en conseguir las dos joyas y jugarlas a fondo.

3. Como técnico de fin de semana sigo poco a poco volviendo a C++ y, para continuar con mi batalla por los formatos, he empezado a trabajar en la carga de ficheros .X manualmente. Las funciones de ayuda incluidas con las DX-utils facilitan mucho la vida a la hora de cargar mallas y “cosas normales”, pero qué pasa si por ejemplo quieres cargar una ruta, un mogollón de vectores, o cualquier otro elemento que no sea necesariamente rendeable: pues que tienes una situación en ciernes XD

He incorporado a la barra lateral, en la sección DirectX algunos enlaces a toymaker que he encontrado muy útiles para empezar a entender qué leches estaba haciendo cuando cargaba un fichero .X
También me ha resultado muy útil el foro de gamedev.

Algunas cosas a tener en cuenta son:
1. Es necesario precargar los templates sobre la estructura básica del fichero.
2. Al ser un desarrollo clásico de Microsoft, no todos los recursos son fáciles de alcanzar ni mucho menos,

#include "rmxftmpl.h" // Incorpora los templates precompilados
#include "rmxfguid.h" // Constantes de identificación de frame


El código de trabajo con ficheros de tipo X sera necesariamente muy recursivo y empezará con algo como:

LPD3DXFILE p_file = NULL;
D3DXFileCreate(&p_file);
p_file->RegisterTemplates(
D3DRM_XTEMPLATES,
D3DRM_XTEMPLATE_BYTES);
LPD3DXFILEENUMOBJECT p_xFileObject = NULL;
p_file->CreateEnumObject(
"Media\\file.x",
D3DXF_FILELOAD_FROMFILE,
&p_xFileObject);

Cualquier búsqueda en gamedev con alguna de las funciones que aparecen en los snippets anteriores os llevarán directos a ayudas y consultas completas.

Antes de entrar a currar a mi actual compañía y que la vorágine de cambiar de tecnología (DX/C++ –> MIDP/J2ME) me sorbiese hasta el tuétano había pillado la sana costumbre de regurgitar mis inmodestas opiniones por este canal. He visto algo que me ha llamado muchísimo la atención y tengo ganas de dejarlo por escrito y no olvidarme.

El ejemplo en cuestión se llama ContentStreaming. Como hace más tiempo de la cuenta que no machaco mi C++ estoy intentando digerirlo aún. Lo que sí os puedo anticipar es qué puntos trata:

1. Cacheado de recursos
2. Mapeado de ficheros en memoria en Windows
3. Carga anticipada
4. Multi-threading

Esencialmente este ejemplo te pone en la pista de las técnicas básicas para los modernos engines sin tiempos de carga. Parte de un fichero que genera proceduralmente de 3.3GBs y luego irá cargando según vaya necesitando rendear zonas del mundo en cuestión.
Mi intención es estudiar el ejemplo e ir posteando por este canal los resultados de la autopsia. Ya veremos cómo sale la cosa, o si se tuerce interferido por otras prioridades.

De vuelta al trabajo de fin de semana: sigo a castañas con problemas de formatos y conversiones entre ellos. Pero esta vez he decidido lurkear entre los foros de XNA sobre MOD y he llegado a algunas desoladoras aunque esperables conclusiones:

El soporte que da Softimage a través de MOD y XSI a DirectX es poco menos que un chiste[1]. Como ya venía diciendo en posts anteriores la exportación geométrica funciona bien, y la salida de coordenadas UV es directamente de chiste. No quiero ni imaginarme lo que ha de ser tratar de sacar animaciones del paquete. Dejaremos las animaciones para más adelante (que será otra odisea criminal)

Sin embargo, sí hay una solución y como siempre, desde el lado más gamberro del 3D: ¡blender! Blender dispone de un exportador out-of-the-box que funciona correctamente al generar .X

Efectivamente el procedimiento incluye pasar por .OBJ para llegar hasta el objetivo, quedando algo así:

1. Se genera todo el contenido sobre XSI + GIMP + nVidia texture tools + …
2. Se exporta a .obj
3. Se abre el .obj con Blender
4. Se exporta a .X

Este procedimiento es algo rústico, ya lo sé. Pero abre la puerta a generar contenido para .X sin necesidad de machacar ninguna versión de MAX; MOD es gratuíto y Blender es libre, y, si realmente te apetece se puede obtener todo el material desde Blender sin necesidad de pasar por la herramientita de XSI, lo que posiblemente sea la mejor opción al estar MOD severamente modificado y resulta en el ahorro de un cambio de formato con todas las pegas que esto tiene.

–
1. No he probado la versión 6.5 pero que no me vengan con hostias: las limitaciones al exportado eran severísimas: un sólo canal de textura por punto (clúster, para ser exactos), que luego había que escalar en las 2 coordenadas por -1.