Jump to content
zelleGames

[GAME] BLOODSHOT EYES

Recommended Posts

Buenas os dejo algunas imágenes, a ver como veis el paso a modo linear, le puse un poco de Occlusion ambient y baje mucho las luces para que se viese más oscuro, he peusto algunos comentarios en los pies de las fotos de problemas que me han surgido al cambiar al modo linear.

 

En las fotos se ven los FPS todavía me queda optimizar cosas. ¿cuanto consideráis que es un rango bueno? Me gustaría conseguir un mínimo de 60FPS para asegurarme que va a ir bien en otros ordenadores más lentos. Según las stats de Unity va sobre 60 70FPS pero el script me da bastantes menos.

On 10/3/2018 at 11:50, Adrianete said:

si,eso es, tanto el tamaño de paso como lo que tarda el sonido, yo lo veo muy largo, pero supongo que sera a gusto del consumidor. el sonido de los pasos tmb se puede regular pero no recuerdo como, ves probando que si se puede.

Ya cambie esto y el sonido de los pasos va acompasado con el movimiento, parecía una tontería pero restaba inmersión.

 

 

Captura de pantalla (23).png

Aquí es donde se ve el efecto raro, la textura parece de cartoon, poco realista. Le quite el checked de RGB a la textura como indican en el manual de Unity pero sigue igual.

 

 

Captura de pantalla (14).png

 

Captura de pantalla (16).png

 

Captura de pantalla (17).png

Captura de pantalla (20).png

El baño queda bastante chulo con el modo linear, aquí se ve que a causa del espejo bajan bastante los FPS

 

 

Captura de pantalla (22).png

Esto se ve fatal también, se supone que es vaho y en modo linear se ven mucho los perfiles de la textura.

 

 

Captura de pantalla (25).png

Captura de pantalla (27).png

 

 

Captura de pantalla (31).png

 

saludos¡¡

Captura de pantalla (33).png

Edited by memonic

Share this post


Link to post
Share on other sites

A las particulas puedes bajarles el alpha para que queden mas sutiles. Si estas usando el postprocessing configura el tonnemaping (color grading) ahí vas a poder conseguir el ajuste global de iluminación y que empaste mejor todo (con el exposure controlas si quieres que se vea más iluminado o más oscuro) luego tienes el eye adaptation que da un effecto muy chulo al pasar de zonas iluminadas a oscuras y viceversa . el bloom actívalo y no te cortes en exagerarlo, luego le vas quitando y ajustando de forma mas fina, el AO este consume un poco más de recursos pero para juegos de terror lo veo casi imprescindible a no ser que bakees. Eso por la parte visual lo va dejar cañon.

Por la parte de rendimiento, como consejo para ir averiguando que te baja los fps: clona la escena, mete todos los props en un gameobject vacio o varios, create comandos para desactivar/activar esos gameobjects, las luces y en definitiva practicamente todo lo que tengas en la escena. Es la forma que utilizamos Lightbug y yo en mi demo para averiguar que era lo que pegaba bajones.

Como consejo final para que no repitas mis errores. En lugar de utilizar static ocludees y ocluders utilizo triggers para desactivar los objetos que no quiero que se vean (MAL), si te enseñas a manejar bien el oclusion culling eso que te ahorras. Fijate mucho en los tris y en los shadow casters, los fps que marca el stats no son fiables, has hecho bien en crear un contador aparte.

Saludos y espero que consigas solucionarlo. En lo que pueda intentaré echarte un cable.

Share this post


Link to post
Share on other sites
On 20/3/2018 at 12:47, memonic said:

En las fotos se ven los FPS todavía me queda optimizar cosas. ¿cuanto consideráis que es un rango bueno?

yo por lo que he visto en juegos de play 4, a partir de 30 fps ya es aceptable, 60fps las aventuras y min 90 el VR.

 

On 20/3/2018 at 12:47, memonic said:

Esto se ve fatal también, se supone que es vaho y en modo linear se ven mucho los perfiles de la textura.

prueba a poner la dust storm de las partículas de standart assets y lo pones todo en grises, sin quitarle el color.

