Proyecto Utopia

[zupervaca]

 pixel shader 1.0 es tan rustico que me parece que no permite operaciones simples como sumar colores, para que me funcionara una prueba que hice tuve que poner minimo el 1.1

[samsaga2]

 Si todo sale bien nuestro compilador de shares generara codigo para las diferentes versiones de shaders.

[er_willy]

 pues tal como esta el mundo de los videojuegos, lo mejor en mi opinion.

Es hacer las demos con el maximo de calidad por encima incluso de las capacidades del mejor ordenador a mano, que vaya a tres frames pero que los palurdos lo flipen.
Una vez que los tengas comiendo en la mano ya habra tiempo para optimizarlo.

mis dos chaspa de mahou

yo es lo que estoy haciendo con el prototipo de mi nuevo juego.  :ph34r:

que no veas como jode currase un modelo  de solo 600 polys para que consuma poco frame y te venga los amigos a casa  a decirte que vaya mierda, pos na 3000 polys de modelo y a toma pol culo.

[zupervaca]

Si todo sale bien nuestro compilador de shares generara codigo para las diferentes versiones de shaders.

podirais usar bison o como se llame para generar el compilador

[Haddd]

 ¿y mis preguntas? ¿no obtienen respuesta?  <_<  

[seryu]

 haddd me parece que quieren hacer un engine al estilo clasico, utilizando los shaders solo para los efectillos de moda. Asi que de un engine shader centric, me parece que nos podemos ir olvidando.

A mi lo que me parece es que ese tipo de motores en 3 años estaran obsoletos, pero si ellos lo hacen asi, sus razones tendran, igual les apetece contarnoslas.

[zupervaca]

 el motor que actualizo de vez en cuando que permite directx u opengl (aquel que fallaba con ati en opengl) solo permite trabajar con shaders, es decir, los vertexbuffers son estaticos, no permite realizar transformaciones en el device con lo que las matrices de transformacion se han de pasar al shader, etc. todo se debe de calcular en el shader, creo que este sistema es el correcto, ademas de que simplifica muchisimo el multirender y el que se implantara en unos años, hacerlo a la vieja me parece un fallo muy gordo y es dar trabajo al cpu que podria hacer la gpu, pero bueno ellos sabran lo que quieren hacer, creo que deberia replantearse el proyecto bien y mirar en que fecha quieren que vea la luz su hijo, por que los shaders llevan usandose hace bastante tiempo aunque no tuvieramos tarjetas que los permitieran

[abel.bernabeu]

 

Si el terreno es estático, pero teselas...¿Como resolveis la física? Esa es una pregunta importante hoy en día. Pq te puede ocurrir que el objeto que está en el suelo cuya y=1, por ejemplo, al desplazarse la cámara y el teselator calcular una nueva y para ese punto, por ejemplo y=1.1, haga que el objeto se caiga, pq no encuentra suelo...por ejemplo... :blink:

Sobre lo de los árboles, entiendo que TREN sea la capa inferior, sólo digo a ver si lo teneis pensado... ;)

Sobre shadowmap, pues está el mismo problema que con la físcia. Pq al renderizar desde la cámara puede ser que el tesselator genere valores diferentes que al renderizar desde la luz...

Venga, a ver si entre todos podemos echar una mano al proyecto. Lo que sigue nadie sin responder es a que tarjeta va destinado el juego.... :blink:

Haddd, perdona que no haya podido responderte antes (estoy realmente liado ahora X)...

Sí hay pequeños ajustes de altura, pero no son un problema para la física. Cuando reteselas hay una serie de "HeightAdjustListener"'s (heredan de esa clase) que desean ser avisados para actualizar sus alturas relativas al terreno si es necesario... Eso es sencillo.

Tampoco veo problema en que quieras hacer algunas sombras con shadow mapping. ¿A qué tipo de sombras te refieres? La variedad es inmensa: de los objetos sobre el terreno, autosombras del terreno, sombras del terreno sobre los objetos, etc...

