El motor Orange Box tiene una entidad de pincel llamada"func_reflective_glass",es una entidad de espejo. Técnicamente, es una cámara y un monitor dentro de sí mismo, por lo que si usted tiene más de uno de estos en una misma habitación, obtendrá problemas.
Estos espejos se ven muy bien y añaden mucho realismo a los ambientes, desafortunadamente hay una cosa que no refleja: el propio jugador.
Esto se debe a que el jugador NO tiene un modelo establecido en Orange Box, e incluso cuando se establece, permanece invisible cuando está en modo en primera persona.

Debido a una pequeña parte en Tercera Persona en Underhell : Capítulo 1, tuvimos que crear un modelo del jugador funcional y animado, que seguiría de cerca la velocidad de movimiento del jugador, animación y dirección de la cabeza, para tratar de hacerlo lo más "vivo" posible.
Esta es la razón por la que animamos manualmente y vinculamos cada comportamiento de un solo jugador, hasta bajar las armas, disparar, saltar y agacharnos, a un modelo de jugador preestablecido.
El modelo de reproductor predeterminado es: "models/player/jake_casual.mdl"Para cambiar el modelo del reproductor, se debe enviar una entrada a la entidad !player:
!player SetPlayerModel models/player/jake_guard.mdl


Esta entrada para el !player establecerá el playermodel en lo que se especifique. Si la ruta/el nombre del modelo no es correcto, el juego simplemente mostrará un mensaje de error en la consola y el modelo permanecerá sin cambios.
Para que cualquier modelo de reproductor adicional se amenmente correctamente, se deben agregar las siguientes líneas al .qc del modelo: (solo aplicable si tu modelo usa esqueleto de valve humano y obviamente los respectivos modelos de half-life 2)

• $includemodel "player/male_anims.mdl"
  
• $includemodel "humans/male_shared.mdl"
  
• $includemodel "humans/male_ss.mdl"
  
• $includemodel "humans/male_gestures.mdl"
  
• $includemodel "humans/male_postures.mdl"
  
• $includemodel "humans/female_shared.mdl"
  
• $includemodel "humans/female_ss.mdl"
  
• $includemodel "alyx_animations.mdl"
  
• $includemodel "alyx_gestures.mdl"

Sí, esos son muchos modelos de animación compilados, pero esto da muchas posibilidades para que el modelo de jugador esté bien animado o incluso sea un actor durante las escenas, que puede tener muchos gestos / poses. Una característica comúnmente utilizada en Underhell.

Así que teníamos nuestro modelo de jugador, totalmente funcional en tercera persona, pero todavía no se representaría en espejos ni monitores. El principal problema era, que para que se representara allí, también tenía que ser representado en el "mundo" para que pudiera reflejarse correctamente, lo que significa que si el jugador miraba hacia abajo mientras que en primera persona, vería dentro del modelo del jugador, y causaría errores visuales muy desagradables.
Por lo tanto, pensamos en un sistema que nos permitiría representar entidades SOLO en las texturas "RenderTarget", lo que nos da no sólo la oportunidad de renderizar jugador en espejos y monitores, mientras que, en primera persona, pero CUALQUIER entidad dinámica en el juego, se puede agregar un valor clave para representarse solo en espejos o monitores.
Este sistema nos da un sinfín de posibilidades de sustos, donde "algo" sólo sería visible mientras lo mira a través de un espejo / monitor.
El playermodel tiene este valor establecido de forma predeterminada, para que cualquier entidad se represente solo en espejos, se debe agregar el siguiente valor de clave en el hammer, desactivando smartedit:
Código:
uh_rendermirrorsonly 1


Establecer este valor clave en cualquier entidad del juego, indicará al motor que los represente solo en texturas "RenderTarget", por lo tanto, solo en func_reflective_glass o func_monitors.

Como se indicó anteriormente en la textura de procesamiento múltiple, colocar varios RenderTargets que usan la misma textura RenderTarget en una habitación, lo arruina mal e incluso puede provocar bloqueos.
La función Espejos múltiples es algo que hemos planeado, sin embargo, en ese momento no sabemos si es posible utilizar la misma técnica utilizada anteriormente. Cada vez que se implementa esta característica y funciona correctamente, editaré esta sección y describiré su funcionalidad.