y para los sustos a lo mejor si le haces una animacion al cromatic aberration del post proccesing quedaría chulo tmb (por ejemplo cuando cae el osito del techo, ponerle el cromatic casi a tope con una animación y luego que baje)

On 20/3/2018 at 12:47, memonic said:

Ya cambie esto y el sonido de los pasos va acompasado con el movimiento, parecía una tontería pero restaba inmersión.

es verdad, restaba realismo.

¿has subido algún archivo mas reciente del juego?

Edited by Adrianete

Share this post


Link to post
Share on other sites
On 3/20/2018 at 4:47 AM, memonic said:

En las fotos se ven los FPS todavía me queda optimizar cosas. ¿cuanto consideráis que es un rango bueno? Me gustaría conseguir un mínimo de 60FPS para asegurarme que va a ir bien en otros ordenadores más lentos. Según las stats de Unity va sobre 60 70FPS pero el script me da bastantes menos.

Yo te recomendaría usar el profiler en todo, y mejor aún usarlo directamente en la build, es decir, haces un development build con la opción del profiler (no recuerdo bien como se llama), dejas el editor abierto, das a play (a la build obvio) y pasas por los lugares críticos del juego, minimizas el juego (rapidamente, alt+Tab) y volvés al editor, de ahí a partir de la info que te da vas a poder saber bien que te provoca las bajadas.

 

On 3/20/2018 at 4:47 AM, memonic said:

Esto se ve fatal también, se supone que es vaho y en modo linear se ven mucho los perfiles de la textura.

que shader estás usando para ese material?

On 3/20/2018 at 4:47 AM, memonic said:

Aquí es donde se ve el efecto raro, la textura parece de cartoon, poco realista. Le quite el checked de RGB a la textura como indican en el manual de Unity pero sigue igual.

