Hola, ¿sabe alguien de buenos tutoriales en castellano sobre programacion de engines? Lightmap, BSP, portal, etc. Todos los que he visto estan en ingles.
Gracias, un saludo.
Javier
Puedes mirar en nehe.gamedev.net, son los mejores tutoriales de opengl de la red.
Ops, no habia leido lo de en castellano.
Gracias de todas formas :sonriendo:
Si buscas algo REALMENTE bueno, debes buscarlo en ingles, ya que es la fuente principal de documentacion. Aun asi, porque no pruebas en 'la web del programador'? no recuerdo la direccion pero por lo que he oido esta bastante completita.
Gracias, ya me lo imaginaba pero por si acaso...
Buscare esa web del programador.
Gracias.
Javier
http://www.lawebdelprogramador.com Aunque creo que hay no hay nada acerca de los BSP y eso. De todas maneras tiene bolsa de trabajo y eso para programadores y esta bastante bien la pagina.
Un saludo.
BSP??? aargh! eso duele... el BSP, a no ser que vayas a hacer un clonico de Quake, no vale para absolutamente nada, ya que con las extensiones de hoy en dia para el vertex streaming, da igual el formato de objeto :sonriendo:
Creo que aunque el BSP/PVS se está dejando atrás (sobre todo porque no permite el dinamismo de por ejemplo un sistema basado en sectores/portales), no es justo decir que no sirve para nada...porque realmente no hay ningún engine con portal rendering que pueda superar en frame rate a un engine basado en un BSP/PVS. Por otra parte un BSP es magnífico para la detección de colisiones por ejemplo. En lo referente al formato de objeto...no lo entiendo bien pero creo que es absolutamnte necesario tener una jerarquización de la escena (un octree, un BSP, sectores...) para el descarte rápido de polígonos y también y muy importante para una rápida detección de colisiones (y supongo que también para la IA).
Y pasando a lo de los tutoriales, en flipcode había (y supongo que seguirá habiendo :ojo:)una serie de tutoriales sobre portal rendering escrito por "The Phantom".
Un saludo
Berserker tu vas a seguir con tus tutoriales que estabas haciendo antes de D3D8 o ya lo dejaste y no volveras?
Y tutoriales pa novatillos en el tema de las 3D sabeis que haya por ahi y que no sean en OGL? es que to los cargadores de modelos de MD* que me encuentro al final siempre son en OGL etc etc :enfadado: .
Un saludo.
[ Este Mensaje fue editado por: Klinex el 2002-03-13 23:27 ]
De momento estoy bastante ocupado con el engine que estoy programando con un colega así que los tutos están aparcados por el momento...pero me gustaría escribir alguno más...a ver si saco tiempo y lo hago. Mi pensamiento ha sido desde hace algún tiempo escribir uno sobre frustum culling..pero ya veremos.
Y bueno, más tutoriales sobre D3D básicos (en inglés) pues puede ser los de
http://nexe.gamedev.net que intentan ser una imitación a los de OpenGL de NeHe. En uno de sus tutoriales me parece recordar que había un cargador de modelos en formato ASCII de milkshape......además ese formato soporta bones así que puede ser un comienzo!
Un saludo.
Oki, muchas gracias BeRSeRKeR :riendo:
Hola Estimados, al igual que la mayoria estoy interesado en videojuegos, tengo experiencia en guiones y demas labores en el cine, y como pasion trabajo en 3d, desde hace 4 años, yo puedo manejar sin problemas la parte grafica, guiones storyboard etc. Ahora falta la programación y aqui van mis preguntas al respecto:
- Que es un engine exactamente ?
- Como se enlaza mi trabajo en 3d y graficos a la programación ?
- El 3d y graficas debe tener que consideraciones para que se pueda programar? es decir cantidad de poligonos etc.
-Cuantos tipos de programación para videojuegos hay (solo para pc) y cual es la recomendable.
- Que lenguaje debe dominar un programador de videojuegos.
- Existe algun software que se utilize para crear juegos en 3d, un tipo de herramienta rad o visual que ayude a reducir la programación.
Estimado BeRSeRKeR, veo que eres una persona muy entendida en el tema y me gustaria si tu y otros pueden responder mis dudas o indicarme links donde puede encontrar pas respuestas. gracias
Mejor que los de Nexe, los de DrunkenHyena:
http://www.drunkenhyena.comEstos SÍ que siguen el estilo de Nehe.
Bye.
PD: Gracias a Grugnorr por recomendarme esta página.
Hi.
- Un engine es un programa, o la seccion de código de un programa que se encarga del renderizado, entrada, sonido, inteligencia artificial, física, red... (no todos los engines controlan estas caracteristicas, no es necesario), de esta forma, se puede estructurar un proyecto en dos secciones, el engine (el trabajo sucio) y la lógica (el juego o el programa en sí).
- Para utilizar los gráficos debes cargarlos en tu programa, mediante la lectura de datos del fichero gráfico, e ir almacenando esa información en el programa.
- Pues segunla potencia, características del programa, y objetivos, los gráficos deben cumplir unos requisitos, como son el número de polígonos, y tambien dependen del hardware, por ejemplo, las imagenes deben tener un tamaño potencia de 2 (32x32, 128x128, 256x1024...) si quieres asegurarte de que funcionará en todos los equipos.
- Pues hay programadores gráficos, de inteligencia artificial, de herramientas, de física... No hay ninguno recomendable, debes elegir el camino que mas te guste (aunque puedes picar un poco de cada, pero, "El que mucho abarca poco aprieta" :ojo:)
- Un programador de videojuegos profesional debe dominar C/C++.
- Se utilizan herramientas de creacion de videojuegos, pero no lo utilizan las grandes empresas del sector, lo suelen utilizar personas en sus comienzos, pero con el tiempo se suele abandonar por el código propio en C++ (pero hay de todo :sonriendo:). Un ejemplo de estas herramientas son RAD, DarkBasic, BlitzBasic....
Espero haberte ayudado.
Un saludo.
[ Este Mensaje fue editado por: NeLo el 2002-03-14 19:08 ]
[ Este Mensaje fue editado por: NeLo el 2002-03-14 19:09 ]
Para Klinex:
Vamos a ver... dices lo de OpenGL como si fuera algun tipo de cancer o enfermedad maligna que siega vidas, pero es que Direct3D es justamente eso: un azote en el pompis, ya que para inicializar cualquier cosa, desde un viewport hasta un objeto o una simple mezcla de texturas, tienes que escribir la biblia en verso, y en OpenGL solo escribes lo que necesitas, ya que OpenGL esta mas orientado al hardware.
Ademas, cualquier juego hecho en OpenGL rebasa a sus homonimos de Direct3D como tropecientasmil veces, y el UNICO engine que ha sabido aprovechar las tristes y flagrantes posibilidades de DX es Max Payne.
Por lo demas, nada mas que decir... aunque una pregunta, solo por curiosidad... has probado alguna vez OpenGL?
Saludos.
Para Berserker:
Bueno, es cierto que el BSP aun sigue dando mucha velocidad de proceso, pero con las nuevas extensiones de hardware para el vertex streaming como el VAR (Vertex Array Range) de las GeForce o simplemente, listas de visualizacion o arrays de vertices entrelazados ya puedes tranquilamente darle mas 'potencia' al codigo y olvidarte un poco de la velocidad, que para eso estan las extensiones.
De esta manera, es mas facil escribir potentes motores graficos con infinidad de efectos, y aun asi, los sistemas de visualizacion no se ven afectados de manera(normalmente con hacer un buen frustum y un backface culling con las normales convenientemente tratatadas) escandalosa.
El problema es que la mayoria de los desarrolladores se limitan a coger el 3D Studio MAX, hacer un modelo 3D y se lo llevan al motor grafico, y ya esta. Pues NO ESTA. Una de las cosas que se deben hacer es corregir TODOS los vectores normales de los objetos y las superficies. De esa manera, el culling por cara opuesta hace MILAGROS y el frustum es bastante util.
Un saludo.
Para Emotion:
Me parece que te equivocas... yo no he dicho que OGL sea una mierda ni na por el estilo (porque si que lo he usado, poco pero lo he usado) lo que pasa que tambien me gustaria aprender a usar Direct3D y me da rabia ver que casi tos los cargadores de MD* son pa OGL. No pretendia iniciar la tipica pelea de OGL vs D3D que ya esta mas que vista ni mucho menos, me gustan los dos y punto, pero ahora quiero aprender tambien de D3D.
No creo ni mucho menos que las BSP actualmente no valgan para nada. Si tienes un escenario minimamente grande tendras que discriminar partes de alguna forma, con BSP, portales o lo que quieras y el BSP es una opcion muy valida, y personalmente de las que mas me gustan.
Si ID sigue haciendo juegos basando su tecnologia en BSP sera por algo.
Y si no ponte un escenario de 100000 poligonos e intenta hacer backface culling ya vereis que bien va.
Salu2
Emotion:
Es cierto que para el tema del render podríamos pasar del tema de la jerarquización y mirar qué objetos, a través de sus bboxes, bspheres o lo que sea están dentro del frustum y una vez que tenemos esos objetos que son visibles (o parcialmente visibles) hacer un backface culling de las faces de dichos objetos...pero aún así, ¿no sería mejor tener una jerarquización de la escena para decartar esos objetos de una forma mucho más rápida?...lo que quiero decir es que teniendo un sistema por ejemplo de portales tenemos que si estamos en un sector en el que hay un portal a través del cual vemos otro sector, si a través de dicho portal no vemos otro portal quiere decir que aunque el nº de sectores que pudiesen haber (cada uno con los objetos que contuviese) fuese de 1000 pues tan sólo recorreremos 2 (el sector en el que estamos y el sector que vemos a través del portal).
Y lo mismo se puede decir para las colisiones...no es lo mismo averiguar si hemos colisionado con 40 objetos que con 1000...supongo que nos ahorraremos unos cuantos cálculos...
Por otro lado creo que si John Carmack se decidiese a programar en Direct3D, haría engines tan rápidos y buenos como si los hiciese en OpenGL...los programas no son más rápidos o buenos porque se utilice una u otra API sino porque el programador que los haya creado se ha preocupado de que así sea.
Yo personalmente utilizo Direct3D (comencé con OpenGL y lo utilicé durante unos 2 años) y la verdad me ahorro toda la problematica de las extensiones y de tener que reprogramar muchas cosas para cada una de las aceleradoras del mercado (o bueno, por lo menos las GeForce y la Radeon). Porque si OpenGL es portable entre plataformas y sistemas no lo es tanto entre aceleradoras (vale, es cierto que si utilizamos un glVertex pues no nos preocupamos...¿pero a donde vamos con un glVertex?...tu mismo has comentado la extensión Vertex Array Range sólo presente en las GeForce de nVidia). No creo que a nadie se le pase por alto que el sistema de extensiones se está convirtiendo en un lio padre...de ahí que se estén presentando las bases para un nuevo OpenGL...OpenGL 2.0
Un saludo
...
Así es la vida del programador querido Lessman :sonriendo:...un aprender sin fin!!
Tranqui Lessman, para cuando OpenGL 2.0 se estandarice tu ya habrás pasado una larga temporadita programando la 1.3 :sonriendo:
Saludos,
Ithaqua.
http://ithaqua.stravaganza.org
Quiero dejar claro que no soy un experto en engines o programación 3D (todos los días se aprende) ni quiero parecerlo...pero no creo que lo que digo esté exento de lógica alguna...y si no, ¿por qué todos los juegos que conozco utilizan un VSD?. Así es en el caso de la serie quake y derivados y Unreal (BSP trees), Blade y el tan esperado (por lo menos para mi :sonriendo:) Doom3 (portal rendering)...y no creo que por utilizar por ejemplo un sistema de portales estés limitando la posibilidad de crear cualquier efecto que se te pase por la cabeza siempre y cuando sea posible en el hardware presente.
También quiero dejar otra cosa clara. No quiero que nadie se ofenda con lo que he dicho sobre OpenGL entre otras cosas porque no he dicho ninguna mentira. La cuestión es que ni quiero ni me apetece entrar en una discusión de este tipo porque como han dicho por ahí arriba eso ya está muy visto y todo lo que digamos será repetir una y otra vez lo que ya hemos leído u oído (muchas cosas de personas que en su vida han utilizado Direct3D y que tan sólo se guían por aquel famosísimo plan de Carmack sobre DX3 o 5, no recuerdo...y la verdad, las cosas han cambiado mucho desde aquel entonces). Sólo diré una cosa más sobre el tema...incluso el mismísimo Carmack reconoció la capacidad de la "nueva" versión de Direct3D y no sólo eso sino que además en su último plan también manifestó su disgusto por todo el tema de las extensiones (que si los vertex programs de nVidia no valen en los de ATI y muchas cosas más).
Un saludo
Por cierto, sobre el tema de las extensiones OpenGL, y el lío que es inicializarlas y luego utilizarlas...
Yo ahora mismo utilizo el sistema de extensiones que viene con el NVidia OpenGL SDK, y ciertamente es un ahorro de curro increible. Olvidaros de wglGetProcAddress, de definir a mano constantes, de funcionar con punteros...etc
Vaya, que es como si tuvieras el header de OpenGL 1.3 y pudieras utilizar todo ese API mas las extensiones como funciones, solo que chequeas primero si existen (d3dcaps?).
Hace un par de días apareció una noticia en Stratos con algo parecido, no lo probé pero tenía buena pinta ya que soportaba también extensiones de ATI.
Es cierto que el tema de las extensiones está fragmentando OpenGL bastante, pero vamos, no es ningún suplicio usarlas. Quejicas :sonriendo:
Sobre el tema de vertex array range, etc.
Con OpenGL no hay nada mejor que las display lists, y siempre seguirá siendo lo mejor ya que es decirle al driver "toma esta geometría y guárdala de tal forma que la proceses lo mas rápido posible". Cada driver optimizará ese proceso según el hardware, y siempre de la forma mas rápida.
¿Que no vale para geometría dinámica? no, es cierto que no vale, pero la proporción geometría estática/dinámica en una escena es abismal. Aparte de que glDrawElements ya de por sí es rápido, y la extensión de compiled vertex arrays la soportan todas las tarjetas ahora.
Y en el caso de que aún no estés contento, te curras 2 o 3 implementaciones distintas de geometría dinámica con las extensiones mayoritarias y listo. Y si es un lío es porque no tienes bien estructurado el código, pero eso no es problema de OpenGL :ojo:
Joer, vaya charla... lo dejo aquí :sonriendo:
Saludos,
Ithaqua
http://ithaqua.stravaganza.org
Ithaqua
Reconozco que hace ya algún tiempo que dejé de utilizar OpenGL y está claro que vosotros (los que lo utilizáis a diario) y no yo sois los que podéis hablar con conocimiento sobre el tema. Pero lo mismo que digo esto también pido que aquel que no haya utilizado Direct3D (a partir de la versión 8) se abstenga de criticar ya que precisamente esas personas son las más radicales, las que lanzan las críticas mas duras y encima muchas de ellas sin sentido y falsas...ahora, si escucho las críticas de una persona como Dracula que ha utilizado intensivamente Direct3D pues me callo porque sé que habla con conocimiento de causa y punto...sin problemas ni rencores porque al fin y al cabo el fin de todo es crear ese engine que tanta ilusión nos hace con este y aquel efecto...y da igual con que medios lo consigamos, ¡el caso es conseguirlo! (bueno y que vaya bien ;))
Un saludo
[ Este Mensaje fue editado por: BeRSeRKeR el 2002-03-14 23:35 ]
Totalmente de acuerdo :sonriendo:
Saludos,
Ithaqua
http://ithaqua.stravaganza.org
Quisiera añadir algo al tema de las optimizaciones.
Hace unos años un amigo mio me dijo, en referencia a la recién salida Voodoo Banshee:
¡Ahora ya no hace falta optimizar, porque las tarjetas son tan rápidas que se lo comen todo!
Yo le miré y le dije:eso no es cierto. Si tu antes utilizabas 500 polígonos para hacer un coche, ahora lo que deberías hacer es utilizar 2.000, pero seguir optimizando, porque así las tarjetas no nos dan velocidad, nos dan calidad.
Pensad en que esta afirmación se hizo hace muchos años, en los que en los juegos 3D que aparecían, lo que más se destacaba era su aspecto gráfico.
Ahora pensad en el presente. ¿se fijan ahora tanto en los gráficos en un juego? Yo creo que no. Hemos superado esta etapa y ahora se fijan mucho en la simulación de la realidad, en la sensación que te proporciona ese juego.
Por ello, creo que si se utiliza un sistema de partición, este debe ir encaminado a que el juego sea más real, y no a que sea más rápido. Si vamos a usar un BSP, nos limita mucho. Si usamos portales tenemos mucha más libertad. ¡Y si no usamos nada pues mejor!(aunque como bien se ha dicho...¡esto tiene un límite!)
Yo por ello estoy en contra de los vertex shaders. Significa limitar para conseguir mejores gráficos. Y no es ese el camino que creo que hay que seguir.
Por cierto, Berserker, gracias por el comentario, pero creeme, no conozco D3D lo suficiente para que digas esto de mi! Sin embargo, espero ansioso el DX9 para volver otra vez a la Scene!
No estoy muy de acuerdo en eso de los gráficos, justo en esta etapa :sonriendo:
Y lo de los vertex shaders ya te lo leí una vez. Sigo sin pillarlo :-? Limitar de que modo? si aparte del fixed pipeline te dan la posibilidad de programar tu mismo el pipe. Y esta flexibilidad/potencia irá aumentando cada vez mas. En que sentido te limita?
Happy coding,
Ithaqua.
http://ithaqua.stravaganza.org
Hay un artículo en tomshardware que explica esto en más profundidad.
En resumen dice que si tienes que usar un vertex shader con luces, DEBES saber de antemano qué luces le afectan y qué tipo de luces le afectan. Convendrás conmigo que ESTO es limitar.
Pero esperemos a DX9. Aunque probablemente NINGUNA tarjeta soporte sus nuevos shaders! Por lo que la standarización de un juego pasará por..¡no usar shaders!
Buenas..,
Es cierto que, en el fondo, da igual usar OpenGL o DirectX (yo he usado los dos), pero en OpenGL hay menos codigo al final.
En cuanto a las extensiones, pues si, te pegas el trabajo padre de crear un .h con todas las extensiones, pero despues solo tienes que añadir las nuevas extensiones y ya esta funcionando.
Con respecto a lo de los poligonos, da igual que una aceleradora te de, pongamos 100 millones de poligonos, pues esta es la cantidad de poligonos que la aceleradora puede gestionar en TRANSFORMACIONES BASICAS (escalado, rotacion y traslacion). el resto va de tu parte, asi que pon que al final tienes en bruto unos 20 millones de poligonos por segundo, que te da mas de 300000 poligonos por frame. De todas formas, con 10000 o 15000 tienes de sobra para representar lo que quieras... para que usar un mesh de 10000 poligonos si con uno de 1000 tienes resolucion de sobra? ademas, para utilizar mas poligonos, siempre se puede recurrir a la tecnica del LOD para los modelos (MRM/VIPM u otros esquemas).
Y con lo de los shaders, pues es normal. De algun sitio tendra que sacar el hardware las normales, los vertices y los parametros para iluminar, vamos que no se los va a sacar de la manga...
Y mas en el proximo mensaje... :sonriendo:
Saludos.
Bueno, pues aqui voy con otro mensaje mas...
Mirad, este es para desmitificar la figura de John Carmack, ya que he escuchado por ahi lo de su plan de programacion, y esto es lo que tengo que decir al respecto...
Afortunadamente, en este foro no he visto esa clase de comportamiento, pero...
Señore, un poco mas de originalidad. Carmack NO es un dios, NI SIQUIERA un guru de la programacion, como la comunidad le pinta, tan solo es INGENIERO, nada mas simple. Sus unicos logros fueron 2:
1. El motor 2D que utiliza DOOM (ya que DOOM no es un juego 3D, ya que comba la Y para tapar ciertos efectos visuales)
2. La tecnica de la SURFACE CACHE en QUAKE 1.
3. La tecnica de los LIGHTMAPS.
Aparte de eso, no ha hecho nada mas. Si os fijais bien, cada vez que Carmack hace una implementacion de algo, la gente lo sigue como si fueran sus fieles. ERROR.
Y digo ERROR por decirlo de alguna manera, ya que: que casualidad que carmack utiliza una consola en Quake y ahora todos los engines 3D, como no..., tienen que llevar consola... Pues bueno, el que quiera....
Ahora llega otra vez el señor Carmack y utiliza lightmaps para simular iluminacion compleja o mas realista. y TACHAN!!! todo el mundo utilizando los lightmaps (oh... como no lo hemos descubierto antes... que gran invento...)... y otras cosas por el estilo...
MIRAD... El mismo Carmack dijo una vez, y muy acertadamente, que el no es ningun genio de la programacion, y que la gente se preguntaba como era capaz de hacer esos efectos especiales en sus juegos... Pues a eso el dijo la verdad: LEE ARTICULOS DEL SIGGRAPH, es decir, tecnicas que se utilizan en principio en infografia, y mas tarde se adaptan a los juegos.
NADA MAS. como veis, no es un dios ni mucho menos es COMO NOSOTROS. ni mas, ni menos :sonriendo:
Moraleja: Cualquiera puede implementar motores tan buenos como el de Carmack y cualquiera puede INCLUSO superarle.
Saludos.
Estoy deacuerdo con Julio. Sin embargo, el hecho de que Carmack haya sido el primero en utilizar estas técnicas en juegos no le desmerece en absoluto:no es fácil darse cuenta de lo que se puede utilizar!
Pero sí pienso que si Quake usa BSP, NO todo tiene que ser BSP. Y de hecho la gente debería buscar otras salidas a los problemas de partición del espacio. A veces por seguir a alguien nos limitamos a nosotros mismos.
Respecto a lo de los Shaders, me parece que no me has entendido. Digo que limita mucho saber de antemano qué luces afectan a que objetos. Ya expliqué en el foro hace poco este razonamiento. Si tienes un shader que calcula 4 luces, y el programa en ese momento sólo utiliza 2, porque las otras están muy lejos y no afectan, NO puedes indicárselo al shader, por lo que éste calcula las 4 luces en lugar de las 2 que sólo sería necesario calcular. Aparte de esto la complejidad de las mil y una variaciones que se pueden hacer con las luces y los efectos en los shaders:¡es imposible controlarlo todo! Y te remito al artículo de tomshardware. Allí se explica muy bien.
Emotion
Efectivamente debemos pensar por nosotros mismos (al fin y al cabo así es como se evoluciona) pero también es cierto que no es malo fijarse en el trabajo de los demás pero aún así te doy toda la razón en que lo que verdaderamente puede revolucionar el mundo del videojuego se encuentra en los papers del Siggraph o de las universidades por ejemplo...e incluso de personas anónimas!...pero aún así no podemos obviar que Carmack siempre va por delante de sus competidores y cuando saca un engine siempre hay una pequeña o gran revolución (el sistema de shaders de quake3 me parece muy bueno y lo hemos adquirido; ampliándolo eso si, para nuestro engine) y si no piensa en una cosa...qué engines han superado (en igualdad de tiempo) a los de id Software?...yo creo que ninguno...y seguramente así ocurrirá en el momento de salida de Doom3. Y es que como dijo una vez Carmack a ellos no les preocupa la competencia conocida (ej: Epic) sino ese grupo de personas que trabaja duro en el anonimato en busca de revolucionar el software de entretenimiento al igual que hizo id en sus comienzos.
Drácula
Efectivamente el tema de los vertex shaders me parece aún bastante lioso como para utilizarlo (el caso más claro es el que tu dices de las luces) de echo en nuestro engine estamos utilizando la fixed pipeline ¡y por ahora estamos muy contentos! :sonriendo:
Un saludo
De todas formas, me alegro que esto vuelva a estar animado.
Berserker
Si necesitas ayuda con tu motor, ya sabes. Esto también va para todo el mundo. Yo no soy de aquellos que responden a preguntas del estilo...¿Como se hace un juego? ¿Qué es DX? Sin embargo, sí me gusta responder a problemas concretos de 3D que pueda resolver.
Emotion: Sobre lo de los .h de extensiones, lee mi anterior mensaje :sonriendo:
Sobre lo de Carmack, yo soy de los que opinan que es exageradamente sobrevalorado. De hecho la gente suele contestar enseguida "J. Carmack" cuando les preguntas acerca de su programador favorito. Pero es que solo conocen a ese y a un par mas :ojo:
Por otra parte la tecnología (ojo, solo tecnología) del Unreal siempre me ha parecido mucho mas interesante que la del Quake.
Ah, y otra cosa. Carmack ha innovado en alguna cosilla más de las que tu listas. Por poner un simple ejemplo: El Carmack's reverse en el cálculo de sombras dinámicas usando shadow volumes.
Aun asi, por mucho que digas que se basa en papers del Siggraph, siempre es de los que estan en la cresta de la ola en cuando a tecnologia se refiere. Definitivamente Carmack no es un cualquiera como tu dices, pero si que es desmesurado el grado de fanatismo que genera.
Dracula: Lo de las luces de los vertex shaders se puede abstraer para generalizarlo, y sino échale un vistazo al trabajo que hicieron unos de la universidad de stanford (google: opengl shading language creo).
Una cosa es que en principio no se pueda realizar (= funcionalidad básica) y otra que con un poco de curro no se pueda conseguir :sonriendo:
Nada mas. Un saludo,
Ithaqua.
http://ithaqua.stravaganza.org
Ithaqua
He leido por encima el documento. Eso es exactamente lo que se debería hacer, sin embargo es imposible de hacer con los vertex shaders actuales. Yo ya dije que el trabajo de los vertex shaders debería hacerlo la CPU y no la GPU, y expuse que además algunas veces necesitas el valor que te ha calculado la GPU para calcular las colisiones(Animación In-Between), con lo que al final no ganas nada ya que lo tienes que calcular también por CPU.
Quizás el VertexShader 2.0 arregle por fin este problema.
Drácula
Gracias por la proposición. Sin duda, si tengo alguna duda o algo que comentar aquí lo pondré...y la verdad, yo también me alegro de que el foro vuelva a ser lo de antes incluso mejor (por ahora los posts están siendo muy interesantes)
Un saludo
Drácula, sí se puede hacer. Échale un vistazo a estas librerías:
http://graphics.stanford.edu/projects/shading/Lo único que haces es 'registrar' las luces y ya.
En todo caso, aunque no se pudiese abstraer, el añadir o quitar código de iluminación es bastante trivial. Incluso podrías currarte una tool simple para automatizar el proceso de adaptación de código.
Saludos,
Ithaqua.
http://ithaqua.stravaganza.org
Creo que utilizar BSPs puede seguir siendo útil. Sin embargo cuando Carmack decidió utilizar este algoritmo para su engine3D fue principalmente porque las placas 3D no tenían Zbuffers y necesitaba ordenar los polígonos previa a su renderización.
Hoy día el BSP está en retirada, aunque eso no significa que ya no se utilice o no tenga ventajas, ya que muchos engines combinan portales con este algortimo.
Ithaqua, quizás no hablamos de lo mismo. Piensa que en el vertex shader hay me parece que espacio sólo para 128 instrucciones(aunque de esto no estoy seguro. Creo que lo leí en la SDK pero ahora no lo encuentro!) Por tanto, me limita mucho ya sólo este aspecto. Después tengo que compilar el vertex shader en tiempo de ejecución. Y ya sabes que según que tarjeta tengas, al final podrás usar uno u otra shader!! Y todo esto para qué:¡sólo para ganar velocidad! Es decir que complico la historia un montón, elimino un montón de tarjetas que no soportan el shader en hardware, para que se puede jugar a 80 fps en 1600x1200!! Pues yo prefiero que el juego funcione en muchas más ordenadores, con TODAS las características, pero que jueguen a 80 fps en 1024x768.
Sin embargo, esto es una opinión. Es evidente que algo falla en los Shaders cuando Microsoft saca una nueva versión en cada revisión de DX. Y en la 9 aparecerá la 2.0, con control de flujos!!
Para Ithaqua:
Es cierto lo que dices respecto a lo de que el siempre dio un paso por delante, pero fue suerte, como bill gates (aunque sobradamente sabido por todos, carmack se merece el lugar que hoy en dia ocupa, y bill gates no).
En cuanto a lo de las tecnicas de sombra y calculo, me remito a lo que dije anteriormente: es INGENIERO. es normal. por eso digo que no tiene merito.
Y por lo demas, y puesto que hoy en dia los juegos se elaboran con el mismo concepto de una pelicula, DA IGUAL que tu engine muestre graficos ultrafinos y realistas. Si tienes un buen guion o un buen ojo para las producciones, da igual lo bueno o malo que sea tu motor. Un ejemplo: METAL GEAR SOLID.
Metal Gear es, ha sido y seguira siendo una de las aventuras mejor hechas (por no decir la mejor, junto con los final fantasy) en la historia de los videojuegos. Y no tiene unos graficos de ensueño. Ademas, quiero que tengais en cuenta una cosa: HIDEO KOJIMA, el creador de Metal Gear, NO ES PROGRAMADOR, sino DIRECTOR ARTISTICO. Eso dice mucho de el, pues ha sido capaz de conjugar el concepto escenico y artistico con la tecnologia.
Señores, para hacer buenos graficos ya estan las APIs. Para hacer buenos juegos, hay que estar entrenado y tener lo que todo director de cine tiene: la ESENCIA.
Es todo.
Saludos.
Es cierto que se endiosan a algunos gurus de la programacion (lease Carmack) y que algunos de ellos se pegan el gran tortazo cuando elevados por fama y fortuna, deciden costruir su propia "basilica" (lease john Romero). A veces los fieles tienen poca memoria y no perdonan un alejamiento de las virtudes pregonadas. :ojo:
Pero tambien es cierto que se ediosan a empresas españolas (lease Dinamic , Pyro). Y algunas tambien se dan el batacazo. Encambio se olvidad de pequeñas empresas que estan dando el cayo bastante mas tiempo que estas y son las que de verdad estan aguantando el software español y haciendo cantera.
Asi que resumiendo ni unos son tan buenos, ni otros tan malos y tanto los algoritmos como los demas efectos introducimos por unos y otros no son mas que un aprovechamiento del momento de saber encauzar un algoritmo en su sitio o de una manera que nadie habia pensado u ocurrido y a partir de ahi es todo muy facil. Una vez visto un tema, es facil copiarlo y decir que no es tanto como dicen. Lo complicado no es programarlo, sino ocurrirsele a uno y saber donde ponerlo...la programacion, pienso que, cualquier programador podria implementarla.
Y se acabo el rollo.
[ Este Mensaje fue editado por: Kabila el 2002-03-18 18:21 ]
[ Este Mensaje fue editado por: Kabila el 2002-03-18 18:23 ]
Emotion
John Carmack no es ingeniero (si con ingeniero te refieres a tener una carrera de ingeniería). El mismo lo ha repetido hasta la saciedad (no tiene ninguna carrera) en respuesta a aquellos que no paraban de preguntarle si era necesario una carrera para ser programador de juegos...o sea que todo lo que John sabe ha sido por libros, documentos...y por su propia experiencia y práctica lo cual tiene mucho más mérito aún...
Un saludo
Juurrrllll pues yo creia que era ingeniero. Puff... que chasco. Pero da igual... sigo con mi exposicion en pie.
Es mas importante un buen fondo para un juego que su aspecto grafico, mal que le pese a aquellos y aquellas que se gastan una pasta gansa en la ultima aceleradora del mercado y piensan que por esa razon todos los juegos tienen que tener un aspecto inmejorable. Deplorable actitud, me temo...
Saludos.
Emotion
Estoy de acuerdo que un juego que base todo su potencial en el engine gráfico y no en el argumento, jugabilidad, etc no es un juego. Pero para mi es muy interesante ver juegos que hacen efectos especiales de "última generación" y me gusta...pero seguramente esto es así porque lo estoy viendo desde el punto de vista del programador que soy y no desde el del usuario típico de juegos al cual seguramente toda esa parafernalia de gráficos le trae sin cuidado :sonriendo:
Un saludo
Totalmente deacuerdo con esto último BerSerKer, tengo amigos con grandes ordenadores que se aburren con todo. Los únicos que nos fijamos en los efectos es un amigo mapeador y yo, pero solo por la cuestión técnica, no porque mejoren los otros aspectos del juego. Aunque como programadores siempre queremos conseguir lo más, antes con las 2D, el sprite más rápido, ahora el render más rápido...
Por cierto, este fin de semana me he pasado un juego que tenía atragantado desde que salió, nunca me lo habia conseguido terminar y al fín lo logré... menudo enganche...horas y horas como hacia tiempo que no me enganchaba.... y vaya gráficos.... el juego en cuestión se llama "Dune"
un saludo
para Berserker:
No estoy deacuerdo contigo al 100% aunque si debo reconocer que algunas cosas son muy ciertas.
Es cierto que uno no se gasta una pasta en una GeForce4 Ti4600 para ver juegos en 2D, pero tambien creo que, como programador, olvidas algo que esta y estara siempre ahi:
la esencia. Porque un jugador de consola jugando a un juego no se queja y uno de PC jugando al mismo juego si? porque el usuario de consola sabe que el hardware que tiene no lo puede ampliar y por lo tanto, no le dara mas problemas de los que ya le de (o ninguno).
Sin embargo, debido a que el mercado de PC esta SATURADO de hardware a mas no poder, pues a pesar de que haya estandares la gente se sigue pasando por el forro lo de ser condescendiente con los demas. Estoy deacuerdo en aprovechar el hardware de nueva hornada con algoritmos mas potentes, pero siempre y cuando NO se deje atras a la gente que tiene un hardware mas modesto.
Ademas, los efectos no lo son todo, ya que solo añaden un poco de leña al fuego. Te sirven para dar un toque de emocion, miedo, risa, etc. a la escena que representes, pero no debes partir de los graficos para construir un juego, ya que lo primero que debes ver es como va a ver el jugador el juego, no tu.
En ese sentido, el programador debe olvidarse de lo que EL quiere y crear lo que se ajuste en mayor o menor medida a lo que el jugador (y no digo quiere) ESPERA.
Cuando tu le preguntas a un programador de juegos si le gustan los juegos que hace, la mayoria te dira que NO. y no porque sea malo, sino porque el lo ve de una forma y los jugadores de otra.
En fin, este dilema es el que siempre mantendra en alerta a desarrolladores y jugadores, aunque te digo una cosa: son ellos los que te pagan (por decirlo de alguna manera) y a ellos debes agradar, no a ti mismo :sonriendo:
Por cierto, con mi topic sobre render avanzado lo que me gustaria es que tu y otros que he visto por aqui me ayudeis a crear una especie de pequeño manual de efectos especiales para que los demas puedan aprender a hacerlos (y yo tambien algunos, para que mentir). te apuntas? :sonriendo:
Saludos.
Emotion.
Seguramente no soy la persona más indicada para llevar a cabo la planificación de un juego lo reconozco :riendo:
Pero vale como ya se ha dicho los gráficos no lo son todo en un juego...así que me callo :sonriendo:
Tal vez mi sitio sea el desarrollo de herramientas para los efectos especiales de cine (jeje...¡¡es broma!!) :riendo:
Un saludo
PD: En estos momentos ando bastante ocupado con el desarrollo de un engine para un juego (más los estudios) así que dudo que tenga tiempo para hacer lo que dices (ni siquiera tengo tiempo para los tutos básicos que empecé a escribir para Direct3D). De todas maneras la propuesta es muy interesante y a ver si la gente se anima...
No te preocupes, que ambos somos del mismo gremio. Yo llevo metido en esto de la imagen desde que tenia 12 años (con el Amstrad CPC modifique un listado que hacia fractales y le añadi agua y niveles de recursion) :sonriendo:
Y no soy superdotado :sonriendo:
Saludos.
Vaya...yo no llegué a ese nivel. De echo comencé a programar algo "tarde" (a los 16) y tal vez me metí en esto de la programación 3D demasiado precipitadamente y a veces tengo la sensación de que me he saltado unos cuantos peldaños...así que tal vez algún día tenga que "volver atrás" y recorrerlos :riendo:
Un saludo
Bueno, lo de los peldaños es muy relativo.
Puede que necesites en algun momento volver atras, pero como mucho para afianzar tus conocimientos en algo muy concreto.
yo llevo ya casi 13 años en esto (ahora tengo casi 25 años) y te digo que, si, merece la pena retroceder a veces, pero no siempre.
Cuantos años llevas tu en esto, o por decirlo de otra manera... cuantos años tienes?
Saludos.
Tengo 23 años o sea que llevo 7 años...
Bueno, entonces veo que llevamos bastante tiempo en esto (somos peor que los dinosaurios, eh? :riendo:)
Saludos