BLADE:: 3D (v 0.1) by R3D.
Con el tiempo, se han ido haciendo niveles, texturas y demás utilidades para Blade:Edge of
Darkness. Sin embargo todo el aspecto de la introducción de objetos nuevos, personajes
y animaciones en el engine era bastante difuso. Esta guía intentara suplir esto.
Pasemos a ver las utilidades/plugins que venian indicadas para estos aspectos en el Blade SDK.
Nos encontramos con 3 plugins:
- bldexp.dle
Este plugin permite exportar objetos, personajes y animaciones al formato de la engine.
- Camera.dle
Este plugin se usa para exportar animaciones de cámara al formato de la engine.
- MBWImporter.dli
Este plugin permite importar un mapa en formato .bmw de la engine al 3DSMAX, para
usar como referencia en la animación de cámaras, actores, etc.
Además se nos indica que debemos acompañar estos plugins con el archivo MSVCRTD.DLL al
directorio de instalación del 3DStudioMAX 2.x. Y sabemos por experiencia, que los plugins
de este soft no sirven de una versión a la siguiente, con lo que todas las preguntas de
los foros intentando meter los plugins en versiones anteriores o posteriores son inutiles.
Bien, con nuestra copia del Max 2.5 en nuestro caso, procedemos a copiar esos 3 ficheros al
directorio plugins de este, y el MSVCRTD.DLL al raiz. Arrancamos el programa, y buscamos la
disposición de los plugins. Sabemos que las extensiones .dle son referidas a plugins de
exportación, y que las .dli a los de importación. Así, nos vamos a File/Import y a
File/Export para ver si todo esta correcto.
En File/Import nos encontramos con el formato Blade World .MBW. Parece todo correcto, y nos dirigimos a File/Export. Cual sera la sorpresa al ver que por mucho que movamos la vista en el desplegable, solo aparecera un nuevo formato de fichero Camera .CAM. Falta la exportación de objetos y animaciones (el bldexp.dle).
Tras comprobar nuestra factura del programa de Discreet, es evidente que el fallo no es de nuestro
Max. Pensamos en el MSVCRTD.DLL. Parece que falta algún archivo. Al tiempo, descubrimos que
asi es.
En concreto faltan dos archivos, que nunca fueron emitidos en el SDK del Blade. Se
trata de estos ficheros: PYTHON15.DLL BBLibc.dll BUIxc.dll y Raster.dll, los cuales vienen
incluidos en esta guía (los de la versión del juego no pueden funcionar). Copiamos cruzando
los dedos estos archivos al raiz, y arrancamos nuestro preciado programa. Comprobamos que
estabamos en lo cierto:
Encontramos Blade Animation File *.BMV que se encarga de las animaciones, y Blade File *.BOD que exporta objetos. Funcionando los plugins, aprendamos como funcionan.
A la hora de exportar cualquier modelo 3D desde el Max al Blade será necesario mantener una nomenclatura interna tanto para personajes como para objetos,escudos... La estructura interna de los distintos modelos es:
* Modelado del objeto:
Un objeto puede tener el nº de caras que creamos oportuno, un canal de mapeado UV, y los grupos de suavizado y ID de subobjecto que creamos oportuno. En cuanto a la escala del objeto, para facilitar la tarea se expone un metro cúbico extraido del museo de.. RAS en el fichero metrocubico.max.
Una vez realizado el modelo, en el que sus texturas apuntan a ficheros .bmp que luego seran introducidos con las utilidades del sdk en .mmp, pasamos a las formalidades.
OBJETOS GENÉRICOS
No pueden ser cogidos por el personaje aunque este los vea. Para conseguir que nuestra malla se comporte de esta forma, solo tenemos que incluirlo en un grupo (Group/group) llamado Blade_Object_NombreDelObjeto.
En NombreDelObjeto servira para que "La engine" hagá referencia a él por este, en este caso NombreDelObjeto.
Posteriormente (no hace falta que el grupo este seleccionado) File/Export-Blade File, e introducimos el nombre del Bod, que no tiene porque ser el mismo que el del grupo que incluye el objeto.
ARMAS
Una vez terminado el mallado de nuestra arma, debemos de tener en cuenta varios aspectos, para que funcione como tal. El primero es que un arma solo funcionara como tal realmente cuando este definida como tal por script. Además, es necesaria la introducción de algunos indicadores para su uso. Estos son los siguientes
-Anclajes:
Deben existir anclajes relativos a la mano derecha, izquierda y espalda del personaje que manipulará el objeto una vez que lo haya cogido. Estos anclajes no son mas que cajas, de los que el exportador extrae el centro de esta, y su orientación. OJO, hay que tener cuidado no sólo con su posición sino también con su orientación. Además existe otro anclaje que determinará el posicionamiento del arma en el interface de juego (inventario)
Estos Anclajes se deben de llamar, respectivamente, de esta manera:
Blade_Anchor_1H_R :Mano Derecha
Blade_Anchor_1H_L :Mano Izquierda
Blade_Anchor_2H :A dos Manos
Blade_Anchor_Inv :Posición en el inventorio
Blade_Anchor_Back :Posición en la que se basara "la engine" para guardar el arma en la espalda
-Filos:
Son necesarios para calcular las zonas de colisión del objeto cuando se realice un golpe con él. Pueden ser de tres tipos, cortantes (filo de espada), empalantes (pinchos o punta de espada) y contundentes (martillo, garrote).
Los filos cortantes se definen como un prisma de sección triangular. Deben llamarse Blade_Edge_N, donde N es un número que permitirá a la engine referenciarlo. La longitud del prisma dará la longitud del filo “virtual” del arma y la dirección de corte nos la dará el ángulo más agudo de la sección triangular del prisma.
De todo esto deducimos que un arma sólo corta por las zonas determinadas por los filos y en la dirección en la que están orientados los filos, es decir, una espada que debiera cortar por ambos lados de la hoja debería llevar dos filos opuestos en dirección.
El segundo tipo de filos son los que realizan daño empalante, y se definen de forma similar a
los anteriormente descritos, con la salvedad de que se representan como una pirámide de sección cuadrada. Sólo hacen daño en la dirección del “pincho”, o sea, en la dirección que une la normal interior de la base de la pirámidecon el vértice opuesto. Su nombre es Blade_Spike_N.
Por último están los filos contundentes. Estos se definen igual que los filos cortantes, se llaman también Blade_Edge_N y su longitud determina la zona contundente de un arma. En este caso la dirección del golpe no tiene importancia ya que estos filos realizan daño contundente en 360 grados alrededor de la arista que identifica el filo (la mas aguda de nuevo).
Para diferenciar un objeto que haga daño contundente de uno cortante, debe de añadirse un anclaje similar al de los personajes, es decir una caja con el nombre Blade_Anchor_Crush y que hará que todos los filos de un arma sean considerados contundentes.
Un detalle a destacar, es que las armas que realicen daño contundente no producen mutilaciones cuando provocan la muerte de un enemigo.
Destacamos también, que un Arma NO puede tener filos cortantes y contundentes al mismo tiempo, SÍ puede sin embargo tener filos cortantes y empalantes a la vez.
-Estelas:
Las estelas que producen las armas las definimos como grupos de dos vértices que trazan una línea "virtual" desde la que se dibujará la estela que deja el arma al realizar golpes con ella.
A estos objetos de 2 vértices (sin cara, evidentemente) los llamamos de la forma Blade_Trail_N , donde N (de 1 en adelante) indica el grupo de vertice de la estela.
Las armas pueden tener tantos filos y estelas como se quiera, pero tenemos que tener en cuenta, que cuantos más tenga más cálculos habrá realizar a la hora de procesar ese arma.
Una vez procesadas estas estructuras,y agrupadas junto con la malla en el grupo del Objeto, un arma del tipo Espada, podria quedar de la siguiente forma:
Y, de forma más detallada...
Y de forma detallada los pivotes de los objetos, que afectan de forma al buen funcionamiento
del arma. Deberian mantener una orientación muy similar a esta, de lo contrario no se puede asegurar
el comportamiento correcto del arma.
ESCUDOS
Una vez terminado el mallado de nuestro escudo, debemos de tener en cuenta varios aspectos, para que funcione como tal. Son necesarios la introducción de algunos indicadores para su uso, como en las armas.
Resaltar como en el caso de las armas, la importancia no solo de su posición, sino de la orientación de estos Estos son los siguientes:
Blade_Anchor_1H_R :Mano Derecha
Blade_Anchor_1H_L :Mano Izquierda
Blade_Anchor_2H : Dos Manos (¿escudo de dos manos?)
Blade_Anchor_Inv :Posición en el inventorio
Blade_Anchor_Shield :Indica a la engine cómo tiene que colocar el escudo en el antebrazo izquierdo del personaje cuando este lo active
Blade_Anchor_Back :Posición en la que se basara "la engine" para guardar el escudo en la espalda
Una vez procesadas estas estructuras, y agrupadas junto con la malla en el grupo del Objeto, un escudo típico, podría quedar de la siguiente forma:
De forma más detallada los anclajes...
Y la orientación por ultimo de los pivotes de estos anclajes...
FUENTES DE LUZ
Lámparas, antorchas y demás objetos que son emisores de luz y partículas tienen tener asociada internamente una estructura determinada construida en torno a una luz de tipo Omni. A esta luz se linka un objeto llamado B_Fire_Fuego que en la engine será invisible, y de cuyos vértices serán emitidas partículas de fuego (rojas y todo eso..).
Una antorcha común, ya agrupada adecuadamente, quedaría de la siguiente manera:
Bien, concluidos los objetos, voy a pasar por comentar un poco el resto de plugins, antes de entrar de lleno en el aspecto más complejo en la exportación del engine, los personajes y animaciones.
Como nota final, comentar que el proceso de exportación del objeto,arma etc... ni siquiera nos dará las gracias.
Si hemos realizado algo mal, el juego se encargará de avisarnos en la forma de cuelgue o comportamiento inesperado
* Mundos imposibles y cámaras:
Por fortuna, este aspecto de la exportación es muy sencillo. Nuestra meta es conseguir animar una trayectoria de cámara con todas las herramientas que dispone Max (olvidandonos de los engorrosos scripts de python), y exportar la cámara. Claro que, mover la cámara a ciegas es un tanto ridiculo.
Por eso, aparece una utilidad intermedia que se encargará de mostrarnos en vivo y en directo el mapa que hayamos creado en LED, con objetos inclusive. A partir de este mundo, no será nada dificil exportar la camára ya animada. El plugin que nos importa el mundo nos lo encontramos en File/Import Blade World .MBW.
Hmm, el formato MBW no parece nada conocido por el LED o el Blade. Para conseguir transformar el mapa realizado a ese MBW habrá que realizar lo siguiente:
Ejecutar Blade en modo consola (Blade -console)
Cargar el mapa
En la consola poner: Bladex.ExportWorld('masklin.mbw')
En el directorio del mapa se exportara con el nombre que le hayas dado el .mbw, en este caso masklin.mbw
File/Import:masklin.mbw y sale algo asi O_o
La tarea de mover la cámara por el paraje solo se puede resolver con un poquitin de paciencia. Minutos u horas después, cuando hayas terminado el movimiento, solo tienes que seleccionar la cámara y File/Export:Camera(nombrearchivo).
En principio, el movimiento de la cámara se samplea, por lo tanto puedes utilizar cualquier cosa para animar esta, y cualquier controlador (como noise, waveform y los que se te puedan imaginar). Pero, como en todas las herramientas de Ras, Cuidado!
* Personajes,Enemigos y Animaciones:
El aspecto más interesante y mas complejo tal vez. Intentaré ser conciso y breve.
Un personaje, en Blade, no consta solo de una malla, sino que son 3 las que definen sus propiedades/capacidades. Estas 3 mallas o grupos (en los que seran incorporadas) forman a su vez otro grupo llamado Blade_Object_NombreDelPersonaje, similar a la estructura de un objeto convencional.
Veamos, que son estas 3 mallas o grupos, concentrando nuestro esfuerzo en el Bárbaro:
Los nombres de estos grupos, vienen indicados en amarillo. Por su nombre ya nos indican ciertas cosas. Vamos a recorrerlos en orden inverso al mostrado, de más facil a ... más dificil.
BLADE_SKIN:: Grupo de plantilla-base y de zonas de heridas.
Este grupo es NECESARIO para que el exportador funcione correctamente. Se encarga de indicar a "la engine" la constitución base de nuestro personaje (volumen y coordenadas de mapeo) e indica mediante los grupos de suavizado qué caras pertenecen a la misma zona de herida (serán caras que tengan el mismo "smoothing group" asignado).
Cuando un arma impacte en cualquier polígono del personaje, se comprobará el smoothing group al que este pertenece y se realizará en consecuencia un cambio de textura (sustituyendo la actual por la versión de textura con heridas que previamente habremos preparado) simultáneo para todos los polígonos del modelo que compartan smoothing group con el polígono golpeado.
Es evidente que hay tenemos que ser un poco coherentes a la hora de asignar estos grupos para que no queden caras aisladas, o sin asignar a un grupo y para que estos smothing groups mantengan una correspondencia física con la forma de la herida a la que hacen referencia.
Si todas las caras del modelo pertenecen al mismo smoothing group, en el momento de recibir el primer impacto de arma todo el modelo adoptará la textura con heridas por completo en lugar de ir apareciendo conforme recibe golpes.
Si no se definimos ninguna textura de heridas, no se producirá ningún cambio al recibir golpes. La textura de daños (wound) no se define en el editor de materiales. En principio asumo que "la engine" busca un .bmp dentro del .mmp con el nombre de la textura de la forma BARNF_W.bmp, donde:
BARN= Bárbaro
F= Textura Frontal
W= Wounded (Herido)
De no ser así, el fichero de daños sera indicado mediante script phyton. Cosa facil, seguramente.
En el caso del Bárbaro, estos son los distintos grupos de suavizado que hemos asignado:
BLADE_MUTILATIONS:: Grupo de mutilaciones
Cada vez que un personaje o enemigo muere, si tenemos el Gore activado, suele sufrir una mutilación visible de parte o varias partes de su cuerpo. Estas mutilaciones vienen indicadas por este grupo, que NO ES NECESARIO incluir a la hora de hacer un personaje o enemigo.
En el caso de no existir este grupo, el enemigo o personaje simplemente morira
"tranquilamente". De decidir insertar mutilaciones, debemos considerar varios aspectos de esta:
En este grupo se indican de forma similar a las heridas del anterior Blade_Skin, la distribución de caras para determinar las mutilaciones en caso de que un golpe en combate al personaje ocasione su muerte. Estas caras están organizadas según los grupos de suavizado a los que pertenecen.
Algunas caras pertenecen a varios grupos simultáneamente, esto es así cuando dichas caras pueden separarse del modelo original en varias posibles mutilaciones, por ejemplo, una mutilacion puede cortar el brazo entero (arrastrandolo todo consigo) o solo la mano.
Para ello, podemos dar al brazo un smothing group de por ejemplo 2, y a la mano de 2 y además otro de 3.
Si nos fijamos en el efecto de mutilación en el juego, nos daremos cuenta de que se ve la herida producida por la sección creada en la mutilación. Este efecto se consige generando una capa extra de caras con la textura de la herida.
Las secciones del cuerpo con la textura del corte permanecen invisibles en el juego hasta que se produce la mutilación adecuada correspondiente. Es entonces cuando esta se queda "al descubierto".
Estas secciones también tienen un smoothing group, que viene dado por su hijo. Además, su numero de vertices debe corresponderse con la sección de la que salen, cosa facilmente realizable, ya que la geometría la realizaremos con una copia del extremo del objeto mutilado.
Y una vista general del grupo:
BLADE_SKELETON::Grupo de animación
El grupo más complejo de todos. Este grupo debe llamarse siempre Blade_Skeleton y es NECESARIO para que el exportador funcione correctamente.
El metodo para la animación que utiliza Blade no se trata de un sistema de deformación por huesos. Basicamente lo que hacemos es definir una jerarquía coherente, y decidir cuales seran las zonas deformables, que se generaran en tiempo de render y que permanecen invisibles en el esqueleto creado.
Mediante este grupo indicamos al engine qué partes del modelo se mantendrán rígidas y qué partes serán flexibles a la hora de recibir las animaciones. Las caras de las distintas piezas de este grupo determinarán las aristas rígidas, mientras que las caras intermedias inexistentes determinarán las aristas flexibles de as articulaciones que permitirán la animación deformable correcta.
Estas piezas deben tener una jerarquía con un orden determinado, un nombre concreto en principio (aunque todas las pruebas realizadas indican que no es primordial), así como ser un número fijo de ellas, si falta o sobra alguna, o si el orden de definición de la jerarquía no es el correcto la animación puede ocasionar efectos indeseables una vez que el modelo esté
en "la engine".
Cuando hablamos de un número concreto de piezas, nos referimos al esqueleto que estemos tratando. Por ejemplo, en Blade la mayoria de personajes y enemigos comparten un esqueleto Bipedo con un nº de piezas X (25 en este caso) determinadas. Gracias a esto, la base de datos de animación puede ser pasada de un modelo a otro, practicamente sin problemas (salvo superposiciones por diferencias de escala/volumen del personaje muy distintas).
Entonces, si lo que queremos es aprovechar toda la base de datos de animación existente, deberemos limitarnos a la jerarquia bipeda (que es la estudiada, aunque la de la araña no sea esta) con su nº de piezas y su orden, que detallaremos en las próximas lineas. Porque en cuanto añadamos un nudo más, como por ejemplo un tercer brazo que sale del pecho, estas animaciones seran inservibles, y habrá que realizarlas enteramente, algo costoso para el ciudadano de calle.
La jerarquia se puede ver claramante en el siguiente gráfico
Además, junto con el esqueleto se incluyen una serie de objetos extras "linkados" (porque en realidad lo estan) a él, que realizan diferentes funciones, descritas a continuación:
-Anclajes:
Son cubos con el nombre Blade_Anchor_Nombre.
Estos cubos hacen referencia sólo al centro geométrico del cubo y a su orientación, como en los anclajes de las armas y los escudos, siendo el resto invisible para "la engine". Se utilizan para posicionar objetos en distintas partes del modelo, como por ejemplo armas, escudos, etc... El nombre es importante para que la engine los identifique.
Son necesarios todos para el correcto funcionamiento, y son estos:
Blade_Anchor_R_Hand :Mano derecha
Blade_Anchor_L_Hand :Mano izquierda
Blade_Anchor_2O ::?
Blade_Anchor_Shield :Anclaje de escudo en el brazo
Blade_Anchor_Back :Anclaje de objetos en la espalda
Blade_Anchor_ViewPoint :Anclaje de la cámara de visión del personaje.
Como anteriormente he comentado, hay que prestar especial atención a la orientación de (como también a la de las piezas que forman la jerarquia del personaje) del pivote de cada uno de estos anclajes, ya que la orientación de las armas, escudos... linkados depende de ella.
A continuación muestro la orientación de la jerarquía y de los anclajes.
-Filos de lucha cuerpo a cuerpo:
Sí, por otro lado están los filos, que al igual que sus correspondientes en las armas, son prismas triangulares situados en los antebrazos, manos, pantorrillas y pies del modelo.
Sólo tiene lógica insertarlos en los personajes jugadores ya que los enemigos no son capaces de luchar sin armas (lucha cuerpo a cuerpo). Deben llamarse Blade_Edge_N
donde N es un número cualquiera para referenciarlo a partir de 1. Su posición y longitud determinará la parte "sólida" del personaje que colisionará con un enemigo u objeto/pared en el caso de que el personaje realice un golpe contra él sin ningún arma en la mano. De estos filos lo que usa "la engine" tan sólo es la arista longitudinal correspondiente al ángulo más agudo del triangulo de sección del prisma. Para que estos filos funcionen como zonas contundentes en lugar de realizar cortes como si fueran cuchillas, es necesario(a igual que en el caso de las armas con filos contundentes) que el modelo cuente con un anclaje extra al que llamaremos de igual manera: Blade_Anchor_Crush y que no se usaba para linkar nada, sino tan sólo como etiqueta para clasificar los filos de daño.
El aspecto general del grupo skeleton queda asi entonces:
Una vez terminados los 3 grupos, lo que tenemos que hacer es ponerlos en una posicion común (0,0,0 es una buena opcion) y agruparlos como se ha dicho en el grupo genéricoBlade_Object_NombreDelPersonaje, Blade_Object_Barbarian_N en el caso de nuestro querido Bárbaro. Y queda esto:
File/Export:Blade File (nombredelarchivo que no tiene que ser el del grupo).
El último tema pendiente es el de la ANIMACIÓN. Para poder exportar una animación lo que haremos sera separar el grupo skeleton y desagrupar la jerarquía que en él está incluida. Hecho esto, podemos borrar todos los anclajes y filos, ya que a los datos de animación no les preocupan estas cosas, solo los nodos(25 recordamos en los bipedos) y su orden correcto.
Básicamente, cada pieza se anima con keys de rotación y/o de posición, en principio sin limite. Es aconsejable usar las cinemáticas inversas aplicadas, para conseguir movimientos más o menos realistas, como el andar, balance, etc...
Sólo tenemos que tener en cuenta un pequeño dato, y se trata de seleccionar el centro de animación(objeto Center), y de crear un grupo solo con el que tenga la forma Blade_AnimRoot_NombreAnimacion por la cual se hara mas tarde referencia desde el script. Si todo fue correctamente, se debería de poder exportar la animación correctamente.
Con esto concluye el apasionante mundo de la exportación en Blade. Con la esperanza de que sirva a alguien...
Notas:
- NO existe ningún importador que permita pasar el formato BOD de objetos del Blade a formato Max.
- NO existe ningún importador que permita pasar animaciones con el formato BMV de Blade a formato Max.
- NO debe de haber más de un objeto en un mismo archivo de Max o el exportador de BOD puede dar problemas.
- Es bastante probable que haya errores e incoherencias en algunas cosas dichas. Esta información esta recogida a base de pruebas y de un primer impulso de RAS. Gracias
- La buena o mala elección de las partes rigidas y deformables del personaje/enemigo determinara en gran medida la calidad visual a la hora de ser aplicado un fichero de animación al personaje.
Es recomendable que las secciones "guía" que forman parte de las 25 piezas de un bipedo standard de Blade tengan el mismo nº de vertices que sus hijos, pero por las pruebas realizadas no es imprescindible.
Quizás uno se anime a escribir algo más avanzado sobre este par de aspectos, ya que
requerirían un tutorial de por si.
Guía compilada por R3D
Para cualquier duda r3d@wol.es