De todas formas me da la impresión de que tienes una pequeña confusión: piensas que la teselación del terreno sería distinta al renderizar desde el terreno desde dos puntos de vista en el mismo frame.

No, nuestra malla es una sola en cada frame, con independencia de que se actualizará en próximos frames al mover la posición del observador.

Sobre la tarjeta... pues en lo que al terreno respecta, conforme avance el desarrollo iré pidiendo mejor tarjeta. Es la verdad XD

De momento exijo vertex shaders 1.0 para acelerar el geomorphing (y eso como sabes, hasta se puede emular por software sin mayor problema). Es seguro que en los próximos meses vamos a subir a pixel shaders 1.0 como mínimo.

Aparte de eso el per pixel-displacement mapping se adapta perfectamente a la arquitectura de TREN que ya trabaja sobre muestreos triangulares en vez de sobre triángulos. El per pixel-displacement mapping  lleva meses pidiendo a gritos que lo use en TREN para renderizar las hojas del árbol de detalle... Ahora es como si lo estuviese haciendo a mano sin soporte del hardware X)

Los detalles para convencerte de lo que te digo podrás verlos en el artículo que expondré en el CGAMES'05.

http://www.scit.wlv.ac.uk/~cm1822/cgamessub.htm

Prometo poner un link en la web del proyecto Utopía con todo el material que presentemos en la conferencia.

Un saludo.

PD: Claro que está todo pensado... lo que necesitamos es tiempo para materializarlo todo ;D

[Haddd]

  :P Genial que contestes, a ver si de esta forma podemos evitar problemas futuros..Te explico lo que veo, a ver que te parece...

Sí hay pequeños ajustes de altura, pero no son un problema para la física. Cuando reteselas hay una serie de "HeightAdjustListener"'s (heredan de esa clase) que desean ser avisados para actualizar sus alturas relativas al terreno si es necesario... Eso es sencillo

En Newton no puedes modificar el terreno "on the fly". Tu puedes crear un terreno teselado y Newton lo utilizar como un CollisionTree. Entonces se me plantea la duda de cuanta información tendrá la física realmente ( qué nivel de teselación tendrá el terreno cuando construya el CollisionTree).

No soy un experto en Newton, pero creo que no puedes crear y destruir vértices fácilmente...

Tampoco veo problema en que quieras hacer algunas sombras con shadow mapping. ¿A qué tipo de sombras te refieres? La variedad es inmensa: de los objetos sobre el terreno, autosombras del terreno, sombras del terreno sobre los objetos, etc...

De todas formas me da la impresión de que tienes una pequeña confusión: piensas que la teselación del terreno sería distinta al renderizar desde el terreno desde dos puntos de vista en el mismo frame.

No, nuestra malla es una sola en cada frame, con independencia de que se actualizará en próximos frames al mover la posición del observador

Bueno, yo no tenía claro si ibas a a teselar una vez para la cámara y luego para cada luz. Tampoco se si utilizareis shadow mapping, ni si utilizareis luces reales, o sólo la del sol. Pero quería hacer incapie en el problema de los jaggies famosos al modificar la Y. Sólo que lo tengais en cuenta  ;)


Se me ocurre ahora el problema multijugador, la malla podría teselarse en el mismo frame de formas totalmente diferentes para cada jugador.... :(

Sobre la tarjeta... pues en lo que al terreno respecta, conforme avance el desarrollo iré pidiendo mejor tarjeta. Es la verdad XD

De momento exijo vertex shaders 1.0 para acelerar el geomorphing (y eso como sabes, hasta se puede emular por software sin mayor problema). Es seguro que en los próximos meses vamos a subir a pixel shaders 1.0 como mínimo.

Aparte de eso el per pixel-displacement mapping se adapta perfectamente a la arquitectura de TREN que ya trabaja sobre muestreos triangulares en vez de sobre triángulos. El per pixel-displacement mapping lleva meses pidiendo a gritos que lo use en TREN para renderizar las hojas del árbol de detalle... Ahora es como si lo estuviese haciendo a mano sin soporte del hardware X)

