PRÁCTICA 3: Implementación de un ajedrez virtualmgarcia/RVA/P3b.pdf · PRÁCTICA 3:...

ESCUELA SUPERIOR DE CIENCIAS EXPERIMENTALES Y TECNOLOGÍA INFORMÁTICA

REALIDAD VIRTUAL Y ANIMACIÓN

PRÁCTICA 3: Implementación de un ajedrez virtual

Marcos García Lorenzo

-{ PAGE }- Realidad virtual y animación

1. INTRODUCCIÓN En esta práctica cada grupo deberá implementar un juego de ajedrez virtual. En

el desarrollo de la práctica se modelará la base de datos de la aplicación. A esta base de datos se le dotará de un comportamiento sencillo ante las acciones del usuario, pudiendo de forma opcional implementarse un comportamiento más complejo, incluso dotarla de un comportamiento inteligente usando la librería GNUChess. Además del modelado del comportamiento de sistema y de la base de datos, se deberán modelar algunas estructuras geométricas que forman parte de la base de datos, utilizando el software 3D Studio Max 6.

En la implementación de la base de datos se utilizará una toolkit de programación gráfica de alto nivel, como las vistas en la parte teórica de la asignatura (OpenInventor, Java3D, Eon), recomendándose el uso de Coin3d (implementación de OpenInventor bajo licencia tanto propietaria como GPL de OpenInventor). El guión de esta práctica da soporte especial a aquellos alumnos que trabajen con OpenInventor, pero se permitirá el uso de cualquier toolkit de programación de alto nivel. No está permitido el uso de librerías gráficas de bajo nivel como OpenGl o DirectX de forma exclusiva, pero sí se permitirá su uso si se combina con alguna librería de alto nivel.

La práctica se realizará en grupos de dos personas como máximo. La entrega de la práctica se realizará de forma presencial debiendo estar presentes todos los miembros del grupo y entregar la práctica funcionando, junto con una memoria explicativa. Se valorará muy positivamente que el código implementado sea portable, así como la realización de partes opcionales.

En la página Web de la asignatura se encontrará toda la información y material necesarios para realizar la práctica:

• Material para realizar la práctica

• Fechas de entrega

• Normativa de prácticas

• Avisos

• Enlaces a páginas de interés

Estas informaciones podrán ser modificadas, por lo que se recomienda consultarlas periódicamente.

2. DESARROLLO DE LA PRÁCTICA

La realización de la práctica puede dividirse en 4 fases. En la primera se modelará la geometría de los objetos que constituirán la escena. En la segunda fase, se cargarán estos objetos en la base de datos. En la tercera, se añadirá un comportamiento básico a la aplicación y por último, cada grupo de prácticas implementará las mejoras que desee en la aplicación. La primera fase se describe en los subapartados 1 y 2, la segunda en los subapartados 3 y 4, la tercera en el subapartado 5 y la cuarta en el subapartado 6.


2.1. Modelado Geométrico de las Fichas (Peones) Antes de empezar con el modelado geométrico de los componentes que

constituyen nuestra base de datos comentaremos algunos aspectos que se deben tener en cuenta:

- Nuestro tablero medirá 80 unidades de ancho y 80 unidades de largo. Esto implica que cada casilla del tablero ocupará 10 unidades de largo y 10 de ancho.

- La primera casilla (casilla (0,0)) se colocará de forma que su esquina inferior izquierda esté en el punto (0,0).

- En OpenInventor se suele utilizar el eje z para la profundidad y 3D Studio utiliza el eje y. Todos los exportadores que se van a utilizar en la práctica solucionan este problema.

- En el material de prácticas se proporcionan mapas de textura, pero se da libertad a cada grupo para que utilice las texturas que considere oportuno.

Comenzaremos con el modelado de los peones utilizando el programa “3D Studio Max”. Utilizaremos un objeto de tipo Loft. Este objeto interpola una superficie a lo largo de una curva. Simplemente hay que indicarle los valores que toma la superficie en una serie de puntos de control.


