PageRenderTime 59ms CodeModel.GetById 21ms RepoModel.GetById 0ms app.codeStats 0ms

/Utilities/Graphics/ShaderFeatures/ShaderFeatureFlags.cs

#
C# | 543 lines | 63 code | 26 blank | 454 comment | 0 complexity | 72f3f3992ba40b8d8e3bb8ea2b32f46a MD5 | raw file
Possible License(s): Apache-2.0
  1. using System;
  2. namespace Delta.Utilities.Graphics.ShaderFeatures
  3. {
  4. /// <summary>
  5. /// Shader feature enum, usually multiple values are combined to define
  6. /// a shader ruffly. This data is mainly used for fallback generation and
  7. /// hints to make rendering quicker. We can skip a lot of code paths if we
  8. /// already know what the shader can and cannot do. For more details see
  9. /// the MaterialEditor tool (that can view and edit materials and shaders).
  10. /// Note: This enum already uses 31 bit-flags (maximum for ints, uints could
  11. /// be 32 bit-flags, ulong could be 64 bit-flags).
  12. /// </summary>
  13. [Flags]
  14. public enum ShaderFeatureFlags
  15. {
  16. #region Basic
  17. /// <summary>
  18. /// Basic shader feature always set, provides always a diffuse map.
  19. /// </summary>
  20. Basic = 0,
  21. #endregion
  22. #region UI2D
  23. /// <summary>
  24. /// By default all shaders are for 3D rendering (meshes, effects, etc.).
  25. /// If a shader should target 2D and more specifically UI rendering, then
  26. /// use this flag to make sure we only handle 2D shader code parts and
  27. /// also use ScreenSpace.ViewProjection2D together with
  28. /// Shader.Set2DRenderMatrix instead of the default
  29. /// ScreenSpace.ViewProjection3D.
  30. /// </summary>
  31. UI2D = 1,
  32. #endregion
  33. #region VertexCompression
  34. /// <summary>
  35. /// Normally vertex data is just a bunch of Vectors, Colors and floats
  36. /// in general, which works fine on fast platforms, but on lower quality
  37. /// mobile devices this could kill bandwidth and fill-rate, so we sometimes
  38. /// need to make sure that we use compressed vertex data. Please note that
  39. /// this flag is often set automatically for low quality mobile devices
  40. /// even if the shader designer did not specify it himself (which he can
  41. /// do both for testing and if more precision is not even required on HD
  42. /// shader and hints set in the MaterialEditor.
  43. /// </summary>
  44. VertexCompression = 2,
  45. #endregion
  46. #region LightMap
  47. /// <summary>
  48. /// Do we have a secondary UV texture channel for a light map? Then this
  49. /// flag must be set. Since dynamic lights are usually way too expensive
  50. /// on mobile platforms we should bake all static geometry with light maps
  51. /// to give games a nice look. We usually even use a little HDR in light
  52. /// maps, but not by providing floating point or HDR light map textures
  53. /// (they have too much overhead for mobile platforms), but instead by
  54. /// just multiplying all light map values by 4, thus the light can be
  55. /// darkened down if it is below 0.25, and lightened up if it is above.
  56. /// Animated and dynamic game objects can still have different lighting or
  57. /// a combination of light maps and lighting in shaders. Remember even on
  58. /// consoles and in big engines like Unreal light maps are used for almost
  59. /// everything :) If this flag is off then you are probably in some unit
  60. /// test, 2D code or your game is ugly :D
  61. /// </summary>
  62. LightMap = 4,
  63. #endregion
  64. #region Lighting
  65. /// <summary>
  66. /// Helper flag to indicate that this shader has no texturing, no UV
  67. /// channel is needed in the vertex data and the material also has no
  68. /// textures set (just material colors). Should be used together with the
  69. /// Lighting flag, else you will only see whatever static computation the
  70. /// pixel shader throws out (e.g. an ambient color or maybe vertex colors,
  71. /// which are used for line and effect shaders btw).
  72. /// No diffuse map is used. Even it is set in basic.
  73. /// </summary>
  74. NoTexturing = 8,
  75. /// <summary>
  76. /// Should dynamic directional lighting be used for this shader? This has
  77. /// the lowest impact on vertex and pixel shaders, but it still adds a
  78. /// few instructions. Note that any lighting calculation needs normals
  79. /// in the vertex data. A simple texturing shader with no flags will
  80. /// result in a very fast 1 pixel shader instruction shader, but adding
  81. /// directional lighting adds 1 or 2 pixel shader instruction (2 if the
  82. /// directional light contribution is calculated in the pixel shader, but
  83. /// it can also be done in the vertex shader, then it is just one pixel
  84. /// shader instruction: ambientColor + diffuseColor * lightContribution,
  85. /// which translates to mad r0, r0, c2, c1).
  86. /// </summary>
  87. DynamicDirectionalLighting = 16,
  88. /// <summary>
  89. /// Point lights are usually calculated (or at least pre-calculated) in
  90. /// the vertex shader and thus are very heavy on the computation side.
  91. /// They add about 20 instructions just for one point light because the
  92. /// light direction needs to be dynamically calculated (4 instructions).
  93. /// Then we need to calculate the distance and build a normal vector (3
  94. /// instructions) and we also need to calculate the attenuation (7
  95. /// instructions). And then all this needs to be applied to the final
  96. /// ambientDiffuseColor for the vertex for use in the pixel shader (6
  97. /// instructions), which adds up to 20 vertex shader instructions or even
  98. /// more for more complex light shaders (adding colors, fall-offs, etc.)!
  99. /// Some calculations can be done in the pixel shader adding a few more
  100. /// instructions there (e.g. applying the light normal and calculating the
  101. /// ambientDiffuseColor there for more realistic close up light gradients),
  102. /// but we should always pre-calculate the light direction and attenuation
  103. /// in the pixel shader. Note: If you use two dynamic point lights, use
  104. /// DynamicPointLight and DynamicSecondPointLight!
  105. /// </summary>
  106. DynamicPointLight = 32,
  107. /// <summary>
  108. /// Calculate a second point light, which usually adds another 10-20
  109. /// vertex shader instructions. See DynamicPointLight for all the notes.
  110. ///Note: Add spot lights, more?
  111. /// </summary>
  112. DynamicSecondPointLight = 64,
  113. /// <summary>
  114. /// Hint to do the light calculation as much as possible in the pixel
  115. /// shader to have more accurate per pixel lighting at the cost of
  116. /// performance. This is usually not used, but if you have close ups
  117. /// or your vertices are too low for good lighting, it can be used to
  118. /// pretty up your final result a bit. For low quality mobile platforms
  119. /// this usually kills the fill-rate performance because we can only do a
  120. /// few pixel shader instructions, e.g. a DynamicPointLight shader with
  121. /// Specular turned on too adds 16 pixel shader instructions and for
  122. /// more than 2-3 instructions on iPad (because of the high resolution) or
  123. /// screen with that complex pixel shaders at 60fps anymore! Note even
  124. /// also all have high resolutions btw) cannot handle this kind of complex
  125. /// pixel shaders. You either need to make sure this is only used in
  126. /// specialized cases when the camera cannot go that close to objects or
  127. /// switch the shader if the object gets too close or just use a much
  128. /// lower resolution or frame rate.
  129. /// </summary>
  130. PerPixelLighting = 128,
  131. /// <summary>
  132. /// Provides ambient color and diffuse color which calculated with the
  133. /// diffuse map. Everything else is set by each shader feature, e.g.
  134. /// specular has specular color and shininess.
  135. /// </summary>
  136. AmbientDiffuse = 256,
  137. /// <summary>
  138. /// Add specular color calculation into the mix, the SpecularColor is
  139. /// added to the final pixel if the light reflection is right. This only
  140. /// makes sense if we have any lighting (DynamicDirectionalLighting or
  141. /// DynamicPointLight). Mostly used together with NormalMapping (which
  142. /// also needs lighting to work correctly) and only adds about 1 varying
  143. /// and maximal one instructions to the pixel shader. Specular lighting
  144. /// is however a little overhead in the vertex shader or even the pixel
  145. /// shader if PerPixelLighting is used.
  146. /// </summary>
  147. Specular = 512,
  148. /// <summary>
  149. /// Same as Specular, but instead of adding the SpecularColor at the end
  150. /// we multiply it with the final diffuse color. This has 4 advantages:
  151. /// 1. The specular effect is much weaker this way, 2. The specular color
  152. /// is not equally distributed, but instead depends on the texture color
  153. /// (black pixels get no specular, brighter ones get lightened up), 3. the
  154. /// vertex and pixel shader impact is usually 1 instruction less and 4.
  155. /// we even save one varying because we can pre-calculate this in the same
  156. /// ambientDiffuseColor variable we use for lighting anyway. This technique
  157. /// has its drawbacks obviously, it can only be used for not so shiny
  158. /// materials. For example metal looks much better with a Specular shader,
  159. /// but for some materials this technique might look good or even better.
  160. /// </summary>
  161. SpecularDiffuse = 1024,
  162. #endregion
  163. #region NormalMapping
  164. /// <summary>
  165. /// Normal mapping shader, which requires both normals (like for any
  166. /// lighting shaders) and also tangents (binormals are calculated in the
  167. /// vertex shader). Normal mapping also only makes sense if we have
  168. /// lights (either directional lighting or point lights). It can be
  169. /// combined with LightMap shaders, but there are issues there: Directional
  170. /// light maps are complex and not really suited for mobile platforms,
  171. /// even with normal light maps, normal mapping should not be used too
  172. /// heavily because light maps already have all lighting pre-calculated.
  173. /// Please also note that normal mapping adds significant overhead to
  174. /// the pixel shader and bandwidth because normal mapping is a per pixel
  175. /// operation. Diffuse (without specular) normal mapping can optimized to
  176. /// 4 pixel shader instructions, so it is fast enough even for slow
  177. /// mobile platforms if not used everywhere (together with LightMaps it
  178. /// might be too much both bandwidth and pixel fill rate wise). Specular
  179. /// normal mapping is more complex (at least 8 pixel shader instructions)
  180. /// and should only be used on small surfaces for slow platforms, else it
  181. /// might kill your performance (same tips as for PerPixelLighting apply).
  182. /// </summary>
  183. NormalMap = 2 * 1024,
  184. #endregion
  185. #region DetailMapping
  186. /// <summary>
  187. /// The Detailmap is a tiled texture that is added to improve the sharpness
  188. /// especially in highly scaled textures. There is a texture on which a
  189. /// fine pattern is shown (usually this is a "noise" effect used).
  190. /// The Detailmap is tiled over the terrain and this combined with a
  191. /// diffuse mal or color map.
  192. /// </summary>
  193. DetailMapping = 4 * 1024,
  194. #endregion
  195. #region SpecularMapping
  196. /// <summary>
  197. /// Gloss (specular map) mapping effect for a directional or point light
  198. /// shaders. Does not add any significant pixel shader overhead, but
  199. /// requires a lot more bandwidth and requires content that is usually
  200. /// not available (has to be created on the artist side).
  201. /// </summary>
  202. SpecularMap = 8 * 1024,
  203. #endregion
  204. #region ColoredVertices
  205. /// <summary>
  206. /// Color is used for vertices, this is not really important for the
  207. /// final pixel output the user sees, but there are different ways
  208. /// rendering of colored output can be optimized. For example it is more
  209. /// efficient to use colored vertices for lines and effects using the
  210. /// same shader instead of using different AmbientColor or DiffuseColor
  211. /// material settings because switching materials or even updating
  212. /// shader parameters is very expensive, not just because you need to
  213. /// do the actual material update, but also because you cannot combine
  214. /// vertices and meshes that easily. For static or animated 3D mesh
  215. /// geometry on the other hand this should be used because coloring those
  216. /// things besides using different light sources and colors is almost non
  217. /// existent (if you need to use different colors for many meshes that
  218. /// all share the same materials otherwise, it is obviously clever again
  219. /// to use VertexColors instead of using many different materials).
  220. /// </summary>
  221. ColoredVertices = 16 * 1024,
  222. #endregion
  223. #region Skinning
  224. /// <summary>
  225. /// Is skinning being used? If this is on all vertices must have SkinWeight
  226. /// and SkinIndex data (2 floats each usually, but can also be optimized
  227. /// to 2 shorts each). We also need a lot of bones that need to be updated
  228. /// for each animated mesh and because of those bones skinning adds
  229. /// significant overhead to the vertex shader, which is still much better
  230. /// than to do all this computation on the CPU (usually a lot of vertices
  231. /// are affected), but obviously not as fast as static geometry!
  232. /// Because of this overhead the number of animated meshes should be
  233. /// kept as low as possible and the number of bones and vertices are also
  234. /// very important for fine tuning the performance on each platform.
  235. /// </summary>
  236. UseSkinning = 32 * 1024,
  237. #endregion
  238. #region Special
  239. /// <summary>
  240. /// If fog is used this flag should be set and the ShaderParameters
  241. /// array should contain: FogColor, FogStart and FogEnd. This does not
  242. /// mean those variables are used as shader uniforms, they are usually
  243. /// constant and can be used for both fixed function pipeline code and
  244. /// for shader code.
  245. /// Note: Currently only the FogColor is used in the shader, the rest
  246. /// is baked as constants into it (faster because we don't need to
  247. /// calculate FogEnd-FogStart and it makes more sense to have the same
  248. /// values for all shaders anyway).
  249. /// </summary>
  250. Fog = 64 * 1024,
  251. /// <summary>
  252. /// Use fresnel for lighting calculations, which will mostly reduce the
  253. /// specular color effect and show it stronger at polygons facing 90
  254. /// degrees away from the camera, which looks nice at silhouettes.
  255. /// Please note that we will completely ignore this effect for low
  256. /// quality platforms or if there is no lighting.
  257. /// </summary>
  258. Fresnel = 128 * 1024,
  259. /// <summary>
  260. /// Parallax mapping is usually used in combination with normal mapping,
  261. /// but you can use it own its own. It needs an extra height map (usually
  262. /// just the light map or normal map extra alpha color channel) for even
  263. /// cooler depth effects on the texture. Adds about 2 instructions, but
  264. /// even if that overhead is ok, also additional work at the artist side
  265. /// is needed, not only to create the extra height/bump map, but also to
  266. /// fine tune the parallax amount to look nice. The height map should be
  267. /// as blurry as possible, high variations will cause parallax glitches.
  268. /// </summary>
  269. ParallaxMap = 256 * 1024,
  270. // NOTE: Removed Glass, because we have no more bits.
  271. ///// <summary>
  272. ///// Is this shader rendering some kind of glass or transparent surface?
  273. ///// For very low performance platforms we can ignore these materials
  274. ///// completely (it will just be completely transparent), for medium
  275. ///// performance platforms we can simplify this a bit (because this kind
  276. ///// of shaders are usually slow) and for high quality platforms we can
  277. ///// do whatever the shader wants us to do.
  278. ///// </summary>
  279. //Glass = 256 * 1024,
  280. //Note: Removed CubeMapping
  281. ///// <summary>
  282. ///// By default all shaders only handle UV texture coordinates, but for
  283. ///// cube mapping or reflection mapping we need UVW texture mapping in the
  284. ///// VertexFormat. This flag helps us to optimize this render path and to
  285. ///// provide a fallback shader or fallback code on non-shader platforms.
  286. ///// </summary>
  287. //CubeMapping = 256 * 1024,
  288. /// <summary>
  289. /// If this is a water shader, then this is one of the most complex and
  290. /// advanced shaders we can do, but we still need fallbacks for slower
  291. /// platforms. For example on fixed function and the slowest mobile
  292. /// devices we just use a moving texture on the surface wobbling around,
  293. /// in medium platforms we might add some more pixel and vertex shader
  294. /// instructions for waves and all the advanced stuff can be done in
  295. /// specially fine tuned water shaders using pixel shader 3.0, etc.
  296. /// </summary>
  297. Water = 512 * 1024,
  298. //NOTE: Removed SubsurfaceScattering, because we have no more bits.
  299. ///// <summary>
  300. ///// Subsurface lighting shaders for light shaders. A lambertian-like
  301. ///// surface with light "bleed-through". Useful for soft translucent
  302. ///// materials like skin. The "subsurfaceColor" shader parameter represents
  303. ///// the tinting acquired by light diffused below the surface. Set the
  304. ///// "subsurfaceRollOff" angle to the cosine of the angle used for
  305. ///// additional lighting "wraparound". The diffuse effect propagates based
  306. ///// on the angle of LightDirection versus SurfaceNormal.
  307. ///// </summary>
  308. //SubsurfaceScattering = 1024 * 1024,
  309. /// <summary>
  310. /// AlphaTest skip everything below 0.66 alpha, which is sometimes useful
  311. /// for decals and models with hard alpha (trees, etc.) which look better
  312. /// without having to sort anything. Examples: GlowLightEffect,
  313. /// LensFlareAdditive, TreeLeavesAlphaTest, etc.
  314. /// </summary>
  315. AlphaTest = 1024 * 1024,
  316. //Note: Unused too right now:
  317. ///// <summary>
  318. ///// Use Hemisphere Lighting. This adds overhead to the vertex shader, but
  319. ///// the pixel cost is usually very low. Currently only used for some demos
  320. ///// and maybe very big objects in the back or the sky itself. Completely
  321. ///// ignored on slower platforms.
  322. ///// </summary>
  323. //HemisphereLighting = 2 * 1024 * 1024,
  324. //Note: Also unused
  325. ///// <summary>
  326. ///// Are we using a reflection surface? Often used together with Water,
  327. ///// Glass or CubeMapping (then this uses a ReflectionCubeMap). Reflection
  328. ///// can significantly add realism to a scene, but usually we need to
  329. ///// calculate the reflection render target each frame for a realistic
  330. ///// water for example, which adds so much overhead, it makes this technique
  331. ///// unusable for lower quality mobile platforms. On the other hand we can
  332. ///// use pre-calculated reflection maps, especially for ReflectionCubeMaps,
  333. ///// which still looks okay in most cases and only adds some bandwidth
  334. ///// overhead and 1 or even zero extra (because all we want might be the
  335. ///// reflection cube map anyway) pixel shader instructions.
  336. ///// </summary>
  337. //Reflection = 4 * 1024 * 1024,
  338. #endregion
  339. #region ShadowMapping
  340. /// <summary>
  341. /// Is this a shader to generate a shadow map? While the shader itself
  342. /// might not be very complex (we just need to render a depth map from
  343. /// the given light position), the implications on the engine are huge!
  344. /// First of all we need to render the whole scene from the light
  345. /// perspective into a render target and then use that for the
  346. /// UseShadowMap shader, which should be added dynamically to all existing
  347. /// shaders to make shadow mapping even work (or alternatively if the
  348. /// bandwidth allows this, we could render a extra pass on top of the
  349. /// final output lighten/darken up things). And finally we need to provide
  350. /// fallbacks for platforms that do not support shadow mapping at all
  351. /// each object if the performance allows us to do so (if not, use fake
  352. /// shadow blobs) and then display all these stencil or fake shadows
  353. /// instead of using a real shadow mapping algorithm.
  354. /// </summary>
  355. GenerateShadowMap = 8 * 1024 * 1024,
  356. /// <summary>
  357. /// This is the counterpart for GenerateShadowMap. The generated shadow
  358. /// map (or if fallbacks were used, the generated stencil shadows or
  359. /// shadow blobs) will be shown here. There are two ways the shadow map
  360. /// can be applied: 1. through an extra pass with a shader just using
  361. /// this flag, but this adds significant bandwidth and especially vertex
  362. /// computation overhead (we need to render the whole scene again) or 2.
  363. /// by just adding this flag to all the existing shaders in the scene,
  364. /// which only adds a single instructions to each pixel for the shadow
  365. /// mapping usually (can be more for more complex comparisons, but those
  366. /// should be done at the vertex level anyway). The second way is much
  367. /// faster and more desirable, but a lot harder to do for the engine,
  368. /// which should not matter for games however (because either you use
  369. /// shadow mapping in your game for a specific platform or not, only in
  370. /// unit tests you might want an extra pass to tweak the shadows).
  371. /// </summary>
  372. UseShadowMap = 16 * 1024 * 1024,
  373. #endregion
  374. #region PreScreen
  375. //Note: Removed, not longer used, we only use a sky dome right now.
  376. ///// <summary>
  377. ///// The sky needs to be rendered before everything else, which we call
  378. ///// PreScreen shaders in the engine (other stuff can be done before
  379. ///// rendering as well, but the sky makes the most sense here). This
  380. ///// uses a cube map for the sky and will render it to the background
  381. ///// (RenderLayer.Background) without depth buffer enabled. Everything
  382. ///// else that will be rendered will be on top!
  383. ///// </summary>
  384. //SkyCubeMapping = 32 * 1024 * 1024,
  385. #endregion
  386. #region PostScreen
  387. /// <summary>
  388. /// Use high dynamic range for the post screen calculations. This means
  389. /// the whole rendering happens into a render target that can do HDR
  390. /// and then the post screen shaders will apply tone mapping after
  391. /// all the effects are done to display the final result on the screen.
  392. /// Obviously this is not only slow on most mobile platform, but almost
  393. /// always not even supported, thus dynamic tone mapping is a thing for
  394. /// PC and consoles, but in the future some mobile platforms might have
  395. /// enough support and speed to do this (maybe not full scale, but for
  396. /// some stuff).
  397. /// </summary>
  398. PostScreenHDR = 64 * 1024 * 1024,
  399. /// <summary>
  400. /// Blur the post screen. Will just make everything blurry depending on
  401. /// how much pixel instructions and passes we can use for this (this is
  402. /// not a cheap effect and thus has to be ignored like all other post
  403. /// screen shaders on low quality mobile platforms).
  404. /// <para></para>
  405. /// Add fake HDR and glow effects to the scene by blurring it down and
  406. /// adding all bright spots to the final screen on top. This way we get
  407. /// a nice glow around all bright objects. This has similar impact on
  408. /// performance as Blur, but we can do some extra optimizations here.
  409. /// Still the main problem is the fill rate, to use this effect we not
  410. /// only need to calculate all the blur texture targets, but we also need
  411. /// to apply the glow to the final image, which costs at least 2 extra
  412. /// instructions (more if the glow is dynamic) for each pixel on the
  413. /// screen plus all the overhead with the render to texture issues.
  414. /// <para></para>
  415. /// Radial blur effect for fast moving games like RocketCommander or
  416. /// the RacingGame. I like it :) Might however not be suitable to every
  417. /// game. Main advantage here is that we can just reuse our last render
  418. /// target and go from there, this is much faster than Blur or Glow, but
  419. /// we still need a render target thus we still have that overhead.
  420. /// <para></para>
  421. /// Radial zoom is even crazier than just blurring the borders, we also
  422. /// zoom into the screen giving the impression of motion blur. This is
  423. /// again the same cheap effect as RadialBlur (also used in
  424. /// RocketCommander and RacingGame btw). It can look very cool and even
  425. /// has been used similarity in movies like Pitch Black, but when rotating
  426. /// around the whole illusion gets destroyed and for still pictures it is
  427. /// also not usable. Real per pixel motion blur is very hard however.
  428. /// </summary>
  429. PostScreenBlurOrGlow = 128 * 1024 * 1024,
  430. /// <summary>
  431. /// Color adjustment shader. Should mainly be used for unit testing and
  432. /// tweaking, not in the final game. Textures should already be tweaked by
  433. /// the artists to fit the final color and even if that was not done, we
  434. /// have a content system and can easily recolor all textures instead of
  435. /// doing this expensive operation at runtime! Sometimes we might want to
  436. /// change the mood of the scene however or we just want to color level
  437. /// parts differently. Then use this shader to recolor the whole scene and
  438. /// final output. On slower platforms this must be ignored most likely
  439. /// (so recoloring textures works better there).
  440. /// <para></para>
  441. /// PostScreenContrast:
  442. /// Similar to ColorAdjust Contrast should have been added to the
  443. /// textures already by the artists, but sometimes we might want to change
  444. /// the contrast dynamically for effects, menus or more dramatic scenes.
  445. /// This has a high overhead like ColorAdjust for a pretty simple effect.
  446. /// <para></para>
  447. /// PostScreenDarken:
  448. /// Darken the whole screen down. We don't need a shader for this,
  449. /// it can also be done with an overlay texture (even without any shaders
  450. /// at all). That still has the same pixel fill rate overhead however!
  451. /// On slower platforms use this with care, it is better to provide
  452. /// special code and only darken parts of the screen (e.g. if the menu
  453. /// is in the center, but you can see the game in the background, only
  454. /// darken the left and right sides that the user can see, not the whole
  455. /// screen).
  456. /// <para></para>
  457. /// PostScreenDesaturate:
  458. /// Desaturate the whole screen (same tips as for Darken apply here).
  459. /// This shader is really simple (even when calculating 0.3 * R +
  460. /// 0.59 * G + 0.11 * B), but we still have the same overhead as for all
  461. /// post screen shaders here (render target, fill rate bound), which
  462. /// can be optimized by only applying this post screen shader to smaller
  463. /// parts of the screen or by using different textures.
  464. /// <para></para>
  465. /// Please note that most PostScreen shaders we can combined, it makes no
  466. /// sense to apply different post screen shaders one after another if we
  467. /// can all do it in the same shader and highly optimize it there :)
  468. /// </summary>
  469. PostScreenColorAdjust = 256 * 1024 * 1024,
  470. //Unused:
  471. ///// <summary>
  472. ///// A toon shader will make look all edges much more sharp by adding
  473. ///// black borders to them and then it will also simplify all colors
  474. ///// giving the final screen a much more cartoonish like look. Has
  475. ///// significant pixel and bandwidth overhead however. Can sometimes be
  476. ///// faked with special geometry and by providing textures already in
  477. ///// a cartoonish look, maybe only adding borders if the platform is
  478. ///// fast enough for that.
  479. ///// <para></para>
  480. ///// PostScreenEdgeDetect:
  481. ///// Edge detection shader, which is the basis of the Toon post screen
  482. ///// shader. This will go through all pixels and try to find edges by
  483. ///// comparing neighboring pixels (has obviously a high pixel fill rate
  484. ///// impact). Then we can display those edges or do other things.
  485. ///// </summary>
  486. //PostScreenToon = 512 * 1024 * 1024,
  487. //Unused:
  488. ///// <summary>
  489. ///// PostScreenRain: Post screen rain effect artists won't like, but it is
  490. ///// cheap and easy to enable.
  491. ///// <para></para>
  492. ///// PostScreenSnow: Post screen snow effect artists won't like, but it is
  493. ///// cheap and easy to enable.
  494. ///// <para></para>
  495. ///// PostScreenThermalView:
  496. ///// Fake thermal view by applying a thermal view texture to each pixel in
  497. ///// the scene (after gray scaling each pixel). Looks wrong, but still is
  498. ///// a fun effect. More advanced thermal view shaders could have extra
  499. ///// heat map textures for each object, use the depth or do other crazy
  500. ///// things, but that is not supported right now.
  501. ///// <para></para>
  502. ///// PostScreenWobble:
  503. ///// Simple wobble effect, has almost no overhead on the pixel shader, but
  504. ///// needs a render target, thus not easily possible on mobile platforms.
  505. ///// <para></para>
  506. ///// PostScreenMenu:
  507. ///// Menu post screen shader for special effects in the menu like
  508. ///// distortions, color corrections, wobbling, water surface and other
  509. ///// things.
  510. ///// <para></para>
  511. ///// Note: PostScreenMotionBlur: Per pixel motion blur, very hard to
  512. ///// implement correctly.
  513. ///// </summary>
  514. //PostScreenEffects = 1024 * 1024 * 1024,
  515. #endregion
  516. }
  517. }