Introducción

La creciente potencia de cálculo de los ordenadores ha permitido que actualmente sea factible el uso de técnicas avanzadas de simulación física en cualquier equipo doméstico de gama media.

La simulación física desempeña un papel importante en múltiples campos actualmente en auge, como son la realidad virtual y los videojuegos. También se hace uso de la simulación física en el nuevo cine de animación, donde el realismo de los elementos que componen la escena y sus interacciones alcanza unos niveles inimaginables hace pocos años.

Existen múltiples formas de aprovechar la potencia de cálculo de los ordenadores para hacer simulaciones físicamente realistas: desde incrustar en el código las fórmulas necesarias y calcular la física a bajo nivel, hasta la utilización de paquetes de software destinados a este fin.

El cálculo de la física incrustado en el código de la aplicación no está en consonancia con la filosofía moderna de la programación orientada a objetos ni con la ingeniería del software. Se pierde toda posibilidad de reutilizar el código y su mantenibilidad se complica a medida que crece la aplicación.

El uso de paquetes de software como Endorphin de NaturalMotion o los añadidos de dinámica para 3DStudio MAX son una opción para casos específicos en los que se requiera un entorno integrado para el desarrollo de modelos articulados. La ventaja de estos paquetes es que disponen de todas las herramientas necesarias para la creación, animación y representación de criaturas virtuales articuladas.

La desventaja que presentan las soluciones integradas derivan de la falta de flexibilidad a la hora de utilizar las características de simulación física en un programa propio. Resulta difícil salir del entorno integrado, y el motor de dinámica usualmente se diseña en exclusiva para su funcionamiento en dicho entorno.

Entre incrustar los cálculos para la simulación en el código de la aplicación y utilizar entornos integrados con posibilidad de simulación física, existe una solución intermedia: las librerías y kits de desarrollo de simulación física (Physics SDK). Estas librerías presentan un API con funciones para la simulación física de entornos virtuales. El grado de realismo que ofrecen depende del campo hacia el que se oriente la librería (industrial, videojuegos). Dependiendo de su campo de aplicación, la librería prestará especial atención a la velocidad de cómputo y al tiempo real (caso de los videojuegos), o bien se centrará en la precisión de los resultados (como suele ocurrir en la simulación industrial), con lo que la capacidad de tiempo real se resentirá.

Independientemente del tipo de software escogido para simular un entorno virutal, es necesario caer en la cuenta de que el cálculo de las fórmulas matemáticas de la física es sólo la base sobre la que construir aplicaciones que requieran de este tipo de simulación. Usualmente un programador necesita utilizar la física a un nivel más elevado. Necesita simular objetos del mundo real, y es en este punto donde surgen las complicaciones. Simular el comportamiento físico de un bloque de piedra (suponiéndola un sólido rígido, la cual es una aproximación bastante aceptable en la mayoría de los casos) es una labor relativamente sencilla. Pero cuando se empieza a trabajar con estructuras más complejas, deformables o articuladas, las fórmulas matemáticas ya no son suficientes. Se requiere alguna capa de software por encima de los cálculos físicos que permita agrupar u organizar de alguna manera primitivas físicas para poder tratar objetos complejos como una única entidad (objeto o clase).

En la actualidad el uso de actores virtuales está en auge. Un actor virtual en el contexto de la simulación física por ordenador puede verse como un modelo articulado. Un modelo compuesto por una serie de miembros unidos mediante articulaciones, y algún mecanismo que permita la aplicación de fuerzas sobre los miembros del modelo, haciendo las veces de músculos o motores.

Pero el uso de actores virtuales en aplicaciones programadas en leguajes de propósito general no es todavía una tarea sencilla. Existe una carencia de herramientas y de estándares que dificulta esta labor.

Otro problema deriva del nivel de aplicación de la dinámica, que no suele estar orientado al modelo articulado. La mayoría de motores de simulación física se orientan al sólido rígido o a alguna entidad homogénea con unas propiedades físicas comunes. Esto implica que un programador debe ingeniárselas para montar un modelo articulado a partir de entidades homogéneas y restricciones en grados de libertad entre ellas (articulaciones).