Empezaremos creando las curvas que darán valor a la superficie en distintos puntos. Utilizaremos rectángulos para la base y circunferencias para el resto de secciones. La creación, para que sea más precisa, la haremos por teclado utilizando el menú “Key entry”, este menú se encuentra en la pestaña de Creation > Shape > Splines > Rectangle.

Es importante tener seleccionada la vista TOP, para que el rectángulo se nos cree

en la posición adecuada. En principio la posición donde se cree el rectángulo no nos importa mientras tenga las dimensiones adecuadas, por seguir un orden crearemos el primer rectángulo centrado en el origen y con altura 0. Como ya se ha comentado cada celda del tablero medirá 10 unidades. Tenemos que intentar que la base se ajuste a esta medida. Así pues nuestro rectángulo medirá 8 unidades tanto de ancho como de largo. Podemos modificar el parámetro corner radius para suavizar las esquinas. Una vez creada el primer rectángulo, se pintará un nuevo rectángulo con las mismas dimensiones, también centrado en el origen, pero con una altura de 2,5 unidades.

En los siguientes pasos se crearan de las circunferencias que se usaran para definir el resto del contorno de la figura. La altura de estas circunferencias variará de


2,5 a 20 unidades. Al concluir tendremos un dibujo parecido al que se muestra en la siguiente figura.

Como ya se ha comentado el objeto Loft interpola una superficie a través de una curva (path). El siguiente paso será construir esta curva mediante una línea (objeto Line). La creación del path se realizará por teclado construyendo una línea de dos puntos. Uno situado en el origen y el otro en la posición (0, 0, 20).

Una vez creado el path, ya podemos construir el objeto Loft. Debemos seleccionar la línea que se usará como path y crear el Loft en Creation > Gemoetry > Compound Object > Loft. Seleccionaremos las curvas que se usarán en la superficie y a qué altura se encuentran. Para seleccionar cada una de estas figuras utilizaremos el comando Get Shape y para indicar la altura usaremos el cuadro Path Parameters.

OPCIONAL: Modelar el resto de figuras.

Podemos refinar el resultado en el cuadro Deformations que se encuentra en Modify cuando el Loft está seleccionado.


Para terminar, borraremos las curvas utilizadas en la construcción del Loft y moveremos el peón para centrarlo en el primer cuadrado del tablero. Para ajustar las unidades correctamente, moveremos el peón insertado nosotros mismos las unidades que deseamos desplazar la ficha. Por último, exportaremos esta figura tanto a formato 3DS como a formato vrml2 y la guardaremos en formato MAX. El resultado es un objeto como el que se muestra a continuación.

2.2. Modelado Geométrico del entorno En este segundo apartado vamos modelar los componentes que van a formar

parte de nuestro entorno virtual: el tablero, el suelo y el horizonte.

Primero modelaremos el tablero de una forma sencilla. Crearemos un rectángulo centrado en el (40, 40, 0) y cuyas dimensiones, tanto de ancho como de largo, sean el número de casillas por 10 (80). A continuación, convertiremos esa línea en un plano, esto lo haremos en Modify > Extrude, aplicándole el operador extrusión. Si la


extrusión (Amount) es mayor que 0 se generará un cubo, si el valor es 0 se genera un plano. Por último lo exportaremos a un fichero VRML2 y lo guardaremos en formato MAX. Las texturas se las añadiremos utilizando OpenInventor.

En un segundo paso crearemos el suelo. Para crear el suelo, utilizaremos un rectángulo de grandes dimensiones (10000x10000) y le aplicaremos el operador de extrusión para dotarle de dimensiones.

