Lightmaps Implementados

[BeRSeRKeR]

 Mientras Haddd anda peleándose con la librería de Newton (la física), yo he estado haciéndole un buen lavado de cara al exportador de MAX para dar soporte a los temas relacionados con el portal rendering, y ya que estaba, decidí exportar todos los canales de mapeado que un objeto soportara. Una vez hecho esto ya teníamos lo necesario para implementar los lightmaps en el motor, así que he estado haciendo unas pequeñas pruebas para ver si todo funcionaba bien y aquí está el resultado:



Como veis no me he matado con la escena de pruebas... :D



La cuestión ahora mismo es saber cada canal de mapeado para qué se va a utilizar. Es posible que demos esa posibilidad al usuario a través de editor de materiales que estamos desarrollando.

La pega que le veo al tema del render to texture de MAX para generar los lightmaps (aunque lo cierto es que sólo he estado trasteando con él unas pocas horas) es que si la escena se compone de objetos separados, te genera un archivo de textura para cada objeto, lo cual es una locura. Si alguno conoce alguna forma de poder crear los lightmaps en un sólo archivo de textura sin tener que asociar los objetos en uno sólo, estaría bien que lo dijera. :)

Y nada más por ahora, después de esto toca seguir con el portal rendering sobre el cual ya tengo bastante código escrito, así que espero terminarlo pronto...

Saludos.

[vincent]

 pues por lo que yo sé, no hay manera humana de juntar los lightmaps en uno solo. Te crea uno por objeto. Te podrias currar un algoritmo para juntarlos ( en el libro de Dani Sanchez-Crespo hay uno explicado ) aunque quizá es un poco matada...

Suerte!

[donald]

 
Supongo q tb sería útil pa quien vaya a usar el motor tener al menos un canal mas de multitexturing, o sea, para poder poner parches de textura y tal, que viene muy bien poder super pone reso a un canal1 de textura tiled, q queda muy aburrido si no....

Lo del render to texture...lo conozco poco pq lo mío son los personajes, y objetos, no edición de niveles.

Pero... Lo de attach, está el cuadradito en el modificador ed edit ploy o edit mesh, al lado de "attach", o attach list, no recuerdo, que permite hacer un attach a lo bestia del objeto seleccionado con todos los de la escena, los que selecciones de la lista....se hace en 1 segundo....


Pudieras tener el problema contrario, que tengas que partir un suelo en trozos para que no se vea el dentado por baja resolución...para eso puedes usar el deconstructor, un script....scriptspot.com.....

El render to texture tiene la mala cosa de que las UVs automáticas de Max no son muy allá. Puede que prefieras mapearlo tú, con un Unwrap modifier usando el canal 3 (en el mismo modificador unwrap uvw)...y luego desmarcar en rendertotexture la checkbox de automatic uv mapping...Es importante controlar bien la distancia, y escala,(el típico lightmap con demasiado espacio entre objetos), edge padding a veces conviene ponerlo a cero... y algunos settings... No es nada trivial.

Tener muchos lightmaps no sólo no es malo, sino que para un area grande, es ideal, pero de 512x512, o 256x256 por ejemplo....Quake3 creo que usaba de 128x128 o menos en sus bsp. Fsrad tb te lo hace así.

SI tienes que cortar pero no en plan grid, que es lo que hace el maxscript deconstructor, el slice plane de max suele ser muy socorrido.

Yo prefiero hacer mis propias UVs, incluso aunque use flattens automáticos, box mappings trabajaos + pack uvs....y escalar lo que yo quiero que tenga mas res en un lightmap de un objeto determinado....

Aunq muchas texturas o lightmaps tb pueden ser un cuello de botella, no sé yo, uno grande de 2048x2048 freirá muchas tarjetas....

[donald]

 
Y por cierto, otros lightmaps sistemas que yo habré usado, giles y fsrad, tienen otra forma de funcionar...

Giles se basa en materiales....le da igual el numero de objetos, en realidad, pero sin importas objetos de uno en uno, puedes optar por general materiales nuevos, con lo que generas tb lightmaps nuevos...o usar el existente, con lo q el mismo lightmap será pa toda la escena.