Para trabajar cómodamente con modelos articulados, obviando su implementación y estructura interna, se hace necesario recurrir a herramientas comerciales como endorphin o havok. Este último es el motor utilizado para la simulación de la física en algunos de los últimos videojuegos vistos en el mercado. Dos buenos ejemplos son Max Payne 2 y Medal of honor, en los que la inclusión de havok ha supuesto un salto cualitativo en el realismo del entorno.

Incluso utilizando las escasas herramientas existentes, no se consigue una separación clara entre el entorno físico simulado y el resto de la aplicación. La física, la visualización y el control de los elementos del entorno se suelen solapar entre si, hasta el punto que se vuelve complicado trazar líneas de separación entro ellas.

Como un intento de solucionar, en la medida de lo posible, algunas de las carencias encontradas en el uso de actores virtuales en entornos dinámicos, se ha llevado a cabo este proyecto de fin de carrera. Los objetivos no son pretenciosos en cuanto a la implementación de un programa, pero sí que se pretende esbozar una arquitectura que pueda servir de referencia para el trabajo con modelos articulados y simulación dinámica.

La simulación física en el campo de la realidad virtual y de la animación, aunque últimamente plagado de logros, se encuentra en constante desarrollo. Con este proyecto se pretende aportar un enfoque más o menos original, enfatizando la separación entre la idea de entorno dinámico y las operaciones con las que se relaciona (visualización, control, gestión). Se busca una separación clara entre contenido (modelo físico-matemático del mundo) y el contenedor (cualquier aplicación que trabaje sobre ese modelo).

Objetivos

Para este proyecto se han planteado los siguientes objetivos:

• Especificar una arquitectura para la gestión de modelos articulados en entornos dinámicos. La filosofía de esta arquitectura hará énfasis en el encapsulamiento del modelo dinámico del mundo, separándolo conceptualmente de las tareas que sobre él se pueden llevar a cabo (gestión, control y visualización).

• Diseñar e implementar un software basado en la anterior arquitectura, orientado al modelo articulado. Es decir, en el que se pueda tratar un modelo articulado o actor virtual como una sola entidad.

• Implementar una sencilla aplicación en la que se aprecie la separación de conceptos en que se basa la arquitectura. Crear un modelo articulado y realizar con él las tareas de visualización y control.

Esquema de la memoria

Este documento se estructura en tres partes, cada una constituída por una serie de capítulos. La primera parte presenta informalmente el contexto en el que este proyecto se enmarca. La segunda abarca las tres fases de desarrollo: análisis del problema, diseño e implementación. En la tercera parte se estudiará el sistema obtenido para validarlo sometiéndolo a una serie de pruebas, tests y ejemplos de aplicación.

El trabajo de Chris Hecker

Chris Hecker, fundador de definition six, es el autor de varios artículos sobre la dinámica del sólido rígido para Game Developer Magazine en los años 96 y 97. Estos artículos están principalmente enfocados al mundo de los videojuegos, y han constituido la base sobre la que varios programadores han desarrollado sus propios motores de dinámica.

Asimismo Hecker llevó a la práctica la información teórica que plasmó en sus artículos, resultando en unos sencillos programas en C que han llegado a convertirse en una referencia imprescindible para cualquier desarrollador interesado en la simulación física por computador.

Motores de dinámica comerciales

Open Dynamics Engine

Es un motor de código abierto y actualmente en desarrollo.

Introducción

"ODE is a free, industrial quality library for simulating articulated rigid body dynamics - for example ground vehicles, legged creatures, and moving objects in VR environments. It is fast, flexible, robust and platform independent, with advanced joints, contact with friction, and built-in collision detection. "

Esta es la definición que aparece en la sección de ODE de la propia web de su autor. La traducción al castellano es la siguiente:

ODE es una libreria gratuita de calidad industrial para la simulación dinámica de sólidos rígidos, por ejemplo vehículos terrestres, criaturas articuladas y objetos móviles en entornos de realidad virtual. Es rápida, flexible, robusta e independiente de la plataforma, con articulaciones avanzadas, contacto con fricción y detección de colisiones propia.

