Por cierto, unas imagenes:
http://usuarios.tripod.es/andromeda_studio...rga/imagen1.jpg
http://usuarios.tripod.es/andromeda_studio...rga/imagen2.jpg

Y si alguien tiene ganas de probar y decirme que fps le da tal y como está ahora mismo la cosilla:
http://usuarios.tripod.es/andromeda_studio...rga/k3dtest.zip

Teneis que ejecutar el programa KQ3BSP2KS.exe y meter un .bsp del quake 3 el programa te convierte el fichero a c:escena.ks  Copiais este fichero en el dir de lap rueba y ejecutais K3D.EXE así se os verán con lightmaps, si kereis texturas, descomprimir el directorio textures del .pak del quake3 dentro del directorio de la prueba :lengua:

Un saludo                                

                                Ayer me dio la vena de implementar octrees en el motor para ver como tiraba con geometría grande. Como habreis visto hace unos dias postee unas imagenes renderizando niveles del quake3. TAl y como abro la escena de estos niveles digamos que hay tantas mallas como materiales, por lo que le pasas (en el caso de opengl):
for (nummallas)
  UpdateMaterial(i)
glDrawElements(ArraydeMalla)

Y renderiza la mar de bien y hace exactamente los cambios mínimos puesto q no repites textura por malla.
Pues eso que me puse a implementar el octree, basicamente iba almacenando en cada hoja los indices de las caras que pertenecian a esas hoja y al fnial de general todo el octree creaba en cada hoja un paquetillo (display list) de la geomet´ria que había en esa hoja. Luego a la hoar de renderizar pues recorria recursivamente el arbol y tal e iba llamando a las display list de cada nodo. Claro está que este método no ordenaba por materiales y al final... menos FPS que con el método inicial. Pensé que seríap orque enviaba paquetillos más pequeños y hacia mas cambios de estado que en el primer método :_(
Total que he estado pensando si sería mas ventajoso en lugar de crear las display list de cada nodo, tener la geometría de cada nodo transformada (Por software, en lugar de cargar la matriz, es decir si traslada dos unidades, en lugar de multiplicar por la matriz, mueves todos los vertices dos unidades) y al tenerla así cuando renderizamos un nodo buscamos todos los subnodos visibles y creamos una lista con la geometría ya transfoormada. De manera que podriamos tener:
KFaces *Faces[NUMMATERIALES]
y en cada array vamos metiendo las caras segun el material al que pertenezcan y al final solo tenemos que
for NumMtariales
  LanzarRender(Faces)

Es que este método de cara a renderizar es videntemente lo más rápido, pero no se yo lo de transformación por software como se lo come, el T&L está pra algo X'D

Alguna sugerencia? :ojo:


                               

                                LOOVER: Habias dicho que cargas los .bsp tambien, como renderizas tu las superficies curvas?                                

                                LOOVER: El .zip no me rula, me lo descarga pero me dice que no puede abrirlo O.o                                

                                LOOVER: El .zip no me rula, me lo descarga pero me dice que no puede abrirlo O.o                                

                                Mecagonlaputa!! X'DDD
http://k3d.sourceforge.net/ :__(
aunque drácula, tu tampoco te libras: http://www.merlin3d.com/

Habrá que ir pensando en cambiar el nombre X'DDD

Un saludillo
                               

                                Bueno aunque ya empiezan los agobios con los examenes uno siempre se puede relajar un poquillo programando :sonriendo: por eso el otro dia me decidí a crear un cargador de niveles BSP del quake 3. Al principio cree una clase específica dentro del motor para albergar este tipo de fichero pero luego pensé que podría ser mucho más ultil crear un conversor BSP->Ks (El formato de mi fichero de escena) y así lo hice. De tal modo que ahora mismo tengo el BSP2KS.exe que le metes un fichero bsp y te genera un .KS (Con un formato parecido al que pudisteis ver en la versión 0.1 que subi a mi web, aunque ya va por la 0.4 ;P y entre otras cosas alberga los lightmaps en su interior). La gracia de esto radica en que si alguien está interesado en usar el formato BSP en su motor no tiene porque usar mi motor si no que puede coger mi exportador/importador y hacer Bsp->Ks->Importador->3D Studio MAX :ojo:
Pues nada ahi os dejo las imagenes que he hecho (Están al final de la página de proyectos/K3D):
http://usuarios.tripod.es/andromeda_studios

concretamente
http://usuarios.tripod.es/andromeda_studio...oyectos/K3D.HTM

En algunas imagenes podreis ver Q3_CurveX es para que se aprecie el detalle de las curvas que si bien ahora mismo soy un poco menso y los paso a triangulos (Aun no he currado lo suficiente con renderización de superficies curvas :ojo: ) pero vamos que da el resultado bastante bueno.

Sobre el motor en si ya os pondré dentro de poco mas noticias porque ahora mismo estoy liado con la demo que vamos a prensentar en la Euskal 10, para cuando lo termine (A mediados de julio) supongo que el motor estará lo suficientemente robusto como para que se pueda usar.
Mucha gente me ha preguntado que porque no he sacado ya versiones Beta para que la gente intente hacer algo con ellas y les he respondido con un rotundo NO, porque me parece una locura sacar un motor que lleves con el tan poco tiempo y esté tan básico que seguramente cuando lo vayas avanzando cambien tantas cosas que lo unico que hagas sea enredar a la gente que lo use. Así que nada :ojo:

Pues eso un saludillo y espero que os gusten las capturas

PD: Emotion where are you?








                               

                                Una preguntilla :sonriendo:, el motor que estas haciendo lo estas haciendo desde 0 o se supone que es un MOD para el quake? Y si lo estas haciendo desde 0, veo que vas camino de montar un motor con las features del quake 2 mas o menos no?
Solo por curiosidad X'D

Un saludo                                

                                JEJE, x cierto la web es: http://usuarios.tripod.es/andromeda_studios :lengua:                                

                                Hi
Bueno hace unos dias ley un post sobre programación grafica en Linux y como hacía tiempo que tenia pensado subir unos artículos de este tema que escribí para la Solo Programadores Linux pues me decidí ayer por la noche a subirlos (Aun solo el primero) por si le pueden servir a alguien para empezar en este sistema.
  Debo comentar que he quitado algunas cosas ya que la mayoría vienen explicadas en los demas tutoriales y tampoco era cosa de repetir definiciones. Inicialmente escribí 4 artículos que van desde la configuración del sistema (Linux, KDevelop y OpenGL), usar SDL para la gestion de eventos e inicialización de video,... carga de superficies  (BMPS) usando SDL, transformaciones geométricas y finalmente carga de modelos desde un fichero.
  Como podeis imaginar estos artículo no son exclusivos de Linux sino que son portables a Windows por lo que podría ser un buen momento para practicar con la lib SDL (Que es batante potente por cierto).
  De todas formas los que quieran programar en Linux, despues de leer los tres primeros artículos en los que se inicializa todo el sistema, se leen texturas sin usar funciones Win32, etc... pueden seguir con la serie de tutoriales inicialmente creada para windows a partir del tutorial de inicialización de OpenGL.
  Pues nada espero que os sirva para algo :ojo:

Un saludo


PD: Tengo problemas al poner el formato de los tutoriales, lo hago en plan bestia pero me gustaría que se me adaptase los margenes al tamaño de la ventana que se abra y además se quedase justificado (En plan los de Nehe) Si alguien me puede ayudar pues le estaría muy agradecido :ojo:                                

                                o_O NO COMMENTS                                

                                -Virtus: "Agradeceria al resto del personal se dejara aconsejar por: Gunder, Ithaqua, Yuio, Una-i y alguno que otro mas"
Totalmente deacuerdo (Tambien te puedes incluir en esa lista tu mismo modestia aparte :ojo: )
-Virtus: "Y es que el motor (a pesar de llevar involucrado mas de 4 años de desarrollo), no lo es todo, ni siquiera un 50%... que digo??? ni un 20%."

Emotion: "pero hasta los maestros se equivocan o pueden no ir siempre por el camino correcto, no? "
   O_o ahhh, ahora resulta que todos los profesionales de españa en cuanto a programación de juegos se referie, vamos de españa y de todo el mundo no han sabido en todos estos años de perfeccionamiento dar el enfoque apropiado al desarrollo de juegos, ahhh... curioso :ojo:
   Bueno y por último sobre lo de que el motor es el 90% del juego y tal, bueno y esto va para Emotion me gustaría que tan seguro está de lo que defiende a pesar de las opiniones vertidas aqui por profesionales de este tema que si verdaderamente está tan seguro de que el motor es el 90% o el 80 o el 70% del juego que porque no pone una pagina web (Si no tienes tiempo y/o conocimientos y/o espacio yo te la hago) y solamente vas poniendo un historial del desarrollo de tu motor y juego. Y vemos desde que has empezado el motor hasta que lo termines y desde que empieces el juego hasta que lo veamos rulando cuanto tiempo tarda. Aceptas la proposicion ? :ojo:

Un saludo                                

                                Bueno vuelvo a hablar, jejej no os asusteis que esta vez no es para tanto.
No voy a volver a hacer ningun incapié en los temas que hemos tratado porque creo que ya ha quedado bastante clara la postura de cada uno, solamente quiero comentarle a Emotion que no es que tenga nada personal contra el solamente pues eso que tenemos diferentes opiniones, y que me parece muy bien que si el se siente cualificado para hacer un motor de esas características pues que adelante y que me alegraré si consigue terminarlo :sonriendo:
  El problema es que, como bien comentó Ithaqua en otro post, aqui viene mucha gente novata, dando sus primeros pasos en la programación o no tan novata pero que tienen características más que sobrantes para hacer un juegecillo en condiciones (No una macroproducción). Y con post como este se les puede confundir y encaminarlos a lo que tu opinas que se debe hacer a la hora de desarrollar un motor, o sea, "HACED UN MOTOR QUE SI LO HACEIS BIEN NO SOLO TENEIS EL 90% DEL JUEGO QUE VAIS A HACER SINO QUE TENEIS EL 90% DE TODOS LOS JUEGOS QUE HAGAIS LUEGO" y no creo que pensando de esa manera llegen a ningun sitio. De ahi mi post intentando plasmar un poco la realidad en este sector desde el punto de vista profesional (Evidentemente no del mio sino de las personas que aludo), para ver si os servia algo de ejemplo.
Pues nada más, creo que con esto se puede dejar por concluido el foro no?
X'DD

Un saludo                                

                                Basicamente lo que tienes que hacer para crear un proyecto híbrido (Con el que si puedes depurar perfectamente) es poner las características de tu proyecto como Debug Multithreaded DLL for Debug y crear una configuración híbrida copiando la configuración del Debug pero poniendo las características de C-Runtime en Release-Mode Multithreaded DLL.

Umm no se si ha quedado claro, sino te ha quedado muy claro te envio si quieres un proyecto en blanco básico para que lo pruebas :ojo:
Un saludo
                               

                                Joder ha creado controversia esto eh?, me tiro unas horas sin verlo y cuando vuelvo ya he perdio el hilo :_(
Quiero decir que estoy totalmente deacuerdo con la opinión mantenida con Ithaqua y Gunder (Que a mi parecer son dos grandes profesionales cada uno en su tema) y quiero dejar claras algunas cosas principalmente a Emotion que si creo que se está llendo un poco por los cerros...
    Sobre mi primer post en el que me respondiste que era una SALVAJADA lo que estaba diciendo de los motores y tal. Bien pues no es ninguna salvajada decir que la gente de stratos no puede competir con los motores (Y estoy hablando de motores que no de juegos) de la talla de ID Software o los del Unreal. Y no es que aqui la gente sea más tonta no, el tema es que aqui la gente generalmente son jovenes, están empezando, a la vez estudian, trabajan y solo se dedican a esto en sus ratos libres. A parte de estos detalles que no son pocos, hay uno muy importante: NO COBRAN por lo que no pueden tener plena dedicación a este "hobby", tampoco estan rodeados por un grupo de profesionales consagrados en programación tan solo nos tenemos los unos a los otros para darnos consejos y por eso no podremos llegar desde aqui a hacer un motor de ese calibre. Así que te invito a ser un poco humilde y darte cuenta de que por mucho empeño que le pongas a tu motor le faltará mucho para llegar a los que ya comentamos, y vuelvo a decir que no es ni mucho menos porque seas tonto :ojo:
   Segundo, que la experiencia en este campo no se aprende solamente mirando todos los papers de los mejores sites de programación de inet, ni papandose libros del estilo de computer graphics, ni tampoco mirando los codigos fuente de los motorcillos que circulan por la red, se aprende programando juegos y sobre todo TRABAJANDO CON UN EQUIPO DE PROFESIONALES. Hace tiempo (y si ya se está haciendo un poco pesado el post) conocí a Yuio (Programador de Pyros, Rebel Act y actualmente Trilobite) el cual me dijo claramente (El que lo ha vivido) que cuando verdaderamente se aprende es estando en una empresa de ese tipo y estando rodeado de profesionales, ahí si notas un aceleron en tus conocimientos. Además, hasta ese momento yo estaba metido en mi motor para hacer un juego, pero solo programaba el motor. El me comentó que en todos los desarrollos que había estado (Conocereis los titulos de dichas empresas) han tenido un motor diferente y para cada uno se desarrollo una base y se fue modificando A LA VEZ QUE SE DESARROLLABA EL JUEGO. Y no al contrario. Vamos que la filosofía desarrollo un megamotor y luego hago un juego en el tiempo que sea es imposible. Y no es imposible (como afirmaba EMOTION) porque no hay ninguna empresa que le haya dado por hacer un mega motor (Que segun el conocimientos hay de sobra) sino porque es impracticable hacer un motor que sirva para todos los tipos de juego. Y porque? porque sencillamente hoy dia lo que se busca es la calidad gráfica, el 3D a toda costa y con muchos efectillos guapos, y para competir en esto solamente se consige de una manera OPTIMIZANDO y es IMPOSIBLE optimizar un motor para que sirva para todos los tipos de juego existentes. Si os sirve tambien de ayuda en este tiempo tambien me he preocupado de hablar con otra gente que considero muy importantes y a imitar dentro de lo que a programación de juegos en españa se refiere. Por ejemplo a Jare (Iguana y actualemente Jefe de Programación del Praetorians-PyroStudios) el cual no ha dejado de decirme insistentemente que me deje de hacer motores y haga algo que se vea, una demo, un juego algo que no sea un motor. O por otro lado una-i (Programador del motor gráfico del Commandos y actualmente jefe de tecnología de trilobite) que no ha hecho más que reforzar los comentarios de Yuio.
    Con esto os quiero animar a que dejeis de meter supercaracterísticas a vuestro Mega[PonAquiTuNombre]3D Engine y os dediqueis con lo que ya teneis hecho a hacer un juego e ir modificando el motor conforme hagais el juego. Yo he adoptado esta forma de hacer las cosas y todo se me ha vuelto más facil, rápido y cómodo... y si encuentra algo mejor le devolvemos el dinero ;P

Pues nada por si os sirve de algo :ojo:

Un saludo