Portal Rendering...

[BeRSeRKeR]

                                Hola a todos.

Hace tiempo que llevo dándole vueltas al tema del portal rendering...no ya al funcionamiento del mismo (que en mayor o menor medida está claro) sino al diseño de los niveles basados en esta técnica.

En un principio pensé en utilizar MAX para crear los niveles y posteriormente con un plugin propio exportar todo a mi propio formato. Ciertamente la cosa parecía viable...incluso los portales (que se asignarían manualmente) podrían ser primitivas de tipo shape. Pero el problema se presentó a la hora de definir un sector...¿qué es un sector?. Está claro que un sector es un conjunto de polígonos de los cuales, alguno/os de ellos puede/n ser portales (aunque tal y como lo pensé los portales no serían polígonos sino shapes como he dicho anteriormente)...pero el problema es...¿qué polígonos conforman un sector?...¿cómo defino en MAX un sector?. Una posible solución sería a cada polígono decirle "hey, tu perteneces al sector 13"...pero supongo que esto no debe sentarle nada bien al diseñador de niveles ni al polígono (si es supersticioso :sonriendo:

Es por esto que pido vuestra opinión acerca del tema...¿creeis que es viable desarrollar los niveles (basados en portales/sectores) con MAX de una forma (relativamente) sencilla?...si es así...¿cómo lo planteariais?.

Yo por el momento seguiré con el BSP/PVS :sonriendo:

Lo que está claro es que el siguiente paso sería basar el engine en un sistema así ya que como dijo Drácula en un post anterior, lo que la gente busca cada vez más es una interacción mayor con el entorno del juego (aunque también unos buenos gráficos y una gran velocidad de proceso) y esto se consigue creando un mundo en el que cualquier objeto pueda ser movido, eliminado, insertado o lo que sea en tiempo de ejecución y esto se consigue con el sistema de portal rendering (aunque no sea el único).

Muchas gracias y un saludo.

PD: Otra solución podría ser crear un editor de niveles propio...pero claro, si no sé como plantear el diseño...¿cómo voy a saber qué capacidades meterle a la hora de su desarrollo?

[ Este Mensaje fue editado por: BeRSeRKeR el 2002-03-16 13:49 ]

[ Este Mensaje fue editado por: BeRSeRKeR el 2002-03-16 13:51 ]                                

[BeRSeRKeR]

                                Una aclaración...realmente la inserción de la palabra "convexos" cuando digo "...pensé que si los sectores debían ser convexos pues se creaba la planta del sector con un shape..." no tiene ningún sentido...¡en que estaría pensando! :riendo:

Un saludo                                

[Drácula]

                                Bueno, en realidad el gran problema estriba en aquellos polígonos que pertenecen o no pertenecen a 2 sectores. Si una pared pertenece a un sector, lo lógico es que la parte de atrás pertenezca a otro. Pero si es 1 solo objeto..¿Cómo puede saberse?
Ese problema me lo he planteado mucho, porque mi idea es también cargar una escena de MAX y punto, para no tener que hacer un editor. Al final, después de mucho pensar, me di cuenta de que...¡lo mejor es hacer un editor! Pero bueno, dejaremos esta reflexión para otro momento.
El problema de la famosa pared que comparte 2 sectores, se puede solucionar..¡teniendo 2 paredes! Una para cada portal. Esto rompe totalmente con la idea de optimización, y por supuesto de BSP, sin embargo es la mejor forma que encontré(y esto lo he razonado muchooo)

Después hay el problema de decirle...¿Qué objetos forman parte de un sector? Bien, la idea del nombre es buena, pero muy engorrosa. Yo apostaría por esta otra:Encierra los objetos que tu quieras que formen un sector en un cubo. Y a este cubo dale el nombre del sector y las propiedades del mismo. Así cuando hagas un sector, agrupas los objetos junto al cubo y...¡perfecto! El grafista tiene los sectores agrupados y tu tienes la información que necesitas.

                               

[BeRSeRKeR]

                                Gracias por responder Drácula.

Efectivamente el problema de la pared también me lo planteé y mas o menos llegué a la conclusión de la que hablas del "doble
tabique" y la verdad es que otra cosa mejor no se me ocurre así que ya veremos cuando llegue el momento. Por ahora utilizamos el q3Radiant para la edición de niveles :ojo:

Aunque ciertamente se podría utilizar q3Radiant e ir poniendo los portales en su sitio (lo cual no sería demasiado complicado). De esta forma, sólo quedaría compilar el nivel con lo cual el propio editor se encargaría del problema de la doble pared. Evidentemente al compilar no sería necesario hacerlo con la visibilidad o la generación de lightmaps activada (ya que precisamente eso es lo que hace que la compilación de un nivel de quake3 lleve horas y horas) ya que la visibilidad se realizaría a través de los portales y la iluminación podría ser dinámica...¿qué te parece?...¿sería posible?...aunque por otra parte ¿cómo le indicamos a q3Radiant qué es un sector?...¿un brush de q3Radiant = sector?...podría ser... :sonriendo:

Jeje...bueno ahí queda eso :ojo:

Un saludo                                

[Drácula]

                                No he visto nunca el q3Radiant, así que no puedo ayudarte.
Pero fíjate que por tu reflexión te encaminas a que lo mejor es hacer un editor.
                               

[Ithaqua]

                                Hola Berserker,

Una posible solución sería hacerte una tool en maxscript. Maxscript es increiblemente potente y la curva de aprendizaje muy muy buena.
Yo era muy reticente a echarle una ojeada al maxscript porque mas que nada me sonaba a que iba a tener que dedicarle mucho tiempo para aprender a hacer la simple tontería.
Nada de eso :sonriendo:

Por proponer algo, podrías hacer algo que asignara un valor de sector a la selección actual (y que dependiendo de este valor de sector, se altere su color). Lo mismo con los portales, asignar la propiedad de portal a la selección, dejando elegir qué sectores comunica.
Esa información la podrías ir guardando en tiempo real en las user defined properties de los nodos (Ej, "Sector=5", "Portal. Sectors=(4,5)" ).
Para el grafista es muy fácil trabajar solo dándole a botoncitos y viendo como cambia el color de los objetos con sus órdenes.
Y ya te digo, que la tool esta la puedes hacer en 2 horas contando que no sepas nada de nada de maxscript.

Como me consta que al final vais a hacer un exportador de MAX, lo unico que debeis hacer a la hora de exportar es exportar tambien la cadena de user defined properties (INode::GetUserPropBuffer(char*)).

Lo de los user defined properties lo podeis utilizar tambien para mas cosas. Yo por ejemplo meto ahi los lensflares (helpers con esa propiedad) y emisores de particulas (un helper sobre una antorcha por poner un simple ejemplo).


Un saludo,

      Ithaqua.

http://ithaqua.stravaganza.org



                               

[BeRSeRKeR]

                                Hola Ithaqua.

Gracias por el consejo. La verdad es que ProD y yo pensamos en lo del User Define para asignar propiedades a los objetos pero la verdad es que no pensé en ningún momento en el maxscript...¿crees que con la ayuda del SDK y los ejemplos será suficiente?...o conoces algún sitio donde pueda encontrar los conceptos básicos de maxscript...

Un saludo y gracias otra vez                                

[BeRSeRKeR]

                                Jeje a través de google he econtrado cosillas pero aún así si conoces algún tutorial interesante pues bienvenido será :ojo:

Un saludo                                

[Ithaqua]

                                Mas que tutorial, buscaría códigos fuente de ejemplo. La ayuda del maxscript es muy buena (si ya conoces el MAXSDK y la jerarquía de clases de MAX). Lo único ahora es aprender la sintaxis, que es muy sencilla, y saber como acceder a determinados elementos de la escena.

Suerte :sonriendo:


          Ithaqua.


http://ithaqua.stravaganza.org