Fsrad se parece más a esas inhouse tools (no me hagais mucho caso, pero creo que Valve uso una hecha en casa, y no el xsi rendermap(yo lo tengo comprado, pero no he conseguido hacerlo rular bien, como me gusta, aún, pq lo he comprado por la animación de personajes))  , más como los generadores de bsp....simplemente es una solución  por radiosidad, como Giles y render to texture si usas eso (por cierto, si no usas radiosidad, la de max, o algun chisme como final render, o brazil, los lightmaps serán de bastante menos calidad) ....que se encarga de gestionar el número de lightmaps que ncesita: aunque lo haga todo a 128x128, no notarás un puto seam, ni un fallo, ni nada... la pena es que no genera lightmaps sobre superficies curvas, o sea, lo hace pero en plan faceted. Una autentica lástima: da calidad, es fácil limitar el tiempo de cálculo, es free y open source, muchos coders han hecho ya sus versiones (Murphy, Lord trancos...) ...yo tengo herramientas incluso para pasar esos resultados a objs y tgas.

Pero vaya, mejor que os sigais centrando en Max, que si no es un follón que ni te cuento, además, de que habrá límites serios. (si no hubierais hecho tanto soporte de max, casi os diría otra cosa, ahora sería una barbaridad)

Bueno, todo esto os lo cuenta un tipo especializado en personajes, así que no me hagais mucho caso, que habré dicho alguna barbaridad. Solo os cuento lo poco que sé, de como yo me las arreglaba.

[donald]

 pero a lo que preguntabas, es muy fácil, simplemente selecciona un objeto, y usa "attach list" o el icono de cuadradito de al lado, que no recuerdo de que forma era, y te permite attachar todos de golpe, o selecciona de la lista con ctrl y shift... ;)

[BeRSeRKeR]

 Donald, efectivamente el método que he utilizado para esa escena ha sido el "attach" de "Edit Poly". Con respecto a lo de los canales de multitextura, efectivamente uno de los usos, además de los lightmaps, podría ser añadir "detail textures" para disimular la repetición de las texturas o dar apariencia de mayor complejidad. Ahora con la exportación que hacemos se podría hacer. Lo único que habrá que hacer con bastante probabilidad es modificar el editor de materiales para que el usuario pueda especificar cada canal de mapeado para qué se utilizará y cómo se mezclará con el anterior.

Por otra parte, podría ser una buena idea hacer lo que dice vicente, un empaquetador de lightmaps. Habrá que pensar en ello. :)

Gracias.

[[Vil]]

 Tambien se puede hacer en plan cutre. Abres la textura de un objeto desde el unwrap, reescalas todos los vertices del mapa uvw a un cuarto de textura y los pones en una esquina. Haces lo mismo con otro objeto y lo pones en otra esquina,etc... Luego renderizas y con photoshop juntas las 4 texturas en una que pueden usar los 4 objetos. Es una solución cutre, pero no se me ocurre otra...
Quiza agrupando los objetos, puedes desplegar todo el grupo entero, luego desagrupar... o colapsar antes la pila... no se, supongo q to es probar (Uno toy en casa y no tengo max pa probar, pero cuadno llegue lo intento)

Saludos

[donald]

 si no recuerdo mal, lo detecta por objetos...como él lo tiene en trozos, es fácil. Sólo hacer un attach list...

eso si está usando uvs automáticos, o tiene hechas ya las Uvs de esa manera, que encajen los uvs unos con otros en uno cuadro común.

puedes recargar las UVs sallvando y cargando en ficheros de uv externos, desde el mismo modificador.  Tb hay un script que funciona, que permite aplicar un unwrap uv a multiples objetos a la vez.

[BeRSeRKeR]

 El problema que yo le veo a lo del "attach" es que por ejemplo habrán objetos a los que le habrá que asignar cierta información extra que se le pasa a través de las "user properties". Entonces si asocio todo en un sólo objeto, pierdo toda esa información y luego al hacer "detach" ya no se recupera. Sí es cierto que se podría crear un script que automatizara el proceso del "attach" y luego el "detach" de forma que dejara los objetos tal y como estaban. Y como al hacer el detach supongo que no se perderá el mapeado, ¿no?. Habrá que pensar en ello.