El código original de ODE se debe al neozelandés Russell Smith. Su distribución bajo el paradigma del código abierto ha hecho posible que diversos programadores interesados en el tema desarrollasen sus propias mejoras y colaboraciones al código original. Este enfoque ha hecho de ODE un motor de dinámica gratuito y de calidad. En su página web se pueden encontrar aplicaciones tanto libres como comerciales que ponen de manifiesto la potencia de este motor.

La web de ODE se encuentra alojada de forma temporal en el servidor de sourceforge. Actualmente, la sección de ODE de la web de Smith es un enlace hacia su localización en sourceforge. Smith pide que los enlaces a ODE se hagan a la sección correspondiente de su web personal. Este es el motivo por el que no se incluirán en este documento referencias a secciones especificas dentro de la web de ODE. No obstante toda la información es fácilmente accesible desde su página principal.

Características

Características

La propia librería ODE restringe la simulación a sólidos rígidos, que simplifican el cálculo de la física, lo que repercute en una mayor velocidad de proceso.

Introducción

Preparación del modelo

A partir de la especificación de requisitos se esbozará en esta sección una arquitectura informal para el programa. Más adelante se irá perfilando hasta conseguir una arquitectura lo suficientemente consistente y formal con la que trabajar en la fase de diseño. Esta arquitectura se centrará más en qué debe hacer el programa, y no tanto en cómo debe hacerlo.

La idea principal de este proyecto viene determinada por la separación clara entre el sistema de simulación física y los sistemas de visualización y control. Esquemáticamente se puede ver el sistema de simulación como un proceso que sirve información al sistema de representación y la recibe del sistema de control. Es decir, la interacción con el mundo simulado se realiza enviando o recibiendo información del sistema de control. La Figura 5-1 muestra gráficamente esta interacción entre los diferentes sistemas. Más adelante se matizarán las formas de transmitir la información.

Otro aspecto importante es la forma de abstraer objetos del mundo real en el mundo virtual. Para ello se diseñará una jerarquia de clases capaz de describir desde las primitivas más simples hasta modelos articulados complejos. Dos clases básicas de esta jerarquia serán las que representan un sólido rígido y una articulación. Cada sólido rígido y articulación determinará un sistema de coordenadas respecto al cual podrán ubicarse otras entidades. Esto llevará a la formación de cadenas de sistemas de referencia o sistemas de referencia anidados.

Las primitivas físicas se derivarán de las clases base sólido rígido y articulación. Así, las clases para describir sólidos rígidos concretos, con sus atributos de forma y masa, vendrán definidas por diferentes especializaciones de la clase base sólido rígido. Del mismo modo, tipos de articulación concretos, con atributos como el número de grados de libertad y ejes de rotación o traslación, derivarán de la clase genérica articulación.

Las primitivas básicas que se implementarán para definir sólidos rígidos son las siguientes:

• Esfera

• Caja

• Cápsula (cilindro de extremos redondeados)

Y para definir articulaciones, se implementarán las siguientes primitivas:

• Telescópica (1 grado de libertad traslacional)

• Bisagra (1 grado de libertad rotacional)

• Universal (2 grados de libertad rotacionales)

• Doble bisagra (dos bisagras conectadas en serie con diferentes ejes de rotación, tiene 2 grados de libertad rotacionales)

• Esférica (3 grados de libertad rotacionales)

• Fija (ningún grado de libertad)

Hay que hacer notar que estas primitivas son exactamente las que implementa ODE. Lo que se hará en este proyecto es encapsularlas en clases pertenecientes a una jerarquía que permita trabajar con agrupaciones de estos elementos de construcción de una forma eficaz. Es decir, facilitar el trabajo con modelos articulados.

Si la especialización de las clases sólido rígido y articulación daba como resultado las primitivas básicas de construcción, agrupaciones de estas clases permitirán definir estructuras más complejas formadas por una serie de sólidos rígidos unidos mediante articulaciones. Estas estructuras vendrán definidas por la clase grupo dinámico. A su vez, especializaciones de esta clase permitirán definir diversos tipos de grupos dinámicos. Una criatura virtual es un buen ejemplo de especialización de un grupo dinámico, pues consiste en un conjunto de miembros unidos por articulaciones, pero además posee otros atributos y funciones que la caracterizan como criatura.

