K3D Engine

[KILE]

                                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:                                

[Drácula]

                                He mirado un poco tu pdf y tengo tres preguntas:

1.¿Controlas las jerarquías?
2.¿Para que complicarte tanto con los vértices, caras y texturas? ¿No es suficiente con una lista de vértices, otra de índices a los vertices(que forman las caras) y otra con la UV de la textura?
3. ¿Qué hay de los objetos con más de 1 material asociado? El ejemplo del cubo donde cada cara tiene una textura asociada en el mismo material.

Espero ayudarte con el tema..¡y poder importar tu formato!

Por cierto, eso de que el 99% hace un engine..¡ojalá! A ver si se anima la gente y así compartimos conocimientos sobre la experiencia.
                               

[Emotion]

                                Hola KILE,

Pues he estado mirando el .PDF que pusiste como enlace y la verdad es que, bueno... esta muy bien en algunas cosas, pero creo personalmente que faltan algunas cosas, como por ejemplo:

1. como relacionas varios materiales simultaneamente?
2. los tipos de material no estan mal, pero podrias definir materiales (o en este caso texturas) para bumpmaps, mascara de transparencia, etc.
3. la camara me ha gustado, aunque estaria mucho mejor si pudieras definir la apertura de la lente o los milimetros de esta, ya que asi podrias crear, por ejemplo, lentes con efecto de ojo de pez o de buey, y ademas, ayudaria a poder incluso separar los efectos especiales de imagen en efectos por lente o efectos de camara, objeto, etc.
4. a lo mejor lei mal (creo que es lo mas probable), pero empezabas a definir caracteristicas para objetos, luces, camaras, formas (shapes) y dummies (o helpers), sin embargo no he encontrado en el texto mencion a los dos ultimos...
5. lo de BBox supongo que te refieres a utilizar bounding boxes para la deteccion de colisiones, no?, pero no hay soporte de BSpheres ni das la oportunidad de definir una malla especifica para detectar colisiones a nivel complejo

Aparte de eso, me ha gustado mucho tu definicion, aunque para mi gusto le faltan muchas cosas, pero eso si... lo de los quaternions, genial :sonriendo: eso si que me ha gustado... en cuanto a lo del TCB, tambien ha estado muy bien, me recuerda a mis viejos tiempos con el 3DS4 de DOS... :triste:

Un Saludo

_________________
Julio Meca
ALPHA SOFTWARE

[ Este Mensaje fue editado por: Emotion el 2002-04-16 17:32 ]                                

[KILE]

                                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é.

                               

[KILE]

                                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:
                               

[Ithaqua]

                                KILE: Yo aún iría mas lejos: El 103% de la gente esta haciendo un engine de cualquier_cosa :lengua:

Yo mientras tanto voy a seguir con mi engine de detección de pulsaciones de la tecla J.

Saludos.

                               

[KILE]

                                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                                

[ethernet]

                                Si, el 99% no hace nada, del 1% q hace algo el 99% de estos se les obvia y de ese 1% q hace algo y ademas no se le obvia, estan demasiado ocupados presumiendo de lo bien q trabajara su motor cuando saquen el codigo del quake3, o de q a su proxima party llevaran un pedazo de intro alucinante( tipico codigo asqueroso, con mas malloc's q free's e inservible)
Perdon por el OT.
Saludos
PD: voy a mandar un email a farbrausch a ver pillan mis printf's("hola mundo");

[ Este Mensaje fue editado por: ethernet el 2002-04-22 02:55 ]                                

[Ithaqua]

                                Mi no entender

                               

[ethernet]

                                creo q esta bien claro no? pse
saludos                                

[Emotion]

                                Para ethernet:

No estoy deacuerdo contigo. Es cierto que mucha gente intenta hacer algo, pero solo unos pocos lo consiguen... aunque siendo objetivos, mas que el 1% y siendo realistas pues yo creo que un 15% de la gente esta metida en algo serio, los demas miran los post e intentan sacar algo en claro...

Y por cierto, eso que tu dices de las intros no es cierto ni mucho menos. Tal vez eso era asi en los tiempos donde las demos entraban a concurso en modalidades de 4k y 64k, pero solian estar hechas en ASM, asi que de malloc y free, nada de nada... Eso si, he visto mas de una demo hecha en OpenGL en 64k y... si, alguna que otra desperdicia recursos, pero voy a decirte algo: muchas de las tecnicas actuales de optimizacion de recursos, trucos para generacion rapida de texturas u objetos y alguna que otra cosa mas han salido casi siempre de la demoscene, asi que decir la tipica demo con codigo asqueroso me parece ir un poco lejos, pero bueno... tan solo es mi opinion. nada mas

Saludos
                               

[Ithaqua]

                                Mas que nada lo decía porque no venía a cuento.

                               

[Emotion]

                                ?? :riendo:                                

[fiero]

                                Hola amigos, yo estoy haciendo un motor 3D.... :riendo:

un saludo                                

[ethernet]

                                Emotion, no decia q todas las demos tengan codigo asqueroso, te lo has tomado demasiado a pecho (el asm sirve para algo?) ;PP.
Ithaqua, respondia precisamente a algo q puso alguien mas arriba ;D