¿no crees que si vais a utilizar shaders 4.0, por ejemplo, el displacement mapping junto a la generación dinámica de vertex en el shader puede cambiar completamente la filosofía de TREN ?

Recuerdo una demo de Matrix con displacement mapping y creo que era adaptative tesselation que precisamente era sobre la generación de terreno.

PD: Claro que está todo pensado... lo que necesitamos es tiempo para materializarlo todo

Eso es lo más importante, un buen análisis, por eso hago estas preguntas...

Venga...sigamos hablando...te toca... :lol:

[abel.bernabeu]

:P Genial que contestes, a ver si de esta forma podemos evitar problemas futuros..Te explico lo que veo, a ver que te parece...

Sí hay pequeños ajustes de altura, pero no son un problema para la física. Cuando reteselas hay una serie de "HeightAdjustListener"'s (heredan de esa clase) que desean ser avisados para actualizar sus alturas relativas al terreno si es necesario... Eso es sencillo

En Newton no puedes modificar el terreno "on the fly". Tu puedes crear un terreno teselado y Newton lo utilizar como un CollisionTree. Entonces se me plantea la duda de cuanta información tendrá la física realmente ( qué nivel de teselación tendrá el terreno cuando construya el CollisionTree).

No soy un experto en Newton, pero creo que no puedes crear y destruir vértices fácilmente...

Tampoco veo problema en que quieras hacer algunas sombras con shadow mapping. ¿A qué tipo de sombras te refieres? La variedad es inmensa: de los objetos sobre el terreno, autosombras del terreno, sombras del terreno sobre los objetos, etc...

De todas formas me da la impresión de que tienes una pequeña confusión: piensas que la teselación del terreno sería distinta al renderizar desde el terreno desde dos puntos de vista en el mismo frame.

No, nuestra malla es una sola en cada frame, con independencia de que se actualizará en próximos frames al mover la posición del observador

Bueno, yo no tenía claro si ibas a a teselar una vez para la cámara y luego para cada luz. Tampoco se si utilizareis shadow mapping, ni si utilizareis luces reales, o sólo la del sol. Pero quería hacer incapie en el problema de los jaggies famosos al modificar la Y. Sólo que lo tengais en cuenta  ;)


Se me ocurre ahora el problema multijugador, la malla podría teselarse en el mismo frame de formas totalmente diferentes para cada jugador.... :(

Sobre la tarjeta... pues en lo que al terreno respecta, conforme avance el desarrollo iré pidiendo mejor tarjeta. Es la verdad XD

De momento exijo vertex shaders 1.0 para acelerar el geomorphing (y eso como sabes, hasta se puede emular por software sin mayor problema). Es seguro que en los próximos meses vamos a subir a pixel shaders 1.0 como mínimo.

Aparte de eso el per pixel-displacement mapping se adapta perfectamente a la arquitectura de TREN que ya trabaja sobre muestreos triangulares en vez de sobre triángulos. El per pixel-displacement mapping lleva meses pidiendo a gritos que lo use en TREN para renderizar las hojas del árbol de detalle... Ahora es como si lo estuviese haciendo a mano sin soporte del hardware X)

¿no crees que si vais a utilizar shaders 4.0, por ejemplo, el displacement mapping junto a la generación dinámica de vertex en el shader puede cambiar completamente la filosofía de TREN ?

Recuerdo una demo de Matrix con displacement mapping y creo que era adaptative tesselation que precisamente era sobre la generación de terreno.

PD: Claro que está todo pensado... lo que necesitamos es tiempo para materializarlo todo

Eso es lo más importante, un buen análisis, por eso hago estas preguntas...

Venga...sigamos hablando...te toca... :lol:

Hombre, el diseño del terreno está ya hecho y no se toca porque no.

Es coña, pero el diseño del motor de terrenos que tenemos admite todo lo que necesitamos y todos los añadidos previstos encajan.