Una clase grupo, además de contener sólidos rígidos y articulaciones, también podrá contener otros grupos. Así, un mundo virtual no será más que una especialización de la clase grupo, ya que contiene sólidos, articulaciones y otros grupos, además de atributos tales como la gravedad.

Cada articulación incluirá motores para aplicar fuerzas en cada uno de sus grados de libertad. El control de estos motores se hará por velocidad deseada. Es decir, el sistema aplicará la fuerza necesaria para que el motor alcance la velocidad indicada. La fuerza máxima que un motor puede aplicar será un parámetro configurable.

Además de disponer de una jerarquia de de clases para describir un mundo virtual, se hace necesario un método para dotar de persistencia al modelo y sus elementos, una forma de guardar en memoria secundaria el estado del mundo en un instante determinado, así como descripciones de los modelos articulados que en él se desenvuelven.

Hasta aquí quedan introducidos informalmente los elementos y clases necesarios para describir un mundo virtual. A lo largo de las secciones siguientes se analizará cada clase en profundidad.

Nomenclatura utilizada

Para hacer el código accesible al mayor número de personas, se utilizará el inglés en los nombres de clases, variables y funciones. Además se utilizará la convención de iniciar los nombres de las clases con la letra C mayúscula para evitar su confusión con otras estructuras.

Asimismo, se adoptará el término criatura virtual o simplemente criatura para hacer referencia a los modelos articulados que se desenvuelven en el mundo virtual. Esta elección se debe al enfoque de este proyecto hacia campo de la inteligencia artificial. El término actor virtual induce a pensar en una figura antropomórfica, mientras que modelo articulado resulta demasiado genérico para definir entidades autónomas dotadas de inteligencia simulada.

Identificación de las clases

Durante la preparación del modelo se han podido distinguir varias clases informales. Ahora se formalizarán un poco más, dándoles nombres concretos y colocándolas en su lugar en un primer diagrama de clases, que se irá perfilando y ampliando conforme se avance hasta la fase de implementación.

Se empezará por las clases básicas para la construcción de un modelo articulado: los miembros y las articulaciones. Puesto que este proyecto se basa en la librería ODE, se utilizará su léxico, siempre que sea posible, para las diferentes clases que se definan. ODE utiliza la nomenclatura de body y joint para los sólidos rígidos y las articulaciones respectivamente. Así, se definen las clases CBody y CJoint.

Se desea disponer de un sistema de coordenadas local para cualquier elemento del mundo, especialmente para sólidos y articulaciones. Para ello se definirá una clase que represente un sistema de coordenadas (un marco de referencia), con funciones para su gestión. El nombre que recibirá esta clase es CFrame, y de ella derivará el resto de clases que requieran determinar un sistema de coordenadas, como CBody y CJoint.

Ahora cabe preguntarse por las agrupaciones de los elementos básicos de construcción. Pensándolo un poco, tanto una criatura virtual como el mundo en el que se desenvuelve van a estar constituidos por agrupaciones de elementos base y otras agrupaciones. De este modo se define la clase CGroup, que va a contener miembros, articulaciones y otros grupos.

Es fácil darse cuenta de que las clases para representar criaturas y mundos (CCreature y CWorld respectivamente) van a derivar de CGroup, pues ambas son en esencia agrupaciones de elementos básicos de construcción y de otras agrupaciones.

Se considerará también que tanto el mundo virtual como las criaturas poseen un sistema de coordenadas particular. Es decir, que un grupo de elementos de construcción determina su propio marco de referencia, razón por la cual se derivará la clase CGroup a partir de CFrame.

Una jerarquía de clases informal, a falta de perfilar varios detalles de diseño, quedaría como muestra la Figura 5-2

Análisis de las clases

Un análisis detallado de las clases principales ayudará a comprender mejor su relación con los elementos del mundo real y su lugar en la jerarquía que se ha esbozado.

Elección del lenguaje

Lenguaje