Space Partitioning

[BeRSeRKeR]

 Well, we've a good portion of the space partitioning system finished. It's based on portals/sectors. The most challenging part has been the sector extraction based on an arbitrary list of polygons and portals placed by the level artist. Also, we've built a BSP tree (non-splitting BSP tree) that will allow us to know in which sector we are in. Also, the BSP tree will allow us to clip shadow volumes (that would be precalculated) for static objects/lights, decals clipping, etc.

Now we have to add special cases like mirror portals, portals that point to non-geometrically-contiguos sectors or portals that point to outdoor areas. Effectively, we want to allow automatic indoor and outdoor areas.

You can see a little video demo where you can see a level made by 7 sectors. All the time you can see a little description of the sector the camera is in (if we are not into the void). This description will be specified by the level artist into MAX. The only thing to do is place a custom MAX helper (sector locators, similar to Doom3) into the desired sector and specify its "description" property. The engine, at load time, will detect these entities and will assign the description to each sector that contains one of these entities.

Greets.

                       ----------------------------------------------

Bueno, ya tenemos buena parte del sistema de particionamiento del espacio terminado. Está basado en un sistema de portales/sectores. Lo más complicado ha sido extraer los sectores a partir de un sopa de polígonos y una lista de portales posicionados por el diseñador de niveles. También se ha creado un arbol BSP del nivel (no se lleva a cabo particionamiento de polígonos) para saber en todo momento en qué sector estamos. El arbol BSP también nos servirá para recortar los shadow volumes (que serían precalculados) de los objetos/luces estáticos, recortar los decals, etc.

Ahora habrá que añadir casos especiales como portales "espejo", portales que dan a otros sectores que no son geométricamente contiguos o portales que dan al exterior. Con exterior me refiero a por ejemplo un terreno, es decir, queremos tener tanto interiores como exteriores controlados de forma automática por el motor.

Podéis ver un pequeño video demostrativo donde se puede ver un nivel con 7 sectores. En todo momento se muestra en pantalla la descripción del sector en el que nos encontramos (si es que no estamos en el vacío). Esta descripción la especificaría el grafista desde MAX. Tan sólo tendría que crear una entidad especial (sector locators, algo similar a Doom3) dentro del sector y asignarle una propiedad "description" o algo similar. El motor, en tiempo de carga, detectaría esas entidades y le asignaría al sector que la contenga, la descripción correspondiente.

Saludos.

[zupervaca]

 Esta guapo, ¿pero implicaria curro de visibilidad al grafista desde el 3dsmax?

[Pogacha]

 

Esta guapo, ¿pero implicaria curro de visibilidad al grafista desde el 3dsmax?

Supongo que no, ... como mucho nombrar los sectores ...

Por cierto lo del video se ve realmente bien.

Lo de no partir las caras tiene ventajas y desventajas ... partiendo caras al proyectar sombras con stencil terminas procesando mas lado pero por otro lado las caras mas pequeñas pueden ser facilmente descartadas en el algoritmo de iluminación disparando el rendimiento.
Hay que lograr un equilibrio entre la cantidad de caras y su superficie visible que pueda ser descartada en oclusion tanto de visibilidad de la camara como de la iluminación.

Dicho sea de paso un enorme consejo para un optimo stencil-shadow: usar la estructura del medio borde!!!, entonces la determinación de silueta se vuelve lineal y trivial.

Saludos y mucha suerte.

[BeRSeRKeR]

 Vaya, me he colado con el mensaje de arriba (Haddd, cuando puedas elimínalo :)).

El grafista sería el responsable de posicionar los portales por lo que tendría que hacerlo con un poco de lógica. El hecho de que nos hayamos decantado por posicionar los portales manualmente es porque el BSP nos generaba un montón de portales/sectores que eran innecesarios.

Así es como se hace en juegos como Max Payne o Doom3 y creo que no es nada descabellado. Como digo sólo requiere que los diseñadores de niveles utilicen un poco la cabeza. :)

Saludos.

[Nato_msc]

 No se si estoy equivocado, pero eso es lo que usan los GTA nuevos, no? como se haria esa particion en el max? seleccionando los poligonos que quieras y dandoles una ID o algo? no entiendo aun de esto pero por preguntar.

Saludos.

[BeRSeRKeR]

 

No se si estoy equivocado, pero eso es lo que usan los GTA nuevos, no? como se haria esa particion en el max? seleccionando los poligonos que quieras y dandoles una ID o algo? no entiendo aun de esto pero por preguntar.

Saludos.

La verdad es que no tengo ni idea de qué sistema utilizan los GTA.

La partición se lleva a cabo en el motor (aunque más bien se trataría de una especie de compilador el que generaría el mapa final). En MAX, el grafista tiene que crear el nivel e ir posicionando los portales donde crea conveniente. El compilador requiere que la geometría satisfaga ciertos requisitos, pero la verdad es que no los considero "pesados" de cumplir.