Si cargamos el suelo y el tablero en nuestra base de datos tal y como están ahora, la tarjeta gráfica no sabrá qué pintar delante, si el suelo, o el tablero. Para solucionar este problema, haremos un agujero en el suelo, en el sitio donde iría el tablero. Para ello crearemos un cubo con las dimensiones del tablero y situado en el mismo punto donde se ubicaría el tablero.

Luego seleccionaremos el suelo construiremos un objeto booleano (Creation > Gemoetry > Compound Object > Boolean). Utilizaremos Pick Operand B para seleccionar le segundo operando y como operación seleccionaremos (A-B).

A continuación dotaremos de textura al suelo. Nos iremos al editor de materiales de 3D Studio. Seleccionaremos el una ranura libre. En Maps seleccionaremos una


textura para la luz difusa (Diffuse Color>Bitmap). El alumno podrá seleccionar la textura que desee.

Una vez seleccionada la textura nos aparecen nuevas opciones. Modificando el parámetro Tiling (en Diffuse Color Coordinates), conseguiremos que la textura se repita el número de veces que le indiquemos. Para asignar la textura, arrastraremos el material sobre el objeto. Por último exportaremos el suelo a VRML2 y lo guardaremos en formato MAX.


Finalmente crearemos el horizonte. Construiremos una esfera centrada en el origen. El radio de esta esfera debe medir aproximadamente la mitad de la anchura del suelo.

Igual que hicimos con el suelo le asignaremos una textura. Para construir esta textura tomaremos la fotografía de un paisaje. La invertiremos y se la volveremos a pegar debajo de la fotografía original. Para realizar este proceso podemos utilizar un editor gráfico tan simple como el Paint.

Para ajustar mejor la textura a la esfera podemos utilizar el Tiling horizontal. Es

importante tener en cuenta que la esfera tiene que ser vista por dentro, así pues debemos marcar Both Sides (Shader Basic Parameters) en el editor de materiales. Al igual que los modelos anteriores lo exportaremos a VRML2 y lo guardaremos en formato MAX.


2.3. Diseño básico del árbol de escena En este apartado modelaremos la base de datos de la aplicación usando

OpenInventor. Primero construiremos el esqueleto básico de la aplicación:

1. Inclusión de la librería OpenInventor: Han de incluirse aquellas librerías que van a ser utilizadas (nodos, ventanas, eventos, acciones, motores, manipuladores…). En un principio se incluirán aquellas librerías que se necesiten y a medida que se avance en el desarrollo se irán incluyendo más.

#include <Inventor/Win/SoWin.h> #include <Inventor/Win/viewers/SoWinExaminerViewer.h> #include <Inventor/Win/viewers/SoWinRenderArea.h> #include <Inventor/nodes/SoNodes.h>

2. Declaración de las variables globales. En un primer momento la única variable global será el área de renderizado. Por simplicidad se recomienda que en un primer momento se utilice una ventana del tipo SoWinExaminerViewer y que en fases más avanzadas se pase a utilizar una SoWinRenderArea.

3. Creación de una función que inicialice la base de datos. Esta función tendría una estructura parecida a la que se indica a continuación.

SoSeparator* initScene();

a. Lectura de los ficheros donde se almacena la geometría, almacenados en nodos SoSeparator. Un nodo por estructura de datos (ver función readFile()).

b. Inicialización del nodo raíz (ref()).

c. Creación de una cámara perspectiva que se añade al nodo raíz.

d. Creación de los nodos que tratan los eventos de teclado y de ratón con sus respectivas callbacks (SoEventCallback). En un primer momento la función callback de ratón estará vacía, mientras que


programaremos la de teclado para que al pulsar la tecla ESC se salga de la aplicación.

e. Retorno del nodo raíz

4. Creación de la función main. La función main queda reducida a:

a. Inicialización de la base de datos de OpenInventor (SoWin::init()) y de la ventana de render.

b. Llamar a la función que genera el árbol de escena.

c. Ajustes de la ventana de render (tipo transparencia, tipo de la acción de renderizado, selección del árbol de escena, mostrar ventana de render…).