ahora explicare cómo implementamos un sistema para solucionar la limitación del motor de origen de tener sólo 1 cámara ingame activa a la vez, y cómo logramos aumentar la resolución para mejorar la calidad de la cámara renderizada.

Es una limitación conocida y afligida, el motor de origen permite que sólo 1 cámara en el juego se represente en un mapa en todo momento. Aunque puede cambiar el point_camera para representar para una func_monitor, sólo puede tener 1 cámara renderizada a la vez, y la resolución de dicho monitor se establece en 256x256, no importa cuánto cambie el tamaño de su monitor en Hammer.
Esto se debe a que Source sólo tiene 1 textura RenderTarget, si varias cámaras estarían activas a la vez, y una estaría apuntando al monitor, representaría la textura dentro de sí misma, generando así un bucle de renderización infinito y bloqueando el juego.

HAMMER

Por eso hemos implementado un Hammer Keyvalue en la entidad point_camera:

Point_Camera Keyvalues :

• Rendertarget : 1
  
• Rendertarget : 2
  
• Rendertarget : 3
  
• Rendertarget : 4
  
• 
  
• Which are, respectively :
  
• 
  
• 256A
  
• 256B
  
• 512A
  
• 512B

Este valor clave de martillo simple que debe agregarse a las propiedades del point_camera desactivando SmartEdit, permite establecer un índice para las nuevas texturas de Render Target para las cámaras, trabajando así en torno a la limitación.

.VMT

Lo que teníamos que hacer era hacer que el motor construyera un nuevo conjunto de texturas de destino de renderización, y para que nos hiciera referencia a ellas en el editor de niveles, creamos un conjunto de VMTs que llama a la textura del motor correspondiente.

materials/dev/dev_monitor_256A.vmt
materials/dev/dev_monitor_256B.vmt
materials/dev/dev_monitor_512A.vmt
materials/dev/dev_monitor_512B.vmt

Si abre los VMT, verá el siguiente código dentro.

dev_monitor_256A.vmt

• "UnlitGeneric"
  
• {
  
• "$basetexture" "_rt_CustomCamera_1"
  
• "%tooltexture" "dev/dev_monitor"
  
• "$surfaceprop" "glass"
  
• }
  
• 
  
• 
  
• dev_monitor_256B.vmt
  
• 
  
• "UnlitGeneric"
  
• {
  
• "$basetexture" "_rt_CustomCamera_2"
  
• "%tooltexture" "dev/dev_monitor"
  
• "$surfaceprop" "glass"
  
• }
  
• 
  
• dev_monitor_512A.vmt
  
• 
  
• "UnlitGeneric"
  
• {
  
• "$basetexture" "_rt_CustomCamera_3"
  
• "%tooltexture" "dev/dev_monitor_512"
  
• "$surfaceprop" "glass"
  
• }
  
• 
  
• dev_monitor_512B.vmt
  
• 
  
• "UnlitGeneric"
  
• {
  
• "$basetexture" "_rt_CustomCamera_4"
  
• "%tooltexture" "dev/dev_monitor_512"
  
• "$surfaceprop" "glass"
  
• }
  

IMPORTANTE: Si no se establece ningún "$surfaceprop", al compilar el Monitor NO se representará. Un fallo extraño nos llevó un tiempo averiguarlo.

Observará que el índice de cada _rt_CustomCamera_* hace referencia directamente al número que necesita introducir en el valor de clave "RenderTarget" del point_camera.
Por lo tanto, si coloca una func_monitor con la textura "dev_monitor_512A" aplicada a ella, que es el número de índice 3,entonces necesita tener una point_camera con el valor de clave:
RenderTarget : 3Target : 3
Así es como están unidos, ahora gracias a esos 4 monitores adicionales, más el original, puedes tener un máximo de 5 monitores en el juego trabajando de forma independiente. Sólo evita poner un point_camera y un func_monitor en la misma habitación, especialmente si están vinculados
Supervisar la superposición de efectos
Si desea agregar una superposición "ScanLines" para que parezca un MonitorTexture real, debe agregar un conjunto de texturas $texture 2 y algunos efectos de proxies.
Le sugiero que eche un vistazo a los VMTs monitor de Valve utilizando GCFScape y a continuación, abra"/.. /steamapps/source materials.gcf"
A continuación, vaya a "hl2/materials/dev/"Echa un vistazo a todas las "dev_combinemonitors"y "dev_tvmonitors"Tienen un par de efectos de monitor allí.