UnityCity - Diario de desarrollo

Leoshito

El video es privado :(

Crucialhunte

Tienes todo mi interés y atención, con ganas de ver el progreso que realizas en el juego.

16 días después
13500

Prometo algún día aprender a grabar GIFs como dios manda

Miniupdate:

  • Ciclo día/noche y nubes aleatorias

3 1 respuesta
N

#33 El código de las transiciones está genial. Pero la transición de colores da la sensación de que vaya a explotar todo en una gran seta de humo nucelar xD

1
13500

un poco de inspiración

4
1 mes después
mr_badger

Como van los proyectos? has tenido tiempo para algún avance en unicity o Tarsis?

1 1 respuesta
13500

#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

4 2 respuestas
r2d2rigo

#37 Mirate las condiciones del dynamic batching de Unity http://docs.unity3d.com/Manual/DrawCallBatching.html

2 2 respuestas
Fadolf

#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!

3 1 respuesta
13500

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

2 respuestas
r2d2rigo

#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

2 1 respuesta
Czhincksx

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.

1 1 respuesta
13500

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)

gracias de nuevo a #41 y #42

3
karlozalb

Me apunto todos los consejos, no tenía ni idea de eso de los GUIText :O

13500

Generación aleatoria de terreno mediante un único parámetro a elegir por el jugador: nivel de escarpado (entre 1 y 10)

edit:

#1 actualizado con las screens/gifs que he ido subiendo

8
3 meses después
Peilo

al final que pasó con esto?

B

Espero que no lo haya dejado, pintaba de puta madre xD

Crucialhunte

Coincido, de los pocos hilos en favoritos en mi lista y deseando que siga adelante.

13500

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

1
Kaos

Muy guapas las texturas del edificio.
Al de policía se le echa de menos algún adorno en el tejado.

2 respuestas
mr_badger

#50 La comisaria esta muy muy en WIP en esa imagen :D

Entre el curro y valki apenas tengo tiempo de ir trabajandolo ;( pero poco a poco, cuando puedo, voy progresando.

1 2 respuestas
Foni

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...

1 respuesta
13500

#50 #52 tranquilidad, como bien dice #51 es un WIP under development muy temprano. Vamos, que no debería ni haberlo posteado pero por enseñaros cosas... xD

1
_dGr_

#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.

1
mr_badger

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.

2 respuestas
_dGr_

#55 Entonces está de lujo. ;)

E

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!

Srednuht

#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.

1 respuesta
Hipnos

_

Simcity 2000 fanboy here.

1 respuesta
mr_badger

#58 No se si 13500 lo habra pensado o no. Yo solo ayudo lo que puedo en temas graficos. El es el dungeon master :D

2