Desconozco qué funcionalidades trae Newton y solo te puedo hablar de lo que estudié en su día para asegurarme de que el motor de dinámica encajaba: ODE.

A ODE le puedes calcular las colisiones tú mismo (no dependes del colision tree que quiera hacerse Newton).
ODE dividía la física en dos partes:

1) La detección de las colisiones, donde todo es mera geometría y cualquier informático se maneja.

2) La simulación mecánica con las fuerzas resultantes de las colisiones y las fuerzas externas que queramos aplicar. La verdad sea dicha, yo no tengo suficientes conocimientos de mecánica lagrangiana y esta segunda parte ya no la considero tan fácil como la primera....

Para la primera parte, y ya tengo mi árbol para el terreno y sé cómo detectar las colisiones con coste O(log n), siendo n el número de parches triangulares que conforman el terreno. No necesito de ODE ni de Newton para detectar las colisiones.

Samsaga2 ha visto que Newton también tiene esta división. Yo le creo (tanto que si él lo ha estudiado yo no necesito verlo por mis propios ojos XD)

Sobre el displacement mapping, hay muchos motores que lo usan. Te puedo decir uno de cabeza que lo vas a encontrar rápido en el Google y no es nuevo: el XVox.

http://users.belgacom.net/xvox/

Aunque la característica principal de TREN es la paginación. Viene a ser la prueba de concepto de cómo concibo yo el LOD y la paginación simultánemente. A partir de un terreno del que sólo tengo en RAM lo que necesito, cargo de disco sobre la marcha y teselo para ofrecer LOD contínuo.

No hay muchos motores que muevan terrenos de 16K x 16K con LOD y paginación.

Lo del multijugador... me recuerda a la historia de aquel hombre que fue al médico con una contusión en la mano (pongamos que no fue grave). El médico le dice que se pondrá bien y el hombre le pregunta: ¿pero podré tocar la guitarra?

Entonces el médico pregunta: ¿usted sabe tocar la guitarra?. El hombre contesta: no, ¿pero podré?.

XDDDD

Te vengo a contar esta historia porque la física NO tenía paginación ni LOD antes de que empezásemos a cabilar sobre cómo hacer paginación y LOD en la representación gráfica.

Aún así, te contesto que sí podrás tocar la guitarra ;)

Tú basicamente a donde acabarías llevándome es a que quieres paginación y LOD en la detección de colisiones con el terreno (además de en la representación visual, donde TREN ya aporta esas cosas). Bien, estoy convencido de poder hacerlo, solo necesito tiempo :D

La máquina de cada jugador será responsable de detectar las colisiones con el terreno de los objetos más cercanos a él (es una solución rápida).

Si tienes miedo del cheating también hay alternativas pero yo de verdad que no me complicaré nada en ese aspecto.

En cualquier caso te digo que la parte de la detección de colisiones es en la que trabajo ahora (en mis ratos libres)... No tiene sentido que te hable de algo que no está implementado aún.

Lo que sí quiero hacerte ver antes de acabar es que la física tiene implicaciones con la red que son independientes de los gráficos. Yo te recomiendo que leas un thread sobre física en red que se abrió en gdalgorithms a principios de este año (a raíz de un mensage Gaffer tilulado "Zen of networked physics").

Para mí fue muy productivo leer aquel thread y saqué bastantes ideas.

Un saludo.

[raistlin]

 Eso que propones que entre los clientes se repartan la logica del juego no es para nada buena idea, y no hablo del cheating precisamente.

Pero supongo que ya las habras tenido en cuenta. Deduzco por tu forma de hablar que no vais a poner multijugador en utopia?

[Haddd]

 Esto parece ya una guerra Haddd <-> Utopía...y no era mi intención...

