Estoy totalmente deacuerdo con Ryuchan. En la experiencia que llevo dentro de esta asociación, concretamente con los comentarios en el IRC el 99% está haciendo un motor de los cuales creo que 0,01% ha hecho algo de un juego. Generalmente los motores se suelen hacer depsues de aprender ap rogramar alguna API y tienes ganas de "juntar" todo lo que has aprendido para poder ver un funcionamiento conjunto y hacer pruebecillas. Otros los hacen porque no tienen suficiente dinero para comprar un motor comercial. Pero evidentemente a parte de cada desarrollo de cada motor creo que estamos todos concientes de que ninguno alcanzará un rendimiento comparable a motores comerciales de la talla de la gente de IDSoftware por ejemplo.
  Y sino porque salen tan pocos juegos de Stratos? pues eso porque todo el mundo hace motores y no juegos. Y eso de que un motor es el 90% de un juego... :riendo:   Yo opino que el motor y el resto del juego pueden estar en el mejor de los casos del motor en un 50%, un juego no es solo gráficos, ni solo IA, ni solo Sonido, es una integración grandisima de muchos factores y mucha planificación. Además si fuera un juego el 10% del desarrollo, si pillas un motor como el del Quake 3 por ejemplo que aparte de gráficos tambien te da cobertura multimedia, IA, etc... umm podiamos sacar un juego como digamos Medal of Honor en ... umm 3 Meses?
  Creo que aqui todos pecamos un poco de prepotentes en este sentido. A ver si conseguimos pasar este bache y volvemos a ver un gran número de titulos en Stratos.
  Sinceramente a mi forma de entender el desarrollo de los juegos lo ideal sería coger tener una base minima con la que se pueda trabajar con el motor y ocmenzar a programar el juego y ir desarrollando modulos del motor conforme los necesitamos y no dedicarons exclusivamente al motor y luego al juego porque seguro que vereoms incompatibilidades que podiamos haber subsanado de esta manera.
Pues nada más ahi va mi opinión :ojo:
Un saludo.
                               

                                La verdad que a mi tambien me gustaría ver alguna captura del motorcillo en marcha :riendo: Por que no las subes a alguna web?                                

                                Bueno como llego un poco tarde a este post y ya esta casi todo dicho solo puedo hablar de lo ultimo que se ha puesto (Sobre Ithaqua y Emotion). Estoy totalmente deacuerdo en lo que ha dicho Ithaqua y es verdad que con interpolación se suplen todas esas dificultades que no parecen convenver a Emotion, y como bien dijo lo único que varia es la suavidad con la que se realice. Y sobre lo de el sincronismo de musica, voces, efectos y tal, pues sinceramente tampoco se me ocurre una manera optima de hacerlo sin hacer uso de la interpolación. Solamente miremos a las miles de demos que podemos descargar por ejemplo en http://www.pouet.net y veremos como en la mayoría (vamos las que tengan nivel aceptable) tienen una perfecta sincronización de música, efectos sonoros y gráficos, particulas, etc... y os aseguro que el 99% usa interpolación :lengua:
Un saludo                                

                                Ithaqua si somos mas precisos, sería mas bien que un 1% de la gente hace un motor de algo ya que el otro 99% de la gente no hace absolutamente nada (Vacilar no se considera hacer algo productivo), y ahora si, de ese 1% que hace algo, el 103% hace motores de algo :lengua:.