d. Llamada al bucle de eventos

e. Liberar recursos.

Todas la figuras que constituyen la base de datos se encuentran por defecto en la casilla 0-0, y estas han de colocarse en distintas posiciones del tablero. Se recomienda la creación de una función que dada una casilla devuelva la traslación que habría que aplicar para colocar la figura en dicha posición. Esta función sería tan simple como multiplicar la i y la j por un factor.

SbVec3f setPos(int i, int j);

En pasos anteriores se generaron los modelos geométricos que se cargarán en la base de datos. Estos modelos deben cargarse en la base de datos. Por simplicidad se recomienda que antes de construir el árbol de escena se cree una función que reciba el nombre de un fichero VRML y te devuelva un nodo SoSeparator con el árbol de escena del fichero.

SoSeparator *readFile(const char *fileName);

La función readFile deberá realizar las siguientes tareas

1. Abrir el fichero: Se utilizará la clase SoInput (openFile); si el fichero no puede abrirse, se devolverá un error y se saldrá de la aplicación.

2. Comprobar que el fichero es valido (SoInput::isValidFile()); en el caso de que no lo sea, se devolverá el correspondiente error y se saldar de la aplicación.

3. Lectura del fichero (SoDB::readAll) y retorno del nodo raíz.

Esta función la utilizaremos para cargar las fichas, el tablero y el entorno, en la función de inicialización. Aunque haya varias fichas iguales sólo almacenaremos la geometría de la figura una vez. Para crear varios peones, por ejemplo, cambiaremos sus nodos de propiedad y de transformación pero utilizaremos el mismo nodo de geometría.

SoSeparator *tablero=readFile("data/tablero.wrl");

SoSeparator *peon=readFile("data/peon.wrl"); SoSeparator *rey=readFile("data/rey.wrl"); SoSeparator *reina=readFile("data/reina.wrl"); SoSeparator *alfil=readFile("data/alfil.wrl"); SoSeparator *caballo=readFile("data/caballo.wrl");


SoSeparator *torre=readFile("data/torre.wrl");

En un primer momento construiremos el siguiente árbol de escena.

Como puede observarse existen dos separadores básicos. Uno contiene las fichas y otro contiene el tablero.

El separador que contiene las fichas contiene a su vez dos separadores: uno para las fichas blancas y otro para las fichas negras. Los primeros nodos de estos separadores contienen los materiales de las fichas que contienen. El primer nodo es del tipo SoTexture2 y contiene una textura 2D. El segundo nodo es del tipo SoTexture2Transform. Al aumentar el factor de escala de este nodo, se aumenta el número de veces que se pega la textura. Cada grupo de prácticas deberá ajustar este valor a la textura que utiliza.

El tablero al igual que las fichas también tiene un nodo SoTexture2 y un nodo SoTextureTransform. La textura que almacena el nodo la generaremos con un editor de imágenes sencillo, como el Saint, a partir de las texturas de las teclas negras y de las texturas de las fichas blancas. De la forma que se indica en la siguiente figura. Puesto que cada componente de la textura representa dos columnas y dos filas el factor de escala que hay que aplicarle es de 4.


Por ultimo utilizaremos el metodo viewAll() de la cámara para ver toda la escena.

2.4. Mejora de la apariencia En este apartado vamos a mejorar la apariencia de nuestra aplicación. Para ello

utilizaremos dos técnicas distintas. La primera consistirá en crear un entorno, es decir, colocaremos nuestro tablero en un mundo virtual (de este modo no parecerá que flota en éter). Después, simularemos un suelo y un tablero pulidos en los que se reflejen las fichas.

Para crear un entorno básico lo único que tendremos que hacer es cargar el suelo y el cielo, que generamos en 3D Studio, en nuestro árbol de escena. Es importante tener


en cuenta que se debe llamar a la función viewAll de la cámara antes de insertar el entorno.

