sábado, 27 de junio de 2015

El Pip-Boy del Fallout 4 (Parte II: Puesta en marcha)

Qué encontrarás en esta entrada?
  • Impresión 3D de un pip-boy del Fallout 4.
  • Pintura y otros retoques finales.

No es la primera vez que en Astaroth's World nos dedicamos a crear nuestro propio merchandising del Fallout, una excepcional saga de videojuegos cuya calidad bien merece toda nuestra atención.

Aunque el Fallout 3 fue el que nos cautivó a gran parte de nosotros, ahora viene pisando con fuerza el Fallout 4, anunciado para el próximo 10 de noviembre de 2015. En este contexto nos pusimos a replicar el Pip-Boy que aparecerá en esta nueva entrega sin más que unas pocas imágenes mostradas en el pasado E3.

Imágenes del nuevo Fallout 4 (en el E3 del 2015) en el que podemos ver la nueva versión del Pip-Boy

Como ya vimos en la última entrada, "El Pip-Boy del Fallout 4 (Parte I: Diseño)", conseguimos hacer una réplica 3D en Blender y la dejamos a punto para imprimir.

Modelo 3D realizado por mi mediante Blender de la versión del "Pip-boy" que aparecerá en el Fallout 4

El pasado miércoles, durante todo el día y acabando por la noche, estuvo imprimiéndose nuestro modelo, como pudimos ver en directo en YouTube.

Impresión de la pieza: se pueden ver defectos importantes en la uniformidad de las capas y la suavidad de las superficies

La impresión estuvo programada para durar 15 horas y 20 minutos, pero terminó demorándose hasta las 18 horas (de 6:00 de la mañana hasta las 00:00 de la noche). Esto ocurrió así incluso pese a los intentos de recortar calidad en pro de una más rápida impresión (las primeras estimaciones daban entre 25 y 35 horas de impresión). A la luz de los resultados, veo poco conveniente recortar en calidad, lo que en realidad plantea un problema en relación a los extremadamente largos periodos de impresión ininterrumpibles. Más adelante parece inevitable hacer un estudio más en profundidad sobre la compleja tarea del laminado (descomponer la figura 3D en capas para que imprima la impresora), una labor que programas como slic3r realizan estupendamente, pero que en su minuciosa configuración se esconde el secreto de que la figura final tenga la calidad deseada o sea un amasijo de plástico derretido.

Dado los defectos de impresión con los que salió la figura, me decidí a rellenar hueco y uniformizar con cola blanca, lo cual solucionó de manera aceptable gran parte de los problemas más gordos que presentaba mi recientemente impreso modelo. Tras un pequeño lijado/limado, pudimos pasar a la siguiente fase: la pintura.

Primera capa de pintura

Como os he contado con otras figuras que hemos impreso en Astaroth's World, podemos pintar el PLA tras salir de nuestra impresora con pinturas para maquetas y figurillas, como las pinturas para modelismo de la marca Vallejo, por ejemplo.
 
Como se puede deducir de las fotos de esta entrada, no me considero ningún experto en pintura (ni en artes plásticas en general). Lo básico es dar una capa de imprimación para que la pintura agarre, luego pintar con las distintas técnicas que, claramente, yo no domino, y por último darle un barniz. Por suerte para nosotros, venden pinturas metálicas que, a diferencia de los colores planos, aun no sabiendo pintar dan a nuestra figura un aspecto más realista, con cierta textura.

Tras una tarde de pintura, éste fue el resultado:
 



 
Nuestro Pip-Boy del Fallout 4 listo para acompañarnos en nuestra próxima aventura.

domingo, 21 de junio de 2015

El Pip-Boy del Fallout 4 (Parte I: Diseño)

Qué encontrarás en esta entrada?
  • Fallout 4: Modelado y preparación para la impresión 3D de un Pip-Boy.

Uno de los anuncios más sonados del E3 de este año (una de las convenciones de videojuegos más importantes del mundo) ha sido el de la esperada cuarta entrega del la saga del Fallout.

La salida al mercado del Fallout 4 es ya una realidad (con fecha del próximo 10 de noviembre de 2015). El anuncio fue acompañado de una edición coleccionista llamada "Fallout 4 Pip-Boy Edition" que incluía una réplica funcional del conocido gadget "Pip-Boy" (un miniordenador que lleva el protagonista del juego en el brazo izquierdo).

Presentación en el E3 de la réplica oficial del Pip-Boy del Fallout 4, que se incluía en la versión coleccionista

