El video es privado 
16 días después
Prometo algún día aprender a grabar GIFs como dios manda
Miniupdate:
- Ciclo día/noche y nubes aleatorias
1 mes después
#36 gracias por mantener tu interés!
El diseño e idea conceptual los tengo sobre el papel, pero no quiero ponerme a implementar la lógica para después descubrir que con 2 calles y 10 edificios, tengo 11fps (que ya me ha pasado).
Así que aunque no posteo nada, sigo con pruebas de rendimiento, colocando 1024 edificios sobre el mapa y ver como se comportan los scripts, cuidando los bajones de fps y analizando como reaccionan los milisegundos del 'main thread' y cuantos draw calls se ejecutan, etc etc
#37 Mirate las condiciones del dynamic batching de Unity http://docs.unity3d.com/Manual/DrawCallBatching.html
#37 Lee la documentación que te ha puesto #38 porque créeme, a mi me ha salvado el pellejo en estos últimos días.
En mi caso, yo ando con mi TFG y estoy con mallas procedurales, y veía que cuando ponía una, no había ningún problema, pero si me ponía a hacer Ctrl+C, Ctrl+V duplicando, incluso con una pequeña cantidad (10 GameObjects) el rendimiento caía hasta los 3 FPS. Te dejo unos cuantos consejos por aquí que quizás te sirvan a la hora de optimizar (seguramente la gente los sabrá porque son bastante básicos, pero son cosas que te salvan el pellejo):
- Si no vas a utilizar el método Update() en un MonoBehaviour, quítalo.
- En tu caso, como los edificios se van a repetir (aunque si bien habrá varios modelos, imaginemos 4 o 5), lo ideal es que todos compartan material y textura. De esta forma, solo se enviará una vez a la GPU, cogerá ese modelo y solo tendrá que replicarlo, aplicar transformaciones...
- Si te salen errores o mensajes de depuración muchos frames, ejemplo "Shader wants texture coordinates, but the mesh doesn't have them", esto es por los UVs, y creedme, el rendimiento se ve penalizado muchísimo.
- Creo que a la hora de recibir luces y proyectar sombras, en términos de batching, solo es válido el segundo.
- Utilizar Texture Atlas, por ejemplo con todas las texturas que pueda tener un GO. Ejemplo, tus edificios a lo mejor tienen X texturas diferentes (una por cada fachada + otra para el tejado), y si las colocas en archivos / materiales / texturas diferentes, si bien es posible que consigas cierto grado de batching, las drawcalls serán mínimo X, y posiblemente X * número de edificios.
En cambio, si las empaquetas en un fichero, las reducirás a 1, porque la GPU solo tendrá que cargar un fichero.
¡Un saludo y ánimo!
P.D A ver si me animo yo también a crear un post explicando lo que estoy haciendo, ya que he sacado bastantes conclusiones o trucos que pueden ayudar a otros.
P.D.2 No hace falta decir que prefabs FTW!
muchas gracias #38 y #39, por vuestros consejos y experiencias, pero creo q mi problema va mas relacionado al recolector de basura de Unity y al memory management.
http://docs.unity3d.com/Manual/UnderstandingAutomaticMemoryManagement.html
En esa captura se pueden apreciar 708 drawcalls que no están nada mal (en mi opinión, no se que opináis vosotors) teniendo en cuenta que hay numerosos shadow projectors para las sombras de las nubes, hard shadows en tiempo real con una luz direccional y multitud de edificios apegotonados (de hecho, el renderer marca 4.1ms lo que creo que no esta nada mal).
Pero por otro lado, creo que mi problema va relacionado con el scripteo porque el main thread tiene nada menos que 53.8ms (con la consecuente bajada de frames).
Si comienzo a desactivar scripts como el control de la fecha y hora, o cualquier otro, los ms se mantienen, pero si dejo un buen rato el proyecto ejecutándose, se estabiliza y vuelvo a tener 60fps
#40 pues si, algo raro tienes en los scripts... mirate este enlace, sobre todo el punto 3 http://docs.unity3d.com/412/Documentation/ScriptReference/index.Performance_Optimization.html
Si tuviera que apostar así a ojo y sin tener ni idea diría que lo que se come tu rendimiento son las físicas. Viendo tu gif de #2 parece que los edificios tienen todos rigidbody. ¿Puede ser que tengas un fixedframerate demasiado rápido? ¿O que los colliders sean muy complejos?
También puede ser cosa del QualitySettings, pero creo que eso se vería reflejado en el tiempo de Render y no en el del hilo principal.
Anoche sobre las 03:30am por fin solucioné los problemas de rendimiento con el main thread (aunque estaba demasiado cansado para postear).
Probe a desactivar los rigidbodies #42 para que Unity no tuviera que calcular 1024 cuerpos (aunque eran simples box colliders discretos). No solucionó demasiado el rendimiento.
Resulta que como bien aconseja el manual del buen uso de Unity, las operaciones constantes sobre arrays y strings en update() hace que el recolector de basura no de abasto. El hecho de que en cada update() se haga recorrido iterativo completo a un array, quema literalmente la memoria y el thread, por lo que la solución pasa por modificar el/los elemento/s <i> necesario/s para cada update (no vale recorrer y comprobar if en cada celda de array).
Luego, el control de tiempo que constantemente modifica el GUIText de la fecha y hora también consumía más de lo normal, por lo que el consejo de unity es modificar multiples GUIText mejor que uno tocho (uno para la fecha y otro para la hora).
( Apartado optimization de http://docs.unity3d.com/Manual/UnderstandingAutomaticMemoryManagement.html )
Actualmente mi main thread oscila entre 1320ms con 1000 prefabs colocados y las nubes aleatorias, lo que viene siendo en mi opinión un éxito, teniendo en cuenta que mi portátil es un Core2Duo T6400 y 4GB de RAM.
Otra cosa que he leído es que en lugar de usar projectors para las sombras de las nubes, me invente unos planos con textura de la sombra, lo cual reduce enormemente la carga de draw calls (hoy cuando salga del curro cambiaré eso)
3 meses después
El proyecto ha seguido y sigue adelante (muy lento por mi parte desgraciadamente, aunque constante).
Con la apreciada colaboración de mr_badger como modelador y decenas de pruebas:
No os imaginais lo que anima saber que hay gente que sigue ahí con interés en este proyecto. De verdad, gracias
#50 La comisaria esta muy muy en WIP en esa imagen 
Entre el curro y valki apenas tengo tiempo de ir trabajandolo 
pero poco a poco, cuando puedo, voy progresando.
La comisaría tiene que tener una antena en el tejado para las radiocomunicaciones, yo creo que es lo que le falta, y ya para que no quede tan soso el tejado una H en un circulo de las que utilizan los helicopteros para aterrizar...
#51, ¿esos son los highpoly? Si no es así, creo que para mejorar rendimiento podrías bakear ese "high" en una caja ( sin más ) con un normal de 512 o incluso 256, dependiendo cómo llegue a verse de pequeño... Espero que la palabra Police no esté modelada... xDD
Veo demasiados polígonos si se pretenden hacer graaaaaandes ciudades. Just a tip 
.
Buen curro y genial la idea.
Si, esas son las highpoly. Solo la imagen de este edificio es lowpoly, como se vera en el juego.
Creo que rondaba los 300 tris + textura diffuse de 512x512 + normal (creo que al final la dejamos en 256x256)
No es mas que un cubo con los salientes de las columnas + el tejado, para reducir ya se tendrian que quitar los assets del tejado o el aire acondicionado.
Dios que ganas tengo de pillarme un pc nuevo y hacer algo de esto! (es que juego en una tostadora de la prehistoria...)
Animo con el juego!
#55 No es mala idea, incluso, es algo que debeis tener en mente desde ya, el tema de los LOD. No te interesa tanto detalle cuando estás lejos de ese edificio.
CitiesXL lo hace, y se nota, y no se sonrojan, es lo más normal del mundo.
Yo defino el PFG de mi carrera como un "GTA pero para aprender a conducir", asi que ahora estoy muy inmerso en la creación de una ciudad ( que no hacerla como tal el usuario) y darle IA a los patones, tráfico y una buena lógica semafórica. Si necestais algo heme por aqui.
Also, estoy muy atento por si se me cae la baba con algo de lo que monteis xD
Suerte.