Otra cuestión es que habrán objetos que por su complejidad, necesitaran mayor resolución, y por lo tanto, un archivo para almacenar el lightmap para ellos sólos. Si no recuerdo mal, en quake3 sólo para lo que era el nivel se calculaba el lightmap. Para los "detail meshes" (estatuas, por ejemplo) la iluminación era per-vertex. Esa podría ser una razón por la que no calculaban lightmaps para ellas, al igual que tampoco entraban en el proceso de "BSPización" (menuda cantidad de splits habrían si lo hicieran). :D

Gracias.

[donald]

 "Y como al hacer el detach supongo que no se perderá el mapeado, ¿no?"

No se pierde. No debería. Vamos, yo lo hacía con frecuencia.

Puede que si haya algun marrón cuando realmente cortes la malla(slice plane o deconstructor script ), y ni aún así...


a lo de las propiedades no le veo otra q un script...
volvarlo a un archivo de texto y después recargarlo ?
No sé, le veo de entrada algún problema...

hmmm...

No sé...si podrías generar el lightmap con una version atachada de la malla, y luego asignarla de algun modo usando las mallas vieja...complicado.

No...estás generando mapping automatico del render to texture, casi seguro...serían otras UVs...

Yo lo que haría sería: Attachar todos, generar el lightmap (si de veras lo quiero todo en uno, que suele ser que no) grande, en el modificador, guardar las UVs en un archivo q exporta, cargar la escena con objetos multiples,  y luego usar un script que hay para aplicar un UNWRAP UVW a multiples objetos. En ese modificador, seleccionar el canal uv 3 tb en la persiana del modifcador,  "load  uvs" , y cargas el fichero de la malla attachada de antes (si no has cambiado la malla en algo) . Una vez cargada, ya está, el tga que vale es el que tenías generado de la malla "toda-una" .En principio esto estaría haciendo eso que decían arriba de que cada objeto tendría unas uvs, usando parte del espacio  UV, y claro, cogiendo la parte correspondiente de textura (lightmap) , y en el canal 3.

Apuesto lo que sea a que no sale XD

[donald]

 eh...sí. precisamente ahí está el quid. Como tengas objetos muy detallados y con detalles de malla pequeños, no te imaginas lo que puede dar de problemas eso...hay que vigilar opciones como edge padding, y muchas otras.

Esos objetos es mejor que sean aparte y que dispongan de un tga de lightmap para ellos.

No tengo casi ni idea de este tema, de todos modos. Soy de personajes, pero por si te sirve de algo.


porque era tan malo que te hiciera a lightmap por objeto?  No puedes poner que haga lightmaps de 256x256 ?

[BeRSeRKeR]

porque era tan malo que te hiciera a lightmap por objeto?  No puedes poner que haga lightmaps de 256x256 ?

Yo lo decía por no hacer tantos cambios de textura pero bueno, tal vez exageré. :)

De todas formas, teniendo en cuenta que en quake3 los lightmaps son de 128x128, en una textura de 512x512 cabrían 16 sets de lighmaps de los de quake3 lo cual es un número bastante majo...aunque en quake3 creo recordar que habían mapas que sobrepasaban esa cifra.

Pero bueno, ya veremos qué solución le damos. De todas formas la idea inicial del motor era que todo fuera dinámico y en eso estamos trabajando así que no creo que nos matemos con los lightmaps. :D

Gracias por las propuestas.

[vincent]

 Por si te interesa BeRSeRKeR, esto lo he encontrado en flipcode:

http://www.blackpawn.com/texts/lightmaps/default.html

Saludos!

[Haddd]

 jejeje. Acabamos de implementar el packing de lightmaps. Ahora mismo, al convertir la escena, si tiene lightmaps, el motor empaqueta los lightmaps con el tamaño de texturas que especifica el programador.

Supongo que pronto pondremos alguna imagen, porque el sistema está funcionando desde ayer.  ;)  

[vincent]

 ole vaya cracks! ya tengo ganas de tener por aqui algun exe vuestro en el que se pueda uno pasear por un escenario...  :P

Seguid asi!  (ole)