La primera parte para tener efectos de
tipo túnel es tener el túnel geometricamente. Luego ya se ponen
efectos chulis, pero hay que empezar por el túnel.
Y aquí tengo que presumir de haber
tomado una buena decisión, comprar una librería para hacerlo. No se
si es cosa de informáticos, ingenieros, estudiantes o qué, pero lo
veo mucho, en mi mismo el primero. Tendemos a hacerlo todo. Nos
parece fácil, “bah, esto lo hago en dos tardes, y a mi gusto, y
mejor que ese otro”, “si son dos chorradas, te haces un par de
clases y hace lo mismo”. Y sí, es verdad, podría haberme hecho
una librería que hiciera trozos de cilindro desde código y me diera
las funciones que necesitaba, y además se adaptaría mejor a mis
necesidades al estar hecha ad-hoc, y no tendría que invertir tiempo
en aprender el funcionamiento de una librería externa. Pero cuando
tienes que tener esto funcionando en unas semanas, y la parte del
túnel no es lo vital, sino los efectos, y tienes otras cuantas
prácticas en el mismo tiempo, con lo que al final podrás dedicar 4
o 5 días de trabajo a esto, pues si que es la mejor decisión
gastarse una pequeña suma de dinero (creo que me costó menos de 10
euros) y tener una librería que genere la geometría tal y como la
necesitas, y que se coman otros los problemas de como hacer el
mapeado UV de esa geometría, dar opción de ver el cilindro por
dentro o por fuera o que el cilindro no sea regular, sino que pueda
ser tipo zigzag. Hacer un cilindro es relativamente sencillo, pero el
demonio está en los detalles y en desarrollar todas esas pequeñas
cosas es en lo que podría haber dedicado unos días que hicieran que
no llegase a entregar a tiempo.
La librería que uso se llama
Tuberenderer,
es capaz de renderizar cilindros dándole los puntos por los que
tiene que pasar el cilindro y la anchura en cada punto. Además
vienen ejemplos para gestionar varios cilindros.
Con algo de configuración conseguí
tener renderizado por la parte interna del cilindro, que no dibuje
las tapas, mapeado UV bien hecho, todo de forma procedural.
Comencé intentando mover los trozos de
cilindro hacia la cámara, encadenando los movimientos dentro del
cilindro y entre cilindros. Y funcionaba relativamente bien en recto,
pero en cuanto intentaba poner curvas relativamente fuertes para
tapar el horizonte, no conseguía que el túnel pasara por la cámara.
Así que cambié la estrategia y finalmente es la cámara la que se
mueve por dentro de los cilindros, en la dirección que marque el
trozo de cilindro actual. Así la cámara se mueve según la
velocidad marcada interpolando entre puntos de un cilindro y saltando
de un cilindro al siguiente cuando se acaba por el que iba.
Tanto las direcciones como los radios
de los cilindros se generan aleatoriamente, pero con la filosofía de
cambios pequeños locales de los mapas de Perlin, pero en lugar de
estar pre-calculados, se van tomando pequeños movimientos aleatorios
desde el punto anterior, controlando el gradiente local y los máximos
y mínimos globales.
Problema en el empalme de trozos
Es un defecto que no di demasiada
importancia, ya que se notaba poco, hasta que comencé a usar shaders
personalizados y se notaba mucho la diferencia gráfica entre el
fondo del render y el túnel. El problema es que no hay geometría
que una el final de un trozo de túnel con el siguiente. Y si la
dirección cambia, entonces aunque ambos estén en el mismo punto, la
orientación cambia y se ve un hueco por el cual se ve el fondo de
escena.
Intenté que un chunk empezase un poco
antes de empezar el último, aunque se cruzasen para que no se viese,
pero el resultado no era bueno, y se notaba en el movimiento fluido
de la cámara que ahí había una discontinuidad de distancias. Otra
solución que intenté fue ir cambiando desde el script el color de
fondo para que fuera coincidiendo con el del túnel según la
distancia a la que estaba. El resultado era algo mejor, pero se
seguía notando el corte y cierta diferencia en el color.
La solución que mejor funcionó fue
hacer cada inicio de trozo nuevo un poco más ancho que el anterior.
Esto hace que recorrido en el sentido que se recorre no se noten los
cortes, aunque si lo recorriéramos en sentido contrario se notaría
mucho, empeorando el proble
ma. En la imagen se muestra una vista lateral, pintada a mano y un poco exagerada de cómo funciona la solución. La cámara avanzaría de izquierda a derecha para que el truco funcionase.
Aún así algo del problema queda si la
cámara es muy poco cuadrada (por ejemplo 16:9) ya que por los lados
se ve más de lo que estaba planeado.
No hay comentarios :
Publicar un comentario