Yo pretendía hacer preguntas "touche" para ver si realmente habiais pensado en ello, porque es que no tengo más datos de los que hay en este thread. Me da la impresión cuando releo, que parezco el típico alumno empollón que quiere sacarle los fallos al profesor, y no era ese mi objetivo. Ya os digo que yo creo que Utopía puede hacerse, igual que Haddd al final ha salido a la luz ( o saldrá prontito ) , pero es que como tenemos tan pocos datos, uno se imagina que quizás sólo habeis pensado en lo que explicais, por ejemplo en que TREN es un sistema de terrenos muy bueno, y no habeis caido en las implicaciones que esto puede tener en la física, y por eso he hecho un poco de incapié en ello.

Pero parece que sí, que el tema está pensado, y me alegro, lo que pasa es que me siento un poco "tonto" porque hago preguntas que ya están respondidas. ¿no podeis explicarlo todo un poco y así podremos ayudaros a detectar posibles agujeros?

Venga...suerte!! (ole)

Por cierto, a ver si haces una versión de TREN para el motor, ahora cuando liberemos el código... (genial)  

[abel.bernabeu]

Esto parece ya una guerra Haddd <-> Utopía...y no era mi intención...

Yo pretendía hacer preguntas "touche" para ver si realmente habiais pensado en ello, porque es que no tengo más datos de los que hay en este thread. Me da la impresión cuando releo, que parezco el típico alumno empollón que quiere sacarle los fallos al profesor, y no era ese mi objetivo. Ya os digo que yo creo que Utopía puede hacerse, igual que Haddd al final ha salido a la luz ( o saldrá prontito ) , pero es que como tenemos tan pocos datos, uno se imagina que quizás sólo habeis pensado en lo que explicais, por ejemplo en que TREN es un sistema de terrenos muy bueno, y no habeis caido en las implicaciones que esto puede tener en la física, y por eso he hecho un poco de incapié en ello.

Pero parece que sí, que el tema está pensado, y me alegro, lo que pasa es que me siento un poco "tonto" porque hago preguntas que ya están respondidas. ¿no podeis explicarlo todo un poco y así podremos ayudaros a detectar posibles agujeros?

Venga...suerte!! (ole)

Por cierto, a ver si haces una versión de TREN para el motor, ahora cuando liberemos el código... (genial)

No te preocupes por el tono de "X vs. Y" que podría interpretar alguien malpensado que llegase ahora y empezase a leer XDD

Creo que la conversación está dentro del tono deseable y que si preguntas es por un poco de interés (cosa que se agradece).

El problema de TREN es que hay muchas cosas pensadas, algunas ya implementadas y otras pocas documentadas. Prometo ir poniendo cosas en la web de Utopia (sobre todo los documentos, que es lo que a mí personalmente me suele interesar).

Me han aceptado un artículo en el CGAMES'05 y espero poder ofrecerlo para descarga durante el congreso (del 28 al 30 de este mes). Creo que no debo dejarlo accesible en web antes por cortesía con los organizadores. El día que exponga lo pondré en la web de Utopía.

¿Donde puedo ojear algo de Haddd?

[Haddd]

 pronto  (ole)  

[arisdg]

Pero supongo que ya las habras tenido en cuenta. Deduzco por tu forma de hablar que no vais a poner multijugador en utopia?

El multijugador no ha sido prioritario debido al propio guion del juego.  El guión no ha sufrido grandes cambios desde que se preparó inicialmente.
Si es verdad que siempre, en toda discursión que hemos tenido, se han planteado las posibles dificultades de montar la versión multijugador y que tipo de multijugador montariamos... Pero en estos momentos, es verdad que todavia no tenemos muy claro que opciones de multijugador vamos a montar.
No es algo que va a caer en saco roto, ya que se esta viendo en el mercado que una gran cantidad de juegos estan triunfando por dar la posibilidad de jugar on-line.
Un ejemplo claro nos lo da el Sacred. No es un juego con un gran despliegue tecnologico pero seguro que unos cuantos firmabamos por vender lo que ha vendido. Y gran parte de su exito ha sido la facilidad de montar partidas online.

Saludos.