En definitiva, el grafista crea el nivel, que no es más que una colección de polígonos y portales (obviamos los objetos de decorado y demás entidades porque no forman parte de la estructura base del mapa). Todo eso es la entrada para el compilador. Entonces el compilador genera los sectores y a cada portal le asigna un sector frontal y trasero. Finalmente crea un arbol BSP para todo el nivel. La salida del compilador sería un archivo con la lista de polígonos por sector, una lista de portales indicando qué sectores conecta y la lista de nodos del arbol BSP. Por ahora, la información que se genera es prácticamente idéntica a los archivos .proc que genera el compilador de mapas de Doom3 por lo que una vez que tengamos el sistema funcionando con nuestro formato, sería bastante sencillo crear un cargador de mapas de Doom3 (que de hecho, ya está desarrollado :)). Lo que es el sistema de visibilidad sería el mismo que ya tuviéramos implementado.

Saludos.

 Does this mean that the engine will need BSP compliant geometry if you want to use the
portal system ?
Constructing all levels with the BSP restrictions (only convex polygons) would be a little
bit painfull and it's a little bit outdated to require BSP compliant geometry for the levels.
It would make the use of the portal system also very complicated for architectural
visiualization, if the buildings have already been constructed in a non-BSP compliant
way.
But I hope I just misunderstood the above posts (I can only read a little bit spanish, so I could
not really follow the discussion in spanish).
Can you clarify if one will need BSP compliant geometry (like for 3D game studio or Quake) in order
to use the portal system ?


Thanks in advance and thanks for the nice engine  :)  

[BeRSeRKeR]

 

Can you clarify if one will need BSP compliant geometry (like for 3D game studio or Quake) in order
to use the portal system ?

The possible restrictions have nothing to do with the BSP because the BSP tree will be used to know in wich sector a point is in and for some splitting operations (among other things). But it won't be used for visibility determination purposes. Not even for sector extraction. Anyway, some of this requisites are similar to BSP ones.

The engine will support concave sectors. For example, if you've seen the video, there is a central room and 6 corridors (a hexagon). I could perfectly remove the portals in the hexagon and the compiler will generate a unique concave sector (plus the central sector).

Of course, the level designer should comply with two or three rules.

One of them is the use of convex polygons (but you can create concave rooms without the need of extra portals). One could fix this restriction easily using the "Turn to Poly" modifier and checking the "Keep Polygons Convex" (well, I don't know if this is considered a clean solution because it will put edges where MAX considers better, not where you think are better placed).



The other one is that every portal vertex has to be in touch with another vertex in the level geometry. That is, if you have a corridor and a portal in the middle, all the portal edges have to be in touch with other edges in the corridor (so the corridor has to be splitted with slice plane, for example). That restriction that sounds bad at first, will make the creation of the portals easier because you can create the necessary edges, select them, create a shape from this edges and finally convert the shape to a polygon. Ok, this task could be automatized using MAXScript. See the following image for clarification.



I know geometry restrictions/requisites are a pain in the ass but otherwise it would be really hard to extract the sectors from an arbitrary list of portals/polygons.

Anyway, we're open to suggestions to make the level creation process easier and less painful.

Greets.

 Quiza debierais hacer un tuto de ejemplo con un mapa pequeñito en el 3d max

por cierto ¿ servira para mapas outdoor?

¿que tal va el tuto del formato md5 y eso?

[BeRSeRKeR]

 

Quiza debierais hacer un tuto de ejemplo con un mapa pequeñito en el 3d max

Veré qué se puede hacer. De todas formas sí tenemos los sectores y el BSP ya terminados (o prácticamente terminados) pero ahora tenemos que estudiar el tema de las entidades. Por ejemplo aquí podrían haber dos opciones. O creamos entidades personalizadas en MAX o utilizamos el visor/editor de escenas para crear/posicionar las entidades. De esta forma no dependeríamos de programas de terceros.

por cierto ¿ servira para mapas outdoor?

Esa es la idea. Poder tener tanto interiores como exteriores de forma simultanea. El motor detectaría automáticamente si tiene que utilizar portal rendering o si tiene que utilizar el octree o si tiene que utilizar ambos. Este caso puede producirse si por ejemplo estamos en un sector con uno o más portales que dan al exterior. O por ejemplo si estamos en el exterior y estamos viendo un portal que evidentemente daría al interior.

¿que tal va el tuto del formato md5 y eso?

Antes de crear el tutorial sobre MD5 tengo que reestructurar el módulo de animación esquelética. Una vez hecho eso, que me imagino que será después de la visibilidad (aunque también tengo pendiente ver con Vicente el sistema para pathfinding), ya podremos escribir uno o los tutoriales que hagan falta. Eso sí, no sabría decirte cuándo va a estar terminado, pero terminarlos hay que terminarlos porque los necesitaremos para el juego.

Saludos.