Ahora, cuando ejecutamos nuestra aplicación, observamos que la cámara está situada a la altura del suelo, lo que provoca un efecto extraño con el horizonte. Debemos cambiar los parámetros de la cámara para que esta se inicialice por encima del suelo y que no se muestre que el cielo esta duplicado.

Al mover la cámara vemos como nos acercamos al horizonte. El horizonte debería

ser un punto muy lejano. Para conseguir que el horizonte siga a la misma distancia, aunque movamos la cámara, conectaremos la x y la z de la cámara a una transformación aplicada al horizonte. El campo posición de la cámara esta formado por un vector del cual nos interesan sólo 2 de sus componentes. Por este motivo no podemos conectar directamente la posición de la cámara con la posición del horizonte. Para solventar este problema utilizaremos un motor, el SoCalculator. Existen otros motores con los que podemos realizar este efecto de manera más eficiente. De forma opcional podrán probarse otros motores, describiendo lo que se ha hecho en la memoria.


En el siguiente paso vamos a simular que tanto el tablero como el

suelo reflejan las fichas. Como se ha visto en la teoría de la asignatura, las técnicas de sombreado que se utilizan en entornos donde es preciso el tiempo real son locales y no nos permiten definir materiales que reflejen otros elementos de la escena. Para simular este efecto utilizaremos un


pequeño truco. Primero haremos que nuestro suelo y nuestro tablero sean trasparentes. Además, tendremos que mejorar el tipo de transparencia que usa el área de render, lo haremos con el método setTransparencyType. El suelo lo haremos transparente en 3D Studio utilizando el editor de materiales e indicado un valor transparencia. Para hacer que el tablero sea transparente añadiremos a su separado un nodo SoMaterial y cambiaremos su campo transparencia.

En un segundo paso duplicaremos nuestra escena por debajo del

suelo y la multiplicaremos por un factor de 1,-1,1. De esta forma, al ver la escena desde arriba, dará la impresión que estamos viendo el reflejo de lo que hay por arriba.


Observamos que las fichas que creamos con 3D Studio, se ven negras

al escalarlas por el factor antes indicado. Esto se debe a los materiales que introduce el exportador de 3D Studio. Para solucionar este problema utilizaremos la herramienta CoinDesigner. Lo primero será importar en la herramienta el fichero 3DS donde se almacena la geometría del peón. CoinDesigner nos mostrará un árbol de escena como el que se indica en la Figura A. Utilizando la herramienta lo modificaremos hasta que sea igual al de la Figura B. Por ultimo guardaremos el fichero como peon.wrl.


Figura { SEQ Figura \* ALPHABETIC }

Figura { SEQ Figura \* ALPHABETIC }

El peón así generado tendrá ordenados los vértices de las caras en

sentido contrario al que usa OpenInventor. Para solucionar este problema utilizaremos el ejecutable “swapTriangles.exe” que se entrega junto al resto del material de prácticas. Opcionalmente, cada grupo podrá diseñar su


propio programa “swapTriangles.exe” y explicar en la memoria como lo ha hecho.

Una vez realizados todos los pasos anteriores nuestra aplicación tendrá un aspecto parecido al que se muestra a continuación.

2.5. Movimiento de las fichas Terminada la descripción de la parte geométrica de la base de datos,

dotaremos a la aplicación de un comportamiento sencillo. A continuación se describe brevemente cómo se tiene que comportar la aplicación.

- Al pinchar con el ratón sobre una ficha esta se marcará. - Si hay una ficha marcada y se pincha sobre otra del mismo color, se

marcará la nueva ficha y se desmarcará la que estaba seleccionada. - Si hay una ficha marcada y se pincha sobre otra del color contrario,

se eliminara la ficha que se ha pinchado con el ratón y la ficha marcada ocupará su posición.

- Si hay una ficha marcada y se pincha sobre el tablero, la ficha marcada pasará a ocupar la casilla sobre la que se ha pinchado.

