PageRenderTime 109ms CodeModel.GetById 60ms app.highlight 10ms RepoModel.GetById 30ms app.codeStats 0ms

/Utilities/Graphics/ShaderFeatures/ShaderFeatureFlags.cs

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