Eso ya va mucho en que tipo de textura usas, la "escala" (uv's), los maps que usas (occlusion, normal, specular, etc) y sobretodo también el shader.

A simple vista podría adivinar que ese normal map no es el que debería ser, o que lo creaste a partir de algun plugin? quizás de gimp o photoshop? no lo se. Mira esta es una textura de madera en un proyecto de por ahí que tengo (fijate como el normal map va a la perfección con el albedo .... en la imagen no sale igual definición, no se porque será , dale click):

madera.png

 

Edited by lightbug

Share this post


Link to post
Share on other sites
hace 8 horas, lightbug said:

Yo te recomendaría usar el profiler en todo, y mejor aún usarlo directamente en la build, es decir, haces un development build con la opción del profiler (no recuerdo bien como se llama), dejas el editor abierto, das a play (a la build obvio) y pasas por los lugares críticos del juego, minimizas el juego (rapidamente, alt+Tab) y volvés al editor, de ahí a partir de la info que te da vas a poder saber bien que te provoca las bajadas...

no sabia que se podia usar el profiler en el built, parece util, thanks

Share this post


Link to post
Share on other sites
6 hours ago, Igor said:

no sabia que se podia usar el profiler en el built, parece util, thanks

Sí, no es super necesario pero si estás tratando de ver realmente de donde salen algunos inconvenientes, por ej los muy conocidos GC allocs, te vas a dar cuenta que el profiler en el editor te miente, ya sea por algunas cosas de Debug o el mismo overhead que mete hacer cosas en un Editor. En mi caso se acumulaban, el gráfico junto con la tabla decía cualquier cosa, no te dice de donde salen ni nada (incluso con "deep profile"), cuando pasas al modo build no había nada de nada, todo bien. Yo lo probé luego de ver una de esas "Unite", un tipo pasó por un montón de cosas y una de ellas era esto.

Igual, no digo que este sea el caso, acá esta claro que los problemas serán gráficos o físicos, cosas mas tangibles seguramente.

Share this post


Link to post
Share on other sites

 

hace 2 horas, lightbug said:

Sí, no es super necesario pero si estás tratando de ver realmente de donde salen algunos inconvenientes, por ej los muy conocidos GC allocs, te vas a dar cuenta que el profiler en el editor te miente, ya sea por algunas cosas de Debug o el mismo overhead que mete hacer cosas en un Editor. En mi caso se acumulaban, el gráfico junto con la tabla decía cualquier cosa, no te dice de donde salen ni nada (incluso con "deep profile"), cuando pasas al modo build no había nada de nada, todo bien. Yo lo probé luego de ver una de esas "Unite", un tipo pasó por un montón de cosas y una de ellas era esto.

Igual, no digo que este sea el caso, acá esta claro que los problemas serán gráficos o físicos, cosas mas tangibles seguramente.

si, el garbaje collector (GC) a veces causa picos de bajo rendimiento... 

nose cual podria ser la solucion a eso....

...a veces, coon algunos objetos que van a estar todo el rato apareciendo y desapareciendo, en vez de instanciar/destruirlos, intento reutilizarlos.... o desactivarlos en vez de destruirlos, o cosas asi... pero porejemplo con el tema particulas y asi eso se vuelve muy complejo..

y creo que es lo que dices que se acumula "basura", y cuando realmente la destruye, proboca un pico, porque le ha tocado destruir mucha basura...

Share this post


Link to post
Share on other sites
On 20/3/2018 at 21:51, Abramelin said:

Si estas usando el postprocessing configura el tonnemaping (color grading) ahí vas a poder conseguir el ajuste global de iluminación y que empaste mejor todo (con el exposure controlas si quieres que se vea más iluminado o más oscuro) luego tienes el eye adaptation que da un effecto muy chulo al pasar de zonas iluminadas a oscuras y viceversa . el bloom actívalo y no te cortes en exagerarlo, luego le vas quitando y ajustando de forma mas fina, el AO este consume un poco más de recursos pero para juegos de terror lo veo casi imprescindible a no ser que bakees. Eso por la parte visual lo va dejar cañon.

He estado tocando esto que me comentas y ha ganado una barbaridad. El bloom y el eye adaption le dan un toque brillante a los metales muy chulo.

 

On 20/3/2018 at 21:51, Abramelin said:

Como consejo final para que no repitas mis errores. En lugar de utilizar static ocludees y ocluders utilizo triggers para desactivar los objetos que no quiero que se vean (MAL), si te enseñas a manejar bien el oclusion culling eso que te ahorras

El Oclussion culling me vuelve un poco loco, en el altillo hay unos objetos con muchos poligonos y cuando testeo el juego veo en el editor que desaparecen pero siguen cargando el sistema de poligonos, así que finalmente los he desactivado mediante un trigger. He hecho lo mismo con el Terreno y los arboles

 

On 22/3/2018 at 0:37, Adrianete said:

y para los sustos a lo mejor si le haces una animacion al cromatic aberration del post proccesing quedaría chulo tmb (por ejemplo cuando cae el osito del techo, ponerle el cromatic casi a tope con una animación y luego que baje)

Esto lo he estado probando tambien y queda curioso, he usado el Chromatic aberration junto con el Motion Blur y queda un efecto chulo. Los ojos del osito con el bloom quedan muy bien también.

Para las particulas las hice mas transparentes y en colores grises y ha mejorado bastante pero tengo que darle una vuelta.

 

On 22/3/2018 at 0:37, Adrianete said:

¿has subido algún archivo mas reciente del juego?

Estoy esperando a completarlo un poco más para no tener que estar subiendo versiones por cada cambio que hago, así se os hará menos pesado probarlo también, jeje. Esta semana lo subo de nuevo a ver como lo veis.

 

On 22/3/2018 at 3:24, lightbug said:

Yo te recomendaría usar el profiler en todo, y mejor aún usarlo directamente en la build, es decir, haces un development build con la opción del profiler (no recuerdo bien como se llama), dejas el editor abierto, das a play (a la build obvio) y pasas por los lugares críticos del juego, minimizas el juego (rapidamente, alt+Tab) y volvés al editor, de ahí a partir de la info que te da vas a poder saber bien que te provoca las bajadas.

He probado esto y hay un proceso que me tiene un poco mosca, solo aparece exagerado cuando corro la build, cuando lo hago desde unity apenas aparece ese proceso, se llama Gfx.WaitForPresent, se come desde un 30% hasta un 80% de CPU en picos continuados. He estado investigando y dicen de todo,pero parece que ser que es debido a configuraciones de la tarjeta gráfica para ahorrar energía en la batería de los portátiles o un tal VSYNC que sirve para hacer capturas de vídeo de los juegos...

Ya podría la gráfica dejarse de chorradas y hacer solo lo que tiene que hacer ;) .