Por cierto a ver aun estoy liado con el Make Portals que en msdos no me pilla el comando :_( jajja
Saludz                                

                                Emotion:
1. Pues viene a ser el 3 de Dracula :sonriendo:
2. El formato esta en principio totalmente abierto a ese tipo de cambios pero ahora mismo solo puse esos dos porque son los que estoy usando en mis pruebas.
3. No me lo había planteado dado que el formato nacio en principio para una serie de proyectos que tenia en mente y que no necesitaban esos efectos pero como dije anteriormente todo sea que alguien lo necesite como para que se cambie :sonriendo:
4. Sobre los demas tipos de objetos, como bien dices en el pdf solo ves unos cuantos, en concreto Geometría, Geometría interna, Cámaras y Luces, los demas aun no los he puesto en el formato porque no están testeados lo suficiente ni tampoco he trabajado en el formato para que sea lo más standar posible.
5. El crear la bsphere se podría hacer tambien como tu bien dices en tiempo de exportación pero eso lo hago yo en tiempo de importación ahora mismo porque no sabia si todo el mundo lo usaría, aunque en proximas versiones pondré una opción de "Exportar datos de colision" que pueda hacer esto. Sobre lo de las mallas de colision si que se soportan aunque no estan reflejadas en el formato del objeto puesto que el enlace sale de la malla de colision y no del nodo que la contiene. Este objeto es un "Dummie" que se puede definir con las utilidades que he programado para el MAX y basicamente es una malla apuntando al nodo que colisiona.
Como he dicho antes en varias ocasiones, esta versión es muy beta de hecho ahora mismo era para test internos por lo que aún está abierta a muchos cambios, sobre todo de cara a exportar características especiales para juegos ya que ahora mismo es mas bien como un exportardor normal de geometría general. Gracias a Dracula y Emotion por vuestros comentarios y espero que en proximas versiones sigais opinando y dandome consejos sobre los mismos.
Muchas thanks :sonriendo:
                               

                                Dracula:
1. Si se controlan las jerarquías, como puedes ver en el formato cada nodo tiene un enlace al padre en el que se indica su nombre y posteriormente indicamos el número de hijos que tiene y los nombres de los mismos. Cuando importes del formato, haces un enlace en base a esos parametros.
2. Sobre los vértices, caras y demás he estructurado esto así porque como sabrás en MAX hay una serie de inconvenientes con las UV y los vértices que no siempre vienen dados en el mismo número y esta es de las formas mas optimas que he visto para almacenar y poder usar todos los formatos de UVW Mapping que soporta el max. Luego lo de los demas valores como los CVertexs, hay mucha gente que los usa y me parecio interesante exportarlos además de que no me suponia ningun trabajo adicional. Luego por ultimo en las caras, los valores de smGroup son muy importantes ya que definen el suavizado del objeto y tambien debia importarlos junto con los Edge of visibility por si alguien quería usarlos.
3. Lo de mas de un material hasta ahora lo que tengo hecho es coger y leer un material (Que no una textura) pero que pueda contener diferentes submateriales y el indice de cada submaterial por cara está indicado cuando se lee la cara ABCM El M es el indice del material. Aunque este tema está aun muy general y mas adelante lo cambiaré.

                               

                                Bueno como ya sabeis estaba desarrollando un motor 3D, al igual que el 99% de la peña que pasa por aqui :lengua: y como dije en otro foro estaba liado con un plugin que en principio nacio para ser usado unicamente con el motor K3D aunque he pensado que tambien podría servir para exportar al formato nativo y que otros programadores pudieran usarlo en sus propios proyectos ya que da todas las características que puede dar el ASE junto con algunas adicionales y sin tener ese tamaño tan horrendo :lengua:  La razón de este post es que he subido un PDF con la versión actual del formato, por si alguien quiere echarle un vistazo y comentarme algo para cambiar en proximas revisiones.
Una captura del plugin en acción es:
http://usuarios.tripod.es/andromeda_studio...arga/plugin.jpg

y el formato:
http://usuarios.tripod.es/andromeda_studio...carga/K3DFF.pdf

(Perdonad por el formato del PDF pero lo hice así para ser mas facil para la impresión y que no ocupara tantas páginas, pondré posteriormente una versión mas legible :lengua:)

Un saludo :lengua:                                

                                Sobre lo del exporter, pues si la verdad que los .ASE son una cagada por su tamaño, y además tienen muchas limitaciones al exportar. Yo ahora mismo estoy desarrollando un plugin para mi motor 3D que tenia pensado poner publico en breve (Tanto el motor como el plugin :lengua:) El plugin lo puedes hacer mirandote del MAX SDK. De todas formas si lo que buscas es no pringarte y   tener un formato pequeño, pues puedes coger el que genera mi plugin xq lo he hecho expresamente para ese fin. A parte tiene características adicionales q no soporta el ASE. Algunas de las carac terísticas que tiene son: Soporta Bones (Skin de modelos), animaciones tanto de keys como de samples, con interpolaciones lineales, bezier y TCB (Todas las del MAX), diferencia entre geometría de escena (BSP/Octrees) y normal, y no se algunas mas :lengua:
ah y una capturilla: http://usuarios.tripod.es/andromeda_studio...arga/plugin.jpg

Byez.                                

                                Lo que tienes que hacer es coger y seguir usando quaterniones pero en lugar de usar la función de QuaternionToAxisAngle()y usar esto con glRotate, implementar otra función (O pastearla de x ejemplo magicsoftware.com) del estilo QuaternionToMatrix() y luego cargar esa matrix con glLoadMatrix o glMultMatrix en su defecto :sonriendo: Y funciona muy bien :sonriendo:                                

                                Solo quería comentarte que si vas a usar los quaterniones en tu código supongo que será evidentemente para usar las características que no te dan la representación habitual de rotaciones usando angulos de Euler. Como ha dicho B3RS3RK3R una de las más llamativas e interesantes es la posibilidad de interpolar aunque no solamente se puede interpolar linearmente (Como el caso de SLERP). Pero sin duda otro de los usos que más lleva a implementar quaterniones es como sabrás el problema del gimbal lock. Te comento esto porque si decides usar el código que pasteó B3RS3RK3R que es totalmente correcto :sonriendo:, y pillas del quaternion para pasar a Angulo/Eje para despues usarlo con glRotate, que sepas que seguirás con el problema del gimbal lock :sonriendo:
Un saludo                                

                                Solo quería hacer una aclaración sobre lo de la detección de colisiones. En principio como es evidente si aplicamos Bouding Volumes (Lo más correcto en el 99% de los casos) nos podemos decantar por 3 de los volumenes más usados Esferas, Cubos o elipsoides (O cilindros) Yo he implementados todos los anteriores en el motor y estoy trabajando en un algoritmo que determine que mejor envoltura le conviene a un objeto dependiendo de los vertices que contiene para hacerlo en tiempo de carga. Lo que quería decir es que segun he leido lo que dijo drácula de que la colision ha hacía de segmento a triangulo, pienso que lo hará previa comprobación del BVolume porque sino es algo impracticable en un mundo con un nivel de geometría medio-alto. El método que yo uso es un pseudo  BSegmento-BVolumen. Me explico, si tenemos por ejemplo una esfera y un bbox y queremos detectar la colision entre ambos. No basta con coger y detectar despues de haber movido la esfera, si está dentro del bbox, sino que lo que hay que hacer es algo pare cido a:
NewPosition=OldPosition+Direction*Speed;
If CollisionVolumenSegment(OldPosition,NewPosition,BBox) then
      colisiona();

Es decir, que hay q  tomer el segmento formado por las dos esferas, pero no solament el segmento sino todo el volumen que forma (Una especia de pildora en este caso) que  básicamente y a lo bruto sería detectar la esfera inicial, la esfera final y el cilindro que une  ambos centros y va en la dirección del vector que une sus centros.
 Luego está el tema de las transformaciones de estos volumenes. Siendo una esfera es evidente q es muy rápido pero siendo un bbox no tanto x q tenemos q transformar más vertices, aunque de este tema hay varis public aciones que explican como hacerlo con gran velocidad (Entre ellas el Graphics Gemms III creo).
 Por último como dice B3rS3rK3r hay que detectar la colision a nivel de triangulo aunque tambien hay muchos algoritmos para hacer esto más rápido, el otro día sin ir más lejos se me ocurrio una forma de descartar c aras de un modelo rodeado por un BBox para mi juego y es mirar la normal de la cara del BBox ocn la que colisiona la esfera e ir descartando en base a esta normal y la de la face que estamos re corriendo así solamente recorremos todas las caras, pero sin hacer el test en todas, slamente una simple comprob ación de la normal.
   Si teneis alguna duda más ac erca de colisiones me lo decis porque ahora estoy bas tante liado mirando articulos sobre este tema y a ver si os puedo ayudar para no pegar las ostias q me he pe gado yo en algunas cosas.
  Un saludo :lengua:                                

                                Sobre lo de la carga de ASE en el tutorial que escribí sobre esto, al ser muy básico no toqué los temas de smoothing groups y las coordenadas de textura que se cargaban podian aparecer incorrectas segun el tipo de UVW mapping que se asignara en el MAX. Esto se debe principalmente a que segun el tipo de envoltorio que se use puedes tener un número de coordenadas de textura igual o menor que le número de vértices y si no controlas bien su carga la puedes pifiar. Para hacer una carga correcta de las coordenadas de textura solamente tienes que controlar esto, no hace falta para nada los smoothing groups que como bien dijo Gunder es para determinar el tipo de sombreado de las caras de un objeto. Por ejemplo en una esfera si cada poligono tiene un smoothing group diferentes, el sombreado será "a cuadros" (Per face) pero si todos los v´ertices pertenecen al mismo smoothing groups  el sombreado será per vertex, y tendras que calcular la normal de los vértices para conseguir ese efecto difuminado :sonriendo:
Espero haberos ayudado. De todas formas en mi web subí la clase CAse completa que usaba para mis proyectos (Que está mucho más avanzada que la del tutorial) por si os pue de ayudar más.
http://usuarios.tripod.es/andromeda_studios