Éste es todo un símbolo del juego que todo el mundo quiere tener, y es el causante de que la edición coleccionista se haya agotado por completo nada más salir.

Pero no hay problema, porque si algo nos ha enseñado vivir en El Yermo, es que hay que utilizar los recursos que nos rodean para sobrevivir como sea, así que si necesitamos un Pip-Boy para empezar a matar mutarachas, nos ponemos a modelarlo en 3D con Blender y nos lo imprimimos con una Prusa i3 Hephestos.

Tras una mañana de modelado básico, y aunque pueda tener bastantes fallos, obtengo una versión para mi "aceptable" de la versión del Pip-Boy que aparecerá en el ansiado juego a partir de este noviembre.

Modelo 3D realizado por mi mediante Blender de la versión del "Pip-boy" que aparecerá en el Fallout 4

Después el modelado básico, hay que hacer algunas adaptaciones para la impresión. Sin embargo, en este caso hemos tenido suerte, y los procesos automáticos de corrección nos salvan dejando una versión que podemos pasar directamente a nuestra impresora sin haber realizados demasiados cambios adicionales.

Interpretación del GCODE (algoritmo para la impresión 3D) basado en mi modelo 3D por el programa repsnapper

La primera decepción viene en el tiempo de impresión. Según la configuración inicial, y el tamaño al que decido imprimirlo (un poco más grande que la réplica oficial, puesto que considero que ésta es menor que la del juego), las primeras estimaciones dan entre 25 y 35 horas de impresión.

Decido arriesgarme a imprimir una versión de 22 horas (probablemente acabarían siendo más), pero me topo entonces con otro problema, fácil de prever, pero por mi ignorado: no había suficiente PLA en la bobina (material con el que imprimo). Esto hace que tenga que parar la impresión y retrasarla una semana cuando a penas había impreso la base.

Primera prueba de impresión: se acaba el material al 30% y se ven algunos errores que he de solventar

Sin embargo, no es una pérdida total de tiempo, ya que verifico que el tamaño es el que deseaba y veo ciertos errores de impresión que puedo ir solventando en la semana que tengo que esperar a que me traigan el material para volver a empezar.

Respecto al tamaño, nótese que la réplica oficial cubre sólo la muñeca, siendo como un reloj bastante grande. Sin embargo, mi versión (y la del juego) parecen ser más grandes, cubriendo casi en su totalidad el antebrazo. Creo que éste es más bien el tamaño correcto.

Realizo algunas correcciones en el diseño inicial y en la configuración de la impresión, obteniendo una versión con tiempos de impresión algo más razonables (15 horas). En el siguiente vídeo podéis ver la simulación de cómo debería ser la impresión que intentaré llevar a cabo a finales de la semana que viene.


Con todo ello, y a la espera de recibir el PLA con el que poder continuar, doy por finalizada la parte de "diseño" propiamente dicha (aunque es posible que aún haya que hacer algunos ajustes finales no programados), y os dejo a la espera de una próxima entrada donde espero poder mostraros, si no surgen más contratiempos, la impresión correcta de nuestro nuevo juguete postapocalíptico.

Hasta entonces, por favor, recordad que la guerra no cambia nunca.

domingo, 31 de mayo de 2015

Cartografía desde el móvil con OruxMaps y MOBAC

Qué encontrarás en esta entrada?
  • Presentación de MOBAC.
  • Conexión con OruxMaps

En este blog ya hemos hablado alguna vez de cartografía y, en concreto, de su integración con dispositivos móviles. A este respecto puedo decir que, a día de hoy, la alternativa que más me convence con mucha diferencia es OruxMaps, una aplicación gratuita y española con unas características y funcionamiento realmente excepcionales.

Recientemente me topé con un pequeño problema. Su resolución, y las tecnologías con las que me he encontrado por el camino, creo que son lo suficientemente interesantes como para llenar las líneas que estamos escribiendo en este espacio.

Aclarar, en cualquier caso, que el público al que va dirigida esta entrada es al usuario medio de este tipo de tecnologías. Daremos algunas cosas por sabidas, y al mismo tiempo es obvio que al usuario experimentado todo lo que vamos a contar le parecerá una trivialidad. Espero, eso sí, que pueda ser de utilidad al usuario medio que estuviese en una situación similar a la que yo estaba hace un par de días.