Me queda también usar tu código para manipular objetos, estuve probando tu demo y muy chula, estuve un buen rato colocando los objetos en las "estanterias", me gusto poder abrir puertas, la verdad que como tu decias se puede hacer un juego entero usando ese script, gracias por compartirlo¡ 

No se si me dejo algo que comentar pero bueno, os mantendré informados. Cuando probasteis el juego y me dijisteis que iba muy lento me dio un poco de bajón tener que meterme a optimizarlo y ver por donde iba mal, sobre todo porque pense que perderia calidad, pero ha sido todo lo contrario, se ve mucho mejor y más fluido.

 

Gracias¡¡

Edited by memonic

Share this post


Link to post
Share on other sites
4 hours ago, memonic said:

He probado esto y hay un proceso que me tiene un poco mosca, solo aparece exagerado cuando corro la build, cuando lo hago desde unity apenas aparece ese proceso, se llama Gfx.WaitForPresent, se come desde un 30% hasta un 80% de CPU en picos continuados. He estado investigando y dicen de todo,pero parece que ser que es debido a configuraciones de la tarjeta gráfica para ahorrar energía en la batería de los portátiles o un tal VSYNC que sirve para hacer capturas de vídeo de los juegos...

Present hablando de graficos es pasar el backbuffer (el que tiene todo trabajado y listo para ser presentado) hacia el frontBuffer (lo que ves actualmente en pantalla) e intercambiar roles, así que el wait ese está relacionado al Vsync, es decir ya lo tiene para presentar pero está esperando supongo. EL vsync basicamente limita tus fps (por lo menos si los medis nunca pasas de cierto numero ... 60?), entonces evitás ese efecto en el que parte de tu pantalla se actualiza pero parte no y se ve cortado (por que es demasiado rápido), aunque pocas veces lo he experimentado en Unity. Lo suelo desactivar para hacer pruebas de rendimiento general (1100 fps!), pero para un juego lo dejaría activado (60 fps).

 

4 hours ago, memonic said:

Me queda también usar tu código para manipular objetos, estuve probando tu demo y muy chula, estuve un buen rato colocando los objetos en las "estanterias", me gusto poder abrir puertas, la verdad que como tu decias se puede hacer un juego entero usando ese script, gracias por compartirlo¡

De nada! me alegro que te guste, hay un detalle que debo verlo, actualmente no se si será algo de la cámara (y su movimiento suave) o no, pero si lo aplicás a un first person ponele, los cambios son notables a caminar con el objeto, ya que uno pasa la vel en fixedupdate y mi camara en LateUpdate entonces usar cambios bruscos de velocidad queda medio medio, voy a ver si logro hacer lo mismo pero usando fuerzas, aunque probé de toda manera y no logro el mismo efecto que con cambios de velocidad. De seguro vas a notarlo si lo probás, cualquier cosa me mandas un MP para ver si me pasa solo a mi.

 

pregunto, la demo está actualizada o es la segunda build de siempre?

 

Saludos

 

Share this post


Link to post
Share on other sites

Buenas gente¡¡

Ya he subido una nueva versión, a ver si esta os va más fluida. He puesto el enlace en el post del principio.

Lightbug, he intentado usar tu script para agarrar objetos pero me sale un error indicando que el script no deriva de monobehaviour y no me deja asignarlo a la camera...he probado añadirle : monobehaviour y entonces me deja asignarselo a la camera pero no funciona, ni poniendo que envié un mensaje print en el Start()... no se si estoy haciendo algo mal.

Ya me diréis que tal lo veis, quedan detallitos pero básicamente esta, me interesa sobre todo ver si os corre bien.

 

