Os parecerá una chorrada, y hasta ahora no le había dado mucha importancia pero...
 
Recomendaríais...
 

1. 
      Usar una única cámara, con un componente potente para gestionarla, y la voy acoplando a diferentes objetos...
      
   
   
   1. 
               Ventajas: más difícil equivocarme con las settings mal copiadas en diferentes cámaras, FOV, rendering...
            
   
         
   2. 
               Contras: no es tan "intuitivo" como tener todas las cámaras creadas y listas en cada objeto.
            
   
      
   
   


2. 
      Usar un GameObject y cámara diferente
      
   
   
   1. 
               Ventajas: simplemente activando y desactivando la cámara que me interesa, ya está en su sitio y con su script de movimiento (si lo tiene).
            
   
         
   2. 
               Contras: Lo malo de esto es que cada vehículo y en varios sitios tengo cámaras, así que acabaría teniendo cientos de cámaras (si bien desactivadas todas menos una).
            
   
      
   
   

¿Qué recomendáis? ¿cuál sería la estrategia "estándar" sugerida por Unity y por los assets de cámara más típicos? ¿y si tuviese un asset de cámara potente (porque creo que acabaré teniendo varios controladores para las cámaras, cinemáticas, etc)?
 
 
 
 

Yo utilizo hasta 5 cámaras diferentes. Que si UI, que si el PPFX para los fondos, que si AR, que si 360, que si modelos 3D, etc. Me creé un gestor de cámaras que va activando y desactivando y aplicando los parámetros adecuados.

Oki, sí, tengo una para UI y otra para interior del vehículo...
 
Pero no me refiero a eso, sino a esto:
 

 
Tengo un montón de cámaras definidas en cada vehículo, en total son cientos, más un montón más (potencialmente miles) repartidas por el escenario (con diferentes zooms, movimientos, etc).
 
Por una parte, necesito esos GameObjects ahí, porque son el Transofrm de "dónde está la cámara" o "a dónde apunta". Son unas decenas por vehículo, pero están desactivados. Podría calcular todas esas posiciones dinámicamente, pero no creo que esos GameObjects sean un problema.
 
Por otro lado, me parece engorroso tener que definir ese Audio Listener y ese Post Process Layer, así como otros parámetros, por separado para cada cámara. Y siendo tantas... podría tener esa información en un ScriptableObject o en cualquier estructura de datos. Aunque me parece cómodo que estén en la escena para poder buscar las más cercanas usando el propio motor (no tengo claro cómo haré esto).
 
La verdad hasta ahora no me ha dado ningún problema como lo he estado haciendo, pero querría poder hacer travellings y transiciones entre diferentes cámaras...
 
Estaba pensando por tanto en tener una única cámara, con un script a mi gusto (que pueda transicionar entre dos posiciones, camerashake, fade in/out... lo que vaya necesitando), y dejar sólo GameObjects vacíos en los vehículos (para usar como referencias de posición). Y por último, como dices, un CameraManager que me permita cambiar entre "camara frontal del coche 1, cámara fija de tal calle, travelling de punto A a punto B...).
 
Estoy muy tentado de hacer esto, creo que tendría más control ¿tendría sentido?
 
 
 
 

Cita de: J Montes date=1582748874con un componente potente para gestionarla
   

¿"Potente" en qué sentido? osea, ¿un componente maestro quizás?
 

Cita de: J Montes date=1582748874¿Qué recomendáis? ¿cuál sería la estrategia "estándar" sugerida por Unity y por los assets de cámara más típicos? ¿y si tuviese un asset de cámara potente (porque creo que acabaré teniendo varios controladores para las cámaras, cinemáticas, etc)?
   

Yo he usado multiples cámaras solamente si tienen características propias del render diferentes, osea, la cámara 1 renderiza tal y tal layer, la cam 2 tal y tal, y así. Un ejemplo bien claro de esto es la cámara del gameplay y la camara de la UI (quizás la de un inventario, podría ser).
 
