https://wiki.delphigl.com/api.php?action=feedcontributions&feedformat=atom&user=Igel457DGL Wiki - Benutzerbeiträge [de]2026-05-17T23:47:23ZBenutzerbeiträgeMediaWiki 1.27.4https://wiki.delphigl.com/index.php?title=Deferred_Shading&diff=24779Deferred Shading2010-03-15T12:31:19Z<p>Igel457: /* Idee */</p>
<hr />
<div>= Deferred Shading =<br />
<br />
Der Begriff ''Deferred Shading'' (zu dt. "verzögertes Schattieren") oder auch ''Deferred Lighting'' ("verzögerte Beleuchtung") beschreibt eine Technik, mit deren Hilfe die Geometrieverarbeitung von der Lichtberechnung getrennt werden kann. Dies erlaubt hunderte Lichtquellen in einer hoch-komplexen Szene.<br />
<br />
== Idee ==<br />
Um eine Szene mit einem traditionellen Forward-Renderer zu beleuchten, wird normalerweise jedes Objekt der Szene mit den entsprechenden Beleuchtungsparametern der Lichtquelle gezeichnet. Die verschiedenen Ergebnisse werden durch additives Blenden akkumuliert. Für jede Lichtquelle muss also jedes Objekt gezeichnet werden. Angenommen wir haben ''nL'' Lichtquellen und ''nO'' Objekte, dann liegt die Anzahl der Rendercalls bei ''O(nO * nL)''. Natürlich ist es möglich mehrere Lichtquellen in einem Pass (z.B. 8 auf einmal) zu berechnen, aber wir gehen von hunderten Lichtquellen aus, es sind also mehrere Passes notwendig und die Geometrie müsste entsprechend mehrfach verarbeitet werden.<br />
<br />
''Deferred Shading'' verfolgt einen anderen Ansatz: Anstatt jedes Objekt der Szene für jeden Licht-Pass neu zu renderen, werden zunächst für jeden Pixel alle beleuchtungsrelevanten Daten (z.B. 3D-Position, Normale, Textur-Farbe, etc.) in ein oder mehrere Rendertargets (oftmals auch G-Buffer genannt) geschrieben. Die eigentliche Lichtberechnung kann nun durchgeführt werden indem ein bildschirmfüllendes Quad bzw. die Lichtgeometrie (Kugel für ein Punktlicht, Kegel für ein Spotlight) gerendert wird. Für jeden Pixel werden die Daten aus dem G-Buffer ausgelesen und die Beleuchtung entsprechend dieser Daten berechnet. Die Zahl der Rendercalls liegt bei diesem Ansatz nur noch bei ''O(nO + nL)''. Mit dieser Methode sind hunderte Lichter gleichzeitig in einer hoch-komplexen Szene möglich.<br />
<br />
Das Verfahren ist nur dann sinnvoll, wenn man es mit einer sehr komplexen Geometrie und sehr vielen Lichtquellen zu tun hat. Hat man zum Beispiel zwar viele Lichtquellen, aber eine einfache Geometrie, kann bereits ein einfacher Depth-Only-Pass zum initialisieren des Z-Buffers verhindern, dass für unsichtbare Pixel unnötige Lichtberechnungen durchgeführt werden.<br />
<br />
== Vor-/Nachteile ==<br />
<br />
'''Vorteile:'''<br />
* Viele Lichtquellen bei komplexer Geometrie möglich<br />
* Postprocessing Effekte (Bloom, Tonemapping, Depth of Field, etc.) können einfach angeschlossen werden, da bereits alle benötigten Informationen aufbereitet vorliegen.<br />
* Lichtberechnung mit reduzierter Auflösung möglich (sinnvoll z.B. bei FSAA, siehe [[Inferred Lighting]])<br />
<br />
'''Nachteile:'''<br />
* Kein Hardware Anti-Aliasing möglich<br />
* Transparente Objekte müssen getrennt behandelt werden (Abhilfe schafft [[Inferred Lighting]])<br />
* Nur auf neueren Grafikkarten mit MRT (Mutliple Render Target) und Floating Point-Textur Support möglich (ab DirectX 9 kompatiblem Grafikchip; OpenGL Version ???)<br />
<br />
== Implementierung ==<br />
Zunächst müssen die Geometriedaten in den (G-Buffer) geschrieben werden. Hierzu benötigen wir drei 16-Bit Float Rendertarget Texturen. Niedrigere Bittiefen sind für Positionsbeschreibung und Normalenvektor zu wenig. Alle Rendertarget-Texturen müssen die gleiche Bittiefe haben. Sind mehrere Rendertargets aktiviert, so wird Hardware-Anti-Aliasing automatisch abgeschaltet. Die folgenden Beispiele sind mit Andorra 2D entwickelt und sollten recht einfach verständlich und nach OpenGL/DirectX umzusetzen sein.<br />
<br />
'''Schritt 1: Erstellen der Rendertargets'''<br />
<source lang="delphi"><br />
FRT_1_Albedo := TAdRenderTargetTexture.Create(FDraw);<br />
FRT_1_Albedo.BitDepth := adF64Bit;<br />
FRT_1_Albedo.SetSize(surfacew, surfaceh);<br />
FRT_1_Albedo.Filter := atPoint;<br />
<br />
FRT_2_Position := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
<br />
FRT_3_Normal := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
<br />
FRT_4_Composite := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
</source><br />
<br />
'''Schritt 2: Der G-Buffer-Fill Shader (HLSL/Cg)'''<br><br />
Der hier gezeigte Shader ist nur ein einfaches Beispiel. Unter anderem kann durch das geschickte Weglassen von Daten (Berechnen von X, Y aus den Z und den Screen-Coordinaten im Lighting-Shader) Bandbreite eingespart werden.<br />
<source lang="c"><br />
//Fragment Shader<br />
<br />
struct fs_res {<br />
float4 position: COLOR1;<br />
float4 normal: COLOR2;<br />
float4 albedo: COLOR0;<br />
};<br />
<br />
fs_res fs_std_geometry(<br />
float3 viewpos: TEXCOORD0,<br />
float3 normal: TEXCOORD1<br />
)<br />
{<br />
fs_res OUT; <br />
<br />
OUT.position = float4(viewpos, 1.0f); <br />
OUT.normal = float4(normal, 1.0f);<br />
OUT.albedo = float4(1.0f, 1.0f, 1.0f , 1.0f);<br />
<br />
return OUT;<br />
}<br />
<br />
//Vertex Shader<br />
<br />
struct vs_res {<br />
float4 pos: POSITION;<br />
float3 viewpos : TEXCOORD0; <br />
float3 normal: TEXCOORD1;<br />
};<br />
<br />
vs_res vs_std_geometry(<br />
float3 position : POSITION,<br />
float3 normal: NORMAL,<br />
uniform float4x4 modelview,<br />
uniform float4x4 modelviewproj<br />
)<br />
{<br />
vs_res OUT; <br />
<br />
OUT.pos = mul(float4(position, 1.0f), modelviewproj);<br />
OUT.viewpos = mul(float4(position, 1.0f), modelview);<br />
OUT.normal = normalize(mul(float4(normal, 0.0f), modelview));<br />
<br />
return OUT;<br />
}<br />
</source><br />
<br />
<br />
'''Schritt 3: Daten in G-Buffer Rendern'''<br />
<source lang="delphi"><br />
//Activate the G-Buffers<br />
FDraw.AdAppl.SetRenderTarget(0, FRT_1_Albedo.Texture);<br />
FDraw.AdAppl.SetRenderTarget(1, FRT_2_Position.Texture);<br />
FDraw.AdAppl.SetRenderTarget(2, FRT_3_Normal.Texture);<br />
<br />
FDraw.AdAppl.Viewport := AdRect(0, 0, surfacew, surfaceh);<br />
FDraw.AdAppl.ClearSurface(AdRect(0, 0, surfacew, surfaceh), [alColorBuffer, alZBuffer,<br />
alStencilBuffer], Ad_ARGB(0, 0, 0, 0), 1, 1);<br />
<br />
//Activate the shaders<br />
FTransformShader.FragmentShader.BindEffect;<br />
FTransformShader.VertexShader.BindEffect;<br />
<br />
FScene.Draw(FCamera, nil, 0);<br />
<br />
//Deactivate the shaders<br />
FTransformShader.VertexShader.UnbindEffect;<br />
FTransformShader.FragmentShader.UnbindEffect;<br />
<br />
FDraw.AdAppl.SetRenderTarget(2, nil);<br />
FDraw.AdAppl.SetRenderTarget(1, nil);<br />
FDraw.AdAppl.SetRenderTarget(0, nil);<br />
</source><br />
<br />
<br />
'''Schritt 4: Einfacher Direktionaler Licht-Shader'''<br><br />
Das zur Beleuchtung verwendete Quad liegt in diesem (einfachen) Fall bereits projeziert in normierten Koordinaten vor.<br />
<source lang="c"><br />
struct ps_light_res {<br />
float4 color: COLOR0;<br />
};<br />
<br />
ps_light_res ps_light_geometry(<br />
float3 screenpos: TEXCOORD0,<br />
float3 viewpos: TEXCOORD1,<br />
float3 lightdir: TEXCOORD2,<br />
<br />
uniform sampler sPosition,<br />
uniform sampler sNormal,<br />
uniform sampler sAlbedo,<br />
uniform float4 lightcolor<br />
)<br />
{<br />
ps_light_res OUT;<br />
<br />
float4 col = tex2D(sAlbedo, float2(screenpos.x, -screenpos.y));<br />
float4 normal = tex2D(sNormal, float2(screenpos.x, -screenpos.y));<br />
<br />
OUT.color = float4((lightcolor * col * clamp(dot(normal.xyz, lightdir), 0.0f, 1.0f)).rgb, 1.0f);<br />
<br />
return OUT;<br />
}<br />
<br />
struct vs_light_res {<br />
float4 pos: POSITION;<br />
float3 screenpos: TEXCOORD0;<br />
float3 viewpos: TEXCOORD1;<br />
float3 lightdir: TEXCOORD2;<br />
};<br />
<br />
vs_light_res vs_light_geometry(<br />
float3 position : POSITION,<br />
uniform float4x4 modelview,<br />
uniform float4x4 modelviewproj,<br />
uniform float3 lightdir<br />
)<br />
{<br />
vs_light_res OUT;<br />
<br />
OUT.pos = float4(position, 1.0f);<br />
OUT.screenpos = position * float3(0.5f, 0.5f, 0.0f) + float3(0.5f, 0.5f, 0.0f);//mul(pos, modelviewproj);<br />
OUT.viewpos = mul(position, modelview);<br />
OUT.lightdir = normalize(mul(float4(lightdir, 0.0f), modelview));<br />
<br />
return OUT;<br />
}<br />
</source><br />
<br />
<br />
'''Schritt 5: Lichtquellen in das Composite RT rendern'''<br />
<source lang="delphi"><br />
//Render a directional light using a quad<br />
FDraw.AdAppl.SetRenderTarget(0, FRT_4_Composite.Texture);<br />
FDraw.AdAppl.Viewport := AdRect(0, 0, surfacew, surfaceh);<br />
FDraw.AdAppl.ClearSurface(AdRect(0, 0, surfacew, surfaceh), [alColorBuffer, alZBuffer,<br />
alStencilBuffer], Ad_ARGB(255, 0, 0, 0), 1, 1); <br />
<br />
FLightShader.FragmentShader.SetParameter('sAlbedo', FRT_1_Albedo.Texture);<br />
FLightShader.FragmentShader.SetParameter('sPosition', FRT_2_Position.Texture);<br />
FLightShader.FragmentShader.SetParameter('sNormal', FRT_3_Normal.Texture);<br />
<br />
FLightShader.FragmentShader.BindEffect;<br />
FLightShader.VertexShader.BindEffect;<br />
<br />
//Render a blue light<br />
FLightShader.FragmentShader.SetParameter('lightcolor', Ad_ARGB(255, 50, 50, 100));<br />
FLightShader.VertexShader.SetParameter('lightdir', AcVector_Normalize(AcVector3(2.0, 2.0, -1.0)));<br />
FQuad.BlendMode = bmAdd;<br />
FQuad.Draw(nil);<br />
<br />
FLightShader.FragmentShader.UnbindEffect;<br />
FLightShader.VertexShader.UnbindEffect;<br />
</source><br />
<br />
<br />
'''Schritt 6: Das Ergebnis Zeichnen'''<br><br />
Nun muss nur noch das Ergebnis im "Composite"-RT gezeichnet werden - oder weitere Post-Processing Maßnahmen durchgeführt werden.<br />
<br />
==Weblinks==<br />
* http://www.gamedev.net/reference/programming/features/defRender/<br />
<br />
==Siehe auch==<br />
* [[Shader]]<br />
* [[FBO]]<br />
* [[Inferred Lighting]]<br />
* [[Hintergrundwissen#Render-Pipeline|Render-Pipeline]]</div>Igel457https://wiki.delphigl.com/index.php?title=Deferred_Shading&diff=24766Deferred Shading2010-03-14T22:18:11Z<p>Igel457: /* Vor-/Nachteile */</p>
<hr />
<div>= Deferred Shading =<br />
<br />
Der Befriff ''Deferred Shading'' (zu dt. "verzögertes Schattieren") oder auch ''Deferred Lighting'' ("verzögerte Beleuchtung") beschreibt eine Technik, mit deren Hilfe eine komplette Lichtquelle mit nur einem einzigen Draw-Call abgebildet werden kann.<br />
<br />
== Vorgehensweise ==<br />
Um eine Szene mit einem traditionellen Forward-Renderer zu beleuchten, wird normalerweise jedes Objekt der Szene mit den entsprechenden Beleuchtungsparametern der Lichtquelle gezeichnet. Die verschiedenen Ergebnisse werden durch additives Blenden akkumuliert. Für jede Lichtquelle ''nl'' muss also jedes Objekt ''no'' gezeichnet werden. Die Anzahl der Rendercalls liegt also bei ''no * nl''. Hierdurch sind nur wenige Lichtquellen gleichzeitig möglich.<br />
<br />
''Deferred Shading'' verfolgt einen anderen Ansatz: Anstatt jedes Objekt der Szene für jede Lichtquelle neu zu renderen, werden zunächst alle beleuchtungsrelevanten Daten (Position des Pixels, Normalenvektoren, unbeleuchtete Farbe des Pixels (Albedo), Glanzstärke, etc.) auf Pixelbasis in mehrere Rendertargets (oftmals auch G-Buffer genannt) geschrieben. Nun muss für jede Lichtquelle lediglich die Lichtquellengeometrie gezeichnet werden und in diesem Schritt die Beleuchtung auf die zwischengespeicherten Daten angewendet werden. Die Zahl der Rendercalls liegt also bei ''no + nl''. Mit dieser Methode sind hunderte Lichter gleichzeitig in einer Szene möglich.<br />
<br />
== Vor-/Nachteile ==<br />
<br />
'''Vorteile:'''<br />
* Viele Lichtquellen möglich<br />
* Postprocessing Effekte (Bloom, Tonemapping, Depth of Field, etc.) können einfach angeschlossen werden, da bereits alle benötigten Informationen aufbereitet vorliegen.<br />
<br />
'''Nachteile:'''<br />
* Kein Hardware Anti-Aliasing möglich<br />
* Transparente Objekte müssen getrennt behandelt werden<br />
* Nur auf neueren Grafikkarten mit MRT (Mutliple Render Target) und Floating Point-Textur Support möglich (ab DirectX 9 kompatiblem Grafikchip; OpenGL Version ???)<br />
<br />
== Implementierung ==<br />
Zunächst müssen die Geometriedaten in den (G-Buffer) geschrieben werden. Hierzu benötigen wir drei 16-Bit Float Rendertarget Texturen. Niedrigere Bittiefen sind für Positionsbeschreibung und Normalenvektor zu wenig. Alle Rendertarget-Texturen müssen die gleiche Bittiefe haben. Sind mehrere Rendertargets aktiviert, so wird Hardware-Anti-Aliasing automatisch abgeschaltet. Die folgenden Beispiele sind mit Andorra 2D entwickelt und sollten recht einfach verständlich und nach OpenGL/DirectX umzusetzen sein.<br />
<br />
'''Schritt 1: Erstellen der Rendertargets'''<br />
<source lang="delphi"><br />
FRT_1_Albedo := TAdRenderTargetTexture.Create(FDraw);<br />
FRT_1_Albedo.BitDepth := adF64Bit;<br />
FRT_1_Albedo.SetSize(surfacew, surfaceh);<br />
FRT_1_Albedo.Filter := atPoint;<br />
<br />
FRT_2_Position := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
<br />
FRT_3_Normal := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
<br />
FRT_4_Composite := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
</source><br />
<br />
'''Schritt 2: Der G-Buffer-Fill Shader (HLSL/Cg)'''<br><br />
Der hier gezeigte Shader ist nur ein einfaches Beispiel. Unter anderem kann durch das geschickte Weglassen von Daten (Berechnen von X, Y aus den Z und den Screen-Coordinaten im Lighting-Shader) Bandbreite eingespart werden.<br />
<source lang="c"><br />
//Fragment Shader<br />
<br />
struct fs_res {<br />
float4 position: COLOR1;<br />
float4 normal: COLOR2;<br />
float4 albedo: COLOR0;<br />
};<br />
<br />
fs_res fs_std_geometry(<br />
float3 viewpos: TEXCOORD0,<br />
float3 normal: TEXCOORD1<br />
)<br />
{<br />
fs_res OUT; <br />
<br />
OUT.position = float4(viewpos, 1.0f); <br />
OUT.normal = float4(normal, 1.0f);<br />
OUT.albedo = float4(1.0f, 1.0f, 1.0f , 1.0f);<br />
<br />
return OUT;<br />
}<br />
<br />
//Vertex Shader<br />
<br />
struct vs_res {<br />
float4 pos: POSITION;<br />
float3 viewpos : TEXCOORD0; <br />
float3 normal: TEXCOORD1;<br />
};<br />
<br />
vs_res vs_std_geometry(<br />
float3 position : POSITION,<br />
float3 normal: NORMAL,<br />
uniform float4x4 modelview,<br />
uniform float4x4 modelviewproj<br />
)<br />
{<br />
vs_res OUT; <br />
<br />
OUT.pos = mul(float4(position, 1.0f), modelviewproj);<br />
OUT.viewpos = mul(float4(position, 1.0f), modelview);<br />
OUT.normal = normalize(mul(float4(normal, 0.0f), modelview));<br />
<br />
return OUT;<br />
}<br />
</source><br />
<br />
<br />
'''Schritt 3: Daten in G-Buffer Rendern'''<br />
<source lang="delphi"><br />
//Activate the G-Buffers<br />
FDraw.AdAppl.SetRenderTarget(0, FRT_1_Albedo.Texture);<br />
FDraw.AdAppl.SetRenderTarget(1, FRT_2_Position.Texture);<br />
FDraw.AdAppl.SetRenderTarget(2, FRT_3_Normal.Texture);<br />
<br />
FDraw.AdAppl.Viewport := AdRect(0, 0, surfacew, surfaceh);<br />
FDraw.AdAppl.ClearSurface(AdRect(0, 0, surfacew, surfaceh), [alColorBuffer, alZBuffer,<br />
alStencilBuffer], Ad_ARGB(0, 0, 0, 0), 1, 1);<br />
<br />
//Activate the shaders<br />
FTransformShader.FragmentShader.BindEffect;<br />
FTransformShader.VertexShader.BindEffect;<br />
<br />
FScene.Draw(FCamera, nil, 0);<br />
<br />
//Deactivate the shaders<br />
FTransformShader.VertexShader.UnbindEffect;<br />
FTransformShader.FragmentShader.UnbindEffect;<br />
<br />
FDraw.AdAppl.SetRenderTarget(2, nil);<br />
FDraw.AdAppl.SetRenderTarget(1, nil);<br />
FDraw.AdAppl.SetRenderTarget(0, nil);<br />
</source><br />
<br />
<br />
'''Schritt 4: Einfacher Direktionaler Licht-Shader'''<br><br />
Das zur Beleuchtung verwendete Quad liegt in diesem (einfachen) Fall bereits projeziert in normierten Koordinaten vor.<br />
<source lang="c"><br />
struct ps_light_res {<br />
float4 color: COLOR0;<br />
};<br />
<br />
ps_light_res ps_light_geometry(<br />
float3 screenpos: TEXCOORD0,<br />
float3 viewpos: TEXCOORD1,<br />
float3 lightdir: TEXCOORD2,<br />
<br />
uniform sampler sPosition,<br />
uniform sampler sNormal,<br />
uniform sampler sAlbedo,<br />
uniform float4 lightcolor<br />
)<br />
{<br />
ps_light_res OUT;<br />
<br />
float4 col = tex2D(sAlbedo, float2(screenpos.x, -screenpos.y));<br />
float4 normal = tex2D(sNormal, float2(screenpos.x, -screenpos.y));<br />
<br />
OUT.color = float4((lightcolor * col * clamp(dot(normal.xyz, lightdir), 0.0f, 1.0f)).rgb, 1.0f);<br />
<br />
return OUT;<br />
}<br />
<br />
struct vs_light_res {<br />
float4 pos: POSITION;<br />
float3 screenpos: TEXCOORD0;<br />
float3 viewpos: TEXCOORD1;<br />
float3 lightdir: TEXCOORD2;<br />
};<br />
<br />
vs_light_res vs_light_geometry(<br />
float3 position : POSITION,<br />
uniform float4x4 modelview,<br />
uniform float4x4 modelviewproj,<br />
uniform float3 lightdir<br />
)<br />
{<br />
vs_light_res OUT;<br />
<br />
OUT.pos = float4(position, 1.0f);<br />
OUT.screenpos = position * float3(0.5f, 0.5f, 0.0f) + float3(0.5f, 0.5f, 0.0f);//mul(pos, modelviewproj);<br />
OUT.viewpos = mul(position, modelview);<br />
OUT.lightdir = normalize(mul(float4(lightdir, 0.0f), modelview));<br />
<br />
return OUT;<br />
}<br />
</source><br />
<br />
<br />
'''Schritt 5: Lichtquellen in das Composite RT rendern'''<br />
<source lang="delphi"><br />
//Render a directional light using a quad<br />
FDraw.AdAppl.SetRenderTarget(0, FRT_4_Composite.Texture);<br />
FDraw.AdAppl.Viewport := AdRect(0, 0, surfacew, surfaceh);<br />
FDraw.AdAppl.ClearSurface(AdRect(0, 0, surfacew, surfaceh), [alColorBuffer, alZBuffer,<br />
alStencilBuffer], Ad_ARGB(255, 0, 0, 0), 1, 1); <br />
<br />
FLightShader.FragmentShader.SetParameter('sAlbedo', FRT_1_Albedo.Texture);<br />
FLightShader.FragmentShader.SetParameter('sPosition', FRT_2_Position.Texture);<br />
FLightShader.FragmentShader.SetParameter('sNormal', FRT_3_Normal.Texture);<br />
<br />
FLightShader.FragmentShader.BindEffect;<br />
FLightShader.VertexShader.BindEffect;<br />
<br />
//Render a blue light<br />
FLightShader.FragmentShader.SetParameter('lightcolor', Ad_ARGB(255, 50, 50, 100));<br />
FLightShader.VertexShader.SetParameter('lightdir', AcVector_Normalize(AcVector3(2.0, 2.0, -1.0)));<br />
FQuad.BlendMode = bmAdd;<br />
FQuad.Draw(nil);<br />
<br />
FLightShader.FragmentShader.UnbindEffect;<br />
FLightShader.VertexShader.UnbindEffect;<br />
</source><br />
<br />
<br />
'''Schritt 6: Das Ergebnis Zeichnen'''<br><br />
Nun muss nur noch das Ergebnis im "Composite"-RT gezeichnet werden - oder weitere Post-Processing Maßnahmen durchgeführt werden.<br />
<br />
==Weblinks==<br />
* http://www.gamedev.net/reference/programming/features/defRender/<br />
<br />
==Siehe auch==<br />
* [[Shader]]<br />
* [[Hintergrundwissen#Render-Pipeline|Render-Pipeline]]</div>Igel457https://wiki.delphigl.com/index.php?title=Deferred_Shading&diff=24765Deferred Shading2010-03-14T22:03:20Z<p>Igel457: </p>
<hr />
<div>= Deferred Shading =<br />
<br />
Der Befriff ''Deferred Shading'' (zu dt. "verzögertes Schattieren") oder auch ''Deferred Lighting'' ("verzögerte Beleuchtung") beschreibt eine Technik, mit deren Hilfe eine komplette Lichtquelle mit nur einem einzigen Draw-Call abgebildet werden kann.<br />
<br />
== Vorgehensweise ==<br />
Um eine Szene mit einem traditionellen Forward-Renderer zu beleuchten, wird normalerweise jedes Objekt der Szene mit den entsprechenden Beleuchtungsparametern der Lichtquelle gezeichnet. Die verschiedenen Ergebnisse werden durch additives Blenden akkumuliert. Für jede Lichtquelle ''nl'' muss also jedes Objekt ''no'' gezeichnet werden. Die Anzahl der Rendercalls liegt also bei ''no * nl''. Hierdurch sind nur wenige Lichtquellen gleichzeitig möglich.<br />
<br />
''Deferred Shading'' verfolgt einen anderen Ansatz: Anstatt jedes Objekt der Szene für jede Lichtquelle neu zu renderen, werden zunächst alle beleuchtungsrelevanten Daten (Position des Pixels, Normalenvektoren, unbeleuchtete Farbe des Pixels (Albedo), Glanzstärke, etc.) auf Pixelbasis in mehrere Rendertargets (oftmals auch G-Buffer genannt) geschrieben. Nun muss für jede Lichtquelle lediglich die Lichtquellengeometrie gezeichnet werden und in diesem Schritt die Beleuchtung auf die zwischengespeicherten Daten angewendet werden. Die Zahl der Rendercalls liegt also bei ''no + nl''. Mit dieser Methode sind hunderte Lichter gleichzeitig in einer Szene möglich.<br />
<br />
== Vor-/Nachteile ==<br />
<br />
'''Vorteile:'''<br />
* Viele Lichtquellen möglich<br />
* Postprocessing Effekte (Bloom, Tonemapping, Depth of Field) können einfach angeschlossen werden<br />
<br />
'''Nachteile:'''<br />
* Kein Hardware Anti-Alias möglich<br />
* Tranparente Objekte müssen getrennt behandelt werden<br />
* Nur auf neueren Grafikkarten mit MRT (Mutliple Render Target) und Floating Point-Textur Support möglich<br />
<br />
== Implementierung ==<br />
Zunächst müssen die Geometriedaten in den (G-Buffer) geschrieben werden. Hierzu benötigen wir drei 16-Bit Float Rendertarget Texturen. Niedrigere Bittiefen sind für Positionsbeschreibung und Normalenvektor zu wenig. Alle Rendertarget-Texturen müssen die gleiche Bittiefe haben. Sind mehrere Rendertargets aktiviert, so wird Hardware-Anti-Aliasing automatisch abgeschaltet. Die folgenden Beispiele sind mit Andorra 2D entwickelt und sollten recht einfach verständlich und nach OpenGL/DirectX umzusetzen sein.<br />
<br />
'''Schritt 1: Erstellen der Rendertargets'''<br />
<source lang="delphi"><br />
FRT_1_Albedo := TAdRenderTargetTexture.Create(FDraw);<br />
FRT_1_Albedo.BitDepth := adF64Bit;<br />
FRT_1_Albedo.SetSize(surfacew, surfaceh);<br />
FRT_1_Albedo.Filter := atPoint;<br />
<br />
FRT_2_Position := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
<br />
FRT_3_Normal := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
<br />
FRT_4_Composite := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
</source><br />
<br />
'''Schritt 2: Der G-Buffer-Fill Shader (HLSL/Cg)'''<br><br />
Der hier gezeigte Shader ist nur ein einfaches Beispiel. Unter anderem kann durch das geschickte Weglassen von Daten (Berechnen von X, Y aus den Z und den Screen-Coordinaten im Lighting-Shader) Bandbreite eingespart werden.<br />
<source lang="c"><br />
//Fragment Shader<br />
<br />
struct fs_res {<br />
float4 position: COLOR1;<br />
float4 normal: COLOR2;<br />
float4 albedo: COLOR0;<br />
};<br />
<br />
fs_res fs_std_geometry(<br />
float3 viewpos: TEXCOORD0,<br />
float3 normal: TEXCOORD1<br />
)<br />
{<br />
fs_res OUT; <br />
<br />
OUT.position = float4(viewpos, 1.0f); <br />
OUT.normal = float4(normal, 1.0f);<br />
OUT.albedo = float4(1.0f, 1.0f, 1.0f , 1.0f);<br />
<br />
return OUT;<br />
}<br />
<br />
//Vertex Shader<br />
<br />
struct vs_res {<br />
float4 pos: POSITION;<br />
float3 viewpos : TEXCOORD0; <br />
float3 normal: TEXCOORD1;<br />
};<br />
<br />
vs_res vs_std_geometry(<br />
float3 position : POSITION,<br />
float3 normal: NORMAL,<br />
uniform float4x4 modelview,<br />
uniform float4x4 modelviewproj<br />
)<br />
{<br />
vs_res OUT; <br />
<br />
OUT.pos = mul(float4(position, 1.0f), modelviewproj);<br />
OUT.viewpos = mul(float4(position, 1.0f), modelview);<br />
OUT.normal = normalize(mul(float4(normal, 0.0f), modelview));<br />
<br />
return OUT;<br />
}<br />
</source><br />
<br />
<br />
'''Schritt 3: Daten in G-Buffer Rendern'''<br />
<source lang="delphi"><br />
//Activate the G-Buffers<br />
FDraw.AdAppl.SetRenderTarget(0, FRT_1_Albedo.Texture);<br />
FDraw.AdAppl.SetRenderTarget(1, FRT_2_Position.Texture);<br />
FDraw.AdAppl.SetRenderTarget(2, FRT_3_Normal.Texture);<br />
<br />
FDraw.AdAppl.Viewport := AdRect(0, 0, surfacew, surfaceh);<br />
FDraw.AdAppl.ClearSurface(AdRect(0, 0, surfacew, surfaceh), [alColorBuffer, alZBuffer,<br />
alStencilBuffer], Ad_ARGB(0, 0, 0, 0), 1, 1);<br />
<br />
//Activate the shaders<br />
FTransformShader.FragmentShader.BindEffect;<br />
FTransformShader.VertexShader.BindEffect;<br />
<br />
FScene.Draw(FCamera, nil, 0);<br />
<br />
//Deactivate the shaders<br />
FTransformShader.VertexShader.UnbindEffect;<br />
FTransformShader.FragmentShader.UnbindEffect;<br />
<br />
FDraw.AdAppl.SetRenderTarget(2, nil);<br />
FDraw.AdAppl.SetRenderTarget(1, nil);<br />
FDraw.AdAppl.SetRenderTarget(0, nil);<br />
</source><br />
<br />
<br />
'''Schritt 4: Einfacher Direktionaler Licht-Shader'''<br><br />
Das zur Beleuchtung verwendete Quad liegt in diesem (einfachen) Fall bereits projeziert in normierten Koordinaten vor.<br />
<source lang="c"><br />
struct ps_light_res {<br />
float4 color: COLOR0;<br />
};<br />
<br />
ps_light_res ps_light_geometry(<br />
float3 screenpos: TEXCOORD0,<br />
float3 viewpos: TEXCOORD1,<br />
float3 lightdir: TEXCOORD2,<br />
<br />
uniform sampler sPosition,<br />
uniform sampler sNormal,<br />
uniform sampler sAlbedo,<br />
uniform float4 lightcolor<br />
)<br />
{<br />
ps_light_res OUT;<br />
<br />
float4 col = tex2D(sAlbedo, float2(screenpos.x, -screenpos.y));<br />
float4 normal = tex2D(sNormal, float2(screenpos.x, -screenpos.y));<br />
<br />
OUT.color = float4((lightcolor * col * clamp(dot(normal.xyz, lightdir), 0.0f, 1.0f)).rgb, 1.0f);<br />
<br />
return OUT;<br />
}<br />
<br />
struct vs_light_res {<br />
float4 pos: POSITION;<br />
float3 screenpos: TEXCOORD0;<br />
float3 viewpos: TEXCOORD1;<br />
float3 lightdir: TEXCOORD2;<br />
};<br />
<br />
vs_light_res vs_light_geometry(<br />
float3 position : POSITION,<br />
uniform float4x4 modelview,<br />
uniform float4x4 modelviewproj,<br />
uniform float3 lightdir<br />
)<br />
{<br />
vs_light_res OUT;<br />
<br />
OUT.pos = float4(position, 1.0f);<br />
OUT.screenpos = position * float3(0.5f, 0.5f, 0.0f) + float3(0.5f, 0.5f, 0.0f);//mul(pos, modelviewproj);<br />
OUT.viewpos = mul(position, modelview);<br />
OUT.lightdir = normalize(mul(float4(lightdir, 0.0f), modelview));<br />
<br />
return OUT;<br />
}<br />
</source><br />
<br />
<br />
'''Schritt 5: Lichtquellen in das Composite RT rendern'''<br />
<source lang="delphi"><br />
//Render a directional light using a quad<br />
FDraw.AdAppl.SetRenderTarget(0, FRT_4_Composite.Texture);<br />
FDraw.AdAppl.Viewport := AdRect(0, 0, surfacew, surfaceh);<br />
FDraw.AdAppl.ClearSurface(AdRect(0, 0, surfacew, surfaceh), [alColorBuffer, alZBuffer,<br />
alStencilBuffer], Ad_ARGB(255, 0, 0, 0), 1, 1); <br />
<br />
FLightShader.FragmentShader.SetParameter('sAlbedo', FRT_1_Albedo.Texture);<br />
FLightShader.FragmentShader.SetParameter('sPosition', FRT_2_Position.Texture);<br />
FLightShader.FragmentShader.SetParameter('sNormal', FRT_3_Normal.Texture);<br />
<br />
FLightShader.FragmentShader.BindEffect;<br />
FLightShader.VertexShader.BindEffect;<br />
<br />
//Render a blue light<br />
FLightShader.FragmentShader.SetParameter('lightcolor', Ad_ARGB(255, 50, 50, 100));<br />
FLightShader.VertexShader.SetParameter('lightdir', AcVector_Normalize(AcVector3(2.0, 2.0, -1.0)));<br />
FQuad.BlendMode = bmAdd;<br />
FQuad.Draw(nil);<br />
<br />
FLightShader.FragmentShader.UnbindEffect;<br />
FLightShader.VertexShader.UnbindEffect;<br />
</source><br />
<br />
<br />
'''Schritt 6: Das Ergebnis Zeichnen'''<br><br />
Nun muss nur noch das Ergebnis im "Composite"-RT gezeichnet werden - oder weitere Post-Processing Maßnahmen durchgeführt werden.<br />
<br />
==Weblinks==<br />
* http://www.gamedev.net/reference/programming/features/defRender/<br />
<br />
==Siehe auch==<br />
* [[Shader]]<br />
* [[Hintergrundwissen#Render-Pipeline|Render-Pipeline]]</div>Igel457https://wiki.delphigl.com/index.php?title=Deferred_Shading&diff=24764Deferred Shading2010-03-14T22:02:10Z<p>Igel457: /* Vorgehensweise */</p>
<hr />
<div>= Deferred Shading =<br />
<br />
Der Befriff ''Deferred Shading'' (zu dt. "verzögertes Schattieren") oder auch ''Deferred Lighting'' ("verzögerte Beleuchtung") beschreibt eine Technik, mit deren Hilfe eine komplette Lichtquelle mit nur einem einzigen Draw-Call abgebildet werden kann.<br />
<br />
== Vorgehensweise ==<br />
Um eine Szene mit einem traditionellen Forward-Renderer zu beleuchten, wird normalerweise jedes Objekt der Szene mit den entsprechenden Beleuchtungsparametern der Lichtquelle gezeichnet. Die verschiedenen Ergebnisse werden durch additives Blenden akkumuliert. Für jede Lichtquelle ''nl'' muss also jedes Objekt ''no'' gezeichnet werden. Die Anzahl der Rendercalls liegt also bei ''no * nl''. Hierdurch sind nur wenige Lichtquellen gleichzeitig möglich.<br />
<br />
''Deferred Shading'' verfolgt einen anderen Ansatz: Anstatt jedes Objekt der Szene für jede Lichtquelle neu zu renderen, werden zunächst alle beleuchtungsrelevanten Daten (Position des Pixels, Normalenvektoren, unbeleuchtete Farbe des Pixels (Albedo), Glanzstärke, etc.) auf Pixelbasis in mehrere Rendertargets (oftmals auch G-Buffer genannt) geschrieben. Nun muss für jede Lichtquelle lediglich die Lichtquellengeometrie gezeichnet werden und in diesem Schritt die Beleuchtung auf die zwischengespeicherten Daten angewendet werden. Die Zahl der Rendercalls liegt also bei ''no + nl''. Mit dieser Methode sind hunderte Lichter gleichzeitig in einer Szene möglich.<br />
<br />
== Vor-/Nachteile ==<br />
<br />
'''Vorteile:'''<br />
* Viele Lichtquellen möglich<br />
* Postprocessing Effekte (Bloom, Tonemapping, Depth of Field) können einfach angeschlossen werden<br />
<br />
'''Nachteile:'''<br />
* Kein Hardware Anti-Alias möglich<br />
* Tranparente Objekte müssen getrennt behandelt werden<br />
* Nur auf neueren Grafikkarten mit MRT (Mutliple Render Target) und Floating Point-Textur Support möglich<br />
<br />
== Implementierung ==<br />
Zunächst müssen die Geometriedaten in den (G-Buffer) geschrieben werden. Hierzu benötigen wir drei 16-Bit Float Rendertarget Texturen. Niedrigere Bittiefen sind für Positionsbeschreibung und Normalenvektor zu wenig. Alle Rendertarget-Texturen müssen die gleiche Bittiefe haben. Sind mehrere Rendertargets aktiviert, so wird Hardware-Anti-Aliasing automatisch abgeschaltet. Die folgenden Beispiele sind mit Andorra 2D entwickelt und sollten recht einfach verständlich und nach OpenGL/DirectX umzusetzen sein.<br />
<br />
'''Schritt 1: Erstellen der Rendertargets'''<br />
<pascal><br />
FRT_1_Albedo := TAdRenderTargetTexture.Create(FDraw);<br />
FRT_1_Albedo.BitDepth := adF64Bit;<br />
FRT_1_Albedo.SetSize(surfacew, surfaceh);<br />
FRT_1_Albedo.Filter := atPoint;<br />
<br />
FRT_2_Position := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
<br />
FRT_3_Normal := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
<br />
FRT_4_Composite := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
</pascal><br />
<br />
'''Schritt 2: Der G-Buffer-Fill Shader (HLSL/Cg)'''<br><br />
Der hier gezeigte Shader ist nur ein einfaches Beispiel. Unter anderem kann durch das geschickte Weglassen von Daten (Berechnen von X, Y aus den Z und den Screen-Coordinaten im Lighting-Shader) Bandbreite eingespart werden.<br />
<source lang="c"><br />
//Fragment Shader<br />
<br />
struct fs_res {<br />
float4 position: COLOR1;<br />
float4 normal: COLOR2;<br />
float4 albedo: COLOR0;<br />
};<br />
<br />
fs_res fs_std_geometry(<br />
float3 viewpos: TEXCOORD0,<br />
float3 normal: TEXCOORD1<br />
)<br />
{<br />
fs_res OUT; <br />
<br />
OUT.position = float4(viewpos, 1.0f); <br />
OUT.normal = float4(normal, 1.0f);<br />
OUT.albedo = float4(1.0f, 1.0f, 1.0f , 1.0f);<br />
<br />
return OUT;<br />
}<br />
<br />
//Vertex Shader<br />
<br />
struct vs_res {<br />
float4 pos: POSITION;<br />
float3 viewpos : TEXCOORD0; <br />
float3 normal: TEXCOORD1;<br />
};<br />
<br />
vs_res vs_std_geometry(<br />
float3 position : POSITION,<br />
float3 normal: NORMAL,<br />
uniform float4x4 modelview,<br />
uniform float4x4 modelviewproj<br />
)<br />
{<br />
vs_res OUT; <br />
<br />
OUT.pos = mul(float4(position, 1.0f), modelviewproj);<br />
OUT.viewpos = mul(float4(position, 1.0f), modelview);<br />
OUT.normal = normalize(mul(float4(normal, 0.0f), modelview));<br />
<br />
return OUT;<br />
}<br />
</source><br />
<br />
<br />
'''Schritt 3: Daten in G-Buffer Rendern'''<br />
<pascal><br />
//Activate the G-Buffers<br />
FDraw.AdAppl.SetRenderTarget(0, FRT_1_Albedo.Texture);<br />
FDraw.AdAppl.SetRenderTarget(1, FRT_2_Position.Texture);<br />
FDraw.AdAppl.SetRenderTarget(2, FRT_3_Normal.Texture);<br />
<br />
FDraw.AdAppl.Viewport := AdRect(0, 0, surfacew, surfaceh);<br />
FDraw.AdAppl.ClearSurface(AdRect(0, 0, surfacew, surfaceh), [alColorBuffer, alZBuffer,<br />
alStencilBuffer], Ad_ARGB(0, 0, 0, 0), 1, 1);<br />
<br />
//Activate the shaders<br />
FTransformShader.FragmentShader.BindEffect;<br />
FTransformShader.VertexShader.BindEffect;<br />
<br />
FScene.Draw(FCamera, nil, 0);<br />
<br />
//Deactivate the shaders<br />
FTransformShader.VertexShader.UnbindEffect;<br />
FTransformShader.FragmentShader.UnbindEffect;<br />
<br />
FDraw.AdAppl.SetRenderTarget(2, nil);<br />
FDraw.AdAppl.SetRenderTarget(1, nil);<br />
FDraw.AdAppl.SetRenderTarget(0, nil);<br />
</pascal><br />
<br />
<br />
'''Schritt 4: Einfacher Direktionaler Licht-Shader'''<br><br />
Das zur Beleuchtung verwendete Quad liegt in diesem (einfachen) Fall bereits projeziert in normierten Koordinaten vor.<br />
<source lang="c"><br />
struct ps_light_res {<br />
float4 color: COLOR0;<br />
};<br />
<br />
ps_light_res ps_light_geometry(<br />
float3 screenpos: TEXCOORD0,<br />
float3 viewpos: TEXCOORD1,<br />
float3 lightdir: TEXCOORD2,<br />
<br />
uniform sampler sPosition,<br />
uniform sampler sNormal,<br />
uniform sampler sAlbedo,<br />
uniform float4 lightcolor<br />
)<br />
{<br />
ps_light_res OUT;<br />
<br />
float4 col = tex2D(sAlbedo, float2(screenpos.x, -screenpos.y));<br />
float4 normal = tex2D(sNormal, float2(screenpos.x, -screenpos.y));<br />
<br />
OUT.color = float4((lightcolor * col * clamp(dot(normal.xyz, lightdir), 0.0f, 1.0f)).rgb, 1.0f);<br />
<br />
return OUT;<br />
}<br />
<br />
struct vs_light_res {<br />
float4 pos: POSITION;<br />
float3 screenpos: TEXCOORD0;<br />
float3 viewpos: TEXCOORD1;<br />
float3 lightdir: TEXCOORD2;<br />
};<br />
<br />
vs_light_res vs_light_geometry(<br />
float3 position : POSITION,<br />
uniform float4x4 modelview,<br />
uniform float4x4 modelviewproj,<br />
uniform float3 lightdir<br />
)<br />
{<br />
vs_light_res OUT;<br />
<br />
OUT.pos = float4(position, 1.0f);<br />
OUT.screenpos = position * float3(0.5f, 0.5f, 0.0f) + float3(0.5f, 0.5f, 0.0f);//mul(pos, modelviewproj);<br />
OUT.viewpos = mul(position, modelview);<br />
OUT.lightdir = normalize(mul(float4(lightdir, 0.0f), modelview));<br />
<br />
return OUT;<br />
}<br />
</source><br />
<br />
<br />
'''Schritt 5: Lichtquellen in das Composite RT rendern'''<br />
<pascal><br />
//Render a directional light using a quad<br />
FDraw.AdAppl.SetRenderTarget(0, FRT_4_Composite.Texture);<br />
FDraw.AdAppl.Viewport := AdRect(0, 0, surfacew, surfaceh);<br />
FDraw.AdAppl.ClearSurface(AdRect(0, 0, surfacew, surfaceh), [alColorBuffer, alZBuffer,<br />
alStencilBuffer], Ad_ARGB(255, 0, 0, 0), 1, 1); <br />
<br />
FLightShader.FragmentShader.SetParameter('sAlbedo', FRT_1_Albedo.Texture);<br />
FLightShader.FragmentShader.SetParameter('sPosition', FRT_2_Position.Texture);<br />
FLightShader.FragmentShader.SetParameter('sNormal', FRT_3_Normal.Texture);<br />
<br />
FLightShader.FragmentShader.BindEffect;<br />
FLightShader.VertexShader.BindEffect;<br />
<br />
//Render a blue light<br />
FLightShader.FragmentShader.SetParameter('lightcolor', Ad_ARGB(255, 50, 50, 100));<br />
FLightShader.VertexShader.SetParameter('lightdir', AcVector_Normalize(AcVector3(2.0, 2.0, -1.0)));<br />
FQuad.BlendMode = bmAdd;<br />
FQuad.Draw(nil);<br />
<br />
FLightShader.FragmentShader.UnbindEffect;<br />
FLightShader.VertexShader.UnbindEffect;<br />
</pascal><br />
<br />
<br />
'''Schritt 6: Das Ergebnis Zeichnen'''<br><br />
Nun muss nur noch das Ergebnis im "Composite"-RT gezeichnet werden - oder weitere Post-Processing Maßnahmen durchgeführt werden.<br />
<br />
==Weblinks==<br />
* http://www.gamedev.net/reference/programming/features/defRender/<br />
<br />
==Siehe auch==<br />
* [[Shader]]<br />
* [[Hintergrundwissen#Render-Pipeline|Render-Pipeline]]</div>Igel457https://wiki.delphigl.com/index.php?title=Deferred_Shading&diff=24763Deferred Shading2010-03-14T21:56:43Z<p>Igel457: /* Implementierung */</p>
<hr />
<div>= Deferred Shading =<br />
<br />
Der Befriff ''Deferred Shading'' (zu dt. "verzögertes Schattieren") oder auch ''Deferred Lighting'' ("verzögerte Beleuchtung") beschreibt eine Technik, mit deren Hilfe eine komplette Lichtquelle mit nur einem einzigen Draw-Call abgebildet werden kann.<br />
<br />
== Vorgehensweise ==<br />
Um eine Szene mit einem traditionellen Forward-Renderer zu beleuchten, wird normalerweise jedes Objekt der Szene mit den entsprechenden Beleuchtungsparametern der Lichtquelle gezeichnet. Die verschiedenen Ergebnisse werden durch additives Blenden akkumuliert. Für jede Lichtquelle ''nl'' muss also jedes Objekt ''no'' gezeichnet werden. Die Anzahl der Rendercalls liegt also bei ''no * nl''. Hierdurch sind nur wenige Lichtquellen gleichzeitig möglich.<br />
<br />
''Deferred Shading'' verfolgt einen anderen Ansatz: Anstatt jedes Objekt der Szene für jede Lichtquelle neu zu renderen, werden zunächst alle beleuchtungsrelevanten Daten (Position des Pixels, Normalenvektoren, unbeleuchtete Farbe des Pixels (Albedo), Glanzstärke, etc.) auf Pixelbasis in mehrere Rendertargets (oftmals auch G-Buffer genannt) geschrieben. Nun muss für jede Lichtquelle lediglich die Lichtquellengeometrie gezeichnet werden und in diesem Schritt die Beleuchtung auf die zwischengespeicherten Daten angewendet werden. Die Zahl der Rendercalls liegt also bei ''no + nl''. Mit dieser Methode sind hunderte Objekte gleichzeitig in einer Szene möglich.<br />
<br />
== Vor-/Nachteile ==<br />
<br />
'''Vorteile:'''<br />
* Viele Lichtquellen möglich<br />
* Postprocessing Effekte (Bloom, Tonemapping, Depth of Field) können einfach angeschlossen werden<br />
<br />
'''Nachteile:'''<br />
* Kein Hardware Anti-Alias möglich<br />
* Tranparente Objekte müssen getrennt behandelt werden<br />
* Nur auf neueren Grafikkarten mit MRT (Mutliple Render Target) und Floating Point-Textur Support möglich<br />
<br />
== Implementierung ==<br />
Zunächst müssen die Geometriedaten in den (G-Buffer) geschrieben werden. Hierzu benötigen wir drei 16-Bit Float Rendertarget Texturen. Niedrigere Bittiefen sind für Positionsbeschreibung und Normalenvektor zu wenig. Alle Rendertarget-Texturen müssen die gleiche Bittiefe haben. Sind mehrere Rendertargets aktiviert, so wird Hardware-Anti-Aliasing automatisch abgeschaltet. Die folgenden Beispiele sind mit Andorra 2D entwickelt und sollten recht einfach verständlich und nach OpenGL/DirectX umzusetzen sein.<br />
<br />
'''Schritt 1: Erstellen der Rendertargets'''<br />
<pascal><br />
FRT_1_Albedo := TAdRenderTargetTexture.Create(FDraw);<br />
FRT_1_Albedo.BitDepth := adF64Bit;<br />
FRT_1_Albedo.SetSize(surfacew, surfaceh);<br />
FRT_1_Albedo.Filter := atPoint;<br />
<br />
FRT_2_Position := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
<br />
FRT_3_Normal := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
<br />
FRT_4_Composite := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
</pascal><br />
<br />
'''Schritt 2: Der G-Buffer-Fill Shader (HLSL/Cg)'''<br><br />
Der hier gezeigte Shader ist nur ein einfaches Beispiel. Unter anderem kann durch das geschickte Weglassen von Daten (Berechnen von X, Y aus den Z und den Screen-Coordinaten im Lighting-Shader) Bandbreite eingespart werden.<br />
<source lang="c"><br />
//Fragment Shader<br />
<br />
struct fs_res {<br />
float4 position: COLOR1;<br />
float4 normal: COLOR2;<br />
float4 albedo: COLOR0;<br />
};<br />
<br />
fs_res fs_std_geometry(<br />
float3 viewpos: TEXCOORD0,<br />
float3 normal: TEXCOORD1<br />
)<br />
{<br />
fs_res OUT; <br />
<br />
OUT.position = float4(viewpos, 1.0f); <br />
OUT.normal = float4(normal, 1.0f);<br />
OUT.albedo = float4(1.0f, 1.0f, 1.0f , 1.0f);<br />
<br />
return OUT;<br />
}<br />
<br />
//Vertex Shader<br />
<br />
struct vs_res {<br />
float4 pos: POSITION;<br />
float3 viewpos : TEXCOORD0; <br />
float3 normal: TEXCOORD1;<br />
};<br />
<br />
vs_res vs_std_geometry(<br />
float3 position : POSITION,<br />
float3 normal: NORMAL,<br />
uniform float4x4 modelview,<br />
uniform float4x4 modelviewproj<br />
)<br />
{<br />
vs_res OUT; <br />
<br />
OUT.pos = mul(float4(position, 1.0f), modelviewproj);<br />
OUT.viewpos = mul(float4(position, 1.0f), modelview);<br />
OUT.normal = normalize(mul(float4(normal, 0.0f), modelview));<br />
<br />
return OUT;<br />
}<br />
</source><br />
<br />
<br />
'''Schritt 3: Daten in G-Buffer Rendern'''<br />
<pascal><br />
//Activate the G-Buffers<br />
FDraw.AdAppl.SetRenderTarget(0, FRT_1_Albedo.Texture);<br />
FDraw.AdAppl.SetRenderTarget(1, FRT_2_Position.Texture);<br />
FDraw.AdAppl.SetRenderTarget(2, FRT_3_Normal.Texture);<br />
<br />
FDraw.AdAppl.Viewport := AdRect(0, 0, surfacew, surfaceh);<br />
FDraw.AdAppl.ClearSurface(AdRect(0, 0, surfacew, surfaceh), [alColorBuffer, alZBuffer,<br />
alStencilBuffer], Ad_ARGB(0, 0, 0, 0), 1, 1);<br />
<br />
//Activate the shaders<br />
FTransformShader.FragmentShader.BindEffect;<br />
FTransformShader.VertexShader.BindEffect;<br />
<br />
FScene.Draw(FCamera, nil, 0);<br />
<br />
//Deactivate the shaders<br />
FTransformShader.VertexShader.UnbindEffect;<br />
FTransformShader.FragmentShader.UnbindEffect;<br />
<br />
FDraw.AdAppl.SetRenderTarget(2, nil);<br />
FDraw.AdAppl.SetRenderTarget(1, nil);<br />
FDraw.AdAppl.SetRenderTarget(0, nil);<br />
</pascal><br />
<br />
<br />
'''Schritt 4: Einfacher Direktionaler Licht-Shader'''<br><br />
Das zur Beleuchtung verwendete Quad liegt in diesem (einfachen) Fall bereits projeziert in normierten Koordinaten vor.<br />
<source lang="c"><br />
struct ps_light_res {<br />
float4 color: COLOR0;<br />
};<br />
<br />
ps_light_res ps_light_geometry(<br />
float3 screenpos: TEXCOORD0,<br />
float3 viewpos: TEXCOORD1,<br />
float3 lightdir: TEXCOORD2,<br />
<br />
uniform sampler sPosition,<br />
uniform sampler sNormal,<br />
uniform sampler sAlbedo,<br />
uniform float4 lightcolor<br />
)<br />
{<br />
ps_light_res OUT;<br />
<br />
float4 col = tex2D(sAlbedo, float2(screenpos.x, -screenpos.y));<br />
float4 normal = tex2D(sNormal, float2(screenpos.x, -screenpos.y));<br />
<br />
OUT.color = float4((lightcolor * col * clamp(dot(normal.xyz, lightdir), 0.0f, 1.0f)).rgb, 1.0f);<br />
<br />
return OUT;<br />
}<br />
<br />
struct vs_light_res {<br />
float4 pos: POSITION;<br />
float3 screenpos: TEXCOORD0;<br />
float3 viewpos: TEXCOORD1;<br />
float3 lightdir: TEXCOORD2;<br />
};<br />
<br />
vs_light_res vs_light_geometry(<br />
float3 position : POSITION,<br />
uniform float4x4 modelview,<br />
uniform float4x4 modelviewproj,<br />
uniform float3 lightdir<br />
)<br />
{<br />
vs_light_res OUT;<br />
<br />
OUT.pos = float4(position, 1.0f);<br />
OUT.screenpos = position * float3(0.5f, 0.5f, 0.0f) + float3(0.5f, 0.5f, 0.0f);//mul(pos, modelviewproj);<br />
OUT.viewpos = mul(position, modelview);<br />
OUT.lightdir = normalize(mul(float4(lightdir, 0.0f), modelview));<br />
<br />
return OUT;<br />
}<br />
</source><br />
<br />
<br />
'''Schritt 5: Lichtquellen in das Composite RT rendern'''<br />
<pascal><br />
//Render a directional light using a quad<br />
FDraw.AdAppl.SetRenderTarget(0, FRT_4_Composite.Texture);<br />
FDraw.AdAppl.Viewport := AdRect(0, 0, surfacew, surfaceh);<br />
FDraw.AdAppl.ClearSurface(AdRect(0, 0, surfacew, surfaceh), [alColorBuffer, alZBuffer,<br />
alStencilBuffer], Ad_ARGB(255, 0, 0, 0), 1, 1); <br />
<br />
FLightShader.FragmentShader.SetParameter('sAlbedo', FRT_1_Albedo.Texture);<br />
FLightShader.FragmentShader.SetParameter('sPosition', FRT_2_Position.Texture);<br />
FLightShader.FragmentShader.SetParameter('sNormal', FRT_3_Normal.Texture);<br />
<br />
FLightShader.FragmentShader.BindEffect;<br />
FLightShader.VertexShader.BindEffect;<br />
<br />
//Render a blue light<br />
FLightShader.FragmentShader.SetParameter('lightcolor', Ad_ARGB(255, 50, 50, 100));<br />
FLightShader.VertexShader.SetParameter('lightdir', AcVector_Normalize(AcVector3(2.0, 2.0, -1.0)));<br />
FQuad.BlendMode = bmAdd;<br />
FQuad.Draw(nil);<br />
<br />
FLightShader.FragmentShader.UnbindEffect;<br />
FLightShader.VertexShader.UnbindEffect;<br />
</pascal><br />
<br />
<br />
'''Schritt 6: Das Ergebnis Zeichnen'''<br><br />
Nun muss nur noch das Ergebnis im "Composite"-RT gezeichnet werden - oder weitere Post-Processing Maßnahmen durchgeführt werden.<br />
<br />
==Weblinks==<br />
* http://www.gamedev.net/reference/programming/features/defRender/<br />
<br />
==Siehe auch==<br />
* [[Shader]]<br />
* [[Hintergrundwissen#Render-Pipeline|Render-Pipeline]]</div>Igel457https://wiki.delphigl.com/index.php?title=Deferred_Shading&diff=24762Deferred Shading2010-03-14T21:55:13Z<p>Igel457: /* Siehe auch */</p>
<hr />
<div>= Deferred Shading =<br />
<br />
Der Befriff ''Deferred Shading'' (zu dt. "verzögertes Schattieren") oder auch ''Deferred Lighting'' ("verzögerte Beleuchtung") beschreibt eine Technik, mit deren Hilfe eine komplette Lichtquelle mit nur einem einzigen Draw-Call abgebildet werden kann.<br />
<br />
== Vorgehensweise ==<br />
Um eine Szene mit einem traditionellen Forward-Renderer zu beleuchten, wird normalerweise jedes Objekt der Szene mit den entsprechenden Beleuchtungsparametern der Lichtquelle gezeichnet. Die verschiedenen Ergebnisse werden durch additives Blenden akkumuliert. Für jede Lichtquelle ''nl'' muss also jedes Objekt ''no'' gezeichnet werden. Die Anzahl der Rendercalls liegt also bei ''no * nl''. Hierdurch sind nur wenige Lichtquellen gleichzeitig möglich.<br />
<br />
''Deferred Shading'' verfolgt einen anderen Ansatz: Anstatt jedes Objekt der Szene für jede Lichtquelle neu zu renderen, werden zunächst alle beleuchtungsrelevanten Daten (Position des Pixels, Normalenvektoren, unbeleuchtete Farbe des Pixels (Albedo), Glanzstärke, etc.) auf Pixelbasis in mehrere Rendertargets (oftmals auch G-Buffer genannt) geschrieben. Nun muss für jede Lichtquelle lediglich die Lichtquellengeometrie gezeichnet werden und in diesem Schritt die Beleuchtung auf die zwischengespeicherten Daten angewendet werden. Die Zahl der Rendercalls liegt also bei ''no + nl''. Mit dieser Methode sind hunderte Objekte gleichzeitig in einer Szene möglich.<br />
<br />
== Vor-/Nachteile ==<br />
<br />
'''Vorteile:'''<br />
* Viele Lichtquellen möglich<br />
* Postprocessing Effekte (Bloom, Tonemapping, Depth of Field) können einfach angeschlossen werden<br />
<br />
'''Nachteile:'''<br />
* Kein Hardware Anti-Alias möglich<br />
* Tranparente Objekte müssen getrennt behandelt werden<br />
* Nur auf neueren Grafikkarten mit MRT (Mutliple Render Target) und Floating Point-Textur Support möglich<br />
<br />
== Implementierung ==<br />
Zunächst müssen die Geometriedaten in den (G-Buffer) geschrieben werden. Hierzu benötigen wir drei 16-Bit Float Rendertarget Texturen. Niedrigere Bittiefen sind für Positionsbeschreibung und Normalenvektor zu wenig. Alle Rendertarget-Texturen müssen die gleiche Bittiefe haben. Sind mehrere Rendertargets aktiviert, so wird Hardware-Anti-Aliasing automatisch abgeschaltet. Die folgenden Beispiele sind mit Andorra 2D entwickelt und sollten recht einfach verständlich und nach OpenGL/DirectX umzusetzen sein.<br />
<br />
'''Schritt 1: Erstellen der Rendertargets'''<br />
<pascal><br />
FRT_1_Albedo := TAdRenderTargetTexture.Create(FDraw);<br />
FRT_1_Albedo.BitDepth := adF64Bit;<br />
FRT_1_Albedo.SetSize(surfacew, surfaceh);<br />
FRT_1_Albedo.Filter := atPoint;<br />
<br />
FRT_2_Position := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
<br />
FRT_3_Normal := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
<br />
FRT_4_Composite := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
</pascal><br />
<br />
'''Schritt 2: Der G-Buffer-Fill Shader (HLSL/Cg)'''<br><br />
Der hier gezeigte Shader ist nur ein einfaches Beispiel. Unter anderem kann durch das geschickte Weglassen von Daten (Berechnen von X, Y aus den Z und den Screen-Coordinaten im Lighting-Shader) Bandbreite eingespart werden.<br />
<source lang="c"><br />
//Fragment Shader<br />
<br />
struct fs_res {<br />
float4 position: COLOR1;<br />
float4 normal: COLOR2;<br />
float4 albedo: COLOR0;<br />
};<br />
<br />
fs_res fs_std_geometry(<br />
float3 viewpos: TEXCOORD0,<br />
float3 normal: TEXCOORD1<br />
)<br />
{<br />
fs_res OUT; <br />
<br />
OUT.position = float4(viewpos, 1.0f); <br />
OUT.normal = float4(normal, 1.0f);<br />
OUT.albedo = float4(1.0f, 1.0f, 1.0f , 1.0f);<br />
<br />
return OUT;<br />
}<br />
<br />
//Vertex Shader<br />
<br />
struct vs_res {<br />
float4 pos: POSITION;<br />
float3 viewpos : TEXCOORD0; <br />
float3 normal: TEXCOORD1;<br />
};<br />
<br />
vs_res vs_std_geometry(<br />
float3 position : POSITION,<br />
float3 normal: NORMAL,<br />
uniform float4x4 modelview,<br />
uniform float4x4 modelviewproj<br />
)<br />
{<br />
vs_res OUT; <br />
<br />
OUT.pos = mul(float4(position, 1.0f), modelviewproj);<br />
OUT.viewpos = mul(float4(position, 1.0f), modelview);<br />
OUT.normal = normalize(mul(float4(normal, 0.0f), modelview));<br />
<br />
return OUT;<br />
}<br />
</source><br />
<br />
<br />
'''Schritt 3: Daten in G-Buffer Rendern'''<br />
<pascal><br />
//<br />
//---- G-Buffer fill pass ----<br />
//<br />
<br />
//Activate the G-Buffers<br />
FDraw.AdAppl.SetRenderTarget(0, FRT_1_Albedo.Texture);<br />
FDraw.AdAppl.SetRenderTarget(1, FRT_2_Position.Texture);<br />
FDraw.AdAppl.SetRenderTarget(2, FRT_3_Normal.Texture);<br />
<br />
FDraw.AdAppl.Viewport := AdRect(0, 0, surfacew, surfaceh);<br />
FDraw.AdAppl.ClearSurface(AdRect(0, 0, surfacew, surfaceh), [alColorBuffer, alZBuffer,<br />
alStencilBuffer], Ad_ARGB(0, 0, 0, 0), 1, 1);<br />
<br />
//Activate the shaders<br />
FTransformShader.FragmentShader.BindEffect;<br />
FTransformShader.VertexShader.BindEffect;<br />
<br />
FScene.Draw(FCamera, nil, 0);<br />
<br />
//Deactivate the shaders<br />
FTransformShader.VertexShader.UnbindEffect;<br />
FTransformShader.FragmentShader.UnbindEffect;<br />
<br />
FDraw.AdAppl.SetRenderTarget(2, nil);<br />
FDraw.AdAppl.SetRenderTarget(1, nil);<br />
FDraw.AdAppl.SetRenderTarget(0, nil);<br />
</pascal><br />
<br />
<br />
'''Schritt 4: Einfacher Direktionaler Licht-Shader'''<br><br />
Das zur Beleuchtung verwendete Quad liegt in diesem (einfachen) Fall bereits projeziert in normierten Koordinaten vor.<br />
<source lang="c"><br />
struct ps_light_res {<br />
float4 color: COLOR0;<br />
};<br />
<br />
ps_light_res ps_light_geometry(<br />
float3 screenpos: TEXCOORD0,<br />
float3 viewpos: TEXCOORD1,<br />
float3 lightdir: TEXCOORD2,<br />
<br />
uniform sampler sPosition,<br />
uniform sampler sNormal,<br />
uniform sampler sAlbedo,<br />
uniform float4 lightcolor<br />
)<br />
{<br />
ps_light_res OUT;<br />
<br />
float4 col = tex2D(sAlbedo, float2(screenpos.x, -screenpos.y));<br />
float4 normal = tex2D(sNormal, float2(screenpos.x, -screenpos.y));<br />
<br />
OUT.color = float4((lightcolor * col * clamp(dot(normal.xyz, lightdir), 0.0f, 1.0f)).rgb, 1.0f);<br />
<br />
//OUT.color = float4(0.0f, 0.0f, 1.0f, 1.0f);<br />
<br />
//OUT.color = col;<br />
<br />
return OUT;<br />
}<br />
<br />
struct vs_light_res {<br />
float4 pos: POSITION;<br />
float3 screenpos: TEXCOORD0;<br />
float3 viewpos: TEXCOORD1;<br />
float3 lightdir: TEXCOORD2;<br />
};<br />
<br />
vs_light_res vs_light_geometry(<br />
float3 position : POSITION,<br />
uniform float4x4 modelview,<br />
uniform float4x4 modelviewproj,<br />
uniform float3 lightdir<br />
)<br />
{<br />
vs_light_res OUT;<br />
<br />
OUT.pos = float4(position, 1.0f);<br />
OUT.screenpos = position * float3(0.5f, 0.5f, 0.0f) + float3(0.5f, 0.5f, 0.0f);//mul(pos, modelviewproj);<br />
OUT.viewpos = mul(position, modelview);<br />
OUT.lightdir = normalize(mul(float4(lightdir, 0.0f), modelview));<br />
<br />
return OUT;<br />
}<br />
</source><br />
<br />
<br />
'''Schritt 5: Lichtquellen in das Composite RT rendern'''<br />
<pascal><br />
//Render a directional light using a quad<br />
FDraw.AdAppl.SetRenderTarget(0, FRT_4_Composite.Texture);<br />
FDraw.AdAppl.Viewport := AdRect(0, 0, surfacew, surfaceh);<br />
FDraw.AdAppl.ClearSurface(AdRect(0, 0, surfacew, surfaceh), [alColorBuffer, alZBuffer,<br />
alStencilBuffer], Ad_ARGB(255, 0, 0, 0), 1, 1); <br />
<br />
FLightShader.FragmentShader.SetParameter('sAlbedo', FRT_1_Albedo.Texture);<br />
FLightShader.FragmentShader.SetParameter('sPosition', FRT_2_Position.Texture);<br />
FLightShader.FragmentShader.SetParameter('sNormal', FRT_3_Normal.Texture);<br />
<br />
FLightShader.FragmentShader.BindEffect;<br />
FLightShader.VertexShader.BindEffect;<br />
<br />
//Render a blue light<br />
FLightShader.FragmentShader.SetParameter('lightcolor', Ad_ARGB(255, 50, 50, 100));<br />
FLightShader.VertexShader.SetParameter('lightdir', AcVector_Normalize(AcVector3(2.0, 2.0, -1.0)));<br />
FQuad.BlendMode = bmAdd;<br />
FQuad.Draw(nil);<br />
<br />
FLightShader.FragmentShader.UnbindEffect;<br />
FLightShader.VertexShader.UnbindEffect;<br />
</pascal><br />
<br />
<br />
'''Schritt 6: Das Ergebnis Zeichnen'''<br><br />
Nun muss nur noch das Ergebnis im "Composite"-RT gezeichnet werden - oder weitere Post-Processing Maßnahmen durchgeführt werden.<br />
<br />
==Weblinks==<br />
* http://www.gamedev.net/reference/programming/features/defRender/<br />
<br />
==Siehe auch==<br />
* [[Shader]]<br />
* [[Hintergrundwissen#Render-Pipeline|Render-Pipeline]]</div>Igel457https://wiki.delphigl.com/index.php?title=Deferred_Shading&diff=24761Deferred Shading2010-03-14T21:54:56Z<p>Igel457: /* Siehe auch */</p>
<hr />
<div>= Deferred Shading =<br />
<br />
Der Befriff ''Deferred Shading'' (zu dt. "verzögertes Schattieren") oder auch ''Deferred Lighting'' ("verzögerte Beleuchtung") beschreibt eine Technik, mit deren Hilfe eine komplette Lichtquelle mit nur einem einzigen Draw-Call abgebildet werden kann.<br />
<br />
== Vorgehensweise ==<br />
Um eine Szene mit einem traditionellen Forward-Renderer zu beleuchten, wird normalerweise jedes Objekt der Szene mit den entsprechenden Beleuchtungsparametern der Lichtquelle gezeichnet. Die verschiedenen Ergebnisse werden durch additives Blenden akkumuliert. Für jede Lichtquelle ''nl'' muss also jedes Objekt ''no'' gezeichnet werden. Die Anzahl der Rendercalls liegt also bei ''no * nl''. Hierdurch sind nur wenige Lichtquellen gleichzeitig möglich.<br />
<br />
''Deferred Shading'' verfolgt einen anderen Ansatz: Anstatt jedes Objekt der Szene für jede Lichtquelle neu zu renderen, werden zunächst alle beleuchtungsrelevanten Daten (Position des Pixels, Normalenvektoren, unbeleuchtete Farbe des Pixels (Albedo), Glanzstärke, etc.) auf Pixelbasis in mehrere Rendertargets (oftmals auch G-Buffer genannt) geschrieben. Nun muss für jede Lichtquelle lediglich die Lichtquellengeometrie gezeichnet werden und in diesem Schritt die Beleuchtung auf die zwischengespeicherten Daten angewendet werden. Die Zahl der Rendercalls liegt also bei ''no + nl''. Mit dieser Methode sind hunderte Objekte gleichzeitig in einer Szene möglich.<br />
<br />
== Vor-/Nachteile ==<br />
<br />
'''Vorteile:'''<br />
* Viele Lichtquellen möglich<br />
* Postprocessing Effekte (Bloom, Tonemapping, Depth of Field) können einfach angeschlossen werden<br />
<br />
'''Nachteile:'''<br />
* Kein Hardware Anti-Alias möglich<br />
* Tranparente Objekte müssen getrennt behandelt werden<br />
* Nur auf neueren Grafikkarten mit MRT (Mutliple Render Target) und Floating Point-Textur Support möglich<br />
<br />
== Implementierung ==<br />
Zunächst müssen die Geometriedaten in den (G-Buffer) geschrieben werden. Hierzu benötigen wir drei 16-Bit Float Rendertarget Texturen. Niedrigere Bittiefen sind für Positionsbeschreibung und Normalenvektor zu wenig. Alle Rendertarget-Texturen müssen die gleiche Bittiefe haben. Sind mehrere Rendertargets aktiviert, so wird Hardware-Anti-Aliasing automatisch abgeschaltet. Die folgenden Beispiele sind mit Andorra 2D entwickelt und sollten recht einfach verständlich und nach OpenGL/DirectX umzusetzen sein.<br />
<br />
'''Schritt 1: Erstellen der Rendertargets'''<br />
<pascal><br />
FRT_1_Albedo := TAdRenderTargetTexture.Create(FDraw);<br />
FRT_1_Albedo.BitDepth := adF64Bit;<br />
FRT_1_Albedo.SetSize(surfacew, surfaceh);<br />
FRT_1_Albedo.Filter := atPoint;<br />
<br />
FRT_2_Position := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
<br />
FRT_3_Normal := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
<br />
FRT_4_Composite := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
</pascal><br />
<br />
'''Schritt 2: Der G-Buffer-Fill Shader (HLSL/Cg)'''<br><br />
Der hier gezeigte Shader ist nur ein einfaches Beispiel. Unter anderem kann durch das geschickte Weglassen von Daten (Berechnen von X, Y aus den Z und den Screen-Coordinaten im Lighting-Shader) Bandbreite eingespart werden.<br />
<source lang="c"><br />
//Fragment Shader<br />
<br />
struct fs_res {<br />
float4 position: COLOR1;<br />
float4 normal: COLOR2;<br />
float4 albedo: COLOR0;<br />
};<br />
<br />
fs_res fs_std_geometry(<br />
float3 viewpos: TEXCOORD0,<br />
float3 normal: TEXCOORD1<br />
)<br />
{<br />
fs_res OUT; <br />
<br />
OUT.position = float4(viewpos, 1.0f); <br />
OUT.normal = float4(normal, 1.0f);<br />
OUT.albedo = float4(1.0f, 1.0f, 1.0f , 1.0f);<br />
<br />
return OUT;<br />
}<br />
<br />
//Vertex Shader<br />
<br />
struct vs_res {<br />
float4 pos: POSITION;<br />
float3 viewpos : TEXCOORD0; <br />
float3 normal: TEXCOORD1;<br />
};<br />
<br />
vs_res vs_std_geometry(<br />
float3 position : POSITION,<br />
float3 normal: NORMAL,<br />
uniform float4x4 modelview,<br />
uniform float4x4 modelviewproj<br />
)<br />
{<br />
vs_res OUT; <br />
<br />
OUT.pos = mul(float4(position, 1.0f), modelviewproj);<br />
OUT.viewpos = mul(float4(position, 1.0f), modelview);<br />
OUT.normal = normalize(mul(float4(normal, 0.0f), modelview));<br />
<br />
return OUT;<br />
}<br />
</source><br />
<br />
<br />
'''Schritt 3: Daten in G-Buffer Rendern'''<br />
<pascal><br />
//<br />
//---- G-Buffer fill pass ----<br />
//<br />
<br />
//Activate the G-Buffers<br />
FDraw.AdAppl.SetRenderTarget(0, FRT_1_Albedo.Texture);<br />
FDraw.AdAppl.SetRenderTarget(1, FRT_2_Position.Texture);<br />
FDraw.AdAppl.SetRenderTarget(2, FRT_3_Normal.Texture);<br />
<br />
FDraw.AdAppl.Viewport := AdRect(0, 0, surfacew, surfaceh);<br />
FDraw.AdAppl.ClearSurface(AdRect(0, 0, surfacew, surfaceh), [alColorBuffer, alZBuffer,<br />
alStencilBuffer], Ad_ARGB(0, 0, 0, 0), 1, 1);<br />
<br />
//Activate the shaders<br />
FTransformShader.FragmentShader.BindEffect;<br />
FTransformShader.VertexShader.BindEffect;<br />
<br />
FScene.Draw(FCamera, nil, 0);<br />
<br />
//Deactivate the shaders<br />
FTransformShader.VertexShader.UnbindEffect;<br />
FTransformShader.FragmentShader.UnbindEffect;<br />
<br />
FDraw.AdAppl.SetRenderTarget(2, nil);<br />
FDraw.AdAppl.SetRenderTarget(1, nil);<br />
FDraw.AdAppl.SetRenderTarget(0, nil);<br />
</pascal><br />
<br />
<br />
'''Schritt 4: Einfacher Direktionaler Licht-Shader'''<br><br />
Das zur Beleuchtung verwendete Quad liegt in diesem (einfachen) Fall bereits projeziert in normierten Koordinaten vor.<br />
<source lang="c"><br />
struct ps_light_res {<br />
float4 color: COLOR0;<br />
};<br />
<br />
ps_light_res ps_light_geometry(<br />
float3 screenpos: TEXCOORD0,<br />
float3 viewpos: TEXCOORD1,<br />
float3 lightdir: TEXCOORD2,<br />
<br />
uniform sampler sPosition,<br />
uniform sampler sNormal,<br />
uniform sampler sAlbedo,<br />
uniform float4 lightcolor<br />
)<br />
{<br />
ps_light_res OUT;<br />
<br />
float4 col = tex2D(sAlbedo, float2(screenpos.x, -screenpos.y));<br />
float4 normal = tex2D(sNormal, float2(screenpos.x, -screenpos.y));<br />
<br />
OUT.color = float4((lightcolor * col * clamp(dot(normal.xyz, lightdir), 0.0f, 1.0f)).rgb, 1.0f);<br />
<br />
//OUT.color = float4(0.0f, 0.0f, 1.0f, 1.0f);<br />
<br />
//OUT.color = col;<br />
<br />
return OUT;<br />
}<br />
<br />
struct vs_light_res {<br />
float4 pos: POSITION;<br />
float3 screenpos: TEXCOORD0;<br />
float3 viewpos: TEXCOORD1;<br />
float3 lightdir: TEXCOORD2;<br />
};<br />
<br />
vs_light_res vs_light_geometry(<br />
float3 position : POSITION,<br />
uniform float4x4 modelview,<br />
uniform float4x4 modelviewproj,<br />
uniform float3 lightdir<br />
)<br />
{<br />
vs_light_res OUT;<br />
<br />
OUT.pos = float4(position, 1.0f);<br />
OUT.screenpos = position * float3(0.5f, 0.5f, 0.0f) + float3(0.5f, 0.5f, 0.0f);//mul(pos, modelviewproj);<br />
OUT.viewpos = mul(position, modelview);<br />
OUT.lightdir = normalize(mul(float4(lightdir, 0.0f), modelview));<br />
<br />
return OUT;<br />
}<br />
</source><br />
<br />
<br />
'''Schritt 5: Lichtquellen in das Composite RT rendern'''<br />
<pascal><br />
//Render a directional light using a quad<br />
FDraw.AdAppl.SetRenderTarget(0, FRT_4_Composite.Texture);<br />
FDraw.AdAppl.Viewport := AdRect(0, 0, surfacew, surfaceh);<br />
FDraw.AdAppl.ClearSurface(AdRect(0, 0, surfacew, surfaceh), [alColorBuffer, alZBuffer,<br />
alStencilBuffer], Ad_ARGB(255, 0, 0, 0), 1, 1); <br />
<br />
FLightShader.FragmentShader.SetParameter('sAlbedo', FRT_1_Albedo.Texture);<br />
FLightShader.FragmentShader.SetParameter('sPosition', FRT_2_Position.Texture);<br />
FLightShader.FragmentShader.SetParameter('sNormal', FRT_3_Normal.Texture);<br />
<br />
FLightShader.FragmentShader.BindEffect;<br />
FLightShader.VertexShader.BindEffect;<br />
<br />
//Render a blue light<br />
FLightShader.FragmentShader.SetParameter('lightcolor', Ad_ARGB(255, 50, 50, 100));<br />
FLightShader.VertexShader.SetParameter('lightdir', AcVector_Normalize(AcVector3(2.0, 2.0, -1.0)));<br />
FQuad.BlendMode = bmAdd;<br />
FQuad.Draw(nil);<br />
<br />
FLightShader.FragmentShader.UnbindEffect;<br />
FLightShader.VertexShader.UnbindEffect;<br />
</pascal><br />
<br />
<br />
'''Schritt 6: Das Ergebnis Zeichnen'''<br><br />
Nun muss nur noch das Ergebnis im "Composite"-RT gezeichnet werden - oder weitere Post-Processing Maßnahmen durchgeführt werden.<br />
<br />
==Weblinks==<br />
* http://www.gamedev.net/reference/programming/features/defRender/<br />
<br />
==Siehe auch==<br />
* [[Shader]]<br />
* [[Hintergrundwissen#Render-Pipeline]]</div>Igel457https://wiki.delphigl.com/index.php?title=Deferred_Shading&diff=24760Deferred Shading2010-03-14T21:53:53Z<p>Igel457: </p>
<hr />
<div>= Deferred Shading =<br />
<br />
Der Befriff ''Deferred Shading'' (zu dt. "verzögertes Schattieren") oder auch ''Deferred Lighting'' ("verzögerte Beleuchtung") beschreibt eine Technik, mit deren Hilfe eine komplette Lichtquelle mit nur einem einzigen Draw-Call abgebildet werden kann.<br />
<br />
== Vorgehensweise ==<br />
Um eine Szene mit einem traditionellen Forward-Renderer zu beleuchten, wird normalerweise jedes Objekt der Szene mit den entsprechenden Beleuchtungsparametern der Lichtquelle gezeichnet. Die verschiedenen Ergebnisse werden durch additives Blenden akkumuliert. Für jede Lichtquelle ''nl'' muss also jedes Objekt ''no'' gezeichnet werden. Die Anzahl der Rendercalls liegt also bei ''no * nl''. Hierdurch sind nur wenige Lichtquellen gleichzeitig möglich.<br />
<br />
''Deferred Shading'' verfolgt einen anderen Ansatz: Anstatt jedes Objekt der Szene für jede Lichtquelle neu zu renderen, werden zunächst alle beleuchtungsrelevanten Daten (Position des Pixels, Normalenvektoren, unbeleuchtete Farbe des Pixels (Albedo), Glanzstärke, etc.) auf Pixelbasis in mehrere Rendertargets (oftmals auch G-Buffer genannt) geschrieben. Nun muss für jede Lichtquelle lediglich die Lichtquellengeometrie gezeichnet werden und in diesem Schritt die Beleuchtung auf die zwischengespeicherten Daten angewendet werden. Die Zahl der Rendercalls liegt also bei ''no + nl''. Mit dieser Methode sind hunderte Objekte gleichzeitig in einer Szene möglich.<br />
<br />
== Vor-/Nachteile ==<br />
<br />
'''Vorteile:'''<br />
* Viele Lichtquellen möglich<br />
* Postprocessing Effekte (Bloom, Tonemapping, Depth of Field) können einfach angeschlossen werden<br />
<br />
'''Nachteile:'''<br />
* Kein Hardware Anti-Alias möglich<br />
* Tranparente Objekte müssen getrennt behandelt werden<br />
* Nur auf neueren Grafikkarten mit MRT (Mutliple Render Target) und Floating Point-Textur Support möglich<br />
<br />
== Implementierung ==<br />
Zunächst müssen die Geometriedaten in den (G-Buffer) geschrieben werden. Hierzu benötigen wir drei 16-Bit Float Rendertarget Texturen. Niedrigere Bittiefen sind für Positionsbeschreibung und Normalenvektor zu wenig. Alle Rendertarget-Texturen müssen die gleiche Bittiefe haben. Sind mehrere Rendertargets aktiviert, so wird Hardware-Anti-Aliasing automatisch abgeschaltet. Die folgenden Beispiele sind mit Andorra 2D entwickelt und sollten recht einfach verständlich und nach OpenGL/DirectX umzusetzen sein.<br />
<br />
'''Schritt 1: Erstellen der Rendertargets'''<br />
<pascal><br />
FRT_1_Albedo := TAdRenderTargetTexture.Create(FDraw);<br />
FRT_1_Albedo.BitDepth := adF64Bit;<br />
FRT_1_Albedo.SetSize(surfacew, surfaceh);<br />
FRT_1_Albedo.Filter := atPoint;<br />
<br />
FRT_2_Position := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
<br />
FRT_3_Normal := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
<br />
FRT_4_Composite := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
</pascal><br />
<br />
'''Schritt 2: Der G-Buffer-Fill Shader (HLSL/Cg)'''<br><br />
Der hier gezeigte Shader ist nur ein einfaches Beispiel. Unter anderem kann durch das geschickte Weglassen von Daten (Berechnen von X, Y aus den Z und den Screen-Coordinaten im Lighting-Shader) Bandbreite eingespart werden.<br />
<source lang="c"><br />
//Fragment Shader<br />
<br />
struct fs_res {<br />
float4 position: COLOR1;<br />
float4 normal: COLOR2;<br />
float4 albedo: COLOR0;<br />
};<br />
<br />
fs_res fs_std_geometry(<br />
float3 viewpos: TEXCOORD0,<br />
float3 normal: TEXCOORD1<br />
)<br />
{<br />
fs_res OUT; <br />
<br />
OUT.position = float4(viewpos, 1.0f); <br />
OUT.normal = float4(normal, 1.0f);<br />
OUT.albedo = float4(1.0f, 1.0f, 1.0f , 1.0f);<br />
<br />
return OUT;<br />
}<br />
<br />
//Vertex Shader<br />
<br />
struct vs_res {<br />
float4 pos: POSITION;<br />
float3 viewpos : TEXCOORD0; <br />
float3 normal: TEXCOORD1;<br />
};<br />
<br />
vs_res vs_std_geometry(<br />
float3 position : POSITION,<br />
float3 normal: NORMAL,<br />
uniform float4x4 modelview,<br />
uniform float4x4 modelviewproj<br />
)<br />
{<br />
vs_res OUT; <br />
<br />
OUT.pos = mul(float4(position, 1.0f), modelviewproj);<br />
OUT.viewpos = mul(float4(position, 1.0f), modelview);<br />
OUT.normal = normalize(mul(float4(normal, 0.0f), modelview));<br />
<br />
return OUT;<br />
}<br />
</source><br />
<br />
<br />
'''Schritt 3: Daten in G-Buffer Rendern'''<br />
<pascal><br />
//<br />
//---- G-Buffer fill pass ----<br />
//<br />
<br />
//Activate the G-Buffers<br />
FDraw.AdAppl.SetRenderTarget(0, FRT_1_Albedo.Texture);<br />
FDraw.AdAppl.SetRenderTarget(1, FRT_2_Position.Texture);<br />
FDraw.AdAppl.SetRenderTarget(2, FRT_3_Normal.Texture);<br />
<br />
FDraw.AdAppl.Viewport := AdRect(0, 0, surfacew, surfaceh);<br />
FDraw.AdAppl.ClearSurface(AdRect(0, 0, surfacew, surfaceh), [alColorBuffer, alZBuffer,<br />
alStencilBuffer], Ad_ARGB(0, 0, 0, 0), 1, 1);<br />
<br />
//Activate the shaders<br />
FTransformShader.FragmentShader.BindEffect;<br />
FTransformShader.VertexShader.BindEffect;<br />
<br />
FScene.Draw(FCamera, nil, 0);<br />
<br />
//Deactivate the shaders<br />
FTransformShader.VertexShader.UnbindEffect;<br />
FTransformShader.FragmentShader.UnbindEffect;<br />
<br />
FDraw.AdAppl.SetRenderTarget(2, nil);<br />
FDraw.AdAppl.SetRenderTarget(1, nil);<br />
FDraw.AdAppl.SetRenderTarget(0, nil);<br />
</pascal><br />
<br />
<br />
'''Schritt 4: Einfacher Direktionaler Licht-Shader'''<br><br />
Das zur Beleuchtung verwendete Quad liegt in diesem (einfachen) Fall bereits projeziert in normierten Koordinaten vor.<br />
<source lang="c"><br />
struct ps_light_res {<br />
float4 color: COLOR0;<br />
};<br />
<br />
ps_light_res ps_light_geometry(<br />
float3 screenpos: TEXCOORD0,<br />
float3 viewpos: TEXCOORD1,<br />
float3 lightdir: TEXCOORD2,<br />
<br />
uniform sampler sPosition,<br />
uniform sampler sNormal,<br />
uniform sampler sAlbedo,<br />
uniform float4 lightcolor<br />
)<br />
{<br />
ps_light_res OUT;<br />
<br />
float4 col = tex2D(sAlbedo, float2(screenpos.x, -screenpos.y));<br />
float4 normal = tex2D(sNormal, float2(screenpos.x, -screenpos.y));<br />
<br />
OUT.color = float4((lightcolor * col * clamp(dot(normal.xyz, lightdir), 0.0f, 1.0f)).rgb, 1.0f);<br />
<br />
//OUT.color = float4(0.0f, 0.0f, 1.0f, 1.0f);<br />
<br />
//OUT.color = col;<br />
<br />
return OUT;<br />
}<br />
<br />
struct vs_light_res {<br />
float4 pos: POSITION;<br />
float3 screenpos: TEXCOORD0;<br />
float3 viewpos: TEXCOORD1;<br />
float3 lightdir: TEXCOORD2;<br />
};<br />
<br />
vs_light_res vs_light_geometry(<br />
float3 position : POSITION,<br />
uniform float4x4 modelview,<br />
uniform float4x4 modelviewproj,<br />
uniform float3 lightdir<br />
)<br />
{<br />
vs_light_res OUT;<br />
<br />
OUT.pos = float4(position, 1.0f);<br />
OUT.screenpos = position * float3(0.5f, 0.5f, 0.0f) + float3(0.5f, 0.5f, 0.0f);//mul(pos, modelviewproj);<br />
OUT.viewpos = mul(position, modelview);<br />
OUT.lightdir = normalize(mul(float4(lightdir, 0.0f), modelview));<br />
<br />
return OUT;<br />
}<br />
</source><br />
<br />
<br />
'''Schritt 5: Lichtquellen in das Composite RT rendern'''<br />
<pascal><br />
//Render a directional light using a quad<br />
FDraw.AdAppl.SetRenderTarget(0, FRT_4_Composite.Texture);<br />
FDraw.AdAppl.Viewport := AdRect(0, 0, surfacew, surfaceh);<br />
FDraw.AdAppl.ClearSurface(AdRect(0, 0, surfacew, surfaceh), [alColorBuffer, alZBuffer,<br />
alStencilBuffer], Ad_ARGB(255, 0, 0, 0), 1, 1); <br />
<br />
FLightShader.FragmentShader.SetParameter('sAlbedo', FRT_1_Albedo.Texture);<br />
FLightShader.FragmentShader.SetParameter('sPosition', FRT_2_Position.Texture);<br />
FLightShader.FragmentShader.SetParameter('sNormal', FRT_3_Normal.Texture);<br />
<br />
FLightShader.FragmentShader.BindEffect;<br />
FLightShader.VertexShader.BindEffect;<br />
<br />
//Render a blue light<br />
FLightShader.FragmentShader.SetParameter('lightcolor', Ad_ARGB(255, 50, 50, 100));<br />
FLightShader.VertexShader.SetParameter('lightdir', AcVector_Normalize(AcVector3(2.0, 2.0, -1.0)));<br />
FQuad.BlendMode = bmAdd;<br />
FQuad.Draw(nil);<br />
<br />
FLightShader.FragmentShader.UnbindEffect;<br />
FLightShader.VertexShader.UnbindEffect;<br />
</pascal><br />
<br />
<br />
'''Schritt 6: Das Ergebnis Zeichnen'''<br><br />
Nun muss nur noch das Ergebnis im "Composite"-RT gezeichnet werden - oder weitere Post-Processing Maßnahmen durchgeführt werden.<br />
<br />
==Weblinks==<br />
* http://www.gamedev.net/reference/programming/features/defRender/<br />
<br />
==Siehe auch==<br />
* [[Shader]]<br />
* [[Grafik Pipeline]]</div>Igel457https://wiki.delphigl.com/index.php?title=Deferred_Shading&diff=24759Deferred Shading2010-03-14T21:53:29Z<p>Igel457: /* Implementierung */</p>
<hr />
<div>= Deferred Shading =<br />
<br />
Der Befriff ''Deferred Shading'' (zu dt. "verzögertes Schattieren") oder auch ''Deferred Lighting'' ("verzögerte Beleuchtung") beschreibt eine Technik, mit deren Hilfe eine komplette Lichtquelle mit nur einem einzigen Draw-Call abgebildet werden kann.<br />
<br />
== Vorgehensweise ==<br />
Um eine Szene mit einem traditionellen Forward-Renderer zu beleuchten, wird normalerweise jedes Objekt der Szene mit den entsprechenden Beleuchtungsparametern der Lichtquelle gezeichnet. Die verschiedenen Ergebnisse werden durch additives Blenden akkumuliert. Für jede Lichtquelle ''nl'' muss also jedes Objekt ''no'' gezeichnet werden. Die Anzahl der Rendercalls liegt also bei ''no * nl''. Hierdurch sind nur wenige Lichtquellen gleichzeitig möglich.<br />
<br />
''Deferred Shading'' verfolgt einen anderen Ansatz: Anstatt jedes Objekt der Szene für jede Lichtquelle neu zu renderen, werden zunächst alle beleuchtungsrelevanten Daten (Position des Pixels, Normalenvektoren, unbeleuchtete Farbe des Pixels (Albedo), Glanzstärke, etc.) auf Pixelbasis in mehrere Rendertargets (oftmals auch G-Buffer genannt) geschrieben. Nun muss für jede Lichtquelle lediglich die Lichtquellengeometrie gezeichnet werden und in diesem Schritt die Beleuchtung auf die zwischengespeicherten Daten angewendet werden. Die Zahl der Rendercalls liegt also bei ''no + nl''. Mit dieser Methode sind hunderte Objekte gleichzeitig in einer Szene möglich.<br />
<br />
== Vor-/Nachteile ==<br />
<br />
'''Vorteile:'''<br />
* Viele Lichtquellen möglich<br />
* Postprocessing Effekte (Bloom, Tonemapping, Depth of Field) können einfach angeschlossen werden<br />
<br />
'''Nachteile:'''<br />
* Kein Hardware Anti-Alias möglich<br />
* Tranparente Objekte müssen getrennt behandelt werden<br />
* Nur auf neueren Grafikkarten mit MRT (Mutliple Render Target) und Floating Point-Textur Support möglich<br />
<br />
== Implementierung ==<br />
Zunächst müssen die Geometriedaten in den (G-Buffer) geschrieben werden. Hierzu benötigen wir drei 16-Bit Float Rendertarget Texturen. Niedrigere Bittiefen sind für Positionsbeschreibung und Normalenvektor zu wenig. Alle Rendertarget-Texturen müssen die gleiche Bittiefe haben. Sind mehrere Rendertargets aktiviert, so wird Hardware-Anti-Aliasing automatisch abgeschaltet. Die folgenden Beispiele sind mit Andorra 2D entwickelt und sollten recht einfach verständlich und nach OpenGL/DirectX umzusetzen sein.<br />
<br />
'''Schritt 1: Erstellen der Rendertargets'''<br />
<pascal><br />
FRT_1_Albedo := TAdRenderTargetTexture.Create(FDraw);<br />
FRT_1_Albedo.BitDepth := adF64Bit;<br />
FRT_1_Albedo.SetSize(surfacew, surfaceh);<br />
FRT_1_Albedo.Filter := atPoint;<br />
<br />
FRT_2_Position := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
<br />
FRT_3_Normal := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
<br />
FRT_4_Composite := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
</pascal><br />
<br />
'''Schritt 2: Der G-Buffer-Fill Shader (HLSL/Cg)'''<br />
Der hier gezeigte Shader ist nur ein einfaches Beispiel. Unter anderem kann durch das geschickte Weglassen von Daten (Berechnen von X, Y aus den Z und den Screen-Coordinaten im Lighting-Shader) Bandbreite eingespart werden.<br />
<source lang="c"><br />
//Fragment Shader<br />
<br />
struct fs_res {<br />
float4 position: COLOR1;<br />
float4 normal: COLOR2;<br />
float4 albedo: COLOR0;<br />
};<br />
<br />
fs_res fs_std_geometry(<br />
float3 viewpos: TEXCOORD0,<br />
float3 normal: TEXCOORD1<br />
)<br />
{<br />
fs_res OUT; <br />
<br />
OUT.position = float4(viewpos, 1.0f); <br />
OUT.normal = float4(normal, 1.0f);<br />
OUT.albedo = float4(1.0f, 1.0f, 1.0f , 1.0f);<br />
<br />
return OUT;<br />
}<br />
<br />
//Vertex Shader<br />
<br />
struct vs_res {<br />
float4 pos: POSITION;<br />
float3 viewpos : TEXCOORD0; <br />
float3 normal: TEXCOORD1;<br />
};<br />
<br />
vs_res vs_std_geometry(<br />
float3 position : POSITION,<br />
float3 normal: NORMAL,<br />
uniform float4x4 modelview,<br />
uniform float4x4 modelviewproj<br />
)<br />
{<br />
vs_res OUT; <br />
<br />
OUT.pos = mul(float4(position, 1.0f), modelviewproj);<br />
OUT.viewpos = mul(float4(position, 1.0f), modelview);<br />
OUT.normal = normalize(mul(float4(normal, 0.0f), modelview));<br />
<br />
return OUT;<br />
}<br />
</source><br />
<br />
<br />
'''Schritt 3: Daten in G-Buffer Rendern'''<br />
<pascal><br />
//<br />
//---- G-Buffer fill pass ----<br />
//<br />
<br />
//Activate the G-Buffers<br />
FDraw.AdAppl.SetRenderTarget(0, FRT_1_Albedo.Texture);<br />
FDraw.AdAppl.SetRenderTarget(1, FRT_2_Position.Texture);<br />
FDraw.AdAppl.SetRenderTarget(2, FRT_3_Normal.Texture);<br />
<br />
FDraw.AdAppl.Viewport := AdRect(0, 0, surfacew, surfaceh);<br />
FDraw.AdAppl.ClearSurface(AdRect(0, 0, surfacew, surfaceh), [alColorBuffer, alZBuffer,<br />
alStencilBuffer], Ad_ARGB(0, 0, 0, 0), 1, 1);<br />
<br />
//Activate the shaders<br />
FTransformShader.FragmentShader.BindEffect;<br />
FTransformShader.VertexShader.BindEffect;<br />
<br />
FScene.Draw(FCamera, nil, 0);<br />
<br />
//Deactivate the shaders<br />
FTransformShader.VertexShader.UnbindEffect;<br />
FTransformShader.FragmentShader.UnbindEffect;<br />
<br />
FDraw.AdAppl.SetRenderTarget(2, nil);<br />
FDraw.AdAppl.SetRenderTarget(1, nil);<br />
FDraw.AdAppl.SetRenderTarget(0, nil);<br />
</pascal><br />
<br />
<br />
'''Schritt 4: Einfacher Direktionaler Licht-Shader'''<br />
Das zur Beleuchtung verwendete Quad liegt in diesem (einfachen) Fall bereits projeziert in normierten Koordinaten vor.<br />
<source lang="c"><br />
struct ps_light_res {<br />
float4 color: COLOR0;<br />
};<br />
<br />
ps_light_res ps_light_geometry(<br />
float3 screenpos: TEXCOORD0,<br />
float3 viewpos: TEXCOORD1,<br />
float3 lightdir: TEXCOORD2,<br />
<br />
uniform sampler sPosition,<br />
uniform sampler sNormal,<br />
uniform sampler sAlbedo,<br />
uniform float4 lightcolor<br />
)<br />
{<br />
ps_light_res OUT;<br />
<br />
float4 col = tex2D(sAlbedo, float2(screenpos.x, -screenpos.y));<br />
float4 normal = tex2D(sNormal, float2(screenpos.x, -screenpos.y));<br />
<br />
OUT.color = float4((lightcolor * col * clamp(dot(normal.xyz, lightdir), 0.0f, 1.0f)).rgb, 1.0f);<br />
<br />
//OUT.color = float4(0.0f, 0.0f, 1.0f, 1.0f);<br />
<br />
//OUT.color = col;<br />
<br />
return OUT;<br />
}<br />
<br />
struct vs_light_res {<br />
float4 pos: POSITION;<br />
float3 screenpos: TEXCOORD0;<br />
float3 viewpos: TEXCOORD1;<br />
float3 lightdir: TEXCOORD2;<br />
};<br />
<br />
vs_light_res vs_light_geometry(<br />
float3 position : POSITION,<br />
uniform float4x4 modelview,<br />
uniform float4x4 modelviewproj,<br />
uniform float3 lightdir<br />
)<br />
{<br />
vs_light_res OUT;<br />
<br />
OUT.pos = float4(position, 1.0f);<br />
OUT.screenpos = position * float3(0.5f, 0.5f, 0.0f) + float3(0.5f, 0.5f, 0.0f);//mul(pos, modelviewproj);<br />
OUT.viewpos = mul(position, modelview);<br />
OUT.lightdir = normalize(mul(float4(lightdir, 0.0f), modelview));<br />
<br />
return OUT;<br />
}<br />
</source><br />
<br />
<br />
'''Schritt 5: Lichtquellen in das Composite RT rendern'''<br />
<pascal><br />
//Render a directional light using a quad<br />
FDraw.AdAppl.SetRenderTarget(0, FRT_4_Composite.Texture);<br />
FDraw.AdAppl.Viewport := AdRect(0, 0, surfacew, surfaceh);<br />
FDraw.AdAppl.ClearSurface(AdRect(0, 0, surfacew, surfaceh), [alColorBuffer, alZBuffer,<br />
alStencilBuffer], Ad_ARGB(255, 0, 0, 0), 1, 1); <br />
<br />
FLightShader.FragmentShader.SetParameter('sAlbedo', FRT_1_Albedo.Texture);<br />
FLightShader.FragmentShader.SetParameter('sPosition', FRT_2_Position.Texture);<br />
FLightShader.FragmentShader.SetParameter('sNormal', FRT_3_Normal.Texture);<br />
<br />
FLightShader.FragmentShader.BindEffect;<br />
FLightShader.VertexShader.BindEffect;<br />
<br />
//Render a blue light<br />
FLightShader.FragmentShader.SetParameter('lightcolor', Ad_ARGB(255, 50, 50, 100));<br />
FLightShader.VertexShader.SetParameter('lightdir', AcVector_Normalize(AcVector3(2.0, 2.0, -1.0)));<br />
FQuad.BlendMode = bmAdd;<br />
FQuad.Draw(nil);<br />
<br />
FLightShader.FragmentShader.UnbindEffect;<br />
FLightShader.VertexShader.UnbindEffect;<br />
</pascal><br />
<br />
<br />
'''Schritt 6: Das Ergebnis Zeichnen'''<br><br />
Nun muss nur noch das Ergebnis im "Composite"-RT gezeichnet werden - oder weitere Post-Processing Maßnahmen durchgeführt werden.<br />
<br />
==Weblinks==<br />
* http://www.gamedev.net/reference/programming/features/defRender/<br />
<br />
==Siehe auch==<br />
* [[Shader]]<br />
* [[Grafik Pipeline]]</div>Igel457https://wiki.delphigl.com/index.php?title=Deferred_Shading&diff=24758Deferred Shading2010-03-14T21:51:33Z<p>Igel457: /* Vorgehensweise */</p>
<hr />
<div>= Deferred Shading =<br />
<br />
Der Befriff ''Deferred Shading'' (zu dt. "verzögertes Schattieren") oder auch ''Deferred Lighting'' ("verzögerte Beleuchtung") beschreibt eine Technik, mit deren Hilfe eine komplette Lichtquelle mit nur einem einzigen Draw-Call abgebildet werden kann.<br />
<br />
== Vorgehensweise ==<br />
Um eine Szene mit einem traditionellen Forward-Renderer zu beleuchten, wird normalerweise jedes Objekt der Szene mit den entsprechenden Beleuchtungsparametern der Lichtquelle gezeichnet. Die verschiedenen Ergebnisse werden durch additives Blenden akkumuliert. Für jede Lichtquelle ''nl'' muss also jedes Objekt ''no'' gezeichnet werden. Die Anzahl der Rendercalls liegt also bei ''no * nl''. Hierdurch sind nur wenige Lichtquellen gleichzeitig möglich.<br />
<br />
''Deferred Shading'' verfolgt einen anderen Ansatz: Anstatt jedes Objekt der Szene für jede Lichtquelle neu zu renderen, werden zunächst alle beleuchtungsrelevanten Daten (Position des Pixels, Normalenvektoren, unbeleuchtete Farbe des Pixels (Albedo), Glanzstärke, etc.) auf Pixelbasis in mehrere Rendertargets (oftmals auch G-Buffer genannt) geschrieben. Nun muss für jede Lichtquelle lediglich die Lichtquellengeometrie gezeichnet werden und in diesem Schritt die Beleuchtung auf die zwischengespeicherten Daten angewendet werden. Die Zahl der Rendercalls liegt also bei ''no + nl''. Mit dieser Methode sind hunderte Objekte gleichzeitig in einer Szene möglich.<br />
<br />
== Vor-/Nachteile ==<br />
<br />
'''Vorteile:'''<br />
* Viele Lichtquellen möglich<br />
* Postprocessing Effekte (Bloom, Tonemapping, Depth of Field) können einfach angeschlossen werden<br />
<br />
'''Nachteile:'''<br />
* Kein Hardware Anti-Alias möglich<br />
* Tranparente Objekte müssen getrennt behandelt werden<br />
* Nur auf neueren Grafikkarten mit MRT (Mutliple Render Target) und Floating Point-Textur Support möglich<br />
<br />
== Implementierung ==<br />
Zunächst müssen die Geometriedaten in den (G-Buffer) geschrieben werden. Hierzu benötigen wir drei 16-Bit Float Rendertarget Texturen. Niedrigere Bittiefen sind für Positionsbeschreibung und Normalenvektor zu wenig. Alle Rendertarget-Texturen müssen die gleiche Bittiefe haben. Sind mehrere Rendertargets aktiviert, so wird Hardware-Anti-Aliasing automatisch abgeschaltet. Die folgenden Beispiele sind mit Andorra 2D entwickelt und sollten recht einfach verständlich und nach OpenGL/DirectX umzusetzen sein.<br />
<br />
'''Schritt 1: Erstellen der Rendertargets'''<br />
<pascal><br />
FRT_1_Albedo := TAdRenderTargetTexture.Create(FDraw);<br />
FRT_1_Albedo.BitDepth := adF64Bit;<br />
FRT_1_Albedo.SetSize(surfacew, surfaceh);<br />
FRT_1_Albedo.Filter := atPoint;<br />
<br />
FRT_2_Position := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
<br />
FRT_3_Normal := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
<br />
FRT_4_Composite := TAdRenderTargetTexture.Create(FDraw);<br />
[...]<br />
</pascal><br />
<br />
'''Schritt 2: Der G-Buffer-Fill Shader (HLSL/Cg)'''<br />
Der hier gezeigte Shader ist nur ein einfaches Beispiel. Unter anderem kann durch das geschickte Weglassen von Daten (Berechnen von X, Y aus den Z und den Screen-Coordinaten im Lighting-Shader) Bandbreite eingespart werden.<br />
<source lang="c"><br />
//Fragment Shader<br />
<br />
struct fs_res {<br />
float4 position: COLOR1;<br />
float4 normal: COLOR2;<br />
float4 albedo: COLOR0;<br />
};<br />
<br />
fs_res fs_std_geometry(<br />
float3 viewpos: TEXCOORD0,<br />
float3 normal: TEXCOORD1<br />
)<br />
{<br />
fs_res OUT; <br />
<br />
OUT.position = float4(viewpos, 1.0f); <br />
OUT.normal = float4(normal, 1.0f);<br />
OUT.albedo = float4(1.0f, 1.0f, 1.0f , 1.0f);<br />
<br />
return OUT;<br />
}<br />
<br />
//Vertex Shader<br />
<br />
struct vs_res {<br />
float4 pos: POSITION;<br />
float3 viewpos : TEXCOORD0; <br />
float3 normal: TEXCOORD1;<br />
};<br />
<br />
vs_res vs_std_geometry(<br />
float3 position : POSITION,<br />
float3 normal: NORMAL,<br />
uniform float4x4 modelview,<br />
uniform float4x4 modelviewproj<br />
)<br />
{<br />
vs_res OUT; <br />
<br />
OUT.pos = mul(float4(position, 1.0f), modelviewproj);<br />
OUT.viewpos = mul(float4(position, 1.0f), modelview);<br />
OUT.normal = normalize(mul(float4(normal, 0.0f), modelview));<br />
<br />
return OUT;<br />
}<br />
</source><br />
<br />
<br />
'''Schritt 3: Daten in G-Buffer Rendern'''<br />
<pascal><br />
//<br />
//---- G-Buffer fill pass ----<br />
//<br />
<br />
//Activate the G-Buffers<br />
FDraw.AdAppl.SetRenderTarget(0, FRT_1_Albedo.Texture);<br />
FDraw.AdAppl.SetRenderTarget(1, FRT_2_Position.Texture);<br />
FDraw.AdAppl.SetRenderTarget(2, FRT_3_Normal.Texture);<br />
<br />
FDraw.AdAppl.Viewport := AdRect(0, 0, surfacew, surfaceh);<br />
FDraw.AdAppl.ClearSurface(AdRect(0, 0, surfacew, surfaceh), [alColorBuffer, alZBuffer,<br />
alStencilBuffer], Ad_ARGB(0, 0, 0, 0), 1, 1);<br />
<br />
//Activate the shaders<br />
FTransformShader.FragmentShader.BindEffect;<br />
FTransformShader.VertexShader.BindEffect;<br />
<br />
FScene.Draw(FCamera, nil, 0);<br />
<br />
//Deactivate the shaders<br />
FTransformShader.VertexShader.UnbindEffect;<br />
FTransformShader.FragmentShader.UnbindEffect;<br />
<br />
FDraw.AdAppl.SetRenderTarget(2, nil);<br />
FDraw.AdAppl.SetRenderTarget(1, nil);<br />
FDraw.AdAppl.SetRenderTarget(0, nil);<br />
</pascal><br />
<br />
<br />
'''Schritt 4: Einfacher Direktionaler Licht-Shader'''<br />
<source lang="c"><br />
struct ps_light_res {<br />
float4 color: COLOR0;<br />
};<br />
<br />
ps_light_res ps_light_geometry(<br />
float3 screenpos: TEXCOORD0,<br />
float3 viewpos: TEXCOORD1,<br />
float3 lightdir: TEXCOORD2,<br />
<br />
uniform sampler sPosition,<br />
uniform sampler sNormal,<br />
uniform sampler sAlbedo,<br />
uniform float4 lightcolor<br />
)<br />
{<br />
ps_light_res OUT;<br />
<br />
float4 col = tex2D(sAlbedo, float2(screenpos.x, -screenpos.y));<br />
float4 normal = tex2D(sNormal, float2(screenpos.x, -screenpos.y));<br />
<br />
OUT.color = float4((lightcolor * col * clamp(dot(normal.xyz, lightdir), 0.0f, 1.0f)).rgb, 1.0f);<br />
<br />
//OUT.color = float4(0.0f, 0.0f, 1.0f, 1.0f);<br />
<br />
//OUT.color = col;<br />
<br />
return OUT;<br />
}<br />
<br />
struct vs_light_res {<br />
float4 pos: POSITION;<br />
float3 screenpos: TEXCOORD0;<br />
float3 viewpos: TEXCOORD1;<br />
float3 lightdir: TEXCOORD2;<br />
};<br />
<br />
vs_light_res vs_light_geometry(<br />
float3 position : POSITION,<br />
uniform float4x4 modelview,<br />
uniform float4x4 modelviewproj,<br />
uniform float3 lightdir<br />
)<br />
{<br />
vs_light_res OUT;<br />
<br />
OUT.pos = float4(position, 1.0f);<br />
OUT.screenpos = position * float3(0.5f, 0.5f, 0.0f) + float3(0.5f, 0.5f, 0.0f);//mul(pos, modelviewproj);<br />
OUT.viewpos = mul(position, modelview);<br />
OUT.lightdir = normalize(mul(float4(lightdir, 0.0f), modelview));<br />
<br />
return OUT;<br />
}<br />
</source><br />
<br />
<br />
'''Schritt 5: Lichtquellen in das Composite RT rendern'''<br />
<pascal><br />
//Render a directional light using a quad<br />
FDraw.AdAppl.SetRenderTarget(0, FRT_4_Composite.Texture);<br />
FDraw.AdAppl.Viewport := AdRect(0, 0, surfacew, surfaceh);<br />
FDraw.AdAppl.ClearSurface(AdRect(0, 0, surfacew, surfaceh), [alColorBuffer, alZBuffer,<br />
alStencilBuffer], Ad_ARGB(255, 0, 0, 0), 1, 1); <br />
<br />
FLightShader.FragmentShader.SetParameter('sAlbedo', FRT_1_Albedo.Texture);<br />
FLightShader.FragmentShader.SetParameter('sPosition', FRT_2_Position.Texture);<br />
FLightShader.FragmentShader.SetParameter('sNormal', FRT_3_Normal.Texture);<br />
<br />
FLightShader.FragmentShader.BindEffect;<br />
FLightShader.VertexShader.BindEffect;<br />
<br />
//Render a blue light<br />
FLightShader.FragmentShader.SetParameter('lightcolor', Ad_ARGB(255, 50, 50, 100));<br />
FLightShader.VertexShader.SetParameter('lightdir', AcVector_Normalize(AcVector3(2.0, 2.0, -1.0)));<br />
FQuad.BlendMode = bmAdd;<br />
FQuad.Draw(nil);<br />
<br />
FLightShader.FragmentShader.UnbindEffect;<br />
FLightShader.VertexShader.UnbindEffect;<br />
</pascal><br />
<br />
<br />
'''Schritt 6: Das Ergebnis Zeichnen'''<br />
Nun muss nur noch das Ergebnis im "Composite"-RT gezeichnet werden - oder weitere Post-Processing Maßnahmen durchgeführt werden.<br />
<br />
==Weblinks==<br />
* http://www.gamedev.net/reference/programming/features/defRender/<br />
<br />
==Siehe auch==<br />
* [[Shader]]<br />
* [[Grafik Pipeline]]</div>Igel457https://wiki.delphigl.com/index.php?title=Deferred_Shading&diff=24757Deferred Shading2010-03-14T21:26:01Z<p>Igel457: Angefangen...</p>
<hr />
<div>= Deferred Shading =<br />
<br />
Der Befriff ''Deferred Shading'' (zu dt. "verzögertes Schattieren") oder auch ''Deferred Lighting'' ("verzögerte Beleuchtung") beschreibt eine Technik, mit deren Hilfe eine komplette Lichtquelle mit nur einem einzigen Draw-Call abgebildet werden kann.<br />
<br />
== Vorgehensweise ==<br />
Um eine Szene mit einem traditionellen Forward-Renderer zu beleuchten, wird normalerweise jedes Objekt der Szene mit den entsprechenden Beleuchtungsparametern der Lichtquelle gezeichnet. Die verschiedenen Ergebnisse werden durch additives Blenden akkumuliert. Für jede Lichtquelle ''nl'' muss also jedes Objekt ''no'' gezeichnet werden. Die Anzahl der Rendercalls liegt also bei ''no * nl''. Besonders bei vielen Lichtquellen führt dies zu Geschwindigkeitseinbußen.</div>Igel457https://wiki.delphigl.com/index.php?title=Shader&diff=24613Shader2010-01-16T19:50:49Z<p>Igel457: /* Beispiel: General-Purpose Computation */</p>
<hr />
<div>== Konzept ==<br />
Die traditionelle [[Feste Funktionspipeline|Funktionspipeline]] der [[OpenGL]] ist eine feste Pipeline, auf die man nur beschränkt durch Statechanges Einfluss nehmen kann. Man hat also an sehr vielen Stellen starre Vorgaben die nur minimal anpassbar sind. So sind z.B. Farbberechnungen oder die Beleuchtung fest definiert und nur wenige ihrer Attribute können variiert werden. Neuere Algorithmen erfordern aber eine viel höhere Flexibilität. <br />
<br />
Einzelne Komponenten der Pipeline können nun aber durch kleine Programme, sog. ''Shader'' ersetzt werden. Diese Shader werden in der C ähnlichen Hochsprache GLSL geschrieben. Es gibt Variablen, if-Bedingungen, Schleifen, beliebige Texturzugriffe, ... vom Prinzip ist auf aktuellen Grafikchips fast alles möglich was auch auf auf einer CPU geht. Der wesentliche Unterschied beim Programmieren der GPU ist jedoch, dass die Programme parallel laufen. Die aktuelle CPUs haben bis zu 4 parallel arbeitende Kerne. Demnächst wird es wohl auch CPUs mit 8 Kernen geben. Im Vergleich dazu hat beispielsweise die GeForce GTX 295 zwei GPUs mit jeweils 240 Kernen [[#Quellen|[1]]]. Diese Kerne können jedoch, anderes wie bei der CPU, untereinander nicht kommunizieren. Daher holen Grafikkarten ihre enorme Geschwindigkeit. Es ist also schwierig bis unmöglich einen sequenziellen Algorithmus effizient auf der GPU zu implementieren.<br />
<br />
Aktuelle Hardware kennt mittlerweile nur noch Shader. Die feste Funktionspipeline existiert nur noch als Softwarelösung. Der Grafiktreiber setzt die feste Funktionspipeline also einfach als Shader um.<br />
<br />
Eine kleine Warnung an OpenGL-Anfänger vorweg: Bevor man sich ernsthaft mit Shadern beschäftigt, sollte man die Grundlagen von OpenGL und den Aufbau der Renderingpipeline vollständig verstanden haben!<br />
<br />
Es gibt verschiedene Shader-Versionen, das sogenannte ''ShaderModel'', kurz SM. Man sollte immer darauf achten welches SM die eigene Grafikkarte unterstützt. SM 1.0 unterstützt beispielsweise noch keine if-Bedingungen oder Schleifen. In SM 2.0 gibt es noch keine Texturzugriffe im Vertexshader. Ab SM 4.0 gibt es dann endlich auch Integer-Arithmetik und die Datentypen ''int'' bzw. ''unsigned''. Hier ein paar grobe Richtwerte:<br />
<br />
{|{{Prettytable_B1}}<br />
! &nbsp;Hersteller&nbsp; !! Chip !! ShaderModel<br />
|-<br />
| ATI || Radeon 9800 Pro || 2.0<br />
|-<br />
| Nvidia || GeForce 9800 GT || 4.0<br />
|}<br />
<br />
Folgendes Bild zeigt den Aufbau der festen Renderingpipeline. Die Teile der Pipeline, die sich durch eigene kleine Programme, also Shader, ersetzen lassen, sind mit roten Kästen markiert. Weiter unten im Artikel werden diese Teile dann im einzelnen kurz erklärt und die Möglichkeiten an kleinen Beispielen erläutert. Die im Bild als ''optional'' markierten Teile sind standardmäßig abgeschaltet und nur auf neuester Grafikhardware verfügbar.<br />
<br />
[[Bild:Pipeline.png]]<br />
<br />
Der Scissor- und Stencil-Test ist im Bild nach dem Pixelshader angeordnet. Auf den meisten Diagrammen im Internet ist dies ebenfalls so, daher haben wir uns entschieden diese hier genauso zu machen. Höchstwahrscheinlich ist der Scissor-Test aber direkt im Rasterizer implementiert und auch der Stencil-Test kommt vermutlich aus Performancegründen vor dem Pixelshader. Möglicherweise ist dies auch auf verschiedenen Chips unterschiedlich implementiert. Für das Verständnis der Shader sind diese Implementierungsdetails jedoch unerheblich.<br />
<br />
== Vertexshader ==<br />
Der Vertexshader erlaubt uns jeden Vertex einzeln zu modifizieren. Wir können und müssen die Modelview-Transformation sowie die Perspective-Transformation selbst übernehmen. Wollen wir klassisches [[Gouraud Shading]] müssen wir dies auch selbst übernehmen. <br />
<br />
====Beispiel: Heightmap-Terrain====<br />
[[Bild:Terrain_Hmap.jpg|thumb|256px|Terrain aus Heightmap mit 2048x2048 Auflösung und 16bit Graustufen]]<br />
Angenommen wir benötigen für jeden Vertex eine Position, eine Normale und zwei Sets von Texturkoordinaten, also insgesamt 10 Floats bzw. 40 Bytes. Bei einer Heightmapgröße von 4096x4096 benötigen wir also 640 Mb Speicher. Dies ist also nicht wirklich sinnvoll, insbesondere da viele Grafikkarten nur 512, 256 oder gar nur 128 Mb Speicher haben. Dies ist also mit der festen Funktionspipeline nicht praktikabel zu lösen.<br />
<br />
Gewöhnlich rendert man das Terrain nicht am Stück sondern in Blöcken von z.B. 64x64 Quads. Wir verwenden nun ''einen'' kleinen Vertexbuffer der 65x65 minimale Vertices enthält: Jeweils nur eine 2D-Position. Im Vertexshader verschieben wir die 2D-Vertices an die richtige Stelle. Die Höhe des jeweiligen Vertex wird aus der Heightmap-Textur ausgelesen und an die entsprechende Koordinate geschrieben. Auch die Vertexnormalen und Texturkoordinaten berechnet man direkt im Shader. Letztlich benötigen wir nur den kleinen Vertexbuffer, den ebenfalls sehr kleinen Indexbuffer und natürlich die Heightmaptextur. Angenommen wir verwenden 16bit Graustufen dann hat diese Textur eine Größe von 32 Mb. Dies sollte auch auf älteren Grafikkarten im Rahmen des machbaren sein. Der hier beschriebene Shader ist in der [[Shadersammlung]] verfügbar.<br />
<br />
====Beispiel: Meshanimation====<br />
Will man ein Meshanimieren muss man normalerweise jeden Teil des Meshes einzelnen rendern. Im Vertexshader kann man jeden Teil des Meshes einzeln transformieren oder auch zwischen den Teilen interpolieren. Diese Methode erfordert natürlich eine Markierung der einzelnen Meshteile. Hier eignet sich beispielsweise ein Farbkanal der Vertexfarbe.<br />
<br />
== Fragmentshader ==<br />
Im Fragmentshader dürfen wir die Berechnung des Farbwertes eines Fragments (Pixel) selbst übernehmen. Angenommen wir verarbeiten Dreiecke, dann erhalten wir die interpolierten Vertexattribute als Shader-Input. Als Output schreiben wir in der Regel in gl_FragColor, der Farbe, die in den Framebuffer geschrieben werden soll. In der [http://de.wikipedia.org/wiki/DirectX DirectX]-Welt ist der Fragmentshader unter der Bezeichnung ''Pixelshader'' bekannt.<br />
<br />
Ich denke alleine die Anzahl der folgenden Beispiele zeigt das hier so einiges möglich ist.<br />
<br />
==== Beispiel: Per-Pixel-Lighting ====<br />
[[Bild:perpixellighting.jpg|thumb|256px|Per-Vertex-Lighting vs. Per-Pixel-Lighting]]<br />
Die klassische Anwendung des Fragmentshader ist sicherlich das [[Tutorial_glsl2#Per-Pixel-Lighting|Per-Pixel-Lighting]]. Die feste Funktionspipeline erlaubt nur pro Vertex eine Beleuchtungsfarbe zu berechnen. Über die Fläche des Dreiecks wird diese Farbe dann interpoliert. Bei sehr hoch aufgelösten (viele kleine Dreiecke) [[Mesh]]es mag das funktionieren. Jedoch bei niedriger Auflösung sieht dies ziemlich grauenhaft aus, insbesondere da Specular-Highlights komplett verloren gehen oder verstärkt werden können. Im Bild rechts sieht man eine niedrig aufgelöste Kugel und wie die per-Vertex-Beleuchtung hier unnatürlich wirkt.<br />
<br />
Beim Per-Pixel-Lighting übergibt man vom Vertexshader zusätzliche die Normale des Vertex. Im Fragmentshader erhält man dann also die interpolierte Normale aller drei Vertices. Nun führt man das Phong-Modell das sonst im Vertexshader (bzw. in der festen Pipeline) ausgewertet würde einfach im Fragmentshader auf Grundlage dieser Normale durch. Man erhält also für jeden Pixel die korrekte Beleuchtung. Der hier beschriebene Shader ist in der [[Shadersammlung]] verfügbar.<br />
<br />
==== Beispiel: Bump-Mapping ====<br />
[[Bild:shader_diffuse_bumpmapping_cg.jpg|thumb|256px|Bump-Mapping]]<br />
Anstatt wie beim [[Tutorial_glsl2#Per-Pixel-Lighting|Per-Pixel-Lighting]] die Normale über das Dreieck zu interpolieren können wir auch eine sogenannte Bump-Map benutzen. Dabei kodiert man in den RGB-Farbkanälen einer Textur eine Normale. Diese können wir dann im Pixelshader auslesen und zur Berechnung der Beleuchtung verwenden. So können wir mit geringem Aufwand ein wesentlich höheres Detail vortäuschen.<br />
<br />
==== Beispiel: einfacher Toon-Shader ====<br />
[[Bild:Cartoon.jpg|thumb|256px|Einfacher Toon-Shader]]<br />
In einigen Fällen will man gar keine realistische Beleuchtung, sondern der Szene eher einen cartoon-artigen Look verpassen. In einem Cartoon werden in der Regel nur wenige Farben verwendet und Silhouetten werden durch schwarze Striche verstärkt. Ein solcher Shader ist ziemlich einfach, wenn man die Diffuse-Beleuchtung verstanden hat.<br />
<br />
Die Grundidee liegt in einer 1D-Textur die man als Color-Lookup verwendet. Diese Textur kann ziemlich klein sein und enthält einfach nur ein paar Grauabstufungen, zum Beispiel:<br />
0.2, 0.2, 0.2, 0.4, 0.4, 0.4, 0.6, 0.6, 0.6, 0.8, 0.8, 0.8<br />
Anstatt die erhaltene Diffuse-Beleuchtung direkt zu verwenden, verwendet man diesen Wert der ja zwischen 0 und 1 liegt einfach als 1D-Texturkoordinate für den Color-Lookup. Dadurch bekommen wir die gewünschten groben Schattierungen.<br />
<br />
Wenn wir auch Silhouetten erhalten wollen berechnen wir im Fragmentshader zusätzlich auch noch das Dot-Produkt zwischen Flächennormale und Richtung zur Kamera. Liegt dieser Wert unter einer gewissen Grenze, z.B. 0.1 oder 0.2, rendern wir einfach nur schwarze Farbe. Ansonsten benutzen wir die oben beschriebene Cartoon-Beleuchtung. Dies erzeugt eine dünne schwarze Umrandung.<br />
<br />
==== Beispiel: Terraintextur aus Layern ====<br />
[[Bild:Terrain.jpg|thumb|256px|Terrain mit 3 Texturlayern]]<br />
Man kann ein Heighmap-Terrain auf verschiedene Arten texturieren. Die triviale Variante legt einfach eine kachelbare Textur über das Terrain, die dann immer wiederholt wird. Das sieht natürlich scheußlich aus, also lassen wir das. Der nächste Gedanke ist einfach eine gigantische Textur (ohne Kacheln) über das Terrain zu legen. Soll diese Textur aber eine zeitgemäße Auflösung haben wäre der Speicherbedarf einfach gigantisch und würde wohl den Grafikspeicher sprengen. Man müsste diese Textur also in kleinere Stücke Teilen und diese dann bei Bedarf von der Festplatte nachladen. Funktioniert, es gibt aber auch eine einfachere Variante: Texturlayer.<br />
<br />
Statt nur einer einzigen kachelbaren Textur legen wir mehrere verschiedene dieser Texturen über das Terrain. Beispielsweise eine für Sand, eine für Gras und eine für Felsen. Zusätzlich haben wir eine Alphamap die sich über das gesamte Terrain legt und etwa die Auflösung der Heightmap hat. Diese Alphamap steuert nun wo wir welches Texturlayer sehen wollen. In jedem Farbkanal der Alphamap befinden sich die Werte für ein zugehöriges Layer. Im Fragmentshader brauchen wir also nur alle 4 Texturen an den richtigen Stellen auswerten und folgende Formel auswerten:<br />
:<tt>gl_FragColor = alpha.r * layer0 + alpha.g * layer1 + alpha.b * layer2;</tt><br />
Haben wir unsere Alphamap zuvor geschickt berechnet, also beispielsweise unter Einbeziehung von Terrainsteigung, Höhe, etc. erzeugen wir so eine sehr abwechslungsreiche sich nicht wiederholende Terraintextur mit quasi beliebig hoher Auflösung. Der hier beschriebene Shader ist in der [[Shadersammlung]] verfügbar.<br />
<br />
== Geometryshader ==<br />
Der Geometryshader ist Teil von Shader Model 4.0 und somit nur auf neueren Grafikkarten verfügbar. Zudem gehört er wirklich zu den fortgeschrittenen Dingen in der Computergrafik. Als Anfänger sollte man sich also vielleicht erstmal mit Vertexshader und Fragmentshader zufriedengeben.<br />
<br />
Der Geometryshader kann vom Prinzip die gleichen Dinge tun wie der Vertexshader, hat aber diverse Vorteile:<br />
* verarbeitet man z.B. Dreiecke, kann man ein Dreieck als ganzes Verarbeiten. Man kann also gleichzeitig auf alle 3 Vertices des Dreiecks zu greifen.<br />
* es gibt neben den bekannten GL_POINTS, GL_LINES und GL_TRIANGLES neue Input-Geometrietypen, z.B.: GL_TRIANGLES_ADJACENCY_EXT und GL_TRIANGLE_STRIP_ADJACENCY_EXT. Diese erlauben es nicht nur auf das aktuelle Dreieck zuzugreifen, sondern auch auf die benachbarten Dreiecke. Bei GL_TRIANGLES_ADJACENCY_EXT bekommt man dann zum Beispiel ein Array der Größe 6 für jedes Attribut des Vertex. Diese Adjazenz-Informationen müssen natürlich auch bereits so im Vertexbuffer gegeben sein.<br />
* der Geometryshader stellt neue Funktionen bereit mit denen man neue Primitive zusammenbauen kann. Es gibt drei mögliche Output-Geometrietypen: GL_POINTS, GL_LINE_STRIP und GL_TRIANGLE_STRIP<br />
* alle Primitive die den Geometryshader verlassen muss man selbst erzeugen. Man kann also insbesondere auch einfach keine Primitive erzeugen.<br />
<br />
Kommen wir zu den Nachteilen der aktuellen Implementierung:<br />
* Anzahl der Output-Vertices und der Geometrietyp müssen im voraus festgelegt werden. Egal ob die Vertices erzeugt werden oder nicht wird der dafür nötige Speicher reserviert. Aus diesem Grund ist die Performance eines Geometryshaders sehr stark von dieser einmal vom Programmierer konstant festgelegten Anzahl Output-Vertices abhängig. [[#Quellen|[2]]]<br />
* Der Geometryshader eignet sich nur für kleine Modifikationen, nicht für Heavy-Output Algorithmen.<br />
<br />
Trotz der genannten Nachteile kann man den Geometryshader durchaus sinnvoll einsetzen.<br />
<br />
==== Beispiel: Shadow-Volumes ====<br />
[[Volumetrische_Stencilschatten|Shadow-Volumes]] haben den Nachteil, dass man zusätzliche Geometrie für die Seiten des Volumes erzeugen muss. Dafür gibt es verschiedene Wege.<br />
* Man kann die zusätzliche Geometrie auf der CPU erzeugen und in drei Passes (1. Frontfaces, 2. Backfaces extrudiert, 3. Seiten) rendern. Dies ist offensichtlich ineffizient.<br />
* jede Kante im Mesh durch zwei degenerierte Dreiecke ersetzen. Im Vertexshader kann man dann Backfacing-Polygone extrudieren. Dies erhöht die Vertexanzahl um den Faktor 2. Die Anzahl der Dreiecke wird um den Faktor 4 erhöht.<br />
* der Geometryshader erlaubt es nun die zwei benötigten Dreiecke einfach dann zu erzeugen wenn man sie benötigt. Da man zusätzlich Adjazenz-Informationen benötigt, vergrößert sich auch hier der Vertexbuffer um den Faktor 2. Allerdings bleibt die Anzahl der Dreiecke konstant und es ist nicht notwendig degenerierte Dreiecke zu rendern.<br />
<br />
==== Beispiel: Cube-Maps / Environment-Mapping ====<br />
[[Bild:Tutorial_Cubemap_cubemap0.jpg|thumb|256px|Beispiel aus dem [[Tutorial_Cubemap|Cubemap-Tutorial]]]]<br />
Der Geometryshader stellt ein neues Vertexattribut ''gl_Layer'' zur Verfügung. Dieses erlaubt es zu bestimmen in welchen Framebuffer ein Dreieck gerendert werden soll. Dies kann man nun benutzen um in 6 Framebuffer gleichzeitig zu rendern. Der Geometryshader arbeitet dabei als Geometrie-Duplizierer. Da wir volle Kontrolle über die erzeugte Geometrie haben, können wir für jeden Framebuffer eine andere ModelViewProjection-Matrix zur Transformation verwenden. Man muss natürlich beachten, dass in diesem Fall das [[Frustum_Culling|Frustum-Culling]] zu einem großen Teil im Shader stattfinden muss. Aber, letztendlich kann man so in einem einzigen Durchgang alle 6 Seiten einer [[Environment_Mapping|Environment-Cubemap]] rendern!<br />
<br />
== Transform-Feedback ==<br />
Auch [[Transform-Feedback]] ist ein Feature von Shader Model 4.0 und somit nur auf neueren Grafikkarten verfügbar. Transform-Feedback gehört ebenfalls zu den fortgeschrittenen Dingen in der Computergrafik und sei daher für Anfänger zunächst nicht zu empfehlen. In der [http://de.wikipedia.org/wiki/DirectX DirectX]-Welt ist Transform-Feedback unter der Bezeichnung ''Stream-Out'' bekannt.<br />
<br />
Bei diesem Feature handelt es sich ''nicht'' um einen Shader im eigentlichen Sinne. Jedoch arbeitet Transform-Feedback eng mit dem Vertexshader bzw. dem Geometryshader zusammen. Diese Funktion ermöglicht es einzelne oder alle Output-Variablen aus dem Shader abzugreifen und in ein (oder mehrere) Buffer-Objekte zu schreiben. Buffer-Objekte sind einfach nur Speicherbereiche die sich flexibel als Textur, als Vertexbuffer oder auch Indexbuffer interpretieren lassen. Immer so wie man es gerade braucht.<br />
<br />
Transform-Feedback stellt also eine flexiblere Alternative zu [[Tutorial_Framebufferobject|Framebuffer-Objekten]] dar. Insbesondere kann man beispielsweise gleichzeitig 32bit Float-Vektoren und Integer schreiben, was mit einem Framebuffer bisher nicht möglich ist.<br />
<br />
Ein weiterer Vorteil ist, dass man die Renderpipeline direkt nach dem Transform-Feedback-Schritt (also noch vor dem Cliping) auf Wunsch auch komplett abschalten kann. Insbesondere der Pixelshader wird dann gar nicht erst ausgeführt und auch nichts in den Framebuffer geschrieben.<br />
<br />
==== Beispiel: GPU Partikelsystem ====<br />
[[Bild:Partikel-Gravitation.jpg|thumb|256px|Gravitationssimulation mit 262144 Partikeln]]<br />
Mittels Transform-Feedback kann man ein Partikelsystem fast vollständig auf der Grafikkarte realisieren. Der Vorteil liegt zum Beispiel darin, dass die Partikel nicht in jedem Frame neu auf die Grafikkarte geladen werden müssen. [[GLSL Partikel 2|Dieser Artikel]] beschreibt eine solche Anwendung.<br />
<br />
==== Beispiel: Meshanimation ====<br />
Für diverse Algorithmen muss man die Szene mehrfach, zum Teil auch aus verschiedenen Perspektiven rendern. Natürlich kann man ein komplex animiertes Mesh jedes mal komplett neu berechnen. Man könnte aber auch beim ersten Durchgang die Vertexdaten abgreifen und in einen temporären Buffer schreiben. Beim nächsten Pass kann man einfach diesen Buffer als Vertexbuffer interpretieren und rendern.<br />
<br />
==== Beispiel: General-Purpose Computation ====<br />
Transform-Feedback ist ein wichtiges Feature, wenn man auf der Grafikkarte beliebige Berechnungen durchführen will. Zwar kann man nicht alles effizient auf der GPU implementieren, aber die Anwendung muss auch nicht unbedingt mit 3D-Grafik zusammenhängen. Der Vorteil einer Grafikkarte ist, dass sie hoch parallel arbeitet, dies kann viele Algorithmen extrem beschleunigen. Diverse Beispiele gibt es auf [http://www.gpgpu.org/ gpgpu.org].<br />
<br />
== Wie geht es nun weiter? ==<br />
Nach der Lektüre dieses Artikels sollte dir ungefähr klar sein wozu Shader gut sind und was man damit so alles anstellen kann. Solltest du dich nun dazu entschieden haben tiefer in die Materie einzusteigen, dann empfehlen wir die Lektüre der folgenden Artikel:<br />
* [[Tutorial_glsl|Tutorial GLSL]]: Einstieg in die Shader-Programmierung mit GLSL<br />
* [[Tutorial_glsl2|Tutorial GLSL, Anhang]]<br />
* [[Shadersammlung]]<br />
* [[Shader_(historisch)|Nutzung von Shadern auf alter Grafikhardware]]<br />
* OpenGL-Extensions<br />
** [[GL_EXT_gpu_shader4]]<br />
** [[GL_ARB_geometry_shader4]]<br />
** [[GL_EXT_geometry_shader4]]<br />
** [[GL_EXT_transform_feedback]]<br />
** [[GL_NV_transform_feedback]]<br />
<br />
Sollten die Artikel hier im Wiki nicht ausreichen, kann ein Blick in die offizielle Dokumentation hilfreich sein:<br />
* [http://opengl.org/documentation/specs/version2.0/glspec20.pdf OpenGL 2.0 Specification] (Englisch)<br />
* [http://www.opengl.org/registry/doc/GLSLangSpec.Full.1.20.8.pdf OpenGL Shading Language Specification v1.20.8] (Englisch)<br />
* [http://opengl.org/registry/specs/EXT/gpu_shader4.txt EXT_gpu_shader4] (Englisch)<br />
* [http://opengl.org/registry/specs/ARB/geometry_shader4.txt ARB_geometry_shader4] (Englisch)<br />
* [http://opengl.org/registry/specs/EXT/geometry_shader4.txt EXT_geometry_shader4] (Englisch)<br />
* [http://opengl.org/registry/specs/EXT/transform_feedback.txt EXT_transform_feedback] (Englisch)<br />
* [http://opengl.org/registry/specs/NV/transform_feedback.txt NV_transform_feedback] (Englisch)<br />
* ([http://opengl.org/documentation/specs/ weitere Dokumentation], sowie die [http://opengl.org/registry/ Extension Registry])<br />
<br />
== Quellen ==<br />
[1] [http://www.nvidia.com/object/product_geforce_gtx_295_us.html NVIDIA GeForce GTX 295]<br /><br />
[2] [http://developer.nvidia.com/object/gpu_programming_guide.html NVIDIA GeForce 8 and 9 Series GPU Programming Guide], insbesondere Abschnitt 4.6</div>Igel457https://wiki.delphigl.com/index.php?title=Tutorial_MultiTexturing&diff=24612Tutorial MultiTexturing2010-01-16T19:36:41Z<p>Igel457: /* Einleitung */</p>
<hr />
<div>=Tutorial Multitexturing=<br />
==Einleitung==<br />
Mit der Markteinführung von NVidias „Riva TNT“ (TwiNTexel Engine) hat auch das Multitexturing im PC-Grafikkartenbereich Einzug gefunden, und wird seit einigen Jahren von allen neu entwickelten Grafikchips unterstützt. Beim Multitexturing können den einzelnen Textureinheiten der Grafikkarte unterschiedliche [[Textur]]en zugeordnet werden, die dann später in einem Durchgang auf ein [[Polygon]] tapeziert bzw. verknüpft werden. Vor der Einführung dieser Technik musste man das Polygon im ersten Durchgang mit Textur A rendern und in einem zweiten Durchgang [[Blending]] aktivieren und es mit Textur B zeichnen. Dadurch verdoppelte sich nicht nur die Anzahl der Polygone, sondern auch die Verknüpfungsmöglichkeiten des Blendings waren weit weniger nützlich als die beim Multitexturing.<br />
<br />
Die Anzahl der Textureinheiten (TMU = Textur Mapping Unit) gibt an, wie viele Texturen in einem Durchgang auf eine Textur gezeichnet werden können. Bei einer „GeForce4“ sind dies z.&nbsp;B. 4 und bei den „Kyro“-Karten von PowerVR sogar bis zu 8 (obwohl man eher selten 8 Texturstufen benötigt). Besitzt eine Grafikkarte nun weniger TMUs als man gleichzeitig Texturen auf ein Polygon zeichnen möchte, dann wird die Arbeit in mehreren Durchgängen erledigt. Ein Grafikchip der nur 2 TMUs besitzt, braucht also 3 Durchgänge um ein Polygon mit 6 Texturen zu zeichnen.<br />
<br />
Multitexturing ist heute besonders in Spielen ein unverzichtbares Mittel geworden. Dabei werden zwei Anwendungsmöglichkeiten häufig genutzt: Zum einen das [[Lightmap]], bei dem Schattenwurf und Lichteinfall auf ein Polygon vorberechnet und in einer separaten Textur abgelegt werden, sowie das [[Detailmapping|Detailtexturing]], bei dem die Basistextur mit einem Muster überzogen wird, das kleine Details simulieren soll.<br />
<br />
Im Falle des Beispielprogramms werden diese beiden Texturen mit Hilfe des Multitexturings mit der Basistextur verknüpft:<br />
<br />
<div align="center"><br />
{|{{Prettytable}}<br />
!Schritt1<br />
|[[Bild:Multitex01.jpg|framed|Basistextur]]<br />
| +<br />
|[[Bild:Multitex02.jpg|framed|Lightmap]]<br />
| =<br />
|[[Bild:Multitex04.jpg|framed|Zwischenergebnis]]<br />
|-<br />
!Schritt2<br />
|[[Bild:Multitex04.jpg|framed|Zwischenergebnis]]<br />
| +<br />
|[[Bild:Multitex03.jpg|framed|Detailtextur]]<br />
| =<br />
|[[Bild:Multitex05.jpg|framed|Endergebnis]]<br />
|-<br />
|}<br />
</div><br />
<br />
==Schritt 1 - Hardware auf Multitexturing-Fähigkeit prüfen==<br />
Bevor man das Multitexturing nutzen kann, sollte man natürlich erst einmal prüfen ob dies auch von der Hardware unterstützt wird. Es wird zwar kaum noch Grafikkarten geben, bei denen dies nicht der Fall ist, aber um sicherzugehen, ist dieser Schritt doch nötig.<br />
<br />
Dabei hat man zwei einfache Möglichkeiten. Entweder man prüft, ob die Erweiterung {{INLINE_CODE|[[GL_ARB_MULTITEXTURE]]}} von der Grafikkarte untersützt wird, oder man liest die Anzahl der TMUs mit dem Befehl {{INLINE_CODE|[[glGetIntegerv]]}} und dem Parameter {{INLINE_CODE|[[GL_MAX_TEXTURE_UNITS_ARB]]}} aus [06]. Ist dieser Wert kleiner als zwei, so wird das Multitexturing nicht unterstützt.<br />
<br />
<source lang="pascal">[01] procedure TForm1.GLInit;<br />
[02] var<br />
[03] TMUs : Integer;<br />
[04] begin<br />
[05] ActivateRenderingContext(FDC, FRC);<br />
[06] glGetIntegerv(GL_MAX_TEXTURE_UNITS_ARB, @TMUs);<br />
[07] if TMUs < 2 then<br />
[08] begin<br />
[09] ShowMessage('Sorry!Your card doesn''t support Multitexturing');<br />
[10] Close;<br />
[11] end;<br />
...<br />
[12] end;</source><br />
<br />
==Schritt 2 - Texturstufen festlegen==<br />
Hat man sich nun von den Multitexture-Fähigkeiten der Grafikkarte überzeugt, kann man endlich damit beginnen, die einzelnen Texturen ihren Texturstufen zuzuordnen. Auf die Texturstufen wird in OpenGL mit Hilfe der Konstanten {{INLINE_CODE|GL_TEXTURE0...GL_TEXTURE31}} zugegriffen.<br />
<br />
<source lang="pascal">[01] procedure DrawRoom;<br />
[02] begin<br />
...<br />
[03] glActiveTexture(GL_TEXTURE1);<br />
[04] if TSActive[0] then<br />
[05] begin<br />
[06] glEnable(GL_TEXTURE_2D);<br />
[07] Texture[2].Bind;<br />
[08] glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);<br />
[09] end<br />
[10] else<br />
[11] glDisable(GL_TEXTURE_2D);<br />
<br />
[12] glActiveTexture(GL_TEXTURE2);<br />
[13] if TSActive[1] then<br />
[14] begin<br />
[15] glEnable(GL_TEXTURE_2D);<br />
[16] Texture[4].Bind;<br />
[17] glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);<br />
[18] end<br />
[19] else<br />
[20] glDisable(GL_TEXTURE_2D);<br />
<br />
[21] glActiveTexture(GL_TEXTURE0);<br />
[22] glEnable(GL_TEXTURE_2D);<br />
[23] glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);</source><br />
<br />
Mit der Funktion {{INLINE_CODE|[[glActiveTexture]](target : Cardinal)}} wird die im Parameter {{INLINE_CODE|target}} angegebene Texturstufe aktiviert, Zeile [03], [12] und [21]. Von nun an beziehen sich alle Befehle, die etwas an einer Textur verändern (Binden von Texturen, Blending, Alphamasking, Veränderung der Texturmatrix, etc.) auf diese aktivierte Texturstufe, und zwar solange, bis auf ihr das Texturing deaktiviert wird oder die Texturstufe gewechselt wird.<br />
<br />
Um nun die Texturstufe zu aktiveren, muss wie gewohnt mit dem Befehl {{INLINE_CODE|[[glEnable]]}} und dem Parameter {{INLINE_CODE|[[GL_TEXTURE_2D]]}} das 2D-Texturing aktiviert werden. Dies muss für jede Texturstufe geschehen, die genutzt wird, Zeile [06], [15] und [22]. Möchte man eine Texturstufe ausschalten, so wählt man diese aus und nutzt {{INLINE_CODE|[[glDisable]]}} mit dem Parameter {{INLINE_CODE|GL_TEXTURE_2D}}, Zeile [11] und [20].<br />
<br />
Bevor nun die Polygone gezeichnet werden, muss für jede Texturstufe die Art der Verknüpfung mit den anderen Texturstufen festgelegt werden. Dies geschieht mit dem Befehl {{INLINE_CODE|[[glTexEnv]]i}}, der als Parameter das Ziel des Parameters (in unseren Falle {{INLINE_CODE|[[GL_TEXTURE_ENV]]}}, was bedeutet, das als Grundwerte die Ausgabewerte der vorherigen Texturstufe genutzt werden), den Parameter selbst (auch {{INLINE_CODE|GL_TEXTURE_ENV}}) und die Art der Verknüpfung erhält.<br />
<br />
Für die Basistextur wird dieser Parameter auf {{INLINE_CODE|[[GL_REPLACE]]}} gesetzt [23], alles was vor dieser Textur kam wird also überschrieben. Der Parameter {{INLINE_CODE|[[GL_MODULATE]]}} für die Lightmap [08] und die Detailtextur [17] geben an, das deren Farbwerte mit den vorherigen Werten multipliziert werden. Neben diesen Verknüpfungen gibt es noch etliche andere, die jedoch weniger oft, oder für andere Anwendungen wie z.&nbsp;B. BumpMapping verwendet werden.<br />
<br />
==Schritt 3 - Übergabe der Texturkoordinaten==<br />
Nachdem die Texturstufen nun vorbereitet wurden, müssen für diese noch die Texturkoordinaten festgelegt werden. Wurde dies vorher mit der Funktion {{INLINE_CODE|[[glTexCoord2f]](s,t : single)}} erledigt, so wird nun die an das Multitexturing angepasste Variante {{INLINE_CODE|[[glMultiTexCoord2f]](target : cardinal;s,t : single)}} genutzt. Im Parameter {{INLINE_CODE|target}} wird die Texturstufe gewählt und in {{INLINE_CODE|s}} bzw. {{INLINE_CODE|t}} wie gewohnt die Texturkoordinaten übergeben:<br />
<br />
<source lang="pascal">[01] glActiveTexture(GL_TEXTURE1);<br />
[02] Texture[6].Bind;<br />
<br />
[03] glActiveTexture(GL_TEXTURE0);<br />
[04] Texture[0].Bind;<br />
<br />
[05] glBegin(GL_QUADS);<br />
[06] glMultiTexCoord2f(GL_TEXTURE0, 0, 0);<br />
[07] glMultiTexCoord2f(GL_TEXTURE1, 0, 0);<br />
[08] glMultiTexCoord2f(GL_TEXTURE2, 0, 0);<br />
[09] glVertex3f(px, py, pz);<br />
[10] glMultiTexCoord2f(GL_TEXTURE0, 0, 2);<br />
[11] glMultiTexCoord2f(GL_TEXTURE1, 0, 1);<br />
[12] glMultiTexCoord2f(GL_TEXTURE2, 0, 8);<br />
[13] glVertex3f(px, py, pz + pLength);<br />
[14] glMultiTexCoord2f(GL_TEXTURE0, 2, 2);<br />
[15] glMultiTexCoord2f(GL_TEXTURE1, 1, 1);<br />
[16] glMultiTexCoord2f(GL_TEXTURE2, 8, 8);<br />
[17] glVertex3f(px + pWidth, py, pz + pLength);<br />
[18] glMultiTexCoord2f(GL_TEXTURE0, 2, 0);<br />
[19] glMultiTexCoord2f(GL_TEXTURE1, 1, 0);<br />
[20] glMultiTexCoord2f(GL_TEXTURE2, 8, 0);<br />
[21] glVertex3f(px + pWidth, py, pz);<br />
[22] glEnd;<br />
<br />
[23] glActiveTexture(GL_TEXTURE2);<br />
[24] if TSActive[1] then<br />
[25] begin<br />
[26] glEnable(GL_TEXTURE_2D);<br />
[27] Texture[4].Bind;<br />
[28] glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);<br />
[29] end<br />
[30] else<br />
[31] glDisable(GL_TEXTURE_2D);<br />
<br />
[32] glActiveTexture(GL_TEXTURE0);<br />
[33] glEnable(GL_TEXTURE_2D);<br />
[34] glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);</source><br />
<br />
Wie in dieser, aus dem Beispielprogramm entnommenen Prozedur sichtbar, werden vor dem Zeichnen des Quads zuerst die Texturen an die einzelnen Texturstufen gebunden. In [01] und [02] wird die Lightmap an die Texturstufe 1 gebunden und in [03] und [04] wird die Basistextur für diesen Quad an Texturstufe 0 gebunden. Da die an Texturstufe 2 gebundene Detailtextur bereits vorher definiert wurde und sich für diesen Quad nicht ändert, muss diese hier nicht gebunden werden.<br />
<br />
Danach werden nur noch die Texturkoordinaten an jede genutzte Texturstufe für jeden Eckpunkt des Polygons übergeben um es mit den an die Stufen gebundenen Texturen zu überziehen.<br />
<br />
==Das Beispielprogramm==<br />
Das von mir zu diesem Tutorial geschriebene Beispielprogramm benutzt 3 Texturstufen. Texturstufe 0 für die Basistextur, Texturstufe 1 für die Lightmap und Texturstufe 2 für die Detailtextur. Die Texturstufen 1 und 2 können mit den entsprechenden Ziffern auf der Tastatur aktiviert bzw. deaktiviert werden. Mit der Maus wird der Blickwinkel verändert und mit Cursor Hoch/Runter kann man sich bewegen.<br />
<br />
Die Lightmaps wurden von mir in einem herkömmlichen Zeichenprogramm erstellt, es steckt also kein Radiosity-Renderer dahinter.<br />
<br />
Das Programm wurde unter Delphi 6.0 geschrieben, sollte jedoch ab Delphi 4.0 kompilierbar sein.<br />
Das Programm läuft natürlich nur auf Grafikkarten, die Multitexturing in der Hardware unterstützen. Dies ist jedoch seit der Riva TNT bei allen Karten der Fall.<br />
<br />
Zu guter Letzt noch ein Screenshot aus dem Beispielprogramm:<br />
<br />
[[Bild:Multitex06.jpg|center]]<br />
<br />
Autor: [[Benutzer:Sascha_Willems|Sascha Willems]]<br />
<br />
==Download==<br />
[http://www.delphigl.de/files/multitex.zip Das Multitexturingdemo (inklusive Quellcode) herunterladen]<br />
<br />
{{TUTORIAL_NAVIGATION|[[Tutorial Bumpmaps mit Blender]]|[[Tutorial StencilSpiegel]]}}<br />
<br />
[[Kategorie:Tutorial|Multitexturing]]</div>Igel457https://wiki.delphigl.com/index.php?title=Datei:AudorraLogo.png&diff=24537Datei:AudorraLogo.png2010-01-10T10:01:34Z<p>Igel457: Audorra Logo</p>
<hr />
<div>Audorra Logo</div>Igel457https://wiki.delphigl.com/index.php?title=DGL_Projekte&diff=24536DGL Projekte2010-01-10T10:01:04Z<p>Igel457: /* Bibliotheken */</p>
<hr />
<div>=DGL Projects Corner=<br />
<br />
<div align="center"><br />
Willkommen in der '''[[DelphiGL|DGL]] Projekte Ecke'''!<br />
[[Bild:ProjekteEcke.jpg|center]]<br />
Auf dieser Seite findet ihr Projekte von '''Mitgliedern von [http://DelphiGL.com DelphiGL.com]''', welche als '''"für die Benutzung freigegeben"''' gewertet wurden.<br />
</div><br />
<br />
{{Hinweis|'''Rechtliches:''' Die Software wurde von Mitgliedern von DelphiGL.com in ihrer Freizeit geschrieben. Es kann deshalb für die angebotene Software keinerlei Garantie gegeben werden. Unsere Mitglieder geben allerdings ihr Bestes damit die hier angebotene Software euch Spass ohne Reue beschehrt. Aus rechtlichen Gründen gilt wie bei allen Angeboten von DelphiGL.com: Download und Nutzung auf eigene Gefahr.}}<br />
<br />
Falls ihr selbst Mitglied von DelphiGL.com seid und ein Projekt habt welches ihr als "benutzbar" bezeichnet (und idealerweise schon bei DelphiGL.com in der Projekte-Sektion vorgestellt habt), dann könnt ihr es hier veröffentlichen.<br />
<br />
==Auszeichnungen==<br />
Einige Projekte wurden mit einem oder mehreren [[DGL_Award]]s ausgezeichnet. Mit dem DGL Award ehrt die DelphiGL Community vorbildliche Projekte und Engagement in der Community.<br />
<br />
==Spiele==<br />
Viele, um nicht zu sagen die meisten, DGL-Mitglieder widmen sich dem Thema Spiele. Was dabei an respektablen Ergebnissen entstanden ist könnt ihr in dieser Rubrik sehen.<br />
<br />
===3D Shooter und Labyrinth Spiele===<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="30%"|Name<br />
!width="50%"|Beschreibung<br />
!width="20%"|Macher<br />
|-<br />
|''Noch keine Programme''<br />
|Hast du ein fertiges Projekt, was du bei DGL vorgestellt hast? Dann nichts wie her damit!<br />
|''Hier könnte dein Name stehen''<br />
|}<br />
<br />
<br />
===Action===<br />
<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="30%"|Name<br />
!width="50%"|Beschreibung<br />
!width="20%"|Macher<br />
|-<br />
|[[Bild:Thumb_asteroids.jpg|framed|center|Link: '''[[Projekt_Asteroids|Asteroids]]''']]<br />
<br />
|Asteroids ist ein Remake des alten Klassikers "Comet". Ziel des Spiels ist es so viel Asteroiden wie möglich zu zerstören um dadurch möglichst viele Punkte zusammeln, ohne dabei von den herum fliegenden Trümmern getroffen zu werden. <br />
<br />
An einem Spiel können bis zu 4 Spieler gleichzeitig teilnehmen.<br />
<br />
|align="center"|[[Benutzer:Magellan|Magellan]]<br />
|-<br />
|[[Bild:PE2.jpg|thumb|center|168px|Link: '''[http://ziz.delphigl.com/downloads.php Perniciei Effector]''']]<br />
|Ein typischer Weltraum Shooter mit 2D Steuerung aber 3D Grafik. Ziel des Spiels ist es in der Highscore möglichst hoch zu klettern. Dies erreicht man durch die passende Auswahl des Raumschiffes zu beginn und die vielen Items, die die Gegner verlieren.<br />
|align="center"|[[Benutzer:Ziz|Ziz]]<br />
|-<br />
|-<br />
|[[Bild:Thumb_napalmbomber.jpg|framed|center|Link: '''[http://www.saschawillems.de/?page_id=90 Napalmbomber3D Projektseite]''']]<br />
<br />
|NapalmBomber3D ist wie der Titel schon vermuten lässt ein 3D-Klon des bekannten Bombermanspielprinzips.Dieses hochbrisante und fesselnde Spiel besticht durch seine tolle Grafik die natürlich mittels OpenGL realisiert wurde.<br />
<br />
Zusätzlich zum Spiel gibt es natürlich auch noch einen Karteneditor mit dem sich in Windeseile eigenen Maps erstellen lassen.<br />
<br />
Neben inzwischen über 50.000 Downloads (im Schnitt sind es immernoch > 400 pro Monat) und diversen sehr guten Reviews hat es das Spiel sogar auf die PC-Action Ausgabe 07/2004 geschafft.<br />
<br />
''([[Tutorial#Spieletutorials_und_Softwareentwicklung|Hier]] findet ihr 2 Tutorials mit denen ihr dieses tolle Spielchen nachbauen könnt.)''<br />
|align="center"|[[Benutzer:Sascha Willems|Sascha Willems]]<br />
|-<br />
|}<br />
<br />
===Brett-, Denk- und Kartenspiele===<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="30%"|Name<br />
!width="50%"|Beschreibung<br />
!width="20%"|Macher<br />
|-<br />
|[[Bild:Projekt_Hex_Change_Screenshot.jpg|thumb|center|168px|Link: '''[[Projekt_Hex-Change|Hex-Change]]''']]<br />
|2 Spieler konkurrieren um die Felder auf einer Hexagon Fläche. Das Spiel enthält einen Einzelspieler- (gegen KI) und einen "Hot-Seat"-Mehrspielermodus.<br />
|align="center"|[[Benutzer:H.A.S.E.|H.A.S.E.]]<br />
|-<br />
|[[Bild:Balance.jpg|thumb|center|168px|Link: '''[[Projekt_Balance|Balance]]''']]<br />
|Durch geschicktes erhöhen von Ladungen werden Kettenreaktionen ausgelöst mithilfe derer man das gesammte Spielfeld erobert. Das Spiel ist Mehrsprachig (Deutsch/Englisch) und enthält einen Einzelspieler und zwei Multiplayer-Modi (HotSeat u. LAN).<br />
|align="center"|[[Benutzer:Flash|Kevin Fleischer aka Flash]]<br />
|}<br />
<br />
===Reaktions- und Geschicklichkeitsspiele===<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="30%"|Name<br />
!width="50%"|Beschreibung<br />
!width="20%"|Macher<br />
|-<br />
|[[Bild:Thumb_confusingball.jpg|framed|center|Link: '''[[Projekt_ConfusingBall|Confusing Ball]]''']]<br />
<br />
|In "Confusing Ball" steuert man einen Ball durch ein 3D Labyrinth, in dem die Gesetze der Physik neu definiert werden müssen. Um ins Ziel eines Levels zu gelangen benötigt man einen gewissen Orientierungssinn und ein gutes räumliches Vorstellungsvermögen.<br />
Nebenher muss man ja auch noch die Münzen einsammeln, und den Bomben aus dem Weg gehen. Frei verschiebbare Steine erhöhen den Schwierigkeitsgrad. <br />
<br />
|align="center"|[[Benutzer:MatReno|MatReno]]<br />
|-<br />
|[[Bild:Thumb_beanmachine.jpg|framed|center|Link: '''[http://www.saschawillems.de/?page_id=86 Bean Machine Projektseite]''']]<br />
<br />
|"Bean Machine" basiert auf dem Sega MegaDrive-Klassiker "Dr.Robotnik's Mean Bean Machine" (ausserhalb Europas auch als "Puyo Puyo" bekannt) und spielt sich somit ähnlich wie Tetris.<br />
Auch dieses Klassikerremake spielt sich fast genauso wie die Vorlage, allerdings gibt es dank OpenGL recht aufwendige Grafiken, natürlich gewohnt komplett in 3D.<br />
<br />
|align="center"|[[Benutzer:Sascha Willems|Sascha Willems]]<br />
|-<br />
|[[Bild:Heiliger Damm.jpg|thumb|center|168px|Link: '''[[Projekt Heiliger_Damm|Heiliger Damm]]''']]<br />
<br />
|"Heiliger Damm" ist ein Geschicklichkeitsspiel passend zum G8-Treffen 2007 in Heiligendamm. Der Spieler übernimmt die Aufgabe, den "heiligen Damm" (eine Oase in der Wüste) vor den Globalisierungsgegner zu schützen. Dies erreicht er, indem er mit der Maus Linien (Zäune) zieht.<br />
<br />
|align="center"|[[Benutzer:GTA-Place|Fabian Gärtner / GTA-Place]]<br />
|}<br />
<br />
===Simulationen===<br />
====Wirtschaftssimulationen/Manager====<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="30%"|Name<br />
!width="50%"|Beschreibung<br />
!width="20%"|Macher<br />
|-<br />
|[[Bild:PBM2_Kdr.jpg|thumb|center|168px|Link: '''[[Projekt_PBM2|PBall Manager 2]]''']]<br />
<br />
|Der PBall Manager 2 ist ein Sportmanager in welchem man in die Rolle des Trainers/Managers eines von 96 PBall Teams aus ganz Europa schlüpft. PBall selbst ist eine fiktive Sportart welche ähnlich Fußball ist.<br />
<br />
Im Spiel hat man die Kontrolle über alle Abläufe: Von der Aufstellung über Spielerkäufe bis hin zum Stadionausbau liegt alles in der Hand des Spielers. Doch auch die eigene Karriere kann voran getrieben werden indem man zu anderen Clubs wechselt.<br />
<br />
Das Ziel aller PBaller ist der Liga-Meister-Pokal indem die besten Clubs der 4 Europäischen Ligen um den Titel spielen.<br />
<br />
|align="center"|[[Benutzer:Flash|Kevin Fleischer alias Flash]]<br />
|-<br />
|}<br />
<br />
====Flugsimulationen====<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="30%"|Name<br />
!width="50%"|Beschreibung<br />
!width="20%"|Macher<br />
|-<br />
|''Noch keine Programme''<br />
|Hast du ein fertiges Projekt, was du bei DGL vorgestellt hast? Dann nichts wie her damit!<br />
|''Hier könnte dein Name stehen''<br />
|}<br />
<br />
====Rennsimulationen====<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="30%"|Name<br />
!width="50%"|Beschreibung<br />
!width="20%"|Macher<br />
|-<br />
|''Noch keine Programme''<br />
|Hast du ein fertiges Projekt, was du bei DGL vorgestellt hast? Dann nichts wie her damit!<br />
|''Hier könnte dein Name stehen''<br />
|}<br />
<br />
<br />
===Strategie===<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="30%"|Name<br />
!width="50%"|Beschreibung<br />
!width="20%"|Macher<br />
|-<br />
|[[Bild:planeto7.jpg|thumb|center|168px|Link: '''[http://nilsbeckmann.de/ Planeto]''']]<br />
<br />
|Planeto ist ein rundenbasiertes Science-Fiction Strategiespiel. Du landest auf einem unbekannten Planeten. Deine Aufgabe ist es, diesen zu erkunden, Rohstoffe zu sichern und die militärische Vorherrschaft zu behaupten. Spieler können gegen Computerspieler antreten oder untereinander simultan übers Netzwerk und Internet. Zur Auswahl stehen mehr als 400 Einheiten, Forschungen und Aufwertungen.<br />
<br />
|align="center"|[[Benutzer:Nils Beckmann|Nils Beckmann]]<br />
|-<br />
|-<br />
|[[Bild:projektw_wiki_projektecke.jpg|thumb|center|168px|Link: '''[http://www.saschawillems.de/?page_id=114 Projekt "W"]''']]<br />
<br />
|Projekt "W" ist ein runden-basierendes Strategiespiel, dessen Ziel die Erlangung der Weltherrschaft ist. Der Spieler kann sich für eine der fünf neuen großen Nationen entscheiden, und muss diese dann zum Sieg über alle anderen Nationen führen.<br />
<br />
Dazu muss man seine Regionen verwalten, dort Gebäude bauen und auf wichtige Faktoren achten. Man baut zudem militärische Einheiten und gliedert diese in Divisionen um damit das eigene Territorium zu verteidigen, bzw. gegnerische Regionen einzunehmen. Zusätzlich kann man Technologien erforschen, die u.A. neue Gebäude und Militäreinheiten freischalten. Auch Spionage und Sabotage spielen eine wichtige Rolle, so kann man z.B. mit Hilfe eines eingeschleusten Spions an wichtige Informationen gelangen oder die Stromversorgung einer Region lahmlegen.<br />
<br />
Neben dem Einzelspielermodus, in dem man gegen die KI bestehen muss, gibt es auch einen Hotseatmodus, bei dem mehrere Spieler an einem Rechner gegeneinander antreten können. Präsentiert wirds wie gewohnt in schicker 3D-Grafik, und auf passender Hardware wird das Ganze noch mit Shadern garniert.<br />
<br />
|align="center"|[[Benutzer:Sascha Willems|Sascha Willems]]<br />
|-<br />
|}<br />
<br />
==Effekte==<br />
Für den optischen Anspruch eines Spiels haben Spezialeffekte große Bedeutung. Was beim einfachen Feuer beim Abschießen einer virtuellen Kugel anfängt, kann sich über plastischen Nebel bis zu imposanten, realistischen Blitzen ziehen.<br />
<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="30%"|Name<br />
!width="50%"|Beschreibung<br />
!width="20%"|Macher<br />
|-<br />
|[[Bild:Pic6.jpg|thumb|center|168px|Link: '''[http://sourceforge.net/projects/fireblade/ FireBlade]''']]<br />
<imagemap><br />
Image:Project_OTY08.png|center<br />
rect 0 0 100 40 [[DGL_Award#Best_Project_Award]]<br />
desc none<br />
</imagemap><br />
|FireBlade ist ein flexibles und leistungsstarkes Partikelsystem auf OpenGL-Basis. Sie ist sehr effizient im Bezug auf Tiefensortierung, Speichermanagement, Ansprechbarkeit und Erweiterbarkeit, und lässt sich durch die Art und Weise, wie Effekte beschrieben werden, sehr gut vor allem in größere Projekte einbringen. Dabei eignet sie sich sowohl für 2D als auch für 3D-Anwendungen. Highlights sind zum Beispiel die integrierte, problemlos erweiterbare Kollisionsabfrage, ein breites, ebenfalls erweiterbares Emitter-Set und ein einfacher, aber sehr effizienter Manager, der die Performance gerade für viele Effekte enorm steigern kann. Alle Eigenschaften, selbst die Textur- und Raumkoordinaten der einzelnen Billboard-Vertices sind manipulierbar.<br />
|align="center"|[[Benutzer:Kyro|Sebastian Wagner alias Kyro]]<br />
|}<br />
<br />
==Bibliotheken==<br />
Diese Rubrik enthält Bibliotheken, die die Grafikprogrammierung vereinfachen und dem Spiele-/Anwendungsentwickler helfend unter die Arme greifen.<br />
<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="30%"|Name<br />
!width="50%"|Beschreibung<br />
!width="20%"|Macher<br />
|-<br />
|[[Bild:AndorraLogo.png|thumb|center|168px|Link: '''[http://andorra.sourceforge.net/ Andorra 2D]''']]<br />
<imagemap><br />
Image:Useful_OTY08.png|center<br />
rect 0 0 100 40 [[DGL_Award#Most_Useful_Project_Award]]<br />
desc none<br />
</imagemap><br />
|Andorra 2D ist eine flexible Lösung um 2D-Spiele oder Anwendungen zu entwickeln. Durch den durchdachten Aufbau des Engine-Kerns ist Andorra 2D komplett von der Grafikschnittstelle und dem Betriebssystem getrennt. Eine Anbindung an OpenGL und Direct3D, sowie Unterstützung für Windows und Linux 32/64 Bit sind gegeben. Andorra 2D ist einfach zu verwenden und erlaubt es auch Einsteigern schnell erste Ergebnisse auf den Bildschirm auszugeben. Andererseits wendet es sich mit Features wie Shadern auch an fortgeschrittene Benutzer.<br />
|align="center"|[[Benutzer:Igel457|Andreas Stöckel alias Igel457]]<br />
|}<br />
<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="30%"|Name<br />
!width="50%"|Beschreibung<br />
!width="20%"|Macher<br />
|-<br />
|[[Bild:AudorraLogo.png|thumb|center|168px|Link: '''[http://audorra.sourceforge.net/ Audorra]''']]<br />
|Audorra ist eine Bibliothek zur Wiedergabe von 3D-Positionalem Audio und vor allem für den Einsatz in Spielen gedacht. Durch den modularen Aufbau kann es - die richtigen Audio-Backends ("Driver") und Decoder vorrausgesetzt - auf fast jeder Plattform eingesetzt werden. Der verwendete 3D-Audio-Softwarerenderer garantiert gleiche Ergbnisse und unterstützt Effekte wie Phasenverschiebung und Dopplereffekt. Mehr über das Projekt gibt es auch im [http://www.delphigl.com/forum/viewtopic.php?f=13&t=8819 Forumsthread] zu erfahren.<br />
|align="center"|[[Benutzer:Igel457|Andreas Stöckel alias Igel457]]<br />
|}<br />
<br />
==Tools==<br />
Diese Rubrik enthält Werkzeuge, die man benutzt um Inhalte zu erstellen.<br />
<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="30%"|Name<br />
!width="50%"|Beschreibung<br />
!width="20%"|Macher<br />
|-<br />
|[[Bild:Beei.png|thumb|center|168px|Link: '''[http://projects.blender.org/projects/beei/ Blender External Engine Interface]''']]<br />
|BEEI steht für Blender External Engine Interface und dient als Schnittstelle für externe Renderer und Gameengines.<br />
Der externe Renderer oder Gameengine muss in Form einer .dll oder .so Datei vorliegen und die von der Schnittstelle erwarteten Funktionen bieten. Das Plugin wird dann von Blender geladen und befindet sich dann im Speicher von Blender.<br />
Nun kann man z.B. mit OpenGL Renderbefehle ausführen und diese werden dann im Space von Blender dargestellt.<br />
Man hat zugriff auf die Blender Daten und kann sie lesen oder schreiben, wobei das Lesen die sichere Art ist und zum schreiben Python und BEEI Boardmittel verwendet werden sollten. Das Testplugin ist ein frühes Framework von Karmarama.<br />
Es zeigt die Blenderdaten wie der interne Blenderrenderer mit der ausnahme, dass ein Entity mit dem Namen Glow als Pfeil dargestellt wird. BEEI bietet neben der schnittstelle noch zugriff auf die Blender UI elemente, um eigene Toolfenster zu erstellen. Der tiefere Sinn liegt im WYSIWYG und erlaubt ein wesentlich leichteres erstellen von Content aller Art.<br />
|align="center"|Thomas Kunze<br />
|}</div>Igel457https://wiki.delphigl.com/index.php?title=alSource&diff=24333alSource2009-11-24T14:48:36Z<p>Igel457: /* AL_REFERENCE_DISTANCE */</p>
<hr />
<div>{{Unvollständig|Die Beschreibung zu den Auswirkungen des Funktionsparameters ''param'' muss noch ergänzt werden. Als Grundlage kann die [http://www.openal.org/documentation.html Open AL-Dokumentation] dienen.}}<br />
= alSource =<br />
<br />
<br />
<br />
== Name ==<br />
'''alSource''' - Setzt Eigenschaften eines Source-Objektes.<br />
<br />
<br />
<br />
== Delphi-Spezifikation ==<br />
procedure '''alSourcef'''(''source'': TALuint; ''param'': TALenum; ''value'': TALfloat);<br />
procedure '''alSource3f'''(''source'': TALuint; ''param'': TALenum; ''v1'': TALfloat; ''v2'': TALfloat; ''v3'': TALfloat);<br />
procedure '''alSourcefv'''(''source'': TALuint; ''param'': TALenum; ''values'': PALfloat);<br />
procedure '''alSourcei'''(''source'': TALuint; ''param'': TALenum; ''value'': TALint);<br />
procedure '''alSource3i'''(''source'': TALuint; ''param'': TALenum; ''v1'': TALint; ''v2'': TALint; ''v3'': TALint);<br />
procedure '''alSourceiv'''(''source'': TALuint; ''param'': TALenum; ''values'': PALint);<br />
<br />
<br />
<br />
== Parameter ==<br />
<br />
{| border="1" rules="all"<br />
! ''source'' <br />
| Name des Source-Objektes, dessen Eigenschaft geändert werden soll<br />
|-<br />
! ''param'' <br />
| Symbolische Konstante, welche die zu setzende Eigenschaft angibt<br />
|-<br />
! ''value'' <br />
| TALfloat-/ TALint-Wert, der gesetzt werden soll (nur bei '''alSourcef''' bzw. '''alSourcei''')<br />
|-<br />
! ''values'' <br />
| Zeiger auf einen TALfloat-/ TALint-Vektor, welcher die zu setzenden Werte enthält (nur bei '''alSourcefv''' und '''alSourceiv''')<br />
|-<br />
! ''v1, v2, v3'' <br />
| TALfloat-/ TALint-Werte, welche die zu setzenden Werte angeben (nur bei '''alSource3f''' und '''alSource3i''')<br />
|}<br />
<br />
<br />
<br />
== Beschreibung == <br />
Die Funktion '''alSource''' bzw. ihre Varianten für verschiedene Wertargumente setzen Eigenschaften eines Source-Objektes der [[OpenAL]]. Welche Eigenschaft gesetzt wird, hängt vom Wert des Parameters ''param'' ab.<br />
<br />
Folgende Werte sind für ''param'' zulässig:<br />
=== AL_BUFFER ===<br />
: Legt den aktuellen Puffer fest und macht ihn zum ersten Eintrag in der Pufferwarteschlange des Source-Objektes. Der Vorgabewert ist '''AL_NONE''', zulässige Werte sind alle gültigen Puffernamen (siehe dazu auch [[alIsBuffer]]). Wird '''alSource''' mit dem Parameter '''AL_BUFFER''' auf ein Source-Objekt im Zustand '''AL_INITIAL''' oder '''AL_STOPPED''' angewendet, so wird die gesamte Pufferwarteschlange geleert und der angegebene Puffer an das Source-Objekt angehangen.<br />
<br />
: Für ein Source-Objekt im Zustand '''AL_PLAYING''' oder '''AL_PAUSED''' wird der Versuch, mit '''AL_BUFFER''' einen Wert zu setzen, den Fehlerstatus '''AL_INVALID_OPERATION''' setzen. '''AL_BUFFER''' kann nur auf Source-Objekte im Zustand '''AL_STOPPED''' oder '''AL_INITIAL''' angewendet werden. Die Angabe eines ungültigen Puffernamens, sei es weil dieser Puffer nicht existiert oder nicht an das Source-Objekt angehängt werden kann, setzt den Fehlerstatus '''AL_INVALID_VALUE''', während die Angabe eines ungültigen Source-Objektes den Fehlerstatus '''AL_INVALID_NAME''' zur Folge hat.<br />
<br />
: '''AL_NONE''' ('''nil''' oder 0) ist ein gültiger Puffername. Der Aufruf alSourcei(sourceName, AL_BUFFER, AL_NONE) ist eine zulässige Möglichkeit, die aktuelle Pufferwarteschlange eines Source-Objektes freizugeben, egal ob die Pufferwarteschlange nur einen Eintrag (den aktuellen Puffer) oder mehrer hat. Jedoch verursacht der Funktionsaufruf alSourcei(sourceName, AL_BUFFER, AL_NONE) immer noch einen '''AL_INVALID_OPERATION'''-Fehlerstatus für ein im Zustand '''AL_PLAYING''' oder '''AL_PAUSED''' befindliches Source-Objekt und kann folgerichtig nicht genutzt werden, um ein Source-Objekt anzuhalten (siehe dazu [[alSourceStop]]) oder stummzuschalten. Der Paramater '''AL_BUFFER''' ist nur für die Funktionsvarianten '''alSourcei''' und '''alSourceiv''' zugelassen.<br />
<br />
=== AL_BYTE_OFFEST ===<br />
: Legt die Abpspielposition, ausgedrückt in Bytes, fest. Für Source-Objekte im Zustand '''AL_LOOPING''' wird dieser Wert wieder auf null zurückspringen, sobald die Wiedergabe wieder von vorn beginnt. Im Falle eines komprimierten Audioformates kann es sein, dass dieser Wert nur einen genäherten Wert innerhalb der komprimierten Daten angibt. Wird das Offset für ein Source-Objekt gesetzt, welches gerade Audiodaten abspielt, springt die Wiedergabe zur neuen Position, es sei denn der angegebene Wert ist außerhalb des zulässigen Bereichs, wodurch ein '''AL_INVALID_VALUE'''-Fehler generiert wird. Falls das Source-Objekt gerade keine Audiodaten abspielt, wird die Offsetänderung beim nächsten zugehörigen Aufruf von [[alSourcePlay]] durchgeführt. Ein Aufruf von [[alSourceStop]], [[alSourceRewind]] oder ein zweiter Aufruf von [[alSourcePlay]] setzt das Offset zurück auf den Anfang des Puffers. Die Position ist relativ zum Anfang aller dem Source-Objekt angehängten Puffer, und jeder Puffer, der beim Setzen des Offsets traversiert wird, wird als verarbeitet (siehe [[alGetSource]] mit Token [[alGetSource#AL_BUFFERS_PROCESSED|AL_BUFFERS_PROCESSED]]) markiert. Zulässige Werte sind Werte größer oder gleich null, ein Vorgabewert ist nicht festgelegt. '''AL_BYTE_OFFSET''' ist nur für die Funktionsvarianten '''alSourcef''', '''alSourcefv''', '''alSourcei''' und '''alSourceiv''' zulässig.<br />
<br />
=== AL_CONE_INNER_ANGLE ===<br />
: (unvollständig)<br />
<br />
=== AL_CONE_OUTER_ANGLE ===<br />
: (unvollständig)<br />
<br />
=== AL_CONE_OUTER_GAIN ===<br />
: (unvollständig)<br />
<br />
=== AL_DIRECTION ===<br />
: Legt die Ausrichtung eines Source-Objektes fest. Falls der '''AL_DIRECTION'''-Wert ungleich dem Nullvektor ist, so handelt es sich um ein gerichtetes Source-Objekt. Die Geräuschemission wird als symmetrisch um den Richtungsvektor herum angenommen (Zylindersymmetrie). Der Nullvektor ist der Vorgabewert, wodurch angegeben wird, dass das Source-Objekt nicht gerichtet ist. Das Setzen eines vom Nullvektor verschiedenen, dreidimensionalen Vektors macht aus dem Source-Objekt ein gerichtetes Objekt; das Setzen des Nullvektors für ein gerichtetes Source-Objekt macht es zu einem ungerichteten Source-Objekt. Zulässig sind alle Werte außer [[NaN]]. Der Parameter '''AL_DIRECTION''' ist nur für die Funktionsvarianten '''alSourcefv''', '''alSource3f''', '''alSourceiv''' und '''alSource3i''' zulässig.<br />
<br />
=== AL_GAIN ===<br />
: Legt den skalaren Amplitudenmultiplikator für das Source-Objekt fest. Der Vorgabewert 1.0 bedeutet, dass die Geräusche ungedämpft sind. Ein Wert von 0.5 ist äquivalent zu einer Abschwächung von 6 dB. Der Wert null entspricht Stille. Die Implementierung ist dafür verantwortlich, artefaktfreie (d.h. klickgeräuschfreie) Änderungen des Wertes zu ermöglichen und kann daher die tatsächliche Änderung des Wertes innerhalb gewisser, akzeptabler Grenzen verzögern. Werte größer als eins sind zwar zulässig, jedoch steht es der Implementierung frei, Werte größer als 1,0 auf 1,0 herunterzuregeln, um einen möglichen Überlauf zu vermeiden. '''AL_GAIN''' ist nur für die Funktionsvarianten '''alSourcef''' und '''alSourcefv''' zulässig.<br />
<br />
=== AL_LOOPING ===<br />
: Legt fest, ob das Source-Objekt nicht in den Zustand '''AL_STOPPED''' wechselt, sobald es das Ende des letzten Puffers in der Pufferwarteschlange erreicht hat. In diesem Fall ist der Wert '''AL_TRUE''' zu setzen, andernfalls '''AL_FALSE'''. Der Vorgabewert für '''AL_LOOPING''' ist '''AL_FALSE'''. Ist das '''AL_LOOPING'''-Flag auf '''AL_TRUE''' gesetzt, so wechselt das Source-Objekt beim Erreichen des Endes der Pufferwarteschlange sofort wieder in den Zustand '''AL_INITIAL''' und danach in den Zustand '''AL_PLAYING''', um die Audiodaten in den zugehörigen Puffern erneut abzuspielen. Das '''AL_LOOPING'''-Flag für ein Source-Objekt kann in jedem Ausführungszustand, besonders auch im Zustand '''AL_PLAYING''', geändert werden. Zulässige Werte sind '''AL_TRUE''' und '''AL_FALSE'''. Der Paramater '''AL_LOOPING''' ist nur für die Funktionsvarianten '''alSourcei''' und '''alSourceiv''' als Paramater zugelassen.<br />
<br />
=== AL_MAX_DISTANCE ===<br />
: (unvollständig)<br />
<br />
=== AL_MAX_GAIN ===<br />
: Setzt den maximalen, erlaubten '''AL_GAIN'''-Wert für das Source-Objekt. Der Vorgabewert ist 1.0, zulässig sind alle Gleitkommawerte aus dem Intervall von 0,0 bis 1,0. Am Ende der Varabrebitung verschiedener Abschwächungs- oder Verstärkungsfaktoren wie der entfernungsbasierten Abschwächung und dem '''AL_GAIN'''-Wert des Source-Objektes wird der berechnete Effektivwert mit dem '''AL_MAX_GAIN'''-Wert verglichen. Falls der berechnete Wert größer ist als der '''AL_MAX_GAIN'''-Wert, dann wird der '''AL_MAX_GAIN'''-Wert angewendet. Dies geschieht jedoch, bevor der '''AL_GAIN'''-Wert des Listener-Objektes in Betracht gezogen wird. Wenn das Produkt aus '''AL_MAX_GAIN''' und dem '''AL_GAIN'''-Wert des Listener-Objektes immer noch den maximalen Wert, welchen die Implementierung handhaben kann, überschreitet, so steht es der Implementierung frei, den Wert zu reduzieren. Falls für '''AL_MAX_GAIN''' der Wert null gesetzt wird, so ist das Source-Objekt quasi stummgeschalten. Die vorgesehene Art, ein Source-Objekt stummzuschalten, ist jedoch, den '''AL_GAIN'''-Wert auf null zu setzen. Der Parameter '''AL_MAX_GAIN''' ist nur für die Funktionsvarianten '''alSourcef''' und '''alSourcefv''' zulässig.<br />
<br />
=== AL_MIN_GAIN ===<br />
: Legt den minimalen '''AL_GAIN'''-Wert fest, welcher für das Source-Objekt immer gewährleistet sein soll. Der Vorgabewert ist 0.0, zulässig sind alle Werte aus dem Intervall von 0,0 bis 1,0. Am Ende der Verarbeitung verschiedener Abschwächungsfaktoren wie der entfernungsbasierten Abschwächung und dem '''AL_GAIN'''-Wertes des Source-Objektes wird der berechnete Effektivwert mit dem '''AL_MIN_GAIN'''-Wert verglichen. Falls der berechnete Wert kleiner ist als '''AL_MIN_GAIN''', so wird der Wert von '''AL_MIN_GAIN''' angewendet. Dies passiert jedoch, bevor der '''AL_GAIN'''-Wert des Listener-Objektes angewendet wird. Wenn der für '''AL_MIN_GAIN''' gesetzte Wert null ist, so wird keine Korrektur vorgenommen. Der Parameter '''AL_MIN_GAIN''' ist nur für die Funktionsvarianten '''alSourcef''' und '''alSourcefv''' zugelassen.<br />
<br />
=== AL_PITCH ===<br />
: Setzt die Verschiebung der Tonhöhe/ Frequenz des Source-Objektes. Ein Wert von 1,0 entspricht der Identität (d.h. keine Verschiebung), dies ist auch der Vorgabewert. Jede Reduzierung des Wertes um 50% entspricht einer Verschiebung um 12 Halbtöne bzw. eine Oktave nach unten. Jede Verdopplung des Wertes entspricht einer Verschiebung von 12 Halbtönen bzw. einer Oktave nach oben. Null ist kein zulässiger Wert, alle Gleitkommawerte größer als null sind erlaubt. Jede Implementierung kann die '''AL_PITCH'''-Werte aber entsprechend ihrer eigenen Limitationen beschränken. '''AL_PITCH''' ist nur für die Funktionsvarianten '''alSourcef''' und '''alSourcefv''' als Parameter zugelassen.<br />
<br />
=== AL_POSITION ===<br />
: Setzt die aktuelle Position des Source-Objektes im Weltkoordinatensystem. Der Standardwert ist (0.0, 0.0, 0.0). '''AL_POSITION''' darf ''nicht'' in '''alSourcei''' oder '''alSourcef''' benutzt werden sondern nur in den Funktionsvarianten für mehrere Wertargumente, also '''alSource3f''', '''alSource3i''', '''alSourcefv''' oder '''alSourceiv'''. Erlaubt ist jedes Tripel von Fließkommawerten mit Ausnahme von [[NaN]]. Es ist nicht definiert, wie sich die Implementation verhält, falls [[NaN]] oder ein unendlicher Wert gesetzt wird.<br />
<br />
=== AL_REFERENCE_DISTANCE ===<br />
: '''AL_REFERENCE_DISTANCE''' beschreibt den Abstand, bei dem der Verstärkungsfaktor der Audioquelle genau 1 beträgt.<br />
<br />
=== AL_ROLLOFF_FACTOR ===<br />
: (unvollständig)<br />
<br />
=== AL_SAMPLE_OFFSET ===<br />
: Legt die Abspielposition fest, wobei diese Position in Samples ausgedrückt wird. Für Source-Objekte im Zustand '''AL_LOOPING''' wird dieser Wert wieder auf null zurückspringen, sobald die Wiedergabe wieder von vorn beginnt. Bei Verwendung eines komprimierten Formates gibt dieser Wert das exakte Offset innerhalb der unkomprimierten Daten an. Wenn '''AL_SAMPLE_OFFSET''' für ein Source-Objekt, welches gerade Audiodaten abspielt, gesetzt wird, so springt die Wiedergabe zur angegebenen Position, es sei denn das neue Offset ist außerhalb des zulässigen Bereiches, wodurch ein '''AL_INVALID_VALUE'''-Fehlerstatus generiert wird. Falls das Source-Objekt gerade keine Audiodaten abspielt, wird die Offsetänderung beim nächsten zugehörigen Aufruf von [[alSourcePlay]] durchgeführt. Ein Aufruf von [[alSourceStop]], [[alSourceRewind]] oder ein zweiter Aufruf von [[alSourcePlay]] setzt das Offset zurück auf den Anfang des Puffers. Die Position ist relativ zum Anfang aller dem Source-Objekt angehängten Puffer, und jeder Puffer, der beim Setzen des Offsets traversiert wird, wird als verarbeitet (siehe [[alGetSource]] mit Token [[alGetSource#AL_BUFFERS_PROCESSED|AL_BUFFERS_PROCESSED]]) markiert. Zulässige Werte sind alle Werte größer oder gleich null, ein Vorgabewert ist nicht festgelegt. '''AL_SAMPLE_OFFSET''' ist nur für die Funktionsvarianten '''alSourcef''', '''alSourcefv''', '''alSourcei''' und '''alSourceiv''' zulässig.<br />
<br />
=== AL_SEC_OFFSET ===<br />
: Legt die Abspielposition fest, wobei diese Position in Sekunden ausgedrückt wird. Für Source-Objekte im Zustand '''AL_LOOPING''' wird dieser Wert wieder auf null zurückspringen, sobald die Wiedergabe wieder von vorn beginnt. Wenn '''AL_SEC_OFFSET''' für ein Source-Objekt, welches gerade Audiodaten abspielt, gesetzt wird, so springt die Wiedergabe zur angegebenen Position, es sei denn das neue Offset ist außerhalb des zulässigen Bereiches, wodurch ein '''AL_INVALID_VALUE'''-Fehlerstatus generiert wird. Falls das Source-Objekt gerade keine Audiodaten abspielt, wird die Offsetänderung beim nächsten zugehörigen Aufruf von [[alSourcePlay]] durchgeführt. Die Position ist relativ zum Anfang aller dem Source-Objekt angehängten Puffer, und jeder Puffer, der beim Setzen des Offsets traversiert wird, wird als verarbeitet (siehe [[alGetSource]] mit Token [[alGetSource#AL_BUFFERS_PROCESSED|AL_BUFFERS_PROCESSED]]) markiert. Der Wert basiert auf der Byteposition, sodass ein mit '''AL_PITCH''' verändertes Source-Objekt eine überspitzte Abspielgeschwindigkeit hat. Zum Beispiel kann ein Puffer ein Offset von 0,50 Sekunden haben, jedoch dauert es nur 0,25 Sekunden, dahin zu gelangen, wenn der '''AL_PITCH'''-Wert auf 2,0 gesetzt ist. Für das Setzen des Offsets ist jeder Wert größer gleich 0,0 zulässig, ein Vorgabewert ist nicht definiert. Der Parameter '''AL_SEC_OFFSET''' ist nur für die Funktionsvarianten '''alSourcef''', '''alSourcefv''', '''alSourcei''' und '''alSourceiv''' zulässig.<br />
<br />
=== AL_SOURCE_RELATIVE ===<br />
: Legt fest, ob die Position, Geschwindigkeit, Richtung und der Schallkegel relativ zum Listener-Objekt interpretiert werden oder nicht. Bei einem Wert von '''AL_TRUE''' sind die Angaben relativ zu sehen, bei '''AL_FALSE''' nicht. Vorgabewert ist '''AL_FALSE'''. '''AL_SOURCE_RELATIVE''' ist nur für die Funktionsvarianten '''alSourcei''' und '''alSourceiv''' als Parameterwert zulässig.<br />
<br />
=== AL_SOURCE_STATE ===<br />
: (unvollständig)<br />
<br />
=== AL_VELOCITY ===<br />
: Setzt die Geschwindigkeit (Schnelligkeit und Richtung) des Source-Objektes im Koordinatensystem. Jedes Tripel aus gültigen Gleitkommawerten ist erlaubt, abgesehen von [[NaN]]. Der Vorgabewert ist (0.0, 0.0, 0.0). Die Geschwindigkeit beeinflußt jedoch nicht die Position des Objektes. [[OpenAL]] berechnet die Geschwindigkeit nicht aus aufeinanderfolgenden Änderungen mit '''AL_POSITION''', ebenso wenig wird die Position des Objektes über die Zeit anhand der angegebenen Geschwindigkeit angepasst. Jede derartige Berechnung bleibt der Anwendung überlassen. Für die Belange der Soundverarbeitung sind Position und Geschwindigkeit unabhängige Parameter, die sich auf verschiedene Aspekte des Klangs auswirken. '''AL_VELOCITY''' wird von Treiber berücksichtigt, um den vom Hörer wahrgenommenen Dopplereffekt zu berechnen, was auf Grundlage der Geschwindigkeit des Source-Objektes, des Listener-Objektes und der dopplereffektbezogenen Paramater geschieht. '''AL_VELOCITY''' ist nur für die Funktionsvarianten '''alSourcefv''', '''alSource3f''', '''alSourceiv''' und '''alSource3i''' als Paramater zulässig.<br />
<br />
<br />
<br />
== Hinweise ==<br />
Falls bei der Ausführung ein Fehler auftritt, kann dieser mit [[alGetError]] erfragt werden.<br />
<br />
<br />
<br />
== Änderungen ==<br />
Folgende Erweiterungen hat die Funktion erfahren:<br />
=== Ab OpenAL-Version 1.1 ===<br />
<br />
Seit OpenAL-Version 1.1 existieren auch die Funktionen für mehrere Ganzzahlwerte, '''alSource3i''' und '''alSourceiv'''.<br />
<br />
Ebenso sind die Token '''AL_BYTE_OFFSET''', '''AL_SAMPLE_OFFSET''' und '''AL_SEC_OFFSET''' erst ab Version 1.1 verfügbar. Jedoch gibt es dafür auch die OpenAL-Erweiterung '''AL_EXT_OFFSET''', welche von jeder Implementation der Open AL 1.1 unterstützt wird und es einer für die Spezifikation von OpenAL 1.0 geschriebenen aber auf eine Implementation der Version 1.1 zugreifenden Anwendung erlaubt, die drei genannten Tokenwerte auch zum Setzen (und Abfragen) der entsprechenden Werte zu nutzen.<br />
<br />
<br />
<br />
== Fehlermeldungen ==<br />
'''AL_INVALID_ENUM''' wird generiert, wenn der Wert für ''param'' unzulässig ist.<br />
<br />
'''AL_INVALID_NAME''' wird generiert, sofern ''source'' kein gültiges Source-Objekt ist. (Siehe auch [[alIsSource]].)<br />
<br />
'''AL_INVALID_OPERATION''' wird generiert, falls es keinen aktuellen Kontext gibt. (Siehe dazu auch [[alcMakeContextCurrent]].)<br />
<br />
'''AL_INVALID_VALUE''' wird generiert, wenn der zu setzenden Wert den zulässigen Bereich überschreitet.<br />
<br />
<br />
<br />
== Zugehörige Wertrückgaben ==<br />
[[alGetSource]] mit den oben genannten Tokenwerten liefert die gesetzten Werte zurück.<br />
<br />
<br />
<br />
== Siehe auch ==<br />
[[alGetSource]], [[alListener]] (analoge Funktion für Listener-Objekte)<br />
<br />
[[Kategorie:AL|Source]]</div>Igel457https://wiki.delphigl.com/index.php?title=alSource&diff=24332alSource2009-11-24T14:47:37Z<p>Igel457: /* AL_REFERENCE_DISTANCE */</p>
<hr />
<div>{{Unvollständig|Die Beschreibung zu den Auswirkungen des Funktionsparameters ''param'' muss noch ergänzt werden. Als Grundlage kann die [http://www.openal.org/documentation.html Open AL-Dokumentation] dienen.}}<br />
= alSource =<br />
<br />
<br />
<br />
== Name ==<br />
'''alSource''' - Setzt Eigenschaften eines Source-Objektes.<br />
<br />
<br />
<br />
== Delphi-Spezifikation ==<br />
procedure '''alSourcef'''(''source'': TALuint; ''param'': TALenum; ''value'': TALfloat);<br />
procedure '''alSource3f'''(''source'': TALuint; ''param'': TALenum; ''v1'': TALfloat; ''v2'': TALfloat; ''v3'': TALfloat);<br />
procedure '''alSourcefv'''(''source'': TALuint; ''param'': TALenum; ''values'': PALfloat);<br />
procedure '''alSourcei'''(''source'': TALuint; ''param'': TALenum; ''value'': TALint);<br />
procedure '''alSource3i'''(''source'': TALuint; ''param'': TALenum; ''v1'': TALint; ''v2'': TALint; ''v3'': TALint);<br />
procedure '''alSourceiv'''(''source'': TALuint; ''param'': TALenum; ''values'': PALint);<br />
<br />
<br />
<br />
== Parameter ==<br />
<br />
{| border="1" rules="all"<br />
! ''source'' <br />
| Name des Source-Objektes, dessen Eigenschaft geändert werden soll<br />
|-<br />
! ''param'' <br />
| Symbolische Konstante, welche die zu setzende Eigenschaft angibt<br />
|-<br />
! ''value'' <br />
| TALfloat-/ TALint-Wert, der gesetzt werden soll (nur bei '''alSourcef''' bzw. '''alSourcei''')<br />
|-<br />
! ''values'' <br />
| Zeiger auf einen TALfloat-/ TALint-Vektor, welcher die zu setzenden Werte enthält (nur bei '''alSourcefv''' und '''alSourceiv''')<br />
|-<br />
! ''v1, v2, v3'' <br />
| TALfloat-/ TALint-Werte, welche die zu setzenden Werte angeben (nur bei '''alSource3f''' und '''alSource3i''')<br />
|}<br />
<br />
<br />
<br />
== Beschreibung == <br />
Die Funktion '''alSource''' bzw. ihre Varianten für verschiedene Wertargumente setzen Eigenschaften eines Source-Objektes der [[OpenAL]]. Welche Eigenschaft gesetzt wird, hängt vom Wert des Parameters ''param'' ab.<br />
<br />
Folgende Werte sind für ''param'' zulässig:<br />
=== AL_BUFFER ===<br />
: Legt den aktuellen Puffer fest und macht ihn zum ersten Eintrag in der Pufferwarteschlange des Source-Objektes. Der Vorgabewert ist '''AL_NONE''', zulässige Werte sind alle gültigen Puffernamen (siehe dazu auch [[alIsBuffer]]). Wird '''alSource''' mit dem Parameter '''AL_BUFFER''' auf ein Source-Objekt im Zustand '''AL_INITIAL''' oder '''AL_STOPPED''' angewendet, so wird die gesamte Pufferwarteschlange geleert und der angegebene Puffer an das Source-Objekt angehangen.<br />
<br />
: Für ein Source-Objekt im Zustand '''AL_PLAYING''' oder '''AL_PAUSED''' wird der Versuch, mit '''AL_BUFFER''' einen Wert zu setzen, den Fehlerstatus '''AL_INVALID_OPERATION''' setzen. '''AL_BUFFER''' kann nur auf Source-Objekte im Zustand '''AL_STOPPED''' oder '''AL_INITIAL''' angewendet werden. Die Angabe eines ungültigen Puffernamens, sei es weil dieser Puffer nicht existiert oder nicht an das Source-Objekt angehängt werden kann, setzt den Fehlerstatus '''AL_INVALID_VALUE''', während die Angabe eines ungültigen Source-Objektes den Fehlerstatus '''AL_INVALID_NAME''' zur Folge hat.<br />
<br />
: '''AL_NONE''' ('''nil''' oder 0) ist ein gültiger Puffername. Der Aufruf alSourcei(sourceName, AL_BUFFER, AL_NONE) ist eine zulässige Möglichkeit, die aktuelle Pufferwarteschlange eines Source-Objektes freizugeben, egal ob die Pufferwarteschlange nur einen Eintrag (den aktuellen Puffer) oder mehrer hat. Jedoch verursacht der Funktionsaufruf alSourcei(sourceName, AL_BUFFER, AL_NONE) immer noch einen '''AL_INVALID_OPERATION'''-Fehlerstatus für ein im Zustand '''AL_PLAYING''' oder '''AL_PAUSED''' befindliches Source-Objekt und kann folgerichtig nicht genutzt werden, um ein Source-Objekt anzuhalten (siehe dazu [[alSourceStop]]) oder stummzuschalten. Der Paramater '''AL_BUFFER''' ist nur für die Funktionsvarianten '''alSourcei''' und '''alSourceiv''' zugelassen.<br />
<br />
=== AL_BYTE_OFFEST ===<br />
: Legt die Abpspielposition, ausgedrückt in Bytes, fest. Für Source-Objekte im Zustand '''AL_LOOPING''' wird dieser Wert wieder auf null zurückspringen, sobald die Wiedergabe wieder von vorn beginnt. Im Falle eines komprimierten Audioformates kann es sein, dass dieser Wert nur einen genäherten Wert innerhalb der komprimierten Daten angibt. Wird das Offset für ein Source-Objekt gesetzt, welches gerade Audiodaten abspielt, springt die Wiedergabe zur neuen Position, es sei denn der angegebene Wert ist außerhalb des zulässigen Bereichs, wodurch ein '''AL_INVALID_VALUE'''-Fehler generiert wird. Falls das Source-Objekt gerade keine Audiodaten abspielt, wird die Offsetänderung beim nächsten zugehörigen Aufruf von [[alSourcePlay]] durchgeführt. Ein Aufruf von [[alSourceStop]], [[alSourceRewind]] oder ein zweiter Aufruf von [[alSourcePlay]] setzt das Offset zurück auf den Anfang des Puffers. Die Position ist relativ zum Anfang aller dem Source-Objekt angehängten Puffer, und jeder Puffer, der beim Setzen des Offsets traversiert wird, wird als verarbeitet (siehe [[alGetSource]] mit Token [[alGetSource#AL_BUFFERS_PROCESSED|AL_BUFFERS_PROCESSED]]) markiert. Zulässige Werte sind Werte größer oder gleich null, ein Vorgabewert ist nicht festgelegt. '''AL_BYTE_OFFSET''' ist nur für die Funktionsvarianten '''alSourcef''', '''alSourcefv''', '''alSourcei''' und '''alSourceiv''' zulässig.<br />
<br />
=== AL_CONE_INNER_ANGLE ===<br />
: (unvollständig)<br />
<br />
=== AL_CONE_OUTER_ANGLE ===<br />
: (unvollständig)<br />
<br />
=== AL_CONE_OUTER_GAIN ===<br />
: (unvollständig)<br />
<br />
=== AL_DIRECTION ===<br />
: Legt die Ausrichtung eines Source-Objektes fest. Falls der '''AL_DIRECTION'''-Wert ungleich dem Nullvektor ist, so handelt es sich um ein gerichtetes Source-Objekt. Die Geräuschemission wird als symmetrisch um den Richtungsvektor herum angenommen (Zylindersymmetrie). Der Nullvektor ist der Vorgabewert, wodurch angegeben wird, dass das Source-Objekt nicht gerichtet ist. Das Setzen eines vom Nullvektor verschiedenen, dreidimensionalen Vektors macht aus dem Source-Objekt ein gerichtetes Objekt; das Setzen des Nullvektors für ein gerichtetes Source-Objekt macht es zu einem ungerichteten Source-Objekt. Zulässig sind alle Werte außer [[NaN]]. Der Parameter '''AL_DIRECTION''' ist nur für die Funktionsvarianten '''alSourcefv''', '''alSource3f''', '''alSourceiv''' und '''alSource3i''' zulässig.<br />
<br />
=== AL_GAIN ===<br />
: Legt den skalaren Amplitudenmultiplikator für das Source-Objekt fest. Der Vorgabewert 1.0 bedeutet, dass die Geräusche ungedämpft sind. Ein Wert von 0.5 ist äquivalent zu einer Abschwächung von 6 dB. Der Wert null entspricht Stille. Die Implementierung ist dafür verantwortlich, artefaktfreie (d.h. klickgeräuschfreie) Änderungen des Wertes zu ermöglichen und kann daher die tatsächliche Änderung des Wertes innerhalb gewisser, akzeptabler Grenzen verzögern. Werte größer als eins sind zwar zulässig, jedoch steht es der Implementierung frei, Werte größer als 1,0 auf 1,0 herunterzuregeln, um einen möglichen Überlauf zu vermeiden. '''AL_GAIN''' ist nur für die Funktionsvarianten '''alSourcef''' und '''alSourcefv''' zulässig.<br />
<br />
=== AL_LOOPING ===<br />
: Legt fest, ob das Source-Objekt nicht in den Zustand '''AL_STOPPED''' wechselt, sobald es das Ende des letzten Puffers in der Pufferwarteschlange erreicht hat. In diesem Fall ist der Wert '''AL_TRUE''' zu setzen, andernfalls '''AL_FALSE'''. Der Vorgabewert für '''AL_LOOPING''' ist '''AL_FALSE'''. Ist das '''AL_LOOPING'''-Flag auf '''AL_TRUE''' gesetzt, so wechselt das Source-Objekt beim Erreichen des Endes der Pufferwarteschlange sofort wieder in den Zustand '''AL_INITIAL''' und danach in den Zustand '''AL_PLAYING''', um die Audiodaten in den zugehörigen Puffern erneut abzuspielen. Das '''AL_LOOPING'''-Flag für ein Source-Objekt kann in jedem Ausführungszustand, besonders auch im Zustand '''AL_PLAYING''', geändert werden. Zulässige Werte sind '''AL_TRUE''' und '''AL_FALSE'''. Der Paramater '''AL_LOOPING''' ist nur für die Funktionsvarianten '''alSourcei''' und '''alSourceiv''' als Paramater zugelassen.<br />
<br />
=== AL_MAX_DISTANCE ===<br />
: (unvollständig)<br />
<br />
=== AL_MAX_GAIN ===<br />
: Setzt den maximalen, erlaubten '''AL_GAIN'''-Wert für das Source-Objekt. Der Vorgabewert ist 1.0, zulässig sind alle Gleitkommawerte aus dem Intervall von 0,0 bis 1,0. Am Ende der Varabrebitung verschiedener Abschwächungs- oder Verstärkungsfaktoren wie der entfernungsbasierten Abschwächung und dem '''AL_GAIN'''-Wert des Source-Objektes wird der berechnete Effektivwert mit dem '''AL_MAX_GAIN'''-Wert verglichen. Falls der berechnete Wert größer ist als der '''AL_MAX_GAIN'''-Wert, dann wird der '''AL_MAX_GAIN'''-Wert angewendet. Dies geschieht jedoch, bevor der '''AL_GAIN'''-Wert des Listener-Objektes in Betracht gezogen wird. Wenn das Produkt aus '''AL_MAX_GAIN''' und dem '''AL_GAIN'''-Wert des Listener-Objektes immer noch den maximalen Wert, welchen die Implementierung handhaben kann, überschreitet, so steht es der Implementierung frei, den Wert zu reduzieren. Falls für '''AL_MAX_GAIN''' der Wert null gesetzt wird, so ist das Source-Objekt quasi stummgeschalten. Die vorgesehene Art, ein Source-Objekt stummzuschalten, ist jedoch, den '''AL_GAIN'''-Wert auf null zu setzen. Der Parameter '''AL_MAX_GAIN''' ist nur für die Funktionsvarianten '''alSourcef''' und '''alSourcefv''' zulässig.<br />
<br />
=== AL_MIN_GAIN ===<br />
: Legt den minimalen '''AL_GAIN'''-Wert fest, welcher für das Source-Objekt immer gewährleistet sein soll. Der Vorgabewert ist 0.0, zulässig sind alle Werte aus dem Intervall von 0,0 bis 1,0. Am Ende der Verarbeitung verschiedener Abschwächungsfaktoren wie der entfernungsbasierten Abschwächung und dem '''AL_GAIN'''-Wertes des Source-Objektes wird der berechnete Effektivwert mit dem '''AL_MIN_GAIN'''-Wert verglichen. Falls der berechnete Wert kleiner ist als '''AL_MIN_GAIN''', so wird der Wert von '''AL_MIN_GAIN''' angewendet. Dies passiert jedoch, bevor der '''AL_GAIN'''-Wert des Listener-Objektes angewendet wird. Wenn der für '''AL_MIN_GAIN''' gesetzte Wert null ist, so wird keine Korrektur vorgenommen. Der Parameter '''AL_MIN_GAIN''' ist nur für die Funktionsvarianten '''alSourcef''' und '''alSourcefv''' zugelassen.<br />
<br />
=== AL_PITCH ===<br />
: Setzt die Verschiebung der Tonhöhe/ Frequenz des Source-Objektes. Ein Wert von 1,0 entspricht der Identität (d.h. keine Verschiebung), dies ist auch der Vorgabewert. Jede Reduzierung des Wertes um 50% entspricht einer Verschiebung um 12 Halbtöne bzw. eine Oktave nach unten. Jede Verdopplung des Wertes entspricht einer Verschiebung von 12 Halbtönen bzw. einer Oktave nach oben. Null ist kein zulässiger Wert, alle Gleitkommawerte größer als null sind erlaubt. Jede Implementierung kann die '''AL_PITCH'''-Werte aber entsprechend ihrer eigenen Limitationen beschränken. '''AL_PITCH''' ist nur für die Funktionsvarianten '''alSourcef''' und '''alSourcefv''' als Parameter zugelassen.<br />
<br />
=== AL_POSITION ===<br />
: Setzt die aktuelle Position des Source-Objektes im Weltkoordinatensystem. Der Standardwert ist (0.0, 0.0, 0.0). '''AL_POSITION''' darf ''nicht'' in '''alSourcei''' oder '''alSourcef''' benutzt werden sondern nur in den Funktionsvarianten für mehrere Wertargumente, also '''alSource3f''', '''alSource3i''', '''alSourcefv''' oder '''alSourceiv'''. Erlaubt ist jedes Tripel von Fließkommawerten mit Ausnahme von [[NaN]]. Es ist nicht definiert, wie sich die Implementation verhält, falls [[NaN]] oder ein unendlicher Wert gesetzt wird.<br />
<br />
=== AL_REFERENCE_DISTANCE ===<br />
'''AL_REFERENCE_DISTANCE''' beschreibt den Abstand, bei dem der Verstärkungsfaktor der Audioquelle genau 1 beträgt.<br />
<br />
=== AL_ROLLOFF_FACTOR ===<br />
: (unvollständig)<br />
<br />
=== AL_SAMPLE_OFFSET ===<br />
: Legt die Abspielposition fest, wobei diese Position in Samples ausgedrückt wird. Für Source-Objekte im Zustand '''AL_LOOPING''' wird dieser Wert wieder auf null zurückspringen, sobald die Wiedergabe wieder von vorn beginnt. Bei Verwendung eines komprimierten Formates gibt dieser Wert das exakte Offset innerhalb der unkomprimierten Daten an. Wenn '''AL_SAMPLE_OFFSET''' für ein Source-Objekt, welches gerade Audiodaten abspielt, gesetzt wird, so springt die Wiedergabe zur angegebenen Position, es sei denn das neue Offset ist außerhalb des zulässigen Bereiches, wodurch ein '''AL_INVALID_VALUE'''-Fehlerstatus generiert wird. Falls das Source-Objekt gerade keine Audiodaten abspielt, wird die Offsetänderung beim nächsten zugehörigen Aufruf von [[alSourcePlay]] durchgeführt. Ein Aufruf von [[alSourceStop]], [[alSourceRewind]] oder ein zweiter Aufruf von [[alSourcePlay]] setzt das Offset zurück auf den Anfang des Puffers. Die Position ist relativ zum Anfang aller dem Source-Objekt angehängten Puffer, und jeder Puffer, der beim Setzen des Offsets traversiert wird, wird als verarbeitet (siehe [[alGetSource]] mit Token [[alGetSource#AL_BUFFERS_PROCESSED|AL_BUFFERS_PROCESSED]]) markiert. Zulässige Werte sind alle Werte größer oder gleich null, ein Vorgabewert ist nicht festgelegt. '''AL_SAMPLE_OFFSET''' ist nur für die Funktionsvarianten '''alSourcef''', '''alSourcefv''', '''alSourcei''' und '''alSourceiv''' zulässig.<br />
<br />
=== AL_SEC_OFFSET ===<br />
: Legt die Abspielposition fest, wobei diese Position in Sekunden ausgedrückt wird. Für Source-Objekte im Zustand '''AL_LOOPING''' wird dieser Wert wieder auf null zurückspringen, sobald die Wiedergabe wieder von vorn beginnt. Wenn '''AL_SEC_OFFSET''' für ein Source-Objekt, welches gerade Audiodaten abspielt, gesetzt wird, so springt die Wiedergabe zur angegebenen Position, es sei denn das neue Offset ist außerhalb des zulässigen Bereiches, wodurch ein '''AL_INVALID_VALUE'''-Fehlerstatus generiert wird. Falls das Source-Objekt gerade keine Audiodaten abspielt, wird die Offsetänderung beim nächsten zugehörigen Aufruf von [[alSourcePlay]] durchgeführt. Die Position ist relativ zum Anfang aller dem Source-Objekt angehängten Puffer, und jeder Puffer, der beim Setzen des Offsets traversiert wird, wird als verarbeitet (siehe [[alGetSource]] mit Token [[alGetSource#AL_BUFFERS_PROCESSED|AL_BUFFERS_PROCESSED]]) markiert. Der Wert basiert auf der Byteposition, sodass ein mit '''AL_PITCH''' verändertes Source-Objekt eine überspitzte Abspielgeschwindigkeit hat. Zum Beispiel kann ein Puffer ein Offset von 0,50 Sekunden haben, jedoch dauert es nur 0,25 Sekunden, dahin zu gelangen, wenn der '''AL_PITCH'''-Wert auf 2,0 gesetzt ist. Für das Setzen des Offsets ist jeder Wert größer gleich 0,0 zulässig, ein Vorgabewert ist nicht definiert. Der Parameter '''AL_SEC_OFFSET''' ist nur für die Funktionsvarianten '''alSourcef''', '''alSourcefv''', '''alSourcei''' und '''alSourceiv''' zulässig.<br />
<br />
=== AL_SOURCE_RELATIVE ===<br />
: Legt fest, ob die Position, Geschwindigkeit, Richtung und der Schallkegel relativ zum Listener-Objekt interpretiert werden oder nicht. Bei einem Wert von '''AL_TRUE''' sind die Angaben relativ zu sehen, bei '''AL_FALSE''' nicht. Vorgabewert ist '''AL_FALSE'''. '''AL_SOURCE_RELATIVE''' ist nur für die Funktionsvarianten '''alSourcei''' und '''alSourceiv''' als Parameterwert zulässig.<br />
<br />
=== AL_SOURCE_STATE ===<br />
: (unvollständig)<br />
<br />
=== AL_VELOCITY ===<br />
: Setzt die Geschwindigkeit (Schnelligkeit und Richtung) des Source-Objektes im Koordinatensystem. Jedes Tripel aus gültigen Gleitkommawerten ist erlaubt, abgesehen von [[NaN]]. Der Vorgabewert ist (0.0, 0.0, 0.0). Die Geschwindigkeit beeinflußt jedoch nicht die Position des Objektes. [[OpenAL]] berechnet die Geschwindigkeit nicht aus aufeinanderfolgenden Änderungen mit '''AL_POSITION''', ebenso wenig wird die Position des Objektes über die Zeit anhand der angegebenen Geschwindigkeit angepasst. Jede derartige Berechnung bleibt der Anwendung überlassen. Für die Belange der Soundverarbeitung sind Position und Geschwindigkeit unabhängige Parameter, die sich auf verschiedene Aspekte des Klangs auswirken. '''AL_VELOCITY''' wird von Treiber berücksichtigt, um den vom Hörer wahrgenommenen Dopplereffekt zu berechnen, was auf Grundlage der Geschwindigkeit des Source-Objektes, des Listener-Objektes und der dopplereffektbezogenen Paramater geschieht. '''AL_VELOCITY''' ist nur für die Funktionsvarianten '''alSourcefv''', '''alSource3f''', '''alSourceiv''' und '''alSource3i''' als Paramater zulässig.<br />
<br />
<br />
<br />
== Hinweise ==<br />
Falls bei der Ausführung ein Fehler auftritt, kann dieser mit [[alGetError]] erfragt werden.<br />
<br />
<br />
<br />
== Änderungen ==<br />
Folgende Erweiterungen hat die Funktion erfahren:<br />
=== Ab OpenAL-Version 1.1 ===<br />
<br />
Seit OpenAL-Version 1.1 existieren auch die Funktionen für mehrere Ganzzahlwerte, '''alSource3i''' und '''alSourceiv'''.<br />
<br />
Ebenso sind die Token '''AL_BYTE_OFFSET''', '''AL_SAMPLE_OFFSET''' und '''AL_SEC_OFFSET''' erst ab Version 1.1 verfügbar. Jedoch gibt es dafür auch die OpenAL-Erweiterung '''AL_EXT_OFFSET''', welche von jeder Implementation der Open AL 1.1 unterstützt wird und es einer für die Spezifikation von OpenAL 1.0 geschriebenen aber auf eine Implementation der Version 1.1 zugreifenden Anwendung erlaubt, die drei genannten Tokenwerte auch zum Setzen (und Abfragen) der entsprechenden Werte zu nutzen.<br />
<br />
<br />
<br />
== Fehlermeldungen ==<br />
'''AL_INVALID_ENUM''' wird generiert, wenn der Wert für ''param'' unzulässig ist.<br />
<br />
'''AL_INVALID_NAME''' wird generiert, sofern ''source'' kein gültiges Source-Objekt ist. (Siehe auch [[alIsSource]].)<br />
<br />
'''AL_INVALID_OPERATION''' wird generiert, falls es keinen aktuellen Kontext gibt. (Siehe dazu auch [[alcMakeContextCurrent]].)<br />
<br />
'''AL_INVALID_VALUE''' wird generiert, wenn der zu setzenden Wert den zulässigen Bereich überschreitet.<br />
<br />
<br />
<br />
== Zugehörige Wertrückgaben ==<br />
[[alGetSource]] mit den oben genannten Tokenwerten liefert die gesetzten Werte zurück.<br />
<br />
<br />
<br />
== Siehe auch ==<br />
[[alGetSource]], [[alListener]] (analoge Funktion für Listener-Objekte)<br />
<br />
[[Kategorie:AL|Source]]</div>Igel457https://wiki.delphigl.com/index.php?title=alSource&diff=24331alSource2009-11-24T14:47:24Z<p>Igel457: /* AL_REFERENCE_DISTANCE */</p>
<hr />
<div>{{Unvollständig|Die Beschreibung zu den Auswirkungen des Funktionsparameters ''param'' muss noch ergänzt werden. Als Grundlage kann die [http://www.openal.org/documentation.html Open AL-Dokumentation] dienen.}}<br />
= alSource =<br />
<br />
<br />
<br />
== Name ==<br />
'''alSource''' - Setzt Eigenschaften eines Source-Objektes.<br />
<br />
<br />
<br />
== Delphi-Spezifikation ==<br />
procedure '''alSourcef'''(''source'': TALuint; ''param'': TALenum; ''value'': TALfloat);<br />
procedure '''alSource3f'''(''source'': TALuint; ''param'': TALenum; ''v1'': TALfloat; ''v2'': TALfloat; ''v3'': TALfloat);<br />
procedure '''alSourcefv'''(''source'': TALuint; ''param'': TALenum; ''values'': PALfloat);<br />
procedure '''alSourcei'''(''source'': TALuint; ''param'': TALenum; ''value'': TALint);<br />
procedure '''alSource3i'''(''source'': TALuint; ''param'': TALenum; ''v1'': TALint; ''v2'': TALint; ''v3'': TALint);<br />
procedure '''alSourceiv'''(''source'': TALuint; ''param'': TALenum; ''values'': PALint);<br />
<br />
<br />
<br />
== Parameter ==<br />
<br />
{| border="1" rules="all"<br />
! ''source'' <br />
| Name des Source-Objektes, dessen Eigenschaft geändert werden soll<br />
|-<br />
! ''param'' <br />
| Symbolische Konstante, welche die zu setzende Eigenschaft angibt<br />
|-<br />
! ''value'' <br />
| TALfloat-/ TALint-Wert, der gesetzt werden soll (nur bei '''alSourcef''' bzw. '''alSourcei''')<br />
|-<br />
! ''values'' <br />
| Zeiger auf einen TALfloat-/ TALint-Vektor, welcher die zu setzenden Werte enthält (nur bei '''alSourcefv''' und '''alSourceiv''')<br />
|-<br />
! ''v1, v2, v3'' <br />
| TALfloat-/ TALint-Werte, welche die zu setzenden Werte angeben (nur bei '''alSource3f''' und '''alSource3i''')<br />
|}<br />
<br />
<br />
<br />
== Beschreibung == <br />
Die Funktion '''alSource''' bzw. ihre Varianten für verschiedene Wertargumente setzen Eigenschaften eines Source-Objektes der [[OpenAL]]. Welche Eigenschaft gesetzt wird, hängt vom Wert des Parameters ''param'' ab.<br />
<br />
Folgende Werte sind für ''param'' zulässig:<br />
=== AL_BUFFER ===<br />
: Legt den aktuellen Puffer fest und macht ihn zum ersten Eintrag in der Pufferwarteschlange des Source-Objektes. Der Vorgabewert ist '''AL_NONE''', zulässige Werte sind alle gültigen Puffernamen (siehe dazu auch [[alIsBuffer]]). Wird '''alSource''' mit dem Parameter '''AL_BUFFER''' auf ein Source-Objekt im Zustand '''AL_INITIAL''' oder '''AL_STOPPED''' angewendet, so wird die gesamte Pufferwarteschlange geleert und der angegebene Puffer an das Source-Objekt angehangen.<br />
<br />
: Für ein Source-Objekt im Zustand '''AL_PLAYING''' oder '''AL_PAUSED''' wird der Versuch, mit '''AL_BUFFER''' einen Wert zu setzen, den Fehlerstatus '''AL_INVALID_OPERATION''' setzen. '''AL_BUFFER''' kann nur auf Source-Objekte im Zustand '''AL_STOPPED''' oder '''AL_INITIAL''' angewendet werden. Die Angabe eines ungültigen Puffernamens, sei es weil dieser Puffer nicht existiert oder nicht an das Source-Objekt angehängt werden kann, setzt den Fehlerstatus '''AL_INVALID_VALUE''', während die Angabe eines ungültigen Source-Objektes den Fehlerstatus '''AL_INVALID_NAME''' zur Folge hat.<br />
<br />
: '''AL_NONE''' ('''nil''' oder 0) ist ein gültiger Puffername. Der Aufruf alSourcei(sourceName, AL_BUFFER, AL_NONE) ist eine zulässige Möglichkeit, die aktuelle Pufferwarteschlange eines Source-Objektes freizugeben, egal ob die Pufferwarteschlange nur einen Eintrag (den aktuellen Puffer) oder mehrer hat. Jedoch verursacht der Funktionsaufruf alSourcei(sourceName, AL_BUFFER, AL_NONE) immer noch einen '''AL_INVALID_OPERATION'''-Fehlerstatus für ein im Zustand '''AL_PLAYING''' oder '''AL_PAUSED''' befindliches Source-Objekt und kann folgerichtig nicht genutzt werden, um ein Source-Objekt anzuhalten (siehe dazu [[alSourceStop]]) oder stummzuschalten. Der Paramater '''AL_BUFFER''' ist nur für die Funktionsvarianten '''alSourcei''' und '''alSourceiv''' zugelassen.<br />
<br />
=== AL_BYTE_OFFEST ===<br />
: Legt die Abpspielposition, ausgedrückt in Bytes, fest. Für Source-Objekte im Zustand '''AL_LOOPING''' wird dieser Wert wieder auf null zurückspringen, sobald die Wiedergabe wieder von vorn beginnt. Im Falle eines komprimierten Audioformates kann es sein, dass dieser Wert nur einen genäherten Wert innerhalb der komprimierten Daten angibt. Wird das Offset für ein Source-Objekt gesetzt, welches gerade Audiodaten abspielt, springt die Wiedergabe zur neuen Position, es sei denn der angegebene Wert ist außerhalb des zulässigen Bereichs, wodurch ein '''AL_INVALID_VALUE'''-Fehler generiert wird. Falls das Source-Objekt gerade keine Audiodaten abspielt, wird die Offsetänderung beim nächsten zugehörigen Aufruf von [[alSourcePlay]] durchgeführt. Ein Aufruf von [[alSourceStop]], [[alSourceRewind]] oder ein zweiter Aufruf von [[alSourcePlay]] setzt das Offset zurück auf den Anfang des Puffers. Die Position ist relativ zum Anfang aller dem Source-Objekt angehängten Puffer, und jeder Puffer, der beim Setzen des Offsets traversiert wird, wird als verarbeitet (siehe [[alGetSource]] mit Token [[alGetSource#AL_BUFFERS_PROCESSED|AL_BUFFERS_PROCESSED]]) markiert. Zulässige Werte sind Werte größer oder gleich null, ein Vorgabewert ist nicht festgelegt. '''AL_BYTE_OFFSET''' ist nur für die Funktionsvarianten '''alSourcef''', '''alSourcefv''', '''alSourcei''' und '''alSourceiv''' zulässig.<br />
<br />
=== AL_CONE_INNER_ANGLE ===<br />
: (unvollständig)<br />
<br />
=== AL_CONE_OUTER_ANGLE ===<br />
: (unvollständig)<br />
<br />
=== AL_CONE_OUTER_GAIN ===<br />
: (unvollständig)<br />
<br />
=== AL_DIRECTION ===<br />
: Legt die Ausrichtung eines Source-Objektes fest. Falls der '''AL_DIRECTION'''-Wert ungleich dem Nullvektor ist, so handelt es sich um ein gerichtetes Source-Objekt. Die Geräuschemission wird als symmetrisch um den Richtungsvektor herum angenommen (Zylindersymmetrie). Der Nullvektor ist der Vorgabewert, wodurch angegeben wird, dass das Source-Objekt nicht gerichtet ist. Das Setzen eines vom Nullvektor verschiedenen, dreidimensionalen Vektors macht aus dem Source-Objekt ein gerichtetes Objekt; das Setzen des Nullvektors für ein gerichtetes Source-Objekt macht es zu einem ungerichteten Source-Objekt. Zulässig sind alle Werte außer [[NaN]]. Der Parameter '''AL_DIRECTION''' ist nur für die Funktionsvarianten '''alSourcefv''', '''alSource3f''', '''alSourceiv''' und '''alSource3i''' zulässig.<br />
<br />
=== AL_GAIN ===<br />
: Legt den skalaren Amplitudenmultiplikator für das Source-Objekt fest. Der Vorgabewert 1.0 bedeutet, dass die Geräusche ungedämpft sind. Ein Wert von 0.5 ist äquivalent zu einer Abschwächung von 6 dB. Der Wert null entspricht Stille. Die Implementierung ist dafür verantwortlich, artefaktfreie (d.h. klickgeräuschfreie) Änderungen des Wertes zu ermöglichen und kann daher die tatsächliche Änderung des Wertes innerhalb gewisser, akzeptabler Grenzen verzögern. Werte größer als eins sind zwar zulässig, jedoch steht es der Implementierung frei, Werte größer als 1,0 auf 1,0 herunterzuregeln, um einen möglichen Überlauf zu vermeiden. '''AL_GAIN''' ist nur für die Funktionsvarianten '''alSourcef''' und '''alSourcefv''' zulässig.<br />
<br />
=== AL_LOOPING ===<br />
: Legt fest, ob das Source-Objekt nicht in den Zustand '''AL_STOPPED''' wechselt, sobald es das Ende des letzten Puffers in der Pufferwarteschlange erreicht hat. In diesem Fall ist der Wert '''AL_TRUE''' zu setzen, andernfalls '''AL_FALSE'''. Der Vorgabewert für '''AL_LOOPING''' ist '''AL_FALSE'''. Ist das '''AL_LOOPING'''-Flag auf '''AL_TRUE''' gesetzt, so wechselt das Source-Objekt beim Erreichen des Endes der Pufferwarteschlange sofort wieder in den Zustand '''AL_INITIAL''' und danach in den Zustand '''AL_PLAYING''', um die Audiodaten in den zugehörigen Puffern erneut abzuspielen. Das '''AL_LOOPING'''-Flag für ein Source-Objekt kann in jedem Ausführungszustand, besonders auch im Zustand '''AL_PLAYING''', geändert werden. Zulässige Werte sind '''AL_TRUE''' und '''AL_FALSE'''. Der Paramater '''AL_LOOPING''' ist nur für die Funktionsvarianten '''alSourcei''' und '''alSourceiv''' als Paramater zugelassen.<br />
<br />
=== AL_MAX_DISTANCE ===<br />
: (unvollständig)<br />
<br />
=== AL_MAX_GAIN ===<br />
: Setzt den maximalen, erlaubten '''AL_GAIN'''-Wert für das Source-Objekt. Der Vorgabewert ist 1.0, zulässig sind alle Gleitkommawerte aus dem Intervall von 0,0 bis 1,0. Am Ende der Varabrebitung verschiedener Abschwächungs- oder Verstärkungsfaktoren wie der entfernungsbasierten Abschwächung und dem '''AL_GAIN'''-Wert des Source-Objektes wird der berechnete Effektivwert mit dem '''AL_MAX_GAIN'''-Wert verglichen. Falls der berechnete Wert größer ist als der '''AL_MAX_GAIN'''-Wert, dann wird der '''AL_MAX_GAIN'''-Wert angewendet. Dies geschieht jedoch, bevor der '''AL_GAIN'''-Wert des Listener-Objektes in Betracht gezogen wird. Wenn das Produkt aus '''AL_MAX_GAIN''' und dem '''AL_GAIN'''-Wert des Listener-Objektes immer noch den maximalen Wert, welchen die Implementierung handhaben kann, überschreitet, so steht es der Implementierung frei, den Wert zu reduzieren. Falls für '''AL_MAX_GAIN''' der Wert null gesetzt wird, so ist das Source-Objekt quasi stummgeschalten. Die vorgesehene Art, ein Source-Objekt stummzuschalten, ist jedoch, den '''AL_GAIN'''-Wert auf null zu setzen. Der Parameter '''AL_MAX_GAIN''' ist nur für die Funktionsvarianten '''alSourcef''' und '''alSourcefv''' zulässig.<br />
<br />
=== AL_MIN_GAIN ===<br />
: Legt den minimalen '''AL_GAIN'''-Wert fest, welcher für das Source-Objekt immer gewährleistet sein soll. Der Vorgabewert ist 0.0, zulässig sind alle Werte aus dem Intervall von 0,0 bis 1,0. Am Ende der Verarbeitung verschiedener Abschwächungsfaktoren wie der entfernungsbasierten Abschwächung und dem '''AL_GAIN'''-Wertes des Source-Objektes wird der berechnete Effektivwert mit dem '''AL_MIN_GAIN'''-Wert verglichen. Falls der berechnete Wert kleiner ist als '''AL_MIN_GAIN''', so wird der Wert von '''AL_MIN_GAIN''' angewendet. Dies passiert jedoch, bevor der '''AL_GAIN'''-Wert des Listener-Objektes angewendet wird. Wenn der für '''AL_MIN_GAIN''' gesetzte Wert null ist, so wird keine Korrektur vorgenommen. Der Parameter '''AL_MIN_GAIN''' ist nur für die Funktionsvarianten '''alSourcef''' und '''alSourcefv''' zugelassen.<br />
<br />
=== AL_PITCH ===<br />
: Setzt die Verschiebung der Tonhöhe/ Frequenz des Source-Objektes. Ein Wert von 1,0 entspricht der Identität (d.h. keine Verschiebung), dies ist auch der Vorgabewert. Jede Reduzierung des Wertes um 50% entspricht einer Verschiebung um 12 Halbtöne bzw. eine Oktave nach unten. Jede Verdopplung des Wertes entspricht einer Verschiebung von 12 Halbtönen bzw. einer Oktave nach oben. Null ist kein zulässiger Wert, alle Gleitkommawerte größer als null sind erlaubt. Jede Implementierung kann die '''AL_PITCH'''-Werte aber entsprechend ihrer eigenen Limitationen beschränken. '''AL_PITCH''' ist nur für die Funktionsvarianten '''alSourcef''' und '''alSourcefv''' als Parameter zugelassen.<br />
<br />
=== AL_POSITION ===<br />
: Setzt die aktuelle Position des Source-Objektes im Weltkoordinatensystem. Der Standardwert ist (0.0, 0.0, 0.0). '''AL_POSITION''' darf ''nicht'' in '''alSourcei''' oder '''alSourcef''' benutzt werden sondern nur in den Funktionsvarianten für mehrere Wertargumente, also '''alSource3f''', '''alSource3i''', '''alSourcefv''' oder '''alSourceiv'''. Erlaubt ist jedes Tripel von Fließkommawerten mit Ausnahme von [[NaN]]. Es ist nicht definiert, wie sich die Implementation verhält, falls [[NaN]] oder ein unendlicher Wert gesetzt wird.<br />
<br />
=== AL_REFERENCE_DISTANCE ===<br />
'''AL_REFERENCE_DISTANCE''' beschreibt den Abstand, bei dem der Verstärkungsfaktor der Audioquelle genau 1 beträgt.<br />
<br />
=== AL_ROLLOFF_FACTOR ===<br />
: (unvollständig)<br />
<br />
=== AL_SAMPLE_OFFSET ===<br />
: Legt die Abspielposition fest, wobei diese Position in Samples ausgedrückt wird. Für Source-Objekte im Zustand '''AL_LOOPING''' wird dieser Wert wieder auf null zurückspringen, sobald die Wiedergabe wieder von vorn beginnt. Bei Verwendung eines komprimierten Formates gibt dieser Wert das exakte Offset innerhalb der unkomprimierten Daten an. Wenn '''AL_SAMPLE_OFFSET''' für ein Source-Objekt, welches gerade Audiodaten abspielt, gesetzt wird, so springt die Wiedergabe zur angegebenen Position, es sei denn das neue Offset ist außerhalb des zulässigen Bereiches, wodurch ein '''AL_INVALID_VALUE'''-Fehlerstatus generiert wird. Falls das Source-Objekt gerade keine Audiodaten abspielt, wird die Offsetänderung beim nächsten zugehörigen Aufruf von [[alSourcePlay]] durchgeführt. Ein Aufruf von [[alSourceStop]], [[alSourceRewind]] oder ein zweiter Aufruf von [[alSourcePlay]] setzt das Offset zurück auf den Anfang des Puffers. Die Position ist relativ zum Anfang aller dem Source-Objekt angehängten Puffer, und jeder Puffer, der beim Setzen des Offsets traversiert wird, wird als verarbeitet (siehe [[alGetSource]] mit Token [[alGetSource#AL_BUFFERS_PROCESSED|AL_BUFFERS_PROCESSED]]) markiert. Zulässige Werte sind alle Werte größer oder gleich null, ein Vorgabewert ist nicht festgelegt. '''AL_SAMPLE_OFFSET''' ist nur für die Funktionsvarianten '''alSourcef''', '''alSourcefv''', '''alSourcei''' und '''alSourceiv''' zulässig.<br />
<br />
=== AL_SEC_OFFSET ===<br />
: Legt die Abspielposition fest, wobei diese Position in Sekunden ausgedrückt wird. Für Source-Objekte im Zustand '''AL_LOOPING''' wird dieser Wert wieder auf null zurückspringen, sobald die Wiedergabe wieder von vorn beginnt. Wenn '''AL_SEC_OFFSET''' für ein Source-Objekt, welches gerade Audiodaten abspielt, gesetzt wird, so springt die Wiedergabe zur angegebenen Position, es sei denn das neue Offset ist außerhalb des zulässigen Bereiches, wodurch ein '''AL_INVALID_VALUE'''-Fehlerstatus generiert wird. Falls das Source-Objekt gerade keine Audiodaten abspielt, wird die Offsetänderung beim nächsten zugehörigen Aufruf von [[alSourcePlay]] durchgeführt. Die Position ist relativ zum Anfang aller dem Source-Objekt angehängten Puffer, und jeder Puffer, der beim Setzen des Offsets traversiert wird, wird als verarbeitet (siehe [[alGetSource]] mit Token [[alGetSource#AL_BUFFERS_PROCESSED|AL_BUFFERS_PROCESSED]]) markiert. Der Wert basiert auf der Byteposition, sodass ein mit '''AL_PITCH''' verändertes Source-Objekt eine überspitzte Abspielgeschwindigkeit hat. Zum Beispiel kann ein Puffer ein Offset von 0,50 Sekunden haben, jedoch dauert es nur 0,25 Sekunden, dahin zu gelangen, wenn der '''AL_PITCH'''-Wert auf 2,0 gesetzt ist. Für das Setzen des Offsets ist jeder Wert größer gleich 0,0 zulässig, ein Vorgabewert ist nicht definiert. Der Parameter '''AL_SEC_OFFSET''' ist nur für die Funktionsvarianten '''alSourcef''', '''alSourcefv''', '''alSourcei''' und '''alSourceiv''' zulässig.<br />
<br />
=== AL_SOURCE_RELATIVE ===<br />
: Legt fest, ob die Position, Geschwindigkeit, Richtung und der Schallkegel relativ zum Listener-Objekt interpretiert werden oder nicht. Bei einem Wert von '''AL_TRUE''' sind die Angaben relativ zu sehen, bei '''AL_FALSE''' nicht. Vorgabewert ist '''AL_FALSE'''. '''AL_SOURCE_RELATIVE''' ist nur für die Funktionsvarianten '''alSourcei''' und '''alSourceiv''' als Parameterwert zulässig.<br />
<br />
=== AL_SOURCE_STATE ===<br />
: (unvollständig)<br />
<br />
=== AL_VELOCITY ===<br />
: Setzt die Geschwindigkeit (Schnelligkeit und Richtung) des Source-Objektes im Koordinatensystem. Jedes Tripel aus gültigen Gleitkommawerten ist erlaubt, abgesehen von [[NaN]]. Der Vorgabewert ist (0.0, 0.0, 0.0). Die Geschwindigkeit beeinflußt jedoch nicht die Position des Objektes. [[OpenAL]] berechnet die Geschwindigkeit nicht aus aufeinanderfolgenden Änderungen mit '''AL_POSITION''', ebenso wenig wird die Position des Objektes über die Zeit anhand der angegebenen Geschwindigkeit angepasst. Jede derartige Berechnung bleibt der Anwendung überlassen. Für die Belange der Soundverarbeitung sind Position und Geschwindigkeit unabhängige Parameter, die sich auf verschiedene Aspekte des Klangs auswirken. '''AL_VELOCITY''' wird von Treiber berücksichtigt, um den vom Hörer wahrgenommenen Dopplereffekt zu berechnen, was auf Grundlage der Geschwindigkeit des Source-Objektes, des Listener-Objektes und der dopplereffektbezogenen Paramater geschieht. '''AL_VELOCITY''' ist nur für die Funktionsvarianten '''alSourcefv''', '''alSource3f''', '''alSourceiv''' und '''alSource3i''' als Paramater zulässig.<br />
<br />
<br />
<br />
== Hinweise ==<br />
Falls bei der Ausführung ein Fehler auftritt, kann dieser mit [[alGetError]] erfragt werden.<br />
<br />
<br />
<br />
== Änderungen ==<br />
Folgende Erweiterungen hat die Funktion erfahren:<br />
=== Ab OpenAL-Version 1.1 ===<br />
<br />
Seit OpenAL-Version 1.1 existieren auch die Funktionen für mehrere Ganzzahlwerte, '''alSource3i''' und '''alSourceiv'''.<br />
<br />
Ebenso sind die Token '''AL_BYTE_OFFSET''', '''AL_SAMPLE_OFFSET''' und '''AL_SEC_OFFSET''' erst ab Version 1.1 verfügbar. Jedoch gibt es dafür auch die OpenAL-Erweiterung '''AL_EXT_OFFSET''', welche von jeder Implementation der Open AL 1.1 unterstützt wird und es einer für die Spezifikation von OpenAL 1.0 geschriebenen aber auf eine Implementation der Version 1.1 zugreifenden Anwendung erlaubt, die drei genannten Tokenwerte auch zum Setzen (und Abfragen) der entsprechenden Werte zu nutzen.<br />
<br />
<br />
<br />
== Fehlermeldungen ==<br />
'''AL_INVALID_ENUM''' wird generiert, wenn der Wert für ''param'' unzulässig ist.<br />
<br />
'''AL_INVALID_NAME''' wird generiert, sofern ''source'' kein gültiges Source-Objekt ist. (Siehe auch [[alIsSource]].)<br />
<br />
'''AL_INVALID_OPERATION''' wird generiert, falls es keinen aktuellen Kontext gibt. (Siehe dazu auch [[alcMakeContextCurrent]].)<br />
<br />
'''AL_INVALID_VALUE''' wird generiert, wenn der zu setzenden Wert den zulässigen Bereich überschreitet.<br />
<br />
<br />
<br />
== Zugehörige Wertrückgaben ==<br />
[[alGetSource]] mit den oben genannten Tokenwerten liefert die gesetzten Werte zurück.<br />
<br />
<br />
<br />
== Siehe auch ==<br />
[[alGetSource]], [[alListener]] (analoge Funktion für Listener-Objekte)<br />
<br />
[[Kategorie:AL|Source]]</div>Igel457https://wiki.delphigl.com/index.php?title=alSource&diff=24330alSource2009-11-24T14:47:05Z<p>Igel457: /* AL_REFERENCE_DISTANCE */</p>
<hr />
<div>{{Unvollständig|Die Beschreibung zu den Auswirkungen des Funktionsparameters ''param'' muss noch ergänzt werden. Als Grundlage kann die [http://www.openal.org/documentation.html Open AL-Dokumentation] dienen.}}<br />
= alSource =<br />
<br />
<br />
<br />
== Name ==<br />
'''alSource''' - Setzt Eigenschaften eines Source-Objektes.<br />
<br />
<br />
<br />
== Delphi-Spezifikation ==<br />
procedure '''alSourcef'''(''source'': TALuint; ''param'': TALenum; ''value'': TALfloat);<br />
procedure '''alSource3f'''(''source'': TALuint; ''param'': TALenum; ''v1'': TALfloat; ''v2'': TALfloat; ''v3'': TALfloat);<br />
procedure '''alSourcefv'''(''source'': TALuint; ''param'': TALenum; ''values'': PALfloat);<br />
procedure '''alSourcei'''(''source'': TALuint; ''param'': TALenum; ''value'': TALint);<br />
procedure '''alSource3i'''(''source'': TALuint; ''param'': TALenum; ''v1'': TALint; ''v2'': TALint; ''v3'': TALint);<br />
procedure '''alSourceiv'''(''source'': TALuint; ''param'': TALenum; ''values'': PALint);<br />
<br />
<br />
<br />
== Parameter ==<br />
<br />
{| border="1" rules="all"<br />
! ''source'' <br />
| Name des Source-Objektes, dessen Eigenschaft geändert werden soll<br />
|-<br />
! ''param'' <br />
| Symbolische Konstante, welche die zu setzende Eigenschaft angibt<br />
|-<br />
! ''value'' <br />
| TALfloat-/ TALint-Wert, der gesetzt werden soll (nur bei '''alSourcef''' bzw. '''alSourcei''')<br />
|-<br />
! ''values'' <br />
| Zeiger auf einen TALfloat-/ TALint-Vektor, welcher die zu setzenden Werte enthält (nur bei '''alSourcefv''' und '''alSourceiv''')<br />
|-<br />
! ''v1, v2, v3'' <br />
| TALfloat-/ TALint-Werte, welche die zu setzenden Werte angeben (nur bei '''alSource3f''' und '''alSource3i''')<br />
|}<br />
<br />
<br />
<br />
== Beschreibung == <br />
Die Funktion '''alSource''' bzw. ihre Varianten für verschiedene Wertargumente setzen Eigenschaften eines Source-Objektes der [[OpenAL]]. Welche Eigenschaft gesetzt wird, hängt vom Wert des Parameters ''param'' ab.<br />
<br />
Folgende Werte sind für ''param'' zulässig:<br />
=== AL_BUFFER ===<br />
: Legt den aktuellen Puffer fest und macht ihn zum ersten Eintrag in der Pufferwarteschlange des Source-Objektes. Der Vorgabewert ist '''AL_NONE''', zulässige Werte sind alle gültigen Puffernamen (siehe dazu auch [[alIsBuffer]]). Wird '''alSource''' mit dem Parameter '''AL_BUFFER''' auf ein Source-Objekt im Zustand '''AL_INITIAL''' oder '''AL_STOPPED''' angewendet, so wird die gesamte Pufferwarteschlange geleert und der angegebene Puffer an das Source-Objekt angehangen.<br />
<br />
: Für ein Source-Objekt im Zustand '''AL_PLAYING''' oder '''AL_PAUSED''' wird der Versuch, mit '''AL_BUFFER''' einen Wert zu setzen, den Fehlerstatus '''AL_INVALID_OPERATION''' setzen. '''AL_BUFFER''' kann nur auf Source-Objekte im Zustand '''AL_STOPPED''' oder '''AL_INITIAL''' angewendet werden. Die Angabe eines ungültigen Puffernamens, sei es weil dieser Puffer nicht existiert oder nicht an das Source-Objekt angehängt werden kann, setzt den Fehlerstatus '''AL_INVALID_VALUE''', während die Angabe eines ungültigen Source-Objektes den Fehlerstatus '''AL_INVALID_NAME''' zur Folge hat.<br />
<br />
: '''AL_NONE''' ('''nil''' oder 0) ist ein gültiger Puffername. Der Aufruf alSourcei(sourceName, AL_BUFFER, AL_NONE) ist eine zulässige Möglichkeit, die aktuelle Pufferwarteschlange eines Source-Objektes freizugeben, egal ob die Pufferwarteschlange nur einen Eintrag (den aktuellen Puffer) oder mehrer hat. Jedoch verursacht der Funktionsaufruf alSourcei(sourceName, AL_BUFFER, AL_NONE) immer noch einen '''AL_INVALID_OPERATION'''-Fehlerstatus für ein im Zustand '''AL_PLAYING''' oder '''AL_PAUSED''' befindliches Source-Objekt und kann folgerichtig nicht genutzt werden, um ein Source-Objekt anzuhalten (siehe dazu [[alSourceStop]]) oder stummzuschalten. Der Paramater '''AL_BUFFER''' ist nur für die Funktionsvarianten '''alSourcei''' und '''alSourceiv''' zugelassen.<br />
<br />
=== AL_BYTE_OFFEST ===<br />
: Legt die Abpspielposition, ausgedrückt in Bytes, fest. Für Source-Objekte im Zustand '''AL_LOOPING''' wird dieser Wert wieder auf null zurückspringen, sobald die Wiedergabe wieder von vorn beginnt. Im Falle eines komprimierten Audioformates kann es sein, dass dieser Wert nur einen genäherten Wert innerhalb der komprimierten Daten angibt. Wird das Offset für ein Source-Objekt gesetzt, welches gerade Audiodaten abspielt, springt die Wiedergabe zur neuen Position, es sei denn der angegebene Wert ist außerhalb des zulässigen Bereichs, wodurch ein '''AL_INVALID_VALUE'''-Fehler generiert wird. Falls das Source-Objekt gerade keine Audiodaten abspielt, wird die Offsetänderung beim nächsten zugehörigen Aufruf von [[alSourcePlay]] durchgeführt. Ein Aufruf von [[alSourceStop]], [[alSourceRewind]] oder ein zweiter Aufruf von [[alSourcePlay]] setzt das Offset zurück auf den Anfang des Puffers. Die Position ist relativ zum Anfang aller dem Source-Objekt angehängten Puffer, und jeder Puffer, der beim Setzen des Offsets traversiert wird, wird als verarbeitet (siehe [[alGetSource]] mit Token [[alGetSource#AL_BUFFERS_PROCESSED|AL_BUFFERS_PROCESSED]]) markiert. Zulässige Werte sind Werte größer oder gleich null, ein Vorgabewert ist nicht festgelegt. '''AL_BYTE_OFFSET''' ist nur für die Funktionsvarianten '''alSourcef''', '''alSourcefv''', '''alSourcei''' und '''alSourceiv''' zulässig.<br />
<br />
=== AL_CONE_INNER_ANGLE ===<br />
: (unvollständig)<br />
<br />
=== AL_CONE_OUTER_ANGLE ===<br />
: (unvollständig)<br />
<br />
=== AL_CONE_OUTER_GAIN ===<br />
: (unvollständig)<br />
<br />
=== AL_DIRECTION ===<br />
: Legt die Ausrichtung eines Source-Objektes fest. Falls der '''AL_DIRECTION'''-Wert ungleich dem Nullvektor ist, so handelt es sich um ein gerichtetes Source-Objekt. Die Geräuschemission wird als symmetrisch um den Richtungsvektor herum angenommen (Zylindersymmetrie). Der Nullvektor ist der Vorgabewert, wodurch angegeben wird, dass das Source-Objekt nicht gerichtet ist. Das Setzen eines vom Nullvektor verschiedenen, dreidimensionalen Vektors macht aus dem Source-Objekt ein gerichtetes Objekt; das Setzen des Nullvektors für ein gerichtetes Source-Objekt macht es zu einem ungerichteten Source-Objekt. Zulässig sind alle Werte außer [[NaN]]. Der Parameter '''AL_DIRECTION''' ist nur für die Funktionsvarianten '''alSourcefv''', '''alSource3f''', '''alSourceiv''' und '''alSource3i''' zulässig.<br />
<br />
=== AL_GAIN ===<br />
: Legt den skalaren Amplitudenmultiplikator für das Source-Objekt fest. Der Vorgabewert 1.0 bedeutet, dass die Geräusche ungedämpft sind. Ein Wert von 0.5 ist äquivalent zu einer Abschwächung von 6 dB. Der Wert null entspricht Stille. Die Implementierung ist dafür verantwortlich, artefaktfreie (d.h. klickgeräuschfreie) Änderungen des Wertes zu ermöglichen und kann daher die tatsächliche Änderung des Wertes innerhalb gewisser, akzeptabler Grenzen verzögern. Werte größer als eins sind zwar zulässig, jedoch steht es der Implementierung frei, Werte größer als 1,0 auf 1,0 herunterzuregeln, um einen möglichen Überlauf zu vermeiden. '''AL_GAIN''' ist nur für die Funktionsvarianten '''alSourcef''' und '''alSourcefv''' zulässig.<br />
<br />
=== AL_LOOPING ===<br />
: Legt fest, ob das Source-Objekt nicht in den Zustand '''AL_STOPPED''' wechselt, sobald es das Ende des letzten Puffers in der Pufferwarteschlange erreicht hat. In diesem Fall ist der Wert '''AL_TRUE''' zu setzen, andernfalls '''AL_FALSE'''. Der Vorgabewert für '''AL_LOOPING''' ist '''AL_FALSE'''. Ist das '''AL_LOOPING'''-Flag auf '''AL_TRUE''' gesetzt, so wechselt das Source-Objekt beim Erreichen des Endes der Pufferwarteschlange sofort wieder in den Zustand '''AL_INITIAL''' und danach in den Zustand '''AL_PLAYING''', um die Audiodaten in den zugehörigen Puffern erneut abzuspielen. Das '''AL_LOOPING'''-Flag für ein Source-Objekt kann in jedem Ausführungszustand, besonders auch im Zustand '''AL_PLAYING''', geändert werden. Zulässige Werte sind '''AL_TRUE''' und '''AL_FALSE'''. Der Paramater '''AL_LOOPING''' ist nur für die Funktionsvarianten '''alSourcei''' und '''alSourceiv''' als Paramater zugelassen.<br />
<br />
=== AL_MAX_DISTANCE ===<br />
: (unvollständig)<br />
<br />
=== AL_MAX_GAIN ===<br />
: Setzt den maximalen, erlaubten '''AL_GAIN'''-Wert für das Source-Objekt. Der Vorgabewert ist 1.0, zulässig sind alle Gleitkommawerte aus dem Intervall von 0,0 bis 1,0. Am Ende der Varabrebitung verschiedener Abschwächungs- oder Verstärkungsfaktoren wie der entfernungsbasierten Abschwächung und dem '''AL_GAIN'''-Wert des Source-Objektes wird der berechnete Effektivwert mit dem '''AL_MAX_GAIN'''-Wert verglichen. Falls der berechnete Wert größer ist als der '''AL_MAX_GAIN'''-Wert, dann wird der '''AL_MAX_GAIN'''-Wert angewendet. Dies geschieht jedoch, bevor der '''AL_GAIN'''-Wert des Listener-Objektes in Betracht gezogen wird. Wenn das Produkt aus '''AL_MAX_GAIN''' und dem '''AL_GAIN'''-Wert des Listener-Objektes immer noch den maximalen Wert, welchen die Implementierung handhaben kann, überschreitet, so steht es der Implementierung frei, den Wert zu reduzieren. Falls für '''AL_MAX_GAIN''' der Wert null gesetzt wird, so ist das Source-Objekt quasi stummgeschalten. Die vorgesehene Art, ein Source-Objekt stummzuschalten, ist jedoch, den '''AL_GAIN'''-Wert auf null zu setzen. Der Parameter '''AL_MAX_GAIN''' ist nur für die Funktionsvarianten '''alSourcef''' und '''alSourcefv''' zulässig.<br />
<br />
=== AL_MIN_GAIN ===<br />
: Legt den minimalen '''AL_GAIN'''-Wert fest, welcher für das Source-Objekt immer gewährleistet sein soll. Der Vorgabewert ist 0.0, zulässig sind alle Werte aus dem Intervall von 0,0 bis 1,0. Am Ende der Verarbeitung verschiedener Abschwächungsfaktoren wie der entfernungsbasierten Abschwächung und dem '''AL_GAIN'''-Wertes des Source-Objektes wird der berechnete Effektivwert mit dem '''AL_MIN_GAIN'''-Wert verglichen. Falls der berechnete Wert kleiner ist als '''AL_MIN_GAIN''', so wird der Wert von '''AL_MIN_GAIN''' angewendet. Dies passiert jedoch, bevor der '''AL_GAIN'''-Wert des Listener-Objektes angewendet wird. Wenn der für '''AL_MIN_GAIN''' gesetzte Wert null ist, so wird keine Korrektur vorgenommen. Der Parameter '''AL_MIN_GAIN''' ist nur für die Funktionsvarianten '''alSourcef''' und '''alSourcefv''' zugelassen.<br />
<br />
=== AL_PITCH ===<br />
: Setzt die Verschiebung der Tonhöhe/ Frequenz des Source-Objektes. Ein Wert von 1,0 entspricht der Identität (d.h. keine Verschiebung), dies ist auch der Vorgabewert. Jede Reduzierung des Wertes um 50% entspricht einer Verschiebung um 12 Halbtöne bzw. eine Oktave nach unten. Jede Verdopplung des Wertes entspricht einer Verschiebung von 12 Halbtönen bzw. einer Oktave nach oben. Null ist kein zulässiger Wert, alle Gleitkommawerte größer als null sind erlaubt. Jede Implementierung kann die '''AL_PITCH'''-Werte aber entsprechend ihrer eigenen Limitationen beschränken. '''AL_PITCH''' ist nur für die Funktionsvarianten '''alSourcef''' und '''alSourcefv''' als Parameter zugelassen.<br />
<br />
=== AL_POSITION ===<br />
: Setzt die aktuelle Position des Source-Objektes im Weltkoordinatensystem. Der Standardwert ist (0.0, 0.0, 0.0). '''AL_POSITION''' darf ''nicht'' in '''alSourcei''' oder '''alSourcef''' benutzt werden sondern nur in den Funktionsvarianten für mehrere Wertargumente, also '''alSource3f''', '''alSource3i''', '''alSourcefv''' oder '''alSourceiv'''. Erlaubt ist jedes Tripel von Fließkommawerten mit Ausnahme von [[NaN]]. Es ist nicht definiert, wie sich die Implementation verhält, falls [[NaN]] oder ein unendlicher Wert gesetzt wird.<br />
<br />
=== AL_REFERENCE_DISTANCE ===<br />
AL_REFERENCE_DISTANCE beschreibt den Abstand, bei dem der Verstärkungsfaktor der Audioquelle genau 1 beträgt.<br />
<br />
=== AL_ROLLOFF_FACTOR ===<br />
: (unvollständig)<br />
<br />
=== AL_SAMPLE_OFFSET ===<br />
: Legt die Abspielposition fest, wobei diese Position in Samples ausgedrückt wird. Für Source-Objekte im Zustand '''AL_LOOPING''' wird dieser Wert wieder auf null zurückspringen, sobald die Wiedergabe wieder von vorn beginnt. Bei Verwendung eines komprimierten Formates gibt dieser Wert das exakte Offset innerhalb der unkomprimierten Daten an. Wenn '''AL_SAMPLE_OFFSET''' für ein Source-Objekt, welches gerade Audiodaten abspielt, gesetzt wird, so springt die Wiedergabe zur angegebenen Position, es sei denn das neue Offset ist außerhalb des zulässigen Bereiches, wodurch ein '''AL_INVALID_VALUE'''-Fehlerstatus generiert wird. Falls das Source-Objekt gerade keine Audiodaten abspielt, wird die Offsetänderung beim nächsten zugehörigen Aufruf von [[alSourcePlay]] durchgeführt. Ein Aufruf von [[alSourceStop]], [[alSourceRewind]] oder ein zweiter Aufruf von [[alSourcePlay]] setzt das Offset zurück auf den Anfang des Puffers. Die Position ist relativ zum Anfang aller dem Source-Objekt angehängten Puffer, und jeder Puffer, der beim Setzen des Offsets traversiert wird, wird als verarbeitet (siehe [[alGetSource]] mit Token [[alGetSource#AL_BUFFERS_PROCESSED|AL_BUFFERS_PROCESSED]]) markiert. Zulässige Werte sind alle Werte größer oder gleich null, ein Vorgabewert ist nicht festgelegt. '''AL_SAMPLE_OFFSET''' ist nur für die Funktionsvarianten '''alSourcef''', '''alSourcefv''', '''alSourcei''' und '''alSourceiv''' zulässig.<br />
<br />
=== AL_SEC_OFFSET ===<br />
: Legt die Abspielposition fest, wobei diese Position in Sekunden ausgedrückt wird. Für Source-Objekte im Zustand '''AL_LOOPING''' wird dieser Wert wieder auf null zurückspringen, sobald die Wiedergabe wieder von vorn beginnt. Wenn '''AL_SEC_OFFSET''' für ein Source-Objekt, welches gerade Audiodaten abspielt, gesetzt wird, so springt die Wiedergabe zur angegebenen Position, es sei denn das neue Offset ist außerhalb des zulässigen Bereiches, wodurch ein '''AL_INVALID_VALUE'''-Fehlerstatus generiert wird. Falls das Source-Objekt gerade keine Audiodaten abspielt, wird die Offsetänderung beim nächsten zugehörigen Aufruf von [[alSourcePlay]] durchgeführt. Die Position ist relativ zum Anfang aller dem Source-Objekt angehängten Puffer, und jeder Puffer, der beim Setzen des Offsets traversiert wird, wird als verarbeitet (siehe [[alGetSource]] mit Token [[alGetSource#AL_BUFFERS_PROCESSED|AL_BUFFERS_PROCESSED]]) markiert. Der Wert basiert auf der Byteposition, sodass ein mit '''AL_PITCH''' verändertes Source-Objekt eine überspitzte Abspielgeschwindigkeit hat. Zum Beispiel kann ein Puffer ein Offset von 0,50 Sekunden haben, jedoch dauert es nur 0,25 Sekunden, dahin zu gelangen, wenn der '''AL_PITCH'''-Wert auf 2,0 gesetzt ist. Für das Setzen des Offsets ist jeder Wert größer gleich 0,0 zulässig, ein Vorgabewert ist nicht definiert. Der Parameter '''AL_SEC_OFFSET''' ist nur für die Funktionsvarianten '''alSourcef''', '''alSourcefv''', '''alSourcei''' und '''alSourceiv''' zulässig.<br />
<br />
=== AL_SOURCE_RELATIVE ===<br />
: Legt fest, ob die Position, Geschwindigkeit, Richtung und der Schallkegel relativ zum Listener-Objekt interpretiert werden oder nicht. Bei einem Wert von '''AL_TRUE''' sind die Angaben relativ zu sehen, bei '''AL_FALSE''' nicht. Vorgabewert ist '''AL_FALSE'''. '''AL_SOURCE_RELATIVE''' ist nur für die Funktionsvarianten '''alSourcei''' und '''alSourceiv''' als Parameterwert zulässig.<br />
<br />
=== AL_SOURCE_STATE ===<br />
: (unvollständig)<br />
<br />
=== AL_VELOCITY ===<br />
: Setzt die Geschwindigkeit (Schnelligkeit und Richtung) des Source-Objektes im Koordinatensystem. Jedes Tripel aus gültigen Gleitkommawerten ist erlaubt, abgesehen von [[NaN]]. Der Vorgabewert ist (0.0, 0.0, 0.0). Die Geschwindigkeit beeinflußt jedoch nicht die Position des Objektes. [[OpenAL]] berechnet die Geschwindigkeit nicht aus aufeinanderfolgenden Änderungen mit '''AL_POSITION''', ebenso wenig wird die Position des Objektes über die Zeit anhand der angegebenen Geschwindigkeit angepasst. Jede derartige Berechnung bleibt der Anwendung überlassen. Für die Belange der Soundverarbeitung sind Position und Geschwindigkeit unabhängige Parameter, die sich auf verschiedene Aspekte des Klangs auswirken. '''AL_VELOCITY''' wird von Treiber berücksichtigt, um den vom Hörer wahrgenommenen Dopplereffekt zu berechnen, was auf Grundlage der Geschwindigkeit des Source-Objektes, des Listener-Objektes und der dopplereffektbezogenen Paramater geschieht. '''AL_VELOCITY''' ist nur für die Funktionsvarianten '''alSourcefv''', '''alSource3f''', '''alSourceiv''' und '''alSource3i''' als Paramater zulässig.<br />
<br />
<br />
<br />
== Hinweise ==<br />
Falls bei der Ausführung ein Fehler auftritt, kann dieser mit [[alGetError]] erfragt werden.<br />
<br />
<br />
<br />
== Änderungen ==<br />
Folgende Erweiterungen hat die Funktion erfahren:<br />
=== Ab OpenAL-Version 1.1 ===<br />
<br />
Seit OpenAL-Version 1.1 existieren auch die Funktionen für mehrere Ganzzahlwerte, '''alSource3i''' und '''alSourceiv'''.<br />
<br />
Ebenso sind die Token '''AL_BYTE_OFFSET''', '''AL_SAMPLE_OFFSET''' und '''AL_SEC_OFFSET''' erst ab Version 1.1 verfügbar. Jedoch gibt es dafür auch die OpenAL-Erweiterung '''AL_EXT_OFFSET''', welche von jeder Implementation der Open AL 1.1 unterstützt wird und es einer für die Spezifikation von OpenAL 1.0 geschriebenen aber auf eine Implementation der Version 1.1 zugreifenden Anwendung erlaubt, die drei genannten Tokenwerte auch zum Setzen (und Abfragen) der entsprechenden Werte zu nutzen.<br />
<br />
<br />
<br />
== Fehlermeldungen ==<br />
'''AL_INVALID_ENUM''' wird generiert, wenn der Wert für ''param'' unzulässig ist.<br />
<br />
'''AL_INVALID_NAME''' wird generiert, sofern ''source'' kein gültiges Source-Objekt ist. (Siehe auch [[alIsSource]].)<br />
<br />
'''AL_INVALID_OPERATION''' wird generiert, falls es keinen aktuellen Kontext gibt. (Siehe dazu auch [[alcMakeContextCurrent]].)<br />
<br />
'''AL_INVALID_VALUE''' wird generiert, wenn der zu setzenden Wert den zulässigen Bereich überschreitet.<br />
<br />
<br />
<br />
== Zugehörige Wertrückgaben ==<br />
[[alGetSource]] mit den oben genannten Tokenwerten liefert die gesetzten Werte zurück.<br />
<br />
<br />
<br />
== Siehe auch ==<br />
[[alGetSource]], [[alListener]] (analoge Funktion für Listener-Objekte)<br />
<br />
[[Kategorie:AL|Source]]</div>Igel457https://wiki.delphigl.com/index.php?title=OpenAL&diff=24329OpenAL2009-11-22T11:46:14Z<p>Igel457: /* Alternativen */</p>
<hr />
<div>'''OpenAL''' ('''Open A'''udio '''L'''ibrary) ist eine plattformunabhängige [[3D Audio|3D Audio-API]]. Sie ist das Sound-Pendant zu [[OpenGL]] und somit die offene Konkurrenz zu DirectSound.<br />
<br />
Dieses Wiki verfügt über eine deutschsprachige Übersetzung der OpenAL Spezifikation. Diese ist unter [[OpenAL-Funktionsübersicht]] zu finden.<br />
<br />
==Spezifikation==<br />
Ähnlich [[OpenGL]], handelt es sich bei OpenAL lediglich um die Spezifikation einer Schnittstelle. Diese sieht unter anderem das Positionieren von Audioquellen im 3D-Raum vor. Implementierungen sind zudem in der Lage Lautstärke und Tonhöhe jeder Audioquelle zu verändern und zudem den [[Dopplereffekt]] zu simulieren.<br />
<br />
Die OpenAL-Spezifikation wurde von Creative herausgegeben und ist als direkter Konkurent zu Microsoft's Direct Sound zu sehen. Ähnlich OpenGL ist eine Schnittstelle zum Einfügen von Erweiterungen vorgesehen.<br />
<br />
Neben Hardwarebeschleunigten implementierungen der Bibliothek finden sich auch zahlreiche Softwarerenderer, zum Beispiel [http://kcat.strangesoft.net/openal.html OpenAL-Soft]. OpenAL ist leicht auf verschiedene Plattformen zu portieren und es existieren Bindings für verschiedene Programmiersprachen.<br />
<br />
OpenAL wird bereits in zahlreichen Spieletiteln verwendet.<br />
<br />
==Vor- und Nachteile==<br />
Zwar bietet OpenAL meist (unter Windows >= Vista) die einzige Möglichkeit hardwarebeschleunigtes 3D-Audio auszugeben, jedoch ist nur für bestimmte, teure Soundkarten eine entsprechende Hardwareunterstützung vorhanden. Für die meisten (OnBoard-)Soundkarten bildet OpenAL lediglich eine weitere Abstrahierungsschicht vor weiteren Audiobibliotheken wie WaveOut, DirectSound, ALSA, PulseAudio, OSS etc. Dies ist nicht unbedingt der Latenzzeit zuträglich.<br />
<br />
==Alternativen==<br />
* [http://msdn.microsoft.com/en-us/library/ee416960%28VS.85%29.aspx DirectSound] - von Microsoft entwickelte Schnittstelle für die Ausgabe von (3D-)Audio, nur unter Windows lauffähig<br />
* [[SDL]] beinhaltet ebenfalls eine Bibliothek zur Audioausgabe<br />
* [http://audorra.sourceforge.net/ Audorra] - eine Plattformübergreifende Audiobibliothek für Pascal (noch in der Entwicklung)<br />
<br />
==Siehe auch==<br />
* [http://de.wikipedia.org/wiki/OpenAL Wikipedia-Artikel zu OpenAL]<br />
* [http://connect.creativelabs.com/openal/default.aspx Offizielle Website zu OpenAL]<br />
* [http://www.noeska.com/doal Bindings für Pascal, Windows und Linux]</div>Igel457https://wiki.delphigl.com/index.php?title=OpenAL&diff=24328OpenAL2009-11-22T11:44:50Z<p>Igel457: </p>
<hr />
<div>'''OpenAL''' ('''Open A'''udio '''L'''ibrary) ist eine plattformunabhängige [[3D Audio|3D Audio-API]]. Sie ist das Sound-Pendant zu [[OpenGL]] und somit die offene Konkurrenz zu DirectSound.<br />
<br />
Dieses Wiki verfügt über eine deutschsprachige Übersetzung der OpenAL Spezifikation. Diese ist unter [[OpenAL-Funktionsübersicht]] zu finden.<br />
<br />
==Spezifikation==<br />
Ähnlich [[OpenGL]], handelt es sich bei OpenAL lediglich um die Spezifikation einer Schnittstelle. Diese sieht unter anderem das Positionieren von Audioquellen im 3D-Raum vor. Implementierungen sind zudem in der Lage Lautstärke und Tonhöhe jeder Audioquelle zu verändern und zudem den [[Dopplereffekt]] zu simulieren.<br />
<br />
Die OpenAL-Spezifikation wurde von Creative herausgegeben und ist als direkter Konkurent zu Microsoft's Direct Sound zu sehen. Ähnlich OpenGL ist eine Schnittstelle zum Einfügen von Erweiterungen vorgesehen.<br />
<br />
Neben Hardwarebeschleunigten implementierungen der Bibliothek finden sich auch zahlreiche Softwarerenderer, zum Beispiel [http://kcat.strangesoft.net/openal.html OpenAL-Soft]. OpenAL ist leicht auf verschiedene Plattformen zu portieren und es existieren Bindings für verschiedene Programmiersprachen.<br />
<br />
OpenAL wird bereits in zahlreichen Spieletiteln verwendet.<br />
<br />
==Vor- und Nachteile==<br />
Zwar bietet OpenAL meist (unter Windows >= Vista) die einzige Möglichkeit hardwarebeschleunigtes 3D-Audio auszugeben, jedoch ist nur für bestimmte, teure Soundkarten eine entsprechende Hardwareunterstützung vorhanden. Für die meisten (OnBoard-)Soundkarten bildet OpenAL lediglich eine weitere Abstrahierungsschicht vor weiteren Audiobibliotheken wie WaveOut, DirectSound, ALSA, PulseAudio, OSS etc. Dies ist nicht unbedingt der Latenzzeit zuträglich.<br />
<br />
==Alternativen==<br />
* [http://msdn.microsoft.com/en-us/library/ee416960%28VS.85%29.aspx DirectSound] - von Microsoft entwickelte Schnittstelle für die Ausgabe von (3D-)Audio, nur unter Windows lauffähig<br />
* [http://audorra.sourceforge.net/ Audorra] - eine Plattformübergreifende Audiobibliothek für Pascal (noch in der Entwicklung)<br />
<br />
==Siehe auch==<br />
* [http://de.wikipedia.org/wiki/OpenAL Wikipedia-Artikel zu OpenAL]<br />
* [http://connect.creativelabs.com/openal/default.aspx Offizielle Website zu OpenAL]<br />
* [http://www.noeska.com/doal Bindings für Pascal, Windows und Linux]</div>Igel457https://wiki.delphigl.com/index.php?title=Datei:surround_sound_7_1.png&diff=24314Datei:surround sound 7 1.png2009-11-07T17:30:35Z<p>Igel457: Anordnung der Lautsprecher in einem 7.1 System.</p>
<hr />
<div>Anordnung der Lautsprecher in einem 7.1 System.</div>Igel457https://wiki.delphigl.com/index.php?title=3D_Audio&diff=243133D Audio2009-11-07T17:30:09Z<p>Igel457: /* Gängige Lautsprecheranordnungen */</p>
<hr />
<div>Unter '''3D Audio''' versteht man allgemein die Wiedergabe von Soundeffekten über mehr als zwei Lautsprecher. Die Soundeffekte werden dabei an einen virtuellen Emitter gekoppelt und je nach Winkel und Entfernung zu einem virtuellen Hörer mit unterschiedlicher Lautstärke auf den Lautsprechern ausgegeben.<br />
<br />
Durch die Kopplung mit verschiedensten Audioeffekten (Reverb, High-/Lowpass Filter) soll somit ein möglichst realistischer Raumklangeindruck erzeugt werden.<br />
<br />
Während z.B. bei Filmen die "Surround"-Toninformationen nebst Effekten für alle Lautsprecher vorberechnet sind, werden diese bei Computerspielen in Echtzeit für jeden Lautsprecher berechnet. Hierzu werden Bibliotheken wie [[OpenAL]] oder [[DirectSound]] eingesetzt.<br />
<br />
==Kanalabhängige Lautstärkeberechnung==<br />
<br />
{|<br />
|Soll ein Soundeffekt in einer Lautsprecherumgebung wiedergegeben werden, so muss man in der Lage sein in Abhängigkeit vom Winkel des Effektes zum Hörer den Amplitudenfaktor für jeden Lautsprecherkanal zu berechnen.<br />
<br />
Dafür werden die Vektoren vx und v(x+1) als Basis für einen Vektorraum angesehen. Nun wird der Richtungsvektor s1 in diesen Vektorraum übersetzt und normalisiert. Die X-Komponente des somit entstandenen Vektors wird auf den Amplitudenfaktor (gf, "Gain Factor") des Lautsprechers X und die Y-Komponente auf die des Lautsprechers X+1 addiert, sofern deren Wert > 0. Dies wird für alle Lautsprecher X wiederholt. Die entstandenen Faktoren werden durch zwei geteilt.<br />
<br />
[[Datei:surround_sound_eq01.png]]<br />
<br />
|[[Datei:surround_sound_calc01.png]]<br />
|}<br />
<br />
==Gängige Lautsprecheranordnungen==<br />
<br />
In der nachfolgenen Tabelle werden die heute gängigen Lautsprecheranordnungen für Surroundsound Systeme aufgeführt:<br />
<br />
{|{{Prettytable_B1}}<br />
|-<br />
|'''System'''<br />
|'''Beispielanordnung'''<br />
|-<br />
|'''Stereo (2.0)'''<br><br />
Zwei Lautsprecher, die im Optimalfall im 45° vom Hörer weg angeordnet sind, bilden das Stereo System. Töne, die hinter dem Betrachter ausgestrahlt werden können nicht wahrgenommen werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_2_0.png]]<br />
<br />
|-<br />
|'''3.0 Sound'''<br><br />
Drei Lautsprecher bilden eine "Linie". Somit können Soundeffekte, die sich im vorderen Bereich des Hörers befinden recht gut aufgelöst werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -30°<br />
|-<br />
|Center<br />
| 0°<br />
|-<br />
|Front Right<br />
| 35°<br />
|}<br />
<br />
|[[Datei:surround_sound_3_0.png]]<br />
<br />
<br />
|-<br />
|'''4.0 Surround Sound'''<br><br />
Bei 4.0 Surround Sound sind vier Lautsprecher im Winkel von je 90° um den Hörer angeordnet. Diese Technik, auch als "Quadrophonie" bezeichnet, fand schon in den 1970er Jahren Anwendung, als ein Nachfolgeformat zu Stereo etabliert werden sollte. Die naheliegende Vermutung, mit 4x90° das gesammte Hörfeld abdecken zu können und somit einen echten räumlichen Klang zu erzeugen, erwies sich jedoch als falsch. Heutzutage findet man seltener Anlagen mit 4 Lautsprechern - eher werden 6 (5.1) oder 8 (7.1) Lautsprecher verwendet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Rear Left<br />
| -135°<br />
|-<br />
|Rear Right<br />
| 135°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_4_0.png]]<br />
<br />
|-<br />
|'''5.1 Surround Sound'''<br><br />
<br />
Beim 5.1 Surround System existieren - im Gegensatz zur Quadrophonie - zwei weitere Lautsprecher. Ein zusätzlicher "Center" Lautsprecher sorgt für die notwendige Auflösung im Frontalbereich des Hörers. Dabei sind die "Front-Left" und "Front-Right" Lautsprecher nicht mehr im 45° sondern im 30° Winkel angeordnet.<br />
<br />
Ein so genannter Subwoofer ist für die wiedergabe niedriger Frequenzen verantwortlich. Da Töne einer Frequenz unterhalb einer gewissen Schwelle nicht mehr lokalisiert werden können, ist die Position des Subwoofers unerheblich für den Raumklang. Gleichzeitig müssen die Satelitenlautsprecher keine niedrigen Frequenzen mehr wiedergeben und können somit kompakter gebaut werden. Der Kanal für den Subwoofer wird als LFE-Channel (Low Frequency Effects) bezeichnet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Center<br />
| 0°<br />
|-<br />
|Front Left<br />
| -30°<br />
|-<br />
|Rear Left<br />
| -110°<br />
|-<br />
|Rear Right<br />
| 110°<br />
|-<br />
|Front Right<br />
| 30°<br />
|}<br />
<br />
|[[Datei:surround_sound_5_1.png]]<br />
<br />
|-<br />
|'''7.1 Surround Sound'''<br><br />
<br />
Zwei weitere Lautsprecher vervollständigen den Raumklang bei einem 7.1 System.<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Center<br />
| 0°<br />
|-<br />
|Front Left<br />
| -30°<br />
|-<br />
|Side Left<br />
| -90°<br />
|-<br />
|Rear Left<br />
| -150°<br />
|-<br />
|Rear Right<br />
| 150°<br />
|-<br />
|Side Right<br />
| 90°<br />
|-<br />
|Front Right<br />
| 30°<br />
|}<br />
<br />
|[[Datei:surround_sound_7_1.png]]<br />
<br />
<br />
<br />
|}<br />
<br />
== Siehe auch ==<br />
* [[OpenAL]]<br />
<br />
== Weblinks ==<br />
* [http://de.wikipedia.org/wiki/Quadrofonie| Wikipedia: Quadrofonie]<br />
* [http://lib.tkk.fi/Diss/2001/isbn9512255324/article1.pdf| Paper "Virtual Sound Source Positioning"]</div>Igel457https://wiki.delphigl.com/index.php?title=3D_Audio&diff=243123D Audio2009-11-07T17:25:09Z<p>Igel457: /* Kanalabhängige Lautstärkeberechnung */</p>
<hr />
<div>Unter '''3D Audio''' versteht man allgemein die Wiedergabe von Soundeffekten über mehr als zwei Lautsprecher. Die Soundeffekte werden dabei an einen virtuellen Emitter gekoppelt und je nach Winkel und Entfernung zu einem virtuellen Hörer mit unterschiedlicher Lautstärke auf den Lautsprechern ausgegeben.<br />
<br />
Durch die Kopplung mit verschiedensten Audioeffekten (Reverb, High-/Lowpass Filter) soll somit ein möglichst realistischer Raumklangeindruck erzeugt werden.<br />
<br />
Während z.B. bei Filmen die "Surround"-Toninformationen nebst Effekten für alle Lautsprecher vorberechnet sind, werden diese bei Computerspielen in Echtzeit für jeden Lautsprecher berechnet. Hierzu werden Bibliotheken wie [[OpenAL]] oder [[DirectSound]] eingesetzt.<br />
<br />
==Kanalabhängige Lautstärkeberechnung==<br />
<br />
{|<br />
|Soll ein Soundeffekt in einer Lautsprecherumgebung wiedergegeben werden, so muss man in der Lage sein in Abhängigkeit vom Winkel des Effektes zum Hörer den Amplitudenfaktor für jeden Lautsprecherkanal zu berechnen.<br />
<br />
Dafür werden die Vektoren vx und v(x+1) als Basis für einen Vektorraum angesehen. Nun wird der Richtungsvektor s1 in diesen Vektorraum übersetzt und normalisiert. Die X-Komponente des somit entstandenen Vektors wird auf den Amplitudenfaktor (gf, "Gain Factor") des Lautsprechers X und die Y-Komponente auf die des Lautsprechers X+1 addiert, sofern deren Wert > 0. Dies wird für alle Lautsprecher X wiederholt. Die entstandenen Faktoren werden durch zwei geteilt.<br />
<br />
[[Datei:surround_sound_eq01.png]]<br />
<br />
|[[Datei:surround_sound_calc01.png]]<br />
|}<br />
<br />
==Gängige Lautsprecheranordnungen==<br />
<br />
In der nachfolgenen Tabelle werden die heute gängigen Lautsprecheranordnungen für Surroundsound Systeme aufgeführt:<br />
<br />
{|{{Prettytable_B1}}<br />
|-<br />
|'''System'''<br />
|'''Beispielanordnung'''<br />
|-<br />
|'''Stereo (2.0)'''<br><br />
Zwei Lautsprecher, die im Optimalfall im 45° vom Hörer weg angeordnet sind, bilden das Stereo System. Töne, die hinter dem Betrachter ausgestrahlt werden können nicht wahrgenommen werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_2_0.png]]<br />
<br />
|-<br />
|'''3.0 Sound'''<br><br />
Drei Lautsprecher bilden eine "Linie". Somit können Soundeffekte, die sich im vorderen Bereich des Hörers befinden recht gut aufgelöst werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -30°<br />
|-<br />
|Center<br />
| 0°<br />
|-<br />
|Front Right<br />
| 35°<br />
|}<br />
<br />
|[[Datei:surround_sound_3_0.png]]<br />
<br />
<br />
|-<br />
|'''4.0 Surround Sound'''<br><br />
Bei 4.0 Surround Sound sind vier Lautsprecher im Winkel von je 90° um den Hörer angeordnet. Diese Technik, auch als "Quadrophonie" bezeichnet, fand schon in den 1970er Jahren Anwendung, als ein Nachfolgeformat zu Stereo etabliert werden sollte. Die naheliegende Vermutung, mit 4x90° das gesammte Hörfeld abdecken zu können und somit einen echten räumlichen Klang zu erzeugen, erwies sich jedoch als falsch. Heutzutage findet man seltener Anlagen mit 4 Lautsprechern - eher werden 6 (5.1) oder 8 (7.1) Lautsprecher verwendet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Rear Left<br />
| -135°<br />
|-<br />
|Rear Right<br />
| 135°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_4_0.png]]<br />
<br />
|-<br />
|'''5.1 Surround Sound'''<br><br />
<br />
Beim 5.1 Surround System existieren - im Gegensatz zur Quadrophonie - zwei weitere Lautsprecher. Ein zusätzlicher "Center" Lautsprecher sorgt für die notwendige Auflösung im Frontalbereich des Hörers. Dabei sind die "Front-Left" und "Front-Right" Lautsprecher nicht mehr im 45° sondern im 30° Winkel angeordnet.<br />
<br />
Ein so genannter Subwoofer ist für die wiedergabe niedriger Frequenzen verantwortlich. Da Töne einer Frequenz unterhalb einer gewissen Schwelle nicht mehr lokalisiert werden können, ist die Position des Subwoofers unerheblich für den Raumklang. Gleichzeitig müssen die Satelitenlautsprecher keine niedrigen Frequenzen mehr wiedergeben und können somit kompakter gebaut werden. Der Kanal für den Subwoofer wird als LFE-Channel (Low Frequency Effects) bezeichnet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Center<br />
| 0°<br />
|-<br />
|Front Left<br />
| -30°<br />
|-<br />
|Rear Left<br />
| -110°<br />
|-<br />
|Rear Right<br />
| 110°<br />
|-<br />
|Front Right<br />
| 30°<br />
|}<br />
<br />
|[[Datei:surround_sound_5_1.png]]<br />
<br />
<br />
<br />
|}<br />
<br />
== Siehe auch ==<br />
* [[OpenAL]]<br />
<br />
== Weblinks ==<br />
* [http://de.wikipedia.org/wiki/Quadrofonie| Wikipedia: Quadrofonie]<br />
* [http://lib.tkk.fi/Diss/2001/isbn9512255324/article1.pdf| Paper "Virtual Sound Source Positioning"]</div>Igel457https://wiki.delphigl.com/index.php?title=3D_Audio&diff=243113D Audio2009-11-07T17:20:10Z<p>Igel457: </p>
<hr />
<div>Unter '''3D Audio''' versteht man allgemein die Wiedergabe von Soundeffekten über mehr als zwei Lautsprecher. Die Soundeffekte werden dabei an einen virtuellen Emitter gekoppelt und je nach Winkel und Entfernung zu einem virtuellen Hörer mit unterschiedlicher Lautstärke auf den Lautsprechern ausgegeben.<br />
<br />
Durch die Kopplung mit verschiedensten Audioeffekten (Reverb, High-/Lowpass Filter) soll somit ein möglichst realistischer Raumklangeindruck erzeugt werden.<br />
<br />
Während z.B. bei Filmen die "Surround"-Toninformationen nebst Effekten für alle Lautsprecher vorberechnet sind, werden diese bei Computerspielen in Echtzeit für jeden Lautsprecher berechnet. Hierzu werden Bibliotheken wie [[OpenAL]] oder [[DirectSound]] eingesetzt.<br />
<br />
==Kanalabhängige Lautstärkeberechnung==<br />
<br />
{|<br />
|Soll ein Soundeffekt in einer Lautsprecherumgebung wiedergegeben werden, so muss man in der Lage sein in Abhängigkeit vom Winkel des Effektes zum Hörer den Amplitudenfaktor für jeden Lautsprecherkanal zu berechnen.<br />
<br />
Dafür werden die Vektoren vx und v(x+1) als Basis für einen Vektorraum angesehen. Nun wird der Richtungsvektor s1 in diesen Vektorraum übersetzt und normalisiert. Die X-Komponente des somit entstandenen Vektors wird auf den Amplitudenfaktor (gf, "Gain Factor") des Lautsprechers X und die Y-Komponente auf die des Lautsprechers X+1 addiert, sofern deren Wert > 0. Dies wird für alle Lautsprecher X wiederholt. Die entstandenen Faktoren werden durch zwei geteilt.<br />
<br />
[[Datei:surround_sound_eq01.png]]<br />
|[[Datei:surround_sound_calc01.png]]<br />
|}<br />
<br />
==Gängige Lautsprecheranordnungen==<br />
<br />
In der nachfolgenen Tabelle werden die heute gängigen Lautsprecheranordnungen für Surroundsound Systeme aufgeführt:<br />
<br />
{|{{Prettytable_B1}}<br />
|-<br />
|'''System'''<br />
|'''Beispielanordnung'''<br />
|-<br />
|'''Stereo (2.0)'''<br><br />
Zwei Lautsprecher, die im Optimalfall im 45° vom Hörer weg angeordnet sind, bilden das Stereo System. Töne, die hinter dem Betrachter ausgestrahlt werden können nicht wahrgenommen werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_2_0.png]]<br />
<br />
|-<br />
|'''3.0 Sound'''<br><br />
Drei Lautsprecher bilden eine "Linie". Somit können Soundeffekte, die sich im vorderen Bereich des Hörers befinden recht gut aufgelöst werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -30°<br />
|-<br />
|Center<br />
| 0°<br />
|-<br />
|Front Right<br />
| 35°<br />
|}<br />
<br />
|[[Datei:surround_sound_3_0.png]]<br />
<br />
<br />
|-<br />
|'''4.0 Surround Sound'''<br><br />
Bei 4.0 Surround Sound sind vier Lautsprecher im Winkel von je 90° um den Hörer angeordnet. Diese Technik, auch als "Quadrophonie" bezeichnet, fand schon in den 1970er Jahren Anwendung, als ein Nachfolgeformat zu Stereo etabliert werden sollte. Die naheliegende Vermutung, mit 4x90° das gesammte Hörfeld abdecken zu können und somit einen echten räumlichen Klang zu erzeugen, erwies sich jedoch als falsch. Heutzutage findet man seltener Anlagen mit 4 Lautsprechern - eher werden 6 (5.1) oder 8 (7.1) Lautsprecher verwendet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Rear Left<br />
| -135°<br />
|-<br />
|Rear Right<br />
| 135°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_4_0.png]]<br />
<br />
|-<br />
|'''5.1 Surround Sound'''<br><br />
<br />
Beim 5.1 Surround System existieren - im Gegensatz zur Quadrophonie - zwei weitere Lautsprecher. Ein zusätzlicher "Center" Lautsprecher sorgt für die notwendige Auflösung im Frontalbereich des Hörers. Dabei sind die "Front-Left" und "Front-Right" Lautsprecher nicht mehr im 45° sondern im 30° Winkel angeordnet.<br />
<br />
Ein so genannter Subwoofer ist für die wiedergabe niedriger Frequenzen verantwortlich. Da Töne einer Frequenz unterhalb einer gewissen Schwelle nicht mehr lokalisiert werden können, ist die Position des Subwoofers unerheblich für den Raumklang. Gleichzeitig müssen die Satelitenlautsprecher keine niedrigen Frequenzen mehr wiedergeben und können somit kompakter gebaut werden. Der Kanal für den Subwoofer wird als LFE-Channel (Low Frequency Effects) bezeichnet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Center<br />
| 0°<br />
|-<br />
|Front Left<br />
| -30°<br />
|-<br />
|Rear Left<br />
| -110°<br />
|-<br />
|Rear Right<br />
| 110°<br />
|-<br />
|Front Right<br />
| 30°<br />
|}<br />
<br />
|[[Datei:surround_sound_5_1.png]]<br />
<br />
<br />
<br />
|}<br />
<br />
== Siehe auch ==<br />
* [[OpenAL]]<br />
<br />
== Weblinks ==<br />
* [http://de.wikipedia.org/wiki/Quadrofonie| Wikipedia: Quadrofonie]<br />
* [http://lib.tkk.fi/Diss/2001/isbn9512255324/article1.pdf| Paper "Virtual Sound Source Positioning"]</div>Igel457https://wiki.delphigl.com/index.php?title=3D_Audio&diff=243103D Audio2009-11-07T17:19:55Z<p>Igel457: /* Kanalabhängige Lautstärkeberechnung */</p>
<hr />
<div>{{Unvollständig}}<br />
<br />
Unter '''3D Audio''' versteht man allgemein die Wiedergabe von Soundeffekten über mehr als zwei Lautsprecher. Die Soundeffekte werden dabei an einen virtuellen Emitter gekoppelt und je nach Winkel und Entfernung zu einem virtuellen Hörer mit unterschiedlicher Lautstärke auf den Lautsprechern ausgegeben.<br />
<br />
Durch die Kopplung mit verschiedensten Audioeffekten (Reverb, High-/Lowpass Filter) soll somit ein möglichst realistischer Raumklangeindruck erzeugt werden.<br />
<br />
Während z.B. bei Filmen die "Surround"-Toninformationen nebst Effekten für alle Lautsprecher vorberechnet sind, werden diese bei Computerspielen in Echtzeit für jeden Lautsprecher berechnet. Hierzu werden Bibliotheken wie [[OpenAL]] oder [[DirectSound]] eingesetzt.<br />
<br />
==Kanalabhängige Lautstärkeberechnung==<br />
<br />
{|<br />
|Soll ein Soundeffekt in einer Lautsprecherumgebung wiedergegeben werden, so muss man in der Lage sein in Abhängigkeit vom Winkel des Effektes zum Hörer den Amplitudenfaktor für jeden Lautsprecherkanal zu berechnen.<br />
<br />
Dafür werden die Vektoren vx und v(x+1) als Basis für einen Vektorraum angesehen. Nun wird der Richtungsvektor s1 in diesen Vektorraum übersetzt und normalisiert. Die X-Komponente des somit entstandenen Vektors wird auf den Amplitudenfaktor (gf, "Gain Factor") des Lautsprechers X und die Y-Komponente auf die des Lautsprechers X+1 addiert, sofern deren Wert > 0. Dies wird für alle Lautsprecher X wiederholt. Die entstandenen Faktoren werden durch zwei geteilt.<br />
<br />
[[Datei:surround_sound_eq01.png]]<br />
|[[Datei:surround_sound_calc01.png]]<br />
|}<br />
<br />
==Gängige Lautsprecheranordnungen==<br />
<br />
In der nachfolgenen Tabelle werden die heute gängigen Lautsprecheranordnungen für Surroundsound Systeme aufgeführt:<br />
<br />
{|{{Prettytable_B1}}<br />
|-<br />
|'''System'''<br />
|'''Beispielanordnung'''<br />
|-<br />
|'''Stereo (2.0)'''<br><br />
Zwei Lautsprecher, die im Optimalfall im 45° vom Hörer weg angeordnet sind, bilden das Stereo System. Töne, die hinter dem Betrachter ausgestrahlt werden können nicht wahrgenommen werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_2_0.png]]<br />
<br />
|-<br />
|'''3.0 Sound'''<br><br />
Drei Lautsprecher bilden eine "Linie". Somit können Soundeffekte, die sich im vorderen Bereich des Hörers befinden recht gut aufgelöst werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -30°<br />
|-<br />
|Center<br />
| 0°<br />
|-<br />
|Front Right<br />
| 35°<br />
|}<br />
<br />
|[[Datei:surround_sound_3_0.png]]<br />
<br />
<br />
|-<br />
|'''4.0 Surround Sound'''<br><br />
Bei 4.0 Surround Sound sind vier Lautsprecher im Winkel von je 90° um den Hörer angeordnet. Diese Technik, auch als "Quadrophonie" bezeichnet, fand schon in den 1970er Jahren Anwendung, als ein Nachfolgeformat zu Stereo etabliert werden sollte. Die naheliegende Vermutung, mit 4x90° das gesammte Hörfeld abdecken zu können und somit einen echten räumlichen Klang zu erzeugen, erwies sich jedoch als falsch. Heutzutage findet man seltener Anlagen mit 4 Lautsprechern - eher werden 6 (5.1) oder 8 (7.1) Lautsprecher verwendet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Rear Left<br />
| -135°<br />
|-<br />
|Rear Right<br />
| 135°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_4_0.png]]<br />
<br />
|-<br />
|'''5.1 Surround Sound'''<br><br />
<br />
Beim 5.1 Surround System existieren - im Gegensatz zur Quadrophonie - zwei weitere Lautsprecher. Ein zusätzlicher "Center" Lautsprecher sorgt für die notwendige Auflösung im Frontalbereich des Hörers. Dabei sind die "Front-Left" und "Front-Right" Lautsprecher nicht mehr im 45° sondern im 30° Winkel angeordnet.<br />
<br />
Ein so genannter Subwoofer ist für die wiedergabe niedriger Frequenzen verantwortlich. Da Töne einer Frequenz unterhalb einer gewissen Schwelle nicht mehr lokalisiert werden können, ist die Position des Subwoofers unerheblich für den Raumklang. Gleichzeitig müssen die Satelitenlautsprecher keine niedrigen Frequenzen mehr wiedergeben und können somit kompakter gebaut werden. Der Kanal für den Subwoofer wird als LFE-Channel (Low Frequency Effects) bezeichnet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Center<br />
| 0°<br />
|-<br />
|Front Left<br />
| -30°<br />
|-<br />
|Rear Left<br />
| -110°<br />
|-<br />
|Rear Right<br />
| 110°<br />
|-<br />
|Front Right<br />
| 30°<br />
|}<br />
<br />
|[[Datei:surround_sound_5_1.png]]<br />
<br />
<br />
<br />
|}<br />
<br />
== Siehe auch ==<br />
* [[OpenAL]]<br />
<br />
== Weblinks ==<br />
* [http://de.wikipedia.org/wiki/Quadrofonie| Wikipedia: Quadrofonie]<br />
* [http://lib.tkk.fi/Diss/2001/isbn9512255324/article1.pdf| Paper "Virtual Sound Source Positioning"]</div>Igel457https://wiki.delphigl.com/index.php?title=3D_Audio&diff=243093D Audio2009-11-07T17:18:52Z<p>Igel457: /* Kanalabhängige Lautstärkeberechnung */</p>
<hr />
<div>{{Unvollständig}}<br />
<br />
Unter '''3D Audio''' versteht man allgemein die Wiedergabe von Soundeffekten über mehr als zwei Lautsprecher. Die Soundeffekte werden dabei an einen virtuellen Emitter gekoppelt und je nach Winkel und Entfernung zu einem virtuellen Hörer mit unterschiedlicher Lautstärke auf den Lautsprechern ausgegeben.<br />
<br />
Durch die Kopplung mit verschiedensten Audioeffekten (Reverb, High-/Lowpass Filter) soll somit ein möglichst realistischer Raumklangeindruck erzeugt werden.<br />
<br />
Während z.B. bei Filmen die "Surround"-Toninformationen nebst Effekten für alle Lautsprecher vorberechnet sind, werden diese bei Computerspielen in Echtzeit für jeden Lautsprecher berechnet. Hierzu werden Bibliotheken wie [[OpenAL]] oder [[DirectSound]] eingesetzt.<br />
<br />
==Kanalabhängige Lautstärkeberechnung==<br />
<br />
{|<br />
|Soll ein Soundeffekt in einer Lautsprecherumgebung wiedergegeben werden, so muss man in der Lage sein in Abhängigkeit vom Winkel des Effektes zum Hörer den Amplitudenfaktor für jeden Lautsprecherkanal zu berechnen.<br />
<br />
Dafür werden die Vektoren vx und v(x+1) als Basis für einen Vektorraum angesehen. Nun wird der Richtungsvektor s1 in diesen Vektorraum übersetzt und normalisiert. Die X-Komponente des somit entstandenen Vektors wird auf den Amplitudenfaktor des Lautsprechers X und die Y-Komponente auf die des Lautsprechers X+1 addiert, sofern deren Wert > 0. Dies wird für alle Lautsprecher X wiederholt. Die entstandenen Faktoren werden durch zwei geteilt.<br />
<br />
[[Datei:surround_sound_eq01.png]]<br />
|[[Datei:surround_sound_calc01.png]]<br />
|}<br />
<br />
==Gängige Lautsprecheranordnungen==<br />
<br />
In der nachfolgenen Tabelle werden die heute gängigen Lautsprecheranordnungen für Surroundsound Systeme aufgeführt:<br />
<br />
{|{{Prettytable_B1}}<br />
|-<br />
|'''System'''<br />
|'''Beispielanordnung'''<br />
|-<br />
|'''Stereo (2.0)'''<br><br />
Zwei Lautsprecher, die im Optimalfall im 45° vom Hörer weg angeordnet sind, bilden das Stereo System. Töne, die hinter dem Betrachter ausgestrahlt werden können nicht wahrgenommen werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_2_0.png]]<br />
<br />
|-<br />
|'''3.0 Sound'''<br><br />
Drei Lautsprecher bilden eine "Linie". Somit können Soundeffekte, die sich im vorderen Bereich des Hörers befinden recht gut aufgelöst werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -30°<br />
|-<br />
|Center<br />
| 0°<br />
|-<br />
|Front Right<br />
| 35°<br />
|}<br />
<br />
|[[Datei:surround_sound_3_0.png]]<br />
<br />
<br />
|-<br />
|'''4.0 Surround Sound'''<br><br />
Bei 4.0 Surround Sound sind vier Lautsprecher im Winkel von je 90° um den Hörer angeordnet. Diese Technik, auch als "Quadrophonie" bezeichnet, fand schon in den 1970er Jahren Anwendung, als ein Nachfolgeformat zu Stereo etabliert werden sollte. Die naheliegende Vermutung, mit 4x90° das gesammte Hörfeld abdecken zu können und somit einen echten räumlichen Klang zu erzeugen, erwies sich jedoch als falsch. Heutzutage findet man seltener Anlagen mit 4 Lautsprechern - eher werden 6 (5.1) oder 8 (7.1) Lautsprecher verwendet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Rear Left<br />
| -135°<br />
|-<br />
|Rear Right<br />
| 135°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_4_0.png]]<br />
<br />
|-<br />
|'''5.1 Surround Sound'''<br><br />
<br />
Beim 5.1 Surround System existieren - im Gegensatz zur Quadrophonie - zwei weitere Lautsprecher. Ein zusätzlicher "Center" Lautsprecher sorgt für die notwendige Auflösung im Frontalbereich des Hörers. Dabei sind die "Front-Left" und "Front-Right" Lautsprecher nicht mehr im 45° sondern im 30° Winkel angeordnet.<br />
<br />
Ein so genannter Subwoofer ist für die wiedergabe niedriger Frequenzen verantwortlich. Da Töne einer Frequenz unterhalb einer gewissen Schwelle nicht mehr lokalisiert werden können, ist die Position des Subwoofers unerheblich für den Raumklang. Gleichzeitig müssen die Satelitenlautsprecher keine niedrigen Frequenzen mehr wiedergeben und können somit kompakter gebaut werden. Der Kanal für den Subwoofer wird als LFE-Channel (Low Frequency Effects) bezeichnet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Center<br />
| 0°<br />
|-<br />
|Front Left<br />
| -30°<br />
|-<br />
|Rear Left<br />
| -110°<br />
|-<br />
|Rear Right<br />
| 110°<br />
|-<br />
|Front Right<br />
| 30°<br />
|}<br />
<br />
|[[Datei:surround_sound_5_1.png]]<br />
<br />
<br />
<br />
|}<br />
<br />
== Siehe auch ==<br />
* [[OpenAL]]<br />
<br />
== Weblinks ==<br />
* [http://de.wikipedia.org/wiki/Quadrofonie| Wikipedia: Quadrofonie]<br />
* [http://lib.tkk.fi/Diss/2001/isbn9512255324/article1.pdf| Paper "Virtual Sound Source Positioning"]</div>Igel457https://wiki.delphigl.com/index.php?title=Datei:surround_sound_calc01.png&diff=24308Datei:surround sound calc01.png2009-11-07T17:18:12Z<p>Igel457: </p>
<hr />
<div></div>Igel457https://wiki.delphigl.com/index.php?title=Datei:surround_sound_eq01.png&diff=24307Datei:surround sound eq01.png2009-11-07T17:17:51Z<p>Igel457: </p>
<hr />
<div></div>Igel457https://wiki.delphigl.com/index.php?title=3D_Audio&diff=243063D Audio2009-11-07T17:17:39Z<p>Igel457: /* Kanalabhängige Lautstärkeberechnung */</p>
<hr />
<div>{{Unvollständig}}<br />
<br />
Unter '''3D Audio''' versteht man allgemein die Wiedergabe von Soundeffekten über mehr als zwei Lautsprecher. Die Soundeffekte werden dabei an einen virtuellen Emitter gekoppelt und je nach Winkel und Entfernung zu einem virtuellen Hörer mit unterschiedlicher Lautstärke auf den Lautsprechern ausgegeben.<br />
<br />
Durch die Kopplung mit verschiedensten Audioeffekten (Reverb, High-/Lowpass Filter) soll somit ein möglichst realistischer Raumklangeindruck erzeugt werden.<br />
<br />
Während z.B. bei Filmen die "Surround"-Toninformationen nebst Effekten für alle Lautsprecher vorberechnet sind, werden diese bei Computerspielen in Echtzeit für jeden Lautsprecher berechnet. Hierzu werden Bibliotheken wie [[OpenAL]] oder [[DirectSound]] eingesetzt.<br />
<br />
==Kanalabhängige Lautstärkeberechnung==<br />
Soll ein Soundeffekt in einer Lautsprecherumgebung wiedergegeben werden, so muss man in der Lage sein in Abhängigkeit vom Winkel des Effektes zum Hörer den Amplitudenfaktor für jeden Lautsprecherkanal zu berechnen.<br />
<br />
Dafür werden die Vektoren vx und v(x+1) als Basis für einen Vektorraum angesehen. Nun wird der Richtungsvektor s1 in diesen Vektorraum übersetzt und normalisiert. Die X-Komponente des somit entstandenen Vektors wird auf den Amplitudenfaktor des Lautsprechers X und die Y-Komponente auf die des Lautsprechers X+1 addiert, sofern deren Wert > 0. Dies wird für alle Lautsprecher X wiederholt. Die entstandenen Faktoren werden durch zwei geteilt.<br />
<br />
[[Datei:surround_sound_eq01.png]]<br />
<br />
[[Datei:surround_sound_calc01.png]]<br />
<br />
==Gängige Lautsprecheranordnungen==<br />
<br />
In der nachfolgenen Tabelle werden die heute gängigen Lautsprecheranordnungen für Surroundsound Systeme aufgeführt:<br />
<br />
{|{{Prettytable_B1}}<br />
|-<br />
|'''System'''<br />
|'''Beispielanordnung'''<br />
|-<br />
|'''Stereo (2.0)'''<br><br />
Zwei Lautsprecher, die im Optimalfall im 45° vom Hörer weg angeordnet sind, bilden das Stereo System. Töne, die hinter dem Betrachter ausgestrahlt werden können nicht wahrgenommen werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_2_0.png]]<br />
<br />
|-<br />
|'''3.0 Sound'''<br><br />
Drei Lautsprecher bilden eine "Linie". Somit können Soundeffekte, die sich im vorderen Bereich des Hörers befinden recht gut aufgelöst werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -30°<br />
|-<br />
|Center<br />
| 0°<br />
|-<br />
|Front Right<br />
| 35°<br />
|}<br />
<br />
|[[Datei:surround_sound_3_0.png]]<br />
<br />
<br />
|-<br />
|'''4.0 Surround Sound'''<br><br />
Bei 4.0 Surround Sound sind vier Lautsprecher im Winkel von je 90° um den Hörer angeordnet. Diese Technik, auch als "Quadrophonie" bezeichnet, fand schon in den 1970er Jahren Anwendung, als ein Nachfolgeformat zu Stereo etabliert werden sollte. Die naheliegende Vermutung, mit 4x90° das gesammte Hörfeld abdecken zu können und somit einen echten räumlichen Klang zu erzeugen, erwies sich jedoch als falsch. Heutzutage findet man seltener Anlagen mit 4 Lautsprechern - eher werden 6 (5.1) oder 8 (7.1) Lautsprecher verwendet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Rear Left<br />
| -135°<br />
|-<br />
|Rear Right<br />
| 135°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_4_0.png]]<br />
<br />
|-<br />
|'''5.1 Surround Sound'''<br><br />
<br />
Beim 5.1 Surround System existieren - im Gegensatz zur Quadrophonie - zwei weitere Lautsprecher. Ein zusätzlicher "Center" Lautsprecher sorgt für die notwendige Auflösung im Frontalbereich des Hörers. Dabei sind die "Front-Left" und "Front-Right" Lautsprecher nicht mehr im 45° sondern im 30° Winkel angeordnet.<br />
<br />
Ein so genannter Subwoofer ist für die wiedergabe niedriger Frequenzen verantwortlich. Da Töne einer Frequenz unterhalb einer gewissen Schwelle nicht mehr lokalisiert werden können, ist die Position des Subwoofers unerheblich für den Raumklang. Gleichzeitig müssen die Satelitenlautsprecher keine niedrigen Frequenzen mehr wiedergeben und können somit kompakter gebaut werden. Der Kanal für den Subwoofer wird als LFE-Channel (Low Frequency Effects) bezeichnet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Center<br />
| 0°<br />
|-<br />
|Front Left<br />
| -30°<br />
|-<br />
|Rear Left<br />
| -110°<br />
|-<br />
|Rear Right<br />
| 110°<br />
|-<br />
|Front Right<br />
| 30°<br />
|}<br />
<br />
|[[Datei:surround_sound_5_1.png]]<br />
<br />
<br />
<br />
|}<br />
<br />
== Siehe auch ==<br />
* [[OpenAL]]<br />
<br />
== Weblinks ==<br />
* [http://de.wikipedia.org/wiki/Quadrofonie| Wikipedia: Quadrofonie]<br />
* [http://lib.tkk.fi/Diss/2001/isbn9512255324/article1.pdf| Paper "Virtual Sound Source Positioning"]</div>Igel457https://wiki.delphigl.com/index.php?title=3D_Audio&diff=243053D Audio2009-11-07T17:09:18Z<p>Igel457: /* Kanalabhängige Lautstärkeberechnung */</p>
<hr />
<div>{{Unvollständig}}<br />
<br />
Unter '''3D Audio''' versteht man allgemein die Wiedergabe von Soundeffekten über mehr als zwei Lautsprecher. Die Soundeffekte werden dabei an einen virtuellen Emitter gekoppelt und je nach Winkel und Entfernung zu einem virtuellen Hörer mit unterschiedlicher Lautstärke auf den Lautsprechern ausgegeben.<br />
<br />
Durch die Kopplung mit verschiedensten Audioeffekten (Reverb, High-/Lowpass Filter) soll somit ein möglichst realistischer Raumklangeindruck erzeugt werden.<br />
<br />
Während z.B. bei Filmen die "Surround"-Toninformationen nebst Effekten für alle Lautsprecher vorberechnet sind, werden diese bei Computerspielen in Echtzeit für jeden Lautsprecher berechnet. Hierzu werden Bibliotheken wie [[OpenAL]] oder [[DirectSound]] eingesetzt.<br />
<br />
==Kanalabhängige Lautstärkeberechnung==<br />
Soll ein Soundeffekt in einer Lautsprecherumgebung wiedergegeben werden, so muss man in der Lage sein in Abhängigkeit vom Winkel des Effektes zum Hörer den Amplitudenfaktor für jeden Lautsprecherkanal zu berechnen.<br />
<br />
Dafür werden die Vektoren vx und v(x+1) als Basis für einen Vektorraum angesehen. Nun wird der Richtungsvektor s1 in diesen Vektorraum übersetzt und normalisiert. Die X-Komponente des somit entstandenen Vektors wird auf den Amplitudenfaktor des Lautsprechers X und die Y-Komponente auf die des Lautsprechers X+1 addiert, sofern deren Wert > 0. Dies wird für alle Lautsprecher X wiederholt. Die entstandenen Faktoren werden durch zwei geteilt.<br />
<br />
==Gängige Lautsprecheranordnungen==<br />
<br />
In der nachfolgenen Tabelle werden die heute gängigen Lautsprecheranordnungen für Surroundsound Systeme aufgeführt:<br />
<br />
{|{{Prettytable_B1}}<br />
|-<br />
|'''System'''<br />
|'''Beispielanordnung'''<br />
|-<br />
|'''Stereo (2.0)'''<br><br />
Zwei Lautsprecher, die im Optimalfall im 45° vom Hörer weg angeordnet sind, bilden das Stereo System. Töne, die hinter dem Betrachter ausgestrahlt werden können nicht wahrgenommen werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_2_0.png]]<br />
<br />
|-<br />
|'''3.0 Sound'''<br><br />
Drei Lautsprecher bilden eine "Linie". Somit können Soundeffekte, die sich im vorderen Bereich des Hörers befinden recht gut aufgelöst werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -30°<br />
|-<br />
|Center<br />
| 0°<br />
|-<br />
|Front Right<br />
| 35°<br />
|}<br />
<br />
|[[Datei:surround_sound_3_0.png]]<br />
<br />
<br />
|-<br />
|'''4.0 Surround Sound'''<br><br />
Bei 4.0 Surround Sound sind vier Lautsprecher im Winkel von je 90° um den Hörer angeordnet. Diese Technik, auch als "Quadrophonie" bezeichnet, fand schon in den 1970er Jahren Anwendung, als ein Nachfolgeformat zu Stereo etabliert werden sollte. Die naheliegende Vermutung, mit 4x90° das gesammte Hörfeld abdecken zu können und somit einen echten räumlichen Klang zu erzeugen, erwies sich jedoch als falsch. Heutzutage findet man seltener Anlagen mit 4 Lautsprechern - eher werden 6 (5.1) oder 8 (7.1) Lautsprecher verwendet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Rear Left<br />
| -135°<br />
|-<br />
|Rear Right<br />
| 135°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_4_0.png]]<br />
<br />
|-<br />
|'''5.1 Surround Sound'''<br><br />
<br />
Beim 5.1 Surround System existieren - im Gegensatz zur Quadrophonie - zwei weitere Lautsprecher. Ein zusätzlicher "Center" Lautsprecher sorgt für die notwendige Auflösung im Frontalbereich des Hörers. Dabei sind die "Front-Left" und "Front-Right" Lautsprecher nicht mehr im 45° sondern im 30° Winkel angeordnet.<br />
<br />
Ein so genannter Subwoofer ist für die wiedergabe niedriger Frequenzen verantwortlich. Da Töne einer Frequenz unterhalb einer gewissen Schwelle nicht mehr lokalisiert werden können, ist die Position des Subwoofers unerheblich für den Raumklang. Gleichzeitig müssen die Satelitenlautsprecher keine niedrigen Frequenzen mehr wiedergeben und können somit kompakter gebaut werden. Der Kanal für den Subwoofer wird als LFE-Channel (Low Frequency Effects) bezeichnet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Center<br />
| 0°<br />
|-<br />
|Front Left<br />
| -30°<br />
|-<br />
|Rear Left<br />
| -110°<br />
|-<br />
|Rear Right<br />
| 110°<br />
|-<br />
|Front Right<br />
| 30°<br />
|}<br />
<br />
|[[Datei:surround_sound_5_1.png]]<br />
<br />
<br />
<br />
|}<br />
<br />
== Siehe auch ==<br />
* [[OpenAL]]<br />
<br />
== Weblinks ==<br />
* [http://de.wikipedia.org/wiki/Quadrofonie| Wikipedia: Quadrofonie]<br />
* [http://lib.tkk.fi/Diss/2001/isbn9512255324/article1.pdf| Paper "Virtual Sound Source Positioning"]</div>Igel457https://wiki.delphigl.com/index.php?title=3D_Audio&diff=243043D Audio2009-11-07T16:55:42Z<p>Igel457: </p>
<hr />
<div>{{Unvollständig}}<br />
<br />
Unter '''3D Audio''' versteht man allgemein die Wiedergabe von Soundeffekten über mehr als zwei Lautsprecher. Die Soundeffekte werden dabei an einen virtuellen Emitter gekoppelt und je nach Winkel und Entfernung zu einem virtuellen Hörer mit unterschiedlicher Lautstärke auf den Lautsprechern ausgegeben.<br />
<br />
Durch die Kopplung mit verschiedensten Audioeffekten (Reverb, High-/Lowpass Filter) soll somit ein möglichst realistischer Raumklangeindruck erzeugt werden.<br />
<br />
Während z.B. bei Filmen die "Surround"-Toninformationen nebst Effekten für alle Lautsprecher vorberechnet sind, werden diese bei Computerspielen in Echtzeit für jeden Lautsprecher berechnet. Hierzu werden Bibliotheken wie [[OpenAL]] oder [[DirectSound]] eingesetzt.<br />
<br />
==Kanalabhängige Lautstärkeberechnung==<br />
Soll ein Soundeffekt in einer Lautsprecherumgebung wiedergegeben werden, so muss man in der Lage sein in Abhängigkeit vom Winkel des Effektes zum Hörer den Amplitudenfaktor für jeden Lautsprecherkanal zu berechnen.<br />
<br />
==Gängige Lautsprecheranordnungen==<br />
<br />
In der nachfolgenen Tabelle werden die heute gängigen Lautsprecheranordnungen für Surroundsound Systeme aufgeführt:<br />
<br />
{|{{Prettytable_B1}}<br />
|-<br />
|'''System'''<br />
|'''Beispielanordnung'''<br />
|-<br />
|'''Stereo (2.0)'''<br><br />
Zwei Lautsprecher, die im Optimalfall im 45° vom Hörer weg angeordnet sind, bilden das Stereo System. Töne, die hinter dem Betrachter ausgestrahlt werden können nicht wahrgenommen werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_2_0.png]]<br />
<br />
|-<br />
|'''3.0 Sound'''<br><br />
Drei Lautsprecher bilden eine "Linie". Somit können Soundeffekte, die sich im vorderen Bereich des Hörers befinden recht gut aufgelöst werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -30°<br />
|-<br />
|Center<br />
| 0°<br />
|-<br />
|Front Right<br />
| 35°<br />
|}<br />
<br />
|[[Datei:surround_sound_3_0.png]]<br />
<br />
<br />
|-<br />
|'''4.0 Surround Sound'''<br><br />
Bei 4.0 Surround Sound sind vier Lautsprecher im Winkel von je 90° um den Hörer angeordnet. Diese Technik, auch als "Quadrophonie" bezeichnet, fand schon in den 1970er Jahren Anwendung, als ein Nachfolgeformat zu Stereo etabliert werden sollte. Die naheliegende Vermutung, mit 4x90° das gesammte Hörfeld abdecken zu können und somit einen echten räumlichen Klang zu erzeugen, erwies sich jedoch als falsch. Heutzutage findet man seltener Anlagen mit 4 Lautsprechern - eher werden 6 (5.1) oder 8 (7.1) Lautsprecher verwendet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Rear Left<br />
| -135°<br />
|-<br />
|Rear Right<br />
| 135°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_4_0.png]]<br />
<br />
|-<br />
|'''5.1 Surround Sound'''<br><br />
<br />
Beim 5.1 Surround System existieren - im Gegensatz zur Quadrophonie - zwei weitere Lautsprecher. Ein zusätzlicher "Center" Lautsprecher sorgt für die notwendige Auflösung im Frontalbereich des Hörers. Dabei sind die "Front-Left" und "Front-Right" Lautsprecher nicht mehr im 45° sondern im 30° Winkel angeordnet.<br />
<br />
Ein so genannter Subwoofer ist für die wiedergabe niedriger Frequenzen verantwortlich. Da Töne einer Frequenz unterhalb einer gewissen Schwelle nicht mehr lokalisiert werden können, ist die Position des Subwoofers unerheblich für den Raumklang. Gleichzeitig müssen die Satelitenlautsprecher keine niedrigen Frequenzen mehr wiedergeben und können somit kompakter gebaut werden. Der Kanal für den Subwoofer wird als LFE-Channel (Low Frequency Effects) bezeichnet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Center<br />
| 0°<br />
|-<br />
|Front Left<br />
| -30°<br />
|-<br />
|Rear Left<br />
| -110°<br />
|-<br />
|Rear Right<br />
| 110°<br />
|-<br />
|Front Right<br />
| 30°<br />
|}<br />
<br />
|[[Datei:surround_sound_5_1.png]]<br />
<br />
<br />
<br />
|}<br />
<br />
== Siehe auch ==<br />
* [[OpenAL]]<br />
<br />
== Weblinks ==<br />
* [http://de.wikipedia.org/wiki/Quadrofonie| Wikipedia: Quadrofonie]<br />
* [http://lib.tkk.fi/Diss/2001/isbn9512255324/article1.pdf| Paper "Virtual Sound Source Positioning"]</div>Igel457https://wiki.delphigl.com/index.php?title=3D_Audio&diff=243033D Audio2009-11-07T16:50:44Z<p>Igel457: /* Gängige Lautsprecheranordnungen */</p>
<hr />
<div>{{Unvollständig}}<br />
<br />
Unter '''3D Audio''' versteht man allgemein die Wiedergabe von Soundeffekten über mehr als zwei Lautsprecher. Die Soundeffekte werden dabei an einen virtuellen Emitter gekoppelt und je nach Winkel und Entfernung zu einem virtuellen Hörer mit unterschiedlicher Lautstärke auf den Lautsprechern ausgegeben.<br />
<br />
Durch die Kopplung mit verschiedensten Audioeffekten (Reverb, High-/Lowpass Filter) soll somit ein möglichst realistischer Raumklangeindruck erzeugt werden.<br />
<br />
Während z.B. bei Filmen die "Surround"-Toninformationen nebst Effekten für alle Lautsprecher vorberechnet sind, werden diese bei Computerspielen in Echtzeit für jeden Lautsprecher berechnet. Hierzu werden Bibliotheken wie [[OpenAL]] oder [[DirectSound]] eingesetzt.<br />
<br />
==Gängige Lautsprecheranordnungen==<br />
<br />
In der nachfolgenen Tabelle werden die heute gängigen Lautsprecheranordnungen für Surroundsound Systeme aufgeführt:<br />
<br />
{|{{Prettytable_B1}}<br />
|-<br />
|'''System'''<br />
|'''Beispielanordnung'''<br />
|-<br />
|'''Stereo (2.0)'''<br><br />
Zwei Lautsprecher, die im Optimalfall im 45° vom Hörer weg angeordnet sind, bilden das Stereo System. Töne, die hinter dem Betrachter ausgestrahlt werden können nicht wahrgenommen werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_2_0.png]]<br />
<br />
|-<br />
|'''3.0 Sound'''<br><br />
Drei Lautsprecher bilden eine "Linie". Somit können Soundeffekte, die sich im vorderen Bereich des Hörers befinden recht gut aufgelöst werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -30°<br />
|-<br />
|Center<br />
| 0°<br />
|-<br />
|Front Right<br />
| 35°<br />
|}<br />
<br />
|[[Datei:surround_sound_3_0.png]]<br />
<br />
<br />
|-<br />
|'''4.0 Surround Sound'''<br><br />
Bei 4.0 Surround Sound sind vier Lautsprecher im Winkel von je 90° um den Hörer angeordnet. Diese Technik, auch als "Quadrophonie" bezeichnet, fand schon in den 1970er Jahren Anwendung, als ein Nachfolgeformat zu Stereo etabliert werden sollte. Die naheliegende Vermutung, mit 4x90° das gesammte Hörfeld abdecken zu können und somit einen echten räumlichen Klang zu erzeugen, erwies sich jedoch als falsch. Heutzutage findet man seltener Anlagen mit 4 Lautsprechern - eher werden 6 (5.1) oder 8 (7.1) Lautsprecher verwendet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Rear Left<br />
| -135°<br />
|-<br />
|Rear Right<br />
| 135°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_4_0.png]]<br />
<br />
|-<br />
|'''5.1 Surround Sound'''<br><br />
<br />
Beim 5.1 Surround System existieren - im Gegensatz zur Quadrophonie - zwei weitere Lautsprecher. Ein zusätzlicher "Center" Lautsprecher sorgt für die notwendige Auflösung im Frontalbereich des Hörers. Dabei sind die "Front-Left" und "Front-Right" Lautsprecher nicht mehr im 45° sondern im 30° Winkel angeordnet.<br />
<br />
Ein so genannter Subwoofer ist für die wiedergabe niedriger Frequenzen verantwortlich. Da Töne einer Frequenz unterhalb einer gewissen Schwelle nicht mehr lokalisiert werden können, ist die Position des Subwoofers unerheblich für den Raumklang. Gleichzeitig müssen die Satelitenlautsprecher keine niedrigen Frequenzen mehr wiedergeben und können somit kompakter gebaut werden. Der Kanal für den Subwoofer wird als LFE-Channel (Low Frequency Effects) bezeichnet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Center<br />
| 0°<br />
|-<br />
|Front Left<br />
| -30°<br />
|-<br />
|Rear Left<br />
| -110°<br />
|-<br />
|Rear Right<br />
| 110°<br />
|-<br />
|Front Right<br />
| 30°<br />
|}<br />
<br />
|[[Datei:surround_sound_5_1.png]]<br />
<br />
<br />
<br />
|}<br />
<br />
== Siehe auch ==<br />
* [[OpenAL]]<br />
<br />
== Weblinks ==<br />
* [http://de.wikipedia.org/wiki/Quadrofonie|Wikipedia: Quadrofonie]<br />
* [http://lib.tkk.fi/Diss/2001/isbn9512255324/article1.pdf|Paper "Virtual Sound Source Positioning"]</div>Igel457https://wiki.delphigl.com/index.php?title=Datei:surround_sound_5_1.png&diff=24302Datei:surround sound 5 1.png2009-11-07T16:49:38Z<p>Igel457: Anordnung der Lautsprecher in einem 5.1 Surround System.</p>
<hr />
<div>Anordnung der Lautsprecher in einem 5.1 Surround System.</div>Igel457https://wiki.delphigl.com/index.php?title=3D_Audio&diff=243013D Audio2009-11-07T16:49:08Z<p>Igel457: /* Gängige Lautsprecheranordnungen */</p>
<hr />
<div>{{Unvollständig}}<br />
<br />
Unter '''3D Audio''' versteht man allgemein die Wiedergabe von Soundeffekten über mehr als zwei Lautsprecher. Die Soundeffekte werden dabei an einen virtuellen Emitter gekoppelt und je nach Winkel und Entfernung zu einem virtuellen Hörer mit unterschiedlicher Lautstärke auf den Lautsprechern ausgegeben.<br />
<br />
Durch die Kopplung mit verschiedensten Audioeffekten (Reverb, High-/Lowpass Filter) soll somit ein möglichst realistischer Raumklangeindruck erzeugt werden.<br />
<br />
Während z.B. bei Filmen die "Surround"-Toninformationen nebst Effekten für alle Lautsprecher vorberechnet sind, werden diese bei Computerspielen in Echtzeit für jeden Lautsprecher berechnet. Hierzu werden Bibliotheken wie [[OpenAL]] oder [[DirectSound]] eingesetzt.<br />
<br />
==Gängige Lautsprecheranordnungen==<br />
<br />
In der nachfolgenen Tabelle werden die heute gängigen Lautsprecheranordnungen für Surroundsound Systeme aufgeführt:<br />
<br />
{|{{Prettytable_B1}}<br />
|-<br />
|'''System'''<br />
|'''Beispielanordnung'''<br />
|-<br />
|'''Stereo (2.0)'''<br><br />
Zwei Lautsprecher, die im Optimalfall im 45° vom Hörer weg angeordnet sind, bilden das Stereo System. Töne, die hinter dem Betrachter ausgestrahlt werden können nicht wahrgenommen werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_2_0.png]]<br />
<br />
|-<br />
|'''3.0 Sound'''<br><br />
Drei Lautsprecher bilden eine "Linie". Somit können Soundeffekte, die sich im vorderen Bereich des Hörers befinden recht gut aufgelöst werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -30°<br />
|-<br />
|Center<br />
| 0°<br />
|-<br />
|Front Right<br />
| 35°<br />
|}<br />
<br />
|[[Datei:surround_sound_3_0.png]]<br />
<br />
<br />
|-<br />
|'''4.0 Surround Sound'''<br><br />
Bei 4.0 Surround Sound sind vier Lautsprecher im Winkel von je 90° um den Hörer angeordnet. Diese Technik, auch als "Quadrophonie" bezeichnet, fand schon in den 1970er Jahren Anwendung, als ein Nachfolgeformat zu Stereo etabliert werden sollte. Die naheliegende Vermutung, mit 4x90° das gesammte Hörfeld abdecken zu können und somit einen echten räumlichen Klang zu erzeugen, erwies sich jedoch als falsch. Heutzutage findet man seltener Anlagen mit 4 Lautsprechern - eher werden 6 (5.1) oder 8 (7.1) Lautsprecher verwendet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Rear Left<br />
| -135°<br />
|-<br />
|Rear Right<br />
| 135°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_4_0.png]]<br />
<br />
|-<br />
|'''5.1 Surround Sound'''<br><br />
<br />
Beim 5.1 Surround System existieren - im Gegensatz zur Quadrophonie - zwei weitere Lautsprecher. Ein zusätzlicher "Center" Lautsprecher sorgt für die notwendige Auflösung im Frontalbereich des Hörers. Dabei sind die "Front-Left" und "Front-Right" Lautsprecher nicht mehr im 45° sondern im 30° Winkel angeordnet.<br />
<br />
Ein so genannter Subwoofer ist für die wiedergabe niedriger Frequenzen verantwortlich. Da Töne einer Frequenz unterhalb einer gewissen Schwelle nicht mehr lokalisiert werden können, ist die Position des Subwoofers unerheblich für den Raumklang. Gleichzeitig müssen die Satelitenlautsprecher keine niedrigen Frequenzen mehr wiedergeben und können somit kompakter gebaut werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Center<br />
| 0°<br />
|-<br />
|Front Left<br />
| -30°<br />
|-<br />
|Rear Left<br />
| -110°<br />
|-<br />
|Rear Right<br />
| 110°<br />
|-<br />
|Front Right<br />
| 30°<br />
|}<br />
<br />
|[[Datei:surround_sound_5_1.png]]<br />
<br />
<br />
<br />
|}<br />
<br />
== Siehe auch ==<br />
* [[OpenAL]]<br />
<br />
== Weblinks ==<br />
* [http://de.wikipedia.org/wiki/Quadrofonie|Wikipedia: Quadrofonie]<br />
* [http://lib.tkk.fi/Diss/2001/isbn9512255324/article1.pdf|Paper "Virtual Sound Source Positioning"]</div>Igel457https://wiki.delphigl.com/index.php?title=Datei:surround_sound_3_0.png&diff=24300Datei:surround sound 3 0.png2009-11-07T16:39:58Z<p>Igel457: Anordnung der Lautsprecher in einem 3.0 Lautsprecher System.</p>
<hr />
<div>Anordnung der Lautsprecher in einem 3.0 Lautsprecher System.</div>Igel457https://wiki.delphigl.com/index.php?title=3D_Audio&diff=242993D Audio2009-11-07T16:39:36Z<p>Igel457: /* Gängige Lautsprecheranordnungen */</p>
<hr />
<div>{{Unvollständig}}<br />
<br />
Unter '''3D Audio''' versteht man allgemein die Wiedergabe von Soundeffekten über mehr als zwei Lautsprecher. Die Soundeffekte werden dabei an einen virtuellen Emitter gekoppelt und je nach Winkel und Entfernung zu einem virtuellen Hörer mit unterschiedlicher Lautstärke auf den Lautsprechern ausgegeben.<br />
<br />
Durch die Kopplung mit verschiedensten Audioeffekten (Reverb, High-/Lowpass Filter) soll somit ein möglichst realistischer Raumklangeindruck erzeugt werden.<br />
<br />
Während z.B. bei Filmen die "Surround"-Toninformationen nebst Effekten für alle Lautsprecher vorberechnet sind, werden diese bei Computerspielen in Echtzeit für jeden Lautsprecher berechnet. Hierzu werden Bibliotheken wie [[OpenAL]] oder [[DirectSound]] eingesetzt.<br />
<br />
==Gängige Lautsprecheranordnungen==<br />
<br />
In der nachfolgenen Tabelle werden die heute gängigen Lautsprecheranordnungen für Surroundsound Systeme aufgeführt:<br />
<br />
{|{{Prettytable_B1}}<br />
|-<br />
|'''System'''<br />
|'''Beispielanordnung'''<br />
|-<br />
|'''Stereo (2.0)'''<br><br />
Zwei Lautsprecher, die im Optimalfall im 45° vom Hörer weg angeordnet sind, bilden das Stereo System. Töne, die hinter dem Betrachter ausgestrahlt werden können nicht wahrgenommen werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_2_0.png]]<br />
<br />
|-<br />
|'''3.0 Sound'''<br><br />
Drei Lautsprecher bilden eine "Linie". Somit können Soundeffekte, die sich im vorderen Bereich des Hörers befinden recht gut aufgelöst werden.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -30°<br />
|-<br />
|Center<br />
| 0°<br />
|-<br />
|Front Right<br />
| 35°<br />
|}<br />
<br />
|[[Datei:surround_sound_3_0.png]]<br />
<br />
<br />
|-<br />
|'''4.0 Surround Sound'''<br><br />
Bei 4.0 Surround Sound sind vier Lautsprecher im Winkel von je 90° um den Hörer angeordnet. Diese Technik, auch als "Quadrophonie" bezeichnet, fand schon in den 1970er Jahren Anwendung, als ein Nachfolgeformat zu Stereo etabliert werden sollte. Die naheliegende Vermutung, mit 4x90° das gesammte Hörfeld abdecken zu können und somit einen echten räumlichen Klang zu erzeugen, erwies sich jedoch als falsch. Heutzutage findet man seltener Anlagen mit 4 Lautsprechern - eher werden 6 (5.1) oder 8 (7.1) Lautsprecher verwendet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Rear Left<br />
| -135°<br />
|-<br />
|Rear Right<br />
| 135°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_4_0.png]]<br />
<br />
<br />
<br />
|}<br />
<br />
== Siehe auch ==<br />
* [[OpenAL]]<br />
<br />
== Weblinks ==<br />
* [http://de.wikipedia.org/wiki/Quadrofonie|Wikipedia: Quadrofonie]<br />
* [http://lib.tkk.fi/Diss/2001/isbn9512255324/article1.pdf|Paper "Virtual Sound Source Positioning"]</div>Igel457https://wiki.delphigl.com/index.php?title=Datei:surround_sound_2_0.png&diff=24298Datei:surround sound 2 0.png2009-11-07T16:39:13Z<p>Igel457: Anordnung der Lautsprecher in einem 2.0 Stereo System.</p>
<hr />
<div>Anordnung der Lautsprecher in einem 2.0 Stereo System.</div>Igel457https://wiki.delphigl.com/index.php?title=3D_Audio&diff=242973D Audio2009-11-07T16:32:09Z<p>Igel457: </p>
<hr />
<div>{{Unvollständig}}<br />
<br />
Unter '''3D Audio''' versteht man allgemein die Wiedergabe von Soundeffekten über mehr als zwei Lautsprecher. Die Soundeffekte werden dabei an einen virtuellen Emitter gekoppelt und je nach Winkel und Entfernung zu einem virtuellen Hörer mit unterschiedlicher Lautstärke auf den Lautsprechern ausgegeben.<br />
<br />
Durch die Kopplung mit verschiedensten Audioeffekten (Reverb, High-/Lowpass Filter) soll somit ein möglichst realistischer Raumklangeindruck erzeugt werden.<br />
<br />
Während z.B. bei Filmen die "Surround"-Toninformationen nebst Effekten für alle Lautsprecher vorberechnet sind, werden diese bei Computerspielen in Echtzeit für jeden Lautsprecher berechnet. Hierzu werden Bibliotheken wie [[OpenAL]] oder [[DirectSound]] eingesetzt.<br />
<br />
==Gängige Lautsprecheranordnungen==<br />
<br />
In der nachfolgenen Tabelle werden die heute gängigen Lautsprecheranordnungen für Surroundsound Systeme aufgeführt:<br />
<br />
{|{{Prettytable_B1}}<br />
|-<br />
|'''System'''<br />
|'''Beispielanordnung'''<br />
|-<br />
|'''4.0 Surround Sound'''<br><br />
Bei 4.0 Surround Sound sind vier Lautsprecher im Winkel von je 90° um den Hörer angeordnet. Diese Technik, auch als "Quadrophonie" bezeichnet, fand schon in den 1970er Jahren Anwendung, als ein Nachfolgeformat zu Stereo etabliert werden sollte. Die naheliegende Vermutung, mit 4x90° das gesammte Hörfeld abdecken zu können und somit einen echten räumlichen Klang zu erzeugen, erwies sich jedoch als falsch. Heutzutage findet man seltener Anlagen mit 4 Lautsprechern - eher werden 6 (5.1) oder 8 (7.1) Lautsprecher verwendet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Rear Left<br />
| -135°<br />
|-<br />
|Rear Right<br />
| 135°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_4_0.png]]<br />
<br />
<br />
<br />
|}<br />
<br />
== Siehe auch ==<br />
* [[OpenAL]]<br />
<br />
== Weblinks ==<br />
* [http://de.wikipedia.org/wiki/Quadrofonie|Wikipedia: Quadrofonie]<br />
* [http://lib.tkk.fi/Diss/2001/isbn9512255324/article1.pdf|Paper "Virtual Sound Source Positioning"]</div>Igel457https://wiki.delphigl.com/index.php?title=3D_Audio&diff=242963D Audio2009-11-07T16:03:18Z<p>Igel457: /* Gängige Lautsprecheranordnungen */</p>
<hr />
<div>{{Unvollständig}}<br />
<br />
Unter '''3D Audio''' versteht man allgemein die Wiedergabe von Soundeffekten über mehr als zwei Lautsprecher. Die Soundeffekte werden dabei an einen virtuellen Emitter gekoppelt und je nach Winkel und Entfernung zu einem virtuellen Hörer mit unterschiedlicher Lautstärke auf den Lautsprechern ausgegeben.<br />
<br />
Durch die Kopplung mit verschiedensten Audioeffekten (Reverb, High-/Lowpass Filter) soll somit ein möglichst realistischer Raumklangeindruck erzeugt werden.<br />
<br />
Während z.B. bei Filmen die "Surround"-Toninformationen nebst Effekten für alle Lautsprecher vorberechnet sind, werden diese bei Computerspielen in Echtzeit für jeden Lautsprecher berechnet. Hierzu werden Bibliotheken wie [[OpenAL]] oder [[DirectSound]] eingesetzt.<br />
<br />
==Gängige Lautsprecheranordnungen==<br />
<br />
In der nachfolgenen Tabelle werden die heute gängigen Lautsprecheranordnungen für Surroundsound Systeme aufgeführt:<br />
<br />
{|{{Prettytable_B1}}<br />
|-<br />
|'''System'''<br />
|'''Beispielanordnung'''<br />
|-<br />
|'''4.0 Surround Sound'''<br><br />
Bei 4.0 Surround Sound sind vier Lautsprecher im Winkel von je 90° um den Hörer angeordnet. Diese Technik, auch als "Quadrophonie" bezeichnet, fand schon in den 1970er Jahren Anwendung, als ein Nachfolgeformat zu Stereo etabliert werden sollte. Die naheliegende Vermutung, mit 4x90° das gesammte Hörfeld abdecken zu können und somit einen echten räumlichen Klang zu erzeugen, erwies sich jedoch als falsch. Heutzutage findet man seltener Anlagen mit 4 Lautsprechern - eher werden 6 (5.1) oder 8 (7.1) Lautsprecher verwendet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Rear Left<br />
| -135°<br />
|-<br />
|Rear Right<br />
| 135°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_4_0.png]]<br />
<br />
<br />
<br />
|}<br />
<br />
== Siehe auch ==<br />
* [[OpenAL]]<br />
<br />
== Weblinks ==<br />
* [http://de.wikipedia.org/wiki/Quadrofonie|Wikipedia: Quadrofonie]</div>Igel457https://wiki.delphigl.com/index.php?title=3D_Audio&diff=242953D Audio2009-11-07T15:24:55Z<p>Igel457: </p>
<hr />
<div>{{Unvollständig}}<br />
<br />
Unter '''3D Audio''' versteht man allgemein die Wiedergabe von Soundeffekten über mehr als zwei Lautsprecher. Die Soundeffekte werden dabei an einen virtuellen Emitter gekoppelt und je nach Winkel und Entfernung zu einem virtuellen Hörer mit unterschiedlicher Lautstärke auf den Lautsprechern ausgegeben.<br />
<br />
Durch die Kopplung mit verschiedensten Audioeffekten (Reverb, High-/Lowpass Filter) soll somit ein möglichst realistischer Raumklangeindruck erzeugt werden.<br />
<br />
Während z.B. bei Filmen die "Surround"-Toninformationen nebst Effekten für alle Lautsprecher vorberechnet sind, werden diese bei Computerspielen in Echtzeit für jeden Lautsprecher berechnet. Hierzu werden Bibliotheken wie [[OpenAL]] oder [[DirectSound]] eingesetzt.<br />
<br />
==Gängige Lautsprecheranordnungen==<br />
<br />
In der nachfolgenen Tabelle werden die heute gängigen Lautsprecheranordnungen für Surroundsound Systeme <br />
<br />
{|{{Prettytable_B1}}<br />
|-<br />
|'''System'''<br />
|'''Beispielanordnung'''<br />
|-<br />
|'''4.0 Surround Sound'''<br><br />
Bei 4.0 Surround Sound sind vier Lautsprecher im Winkel von je 90° um den Hörer angeordnet. Diese Technik, auch als "Quadrophonie" bezeichnet, fand schon in den 1970er Jahren Anwendung, als ein Nachfolgeformat zu Stereo etabliert werden sollte. Die naheliegende Vermutung, mit 4x90° das gesammte Hörfeld abdecken zu können und somit einen echten räumlichen Klang zu erzeugen, erwies sich jedoch als falsch. Heutzutage findet man seltener Anlagen mit 4 Lautsprechern - eher werden 6 (5.1) oder 8 (7.1) Lautsprecher verwendet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Rear Left<br />
| -135°<br />
|-<br />
|Rear Right<br />
| 135°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_4_0.png]]<br />
<br />
<br />
<br />
|}<br />
<br />
<br />
<br />
== Siehe auch ==<br />
* [[OpenAL]]<br />
<br />
== Weblinks ==<br />
* [http://de.wikipedia.org/wiki/Quadrofonie|Wikipedia: Quadrofonie]</div>Igel457https://wiki.delphigl.com/index.php?title=3D_Audio&diff=242943D Audio2009-11-07T15:23:58Z<p>Igel457: </p>
<hr />
<div>{{Unvollständig}}<br />
<br />
Unter '''3D Audio''' versteht man allgemein die Wiedergabe von Soundeffekten über mehr als zwei Lautsprecher. Die Soundeffekte werden dabei an einen virtuellen Emitter gekoppelt und je nach Winkel und Entfernung zu einem virtuellen Hörer mit unterschiedlicher Lautstärke auf den Lautsprechern ausgegeben.<br />
<br />
Durch die Kopplung mit verschiedensten Audioeffekten (Reverb, High-/Lowpass Filter) soll somit ein möglichst realistischer Raumklangeindruck erzeugt werden.<br />
<br />
Während z.B. bei Filmen die "Surround"-Toninformationen nebst Effekten für alle Lautsprecher vorberechnet sind, werden diese bei Computerspielen in Echtzeit für jeden Lautsprecher berechnet.<br />
<br />
==Gängige Lautsprecheranordnungen==<br />
<br />
In der nachfolgenen Tabelle werden die heute gängigen Lautsprecheranordnungen für Surroundsound Systeme <br />
<br />
{|{{Prettytable_B1}}<br />
|-<br />
|'''System'''<br />
|'''Beispielanordnung'''<br />
|-<br />
|'''4.0 Surround Sound'''<br><br />
Bei 4.0 Surround Sound sind vier Lautsprecher im Winkel von je 90° um den Hörer angeordnet. Diese Technik, auch als "Quadrophonie" bezeichnet, fand schon in den 1970er Jahren Anwendung, als ein Nachfolgeformat zu Stereo etabliert werden sollte. Die naheliegende Vermutung, mit 4x90° das gesammte Hörfeld abdecken zu können und somit einen echten räumlichen Klang zu erzeugen, erwies sich jedoch als falsch. Heutzutage findet man seltener Anlagen mit 4 Lautsprechern - eher werden 6 (5.1) oder 8 (7.1) Lautsprecher verwendet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Rear Left<br />
| -135°<br />
|-<br />
|Rear Right<br />
| 135°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_4_0.png]]<br />
<br />
<br />
<br />
|}<br />
<br />
<br />
<br />
== Siehe auch ==<br />
* [[OpenAL]]<br />
<br />
== Weblinks ==<br />
* [http://de.wikipedia.org/wiki/Quadrofonie|Wikipedia: Quadrofonie]</div>Igel457https://wiki.delphigl.com/index.php?title=3D_Audio&diff=242933D Audio2009-11-07T15:19:26Z<p>Igel457: </p>
<hr />
<div>{{Unvollständig}}<br />
<br />
Unter 3D Audio versteht man allgemein die Wiedergabe von Soundeffekten über mehr als zwei Lautsprecher. Die Soundeffekte werden dabei an einen virtuellen Emitter gekoppelt und je nach Winkel und Entfernung zu einem virtuellen Hörer mit unterschiedlicher Lautstärke auf den Lautsprechern ausgegeben.<br />
<br />
Durch die Kopplung mit verschiedensten Audioeffekten (Reverb, High-/Lowpass Filter) soll somit ein möglichst realistischer Raumklangeindruck erzeugt werden.<br />
<br />
{|{{Prettytable_B1}}<br />
|-<br />
|'''System'''<br />
|'''Beispielanordnung'''<br />
|-<br />
|'''4.0 Surround Sound'''<br><br />
Bei 4.0 Surround Sound sind vier Lautsprecher im Winkel von je 90° um den Hörer angeordnet. Diese Technik, auch als "Quadrophonie" bezeichnet, fand schon in den 1970er Jahren Anwendung, als ein Nachfolgeformat zu Stereo etabliert werden sollte. Die naheliegende Vermutung, mit 4x90° das gesammte Hörfeld abdecken zu können und somit einen echten räumlichen Klang zu erzeugen, erwies sich jedoch als falsch. Heutzutage findet man seltener Anlagen mit 4 Lautsprechern - eher werden 6 (5.1) oder 8 (7.1) Lautsprecher verwendet.<br />
<br />
{| {{Prettytable_B1}}<br />
|-<br />
|'''Lautsprecher'''<br />
|'''Winkel'''<br />
|-<br />
|Front Left<br />
| -45°<br />
|-<br />
|Rear Left<br />
| -135°<br />
|-<br />
|Rear Right<br />
| 135°<br />
|-<br />
|Front Right<br />
| 45°<br />
|}<br />
<br />
|[[Datei:surround_sound_4_0.png]]<br />
<br />
<br />
<br />
|}<br />
<br />
<br />
<br />
== Siehe auch ==<br />
* [[OpenAL]]</div>Igel457https://wiki.delphigl.com/index.php?title=Datei:surround_sound_4_0.png&diff=24292Datei:surround sound 4 0.png2009-11-07T15:03:29Z<p>Igel457: Anordnung der Lautsprecher in einem 4.0 Surround System.</p>
<hr />
<div>Anordnung der Lautsprecher in einem 4.0 Surround System.</div>Igel457https://wiki.delphigl.com/index.php?title=3D_Audio&diff=242913D Audio2009-11-07T14:58:24Z<p>Igel457: </p>
<hr />
<div>{{Unvollständig}}<br />
<br />
Unter 3D Audio versteht man allgemein die Wiedergabe von Soundeffekten über mehr als zwei Lautsprecher. Die Soundeffekte werden dabei an einen virtuellen Emitter gekoppelt und je nach Winkel und Entfernung zu einem virtuellen Hörer mit unterschiedlicher Lautstärke auf den Lautsprechern ausgegeben.<br />
<br />
Durch die Kopplung mit verschiedensten Audioeffekten (Reverb, High-/Lowpass Filter) soll somit ein möglichst realistischer Raumklangeindruck erzeugt werden.<br />
<br />
[[Datei:surround_sound_4_0.png]]<br />
<br />
== Siehe auch ==<br />
* [[OpenAL]]</div>Igel457https://wiki.delphigl.com/index.php?title=3D_Audio&diff=242903D Audio2009-11-07T14:37:28Z<p>Igel457: Die Seite wurde neu angelegt: „{{Unvollständig}} Unter 3D Audio versteht man allgemein die Wiedergabe von Soundeffekten über mehr als zwei Lautsprecher. Die Soundeffekte werden dabei an eine…“</p>
<hr />
<div>{{Unvollständig}}<br />
<br />
Unter 3D Audio versteht man allgemein die Wiedergabe von Soundeffekten über mehr als zwei Lautsprecher. Die Soundeffekte werden dabei an einen virtuellen Emitter gekoppelt und je nach Winkel und Entfernung zu einem virtuellen Hörer mit unterschiedlicher Lautstärke auf den Lautsprechern ausgegeben.<br />
<br />
Durch die Kopplung mit verschiedensten Audioeffekten (Reverb, High-/Lowpass Filter) soll somit ein möglichst realistischer Raumklangeindruck erzeugt werden.<br />
<br />
<br />
== Siehe auch ==<br />
* [[OpenAL]]</div>Igel457https://wiki.delphigl.com/index.php?title=OpenAL&diff=24289OpenAL2009-11-07T14:35:09Z<p>Igel457: </p>
<hr />
<div>'''OpenAL''' ('''Open A'''udio '''L'''ibrary) ist eine plattformunabhängige [[3D Audio|3D Audio-API]]. Sie ist das Sound-Pendant zu [[OpenGL]] und somit die offene Konkurrenz zu DirectSound.<br />
<br />
Dieses Wiki verfügt über eine deutschsprachige Übersetzung der OpenAL Spezifikation. Diese ist unter [[OpenAL-Funktionsübersicht]] zu finden.<br />
<br />
==Laut Wikipedia==<br />
Wikipedia liefert dazu folgende Informationen:<br />
<br />
Mit OpenAL lassen sich Soundeffekte wie Raumklang und Dopplereffekt erstellen und einbinden, auch Hardwarebeschleunigung wird unterstützt.<br />
<br />
OpenAL unterliegt in weiten Teilen der LGPL und liegt aktuell in der Version 1.1 vor.<br />
<br />
Die OpenAL-API kann und soll als Ergänzung zur Grafik-API OpenGL gesehen werden, daher wurde bei der Entwicklung besonders auf Angleichung von Aufbau, Programmierstil und Namenskonventionen geachtet. Zudem ist OpenAL ebenfalls in der Sprache C geschrieben.<br />
<br />
Durch die kombinierte Nutzung der beiden Bibliotheken ist eine hohe Portierbarkeit gewährleistet. Ebenso wie bei OpenGL gibt es OpenAL-Implementierungen für zahlreiche Plattformen und Programmiersprachen.<br />
<br />
OpenAL ist als direkter Konkurrent zu Microsofts DirectSound (Bestandteil von DirectX) anzusehen. Dank der guten Portierbarkeit hat OpenAL dennoch bis heute eine recht weite Verbreitung gefunden, so gibt es bereits zahlreiche Programme, Spiele und Engines, die OpenAL nutzen.<br />
<br />
Für weitere Details verweisen wir hier auf den [http://de.wikipedia.org/wiki/OpenAL Wikipedia-Artikel zu OpenAL]</div>Igel457https://wiki.delphigl.com/index.php?title=OpenAL&diff=24288OpenAL2009-11-07T14:26:54Z<p>Igel457: </p>
<hr />
<div>'''OpenAL''' ('''Open A'''udio '''L'''ibrary) ist eine plattformunabhängige [[3D Audio-API|3D Audio]]. Sie ist das Sound-Pendant zu [[OpenGL]] und somit die offene Konkurrenz zu DirectSound.<br />
<br />
Dieses Wiki verfügt über eine deutschsprachige Übersetzung der OpenAL Spezifikation. Diese ist unter [[OpenAL-Funktionsübersicht]] zu finden.<br />
<br />
==Laut Wikipedia==<br />
Wikipedia liefert dazu folgende Informationen:<br />
<br />
Mit OpenAL lassen sich Soundeffekte wie Raumklang und Dopplereffekt erstellen und einbinden, auch Hardwarebeschleunigung wird unterstützt.<br />
<br />
OpenAL unterliegt in weiten Teilen der LGPL und liegt aktuell in der Version 1.1 vor.<br />
<br />
Die OpenAL-API kann und soll als Ergänzung zur Grafik-API OpenGL gesehen werden, daher wurde bei der Entwicklung besonders auf Angleichung von Aufbau, Programmierstil und Namenskonventionen geachtet. Zudem ist OpenAL ebenfalls in der Sprache C geschrieben.<br />
<br />
Durch die kombinierte Nutzung der beiden Bibliotheken ist eine hohe Portierbarkeit gewährleistet. Ebenso wie bei OpenGL gibt es OpenAL-Implementierungen für zahlreiche Plattformen und Programmiersprachen.<br />
<br />
OpenAL ist als direkter Konkurrent zu Microsofts DirectSound (Bestandteil von DirectX) anzusehen. Dank der guten Portierbarkeit hat OpenAL dennoch bis heute eine recht weite Verbreitung gefunden, so gibt es bereits zahlreiche Programme, Spiele und Engines, die OpenAL nutzen.<br />
<br />
Für weitere Details verweisen wir hier auf den [http://de.wikipedia.org/wiki/OpenAL Wikipedia-Artikel zu OpenAL]</div>Igel457https://wiki.delphigl.com/index.php?title=Tutorial_OpenGL3_Scissor_Clipping_DepthTest&diff=24286Tutorial OpenGL3 Scissor Clipping DepthTest2009-11-04T15:51:00Z<p>Igel457: /* Tiefen-Test */</p>
<hr />
<div>=Clipping, Scissor und Tiefen-Test=<br />
Clipping, Scissor und Tiefen-Test sind Optimierungsprozesse welche dafür sorgen, dass der Datenpool minimiert wird. Dabei ist die Clipping Funktion dafür zuständig Vertice und damit verbundene Daten aus der Renderpipeline zu werfen. Die Scissor Funktion soll den Shading-Prozess beschleunigen, also das errechnen der Pixelfarben für ein Dreieck reduzieren.<br />
Der Tiefen-Test hat die gleiche Aufgabe wie der Scissor-Test aber reduziert die Datenmenge auf Basis anderer Informationen und soll zugleich das korrekte Zeichnen von sich überschneidender Geometry ermöglichen.<br />
<br />
==Clipping==<br />
Der Clipping-Prozess wird nach dem errechnen der Vertexpositionen auf dem Monitor durch geführt. Diese erhält man durch das Multiplizieren der Projektionsmatrix mit der Modelviewmatrix und dem anschliessenden multiplizieren mit der Vertexposition. Die neue Vertexposition hat zwar noch 4 Komponenten aber beim Clipping werden nur X und Y betrachtet.<br />
Man muss in allen OpenGL Versionen den Viewport einstellen, indem man [[glViewport]] verwendet.<br />
Als Parameter übergibt man X,Y,Width und Height, welche zusammen ein Rechteck ergeben.<br />
Dieses Rechteck ist nun der gültige Sichtebereich und alles ausserhalb von diesen ist nicht sichtbar und wird damit nicht in der Renderpipeline benötigt. Wenn nun also ein Dreieck nicht das Rechteck schneidet, dann wird es aus der Renderpipeline entfernt. Dies reduziert die zu behandelnden Dreiecke in den Anschliessenden Prozessschritten und spart Zeit ein.<br />
<br />
==Scissor==<br />
Der Scissor-Prozess wird vor dem Fragmentshader durch geführt, dieser Schritt muss nicht durchgeführt werden. Der Scissor-Test kann über [[glEnable#GL_SCISSOR_TEST]] aktiviert werden und mit Hilfe von [[glScissor]] konfiguriert werden. Genau wie beim Clipping wird die X und Y Koordinate des Bildschirmpixels als Eingabe genommen aber im gegensatz zum Clipping-Test wird im Scissor-Test nur ein X/Y Wertepaar benötigt und nicht 3. Der Test ist daher recht einfach und kann bei komplexeren Shadern immense Summen an Zeit herraus holen. Folgender Code zeigt ein einfachen InBound check.<br />
<source lang="cpp">bool InBoundCheck(const int X, const int Y, const int RectX, const int RectY, const unsigned int RectWidth, const unsigned int RectHeight)<br />
{<br />
if ((X<=RectX+RectWidth) && (X>=RectX))<br />
if ((Y<=RectY+RectHeight) && (Y>=RectY))<br />
return true;<br />
return false;<br />
}</source><br />
Alle Pixel, die den Test bestehen, werden dann an den Fragmentshader weiter gereicht und der rest wird einfach verworfen.<br />
Wenn ein Shader sehr komplex ist und z.B. mehrere Texelzugriffe macht, AntiAliasing aktiviert ist und/oder komplexe Berechnungen im Fragmentshader getan werden, dann kann durch das Verwerfen von Pixeln viel Zeit eingespart werden.<br />
<br />
==Tiefen-Test==<br />
Der Tiefen-Test wird nach dem Scissor-Test ausgeführt und soll die Anzahl der zu verarbeitenden Pixel reduzieren und Dreiecksüberschneidungen korrekt darstellen. <br />
Wenn man in einen Artikel, Blog oder Forum von Overdraw redet, dann hat dies mit dem Tiefen-Test zu tun. Overdraw ist der Zustand, wenn ein Bildschirmpixel mehrfach gezeichnet wird, also mehrere Dreiecke die gleiche X-,Y-Koordinate auf dem Bildschirm haben.<br />
Der Tiefen-Test betrachtet die Z-Koordinate von dem Bildschirmpixel und schaut in einen Tiefenpuffer nach, ob das Fragment(aktueller Pixel vom Dreieck) sichtbar wäre. Jedes Fragment, welches durch ein Dreieck in der Pipeline verarbeitet wird, besitzt einen Tiefenwert Z und dieser wird in dem Tiefenpuffer Hinterlegt. Wenn man mit [[glEnable#GL_DEPTH_TEST]] den Tiefen-Test aktiviert, dann wird jedes Fragment mit einer definierten Funktion verarbeitet. Diese Funktion kann über [[glDepthFunc]] fest gelegt werden. Wenn die Funktion erfolgreich ist und true zurück gibt, dann wird der Z Wert in den Tiefenpuffer eingetragen und wird anschliessend vom Fragmentshader verarbeitet. Sollte der Test negativ ausfallen, dann wird der Tiefenwert nicht geschrieben und das Fragment verworfen.<br />
Es ist sinnvoll, die Tiefen-Test Funktion nur auf kleinere oder gleiche Z Werte, als im Tiefenpuffer, fest zu legen. Wenn man nun seine Dreiecke von vorne nach hinten sortiert und rendert, dann werden nur die vordersten Fragmente, der Dreiecke gezeichnet. Sollten man die Dreiecke von hinten nach vorne zeichnen, dann wird jedes Fragment in der Szene durch den Fragmentshader geschliffen und die Framerate bricht stark ein. <br />
<br />
{{Hinweis|Nvidia und ATI empfehlen das Rendern in 2 Schritten zu vollziehen. Im ersten Schritt wird mit Hilfe von [[glColorMask]] alle Kanälle ab geschalten, mit [[glDepthMask]] der Tiefenpuffer schreibar gemacht, der Tiefen-Test aktiviert, der Tiefen- und Farbpuffer geleert, die Texturen deaktivert([[glDisable#GL_TEXTURE_2D]]) und die nicht Transparente Geometry gezeichnet. Dieser Schritt ist zum erfassen der Z-Koordinaten. Anschliessend aktiviert man wieder alle Farbkanälle, deaktiviert das schreiben im Tiefenpuffer, Texturen und zeichnet nun ganz normal seine nicht Transparente Geometry und dann die Transparente. Dieses 2 Schritt verfahren ist um ein vielfaches schneller und wird umso schneller, je komplexer Geometry und Shader werden.}}</div>Igel457https://wiki.delphigl.com/index.php?title=Kategorie_Diskussion:Exzellent&diff=24273Kategorie Diskussion:Exzellent2009-11-02T21:14:41Z<p>Igel457: /* Kandidatenliste */</p>
<hr />
<div>=Voraussetzungen für Exzellente Artikel=<br />
Hier könnt ihr Artikel vorschlagen welche ihr als "exzellenten Artikel" einstufen würdet.<br />
<br />
Folgende Punkte '''müssen''' erfüllt sein:<br />
* Kein Sackgassenartikel - Artikel muss auf andere Artikel direkt (nicht über Code) verlinken<br />
* Kein Plain Text - Artikel muss eine einheitliche Formatierung aufweisen<br />
* Bilder - Artikel muss mindestens ein Bild/Grafik besitzen<br />
* Umfassend - Der Artikel muss das Thema umfassend behandeln.<br />
* Kein Tutorial - Der Artikel darf nicht der [[:Kategorie:Tutorial|Kategorie Tutorial]] angehören.<br />
<br />
<br />
Damit ein Artikel als '''exzellent''' eingestuft wird müssen:<br />
* 3 Wiki-User der Wahl zustimmen darunter mindestens ein Moderator,<br />
* keine Gegenstimmen bestehen,<br />
* die Voraussetzungen von oben gelten.<br />
<br />
<br><br />
<br />
=Kandidatenliste=<br />
Um einen Artikel zur Kandidatenliste hinzuzufügen bitte den Nachfolgenden Code vor dem Ende ("<nowiki>|}</nowiki>") der Tabelle einfügen:<br />
<br />
|<nowiki>[[Artikelname]]</nowiki><br />
|<br />
|<br />
|<br />
|-<br />
<br />
Um eine Stimme abzugeben, kopiert ihr bitte den Wiki-Code "<nowiki>--~~~~</nowiki>" in die entsprechende Spalte. Das Wiki generiert daraus eure Unterschrift (Signatur).<br />
<br />
Falls ihr eine Gegenstimme abgebt, muss eine Begründung dazu gegeben werden.<br />
<br />
----<br />
<br><br />
<div align="center"><br />
{|{{Prettytable_B1}}<br />
!width="15%"|Vorgeschlagener Artikel<br />
!width="20%"|Beführworter<br />
!width="20%"|Gegner<br />
!width="45%"|Begründung für Gegenstimme / Diskussion<br />
|-<br />
| [[glTexParameter]]<br />
| <br />
| --[[Benutzer:Flash|Flash]] 09:56, 11. Jan 2007 (CET)<br />
|Wenn jemand noch die restlichen Wrapmodes einbaut sicher ein guter kandidat (GL_CLAMP_TO_EDGE, GL_CLAMP_TO_BORDER,GL_MIRRORED_REPEAT laut glitmap.pas) (Winner)<br />
<br />
Stimme Winner zu. Ohne die ergänzungen kommt der Artikel nicht in Frage.<br />
|-<br />
|[[gluCylinder]]<br />
| --[[Benutzer:Flash|Flash]] 09:09, 10. Apr. 2008 (UTC)<br />
--[[Benutzer:Igel457|Igel457]] 22:14, 2. Nov. 2009 (CET)<br />
| <br />
| <br />
Guter und anschaulicher Artikel, wenn auch GLU-Funktionen im Allgemeinen vermieden werden sollten --[[Benutzer:Igel457|Igel457]] 22:14, 2. Nov. 2009 (CET)<br />
|-<br />
|[[Raytracing]]<br />
| <br />
| --[[Benutzer:I0n0s|I0n0s]] 13:25, 10. Dez. 2008 (UTC)<br />
--[[Benutzer:Delphic|Delphic]] 17:14, 10. Dez. 2008 (UTC)<br />
|<br />
# Es existieren 2 Tutorials zu dem Thema.<br />
# Ist nur als Oberflächliche Information konzipiert und enthält keine Information, wie die Techniken tatsächlich zu verwenden sind.<br />
<br />
Ok. Bis der Artikel das Thema etwas besser "ausleuchtet" ;) bleibt das Veto stehen. Die Tutorials sprechen nicht dagegen. --[[Benutzer:Flash|Flash]] 17:58, 10. Dez. 2008 (UTC)<br />
|-<br />
|}<br />
</div><br />
<br />
<br />
<br><br />
<br><br />
<br><br />
<br><br />
<br />
== Auswahlkriterien ==<br />
<br />
Ich finde die Asuwahlkriterien etwas strange. Schließlich sind Tutorials auch Artikel und in den meisten Fällen noch dazu ziemlich gute. Warum sollten diese also ausgeschlossen werden? Vermitteln ja schließlich meist recht anschaulich viel Information. Also exakt das, was nen guten Artikel ausmacht.<br />
--[[Benutzer:Frase|Frase]] 18:48, 18. Mär 2006 (CET)<br />
<br />
<br />
Tutorials sind einzelarbeiten die von einer Person gemacht wurden und die eigentlich auch nur von dieser zu Verantworten/Verbessern sind. Die Auszeichnung soll gerade dafür sorgen die "graue Maus" Artikel aufzuwerten. Das unsere Tutorials alle Exzellent sind steht außer Frage. Die Auszeichnung heißt aber nicht um sonst "Exzellente Artikel" und nicht "Exzellente Tutorials". Außerdem soll die Auzeichnung erreichen, dass die Nutzer einfach mal ins Wiki reinlesen. Tutorials sind in sich geschlossen und verlinken kaum auf andere Artikel. Sie behandeln ein Thema, und das ist gut so.<br />
--[[Benutzer:Flash|Flash]] 01:11, 19. Mär 2006 (CET)<br />
<br />
<br />
Und es kann die Leute animieren die Artikel den Kritierie anzupassen bzw. eigene Artikel einzustellen.<br />
So hat es zumindest bei mir funktioniert. Ich habe jetzt sogar Bilder! :lol:<br />
<br />
--[[Benutzer:I0n0s|I0n0s]] 04:35, 19. Mär 2006 (CET)</div>Igel457