saludos¡¡

 

Share this post


Link to post
Share on other sites
6 hours ago, memonic said:

Lightbug, he intentado usar tu script para agarrar objetos pero me sale un error indicando que el script no deriva de monobehaviour y no me deja asignarlo a la camera...he probado añadirle : monobehaviour y entonces me deja asignarselo a la camera pero no funciona, ni poniendo que envié un mensaje print en el Start()... no se si estoy haciendo algo mal.

Fijate que el script ya tiene una clase derivada de monobehaviour, (no la de arriba, la de abajo)

[RequireComponent(typeof(Camera))]
public class GrabObject : MonoBehaviour {

	...

Para que funcione tenés que tener el script llamado exactamente como la clase esta, osea "GrabObject.cs" , por supuesto ponele el nombre que quieras, pero a ambos juntos, no a uno sí y al otro no. El RequiereComponent sacalo si querés usarlo en algún obj distinto a una cámara, no necesariamente lo debe tener una cámara, son cositas que me olvidé en el camino.

 

6 hours ago, memonic said:

Ya me diréis que tal lo veis, quedan detallitos pero básicamente esta, me interesa sobre todo ver si os corre bien.

Dale, te digo que tal me fue

Share this post


Link to post
Share on other sites

Ya me funciona, mal llame al script GrabObjectProperties, lo cambie por el de abajo y ya va bien, por cierto muy interesantes las opciones que usas para que se muestren los parámetros en el inspector con sliders, rangos etc...muy profesional.

 

Share this post


Link to post
Share on other sites
58 minutes ago, memonic said:

...por cierto muy interesantes las opciones que usas para que se muestren los parámetros en el inspector con sliders, rangos etc...muy profesional.

 

hombre, pus claro, el Range es 100% Pro :7_sweat_smile: jaja más que nada para limitar a valores seguros de X campo (tengo un atributo que funciona igual al arnge pero sin mostrar el slider, aveces ver tanto slider te puede llegar a quemar el coco) o muchas veces para forzar a valores positivos (con otro atributo similar al anterior para positivos sin Slider, creo que Unity no serializa por ej uint's para el inspector o por lo menos nunca antes lo hizo).

Edit: me vengo a enterar que desde 5.5 o parecido se soportan uint en el inspector :28_hugging: ... bueno igual me sirve para limitar los floats

Edited by lightbug

Share this post


Link to post
Share on other sites
On 26/3/2018 at 23:22, lightbug said:

Present hablando de graficos es pasar el backbuffer (el que tiene todo trabajado y listo para ser presentado) hacia el frontBuffer (lo que ves actualmente en pantalla) e intercambiar roles, así que el wait ese está relacionado al Vsync, es decir ya lo tiene para presentar pero está esperando supongo.

Ya averigüe porque Gfx.WaitForPresent se comía tanta CPU, era por la simple tonteria de no tener el portatil enchufado, fue enchufarlo y ya dejo de comerse la CPU...

He estado revisando las geometrías de los modelos como me comentaste y tenía algunos desfases, uno de ellos delante de mis narices y muy estúpido...la vela que lleva el player tenía unos 30.000 polígonos, ahora tiene 1.200 y se ve igual. Y lo peor era que la mecha de la vela tenía 1.200...un objeto que apenas se ve, ahora tiene 44

También en el sótano había una mesa con herramientas, botes y demás que tenia 400.000 polígonos, una locura¡¡ y claro el agua del sótano tenía que reflectar esos 400k polígonos y yo le echaba la culpa al agua...

Ahora el juego corre mucho mejor, en las vistas con mas objetos detalaldo no supera los 400k poligonos en total y antes eran varios millones...

 

Esta claro que con los próximos proyectos voy andar desde un principio con mucho cuidado con el tema de los polígonos, pensé que con el hardware actual no tenia ya tanta importancia optimizar los modelos y ni me fijaba.

 

muchisimas gracias por tus consejos¡¡

Share this post


Link to post
Share on other sites

UnitySpain © Todos los derechos reservados 2020
×
×
  • Create New...