Ahora, el tener varias cámaras solo por comodidad del transform no me convence, verás, es probablem que te interese solo tener multiples ángulos, otros FOVs, near/far, etc. EN ese caso prefiero usar el concepto de cámara virtual (una clase de C# con propiedades de la cámara) y luego ir interpolando (o no) los parámetros. De hecho, así es como cinemachine funciona.
 

Cita de: J Montes date=1582758833Por una parte, necesito esos GameObjects ahí, porque son el Transofrm de "dónde está la cámara" o "a dónde apunta"
   

Quédate solo con los "Transform" de referencia, todos los "Camera" no los necesitas (si solo querés cambiar de pos/rot/fov, etc). Con la camara virtual podés meter los parámetros de interés. Incluso, podrías definir estos parámetros usando ScriptableObjects y mostrarlos en el inspector (para que se entienda, sería un equivalente a los efectos del PostProccesing Stack, que son SritableObjects también). Esto sería útil si tuvieras un número razonable de cámaras para todo el juego (que necesiten ser iguales a lo largo del juego, un ej típico sería la cámara de 1er persona, la de 3ra persona, la de top down, etc).
 
Podés meter esos transforms ( contenidos dentro de un elemento de camara virtual) en un componente controlador de la camara (el CameraController, ponele) y de ahí pasar de elemento en elemento, con la transición que quieras.
 
 
 
 
 

Cita de: J Montes date=1582758833Estaba pensando por tanto en tener una única cámara, con un script a mi gusto (que pueda transicionar entre dos posiciones, camerashake, fade in/out... lo que vaya necesitando), y dejar sólo GameObjects vacíos en los vehículos (para usar como referencias de posición). Y por último, como dices, un CameraManager que me permita cambiar entre "camara frontal del coche 1, cámara fija de tal calle, travelling de punto A a punto B...).
   
   
      Estoy muy tentado de hacer esto, creo que tendría más control ¿tendría sentido?
   

Sí, y mucho, por lo menos para mí.
 
Te vas a dar cuenta que cuando el controller de la cámara se transforme en super sayayin tenderá a ser una maquina de estados, así que probablemente vas a terminar definiendo a estas "cámaras virtuales" como estados independientes.
 
Un ej: Al leer la tecla "C" el estado "First Person" (actual) pasa al "Third Person". Acá podés disparar un evento "OnTransitionStart" (ponele) y sabiendo que se pasa al estado "ThirdPerson" podés usar un cierto tiempo/tipo de transición, definido en el propio estado "ThirdPerson".
 
Una vez que la transición se haya completado podés disparar un evento "OnTransitionEnd" que diga de qué a qué estado se dio, el tiempo que tomó la transición, etc. Lo bueno es que no tenés que definir un montón de cosas predefinidas en cada cámara virtual, sino que lo manejas vos dentro de cada estado. El tiempo de transición puede ser un elemento propio del estado, como también si admite o no transición a otro "transform", si tiene un target o no, efectos ordenados  temporalmente, y mucho más.
 
 

Claro @lightbug utilizar puntos de Transforrm para ir trasladando unas pocas cámaras. Y no te olvides de pegarle una mirada al cinemachine (https://unity.com/es/unity/features/editor/art-and-design/cinemachine" ipsnoembed="true" rel="external nofollow">https://unity.com/es/unity/features/editor/art-and-design/cinemachine). Lo he utilizado para movimientos de cámara estilo "del cielo a third player" o "de third player a travelling" y es muy potente.

Resumo los puntos claves para mí, como referencia:
 

• 
     Multiples cámaras solamente si tienen características propias del render diferentes: suponía que al final partendría ser así, pero no quería meterme en el cambio todo sin preguntar.
  


• 
     Incluso, podrías definir estos parámetros usando ScriptableObjects y mostrarlos en el inspector: interesante idea, a no olvidar si la gestión de cams se vuelve más compleja.
  


• 
     No te olvides de pegarle una mirada al cinemachine: gracias, siempre hay que ver alguna referencia de cómo lo hace la gente que lo ha hecho varias veces y no sé qué es lo que se usa mayormente 8-).
  


• 
     Tenderá a ser una maquina de estados: tiene todo el sentido.
  

Gracias de nuevo. Entre los dos me habéis respondido y ampliado el tema.

Y entonces debería usar Cinemachine para un juego de coches con algunas cinemáticas... ¿o me escribo la cámara?
 
Me echa un poco para atrás meterme ahora con eso, pero por otra parte, igual estoy haciendo el pringao y pierdo muchas opciones... (además, lo venden muy bien, soporta 2 y 4 split screen, y la gestión de colisiones entiendo que la hará mejor que cualquier cosa que pueda hacer yo, aunque no sea lo más importante para mí ahora mismo)
 
 

Considero que lo importante es: qué puede hacer Cinemachine , qué te aporta y cómo te afectaría a tu gestor de cámaras,  Y en el futuro lo puedes implementar dejando el código más o menos preparado.

2/4 split screen y gestión de colisiones decente, además de transiciones entre cámaras (que es el motivo por el que tengo que hacer algún cambio en cualquier caso).
 
Pero me da miedo que al final tener una cámara detrás del coche sea supercomplicado. En fin, voy a probarlo.
 
 

Qué va. Es muy fácil. Defines las transiciones en el componente y luego activas/desactivas las cámaras y el mismo realiza la transición de una a otra.

Cita de: iRobb date=1582776670Claro @lightbug utilizar puntos de Transforrm para ir trasladando unas pocas cámaras. Y no te olvides de pegarle una mirada al cinemachine (https://unity.com/es/unity/features/editor/art-and-design/cinemachine" ipsnoembed="true" rel="external nofollow" target="_blank">https://unity.com/es/unity/features/editor/art-and-design/cinemachine). Lo he utilizado para movimientos de cámara estilo "del cielo a third player" o "de third player a travelling" y es muy potente.
   

Muy interesante el Cinemachine, habia oido hablar de el pero no lo habia visto con detenimiento. ¡Habrá que probarlo!
 
Ganaron un Emmy los de Unity por el Cinemachine que maquinas

Yo estuve muchas veces interesado en Cinemachine, es tremendamente poderoso y está integrado con el post processing stack. La razones para escribir mi propio sistema serían:
 

1. 
      Personalización: Aunque CM seguramente tenga lo que quiera y mucho más, puede ser que no haga las cosas exactamente como quiero. Un ej: en mi juego necesito camaras que sean objetos físicos, es decir que se muevan en FixedUpdate junto con los personajes y las plataformas (por cuestiones de raycasts y sync de las físicas) -> Cinemachine se actualiza usando este sistema? en el orden que yo quiero?
   


2. 
      Bugs: Si CM tiene X bug y me impide seguir trabajando en lo mío, bueno, supongo que tengo que esperar a que lo soluciones. Si el código es mío me resulta mucho más fácil encontrar dichos bugs y resolverlos.
   

Sacando esto, CM es una gran opción y además muy usada e integrada por muchos assets.

El Cinemachine Brain (sí, así se llama el controller) tiene un parámetro llamado "UpdateMethod" donde puedes decirle que tipo de Update tiene que ejecutarse para el grupo de cámaras que controla el Brain. Tiene FixedUpdate. Aunque la opción SmartUpdate es mejor ya que él mismo lo escoge dependiendo del target si es rigidbody o no.

Yo la mayoría de cosas relativas a múltiples setups de cámara las he resuelto sin problemas con el CineMachine. Es lo bastante potente y maduro para mí, yo le doy mi visto bueno.
 
Si ya necesitáis alguna solución más personalizada, toca buscar por el Asset Store, o hacérsela a mano...
 
 
 
Lo importante es no confundirlo ni meterlo en el mismo saco que el TimeLine. Aunque los de Unity te vendan la moto junta, son herramientas distintas para cosas distintas. Es sólo que TimeLine también trae extras para ser usados junto con el CineMachine. Pero ni de coña dependen el uno del otro, eh?