Uno de los grandes puntos en los que sobresale OruxMaps es su gestión de mapas. Aún recuerdo, en una etapa temprana del desarrollo de las tecnologías de tracking (que el GPS registrase la ruta que estás siguiendo), cómo las aplicaciones más punteras ofrecían la posibilidad de registrar la ruta sobre una superficie de color plano, de tal manera que no había más referencias que la del propio camino que estabas tomando. Se ofrecía entonces, como ventaja de pago, la posibilidad de añadir un sencillo mapa de base.

Hoy en día OruxMaps proporciona infinidad de mapas online, con la posibilidad de descargarlos para su uso offline y la de añadir nuevos mapas sabiendo los servidores en los que están alojados.

El uso de mapas offline es básico. En plena ruta, es muy posible perder la señal de datos para descargarlos de manera online, y en cualquier caso es un gasto de energía y megas fácilmente evitable. Para ello es muy conveniente descargarse el mapa en casa, con una conexión WiFi.

OruxMaps da la posibilidad de descargarse una parte de un mapa online que estés visualizando en ese momento, para que luego puedas usarlo cuando quieras sin conexión. Esta herramienta es muy útil, y no he tenido problemas con ella hasta ahora, que he querido ampliar mi rango de acción y me he topado con una limitación: sólo se permite la descarga de un bloque que como máximo ocupe 500MB.

Mapa IGN Ráster - Alcalá de Henares (ejemplo de mapa por imágenes no vectoriales)

Mapa OSM MapQuest - Alcalá de Henares (ejemplo de mapa vectorial)

Los mapas ocupan de manera diferente según cómo estén construidos: hay mapas vectoriales, que ocupan muy poco puesto que guardan sólo información vectorial, y al reescalarse se redibujan atendiendo a los vectores que los definen, pero también hay mapas escaneados, que lo que hacen es mostrarte a cada nivel de zoom una imagen, por ejemplo, en TIFF. Los últimos suelen ser mucho más detallados, pero a cambio, ocupan bastante más. Si queremos descargarnos la Comunidad de Madrid de un mapa como el IGN Ráster, vamos a necesitar bastante más de 500 MB.

¿Cuál es la solución? Sin salir de OruxMaps la única solución (según he visto, quizás esté equivocado) es descargarse múltiples retículas de 500MB como máximo. Esto es un poco lioso, puesto que cada retícula tarda un tiempo considerable en descargarse, y si algún día queremos actualizar todo el mapa, deberemos volver a descargar todas las retículas una por una, definiéndolas a mano, con el respectivo solapamiento entre retículas que produciría que el mapa final acabase pesando más. Es un proceso lento, costoso y poco eficiente. Una vez descargado, OruxMaps carga (ya sea de forma manual, o automáticamente, según la configuración) cada trozo de mapa cuando corresponda. Esto tampoco es elegante: estar haciendo una ruta y tenerla partida en varios trozos de mapa.

Mi pregunta era: ¿existe alguna forma de utilizar en OruxMaps mapas offline "grandes" (de más de 500MB)? La respuesta es .

Para ello nos basaremos en una aplicación externa bastante popular: MOBile Atlas Creator (o MOBAC).


Este software multiplataforma (vale para Windows, Linux, OSX...) permite, entre otras cosas, visualizar mapas de distintas fuentes, descargarlos y convertirlos en un formato compatible para una gran variedad de programas, entre los que se encuentra OruxMaps.


Aunque también cuenta con sus limitaciones en el tamaño de los mapas, y con respecto al solape de capas del mismo nivel, éstas están bastante por encima de los 500MB máximos que permite OruxMaps.
 
Como vemos en la imagen  de un poco más arriba, una vez elegido el mapa que queramos utilizar, se selecciona con el ratón la parte del mismo que queramos (esto ya es un avance, porque con el ratón tenemos bastante más precisión que la que tendríamos con el dedo desde OruxMaps, y si queremos rectificar la selección es también más fácil desde el ordenador que desde un móvil o tablet), seleccionamos los niveles de zoom y le damos a "Add selection" para incluir las capas en nuestro atlas. Como podéis ver, he seleccionado gran parte del Este de la Comunidad de Madrid. Seleccionando las capas de zoom desde la 17 a la 0 (ambas incluidas), tenemos un mapa de 1GB (el doble del máximo permitido por OruxMaps).


Al darle a "Create Atlas" empieza la descarga y la conversión al formato que le hayamos indicado. Una vez finalizado, y habiendo elegido el formato "OruxMaps Sqlite", obtenemos dos archivos en la siguiente ruta:
 