-Si hay una ficha marcada y se pincha con el ratón en cualquier sitio, excepto en los anteriormente mencionados, la ficha se deseleccionará.


Lo primero que haremos será sustituir el nodo SoSeparator de las fichas por un nodo SoSelection. Este nodo captura eventos de ratón y marca el nodo sobre el que se ha pintado. Configuraremos este nodo para que tenga el comportamiento, a la hora de seleccionar nodos, que buscamos: es decir, que sólo se seleccione un nodo al mismo tiempo. Al área de render hay que indicarle que se repinte cuando se produzca una selección. Esto se hace con el método redrawOnSelectionChange. Para indicar que queremos que se recuadren las partes seleccionadas utilizaremos el método setGLRenderAction y le cambiaremos la acción de renderizado.

Utilizaremos la función que trata los eventos de ratón para realizar los cambios que haya que hacer en la base de datos como consecuencia de las acciones de los usuarios. En esta función comprobaremos si hay algún objeto seleccionado. Si lo hay, utilizaremos la acción SoRayPickAction. Para saber dónde se ha picado, podemos dar a los objetos nombres y crear variables globales para comparar su valor. Son de especial interés los métodos que se listan a continuación:

SoNode: - getName: Devuelve el nombre que se le ha asignado a

un objeto. - setName: Asigna un nombre a un objeto

SoRayPickAction: - getPickedPoint: Estructura de datos donde se

almacena la información del punto seleccionado. SoPickedPoint:

- getPoint: Punto sobre el que se ha pinchado - getPath: Ruta al objeto seleccionado

SoPath - getChild: Devuelve un elemento de la ruta empezando

por el nodo raíz. - getNodeFromTail: Devuelve un elemento de la ruta

empezando por el nodo hoja. - getIndex: Devuelve la posición que ocupa un hijo en la

lista del padre SoSelection

- getNumSelected: Número de nodos seleccionados - deselect: Deselecciona el nodo que se le indique. - getPath: Devuelve el path del elemento seleccionado


SoSeparator - getNode: Devuelve el nodo hijo que se indique - removeChild: Borra el nodo hijo que se indique

SoEventCallback - getEvent: Devuelve el evento que produce la llamada a

la función - SO_MOUSE_PRESS_EVENT: Macro utilizada para

saber si se ha pulsado un determinado botón del ratón - setHandled: Marca un evento como tratado, de este

modo no sigue recorriendo el árbol

2.6. Mejoras opcionales En este último apartado el alumno es libre para realizar cualquier mejora sobre

la aplicación. La realización de este apartado es libre pero obligatoria. A continuación se sugieren algunas posibles mejoras.

- Limitar el movimiento de la cámara, para evitar que la cámara se aleje mucho de la escena y se sitúe bajo el suelo.

- Introducir la posibilidad de ver la escena en estéreo en formato Above-Below

- Modificar la aplicación para que se respeten los turnos de cada usuario.

- No permitir movimientos incorrectos de las fichas


- Permitir jugar partidas con un jugador virtual utilizando GNUChess.

- Crear una interfaz de red para jugar partidas remotas

- Introducir mejoras en la interfaz de usuario

3. CONTENIDO DE LA MEMORIA DE LA PRÁCTICA

El día de la entrega de la práctica se deberá adjuntar una pequeña memoria explicativa. Se deberá hacer énfasis en las partes no guiadas de la práctica, así como en las partes opcionales que se han realizado. La memoria deberá explicar, al menos, los puntos que se enuncian a continuación.

Funcionamiento de la aplicación Modelo matemático utilizado (si procede) Descripción de la arquitectura de la aplicación Librerías utilizadas Información que el alumno considere relevante Bibliografía (si procede) Opinión personal

En la portada de la memoria se indicarán los apellidos y nombre de los componentes del grupo (máximo 2 personas).

