Difference between revisions of "Shaders"

From GiderosMobile
 
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
 
'''Supported platforms:''' [[File:Platform android.png]][[File:Platform ios.png]][[File:Platform mac.png]][[File:Platform pc.png]][[File:Platform html5.png]][[File:Platform winrt.png]][[File:Platform win32.png]][[File:Platform linux.png]]<br/>
 
'''Supported platforms:''' [[File:Platform android.png]][[File:Platform ios.png]][[File:Platform mac.png]][[File:Platform pc.png]][[File:Platform html5.png]][[File:Platform winrt.png]][[File:Platform win32.png]][[File:Platform linux.png]]<br/>
'''Available since:''' Gideros 2023.1<br/>
+
'''Available since:''' Gideros 2015.06.30<br/>
  
 
=== Description ===
 
=== Description ===
[[Writing Shaders]]<br/>
+
As you may know, most of graphics hardware now allow processing of user code directly on the GPU. This means two things:
[[Lua Shaders]]<br/>
+
* you can relieve the CPU from performing some graphics-related computation by letting the GPU perform those computations and thus gain overall performance in your app
[[Lua Shaders Pebbles|Lua Shaders]]</br>
+
* you can achieve beautiful graphic effects by modifying the per-pixel rendering process
 +
 
 +
Those little pieces of code you can upload to the GPU are called Shader.
 +
 
 +
Gideros uses a shader system (a programmable pipeline), which uses five distinct shaders:
 +
* the '''''Basic''''' shader handle shapes with a constant color
 +
* the '''''Color''''' shader handle shapes with per-vertex colors (mostly used by Mesh sprite)
 +
* the '''''Texture''''' shader handle textured shapes (Bitmaps)
 +
* the '''''TextureColor''''' shader handle textured and per-vertex colored shapes
 +
* the '''''Particle''''' shader deals with Box2D particle systems
 +
 
 +
The shader API allows replacing the default shader used by Gideros with a custom one, on a sprite per sprite basis. As with most of Gideros API, this one is straightforward: create a Shader object and assign it to one or several sprites.
 +
<syntaxhighlight lang="lua">
 +
local myShader=Shader.new(…shader parameters…)
 +
mySprite:setShader(myShader)
 +
</syntaxhighlight>
 +
 
 +
Gideros users can access the shaders system themselves, opening a broad range of possibilities. The rendering pipeline has several chained processing stages, which is why we call it a pipeline. A few stages are programmable, each requiring a particular type of program or shader. Gideros uses and lets user access two of them:
 +
 
 +
==== The Vertex Shader ====
 +
The first processing stage that Gideros deals with is the Vertex shader. As its name implies, its purpose is to manipulate vertices for the geometry being rendered. No real big deal here, most of the work of a vertex shader is transforming geometry coordinates from sprite local space to actual window coordinates. Other input data is most of the time just passed along unmodified to the next stage.
 +
 
 +
The Vertex shaders typically uses the following attributes:
 +
* Vertex coordinates (always)
 +
* Texture coordinates (if required)
 +
* Vertex color (if required)
 +
 
 +
==== The Fragment Shader (also called pixel shader)====
 +
The fragment shader is the most interesting. It takes its inputs from the vertex shader outputs but is applied to every pixel of the shape being rendered. Input data from the vertex shader is interpolated and then fed to the fragment shader. The final goal of the fragment shader is to produce the color of the pixel to actually draw.
 +
 
 +
The Fragment shaders typically uses the following attributes:
 +
* Interpolated texture coordinates (if required)
 +
* Interpolated pixel color (if required)
 +
 
 +
=== Shader Programs ===
 +
Plenty of literature is available to learn writing shaders, so we won’t go into language details here.
 +
 
 +
Shaders can be written in either in the '''Shader language''' for the platform you are coding for (eg. ''GLSL'', ''HLSL'' or ''MTL'') or '''Lua''' (''recommended'').
 +
 
 +
{|-
 +
|style="width: 50%;"|
 +
::::::::::::::
 +
==='''[[Writing Shaders|Shader Language]]'''===
 +
 
 +
|style="width: 50%;"|
 +
::::::::::::::
 +
==='''[[Lua Shaders]]'''===
 +
|}
  
 
{{GIDEROS IMPORTANT LINKS}}
 
{{GIDEROS IMPORTANT LINKS}}

Revision as of 05:44, 4 November 2023

Supported platforms: Platform android.pngPlatform ios.pngPlatform mac.pngPlatform pc.pngPlatform html5.pngPlatform winrt.pngPlatform win32.pngPlatform linux.png
Available since: Gideros 2015.06.30

Description

As you may know, most of graphics hardware now allow processing of user code directly on the GPU. This means two things:

  • you can relieve the CPU from performing some graphics-related computation by letting the GPU perform those computations and thus gain overall performance in your app
  • you can achieve beautiful graphic effects by modifying the per-pixel rendering process

Those little pieces of code you can upload to the GPU are called Shader.

Gideros uses a shader system (a programmable pipeline), which uses five distinct shaders:

  • the Basic shader handle shapes with a constant color
  • the Color shader handle shapes with per-vertex colors (mostly used by Mesh sprite)
  • the Texture shader handle textured shapes (Bitmaps)
  • the TextureColor shader handle textured and per-vertex colored shapes
  • the Particle shader deals with Box2D particle systems

The shader API allows replacing the default shader used by Gideros with a custom one, on a sprite per sprite basis. As with most of Gideros API, this one is straightforward: create a Shader object and assign it to one or several sprites.

local myShader=Shader.new(shader parameters)
mySprite:setShader(myShader)

Gideros users can access the shaders system themselves, opening a broad range of possibilities. The rendering pipeline has several chained processing stages, which is why we call it a pipeline. A few stages are programmable, each requiring a particular type of program or shader. Gideros uses and lets user access two of them:

The Vertex Shader

The first processing stage that Gideros deals with is the Vertex shader. As its name implies, its purpose is to manipulate vertices for the geometry being rendered. No real big deal here, most of the work of a vertex shader is transforming geometry coordinates from sprite local space to actual window coordinates. Other input data is most of the time just passed along unmodified to the next stage.

The Vertex shaders typically uses the following attributes:

  • Vertex coordinates (always)
  • Texture coordinates (if required)
  • Vertex color (if required)

The Fragment Shader (also called pixel shader)

The fragment shader is the most interesting. It takes its inputs from the vertex shader outputs but is applied to every pixel of the shape being rendered. Input data from the vertex shader is interpolated and then fed to the fragment shader. The final goal of the fragment shader is to produce the color of the pixel to actually draw.

The Fragment shaders typically uses the following attributes:

  • Interpolated texture coordinates (if required)
  • Interpolated pixel color (if required)

Shader Programs

Plenty of literature is available to learn writing shaders, so we won’t go into language details here.

Shaders can be written in either in the Shader language for the platform you are coding for (eg. GLSL, HLSL or MTL) or Lua (recommended).

Shader Language

Lua Shaders