<directorio_raíz_del_MOBAC>/atlases/<nombre_del_mapa>/
 
Uno es un ".xml" de unos pocos kBs y el otro es un ".db" que ocupa más. La carpeta con el nombre que le hayamos puesto al mapa, que contiene los dos archivos, ha de copiarse tal cual al móvil, dentro de la ruta:
 
<directorio_oruxmaps>/mapfiles/

De tal manera que tengamos, por ejemplo:

oruxmaps/mapfiles/Madrid Este Raste IGN/

que contega:

  • Madrid Este Raste IGN.otrk2.xml (14,46 KB).
  • OruxMapsImages.db (977,26 MB)


El traspaso de este archivo fue un tema que también se me complicó un poco. Generalmente, paso archivos del ordenador al móvil por red local mediante WiFi vía SFTP (SSH File Transfer Protocol). Esto funciona muy bien y es lo más cómodo para archivos de unos cuantos megas, pero parece que no va tan bien para archivos de gran tamaño.
 
La mejor alternativa parece ser el cable USB, pero por lo visto las últimas versiones de Android utilizan el protocolo MTP (Multimedia Transfer Protocol), que es parte del PTP (Picture Transfer Protocol) desarrollado por Microsoft, y que dependiendo de la versión del sistema operativo que tengas, puede dar problemas en Linux. De hecho, después de leer varios foros al respecto, no conseguí hacer funcionar el MTP en Ubuntu 14.04 con mi Nexus 5.
 
La solución en este caso fue una tontería: cuando elegimos el protocolo PTP (seleccionable desde el móvil cuando está enchufado al equipo), se nos abren las carpetas de imágenes (puesto que este protocolo está diseñado para transferir fotos). Sin embargo, nada nos impide copiar un archivo del formato que sea a la carpeta de imágenes, y luego moverlo con un explorador de archivos desde el móvil (Solid Explorer es mi favorito).

Por WiFi pasar el archivo de mapas de alrededor de 1GB tardó más de 3 horas en pasarse al 50%, con el consecuente calentamiento y gasto de batería del móvil. Mediante USB 3.0, utilizando el protocolo PTP, unos pocos segundos.
 

 
Una vez copiados los archivos, abrimos OruxMaps y comprobamos que el mapa se lee a la perfección.

Algo interesante es que con MOBAC podemos añadir varias fuentes de mapas además de las que ya vienen. Una forma de hacerlo es con un mapa WMS (Web Map Service). Para ello, en la carpeta:
 
<directorio_raíz_del_MOBAC>/mapsources/

Debemos añadir un archivo ".xml" que contenga lo siguiente:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<customWmsMapSource>
<name>NOMBRE</name>
<minZoom>0</minZoom>
<maxZoom>20</maxZoom>
<tileType>png</tileType>
<version>1.1.1</version>
<url>http://url_del_wms?</url>
<coordinatesystem>EPSG:4326</coordinatesystem>
</customWmsMapSource>

He de decir que no se me da demasiado bien rellenar estos archivos, y aunque parece simple, me ha costado hacerlos funcionar (y en ocasiones me ha resultado imposible detectar dónde podría estar el error). En principio habría que cambiar el nombre, seleccionar la escala mínima y máxima, poner el formato de la imagen y la ruta del servidor. En ocasiones es necesario añadir la capa, mediante la etiqueta <layers>. Aquí podréis encontrar más información al respecto.

Un ejemplo que parece que he conseguido hacer funcionar es el mapa de riqueza de especies de Magrama:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<customWmsMapSource>
<name>Riqueza Especies</name>
<minZoom>0</minZoom>
<maxZoom>20</maxZoom>
<tileType>png</tileType>
<version>1.1.1</version>
<url>http://wms.magrama.es/sig/Biodiversidad/RiquezaEspecies/wms.aspx?</url>
<coordinatesystem>EPSG:4326</coordinatesystem>
</customWmsMapSource>

Mapa de Riqueza de Especies de Magrama

La gracia está en que cualquiera de estos mapas que configuremos para ver en MOBAC, podremos descargarlos para su uso offline desde nuestro móvil con OruxMaps.
 

Por último, hablaros de la posibilidad de incluir GPXs en MOBAC, de manera que podamos visualizar nuestras rutas sobre los mapas que hayamos configurado previamente.


En resumen, MOBAC ha sido un interesante descubrimiento para mi, con una integración total con OruxMaps, una aplicación que me parece digna de admiración en su campo.