Estas son recomendaciones para tener en cuenta cuando actualice proyectos de Unity 5 a Unity 5, si su proyecto utiliza código personalizado de shader.
Los Shaders ya no aplicar un multiplicador 2x de la intensidad de luz. En vez, las luces son automáticamente actualizadas a ser el doble de brillantes. Esto crea más consistencia y simplicidad en los rigs de lights (luces). Por ejemplo, una directional light (luz direccional) alumbrando en una superficie blanca diffuse (difusa) tendrá el color exacto de la luz. La actualización no afecta la animación, por lo tanto, si usted tiene un valor de intensidad de animación usted tendrá que cambiar sus curvas de animación o código script y hacerlas el doble de grandes para obtener la misma apariencia.
En el caso de que haya shaders personalizados, dónde usted define sus propias funciones de iluminación , usted tendrá que quitar el *2 usted mismo.
// A common pattern in shader code that has this problem will look like this
c.rgb = s.Albedo * _LightColor0.rgb * (diff * atten * 2);
// You need to fix the code so it looks more like this
c.rgb = s.Albedo * _LightColor0.rgb * (diff * atten);
El pipeline de iluminación integrado en Unity 5 puede en algunos casos utilizar más interpolators (interpoladores) de coordenadas de texturas o counts de instrucciones de matemáticas (para obtener cosas como una escala no-uniforme mesh, un GI dinámico etc. funcionando). Algunos de sus surface shaders existentes podrá correr a texture coordinate (coordenadas de textura) o ALU instruction limits (limites de instrucción ALU), especialmente si estas tenían como objetivo el shader model 2.0 (Predeterminado). Agregando “#pragma target 3.0” puede funcionar alrededor de este problema. Ver http://docs.unity3d.com/Manual/SL-ShaderPrograms.html para referencia.
En Unity 5.0, los meshes no-uniformes no son “pre-escalados” en el CPU ya. Esto significa que los vectores de normales y tangentes pueden ser no-normalizados en el vertex shader. Si usted está haciendo cálculos manuales de iluminación ahí, usted tendrá que normalizarlos. Si usted está utilizando los Surface Shaders de Unity, entonces todo el código necesario será generado para usted.
Unity 5.0 hace que el Fog (niebla) integrado funcione en WP8 y consolas, pero con el fin de lograr esto, nosotros hemos cambiado como el Fog es hecho. Para los surface shaders y fix function shaders, nada extra debe ser hecho - el fog va a ser automáticamente agregado (usted puede agregar “nofog” a la linea #pragma del surface shader para explícitamente hacer que no soporte fog).
Para vertex/fragment shaders escritos de manera manual, fog no sucede ya de manera automática. Usted necesita agregar #pragma multi_compile_fog y macros que manejen el fog para su código del shader. Revise el shader source integrado, por ejemplo Unlit-Normal para cómo hacerlo.
Por defecto todos los surface shaders opaque (opacos) output 1.0 (“blanco”) al canal alpha ahora. Si usted quiere parar esto, utilice la opción “keepalpha” en la linea #pragma del surface.
Todos los alpha blended surface shaders (surface shaders mezclados con alpha) utiliza un componente alpha computado por la función de iluminación como factor de mezcla ahora (en vez de s.Alpha). Si usted está utilizando funciones de iluminación personalizadas, usted probablemente querrá agregar algo como “c.a = s.Alpha” hacia el final.
Unity ya no clasifica por indice de material en el forward renderloop. Esto mejora el rendimiento ya que más objetos pueden ser renderizados sin cambios de estados entre ellos. Esto rompe la compatibilidad para contenido que se apoya en el indice de material como una manera de clasificación. En 4.x un mesh con dos materiales siempre iba a renderizar el primer material primero, y el segundo material de segundo. En Unity 5 esto no es el caso, el orden depende en qué reduce la mayoría de cambios de estado para renderizar la escena.
Unity 5.0 quito soporte para la funcionalidad de este fixed function shader :
Cualquiera de los de arriba ahora hará nada, y el inspector del shader mostrará advertencias acerca de sus usos. Usted debería re-escribir los shaders afectados utilizando shaders vertex+fragment programables más bien. Todas las plataformas los soporta hoy en día, y no hay ventajas en absoluto para utilizar fixed function shaders.
Si usted tiene versiones viejas de paquetes Projector o Water shader en su proyecto, los shaders ahí podrían estar utilizando esta funcionalidad. Actualice los paquetes a la versión 5.0.
La mezcla de shaders progamables y fixed function (e.g. la fixed function vertex lighting & pixel shader, o un vertex shader y texture combiners (combinadores de textura) ) ya no es soportado. No estaba funcionando en móviles, consolas o DirectX 11 igual. Este cambio de comportamiento requerido de que el Legacy/Reflective/VertexLit shader no haga esto - perdio soporte per-vertex specular; en el lado positivo se comporta ahora consistentemente entre plataformas.
En la mayoría esto debería ser transparente (simplemente resulta en menos bugs de codegen y un poco más rápido los shaders). Sin embargo, el compilador HLSL puede ser un poco más problemático acerca de sintaxis. Algunos ejemplos:
La propiedad del shader “unity_Scale” ha sido quitada. En 4.x unity_Scale.w fue 1 / uniform Scale del transform, Unity 4.x solamente renderizaba modelos no-escalados o uniformemente escalados. Otras escalas fueron realizadas en CPU, lo cual fue muy costoso & tuvo una sobrecarga inesperada de memoria.
En Unity 5.0 todo esto es hecho en el GPU al simplemente pasar matrices con escalas no-uniformes a los shaders. Por lo tanto, unity_Scale ha sido quitado porque ya no representa la escala completa. En la mayoría de casos dónde “unity_Scale” era utilizado, nosotros recomendamos más bien transformarlo primero al espacio del mundo. En el caso de transformar normales, usted siempre tendrá que utilizar normalize en la normal transformada ahora. En algunos casos esto lleva a código un poco más caro en el vertex shader.
// Unity 4.x
float3 norm = mul ((float3x3)UNITY_MATRIX_IT_MV, v.normal * unity_Scale.w);
// Becomes this in Unity 5.0
float3 norm = normalize(mul ((float3x3)UNITY_MATRIX_IT_MV, v.normal));
// Unity 4.x
temp.xyzw = v.vertex.xzxz * unity_Scale.xzxz * _WaveScale4 + _WaveOffset;
// Becomes this in Unity 5.0
float4 wpos = mul (_Object2World, v.vertex);
temp.xyzw = wpos.xzxz * _WaveScale4 + _WaveOffset;
Las sombras de los Forward rendered directional light no separan ya los pass “shadow collector”. Ahora estas calculan las sombras del screenspace de la depth texture (textura profunda) de la cámara ( como en deferred lighting).
Esto significa que los passes LightMode=ShadowCollector en los shaders (sombreadores) no so utilizados para nada; usted puede simplemente quitarlos de sus shaders.
En sí, la Depth texture no es generada utilizando el shader replacement (remplazo del shader) ya; ésta es renderizada con shader passes ShadowCaster. Esto significa que siempre y cuando sus objetos pueden emitir una sombras propias, entonces estas también van a aparecer en la depth texture de la cámara apropiadamente (antes era muy difícil hacer esto, si usted quería una custom vertex animation o funky alpha testing). Esto también significa que Camera-DepthTexture.shader ya no es utilizada para algo. Y también, todos los shadow shaders integrados utilizaban backface culling; esto fue cambiado para coincidir con el modo de culling de un renderizado regular.