4. ENTREGA DE LA PRÁCTICA

Los alumnos podrán entregar la práctica al profesor encargado en horario de tutorías, o bien pidiendo una cita vía e-mail. La práctica podrá ser entregada cualquier día, siempre y cuando no se exceda la fecha tope de entrega (esta fecha se publicará en la Web).

Para la entrega de la práctica deberán presentarse los dos miembros del grupo y deberán entregar:

- Ficheros fuente (junto con los ficheros de proyecto o Makefiles)

- Ficheros ejecutables. El material que se entregue debe funcionar si necesidad de instalar ningún componente adicional. Los ficheros binarios deberán funcionar bajo Windows.

- Una memoria explicativa. Esta memoria deberá completarse siguiendo las directivas indicadas en el apartado anterior.

- Todas las texturas utilizadas

- Todos los ficheros iv y wrl que se cargan en la base de datos


- Los ficheros 3DS de todos los elementos de la base de datos elaborados con 3D Studio.

La práctica se realizará en grupos de dos personas como máximo. La entrega de la práctica se realizará de forma presencial teniendo que estar presentes todos los miembros del grupo y entregar la práctica funcionando, junto con una memoria explicativa. Se valorará muy positivamente que el código implementado sea portable, así como la realización de partes opcionales.

En el momento de la entrega, el profesor podrá realizar preguntas a los miembros del grupo, relacionadas con la práctica y su desarrollo.

5. MATERIAL

En este apartado se describe brevemente el material de apoyo que se proporciona para realizar la práctica.

- CoinDesigner: Editor de ficheros VRML. Permite importar de varios formatos

- swapTriangles: Aplicación que cambia la ordenación de los vértices de una malla.

- Fichas: Carpeta que contiene algunas fichas de ajedrez en formato iv.

- Maps: Algunas texturas que se pueden utilizar durante el desarrollo de la práctica.

6. BIBLIOGRAFÍA Y REFERENCIAS “The Inventor Toolmaker : Extending Open Inventor, Release 2” Josie Wernecke. Ed. Wesley.

“Open Inventor C++ Reference Manual” Josie Wernecke. Ed. Wesley.

"Virtual Reality Technology (Second Edition)" Grigore C. Burdea, Philippe Coiffet Ed. Wiley-IEEE Press, 2003

Direcciones Web { HYPERLINK "http://oss.sgi.com/projects/inventor/" }

http://oss.sgi.com/projects/inventor/


{ HYPERLINK "http://wwwasd.web.cern.ch/wwwasd/lhc++/OpenInventor/pro/html/inventor_base.htm" } { HYPERLINK "http://www.coin3d.org/" }

http://wwwasd.web.cern.ch/wwwasd/lhc++/OpenInventor/pro/html/inventor_base.htm



http://www.coin3d.org/

Nombre de archivo: PracticaChess.doc Directorio: D:\Marcos\docencia\material\RVYA(3D)\Practica

programcion Plantilla: C:\Documents and Settings\marcos\Datos de

programa\Microsoft\Templates\Normal.dot Título: ESCUELA SUPERIOR DE CIENCIAS

EXPERIMENTALES Y TECNOLOGÍA Asunto: Autor: Marcos Garcia Palabras clave: Comentarios: Fecha de creación: 08/03/2005 2:31 Cambio número: 2 Guardado el: 08/03/2005 2:31 Guardado por: Administrador Tiempo de edición: 5 minutos Impreso el: 09/03/2005 10:53 Última impresión completa Número de páginas: 24 Número de palabras: 4.143 (aprox.) Número de caracteres: 21.423 (aprox.)

PRÁCTICA 3: Implementación de un ajedrez virtualmgarcia/RVA/P3b.pdf · PRÁCTICA 3:...

Documents

Transcript of PRÁCTICA 3: Implementación de un ajedrez virtualmgarcia/RVA/P3b.pdf · PRÁCTICA 3:...