Blog de Jorge Machín

Cuando era niño, programaba juegos en mi compú donde todo vivía en un mundo de dos dimensiones. No estaba tan mal porque los gráficas en ese entonces eran muy sencillas. De hecho, una nave espacial solía ser un aburrido cuadro rojo. Sin embargo, conforme fuí aprendiendo física, me fue necesario construir un mundo tridimensional, no sólo para hacer juegos, sino también para hacer mis cálculos y simulaciones.

Antes de consultar libros sobre el tema, intenté resolver el problema por mi cuenta. Yo lo visualizaba como convertir un espacio 3D (el mundo) a un espacio 2D (la pantalla). La manera más sencilla que se me ocurrió fue simplemente proyectar todos los puntos a una pared imaginaria en frente de mí. Las proyecciones podían ser de forma recta ignorando simplemente el eje Z; pero así no es muy atractivo porque no se crea la sensación de perspectiva. Es mejor proyectar con un ángulo imaginando que es el ángulo de visión del ojo. Mi primera representación aplanada fue esta:

Diagrama 1

Nuestro observador esta en el origen y mirando hacia Z, P es el punto que queremos proyectar, X es el punto proyectado y d es la distancia a nuestra pantalla imaginaria.

Ahora, ni modo, a hacer álgebra. Por triángulos semejantes tenemos:

Haciendo un lado pasos engorosos, despejamos Xp:

Por analogía también encontramos:

De las dos ecuaciones anteriores es fácil deducir que d es matemáticamente un factor de escala y que al usar estas ecueciones, los objetos se ven más grandes conforme se acercan al observador y reducen su tamaño al alejarse; sin importar si nuestros puntos a gráficas se encuentran antes o después del punto d.

Pero no hemos terminado, nuestra pantalla hasta ahora esta en "coordenadas mundiales" las cuales no tienen porque concordar con las coordenadas de nuestra pantalla. De hecho, las coordenadas de nuestra pantalla son siempre positivas y el origen esta en la esquina superior izquierda. Es necesario hacer la transformación de coordenadas mundiales a coordenadas de la pantalla.

Diagrama 2

Con un poco de observación, se puede encontrar el factor de conversión para el eje x:

En la mayoría de los casos se puede suponer para Sxmin un valor de cero:

Si queremos manejar la pantalla mostrando 4 cuadrantes, entonces :

De forma similar para el caso del eje y:

De igual forma, se puede suponer para Symin un valor de cero:

Para acomodar en cuatro cuadrantes, :

Conclusiones:

Ya con esto podemos armar una ciudad de casas de cerrillos con formulas con operaciones sencillas que incluso en las antigüas máquinas de 8 bits corren relativamente rápido

Aplicando las formulas en una computadora de 0.895 MHz

Las formulas presentadas aquí son muy limitadas, pero demuestran lo fácil que puede ser trabajar la tercera dimensión. En posts posteriores se trabajarán más para quitar las restricciones autoimpuestas como que el plano de proyección este únicamente perpendicular el eje Z y que el centro de proyección se encuentre únicamente en el origen.

El tiro parabólico es indispensable para todo juego que maneje balística. Su ecuación en su caso más simple en dos dimensiones la conocemos desde nuestros primeros estudios de física en la secundaria o la preparatoria. Ahora que esta muy de moda los juegos en tres dimensiones es bueno tener a la mano la ecuación parametrizada:

En lo único que cambia es la proyección extra (con un nuevo ángulo) y obviamente la tercera variable espacial. Me fue muy útil para un videojuego de baloncesto.

Cuando trabajé en la constructora en 1997, tuve la oportunidad de aprender a modelar las obras que se estaban proyectando para construir maquetas y paseos virtuales. Era un trabajo que disfrutaba bastante porque es relajante y artístico en cierta forma. También era toda una experiencia caminar por los edificios ya que estaban terminados; era como si de pronto se pudiera vivir la realidad virtual. No tenían que mostrarme el camino porque ya los conocía de memoria.

Desafortunadamente ya no cuento con los archivos de las maquetas finales con texturas, vegetación, macetas y personas; pero encontré en unos diskettes algunos de los primeros borradores que hice junto con mis compañeros de trabajo:

Usabamos Autocad Release 12 para extruir los edificios directamente de los planos arquitectónicos y 3D Studio Release 4 para colocar las texturas y hacer los paseos virtuales. El tiempo de modelado era corto, en un par de días se tenía un edificio completo. El problema era el "rendereado" de alguna animación porque llevaba toda una noche en las recién salidas Pentium y se tenía que repetir si algo no nos gustaba. El resultado final era una película, un archivo VRML para internet o bien un archivo ejecutable en DirectX.

Nota: Como pasatiempo, puede buscar las diferencias entre las fotografías aéreas.

Cuando comencé a estudiar OpenGL para exportar modelos tridimensionales de blender a un programa de simulación escrito en C++ que estaba escribiendo, utilicé primero un programa de un sólo archivo para hacer pruebas rápidamente para después implementarlo ya de manera formal. Esta forma de trabajo me ha funcionado muy bien porque puedo dejar guardados varios archivos con distintas pruebas de concepto que me pueden servir para dar clases o refrescar rapidamente mi memoria en vez de andar buscando y recordando ¿dónde use eso?.

Simple pero efectivo

Los fuentes del programa se pueden encontrar aqui: Código Fuente.

Páginas: 1 2

DeterK 1.0 era un programa de utilería para ingeniería civil que realizaba cálculos de estructuras de concreto y de elementos metálicos para edificios. En el caso de estructuras de concreto obtenía la geometría y el calibre de las varillas a utilizar. Estaba programado en Borland C++ 5.0, usaba OWL para el manejo de ventanas y BDE para el manejo de bases de datos. Podía importar y exportar archivos a otros programas de Ingeniería civil incluyendo al STAAD.

Cálculo de un estacionamiento

Lo escribí a principios de 1996 en la vida en la que trabajaba en una constructora. Fue mi primer programa relativemente complejo en C++, donde desarrollé y apliqué técnicas de programación profesionales para reducir el número de errores en la programación, realizar cambios de forma rápida y autodocumentables.

Cabe aclarar que en esa época era más talachudo programar, porque había menos librerías libres y poca información en Internet; por lo que prácticamente había que hacerlo todo desde cero. Por ejemplo, la librería de 3D la tuve que programar, pero me sirvió bastante como ejercicio. Poco tiempo después conocí Direct-X y OpenGL, pero al cambiar de trabajo tuve menos necesidad de utilizar este tipo de librerias hasta varios años después.