Necesito alguna fórmula o solución mágica para reducirlos. Bajé un asset para reducirlos,pero sigue consumiendo bastante,la cpu se pone sobre el 20%.¿Alguna idea,recomendación o solución?
Gracias.
La primera que se me ocurre y muy buena es usar static batching, todo lo que no se mueva se pone a "static", proba antes y despues y vas a ver como mejora.
Cita de: lightbug date=1484424893La primera que se me ocurre y muy buena es usar static batching, todo lo que no se mueva se pone a "static", proba antes y despues y vas a ver como mejora.
Como dice el compañero lightbug, static batching y también oclussion culling... Prueba también aplicando lods a los modelos (levels of detail) y... No se me ocurre ninguno mas... Los hay pero no me vienen ahora xD
Los modelos del mapeado los tengo con lods y con static. No se ya que hacer.
Cita de: diegin2 date=1484425877Los modelos del mapeado los tengo con lods y con static. No se ya que hacer.
Has hecho oclusión? Tanto modelo tienes en la escena?
uh si ya tenes todos esos estas bien jugado jaja. Podrias especificar tu pc, como es tu escena, y todo lo que puedas. eso ayudaria mas.
Usa texturas atlas. Si tienes 4 texturas de 256x256 puedes crear atlas que ocupen 512x512 (uniendo las 4 texturas en una sola) de está forma puedes usar un mismo material para varios objetos que de otra forma tendrías que usar un material diferente por textura.
Es un morpg...pero bueno, tampoco tengo tanto modelo. Creo que es el oclusion...jeeeee vaya tela.
Cita de: OldGuy date=1484427010 Usa texturas atlas. Si tienes 4 texturas de 256x256 puedes crear atlas que ocupen 512x512 (uniendo las 4 texturas en una sola) de está forma puedes usar un mismo material para varios objetos que de otra forma tendrías que usar un material diferente por textura.
Puse un asset para hacer eso,bajó algo pero no lo suficiente. Igualmente creo que es el oclusion :( ahora testeo y os digo.
Vale era eso....
Gracias a todos por las respuestas. :))
Buenas, me encontré recientemente en la misma situación. Hice todo esto y ahora el juego va muy bien:
- Static batching: todos los objetos con el mismo material (esto ya lo hice desde el principio). Una textura común para todos, en blender mapeo cada objeto donde me interesa, y luego en unity mismo material (y shader por supuesto) para casi todos los objetos. Luego los marcas static y así el static batching de unity puede actuar y te los renderiza todos a la vez reduciendo los drawcalls muchísimo. Hay assets que te los juntan todos a posteriori, te crean atlas de texturas etc, pero no me fío mucho por lo siguiente: si utilizas el static batching de unity los objetos se renderizan en un solo drawcall pero siguen siendo susceptibles de ser ocultados por el culling individualmente. Algunos assets lo que hacen es generarte una malla gigantesca con todos los objetos que te mergean, reduce drawcalls pero entonces ese objeto enorme o se pinta o no se pinta, va todo a la vez, y hace que el culling no sea tan eficiente.
- Camera.layerCullDistances: distribuye bien los objetos en capas de manera que luego puedas configurar el array Camera.layerCullDistances. Este array determina, para cada una de las 32 layers, la distancia del farClipPane de la cámara, o sea, los objetos de esa layer no se renderizan más allá de esa distancia. Las montañas y cosas grandes puedes poner distancias más grandes para que se vean desde lejos pero los props y objetos pequeños hasta que estás cerca no hace falta que se rendericen. La vegetación es un caso intermedio, hasta puedes tener varias layers para vegetación, los árboles se ven más de lejos y las plantas más de cerca. Ajustando bien la distancia de renderizado de cada layer te puede ahorrar muchísima geometría y drawcalls (tampco te pases porque entonces aparece el poping, puedes meter niebla pero la niebla en el manual la desaconsejan en la medida de lo posible...)
- Usar el sistema de LOD con los objectos grandes que se vayan a ver desde lejos (esto lo tengo a medias, no me es muy necesarios porque mis objetos tienen una geometría muy simple)
- Culling: este mecanismo evita que se rendericen los objetos que están ocultos tras otros. Antes que nada te recomiendo que, en la vista de escena, en el desplegable de la parte superior izquierda, cambies el modo de renderizado a "Overdraw". Yo aluciné cuando lo hice. Ahí puedes ver la de geometría superpuesta que tienes, si mueves la cámara verás que hay puntos en los que se está renderizando muchísimo más de lo que ve el usuario. Ok, para minimizar esto se utiliza el culling (hasta donde yo sé). Tenemos el frustum culling y el oclussion culling. El primero hace que todo lo que queda fuera del frustum de la cámara no se renderice. Esto lo hace Unity de forma automática, no tienes que hacer nada. El segundo lo tienes que activar en la cámara y luego desde la ventana Oclussion culling configurar y bakear (mira en el manual de Unity). Una vez activado el oclussion culling el cambio es bestial. Eso sí, para que sea efectivo tienes que tener en mente una serie de cosas: no hagas objetos muy grandes porque a la que aparece un vértice en pantalla se renderiza el objeto entero; y diseña tus niveles teniendo el oclussion culling en mente: no hagas zonas abiertas enormes ni habilites puntos altos desde donde se pueda ver mucha cosa, pon en el escenario objetos a modo de separados para que el OC puede esconder todo lo que hay detrás. En fin lee esta parte del manual, vale mucho la pena
- Profiler y Frame debugger: estas dos ventanas no tienen precio. Hasta hace poco los usuarios Free no disponíamos de esto (ni del oclussion culling) y los juegos eran prácticamnete imposibles de optimizar. A mí el frame debuger me encanta, para cierto frame puedes ver paso a paso todo lo que hace unity y ahí te encuentras con muchísimas sorpresas: sistemas de partículas que se siguen calculando pese a no estar en escena, objetos de los que ni te acordabas que utilizan un material diferente que se está tragando drawcalls, objetos GUI que se tragan drawcalls cada vez que aparecen, etc... es muy muy muy util. El profiler aún recién estoy empezando a explotarlo pero es que ya con el frame debugger he pulido muchísimo el juego.
- Skybox: por defecto y hasta donde yo sé el sistema de Skybox de unity se traga nada menos que 6 drawcalls (uno por cada cara del cubemap). Existen técnicas para reducir estos 6 drawcalls a 1. He leído que hay que utilzar un cubo con las normales invertidas hacia dentro y atacharlo a una cámara que servirá exclusivamente para renderizar ese skybox. Aún no lo he intentado, ahora mismo estaba en ello, de momento para probar simplemente quita el skybox de tu juegos a ver qué tal.
- Lightmapping: mi primera regla en este sentido es no utilizar luces, sólo 1 direccional para toda la escena. Pero bueno más allá de eso lo mejor es bakear la iluminación en lugar de hacer que se calcule en realtime. He explorado poco este aspecto porque como te digo intento no utilizar luces (mi target son los móviles de gama baja).
- Mira en le manual de unity 5.5>Graphics>Graphics overview>Optimizing graphics performance. Casi todo lo que te cuenta ahí es super interesante (ejemplo: muchos shaders implican varias "capas" de renderizado y todo eso va tragando drawcalls, utiliza los shaders con cuidado y lo más sencillos posible).
Bueno no se si me dejo cosas, seguro que sí, pero vamos que utilizando todo esto en unos días el juego tendría que funcionarte mucho mejor.
En cuanto a reducir los 6 drawcalls del skybox al final he optado por el shader Skybox\procedural que ofrece Unity. Ni lo conocía, lo he descubierto de rebote.
No tienes nubes ni historias pero queda genial si lo configuras un poco y además en runtime supongo que lo puedes mani***r desde c# para crear efectos realmente chulos. 1 drawcall, perfecto. Otra cosa es la memoria que trague, esto aún no lo estoy midiendo, de todos modos he deployado mi prototipo en un móvil cutre con el skybox procedural y va perfecto, impacto cero, así que veredicto: ES UNA MUY BUENA OPCIÓN.