DGL Wiki - Benutzerbeiträge [de]

Vorlage:dglOpenGL History

2009-09-14T08:31:12Z

Lossy eX:

<pascal>Version 1.0 - Initial Release

Version 1.1 - Added PPointer in Tpyessection for compatiblity with Delphi
versions lower than 7 (SW)
- Added a function named RaiseLastOSError including a comment
on how to make it run under Delphi versions lower than 7 (SW)
- Added some data types according to the GL-Syntax (SW)

Version 1.2 - Fixed some problems with getting the addresses of some
Extensions (e.g. glTexImage3D) where the EXT/ARB did work
but not the core-functions (SW)

Version 1.3 - A second call to ReadimplementationProperties won't
revert to the default libs anymore (MW)
- Libraries now will be released if necessary (MW)

Version 1.3a - Small fixes for glSlang-functions (SW)

Version 1.3b - Fixed a small bug with GL_ARB_shader_objects, that lead
lead to that extension not loaded correctly (SW)

Version 1.3c - More GL 1.5 compliance by FOG_COORD_xx and
ARB-less VBO and occlusion query routines (MW)

Version 1.3d - Fixed linebreaks (should now be corrected under D5) (SW)

Version 1.4 - Changed header to correspond to the OpenGL-Shading
- Language specification 1.10 :
- Added new GL_SAMPLER_*-Constants
- Added Constant GL_SHADING_LANGUAGE_VERSION_ARB
- Added Constant GL_FRAGMENT_SHADER_DERIVATIVE_HINT_ARB
- Added Constant GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB (SW)

Version 1.4a - Fixed a missing stdcall for glBindAttribLocationARB (SW)

Version 1.4b - Fixed declaration for glUniform*(f/i)vARB (added count) (MW)
- glCompileShaderARB changed from function to procedure (MW)

Version 1.5 - Added support for FreePascal (BR)
- Added type TGLVectorf3/TGLVector3f (SW)

Version 1.6 - Added Extension GL_EXT_framebuffer_object (SX)

Version 1.7 - Added Extension GL_ARB_fragment_program_shadow (SX)
- Added Extension GL_ARB_draw_buffers (SX)
- Added Extension GL_ARB_texture_rectangle (SX)
- Added Extension GL_ARB_color_buffer_float (SX)
- Added Extension GL_ARB_half_float_pixel (SX)
- Added Extension GL_ARB_texture_float (SX)
- Added Extension GL_ARB_pixel_buffer_object (SX)
- Added Extension GL_EXT_depth_bounds_test (SX)
- Added Extension GL_EXT_texture_mirror_clamp (SX)
- Added Extension GL_EXT_blend_equation_separate (SX)
- Added Extension GL_EXT_pixel_buffer_object (SX)
- Added Extension GL_EXT_texture_compression_dxt1 (SX)
- Added Extension GL_NV_fragment_program_option (SX)
- Added Extension GL_NV_fragment_program2 (SX)
- Added Extension GL_NV_vertex_program2_option (SX)
- Added Extension GL_NV_vertex_program3 (SX)

Version 1.8 - Added explicit delegate type definitions (LM)
- Added .Net 1.1 Support (LM)
- Added .Net overloaded functions (LM)
- Added delayed extension loading and stubs (LM)
- Added automatic InitOpenGL call in CreateRenderingContext(LM)
- Added extra Read_* function (LM)

Version 2.0 - fixed some Problem with version string and damn drivers.
String 1.15 identified as OpenGL 1.5 not as OpenGL 1.1 (SX)
- Removed unexisting extension GL_ARB_texture_mirror_repeat(SX)
- Added Extension WGL_ARB_pixel_format_float (SX)
- Added Extension GL_EXT_stencil_clear_tag (SX)
- Added Extension GL_EXT_texture_rectangle (SX)
- Added Extension GL_EXT_texture_edge_clamp (SX)
- Some 1.5 Core Consts added (now completed) (SX)
- gluProject need pointer for not .net (SX)
- gluUnProject need pointer for not .net (SX)
- wglUseFontOutlines* need pointer for not .net (SX)
- wglSwapMultipleBuffers need pointer for not .net (SX)
- Bug with wglGetExtensionsStringEXT removed
different type for .net (SX)
- Added OpenGL 2.0 Core (SX)

Version 2.0.1 - fixed some problems with glGetActiveAttrib in 2.0 Core (SX)
- fixes some problems with gluProject (SX)
- fixes some problems with gluUnProject (SX)
- fixes some problems with gluTessVertex (SX)
- fixes some problems with gluLoadSamplingMatrices (SX)

Version 2.1 - Removed .NET Support (SX)
- Better support for Linux (SX)
- Better Codeformation (SX)
- Added some more Vector/Matrix types (SX)
- Added OpenGL 2.1 Core (SX)
- Added Extension GL_EXT_packed_depth_stencil (SX)
- Added Extension GL_EXT_texture_sRGB (SX)
- Added Extension GL_EXT_framebuffer_blit (SX)
- Added Extension GL_EXT_framebuffer_multisample (SX)
- Added Extension GL_EXT_timer_query (SX)
- Added Extension GL_EXT_gpu_program_parameters (SX)
- Added Extension GL_EXT_bindable_uniform (SX)
- Added Extension GL_EXT_draw_buffers2 (SX)
- Added Extension GL_EXT_draw_instanced (SX)
- Added Extension GL_EXT_framebuffer_sRGB (SX)
- Added Extension GL_EXT_geometry_shader4 (SX)
- Added Extension GL_EXT_gpu_shader4 (SX)
- Added Extension GL_EXT_packed_float (SX)
- Added Extension GL_EXT_texture_array (SX)
- Added Extension GL_EXT_texture_buffer_object (SX)
- Added Extension GL_EXT_texture_compression_latc (SX)
- Added Extension GL_EXT_texture_compression_rgtc (SX)
- Added Extension GL_EXT_texture_integer (SX)
- Added Extension GL_EXT_texture_shared_exponent (SX)
- Added Extension GL_NV_depth_buffer_float (SX)
- Added Extension GL_NV_fragment_program4 (SX)
- Added Extension GL_NV_framebuffer_multisample_coverage (SX)
- Added Extension GL_NV_geometry_program4 (SX)
- Added Extension GL_NV_gpu_program4 (SX)
- Added Extension GL_NV_parameter_buffer_object (SX)
- Added Extension GL_NV_transform_feedback (SX)
- Added Extension GL_NV_vertex_program4 (SX)

Version 3.0 - fixed some const of GL_EXT_texture_shared_exponent (SX)
- possible better support for mac (SX)
- Added OpenGL 3.0 Core (SX)
- Added Extension GL_ARB_depth_buffer_float (SX)
- Added Extension GL_ARB_draw_instanced (SX)
- Added Extension GL_ARB_framebuffer_object (SX)
- Added Extension GL_ARB_framebuffer_sRGB (SX)
- Added Extension GL_ARB_geometry_shader4 (SX)
- Added Extension GL_ARB_half_float_vertex (SX)
- Added Extension GL_ARB_instanced_arrays (SX)
- Added Extension GL_ARB_map_buffer_range (SX)
- Added Extension GL_ARB_texture_buffer_object (SX)
- Added Extension GL_ARB_texture_compression_rgtc (SX)
- Added Extension GL_ARB_texture_rg (SX)
- Added Extension GL_ARB_vertex_array_object (SX)
- Added Extension GL_NV_conditional_render (SX)
- Added Extension GL_NV_present_video (SX)
- Added Extension GL_EXT_transform_feedback (SX)
- Added Extension GL_EXT_direct_state_access (SX)
- Added Extension GL_EXT_vertex_array_bgra (SX)
- Added Extension GL_EXT_texture_swizzle (SX)
- Added Extension GL_NV_explicit_multisample (SX)
- Added Extension GL_NV_transform_feedback2 (SX)
- Added Extension WGL_ARB_create_context (SX)
- Added Extension WGL_NV_present_video (SX)
- Added Extension WGL_NV_video_out (SX)
- Added Extension WGL_NV_swap_group (SX)
- Added define DGL_TINY_HEADER to suppress automatic
function loading (SX)
- glProcedure renamed to dglGetProcAddress and now it's
visible from outside the unit to custom load functions (SX)
- dglCheckExtension added to check if an extension exists (SX)
- Read_GL_ARB_buffer_object renamed to
Read_GL_ARB_vertex_buffer_object (SX)

Version 3.0.1 - fixed an problem with fpc (SX)

Version 3.0.2 - fixed an problem with WGL_ARB_create_context (SX)

Version 3.2 - Functions from GL_VERSION_3_0 where updated (SX)
- Functions from GL_ARB_map_buffer_range where updated (SX)
- Functions from GL_NV_present_video where added (SX)
- Added consts of GL_ARB_instanced_arrays (SX)
- Defines to identify Delphi was changed (prevent for
feature maintenance) (SX)
- Added Extension GL_ATI_meminfo (SX)
- Added Extension GL_AMD_performance_monitor (SX)
- Added Extension GL_AMD_texture_texture4 (SX)
- Added Extension GL_AMD_vertex_shader_tesselator (SX)
- Added Extension GL_EXT_provoking_vertex (SX)
- Added Extension WGL_AMD_gpu_association (SX)
- Added OpenGL 3.1 Core (SX)
- All deprecated stuff can be disabled if you undef the
define DGL_DEPRECATED (SX)
- Added Extension GL_ARB_uniform_buffer_object (SX)
- Added Extension GL_ARB_compatibility (SX)
- Added Extension GL_ARB_copy_buffer (SX)
- Added Extension GL_ARB_shader_texture_lod (SX)
- Remove function from GL_NV_present_video (SX)
- Added Extension WGL_3DL_stereo_control (SX)
- Added Extension GL_EXT_texture_snorm (SX)
- Added Extension GL_AMD_draw_buffers_blend (SX)
- Added Extension GL_APPLE_texture_range (SX)
- Added Extension GL_APPLE_float_pixels (SX)
- Added Extension GL_APPLE_vertex_program_evaluators (SX)
- Added Extension GL_APPLE_aux_depth_stencil (SX)
- Added Extension GL_APPLE_object_purgeable (SX)
- Added Extension GL_APPLE_row_bytes (SX)
- Added OpenGL 3.2 Core (SX)
- Added Extension GL_ARB_depth_clamp (SX)
- Added Extension GL_ARB_draw_elements_base_vertex (SX)
- Added Extension GL_ARB_fragment_coord_conventions (SX)
- Added Extension GL_ARB_provoking_vertex (SX)
- Added Extension GL_ARB_seamless_cube_map (SX)
- Added Extension GL_ARB_sync (SX)
- Added Extension GL_ARB_texture_multisample (SX)
- Added Extension GL_ARB_vertex_array_bgra (SX)
- Added Extension GL_ARB_draw_buffers_blend (SX)
- Added Extension GL_ARB_sample_shading (SX)
- Added Extension GL_ARB_texture_cube_map_array (SX)
- Added Extension GL_ARB_texture_gather (SX)
- Added Extension GL_ARB_texture_query_lod (SX)
- Added Extension WGL_ARB_create_context_profile (SX)
- Added GLX Core up to Version 1.4 (SX)
- Added Extension GLX_ARB_multisample (SX)
- Added Extension GLX_ARB_fbconfig_float (SX)
- Added Extension GLX_ARB_get_proc_address (SX)
- Added Extension GLX_ARB_create_context (SX)
- Added Extension GLX_ARB_create_context_profile (SX)
- Added Extension GLX_EXT_visual_info (SX)
- Added Extension GLX_EXT_visual_rating (SX)
- Added Extension GLX_EXT_import_context (SX)
- Added Extension GLX_EXT_fbconfig_packed_float (SX)
- Added Extension GLX_EXT_framebuffer_sRGB (SX)
- Added Extension GLX_EXT_texture_from_pixmap (SX)
</pascal>

Team

2009-08-27T07:29:40Z

Lossy eX: /* Moderatoren */

= Vorwort =

Auf dieser Seite befindet sich eine Auflistung der Personen, die momentan aktiv daran arbeiten, dass DGL Euch wie gewohnt im Netz mit Informationen versorgt. Bitte beachtet, dass die meisten der Personen nur einen begrenzten Vorrat an Zeit haben. Überlegt daher bitte sorgsam, an wen Ihr Euch wendet.

Im unteren Teil dieser Seite sind die verschiedenen Bereiche von DGL und deren Betreuer aufgelistet. Bitte wendet auch an den passenden Ansprechpartner.

Diese Seite ersetzt nicht das '''[http://www.delphigl.com/launcher.php?em=impressum IMPRESSUM]'''.

= Das Team im Ganzen =
In diesen Abschnitt ist aufgelistet '''wer''' bei [[DelphiGL]] Verantwortung für einen Teil übernommen hat, und '''was''' genau er macht.
== Moderatoren ==
<div align="center">
{|{{Prettytable_B1}} width="80%"
!width="20%"|Forumsname
!width="30%"|Email
!width="50%"|Aufgabenbereich
|-
|[[Benutzer:Phobeus|Phobeus]]
|{{eMail|Phobeus|delphigl.com}}
|
*Technische Pflege des Wikis (Wartung/Updates)
*Betreuung der Hardware
*Freischalten von Usern für das Forum
*Freischalten von Usern für das Wiki
*''News eintragen''
*''allgemeine inhaltliche Kontrolle''
*"der Boss"
|-
|[[Benutzer:Flash|Flash]]
|{{eMail|Flash|delphigl.com}}
|
*Inhaltliche Pflege/Koordination des Wikis
*Community-Aktionen
*Tutorial Lektor
*DGL-Poll pflegen
*News eintragen
*allgemeine inhaltliche Kontrolle im Forum
|-
|[[Benutzer:Frase|Frase]]
|{{eMail|Frase|delphigl.com}}
|
*Technische Unterstützung für Phobeus
*Tutorial Lektor
*News eintragen
*allgemeine inhaltliche Kontrolle im Forum
|-
|[[Benutzer:Delphic|Delphic]]
|{{eMail|delphic|delphigl.com}}
|
*Freischalten von Usern für das Forum
*News eintragen
*allgemeine inhaltliche Kontrolle
|-
|[[Benutzer:Lossy eX|Lossy eX]]
|{{eMail|Lossy|delphigl.com}}
|
*dglOpenGL.pas
*Tutorial Lektor
*News eintragen
*allgemeine inhaltliche Kontrolle
|-
|[[Benutzer:Flo|Flo]]
|{{eMail|Flo|DelphiGL.com}}
|
*DGL-Wiki-Bot Manager
*Freischalten von Usern für das Wiki
*Tutorial Lektor
*News eintragen
*allgemeine inhaltliche Kontrolle
|-
|[[Benutzer:I0n0s|i0n0s]]
|{{eMail|i0n0s|DelphiGL.com}}
|
*DGLSDK
*Freischalten von Usern für das Forum
*Tutorial Lektor
*News eintragen
*allgemeine inhaltliche Kontrolle
|-
|[[Benutzer:Sascha Willems|Sascha Willems]]
|{{eMail|webmaster|delphigl.de}}
|
*News eintragen
*allgemeine inhaltliche Kontrolle
|-
|[[Benutzer:Lord_Horazont|Lord Horazont]]
| -
|
*SVN/WebSVN Betreuung
*News eintragen
*allgemeine inhaltliche Kontrolle
|-
|}
</div>

= Gruppen =
In diesem Teil findet ihr detailierte Informationen, wer für welchen Bereich zuständig ist.
== DGLSDK ==
<div align="center">
{|{{Prettytable_B1}} width="80%"
!width="20%"|Forumsname
!width="30%"|Email
!width="50%"|Aufgabenbereich
|-
|[[Benutzer:I0n0s|i0n0s]]
|{{eMail|i0n0s|DelphiGL.com}}
|
|-
|}
</div>

== DGLOpenGL.pas ==
<div align="center">
{|{{Prettytable_B1}} width="80%"
!width="20%"|Forumsname
!width="30%"|Email
!width="50%"|Aufgabenbereich
|-
|[[Benutzer:Lossy eX|Lossy eX]]
|{{eMail|Lossy|delphigl.com}}
|
*Weiterentwicklung, Debugging
|-
|}
</div>

== Webseite ==
<div align="center">
{|{{Prettytable_B1}} width="80%"
!width="20%"|Forumsname
!width="30%"|Email
!width="50%"|Aufgabenbereich
|-
|[[Benutzer:Phobeus|Phobeus]]
|{{eMail|Phobeus|delphigl.com}}
|
*Technische Pflege des Seite (Wartung/Updates)
*Coding (Integrieren von Neuerungen)
|-
|[[Benutzer:Lord_Horazont|Lord Horazont]]
| -
|
*PHP
|-
|[[Benutzer:Flash|Flash]]
|{{eMail|Flash|delphigl.com}}
|
*DGL-Poll pflegen
|-
|Alle Anderen
|(siehe oben)
|
*News
*Sorgen für angemessene Umgangsformen
|-
|}
</div>

== Wiki ==
<div align="center">
{|{{Prettytable_B1}} width="80%"
!width="20%"|Forumsname
!width="30%"|Email
!width="50%"|Aufgabenbereich
|-
|[[Benutzer:Flash|Flash]]
|{{eMail|Flash|delphigl.com}}
|
*Inhaltliche Pflege des Wikis
*Koordinierung
|-
|[[Benutzer:Phobeus|Phobeus]]
|{{eMail|Phobeus|delphigl.com}}
|
*Technische Pflege des Wikis (Wartung/Updates)
*Betreuung der Hardware
|-
|[[Benutzer:I0n0s|i0n0s]]
|{{eMail|i0n0s|DelphiGL.com}}
|
*Filesektion
|-
|[[Benutzer:Lord_Horazont|Lord Horazont]]
| -
|
*Filesektion (SVN Betreuung)
|-
|}

GL ARB texture env combine

2007-11-03T11:05:35Z

Lossy eX: /* Verwendungsbeispiel */

= GL_ARB_texture_env_combine =
{{Hinweis|Die Orginalspezifikation finden Sie unter "Ressourcen" am Ende des Artikels.}}

== Abfragestring ==
GL_ARB_texture_env_combine

== Abhängigkeiten ==
Diese Extension baut auf OpenGL 1.1 auf und ist abhängig von der OpenGL 1.2.1 Extension [[GL_ARB_multitexture]].

== Beschreibung ==
Diese Extension ist eine wichtige Erweiterung für [[Multitexturing]]. Sie erlaubt es zu bestimmen wie die Farbwerte und Alphawerte von 2 oder mehreren Texturen kombiniert werden soll.

Für jede [[Texture stage]] können hierbei die Berechnung die durchgeführt werden sollen angegeben werden. Zuerst wird die Berechnung für die 0. [[Texture stage]] durchgeführt, dann die Berechnungen für die 1. und so weiter, bis die letzte [[Texture stage]] das Ergebnis an die nächste Stufe der [[Rendering Pipeline]] weiter gibt.

=== '''Verwendung''' ===
Man muss OpenGL für jede [[Texture stage]] mitteilen, dass diese Extension verwendet werden soll. Dies wird mittels

[[glTexEnv|glTexEnvi]]( GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE_ARB);

gemacht. Nun muss sowohl für den Alphawert, als auch für den Farbwert festgelegt werden, welcher Art die Kombinierung sein soll.

=== '''Kombinierungsarten''' ===
<table border=1 rules=all>
<tr>
<td>'''Art'''</td>
<td>'''Formel'''</td>
</tr>
<tr>
<td>'''GL_REPLACE'''</td>
<td>Arg0</td>
</tr>
<tr>
<td>'''GL_MODULATE'''</td>
<td>Arg0 * Arg1</td>
</tr>
<tr>
<td>'''GL_ADD'''</td>
<td>Arg0 + Arg1</td>
</tr>
<tr>
<td>'''GL_ADD_SIGNED_ARB'''</td>
<td>Arg0 + Arg1 - 0.5</td>
</tr>
<tr>
<td>'''GL_SUBTRACT_ARB'''</td>
<td>Arg0 - Arg1</td>
</tr>
<tr>
<td>'''GL_INTERPOLATE_ARB'''</td>
<td>Arg0 * (Arg2) + Arg1 * (1-Arg2)</td>
</tr>
</table>

gesetzt wird die Kombinierungsart mittels:

[[glTexEnv|glTexEnvi]]( GL_TEXTURE_ENV, GL_COMBINE_RGB_ARB, KOMBINIERUNGSART);

für die Farbwerte bzw. mit

[[glTexEnv|glTexEnvi]]( GL_TEXTURE_ENV, GL_COMBINE_ALPHA_ARB, KOMBINIERUNGSART);

für die Alphawerte. Nun müssen noch die Operanden Arg0, Arg1 und Arg2 für die Kombinierung gesetzt werden.

=== '''Operanden''' ===
Für das setzen eines Operanden werden 2 Informationen benötigt. Zum einen die Quelle (Source) der Information, wofür es folgende Möglichkeiten gibt:

<table border=1 rules=all>
<tr>
<td>'''Quelle'''</td>
<td>'''Beschreibung'''</td>
</tr>
<tr>
<td>'''GL_PRIMARY_COLOR_ARB'''</td>
<td>Farbwert der mit [[glColor]] oder vergleichbarem gesetzt wurde.</td>
</tr>
<tr>
<td>'''GL_TEXTURE'''</td>
<td>Wert der aktuellen [[Textur]] (in der aktuellen [[Texture stage]])</td>
</tr>
<tr>
<td>'''GL_CONSTANT_ARB'''</td>
<td>Wert der mit [[glTexEnv]]fv] für die aktuelle [[Textur]] gesetzt wurde.</td>
</tr>
<tr>
<td>'''GL_PREVIOUS_ARB'''</td>
<td>Ergebnis der Berechnungen aus der vorherigen [[Texture stage]], oder gleich wie GL_PRIMARY_COLOR_ARB, wenn es sich um die aller erste [[Texture stage]] handelt.</td>
</tr>
</table>

nun erfolgt noch die Unterscheidung für welchen Operanden (Arg0, Arg1 oder Arg2) der Wert gesetzt werden soll, und ob dieser Operand für die RGB- oder Alphawert Berechnung verwendet werden soll. Hier gibt es folgende Möglichkeiten:

<table border=1 rules=all>
<tr>
<td>'''Art der Quelle'''</td>
<td>'''Beschreibung'''</td>
</tr>
<tr>
<td>'''GL_SOURCE0_RGB_ARB'''</td>
<td>Wert für Arg0 in der RGB Berechnung setzen</td>
</tr>
<tr>
<td>'''GL_SOURCE1_RGB_ARB'''</td>
<td>Wert für Arg1 in der RGB Berechnung setzen</td>
</tr>
<tr>
<td>'''GL_SOURCE2_RGB_ARB'''</td>
<td>Wert für Arg2 in der RGB Berechnung setzen</td>
</tr>
<tr>
<td>'''GL_SOURCE0_ALPHA_ARB'''</td>
<td>Wert für Arg0 in der Alpha Berechnung setzen</td>
</tr>
<tr>
<td>'''GL_SOURCE1_ALPHA_ARB'''</td>
<td>Wert für Arg1 in der Alpha Berechnung setzen</td>
</tr>
<tr>
<td>'''GL_SOURCE2_ALPHA_ARB'''</td>
<td>Wert für Arg2 in der Alpha Berechnung setzen</td>
</tr>
</table>

gesetzt werden diese Werte nun mit

[[glTexEnv|glTexEnvi]]( GL_TEXTURE_ENV, Art der Quelle, Quelle );

Nun weiß OpenGL welchen Wert er für die Berechnung nehmen soll, jedoch muss man auch noch angeben Welcher Teil des Wertes verwendet werden soll. Für die RGB Berechnung hat man hier folgende Möglichkeiten:

<table border=1 rules=all>
<tr>
<td>'''Operand RGB-Berechnung'''</td>
<td>'''Beschreibung'''</td>
</tr>
<tr>
<td>'''GL_SRC_COLOR'''</td>
<td>Verwende RGB Teil des Wertes</td>
</tr>
<tr>
<td>'''GL_ONE_MINUS_SRC_COLOR'''</td>
<td>Verwende 1-RGB Teil des Wertes</td>
</tr>
<tr>
<td>'''GL_SRC_ALPHA'''</td>
<td>Verwende Alpha Teil des Wertes</td>
</tr>
<tr>
<td>'''GL_ONE_MINUS_SRC_ALPHA'''</td>
<td>Verwende 1-Alpha Teil des Wertes</td>
</tr>
</table>

Da RGB 3 Werte sind und Alpha nur 1 Wert gibt es für die Alphaberechnung nur 2 Arten von Operanden:

<table border=1 rules=all>
<tr>
<td>'''Operand Alphaberechnung'''</td>
<td>'''Beschreibung'''</td>
</tr>
<tr>
<td>'''GL_SRC_ALPHA'''</td>
<td>Verwende Alpha Teil des Wertes</td>
</tr>
<tr>
<td>'''GL_ONE_MINUS_SRC_ALPHA'''</td>
<td>Verwende 1-Alpha Teil des Wertes</td>
</tr>
</table>

Um anzugeben wofür der Operand eingesetzt werden soll muss man noch wählen zwischen:

<table border=1 rules=all>
<tr>
<td>'''Art des Operanden'''</td>
<td>'''Beschreibung'''</td>
</tr>
<tr>
<td>'''GL_OPERAND0_RGB_ARB'''</td>
<td>Operand für Arg0 in der RGB Berechnung setzen</td>
</tr>
<tr>
<td>'''GL_OPERAND1_RGB_ARB'''</td>
<td>Operand für Arg1 in der RGB Berechnung setzen</td>
</tr>
<tr>
<td>'''GL_OPERAND2_RGB_ARB'''</td>
<td>Operand für Arg2 in der RGB Berechnung setzen</td>
</tr>
<tr>
<td>'''GL_OPERAND0_ALPHA_ARB'''</td>
<td>Operand für Arg0 in der Alpha Berechnung setzen</td>
</tr>
<tr>
<td>'''GL_OPERAND1_ALPHA_ARB'''</td>
<td>Operand für Arg1 in der Alpha Berechnung setzen</td>
</tr>
<tr>
<td>'''GL_OPERAND2_ALPHA_ARB'''</td>
<td>Operand für Arg2 in der Alpha Berechnung setzen</td>
</tr>
</table>

gesetzt werden diese Werte nun mit [[glTexEnv]]i]( GL_TEXTURE_ENV, Art des Operanden, Operand Alphaberechnung bzw. Operand RGB-Berechnung );

=== '''Scalen''' ===
Am Ende der Berechnung einer [[Texture stage]] kann der errechnete Wert noch mit einem Scale Faktor multipliziert werden, und zwar mittels

[[glTexEnv|glTexEnvf]]( GL_TEXTURE_ENV, RGB_SCALE_ARB, Faktor );

Gültige Werte für Faktor sind hier jedoch nur 1.0, 2.0 oder 4.0. Am Ende Wird das Ergebnis noch auf den Wertebereich [0|1] gebracht. Zu hohe oder zu niedrige Werte werden mit 1.0 bzw. mit 0.0 ersetzt.

== Neue Tokens ==

=== Neue Parameterwerte ===
'''Für [[glTexEnv]]'''
wenn ''pname'' '''GL_TEXTURE_ENV_MODE''' ist, dann ist für ''param'' folgender zustäzlicher Wert gültig:
<table border=1 rules=all>
<tr>
<td>'''GL_COMBINE_ARB'''</td>
<td>0x8570</td>
<td>Diese Extension wird für diese [[Texture stage]] aktiviert</td>
</tr>
</table>

'''Für [[glTexEnv]]'''
wenn ''target'' '''TEXTURE_ENV''' ist, dann sind für ''pname'' folgende zustäzliche Werte gültig:
<table border=1 rules=all>
<tr>
<td>'''GL_COMBINE_RGB_ARB'''</td>
<td>0x8571</td>
<td>Berechnungsart für RGB angeben</td>
</tr>
<tr>
<td>'''GL_COMBINE_ALPHA_ARB'''</td>
<td>0x8572</td>
<td>Berechnungsart für Alpha angeben</td>
</tr>
<tr>
<td>'''GL_SOURCE0_RGB_ARB'''</td>
<td>0x8580</td>
<td>Quelle für Arg0 der RGB Berechnung angeben</td>
</tr>
<tr>
<td>'''GL_SOURCE1_RGB_ARB'''</td>
<td>0x8581</td>
<td>Quelle für Arg1 der RGB Berechnung angeben</td>
</tr>
<tr>
<td>'''GL_SOURCE2_RGB_ARB'''</td>
<td>0x8582</td>
<td>Quelle für Arg2 der RGB Berechnung angeben</td>
</tr>
<tr>
<td>'''GL_SOURCE0_ALPHA_ARB'''</td>
<td>0x8588</td>
<td>Quelle für Arg0 der Alpha Berechnung angeben</td>
</tr>
<tr>
<td>'''GL_SOURCE1_ALPHA_ARB'''</td>
<td>0x8589</td>
<td>Quelle für Arg1 der Alpha Berechnung angeben</td>
</tr>
<tr>
<td>'''GL_SOURCE2_ALPHA_ARB'''</td>
<td>0x858A</td>
<td>Quelle für Arg2 der Alpha Berechnung angeben</td>
</tr>
<tr>
<td>'''GL_OPERAND0_RGB_ARB'''</td>
<td>0x8590</td>
<td>Teil der Quelle für Arg0 der RGB Berechnung angeben</td>
</tr>
<tr>
<td>'''GL_OPERAND1_RGB_ARB'''</td>
<td>0x8591</td>
<td>Teil der Quelle für Arg1 der RGB Berechnung angeben</td>
</tr>
<tr>
<td>'''GL_OPERAND2_RGB_ARB'''</td>
<td>0x8592</td>
<td>Teil der Quelle für Arg2 der RGB Berechnung angeben</td>
</tr>
<tr>
<td>'''GL_OPERAND0_ALPHA_ARB'''</td>
<td>0x8598</td>
<td>Teil der Quelle für Arg0 der Alpha Berechnung angeben</td>
</tr>
<tr>
<td>'''GL_OPERAND1_ALPHA_ARB'''</td>
<td>0x8599</td>
<td>Teil der Quelle für Arg1 der Alpha Berechnung angeben</td>
</tr>
<tr>
<td>'''GL_OPERAND2_ALPHA_ARB'''</td>
<td>0x859A</td>
<td>Teil der Quelle für Arg2 der Alpha Berechnung angeben</td>
</tr>
<tr>
<td>'''GL_RGB_SCALE_ARB'''</td>
<td>0x8573</td>
<td>Scale Faktor für RGB Berechnung angeben</td>
</tr>
<tr>
<td>'''GL_ALPHA_SCALE'''</td>
<td></td>
<td>Scale Faktor für Alpha Berechnung angeben</td>
</tr>
</table>

'''Für [[glTexEnv]]'''
wenn ''pname'' '''GL_COMBINE_RGB_ARB''' oder '''GL_COMBINE_ALPHA_ARB''' ist, dann sind für ''param'' folgende Werte gültig:
<table border=1 rules=all>
<tr>
<td>'''GL_REPLACE'''</td>
<td></td>
<td>Arg0</td>
</tr>
<tr>
<td>'''GL_MODULATE'''</td>
<td></td>
<td>Arg0 * Arg1</td>
</tr>
<tr>
<td>'''GL_ADD'''</td>
<td></td>
<td>Arg0 + Arg1</td>
</tr>
<tr>
<td>'''GL_ADD_SIGNED_ARB'''</td>
<td>0x8574</td>
<td>Arg0 + Arg1 - 0.5</td>
</tr>
<tr>
<td>'''GL_INTERPOLATE_ARB'''</td>
<td>0x8575</td>
<td>Arg0 * (Arg2) + Arg1 * (1-Arg2)</td>
</tr>
<tr>
<td>'''GL_SUBTRACT_ARB'''</td>
<td>0x84E7</td>
<td>Arg0 - Arg1</td>
</tr>
</table>

'''Für [[glTexEnv]]'''
wenn ''pname'' '''GL_SOURCE0_RGB_ARB''', '''GL_SOURCE1_RGB_ARB''', '''GL_SOURCE2_RGB_ARB''', '''GL_SOURCE0_ALPHA_ARB''', '''GL_SOURCE1_ALPHA_ARB''', oder '''GL_SOURCE2_ALPHA_ARB''' ist, dann sind für ''param'' folgende Werte gültig:
<table border=1 rules=all>
<tr>
<td>'''GL_TEXTURE'''</td>
<td></td>
<td>Aktuelle Textur als Quelle verwenden</td>
</tr>
<tr>
<td>'''GL_CONSTANT_ARB'''</td>
<td>0x8576</td>
<td>Mit [[glTexEnv]] für diese Textur gesetzte Farbe als Quelle verwenden</td>
</tr>
<tr>
<td>'''GL_PRIMARY_COLOR_ARB'''</td>
<td>0x8577</td>
<td>Mit [[glColor]] oder vergleichbarem gesetzte Farbe als Quelle verwenden</td>
</tr>
<tr>
<td>'''GL_PREVIOUS_ARB'''</td>
<td>0x8578</td>
<td>Ergebnis der vorigen [[Texture Stage]] als Quelle verwenden oder gleich wie GL_PRIMARY_COLOR_ARB wenn es die erste [[Texture stage]] ist.</td>
</tr>
</table>

'''Für [[glTexEnv]]'''
wenn ''pname'' '''GL_OPERAND0_RGB_ARB''', '''GL_OPERAND1_RGB_ARB''' oder '''GL_OPERAND2_RGB_ARB''' ist, dann sind für ''param'' folgende Werte gültig:
<table border=1 rules=all>
<tr>
<td>'''SRC_COLOR'''</td>
<td></td>
<td>RGB Teil der Quelle als Operand verwenden</td>
</tr>
<tr>
<td>'''GL_ONE_MINUS_SRC_COLOR'''</td>
<td></td>
<td>1-RGB Teil der Quelle als Operand verwenden</td>
</tr>
<tr>
<td>'''GL_SRC_ALPHA'''</td>
<td></td>
<td>Alpha Teil der Quelle als Operand verwenden</td>
</tr>
<tr>
<td>'''GL_ONE_MINUS_SRC_ALPHA'''</td>
<td></td>
<td>1-Alpha Teil der Quelle als Operand verwenden</td>
</tr>
</table>

'''Für [[glTexEnv]]'''
wenn ''pname'' '''GL_OPERAND0_ALPHA_ARB''', '''GL_OPERAND1_ALPHA_ARB''' oder '''GL_OPERAND2_ALPHA_ARB''' ist, dann sind für ''param'' folgende Werte gültig:
<table border=1 rules=all>
<tr>
<td>'''GL_SRC_ALPHA'''</td>
<td></td>
<td>Alpha Teil der Quelle als Operand verwenden</td>
</tr>
<tr>
<td>'''GL_ONE_MINUS_SRC_ALPHA'''</td>
<td></td>
<td>1-Alpha Teil der Quelle als Operand verwenden</td>
</tr>
</table>

'''Für [[glTexEnv]]'''
wenn ''pname'' '''GL_RGB_SCALE_ARB''' oder '''GL_ALPHA_SCALE''' ist, dann sind für ''param'' folgende Werte gültig:
<table border=1 rules=all>
<tr>
<td>'''1.0'''</td>
</tr>
<tr>
<td>'''2.0'''</td>
</tr>
<tr>
<td>'''4.0'''</td>
</tr>
</table>

=== '''Neue States''' ===
<table border=1 rules=all>
<tr>
<td>'''Name'''</td>
<td>'''Abfrage mit'''</td>
<td>'''Initialwert'''</td>
</tr>
<tr>
<td>'''GL_COMBINE_RGB_ARB '''</td>
<td>GetTexEnviv</td>
<td>GL_MODULATE</td>
</tr>
<tr>
<td>'''GL_COMBINE_ALPHA_ARB'''</td>
<td>GetTexEnviv</td>
<td>GL_MODULATE</td>
</tr>
<tr>
<td>'''GL_SOURCE0_RGB_ARB'''</td>
<td>GetTexEnviv</td>
<td>GL_TEXTURE</td>
</tr>
<tr>
<td>'''GL_SOURCE1_RGB_ARB'''</td>
<td>GetTexEnviv</td>
<td>GL_PREVIOUS_ARB</td>
</tr>
<tr>
<td>'''GL_SOURCE2_RGB_ARB'''</td>
<td>GetTexEnviv</td>
<td>GL_CONSTANT_ARB</td>
</tr>
<tr>
<td>'''GL_SOURCE0_ALPHA_ARB'''</td>
<td>GetTexEnviv</td>
<td>GL_TEXTURE</td>
</tr>
<tr>
<td>'''GL_SOURCE1_ALPHA_ARB'''</td>
<td>GetTexEnviv</td>
<td>GL_PREVIOUS_ARB</td>
</tr>
<tr>
<td>'''GL_SOURCE2_ALPHA_ARB'''</td>
<td>GetTexEnviv</td>
<td>GL_CONSTANT_ARB</td>
</tr>
<tr>
<td>'''GL_OPERAND0_RGB_ARB'''</td>
<td>GetTexEnviv</td>
<td>GL_COLOR</td>
</tr>
<tr>
<td>'''GL_OPERAND1_RGB_ARB'''</td>
<td>GetTexEnviv</td>
<td>GL_COLOR</td>
</tr>
<tr>
<td>'''GL_OPERAND2_RGB_ARB'''</td>
<td>GetTexEnviv</td>
<td>GL_ALPHA</td>
</tr>
<tr>
<td>'''GL_OPERAND0_ALPHA_ARB'''</td>
<td>GetTexEnviv</td>
<td>GL_ALPHA</td>
</tr>
<tr>
<td>'''GL_OPERAND1_ALPHA_ARB'''</td>
<td>GetTexEnviv</td>
<td>GL_ALPHA</td>
</tr>
<tr>
<td>'''GL_OPERAND2_ALPHA_ARB'''</td>
<td>GetTexEnviv</td>
<td>GL_ALPHA</td>
</tr>
<tr>
<td>'''GL_RGB_SCALE_ARB'''</td>
<td>GetTexEnvfv</td>
<td>1.0</td>
</tr>
<tr>
<td>'''GL_ALPHA_SCALE'''</td>
<td>GetTexEnvfv</td>
<td>1.0</td>
</tr>
</table>

== Abhängigkeiten ==
[[GL_ARB_multitexture]]

== Verwendungsbeispiel ==
Folgendender Code benutzt Multitexturing und texture_env_combine um über die erste Textur eine Zweite zu blenden. Die zweite Textur wird dabei mit einem Alphawert verrechnet. Das Ganze entspricht vom Ergebniss dem was man erreichen würde wenn man die Fläche mehrfach zeichnen (multi pass) würde und dabei als Blendfunktion GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA benutzen würde.

<pascal>var
Color: array [0..3] of single;
begin
glActiveTexture(GL_TEXTURE0);
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
fTex.Bind;</pascal>
Die erste Textur kann ganz normal an die TMU0 gebunden werden.

<pascal> glActiveTexture(GL_TEXTURE1);
fCube.Bind;</pascal>
Die Zweite Textur wird auch normal gebunden.

<pascal> Color[0] := 0;
Color[1] := 0;
Color[2] := 0;
Color[3] := 0.125;
glTexEnvfv(GL_TEXTURE_ENV, GL_TEXTURE_ENV_COLOR, @Color);</pascal>
Damit wird die Farbe gesetzt. Aus dieser Farbe wird im aktuellen Beispiel aber lediglich der Alphakanal benutzt.

<pascal> glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE);</pascal>
texture_env_combine aktivieren.

<pascal> glTexEnvi(GL_TEXTURE_ENV, GL_COMBINE_RGB, GL_INTERPOLATE);</pascal>
Die Kombinierungsart festlegen. Nähere informationen dazu wurden bereits oben beschrieben.

<pascal> glTexEnvi(GL_TEXTURE_ENV, GL_SOURCE0_RGB, GL_TEXTURE);
glTexEnvi(GL_TEXTURE_ENV, GL_SOURCE1_RGB, GL_PREVIOUS);
glTexEnvi(GL_TEXTURE_ENV, GL_SOURCE2_ALPHA, GL_CONSTANT);</pascal>
Die einzelnen Operanden festlegen. Dieses richten sich nach der Kombinierungsart.

<pascal> glBegin(GL_QUADS);
glTexCoord2f(0, 1);
glVertex3f(- 2, - 2, 0);

...
glEnd;</pascal>
Objekte zeichnen. In diesem Fall nur eine simple Fläche.

<pascal> glActiveTexture(GL_TEXTURE1);
fCube.Unbind;

glActiveTexture(GL_TEXTURE0);
fTex.Unbind;
end;</pascal>
Die Texturen wieder aus dem TMUs entbinden.

Mit diesem Code lässt sich auch auf Objekten eine leichte Spiegelung der Umgebung erzeugen. Dazu muss für die zweite Textur lediglich eine CubeMap oder SphereMap benutzt werden.

== Ressourcen ==
[http://www.delphi3d.net/hardware/extsupport.php?extension=GL_ARB_texture_env_combine Hardware Unterstützung] 
[http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_env_combine.txt Original Extension-Spezifikation]

Dithering

2007-10-10T07:59:55Z

Lossy eX: /* Floyd-Steinberg Error Diffusion */

{{Unvollständig}}
{{Bildwunsch|Für die unterschiedlichen Verfahren ein Bild bitte.}}
== Übersicht ==
Dithering wird verwendet um mit wenigen Farben viele Farben zu simulieren. In den Printmedien wird Dithering häufig auch als ''Halftoning'' bezeichnet und verwendet. Hierbei werden schwarze und weisse Bildpunkte so angeordnet, dass man den Eindruck eines Graustufen-Bildes erhält.
Nachteil an der Sache ist, das meistens die Auflösung reduziert wird.

== Dithering und OpenGL ==
Der verwendete Dithering-Algorithmus ist abhängig von der OpenGL-Implementierung. Allerdings kann ein guter Dithering-Algorithmus die Bildqualität auf Displays mit kleiner Farbzahl stark erhöhen. Dithering ist standardmässig eingeschaltet und kann mit [[glEnable]] bzw. [[glDisable]] und dem Parameter '''GL_DITHER''' kontrolliert werden.
Bei hoher Farbzahl ist Dithering nicht zwingend erforderlich und kann aus Perfomance-Gründen abgeschaltet werden.

== Technischer Hintergrund ==
Aus Gründen der Übersichtlichkeit wird Dithering anhand von 256 Graustufen erläutert. Um Dithering auf Farbe anzuwenden, werden die vorgestellten Techniken auf jeden Farbkanal angewandt.

=== Naive Ansätze ===
==== Down Scaling ====
[[Bild:Downscale.gif|right|framed|Wiki-Logo mit Downscaling]]
Im einfachsten Ansatz wird für jeden Pixel eine Entscheidung getroffen, welchen Wert er zugewiesen bekommt. Das heißt die Originalfarben werden gleichmäßig auf die reduzierte Palette aufgeteilt. Bei einer Reduktion auf Schwarz und Weiss werden z.B. Pixel mit einem Grauwert >= 128 auf Weisse Pixel und alle anderen Pixel auf Schwarz abgebildet.

==== Random Decision ====
Eine deutliche Verbesserung erzielt man wenn die Entscheidung nicht über den Wert des Pixels getroffen wird, sondern dieser Wert als Wahrscheinlichkeit betrachtet wird ob ein Pixel gesetzt wird oder nicht. So wird ein Pixel mit einem Wert von 152 mit der Wahrscheinlichkeit 152/256 durch einen weissen Pixel ersetzt.
Die harten Kanten zwischen Weiss und Schwarz werden durch diese Weise zwar ersetzt, aber es ist ein ziemlich guter Zufallszahlen-Generator erforderlich um akzeptable Ergebnisse zu erhalten.

==== Filling Patterns ====
Filling Patterns sind reguläre Muster, die dazu verwendet werden eine gewisse Anzahl an Graustufen abzubilden. Mit einem nxn Muster ist es möglich n*n+1 verschiedene Graustufen darzustellen. Als Beispiel die Muster für ein 2x2 (5 Graustufen) Muster.
{|border="1" cellspacing="0" align="center"
|+2x2 Muster = 5 Graustufen
!width="50px"| 0%
!width="50px"| 25%
!width="50px"| 50%
!width="50px"| 75%
!width="50px"| 100%
|- align = "center"
|00 00||10 00||10 01||11 01||11 11
|}
Hierbei sollte man versuchen die Pixel so irregulär wie möglich zu verteilen, da sonst sichtbare Artefakte (horizontale/vertikale) Linien in den Bilder entstehen. Das Muster wird auf einen gleichgrossen Bereich von Pixeln im Bild gelegt. Man berechnet den Mittelwert der Pixel unter dem Muster und entscheided dann, welches Muster anstelle der nxn Pixel verwendet wird.

=== Dither Matrizen ===
Dither Matrizen sind eine Weiterentwicklung von Filling Patterns. Eine Dither-Matrix der Grösse nxn wird mit den Werten von [0..n*n-1] gefüllt und bewirkt eine Reduktion der Graustufen auf nxn+1.
Im Unterschied zu Filling Patterns werden hier allerdings die einzelnen Pixel stärker berücksichtigt. Je nach Art des Musters in dem die Werte in der Matrix verteilt werden spricht man von Clustered-Dot Dithering (Laserdrucker, Printmedien, etc.) oder Dispersed Dot Dithering.
{|border="1" cellspacing="0" align="center"
|+4x4 Dither-Matrizen
!Dis
!per
!sed
!Dot
!---
!Clu
!ste
!red
!Dot
|- align = "center"
| 0|| 8|| 2||10|| ||13||10|| 6||14
|- align = "center"
|12|| 4||14|| 6|| || 5|| 0|| 3||11
|- align = "center"
| 3||11|| 1|| 9|| || 9|| 2|| 1|| 7
|- align = "center"
|15|| 7||13|| 5|| ||12|| 4|| 8||15
|}

Je nach Ausgabemedium werden unterschiedliche Verfahren angewendet.
Hat das Ausgabemedium eine höhere Auflösung als das Eingabebild, so werden die Dither-Matrizen auf jeden Pixel angewandt. Für jeden Pixel wird ein Wert berechnet, der im Wertebereich [0..n*n-1] liegt und in der Matrix werden alle Elemente < dieses Wertes angeschaltet. Eine weit verbreitete Methode zur Berechnung des Wertes ist der Modulo-Operator (C mod n*n - wobei C die aktuelle Pixelfarbe ist).
Bei niedrigerer Auflösung wird das gleiche Verfahren wie bei Filling Patterns angewandt, was die Auflösung allerdings drastisch reduziert.
Die Verteilung der Werte in der Matrix ist übrigens beliebig. Man sollte aber beachten das reguläre Muster zu sichtbaren Artefakten im Ausgabe-Bild führen.

=== Floyd-Steinberg Error Diffusion ===
[[Bild:Dithering.gif|right|framed|Das Wiki-Logo mit Floyd-Steinberg Dithering vereinfacht.]]
Das Floyd-Steinberg Dithering arbeitet nach dem Error Diffusion Verfahren. Der Algorithmus sucht in der Farbpalette nach der bestmöglichen Farbe, die in den aktuellen Farbwert hineinpasst. Der Farbwert aus der Palette darf nicht größer sein als die eigentliche Farbe. Die Abweichung des Paletteneintrages zur ursprünglichen Farbe (auch Fehler genannt) wird nach einem festen Schema auf die umliegenden Pixel verteilt. Dadurch wird bewerkstelligt, dass das resultierende Bild, vom Pixeldurchschnitt her, so nah wie möglich an dem Original liegt.
{| border="1" cellpadding="6" rules="all"
|-
|
| bgcolor="#DDDDDD" | Pixel
|7/16
|-
|3/16
|5/16
|1/16
|-
|}

Um die Entstehung von zu gleichmäßige Mustern zu verhindern wird abwechselnd je eine Zeile von Links und eine von Rechts verarbeitet.

== Literatur ==
*OpenGL Superbible, 3rd. Edition, Wright & Lipchak, SAMS
*Computer Graphics - Principles and Practice, Second Edition in C, Foley & van Dam & Feiner & Hughes, Addison Wesley
*Skript zur Vorlesung Computer Graphics I, 1st Edit. 3rd Rev., Kobbelt & Sar-Dessai, Lehrstuhl für Informatik 8 - RWTH Aachen
*Périphériques de tracé, d'affichage et d'impression 2-D, Notes de cours, Hersch, Laboratoire de Systèmes Périphériques - EPFL

TTF FontFaceStyleName

2007-09-14T18:04:38Z

Lossy eX: Die Seite wurde neu angelegt: = TTF_FontFaceStyleName = == Name == '''TTF_FontFaceStyleName''' - Gibt den Namen des Stils der Schrift zurück. == Delphi-Spezifikation == function '''TTF_FontFac...

= TTF_FontFaceStyleName =

== Name ==
'''TTF_FontFaceStyleName''' - Gibt den Namen des Stils der Schrift zurück.

== Delphi-Spezifikation ==
function '''TTF_FontFaceStyleName'''( ''font'' : PTTF_Font ) : pChar;

== Parameter ==

{| border="1" rules="all"
! ''font''
| Eine geladene Schrift
|}

== Beschreibung ==
Gibt den Namen des Stils der Schrift zurück. Dabei handelt es sich unter Anderem um solche Angaben wie "regular", "bold", "italic" und viele mehr, da diese Texte von dem Schriftenersteller frei gewählt werden können.

== Hinweise ==
Ein '''nil''' an die Funktion erzeugt einen Segfault.

== Rückgabewert ==
Der Rückgabewert ist ein Zeiger auf einen nullterminierten String. Sollte diese Information nicht verfügbar sein so ist der Rückgabewert '''nil'''.

== Siehe auch ==
[[TTF_FontFaces]], [[TTF_FontFaceIsFixedWidth]], [[TTF_FontFaceFamilyName]]

[[Kategorie:SDLTTF|FontFaceStyleName]]

TTF FontFaceFamilyName

2007-09-14T17:57:03Z

Lossy eX: Die Seite wurde neu angelegt: = TTF_FontFaceFamilyName = == Name == '''TTF_FontFaceFamilyName''' - Gibt den Namen der geladenen Schrift zurück. == Delphi-Spezifikation == function '''TTF_FontF...

= TTF_FontFaceFamilyName =

== Name ==
'''TTF_FontFaceFamilyName''' - Gibt den Namen der geladenen Schrift zurück.

== Delphi-Spezifikation ==
function '''TTF_FontFaceFamilyName'''( ''font'' : PTTF_Font ) : pChar;

== Parameter ==

{| border="1" rules="all"
! ''font''
| Eine geladene Schrift
|}

== Beschreibung ==
Gibt den Namen der geladenen Schrift zurück. Der Name ist normal das was man in allen Anwendungsprogrammen von einem Font zu sehen bekommt.

== Hinweise ==
Ein '''nil''' an die Funktion erzeugt einen Segfault.

== Rückgabewert ==
Der Rückgabewert ist ein Zeiger auf einen nullterminierten String. Sollte diese Information nicht verfügbar sein so ist der Rückgabewert '''nil'''.

== Siehe auch ==
[[TTF_FontFaces]], [[TTF_FontFaceIsFixedWidth]], [[TTF_FontFaceStyleName]]

[[Kategorie:SDLTTF|FontFaceFamilyName]]

TTF FontFaceIsFixedWidth

2007-09-14T17:40:10Z

Lossy eX: Die Seite wurde neu angelegt: = TTF_FontFaceIsFixedWidth = == Name == '''TTF_FontFaceIsFixedWidth''' - Gibt zurück ob die übergebene Schrift eine nicht proportionale Schrift ist. == Delphi-Spe...

= TTF_FontFaceIsFixedWidth =

== Name ==
'''TTF_FontFaceIsFixedWidth''' - Gibt zurück ob die übergebene Schrift eine nicht proportionale Schrift ist.

== Delphi-Spezifikation ==
function '''TTF_FontFaceIsFixedWidth'''( ''font'' : PTTF_Font ) : Integer;

== Parameter ==

{| border="1" rules="all"
! ''font''
| Eine geladene Schrift
|}

== Beschreibung ==
Gibt zurück ob es sich um eine nicht proportionale Schrift handelt. Im Gegensatz zu proportionalen Schriften besitzen die Zeichen, bei nicht proportionalen, immer die gleiche Breite. Um die Breite eines Textes zu bestimmen genügt also die Breite eines einzelnen Zeichens. Typisches Einsatzgiet von nicht proportionalen Schriften sind Befehlskonsolen und Texteditore jeglicher Art.

== Hinweise ==
Ein '''nil''' an die Funktion erzeugt einen Segfault.

== Rückgabewert ==
Der Rückgabewert ist größer 0 wenn es sich um eine nicht proportionale Schrift handelt ansonsten 0.

== Siehe auch ==
[[TTF_FontFaces]], [[TTF_FontFaceFamilyName]], [[TTF_FontFaceStyleName]], [[TTF_GlyphMetrics]]

[[Kategorie:SDLTTF|FontFaceIsFixedWidth]]

TTF FontFaces

2007-09-14T17:32:44Z

Lossy eX: /* TTF_FontFaces */

= TTF_FontFaces =

== Name ==
'''TTF_FontFaces''' - Gibt die Anzahl der, in einer Schriftdatei enthalten, Schriften (Unterschriften) zurück.

== Delphi-Spezifikation ==
function '''TTF_FontFaces'''( ''font'' : PTTF_Font ) : Longint;

== Parameter ==

{| border="1" rules="all"
! ''font''
| Eine geladene Schrift
|}

== Beschreibung ==
In manchen Schriftdateien gibt es die Möglichkeit gleich mehrere Schriften abzulegen. TTF_FontFaces gibt die Anzahl der Unterschriften zurück. Diese Information ist allerdings recht nutzlos, da SDL_ttf nirgendswo die Ansteuerung von Unterschriften ermöglicht. Da aber nahezu alle Schriften so etwas nicht unterstützen ist das auch nicht weiter tragisch.

== Hinweise ==
Ein '''nil''' an die Funktion erzeugt einen Segfault.

== Rückgabewert ==
Die Anzahl der enthalten Unterschriften.

== Siehe auch ==
[[TTF_FontFaceIsFixedWidth]], [[TTF_FontFaceFamilyName]], [[TTF_FontFaceStyleName]]

[[Kategorie:SDLTTF|FontFaces]]

TTF FontFaces

2007-09-14T17:26:14Z

Lossy eX: Die Seite wurde neu angelegt: = TTF_FontFaces = == Name == '''TTF_FontFaces''' - Gibt die Anzahl der, in einer Fontdatei enthalten, Fonts (Subfonts) zurück. == Delphi-Spezifikation == function...

= TTF_FontFaces =

== Name ==
'''TTF_FontFaces''' - Gibt die Anzahl der, in einer Fontdatei enthalten, Fonts (Subfonts) zurück.

== Delphi-Spezifikation ==
function '''TTF_FontFaces'''( ''font'' : PTTF_Font ) : Longint;

== Parameter ==

{| border="1" rules="all"
! ''font''
| Eine geladene Schrift
|}

== Beschreibung ==
In manchen Fontsdateien gibt es die Möglichkeit gleich mehrere Fonts abzulegen. TTF_FontFaces gibt die Anzahl der Fonts (Subfonts) zurück. Diese Information ist allerdings recht nutzlos, da SDL_ttf nirgendswo die Ansteuerung von Subfonts ermöglicht. Da aber nahezu alle Fonts so etwas sowieso nicht unterstützen ist das auch nicht weiter tragisch.

== Hinweise ==
Ein '''nil''' an die Funktion erzeugt einen Segfault.

== Rückgabewert ==
Die Anzahl der enthalten Subfonts.

== Siehe auch ==
[[TTF_FontFaceIsFixedWidth]], [[TTF_FontFaceFamilyName]], [[TTF_FontFaceStyleName]]

[[Kategorie:SDLTTF|FontFaces]]

TTF Rendermode

2007-09-14T11:09:18Z

Lossy eX: /* Anwendung in OpenGL */

= TTF_Rendermode =

[[SDL_TTF]] kennt drei verschiedene Rendermodi:

== Solid ==
'''Quick and Dirty'''

Erstellt eine 8-Bit palettierte [[SDL_Surface|Surface]] und rendert den gegebenen Text in schneller Qualität mit der gegebenen Schrift und Farbe. Der Pixelwert 0 ist der Colorkey, der den transparenten Hintergrund vorgibt, wenn es kopiert wird. Pixel- und Colormapwert 1 wird für die Vordergrundfarbe des Textes gesetzt. Dies erlaubt die Textfarbe zu ändern ohne den Text neuzurendern. Der Palettenindex 0 wird natürlich nicht gezeichnet, wenn es auf eine andere Surface kopiert wird, seitdem es ein Colorkey und somit die Transparenz ist, da die aktuelle Farbe 255 minus jeden der RGB Komponenten der Vordergrundfarbe ist.

Dies ist der schnellste Rendermodus von allen. Das Resultat hat keine Box um den Text, dafür ist der Text nicht glatt. Dieser Modus ist für FPS und andere schnell aktualisierende Textanzeigen geeignet.

[[Bild:TTF solid.png|framed|center]]

== Shaded ==
'''Slow and Nice, but with a Solid Box'''

Erstellt eine [[SDL_Surface|Surface]] mit einer 8-Bit Farbpalette und rendert den gegebenen Text in hoher Qualität mit der gegebenen Schrift und Farbe. Der 0 Pixelwert ist der Hintergrund, während die anderen Pixel variirende Farben zwischen der Vordergrundfarbe und Hintergrundfarbe sind. Dies resultiert in eine Box mit der Farbe des Hintergrundes um den Text in der Vordergrundfarbe. Der Text ist antialiased. Das Rendern ist langsamer als Solid, aber in ungefähr der selben Zeit wie Blended. Die resultierende Surface sollte sich so schnell wie eine 'Solid-Surface' kopieren lassen. Geeignet für netten Text wenn man zeitgleich mit der Box leben kann.

[[Bild:TTF blended.png|framed|center]]

== Blended ==
'''Slow Slow Slow, but Ultra Nice over another image'''

Erstellt eine 32-Bit ARGB [[SDL_Surface|Surface]] und rendert den gegebenen Text in hoher Qualität unter Benutzung von [[Blenden|Alpha Blending]]. Dies resultiert in eine Surface mit Alpha Transparenz, sodass man keine solide farbige Box um den Text hat. Der Text ist antialiased. Das Render ist langsamer als Solid, aber in der selben Zeit wie im Shaded Modus. Die resultierende Surface lässt sich langsamer kopieren als bei Solid oder Shaded. Zu benutzen, wenn man hohe Qualität haben will und der Text sich nicht zu oft ändert.

[[Bild:TTF blended.png|framed|center]]

== Anwendung in OpenGL ==
Der Modus "Blended" liefert direkt die passende Textur, um eine schöne Schrift zu erzeugen.

<pascal>
var surface : PSDL_Surface;
tex : GLUint;
begin
surface :=TTF_RenderText_Blended(font,'Fischer''s Frase fischt frische Forellen', color);
//lädt die Daten aus der Surface in den Speicher:
tex :=SDL_GL_LoadTexture(surface);
</pascal>

=== Zeichnen per Alphatest ===
Doch wie zeichnet man die Schrift den jetzt?
Ich habe es bisher immer wie bei Sascha's [[Tutorial_Bomberman2#Texturenfonts|BombermanFontUnit]] gemacht:
<pascal>
glEnable(GL_ALPHA_TEST);
glAlphaFunc(GL_GREATER, 0.1);
//Zeichnen der Textur
glDisable(GL_ALPHA_TEST);
</pascal>

Das Resultat sieht dann so aus:
[[Bild:TTF Alpha.png|thumb|center|Anklicken für grosse Darstellung]]

Im Prinzip also wie [[TTF_RenderText_Solid]], was auch klar ist, wenn man sich anschaut was der Alphatest genau macht.

=== Zeichnen per Blenden ===
Eine Alternative ist das Blenden:
<pascal>
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
glEnable(GL_BLEND);
//Zeichnen der Textur
glDisable(GL_BLEND);
</pascal>

Ergebnis:
[[Bild:TTF Blending.png|thumb|center|Anklicken für grosse Darstellung]]
Die Schrift wird an den Kanten leicht mit dem Hintergrund vermischt. Dadurch wirkt sie wesentlich ruhiger und lässt sich besser lesen.

=== Hinweis ===
Eine Demo-Anwendung zu SDL_TTF kann man im [[DGLSDK]]-[[SVN]] finden.

== Siehe auch ==
[[TTF_RenderText_Solid]], [[TTF_RenderText_Shaded]], [[TTF_RenderText_Blended]]

[[Kategorie:SDLTTF|Rendermode]]

dglOpenGL.pas

2007-04-09T13:36:19Z

Lossy eX:

{{Hinweis| '''Im Lieferumfang von Delphi ist bereits ein OpenGL Header enthalten. Dieser Header ist allerdings ''veraltet und fehlerhaft''. Unter anderem wurden Befehlsbezeichner nicht korrekt übernommen. ''Es wird daher dringend davon abgeraten diesen Header zu benutzen.'''''}}

=Der DelphiGL-Header=
Für alle die OpenGL unter Delphi nutzen möchten hat die [http://www.delphigl.com DelphiGL Community] einen Header zur Verfügung gestellt.

Der Header enthält alle aktuellen OpenGL-Funktionen sowie alle aktuellen GLU-Funktionen.

Des weiteren sind alle ARB-, EXT-, NV- und ATI- Extensions enthalten sowie einige weitere Extensions von anderen Herstellern (Apple, HP, SGI...)

Als besonderer Service bei den Extensions enthält der Header eine Booleanvariablen für jede Extension die automatisch bei Initialisieren gesetzt wird. Diese Booleanvariable (die den gleichen Namen wie der Abfragestring hat) gibt dann an, ob die Extension verfügbar ist oder nicht. (Man erspart sich damit die Stringauswertung bei [[glGetString]].)

Der Header wird von der DGL-Community gepflegt und auf dem neuesten Stand gehalten. Dadurch wird es den Nutzern des Headers sehr leicht gemacht bei neuen OpenGL Versionen einfach den neuen Header in ihre Programme einzubinden (Man muss nur den alten durch den neuen Header ersetzen). Weiterhin ist es auch möglich den Header unter anderen Pascalplattformen wie z.B. Freepascal zu benutzen.

==Hinweis==
Seit der Headerversion 2.1 unterstützt der reguläre Header kein .NET mehr. Mit dem Entfernen der .NET Unterstützung wurde auch eine Technik entfernt die es dem Header möglich gemacht hat benötigte Methoden dynamisch nachzuladen. Dies Funktioniert jetzt nicht mehr. Ihr müsste also nachdem ihr euren Kontex erstellt habe ihn entweder über ''ActivateRenderingContext'' aktivieren oder aber es muss ''ReadExtensions'' und ''ReadImplementationProperties'' von Hand aufgerufen werden. Solltet ihr Zugriffsverletzungen an Adresse 0x00000000 bekommen wo vorher keine waren. Überprüft das.

==Download==

<div align="center">
'''Hier könnt ihr den aktuellen [http://files.delphigl.com/download/dglOpenGL.zip dglOpenGL.pas Header downloaden].'''

'''Hier könnt ihr den aktuellen [http://files.delphigl.com/download/dglOpenGL_net.zip dglOpenGL.pas Header mit .NET Unterstützung downloaden].'''

''[[Benutzer:Mars|Mars]] hat im DGL-Forum ein '''abgewandelte Form der dglOpenGL.pas''' gepostet, welche auch mit '''Delphi 3''' funktioniert:'' 
[http://www.delphigl.com/forum/viewtopic.php?p=26697#25642 dglOpenGL.pas für Delphi 3]

''Weiterhin existiert eine inoffizielle Version des Headers für C++.''

</div>

glCompileShader

2007-02-12T19:18:31Z

Lossy eX: /* Delphi-Spezifikation */ prcedur statt function

= glCompileShader (glCompileShaderARB)=

== Name ==
'''glCompileShader''' - Kompiliert ein Shaderobjekt.

== Delphi-Spezifikation ==
procedure '''glCompileShader'''(''shaderObj'' : GLHandle);
procedure '''glCompileShaderARB'''(''shaderObj'' : GLHandleARB);

== Parameter ==
<table border=1 rules=all>
<tr>
<td>''shaderObj''</td>
<td>Handle des zu kompilierenden Shaderobjektes.</td>
</tr>
</table>

== Beschreibung ==
'''glCompileShader''' kompiliert den Quellcode der im Shaderobjekt abgelegt ist, wobei der Status der Kompilation als Teil des Objektstatus des Shaderobjektes gespeichert wird. Dieser Wert ist True, wenn der Shader ohne Fehler kompiliert wurde und bereit zur Nutzung ist, und ansonsten False. Er kann mittels [[glGetObjectParameterARB]] und dem Shader sowie ''GL_OBJECT_COMPILE_STATUS'' als Argument abgefragt werden.

Die Kompilierung des Shaders kann aus vielerlei Gründen scheitern, die genauer in den Spezifikationen der OpenGL-Shadersprache aufgelistet sind. Ob die Kompilierung erfolgreich war, kann aus dem Informationslog des Shaderobjektes via [[glGetInfoLogARB]] ermittelt werden.

Seit der OpenGL Version 2.0 ist '''glCompileShader''' im Kern enthalten. Die alte ARB Bezeichnung war '''glCompileShaderARB'''.
 
== Fehlermeldungen ==
'''GL_INVALID_VALUE''' wird generiert wenn der Shader kein gültiges OpenGL-Handle ist.

'''GL_INVALID_OPERATION''' wird generiert wenn der Shader nicht vom Typ ''GL_SHADER_OBJECT'' ist.

'''GL_INVALID_OPERATION''' wird generiert wenn '''glCompileShaderARB''' zwischen einem [[glBegin]] und dem passenden [[glEnd]] aufgerufen wird.

== Zugehörige Wertrückgaben ==
[[glGetInfoLog]] mit dem Argument ''shaderObj''.

[[glGetObjectParameterARB]] mit den Argumenten ''shaderObj'' und ''GL_OBJECT_COMPILE_STATUS''.

== Siehe auch ==
[[glCreateShaderObjectARB]], [[glLinkProgram]], [[glShaderSource]] 
'''Hintergrundwissen :''' [[Shader]] 
[http://developer.3dlabs.com/openGL2/slapi/CompileShaderARB.htm Englische Originalversion] (Copyright 3DLabs Inc.)
[[Kategorie:GL|CompileShader]]
[[Kategorie:SHADER_OBJECTS|CompileShader]]

Farbraum

2006-09-01T07:54:22Z

Lossy eX: Hier ist als Linktext immer etwas ungenau

== Übersicht ==
Farbräume dienen der Darstellung von Farben. Üblicherweise werden alle an Monitoren darstellbaren Farben durch 3 Grundtöne codiert. Durch verschieden starke Abstufungen dieser 3 Grundtöne entsteht der Eindruck von verschiedenen Farben.

== Grundlegende Bildschirmkalibrierung ==
Um die dargestellten Farben an Computermonitoren optimal anzuzeigen, muss der Monitor zuerst kalibriert werden. Für unsere Zwecke soll eine einfache Kalibrierung ausreichen: In professionellem Umfeld kommt es nicht nur auf optimale Farbdarstellung an, sondern auch auf Farbechtheit. Um dies zu erreichen ist nicht ganz billiges Equipment notwendig. Wir wollen uns deshalb auf ein paar Hausmittel beschränken. Tatsächlich sind die meisten Computermonitore derart schlecht eingestellt, daß man bei weitem nicht von guter Farbdarstellung reden kann. Bevor wir also weitermachen, wollen wir diesen Umstand ändern. Zuerst muss der Monitor jedoch warm sein - also mindestens eine Stunde in Betrieb sein, bevor er eingestellt wird.

=== Schwarzpunkt ===
Macht euer Zimmel dunkel. Alle Beleuchtung muss abgestellt werden. Eventuelle Rolläden werden bitte geschlossen. Stellen wir die Helligkeit des Monitors auf das Minimum und betrachten das untere Bild (wenn du nach dem dunkelstellen nichts mehr sehen kannst solltest du den folgenden Teil der Anleitung vorher durchlesen):

[[Bild:Farbräume_Schwarzpunkt.png|center]]

Stelle nun die Helligkeit soweit nach oben, bis das schwarze Bild gerade beginnt heller zu erscheinen. Ist dieser Punkt erreicht, dann stelle die Helligkeit wieder ein kleines Stück zurück, so daß es wieder komplett schwarz ist. Wenn das Bild partout nicht hell werden möchte, dann stelle die Helligkeit auf ein Maß, so daß der Mointor nicht zu hell leuchtet ( ein zu heller Monitor ist sehr unangenehm für die Augen. Wenn ihr beim längeren arbeiten Augenschmerzen oder Tränen in den Augen bekommt, dann stellt die Helligkeit unbedingt weiter zurück. Soviel ist der optimale Schwarzpunkt nicht wert. ). '''Achtung TFT Benutzer:''' Der Helligkeitsverlauf auf TFT Monitoren ist nicht konstant. Ich empfehle deshalb das Bild etwa mittig zu plazieren.

=== Kontrast und Gamma ===
[[Bild:Farbräume_Kontrast.png|center]]

Betrachtet bei den obigen Farbverläufen den von Schwarz nach Weiß. Alle 24 Felder sind gleich groß. Der erste Übergang von Schwarz nach etwas Helligkeit sollte in etwa so stark ausfallen, wie der von Weiß auf die erste Abstufung. Regelt die Kontrasteinstellung eures Monitores solange bis beide Übergänge tatsächlich sichtbar sind und in etwa gleich stark ausfallen. Die anderen Felder sollten sich dann bereits halbwegs angepasst haben: Der Verlauf erscheint linear. Wenns noch nicht ganz passt, könnt ihr am Monitor ( wenn das der Monitor nicht bietet, benutzt die Einstellungsmöglichkeiten eures Grafikkartentreibers ) den Gammawert noch ein wenig korrigieren.

Falls ihr gerne noch etwas mehr Zeit investieren wollt, dann schaut doch mal bei [http://tom.via.de/Fotoseiten/Kalibrierung/kalibrierung.asp Tom Kurpjuweit] oder im [http://de.wikipedia.org/wiki/Gammakorrektur#Gamma-Testgrafik Wikipedia] vorbei. Auf diesen und auf vielen anderen Seiten im Netz wird beschrieben, wie man seinen Monitor einstellen kann - meine Anleitung gehört doch eher zu den primitiven. Falls das Bild des Monitors jetzt eher grau und milchig erscheint, seid ihr wahrscheinlich dem Problem erlegen, daß unsere Augen logarithmische Farbveränderungen bevorzugen und lineare Verläufe eher ungewohnt sind - dann ist es Zeit, sich eine etwas genauere Beschreibung zum Thema Bildschirm-justierung/kalibrierung durchzulesen.

== Physikalische und biologische Grundlagen ==
Physikalisch besteht Licht aus Wellen. Diese haben verschiedene Wellenlaengen und je nach Zusammensetzung entsteht der eine oder der andere Farbeindruck.

[[Bild:Farbräume_Farbspektrum.png|center]]

Das sichtbare Licht hat Wellenlängen zwichen 400nm (Violett) bis 750 nm (Rot). Bei kürzeren Wellenlängen unter 400nm kommen dann Ultra Violette, Röntgen und schließlich Gamma Strahlen. Auf der anderen Seite über 750 nm folgen Infrarot, Mikrowellen, Funkempfang (LW, MW, UKW, ...), usw. Auf dem Monitor lassen sich nicht alle Reinfarben darstellen, seht das obige Bild also eher als Eindruck statt als "so siehts also aus".

Da unser Auge nur 3 Grundfarben unterscheiden kann (manche Menschen können sogar 4 Farben unterscheiden, wieder andere dagegen nur 2.), kann man verschiedene Farbeindrücke nicht nur durch verschiedene Wellenlängen erzeugen, sondern auch durch das Mischen und Verlagern der Intensitäten einer Reihe von Grundfarben. So wird am Monitor bekanntlich (additiv) mit Rot, Grün und Blau, auf Printmedien üblicherweise (subtraktiv) mit Cyan, Gelb, Magenta und Schwarz gemischt. Man kann so zwar nicht jede sichtbare Farbe mischen, aber doch so viele, daß ein guter Farbeindruck entsteht.

== Verschiedene Farbräume ==
=== RGB ===
Der Rot, Grün, Blau Farbraum ist der Standardfarbraum für Computer und viele andere Bildschirmgeräte. Damit Farben aus anderen Farbräumen auf einem solchen Gerät dargestellt werden können, müssen sie immer zuerst auf diesen Farbraum umgerechnet werden. Er ist neben CMY einer der am wenigsten anschaulichen Farbräume. Farben lassen sich darin nur sehr schlecht identifizieren, sinnvolle Farbmanipulationen sind kaum möglich. Der Vorteil ist jedoch, daß die 3 Grundfarben etwa denen entsprechen, die auch auf unserer Netzhaut am besten erkannt werden - die Folge: höchst brilliante Farben, die einen großen Teil aller sichtbaren Farben abdecken. Den Farbraum kann man sich als dreidimensionalen Würfel am Nullpunkt vorstellen:

[[Bild:Farbräume_RGB.png|center]]

Ausgehend vom Schwarz kann man nach rechts (Rot), nach oben (Grün) oder nach vorne (Blau) laufen und erhält immer hellere Farben. Schließlich gelangt man zum Weiß. Dazu gibt es auch eine weitere Veranschaulichung:

[[Bild:Farbräume_RGB_additiv.png|center]]

=== CMY ===
Der Cyan, Magenta, Gelb Farbraum ist dem RGB Farbraum sehr ähnlich. Allerdings ist er für Printmedien konzipiert. Ist keine Farbe aufgetragen, so erhält man den Hintergrund - meist ein weißes Blatt Papier. Je mehr man von einer Farbe aufträgt, desto weniger scheinen die anderen Farben durch - trägt man also alle Farben auf, bleibt vom ursprünglichen Weiß nichts über und man erhält Schwarz. Da jedoch der Hintergrund im Allgemeinen nicht leuchtet, können Farben nie derart hell erscheinen, wie im RGB Farbraum - man möge dies bei Druck-Anwendungen beachten:

[[Bild:Farbräume_CYM.png|center]]

[[Bild:Farbräume_CYM_subtraktiv.png|center]]

Zum Umrechnen von RGB in CMY ist nicht viel nötig:
R = 1-C
G = 1-M
B = 1-Y
Und umgekehrt:
C = 1 - R
M = 1 - G
Y = 1 - B

=== CMYK ===
Der CMYK Farbraum entspricht im wesentlichen dem CMY Farbraum, mit dem Unterschied, daß zusätzlich Schwarz zum Beimischen zur Verfügung steht. Dies kann beim Drucken von sehr dunklen Tönen hilfreich sein und spart ausserdem die teure Farbe. In manchen Fällen ist es sogar unumgänglich mit Schwarz zu drucken, wenn sich durch die anderen Druckfarben kein richtiges Schwarz erzeugen lässt (was häufig der Fall ist, u.a. auch bei den meisten Tintendruckern).

Umrechnen CMYK nach CMY:
CMY.C = C * ( 1 - K ) + K
CMY.M = M * ( 1 - K ) + K
CMY.Y = Y * ( 1 - K ) + K

Umrechnen CMY nach CMYK
CMYK.K = min(C,M,Y);
if ( CMYK.K == 1 ) {
CMYK.C = 0;
CMYK.M = 0;
CMYK.Y = 0;
} else {
CMYK.C = (C-CMYK.K)/(1-CMYK.K);
CMYK.M = (M-CMYK.K)/(1-CMYK.K);
CMYK.Y = (Y-CMYK.K)/(1-CMYK.K);
}

=== HSV ===
Der Hue, Saturation, Value (Farbton, Sättigung, Helligkeit) ist ein Farbraum, der sehr häufig im Einsatz ist. Da der Farbton als solches an einem Kanal zu identifizieren ist, werden viele Bildoperationen, die mit Farbe zu tun haben, in eben diesem Farbraum berechnet. Eine bildliche Vorstellung dieses Farbraums ist sehr viel einfacher, als die des RGB Farbraums. Wie also kann man sich ihn vorzustellen?

Eine gute Möglichket ist als Zylinder. Die Unterseite ist schwarz. Bewegt man sich von der Mitte der Unterseite auf die gegenüberliegende Seite zu, wird es heller. Inmitten der hellen Seite ist Weiß. Geht man von dort nach aussen, erhöht sich die Farbsättigung. Geht man dann auf dem Kreis spazieren, bleibt Helligkeit und Sättigung konstant, während sich die Farbe ändert. Dieses Prinzip wird bei vielen Farbauswahldialogen angewendet (Im Beispiel: Paint.NET) :

[[Bild:Farbräume_HSV_auswahl1.png|center]]

Der Kreis stellt die farbige Oberseite des Zylinders dar. Von der Mitte nach Aussen also die Sättigung, den Umfang entlang die Farbe. Der Balken beschreibt die Helligkeit. Sehr beliebt ist auch die aufgefaltete Variante (MS-Windows Standard Farbauswahl Dialog):

[[Bild:Farbräume_HSV_auswahl2.png|center]]

Im quadratischen Feld ist von Links nach Rechts die Farbe, von Unten nach Oben die Sättigung aufgetragen. Der Balken gibt wieder die Helligkeit an.

Es existieren noch viele verschiedene Varianten, die alle mehr oder weniger identisch funktionieren. Wir wollen es bei diesen zwei Beispielen belassen.

Die Farbreihenfolge wird gewöhnlich definiert als Rot, Magenta, Blau, Cyan, Grün, Gelb, Rot. Zwischen den Vollfarben wird linear interpoliert, was zu folgenden Umrechnungen führt:
<cpp>
// Based on C Code in "Computer Graphics -- Principles and Practice,"
// Foley et al, 1996, p. 593.
public static RGB HSVToRGB(double h, double s, double v)
{
double f, hTemp, p,q,t;
int i;
RGB Result = new RGB();
if (s == 0) {
//Achromatic
Result.R = v;
Result.G = v;
Result.B = v;
return Result;
}
if (h < 0)
h = Math.PI * 2 - h;

if (h > 2 * Math.PI)
h = h - Math.Truncate(1.0 / (Math.PI * 2) *h)* (Math.PI * 2);

hTemp = h / (2*Math.PI / 6);
i = (int) Math.Truncate(hTemp); // largest integer <= h
f = hTemp - i; // fractional part of h

p = v * (1.0 - s);
q = v * (1.0 - (s * f));
t = v * (1.0 - (s * (1.0 - f)));

switch (i) {
case 0: { Result.R = v; Result.G = t; Result.B = p; break; }
case 1: { Result.R = q; Result.G = v; Result.B = p; break; }
case 2: { Result.R = p; Result.G = v; Result.B = t; break; }
case 3: { Result.R = p; Result.G = q; Result.B = v; break; }
case 4: { Result.R = t; Result.G = p; Result.B = v; break; }
case 5: { Result.R = v; Result.G = p; Result.B = q; break; }
}
return Result;
}

// Based on C Code in "Computer Graphics -- Principles and Practice,"
// Foley et al, 1996, p. 594.
public static HSV RGBToHSV(double r, double g, double b)
{
HSV result = new HSV();
double delta, min;

min = Math.Min(r, Math.Min(g, b));
result.v = Math.Max(r, Math.Max(g, b));
delta = result.v - min;

// Calculate saturation: saturation is 0 if r, g and b are all 0
if (result.v == 0.0)
result.s = 0;
else
result.s = delta / result.v;

if (result.s == 0)
result.h = 0; //Achromatic
else
{
if (r == result.v)
{ //winkel zw. gelb/magenta
result.h = (g - b) / delta * (2 * Math.PI / 6.0);
}
else if (g == result.v)
{ //zwischen cyan und gelb
result.h = (2 + (b - r) / delta) * (2 * Math.PI / 6.0);
}
else if (b == result.v)
{// ...
result.h = (4 + (r - g) / delta) * (2 * Math.PI / 6.0);
}
if (result.h < 0)
result.h = result.h + 2 * Math.PI;
}
return result;
}
</cpp>

=== HSL ===
Der Hue Saturation Lightness Farbraum ist dem HSV Farbraum sehr ähnlich. Die Definition des Farbtons (Hue) ist identisch, lässt sich also auf die gleiche Weise berechnen. Die anderen Werte berechnen sich aus den RGB Werten wie folgt:
MAX = max (R,G,B);
MIN = min (R,G,B);

L = (1.0/2.0) * (MAX + MIN);
if (MIN == MAX)
{
S = 0
} else if (L <= 1.0/2.0) {
S = (MAX - MIN) / (2.0*L)
} else {
// entspr. Fall: L > 1.0/2.0
S = (MAX - MIN) / (2.0-2.0*L)
}

Man stellt sich den HSV Farbraum gerne als Doppelkonus vor. Die obere Spitze ist weiß, die untere schwarz. Am Rand des Bauches befinden sich die Vollfarben, die zur Mitte hin an Sättigung verlieren (Bild: Wikipedia [EN]):

[[Bild:Farbräume_Color_Cones.png|center]]

=== LAB ===
Der LAB Farbraum ist einer an das menschliche Sehen angepasster Farbraum. Er umfasst alle vom Auge unterscheidbaren Farben und ein bischen mehr. Er dient dazu, Farbechtheit zu garantieren, was wichtig ist, wenn man z.B. am Bildschirm Bilder bearbeitet und diese am Ende drucken oder auf Fotopapier auslasern lassen möchte, so daß die Vorlage am Monitor dem entspricht, was auf dem Papier landen wird. Er dient dabei nur als Umrechnungsfarbraum, wobei auf die spezifischen Eigenschaften des jeweilig genutzen Gerätes geachtet werden muss.

== Farbraumspaß ==
Wir wollen uns hier ein wenig mit den Möglichkeiten des HSV Farbraumes vertraut machen und einige Spielereien ausprobieren.
=== Vergrauen ===
Im HSV Farbraum kann man ein Bild sehr einfach in ein Graustufenbild umwandeln, indem man die Sättigung auf 0 stellt:

[[Bild:Farbräume_Rothsee_farbig.png|center]]
[[Bild:Farbräume_Rothsee_grau.png|center]]

Wenn einem reines S/W zu langweilig ist, kann man auch ein feste Sättigung und Farbe vorgeben, so daß das Bild eingefärbt wird ( S/W-Foto-Material verändert häufig mit dem Alter ein wenig seine Farbe oder ist von vornherein leicht farbig ). Wer Spaß an dieser Art der Bildbearbeitung findet, kann auch noch die Helligkeit anpassen - Schwarzweißfilme sind nach Wellenlängen unterschiedlich empfindlich. Blau wird auf dem positiv häufig heller wiedergegeben als grün, welches wiederum heller als rot erscheint. Viel Spaß beim ausprobieren.

[[Bild:Farbräume_Rothsee_blackwhitestyle.png|center]]

=== Farbkurven ===
Wer sich einmal mit einem Bildbearbeitungsprogramm auseinandergesetzt hat, wird sie kennen, die Dialoge zum Verändern der Farbkurven. Die Kurven stellen eine Verschiebungsfunktion dar: Hat man z.B. ein Farbkurve für den roten Farbkanal festgelegt, so beschreibt die Farbkurve f an einer Stelle i den Wert, den ein Punkte im roten Farbkanal hat, wenn er vorher den Wert i hatte, also:
Punkt.rot = f(Punkt.rot);
im Bild: GIMP:
[[Bild:Farbräume_GIMPColorcurvesdialog.png|center]]
Diese Idee wollen wir uns zu Eigen machen - so ist es im HSV Farbraum nur zu konsequent, nicht Rot/Grün/Blau, bzw. Cyan/Magenta/Gelb sondern die Hue, Saturation und Value Werte zu manipulieren. Und die Sache ein wenig auf die Spitze zu treiben, wollen wir uns nicht nur mit Hue/Hue und den 2 anderen Kurven beschäftigen, sondern auch mit gemischten, bei denen sich anhand der Farbe die Helligkeit oder Sättigung ändert. Vieles ist hier denkbar.

Um es realisieren zu können, benötigt man zuerst einmal eine eigene Dialogbox, die das Bearbeiten von (Farb-)Kurven zulässt. Im wesentlichen dürfte das niemanden hier überfordern - ich empfehle folgende Szenerie: Die Kurve wird mithilfe von Spline-Interpolation erzeugt. Die Menge der Stützstellen ist im wesentlichen beliebig, für einige Kurven ist es jedoch wichtig, nicht nur natürliche, sondern auch periodische Kurven erzeugen zu können. Genauere Informationen hierzu finden sich in den Literaturangaben.

Die einfachste Art der Kurven ist wie gesagt die, die sich selber beeinflussen. So lassen sich leicht Farben durch andere Farben tauschen, ohne den Rest der Farben zu beeinflussen. Man kann natürlich auch bestimmte Sättigungen hervorheben (also Sättigung/Sättigung statt bei Farben Hue/Hue) oder ähnliches. Als Beispiel wird der Hue-Bereich von Gelb in den von Rot verschoben. Durch feine Abstimmung lässt sich erreichen, daß andere Farben sich dabei nicht verändern (Diesen Effekt kann man noch leicht in Photoshop erreichen, man muss jedoch für jede Farbe getrennt vorgehen, falls man verschiedene Farben verändern möchte: Image/Adjustmennts/Hue-Saturations . Wir können dagegen leicht mehrere Farben auf einmal austauschen.).

[[Bild:Farbräume_Hue_Hue_mapping.png|center]]

Als Alternative noch eine Sättigung/Sättigung Variante des obigen Bildes. Links wurde die 20. Wurzel aus der Sättigung gezogen, rechts wurde die Sättigung zur 4. Potenz erhoben (dies entspricht einer Erniedrigung bzw. Erhöhung des Sättigungkontrastes). Die einstellbaren Kurven lassen sich dazu natürlich genauso benutzen, aber so sparen wir uns ein paar Bilder ;-)

[[Bild:Farbräume_Sat_Sat_mapping.png|center]]

Nun wollen wir einmal eine Value/Hue Variante betrachten. Ziel ist es, ein Pixel anhand seines Value den Hue weiterzudrehen. Man trägt im Kurvendialog wie folgt an: In Y-Richtung variiert die Hue, in X-Richtung ist Value von 0 bis 1 angetragen. Zu einer bestimmten Value soll also der Hue um einen bestimmten Winkel weitergedreht werden - vorwärts und rückwärtsdrehen sollte möglich sein. Rechnen könnte man dann:

Pixel.Hue = Pixel.Hue + Kurve(Pixel.Value);

Da Pixel.Hue dadurch auch negative oder zu große Werte annehmen kann, sollte man sie wieder auf den Berech 0 bis 2*Pi zurückrechnen.

[[Bild:Farbräume_Val_Hue_mapping.png|center]]

Im obigen Bild ist die zugrundeliegende Kurve die [http://de.wikipedia.org/wiki/Glockenkurve Gaussche Glockenkurve] mit sigma = 0.29, mu = 0.9, d.h. also, daß bei niedrigen value Werten im wesentlichen keine Veränderung des Hue passiert. Je heller die Szene jedoch wird, desto stärker verschiebt sich der Farbton. Da die Lichtquelle im Hintergrund des Fotos ist, verändern sich die Farben stärker, je weiter hinten sich die Luftballons befinden.

Es lassen sich noch einige weitere Varianten vorstellen, als die, die hier gezeigt wurden. So könnte man anhand einer Hue/Sat Kurve bestimmte Farben vergrauen lassen und andere hervorheben - der Effekt ist sicherlich nicht gänzlich unbekannt. In der Fotografie wird gerne entsprechend manipuliert: Man stelle sich ein Mädchen vor, das eine rote Rose hält. Alle Farben sind grau, nur die Blüte der Rose ist rot - mit Hue/Sat Kurven ist das wirklich sehr leicht zu erreichen.

== Literatur ==
* [http://www.efg2.com/Lab/Graphics/Colors/index.html Earl F. Glynn II: efg's Palettes and Colors Lab]
* [http://www.efg2.com/Lab/Library/Color/index.html Earl F. Glynn II: efg's Color Reference Library]
* [http://www.midnightkite.com/color.html Dan Bruton: Color Science]
* [http://en.wikipedia.org/wiki/Color_model Englische Wikipedia: Color Models. Viele informationen, Veranschaulichungen, Umrechnungsformeln]
* [http://www.adhocconference.com/cgi-bin/blosxom.cgi/PastShows/MacHack16/2001_papers.html Darrin Cardani: Adventures in HSV Space (als PDF)]
* [http://de.wikipedia.org/wiki/Spline-Interpolation Wikipedia: Spline interpolation]
* Bronstein, Semendjajew, Musiol, Mühlig: Taschenbuch der Mathematik. 5 Auflage. S.955: 19.7.1 Kubische Splines
* [http://www.arndt-bruenner.de/mathe/scripts/kubspline.htm Arndt Brünner: Kubische Splines]

Link

2006-03-16T10:35:14Z

Lossy eX: /* OpenGL */

= Links =
Hier finden Sie eine Übersicht von Links.

*Weitere Navigations Links findet ihr unter [[DGL Wiki:Portal]]
*Links zu Tools oder Programmen finden Sie unter [[Tool]]s

== Hardwareinfos ==
<div align="center">
{|{{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://delphi3d.net/hardware/listreports.php OpenGL Hardware Registry - Hardwareübersicht]
|{{Englisch}}
|Eine Datenbank aller Grafikkarten die in der Harware Registry vorhanden sind. Die einzelnen Artikel enthalten Infos darüber, welche Extensions von der Grafikkarte unterstützt werden.
|-
|[http://delphi3d.net/hardware/allexts.php OpenGL Hardware Registry - Extensionübersicht]
|{{Englisch}}
|Eine Datenbank aller Extensions die in der Harware Registry vorhanden sind. Die einzelnen Artikel enthalten Infos darüber, welche Grafikkarten die entsprechende Extension unterstützen.
|-
|}
</div>
 

== Tutorials ==

=== OpenGL ===
<div align="center">
{|{{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
||[[Tutorial|DGL Wiki - Tutorial]]
|{{Deutsch}}
|DelphiGL.com ist Betreiber dieses Wikis und stellt eine Vielzahl Tutorials mit Schwehrpunkt OpenGL zur Verfügung.
Neben Tutorials für Einsteiger und OpenGL Anfänger gibt es auch fortgeschrittene Themen wie Shader oder Partikelsysteme.Sprache der Wahl ist hier Delphi.
|-
|[http://www.joachimrohde.com/cms/xoops/modules/articles/index.php?cat_id=1 joachimrohde.com]
|{{Deutsch}}
|Auf dieser Seite findet ihr deutsche Übersetzungen der bekannten NeHe Tutorials. Sprache der Wahl ist hier C++.
|-
|[http://www.informatik.fh-muenchen.de/~schieder/opengl-ss99/index.html FH Muenchen]
|{{Deutsch}}
| Eine Art riesiges OpenGL Tutorial von mehren Autoren
|-
|[http://www.informatik.fh-muenchen.de/~schieder/graphik-01-02/index.html FH Muenchen]
|{{Deutsch}}
| Begleit Script von Prof. Dr. R. Schiedermeier ueber Computergrafik.
|-
|[http://www.cg.tuwien.ac.at/studentwork/VRSem96/OpenGL/ Technische Universität Wien]
|{{Deutsch}}
|
|-
|[http://www.husser.de/index.php?site=content&action=overview&id=2 Husser.de]
|{{Deutsch}}
|
|-
|[http://www.dcw-group.net/index.php?menue=cod&site=tuts/coding/oglkurs/index dcw-group.net]
|{{Deutsch}}
|Hier findet ihr einige OpenGL Tutorials die primär an OpenGL-Anfänger gerichtet sind. Der Autor dieser Artikel ist auch im DelphiGL Forum anzutreffen. Sprache der Wahl ist hier Delphi.
|-
|[http://nehe.gamedev.net/ Nehe]
|{{Englisch}}
|Die berühmt berüchtigten NeHe Tutorials sind eine umfangreiche Sammlung an Tutorials zum Thema OpenGL. Von Anfängertutorials bis hin zu komplexen Effekten wird alles behandelt. Sprache der Wahl ist hier C++. (Eine Übersetzung der NeHe Tutorials findet ihr bei Joachim Rhode (siehe oben). )
|-
|[http://www.sulaco.co.za/tut.htm sulaco.co.za]
|{{Englisch}}
|
|-
|[http://people.fh-landshut.de/~gschied/opengl/ FH Landshut]
|{{Deutsch}}
|
|-
|}
</div>
 

=== Textur Erstellung ===
<div align="center">
{|{{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://3d.diehlsworld.de/textures/index.htm 3d.diehlsworld.de]
|{{Deutsch}}
|Auf dieser Seite findet ihr kurze aber inhaltlich reiche Tutorials zu der Frage "Wie erstelle ich XXXXX-Texturen". Dabei reicht die Palette von Untergrundtexturen wie Gras, Sand , Fels und Wasser (und Kombinationen dieser) bis hin zu Blitzen und Partikeln. Als Programm wird hier Photoshop verwendet.
|-
|[http://www.gimps.de/gimp/textur-muster/ gimps.de]
|{{Deutsch}}
|Schritt für Schritt Anleitungen wie man mit Gimp verschiedene Texturen erstellt.
|-
|[http://www.frakes.de/gimp-tutorials/texturen/index.html frakes.de]
|{{Deutsch}}
|Gimptutorials zum erstellen verschiedene Texturen.
|}
</div>
 

=== Blender ===
<div align="center">
{|{{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://blendpolis.serverpool.org/f/viewtopic.php?t=5786 Blendpolis]
|{{Deutsch}}
| Ein Thread im Forum von [http://blendpolis.serverpool.org Blendpolis] in dem '''sehr''' viele Tutorials aufgelistet sind
|-
|[http://blendpolis.serverpool.org/f/article_cat.php?fldAuto=7 Blendpolis]
|{{Deutsch}}
| Eigentliche Tutorial Seite von [http://blendpolis.serverpool.org Blendpolis] die Auswahl ist hier aber nicht so groß
|-
|[http://www.trcoding.de/informatik/blender/index.html trcoding.de]
|{{Deutsch}}
| Auf dieser Seite findet ihr ein großes Blender Turorial, welches an Blender Anfänger gerichtet ist
|-
|[http://blender3d.org/cms/Getting_Started.246.0.html blender3d.org]
|{{Englisch}}
| Auch die Heimatseite von Blender bietet viele Tutorials unter anderm auch Video Tuorials
|}
</div>
 

== OpenGL Funktionen ==

=== GL ===
<div align="center">
{|{{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[[:Kategorie:GL|DGL Wiki - Kategorie GL]]
|{{Deutsch}}
| Wiki-Kategorie die alle übersetzten OpenGL Befehle enthält.
|-
|[http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/ OpenGL.org - Orginal Spezifkationen]
|{{Englisch}}
|Die Orginalspezifikationen der OpenGL 1.0 und OpenGL 1.1 Befehle. (Diese HTML-Dokumente sind nicht Copy&Paste freundlich, da sie vermutlich automatisch aus vorhandenen Dateien (Postscript) erzeugt wurden.)
|-
|[http://developer.3dlabs.com/documents/glmanpage_index.htm 3dLabs]
|{{Englisch}}
|Die Orginalspezifikationen der OpenGL 1.0 und OpenGL 1.1 Befehle.
|-
|[http://www.mevis.de/~uwe/opengl/opengl.html mevis.de]
|{{Englisch}}
|Sammlung von Englischsprachigen Spezifikationen für GL(bis Version 1.1), GLX und GLU Funktionen.
|-
|[http://msdn.microsoft.com/library/default.asp?url=/library/en-us/opengl/glfunc01_4f03.asp MSDN von Microsoft]
|{{Englisch}}
|OpenGL Dokumentation in der MSDN. Die Erklärung der MSDN sind meist keine reinen Kopien der Orginalspezifikationen, sondern enthalten hin und wieder auch zusätzliche Informationen, oder formulieren Texte auf verständlichere Art und Weise.
|-
|}
</div>
 

=== GLU ===
<div align="center">
{|{{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[[:Kategorie:GLU|DGL Wiki - Kategorie GLU]]
|{{Deutsch}}
| Wiki-Kategorie die alle übersetzten GLU Befehle enthält.
|-
|[http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/glu/ OpenGL.org - Orginal Spezifkationen]
|{{Englisch}}
|Orginalspezifikationen für die GLU Befehle. (Diese HTML-Dokumente sind nicht Copy&Paste freundlich, da sie vermutlich automatisch aus vorhandenen Dateien (Postscript) erzeugt wurden.)
|-
|[http://www.mevis.de/~uwe/opengl/opengl.html mevis.de]
|{{Englisch}}
|Sammlung von englischsprachigen Spezifikationen für GL(bis Version 1.1), GLX und GLU Funktionen.
|-
|[http://msdn.microsoft.com/library/default.asp?url=/library/en-us/opengl/glufnc01_0e43.asp MSDN von Microsoft]
|{{Englisch}}
|GLU Dokumentation in der MSDN. Die Erklärung der MSDN sind meist keine reinen Kopien der Orginalspezifikationen, sondern enthalten hin und wieder auch zusätzliche Informationen, oder formulieren Texte auf verständlichere Art und Weise.
|-
|}
</div>
 

=== GLX ===
<div align="center">
{|{{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[[:Kategorie:GLX|DGL Wiki - Kategorie GLX]]
|{{Deutsch}}
| Wiki-Kategorie die alle übersetzten GLX Befehle enthält.
|-
|[http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/glx/ OpenGL.org - Orginal Spezifkationen]
|{{Englisch}}
|Orgninalspezifikationen der GLX Befehle bei OpenGL.org.
|-
|[http://www.mevis.de/~uwe/opengl/opengl.html mevis.de]
|{{Englisch}}
|Sammlung von Englischsprachigen Spezifikationen für GL(bis Version 1.1), GLX und GLU Funktionen.
|-
|}
</div>
 

=== WGL ===
<div align="center">
{|{{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[[:Kategorie:WGL|DGL Wiki - Kategorie WGL]]
|{{Deutsch}}
|Wiki-Kategorie die alle übersetzten WGL Befehle enthält.
|-
|[http://developer.3dlabs.com/documents/wglmanpage_index.htm 3dLabs]
|{{Englisch}}
|Sammlung einiger WGL Befehlsspezifikationen.
|-
|}
</div>
 

=== GLUT ===
<div align="center">
{|{{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://freeglut.sourceforge.net/docs/api.php The freeglut Projekt]
|{{Englisch}}
|Englischsprachige Dokumentation zum OpenGL Utility Toolkit kurz GLUT.
|-
|}
</div>
 

=== SDL ===
<div align="center">
{|{{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[[:Kategorie:SDL|DGL Wiki - Kategorie SDL]]
|{{Deutsch}}
|Übersicht aller auf die SDL bezogenen Artikel hier im Wiki. Darunter befinden sich eine Vielzahl von Übersetzungen der SDL Befehlspezifikationen. Diese können auch in der [[SDL-Funktionsübersicht]] gefunden werden.
|-
|[http://www.libsdl.org/cgi/docwiki.cgi/SDL_20API libsdl.org]
|{{Englisch}}
|Das Dokumentationswiki von libSDL.org enthält die komplette Dokumenation zur SDL in englischer Sprache.
|-
|-
|[http://www.fp.sdl.de.vu/ fp.sdl.de.vu]
|{{Englisch}}
| Eine Webseite die speziell Informationen über die Programmierung von SDL unter Freepascal zur Verfügung stellt.
|-
|}
</div>
 

== FAQs ==
<div align="center">
{|{{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[[FAQ| DGL Wiki - FAQ]]
|{{Deutsch}}
|Ein FAQ (Frequently Asked Questions = Häufig gestellte Fragen) zu DelphiGL.com und dem DGL Wiki.
|-
|[http://www.3dsource.de/faq/index.htm 3dsource.de]
|{{Deutsch}}
|Ein FAQ zu Fragen rund um OpenGL.
|-
|}
</div>
 

== Effekte und Techniken mit OpenGL ==

===Glow===
<div align="center">
{|{{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://www.gamasutra.com/features/20040526/james_01.shtml Gamasutra]
|{{Englisch}}
|Beschreibt, wie man mit Hilfe von Shader(hier DirectX Shader) den Gloweffekt in Realtime umsetzt. Dabei wird erst die Technik dahinter erklährt, und dann wie man sie Schritt für Schritt umsetzt.
|-
|[http://collective.valve-erc.com/index.php?go=tron1 valve-erc.com]
|{{Englisch}}
|Schritt für Schritt Anleitung, wie man mit Hilfe von Cg in OpenGL den Glow Effekt realisieren kann
|-
|}
</div>
 

===HDR===
<div align="center">
{|{{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://www.blochi.com/HDRI/ blochi.com]
|{{Deutsch}}
|Diplomarbeit, beschreibt umfangreich, was überhaupt HDR ist, geht darauf ein, wie man HDR Bilder mit verschiedenen Tools erzeugt, und zeigt Beispiele auf, wie HDR im CG Bereich Anwendung findet. Hier wird jedoch keine mathematische Theorie dazu vermittelt.
|-
|[http://www.gamedev.net/columns/hardcore/hdrrendering/ gamedev.net]
|{{Englisch}}
|Hier wird sehr kurz eingeleitet, was HDR Rendering überhaupt ist, dann wird der Aufbau des *.hdr Formats erläutert, und dann geht es schon von 0 auf 100 zum Programmieren. Erklährungen gibt es kaum, dafür werden fertige Shader(für DirectX) geboten.
|-
|[http://www.gamedev.net/reference/articles/article2208.asp gamedev.net]
|{{Englisch}}
|Beschreibt auch nur etwas kurz das HDR Verfahren, jedoch mit mehr mathematischen Hintergrund in Sachen Tonemapping. Beispielcode für Tonemapping in C++ liegt bei.
|-
|}
</div>
 

===BSP Bäume===
<div align="center">
{|{{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://www.3dtechdev.com/tutorials/leafbsp/3dbsptrees.html 3dtechdev.com]
|{{Englisch}}
|Das beste Dokument überhaupt, für allem die selber BSP Bäume compilieren möchte. Ist belegt mit sehr viel Grafik. Erst beginnt er das Prinzip allgemein zum umschreiben, dann wird alles genau erläutert, und mit verständlichen Pseudocode untermalt.
|-
|[http://www.3dtechdev.com/tutorials/illegalgeometry/illegalgeometrytut.html 3dtechdev.com]
|{{Englisch}}
|Nicht ganz so gut geworden, wie sein erstes Tutorial, aber erklährt auch sehr gut, wie man illegale Geometrie aufspürt und beseitigt. Wieder mit Grafiken und Pseudocodes verständlich belegt. Hiermit kann man seinem Map-Compiler den letzten Schliff verleien.
|-
|[http://www.gamedev.net/reference/articles/article981.asp Gamedev]
|{{Englisch}}
|Von Michael Abrash, dürfte der ''Erfinder'' von Quake sein. Naja, meine Englischkenntnisse reichen hier nicht ganz aus, um den Text zu verstehen. Ist etwas umständlich geschrieben. Dafür mit Grafiken unterlegt.
|-
|[http://www.zfx-online.de/Tutorials.php?ID=11 Part 1 - Allgemein]
|{{Deutsch}}
|Einzigste deutsche Referenz zu BSP Bäumen, dafür Daumen hoch. Ist aber nicht das Wahre: schlechter C Code, und ich hatte auch nicht den Einduck, das er die Theorie zu diesem Thema bis in die Tiefe verstanden hat(oder er wollte es nicht zu akademisch Erklähren oO). Aber ein guter Einstieg in dieses Thema.
|-
|[http://www.zfx-online.de/Tutorials.php?ID=13 Part 2 - Kollision und PVS]
|{{Deutsch}}
|-
|[http://www.cs.uwec.edu/~stevende/cs455/programs/GameTutorials%20-%20Quake%203%20BSP%20Format.htm Quake3 *.bsp Format]
|{{Englisch}}
|Die beste Dokumentation für das BSP Format, die ich gefunden habe, besser als den Quake3 Sourcecode zu durchforsten. Leider etwas magere Eklährung zu wichtigen Themen wie Patches(Curved Surfaces). Ich pers. hatte jetzt 1 1/2 Wochen gebraucht, um das *.bsp Format vollständig zu verstehen. Ist aber anscheinend die beste Format Dokumentation im Netz.
|-
|[http://www.flipcode.com/articles/article_q2bsp.shtml Quake2 *.bsp Format]
|{{Englisch}}
|Kann auch nur soviel sagen, wie beim Link zuvor. Es fehlen hier auch zum Teil Informationen. Man muss halt viel ausprobieren, und sich den Quake 2 Source zu Herzen nehmen, damit man es versteht.
|-
|}
</div>
 

===Himmel & Wolken===
<div align="center">
{|{{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://www.gamedev.net/community/forums/topic.asp?topic_id=86024 Gamedev]
|{{Englisch}}
|Guter Thread mit vielen Anregungen und Links.
|-
|[http://www.gamedev.net/community/forums/topic.asp?topic_id=135654 Gamedev]
|{{Englisch}}
|Hier wird die Diskussion zum obigen Link weitergeführt.
|-
|[http://freespace.virgin.net/hugo.elias/models/m_clouds.htm Plasma]
|{{Englisch}}
|Eine nette Idee um Plasma in Echtzeit zu generieren, und zu verändern. Leider nichts zum Shading.
|-
|[http://nis-lab.is.s.u-tokyo.ac.jp/~nis/cdrom/sig00_cloud.pdf 3D Wolken]
|{{Englisch}}
|Paper über generieren und rendern von 3 dimensionalen Wolken inklusive Schatten und Lichtstrahlen. Ich hab nur den Lichtstahlen-Algorithmus ausprobiert. Saulangsam aber sehr einfach zu implementieren. Einen Blick ist es auf jeden Fall wert.
|-
|[http://www.geocities.com/ngdash/whitepapers/skydomecolor.html Skydome]
|{{Englisch}}
|Wenn man mal schnell gute Farben für seinen Skydome braucht...
|}
</div>
 

===Terrain===
<div align="center">
{|{{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://www.delphi3d.net/articles/viewarticle.php?article=terraintex.htm Delphi3D]
|{{Englisch}}
|Terraintexturierung. Hier hab ich es gelernt. Man sollte nur die Coverage-Faktoren in eine Textur stecken, dann verträgt es sich mit LODing besser.
|-
|[http://www.flipcode.com/articles/article_geomipmaps.shtml FlipCode]
|{{Englisch}}
|Artikel zu Geomipmaping. Zummindest hab ich es hier zum ersten mal gesehen. Und es funzt ganz gut.
|-
|[http://www.vterrain.org Virtual Terrain Project]
|{{Englisch}}
|Eine Seite mit Links und Artikeln zu allem, was etwas mit Terrainrendering zu tun hat.
|-
|}
</div>
 

===Sonstiges===
<div align="center">
{|{{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://freespace.virgin.net/hugo.elias/radiosity/radiosity.htm Radiosity]
|{{Englisch}}
|Erklährt sehr schön die Funktionsweise von Radiosity, liefert Beispielcodes und ist recht gut illustriert.
|-
|[http://legion.gibbering.net/projectx/paper/shadow%20mapping/ Shadowmapping]
|{{Englisch}}
|Beschreibt das Trapezoidal Shadow Mapping - Verfahren für gerichte Lichter.
|-
|[http://www.flipcode.com/articles/article_generatingnames.shtml Namensgenerator]
|{{Englisch}}
|Per Zufallsgenrator Namen erzeugen, und nie wieder kreativ werden müssen.
|-
|[http://www.paulsprojects.net/tutorials/simplebump/simplebump.html Bumpmapping]
|{{Englisch}}
|Bumpmapping auf Lowend-Grakas. Damals war Bumpmapping noch was ganz tolles...
|-
|[http://www.paulsprojects.net/opengl/dpreflect/dpreflect.html Dot Product Reflect]
|{{Englisch}}
|zwar nur ne Demo, aber wenn man schon immer mal mit EMBM das Wasser aus Morrowind nachproggen wollte...
|-
|}
</div>
 

== Beispiele/Demos mit Quelltext ==
<div align="center">
{|{{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://www.delphigl.de DelphiGL.de]
|{{Deutsch}}
| Hier finden sich besonders eindrucksvolle Newton Physik Demos. Meißtens sogar mit Quelltext.
|-
|[http://www.shadow3d.de.vu/ Shadow 3D]
|{{Deutsch}}
| Hier finden sich zwei Demos wie man Quake 3 Modelle lädt und eine glSlang Demo
|-
|[http://www.humus.ca Humus]
|{{Englisch}}
| Diverse eindrucksvolle Demos zu verschiedenen Techniken, häufig mit Quelltext in C
|}
</div>
 

== weitere Links ==
<div align="center">
{|{{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://www.delphigl.com/launcher.php?em=links alte Link Seite]
|{{Deutsch}}
| Die alte Link Seite von DelphiGL.com.(Diese hier ist aktueller)
|-
|[http://www.robsite.de/ robsite.de]
|{{Deutsch}}
| Auf dieser riesigen Seite finden sich auch viele weitere Links über verschiedene Themen der 3D Programmierung.
|-
|[http://www.3dlinks.com/links.cfm?categoryid=3&subcategoryid=21 3dlinks.com]
|{{Englisch}}
| Diese Seite hat es sich zur Hauptaufgabe gemacht Links auf Seiten mit dem Thema 3D zu sammeln.
|
|-
|[http://www.two-kings.de/links.html two-kings.de]
|{{Englisch}}
| Sammlung diverser interessanter Links, vorallem auf Themen im gamedev-Forum verweisend.
|-
|[http://www.delgine.com Delgine.com]
|{{Englisch}}
| Heimat des freien 3D Modellers "DeleD", welcher in Delphi programmiert ist. Ihr findet dort auch Modellpackete, Texturpackete, Plugins und Hilfe bei der Programmierung von Delphi und OpenGL.
|}
</div>

Bilder als Ressourcen

2006-03-13T15:38:12Z

Lossy eX: /* Ressourcen laden */ Code angepasst

==Vorwort==
Eins vorneweg: Da ich noch OpenGL-Frischling bin, sollten die in diesem Artikel beschriebenen Methoden zwar funktionieren, jedoch bin ich fast der Überzeugung, dass sie Speicher- sowie Performancetechnisch eher miserabel sind...

==Einleitung==
Man kann Bilder (und auch jeglichen anderen Daten) beispielsweise in Ressourcen-Dateien packen,
um die .exe möglichst klein zu halten. 
Oder aber man freut sich, wenn man immer alle Grafiken in einer Datei zusammen hat. 
Oder man verwendet Ressourcen-Dateien, damit "net jeder Wald und Wiesendepp mit Paint die Grafiken verunstalten kann" (Zitat Flash)

Warum auch immer man sich für Ressourcen-Dateien entscheiden sollte, die Herangehensweise ist die selbe - nämlich folgende:

==.RES Datei Erstellen...==
Als erstes nehmen wir alle Grafiken, die wir brauchen, und packen sie in eine .res Datei. 
"packen" weckt hier möglicherweise falsche Hoffnungen, denn die Daten werden dadurch nicht komprimiert, sie kommen bloß alle zusammen in eine Datei. 
Um eine solche .res Datei zu erschaffen gibt es mehrere Wege - hier sind zwei:

===einfach und schnell===
Man benutzt das Programm "PE Resource Explorer", mit welchem man sich recht bequem seine Resourcen zusammen klicken kann. (Download: http://www.wilsonc.demon.co.uk/d10resourceeditor.htm)

===selber tippen===
Die andere Möglichkeit ist etwas mehr Arbeit: Also schnappst du dir Notepad oder sonst irgendeinen Editor und erstellst eine Datei mit folgendem Format: 
<Ressourcenbezeichner> <Resourcentyp> <Pfad zur Datei> 
beispielsweise: 
myCharTex BITMAP char.tga 

:'''Ressourcenbezeichner:''' ist der Name, den du der Ressource gibst. Statt einem String kannst du auch ne Zahl hinschreiben, also:
:10 BITMAP holla.bmp
:Muss man selber wissen, ob man lieber mit Strings oder Integers als Bezeichner arbeitet, hat bestimmt beides Vorzüge...

:'''Ressourcentyp:''' Es gibt einige vordefinierte Typen (für Bitmaps, Jpgs, Cursor, Icon, usw)
:Für alle Sachen, die nicht explizit nen eigenen Typ haben gibt es RCDATA
:Das wär dann wohl allgemeine Datenvielfalt, oder so...

:'''Pfad zur Datei:''' ist selbsterklärend denke ich.
:Kann sein, dass man Gänsefüsschen setzen muss, keine Ahnung - testen!

Jetzt hast du im Editor zeilenweise deine Ressourcen angegeben und speicherst das Werk erstmal als Datei mit der Endung ".rc" ab. 
Dann gibt es in deinem Delphi Verzeichnis einen Ordner "bin" und in selbigem eine Datei brcc32.exe - die brauchen wir jetzt. 
Die .rc Datei enthält ja nur die Dateinamen zu den Ressourcen die du haben willst. brcc32.exe nimmt sich diese Datei und packt die darin angegebenen Ressourcen in eine .res Datei. 
Dazu ruft man die brcc32 in der Kommandozeile auf und übergibt als Parameter den Pfad zur .rc Datei 
Ipp Zipp Zapp, fertig ist die .res Datei

Dieser zweite Weg ist zwar unter Umständen mehr Arbeit, aber dafür hat man dann auch n bisschen Hintergrundwissen abbekommen - kann ja nicht schaden.

==...und einbinden==
Soweit so gut, wir haben die Resourcen alle in einer .res Datei und binden diese mit {$R lemon.RES} in unser Programm ein... 
HA! Wenn man die .res Datei in das Hauptprojekt eingebunden hätte, wäre sie beim compilieren mit in die .exe hineinkompiliert worden. 
Weil wir das aber nicht wollen, gehen wir her und erstellen in Delphi ein neues DLL Projekt. 
Den vorgeschriebenen Quelltext ersetzen wir mit: 
<pascal>
library lemon;

{$R lemon.RES}

begin
end.
</pascal>
wobei der Name der Library und "lemon.RES" natürlich auf eure Bedürfnisse angepasst werden sollte. 
Wunderbar, jetzt speichern wir das Projekt, compilieren es und der ein oder andere kann auch "Hosianna" rufen, denn jetzt haben wir eine wunderschöne .dll Datei, die all unsere Resourcen enthält. Und ich denke, jeder gewöhnliche Wald und Wiesen Depp, wird sich denken "Möh? DLL - Wasn datt da? Kann man das essen?? Lass ich mal lieber in Ruhe" 
Hehe, aber wir sind noch nicht am Ziel... wir müssen die Daten ja auch wieder aus der DLL rausbekommen.

==Ressourcen laden==
Zurück in der Hauptanwendung gehen wir folgendermaßen vor: 
Erstmal brauchen wir eine Variable vom Typen Papst ääh, Cardinal. 
Der weisen wir mittels 
<pascal>
var h: cardinal;
h := LoadLibrary('lemon.dll');
</pascal>
die eben erstelle DLL Datei zu. 
Wenn man jetzt in LoadFromRessource oder ähnlichen Funktionen als Parameter eine Instance angeben sollst, ist das unsere Cardinal Variable, die ja auf die DLL zeigt. 
Bei der glBitmap.pas laden wir allerdings immer aus Streams - und zwar so: 
<pascal>
var myStream: TResourceStream
var h: Cardinal;
var foo: TglBitmap2D;

// DLL Laden
h := LoadLibrary('lemon.dll');

// Texturklasse erstellen
foo := TglBitmap2D.Create;

// Stream auf eine Resource erstellen
myStream := TResourceStream.CreateFromID(h, 10, RT_RCDATA);
try
// Bild aus Stream laden
foo.LoadFromStream(myStream);
finally
// Stream in jedem Falle wieder frei geben
myStream.Free;
end;

// OpenGL Textur erstellen
foo.GenTexture;

// DLL Wieder entladen wenn sie nicht mehr gebraucht wird
FreeLibrary(h);
</pascal>
damit würden wir aus der Datei lemon.dll eine RCDATA Resource mit dem Bezeichner 10 laden. 
Wenn man den Ressourcen String-Namen gegeben hat, benutzt man "Create" statt "CreateFromId" und gibt den String an.

==Nachwort==
Sohohohoho, ich hoffe, ich habe alles Erwähneswerte erwähnt und wenn es jemandem hilft, dann bin ich mächtig stolz, auch mal ne Antwort gegeben zu haben, statt immer nur zu Fragen. 
Abgesehen davon hoffe ich, dass ich an dieser Stelle Lossy eX für Geduld und Wissen danken darf :) 
Ciao

[[Benutzer:Doppelreim|Doppelreim]]

[[Kategorie:Anleitung|Bilder in Ressourcen]]

Benutzer:Lossy eX

2006-02-10T12:43:11Z

Lossy eX:

= Steckbrief =

Name: Steffen Xonna

Nick: Lossy eX

Geb.: 1980

Wohnort: Dortmund

Tätigkeit: Softwareentwickler

Homepage: [http://www.dev-center.de/ www.dev-center.de]

= Werdegang =

Bin eigentlich eher sehr zufällig zu den Computern gekommen. Ursprünglich wollte ich RFT-Mechaniker werden. Da wurde mir aber gesagt, dass ich dazu mindest einen Notendurchschnitt von 1.7 brauchte. Na ja. War nie sonderlich der Fleißigste in der Schule. Nicht, dass ich es nicht könnte hatte nur keinen Bock drauf und habe also auch nicht gelernt. Wie dem auch sei. Es musste also was anderes her. So geschehen hatte ich also die Auswahl zwischen einer schulischen Ausbildung zum Informatikassistent oder eine Ausbildung als KFZ-Mechaniker. Also Malochen bis zum Umfallen. Wofür ich mich entschieden habe könnt ihr euch sicherlich denken. Genau. Für den Informatikassistenten.

Es stellte sich dann auch recht schnell herraus, dass ich auf dem Gebiet der Software Entwicklung eine Art Naturtalent bin. Vorher keine Ahnung vom Rechner gehabt, war ich in der Lage Programme zu schreiben als hätte ich nie etwas anderes getan. Ab diesem Zeitpunkt habe ich dann auch nichts anderes mehr getan. Schon wärend meiner Ausbildung hatte ich in C eine kleine DOS Grafikengine für 2D Spiele geschrieben. Also mit allem Drum und Dran. Na ja. Windows 95 sei Danke konnte ich sie als sie recht weit fortgeschritten war dann auch verschrotten. Was will man schon mit DOS Spielen wenn man Windows Spiele haben kann. *argh*

Seit 1999 durfte ich dann auch endlich profesionell Entwickeln. Leider gingen die Firmen immer in regelmäßigen Abständen insolvent auf dass ich nie irgendwo sesshaft wurde. Aber durch die vielen Ansichten habe ich sehr viele unterschiedliche Bereiche kennengelernt und mein Programmierstil hat sich maßgeblich verändert. Ich bin zu einem Verfechter von OOP gewurden. Allerdings bin ich auch sehr gut in der Lage von OOP abstand zu halten wenn es erforderlich ist. In der letzten Firma bin ich dann eher Notgedrungen an OpenGL geraten und seit her nicht wieder von los gekommen. Aber auch wärend dieser Tätigkeit habe ich sehr viele Grafiken mit der GDI programmiert.

All das formt natürlich ein persönliches Interessengebiet und das liegt bei mir voll und ganz im 2D Bereich. Wie der ein oder andere schon mitbekommen haben dürfte. Und sehr sehr gerne auch selber Grafiken irgendwo im Speicher bearbeiten. Sie wie man es bei der [[Glbitmap_loader|glBitmap]] der Fall ist.

Team

2006-02-10T12:05:45Z

Lossy eX: /* DGLOpenGL.pas */

Team

2006-02-10T12:04:37Z

Lossy eX: /* Moderatoren */

Selektion

2006-01-05T18:45:36Z

Lossy eX: /* Hinweis */ Etwas drastischer geschrieben

==Was ist das?==
Die Selektion ist ein bestimmter Rendermodus von '''OpenGL'''. Im Selektionsmodus (der durch [[glRenderMode]] gesetzt wird) werden keine [[Fragment]]e erzeugt und auch keine Änderungen am [[Framebuffer]] durchgeführt. Anstelle dessen werden 4 Werte pro sichtbaren [[Primitive]]n in einen [[glSelectBuffer|Selektions Puffer]] geschrieben. Dieser Puffer muss schon vor dem Aufruf dieser Funktion erstellt worden sein.

Die vier Werte die man pro Primitiven erhält sind:
# Anzahl der Namen auf dem Stack
# Kleinster Z-Wert des getroffenen Objektes
# Größter Z-Wert des getroffenen Objektes
# Name des Objektes

==Wozu brauch ich das?==
Für die Interaktion des Nutzers mit der Szene.

==Wie geht das?==
Durch den Selektionspuffer bekommt man die [[OpenGL Name]]n der Szenen Elemente zurückgeliefert die im Rendermodus GL_RENDER gerendert worden wären. Dies ermöglicht es unter zuhilfenahme von [[gluPickMatrix]] den Bereich um einen Mausklick auszuwerten. Wie das genau funktioniert könnt ihr im Selektionstutorial (siehe Links) nachlesen.

==OpenGL Funktionen==
Folgende Funktionen haben mit der Selektion zu tun:

[[glRenderMode]], [[glSelectBuffer]], [[glLoadName]], [[gluPickMatrix]], [[Picking]]

==Hinweis==
Wärend der Selektion muss die selbe Perspektive ([[gluPerspective]] oder [[glOrtho]]) gesetzt sein wie beim rendern der Ausgabe. Wärend der Selektion darf die Perspektive nicht verändert werden, da das Ergebnis sonst merkwürdig ausfallen würde. Ein setzen des Orthomoduses wärend einer Perspectivenausgabe führt zu eben solchen Problemen. Entweder das Eine oder das Andere.

==Beispiele==

===Selektion in 2D (glOrtho)===
Im OnShow meines Formulares erstelle ich den Kontext. Zum Initialisieren der Ansicht rufe ich die untere Methode auf:
<pascal>procedure TForm1.FormResize(Sender: TObject);
var
VP: array[0..1] of Integer;
newWidth, newHeight: Integer;
begin
if (FInitialised) then begin
// Set the viewport for the OpenGL window
glGetIntegerv(GL_MAX_VIEWPORT_DIMS, @VP);

// Dont make the Window to large
newWidth := Min(VP[0], ClientWidth);
newHeight := Min(VP[1], Max(1, ClientHeight));

// Viewport von OpenGL setzen
glViewport(
(ClientWidth div 2) - (newWidth div 2),
(ClientHeight div 2) - (newHeight div 2),
newWidth,
newHeight);

// Projection matrix
glMatrixMode(GL_PROJECTION);
glLoadIdentity();

// Perspektive setzen
glOrtho(0, newWidth, newHeight, 0, -1, 1);

// Modelview Matrix
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
end;
end;</pascal>

Beim Zeichnen mache ich dann nichts weiter als:
<pascal>var
Error: Cardinal;
RenderMode: Cardinal;
begin
// Go to the model view matrix mode
glMatrixMode(GL_MODELVIEW);

// Replaces the current matrix with the identity matrix
glLoadIdentity();

// Clear the color and depth buffers
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);

glGetIntegerv(GL_RENDER_MODE, @RenderMode);

glPushName(0);
glLoadName(10);
// Zeichnen
glPopName;

Error := glGetError;
if Error <> 0 then
Caption := gluErrorString(Error);

if (RenderMode = GL_RENDER)
then SwapBuffers (FDC);
end;</pascal>

Die Selection sieht so aus:
<pascal>var
Puffer : array[0..256] of GLUInt;
Viewport : TGLVectori4;
Treffer,i : Integer;
Z_Wert : GLUInt;
Getroffen : GLUInt;
begin
glGetIntegerv(GL_VIEWPORT, @viewport);
glSelectBuffer(256, @Puffer);
glRenderMode(GL_SELECT);

glMatrixMode(GL_PROJECTION);
glPushMatrix;
glLoadIdentity;

gluPickMatrix(X, Viewport[3] - Y, 1.0, 1.0, Viewport);
glOrtho(0, ClientWidth, ClientHeight, 0, -1, 1);

FormPaint(Self);

glMatrixMode(GL_PROJECTION);
glPopMatrix;

treffer := glRenderMode(GL_RENDER);

if treffer > 0 then begin
Getroffen := High(GLUInt);
Z_Wert := High(GLUInt);
for i := 0 to Treffer-1 do
if Puffer[(i*4)+1] < Z_Wert then begin
getroffen := Puffer[(i*4)+3];
Z_Wert := Puffer[(i*4)+1];
end;

ShowMessage(IntToStr(Getroffen));
end;
end;</pascal>

==Links==
[[Tutorial_Selection| Selektionstutorial von DelphiGL.com]]

Selektion

2006-01-05T12:05:22Z

Lossy eX: /* Selektion in 2D (glOrtho) */ Projektion wird jetzt gepushed anstelle es hinterher neu zu setzen. Ist wohl einfacher.

==Was ist das?==
Die Selektion ist ein bestimmter Rendermodus von '''OpenGL'''. Im Selektionsmodus (der durch [[glRenderMode]] gesetzt wird) werden keine [[Fragment]]e erzeugt und auch keine Änderungen am [[Framebuffer]] durchgeführt. Anstelle dessen werden 4 Werte pro sichtbaren [[Primitive]]n in einen [[glSelectBuffer|Selektions Puffer]] geschrieben. Dieser Puffer muss schon vor dem Aufruf dieser Funktion erstellt worden sein.

Die vier Werte die man pro Primitiven erhält sind:
# Anzahl der Namen auf dem Stack
# Kleinster Z-Wert des getroffenen Objektes
# Größter Z-Wert des getroffenen Objektes
# Name des Objektes

==Wozu brauch ich das?==
Für die Interaktion des Nutzers mit der Szene.

==Wie geht das?==
Durch den Selektionspuffer bekommt man die [[OpenGL Name]]n der Szenen Elemente zurückgeliefert die im Rendermodus GL_RENDER gerendert worden wären. Dies ermöglicht es unter zuhilfenahme von [[gluPickMatrix]] den Bereich um einen Mausklick auszuwerten. Wie das genau funktioniert könnt ihr im Selektionstutorial (siehe Links) nachlesen.

==OpenGL Funktionen==
Folgende Funktionen haben mit der Selektion zu tun:

[[glRenderMode]], [[glSelectBuffer]], [[glLoadName]], [[gluPickMatrix]], [[Picking]]

==Beispiele==

===Selektion in 2D (glOrtho)===
Im OnShow meines Formulares erstelle ich den Kontext. Zum Initialisieren der Ansicht rufe ich die untere Methode auf:
<pascal>procedure TForm1.FormResize(Sender: TObject);
var
VP: array[0..1] of Integer;
newWidth, newHeight: Integer;
begin
if (FInitialised) then begin
// Set the viewport for the OpenGL window
glGetIntegerv(GL_MAX_VIEWPORT_DIMS, @VP);

// Dont make the Window to large
newWidth := Min(VP[0], ClientWidth);
newHeight := Min(VP[1], Max(1, ClientHeight));

// Viewport von OpenGL setzen
glViewport(
(ClientWidth div 2) - (newWidth div 2),
(ClientHeight div 2) - (newHeight div 2),
newWidth,
newHeight);

// Projection matrix
glMatrixMode(GL_PROJECTION);
glLoadIdentity();

// Perspektive setzen
glOrtho(0, newWidth, newHeight, 0, -1, 1);

// Modelview Matrix
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
end;
end;</pascal>

Beim Zeichnen mache ich dann nichts weiter als:
<pascal>var
Error: Cardinal;
RenderMode: Cardinal;
begin
// Go to the model view matrix mode
glMatrixMode(GL_MODELVIEW);

// Replaces the current matrix with the identity matrix
glLoadIdentity();

// Clear the color and depth buffers
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);

glGetIntegerv(GL_RENDER_MODE, @RenderMode);

glPushName(0);
glLoadName(10);
// Zeichnen
glPopName;

Error := glGetError;
if Error <> 0 then
Caption := gluErrorString(Error);

if (RenderMode = GL_RENDER)
then SwapBuffers (FDC);
end;</pascal>

Die Selection sieht so aus:
<pascal>var
Puffer : array[0..256] of GLUInt;
Viewport : TGLVectori4;
Treffer,i : Integer;
Z_Wert : GLUInt;
Getroffen : GLUInt;
begin
glGetIntegerv(GL_VIEWPORT, @viewport);
glSelectBuffer(256, @Puffer);
glRenderMode(GL_SELECT);

glMatrixMode(GL_PROJECTION);
glPushMatrix;
glLoadIdentity;

gluPickMatrix(X, Viewport[3] - Y, 1.0, 1.0, Viewport);
glOrtho(0, ClientWidth, ClientHeight, 0, -1, 1);

FormPaint(Self);

glMatrixMode(GL_PROJECTION);
glPopMatrix;

treffer := glRenderMode(GL_RENDER);

if treffer > 0 then begin
Getroffen := High(GLUInt);
Z_Wert := High(GLUInt);
for i := 0 to Treffer-1 do
if Puffer[(i*4)+1] < Z_Wert then begin
getroffen := Puffer[(i*4)+3];
Z_Wert := Puffer[(i*4)+1];
end;

ShowMessage(IntToStr(Getroffen));
end;
end;</pascal>

==Links==
[[Tutorial_Selection| Selektionstutorial von DelphiGL.com]]

Diskussion:Tutorial Komponentenentwicklung

2005-11-29T12:24:21Z

Lossy eX:

Das Tutorial ist formal erstmal soweit korrekt, vermittelt aber gegenüber den Einsteiger-Tuts IMHO nichts Neues (oder ich hab das Neue übersehen).

Stellen, an denen Du mehr ins Detail gehen könntest, währen das Beeinflussen des DC (z.B. Skalierung der logischen Pixel-Skala unabhängig von der Fenstergröße, überschreiben von Properties, Implementierung einfacher nicht-visueller Komponenten).

Weiterhin fehlt mir in diesem Tut auch eine gewisse Erklärung von dem, wie Du auf gewisse Source-Zeilen kommst, auch wenn alles dahinter kommentiert ist. Unter einem Tutorial stelle ich mir eine Wissensvermittelnde Erklärung vor, die wesentlich ausführlicher darlegt, wie man sich selbst den vermittelten Gegenstand herleiten kann.

MfG, --[[Benutzer:BenBE|BenBE]] 09:04, 29. Nov 2005 (CET)
----

Was mir auch gerade in einem anderen Artikel aufgefallen ist. Könntest du zwischen Code und Kommentar bitte mindestens 1 Leerzeichen platz lassen? Ich finde das wirkt so ein wenig globig. Mir persönlich fällt es mit einem Leerzeichen viel leichter den Code zu lesen.
--[[Lossy eX|Lossy eX]] 13:23, 29. Nov 2005 (CET)

Tutorial Lektion 2

2005-11-29T12:16:09Z

Lossy eX: /* Saubere Arbeit */

= Entdeckung einer neuen Welt =
== Vorwort ==
Ich möchte Euch an dieser Stelle bei DGL herzlich willkommen heißen. Vermutlich wird dies eines der ersten Tutorials sein, das Ihr als Einsteiger lesen werdet. Wahrscheinlich werdet Ihr dann auch noch nicht lange bei uns sein und Euch nicht vorstellen können, dass all die Schreiber auf unserer Seite keine Gurus, sondern ganz normale Menschen sind.

Man kann uns also jeder Zeit im Forum "anfassen", uns Fragen stellen, Vorschläge unterbreiten oder einfach nur einmal kurz mit einem Lob ermutigen weitere Texte zu verfassen ;-).

Ich wünsche Euch an dieser Stelle viel Erfolg bei dem Einstieg in die Thematik OpenGL und ermahne Euch noch einmal, dass Ihr Eure Ziele nicht zu weit steckt. Wirklich Spaß beginnt OpenGL nämlich erst dann zu machen, wenn man stets kleinere Erfolge feiern kann.
== Höhere Mächte - Matrizen und ihre Folgen ==
=== Saubere Arbeit ===
Bevor wir direkt beginnen etwas zu Zeichnen müssen wir erst einmal das Bild löschen, denn wie in der vorherigen Lektion beschrieben zeichnen wir die Szene jeden Schleifendurchlauf neu. Das Löschen der Puffer, in dem die Bildinformationen enthalten sind übernimmt die Funktion [[glClear]]. Die Farbinformationen unser [[Fragment|Fragmente]] (Fragmente sind vergleichbar mit den [[Pixel|Pixeln]] auf dem Bildschirm besitzen aber weitere Informationen wie z.B. Tiefenwerte. Bei der Ausgabe des Bildes werden diese Fragmente in Pixel umgewandelt) sind in dem so genannten [[Farbpuffer]] (Colorbuffer) gespeichert. Aus diesem Grund übergeben wir an die Funktion glClear die Konstante GL_COLOR_BUFFER_BIT. Die oben bereits angesprochenen Tiefenwerte stehen im [[Tiefenpuffer]]. Diese Daten werden benutzt um zu entscheiden welche Pixel durch andere verdeckt werden. Deshalb sollten wir den Tiefenpuffer auch mit löschen. Die Konstante dafür heißt GL_DEPTH_BUFFER_BIT.

<pascal>//Farbbuffer und Tiefenpuffer entleeren
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);</pascal>

[[bild:tutimg_lektion2_puffereffekt.gif|right]]
Mit Hilfe des Befehls [[glClearColor]] können wir festlegen, welche Farbinformationen mit dem Aufruf von glClear in den Colorbuffer geschrieben werden sollen. Wenn wir es also genau nehmen so löscht glClear den Colorbuffer nicht, sondern es schreibt ihn mit den definierten Werten voll. Standardmäßig erhalten die Fragmente eine schwarze Farbe. (Der Vollständigkeit halber sei erwähnt, dass der Tiefenpuffer immer mit Nullen überschrieben wird.)

Es wird also nicht bei jedem Zeichenvorgang (Rendervorgang) der Bildspeicher gelöscht, sondern der Programmierer entscheidet, wann dies geschehen soll. Theoretisch könnt Ihr auch die Szene wiedergeben und dann löschen, bevor sie ausgegeben wird... wer's mag :).

Wer sich entscheidet den Colorbuffer nicht zu löschen, der kann so auch einige nette Effekte erzeugen. Den Cheatern unter euch sollte der erreichte Effekt bekannt vorkommen, wenn man beispielsweise bei Counter-Strike durch die Wand gelaufen ist. Der Grund für das Verwischen ist in beiden Fällen derselbe: Das neue Bild wird gezeichnet, ohne dass das alte Bild aus dem Puffer entfernt wurde.

=== Und die Welt ist doch keine Scheibe... ===
[[bild:tutimg_lektion2_koordinatensystem.jpg|256px|right]]
Nachdem wir nun wieder Ordnung im Speicher geschafft haben, können wir zum interessanten Teil kommen: "Wie darf man sich einen 3D-Raum vorstellen?" Nun ... warum schaut Ihr Euch nicht einmal in Eurem Zimmer um?

Versuchen wir doch mal, ein Beispiel direkt aus dem Leben gegriffen zu nehmen und stellen uns unsere Umgebung als Koordinaten-System vor (Igitt!). Der Monitor, der hoffentlich direkt vor uns steht, ist in diesem Fall unser Ursprung, d.h. er liegt an dem Punkt (0, 0, 0).

Blicken wir seitwärts neben den Monitor, so sehen wir eine Linie (wenn Ihr es nicht tun solltest, macht Euch keine Sorgen ... solche Anfälle hat der Autor häufiger *g*), die von links nach rechts verläuft. Es handelt sich hierbei um die X-Achse, die links vom Monitor im negativen Bereich verläuft, rechts davon in den positiven.

Nun blicken wir einmal nach oben und einmal nach unten und schon erspähen wir die Y-Achse, die oberhalb des Monitors positiv verläuft, unterhalb negativ. Wunderbar! Wenn Ihr bereits in 2D gearbeitet habt, solltet Ihr an dieser Stelle ein dümmliches Grinsen auf Eurem Gesichte haben und das wohltuende Gefühl, dass Euch das doch alles bereits irgendwie bekannt vorkommt. Doch zu unserem Entsetzen können wir uns ja auch noch von unserem Bildschirm wegbewegen oder auch dichter heran (alle Kurzsichtigen unter uns sollten das nicht so persönlich nehmen, auch sie leben in einem 3D-Raum ^__-).

Dieses Phänomen ist im 3D-Raum typisch, jedoch nicht unerklärlich, da wir uns auf der Z-Achse bewegen. Rollen wir mit dem Stuhl vom Monitor weg, so gelangen wir in den positiven Bereich der Z-Achse, bewegen wir uns drauf zu, gelangen wir in den negativen Bereich. Jeder, der bereits in D3D programmiert hat, sollte sich schleunigst einprägen, dass das ein großer Unterschied zwischen D3D und OpenGL ist. Das kann sonst zu einigen wirklich fiesen Fehlern führen, wenn man es nicht weiß... *fg*.

Soweit so gut! Klingt bisher hoffentlich immer noch nicht so kompliziert. Nur keine Sorge, das Niveau versuchen wir zu halten ;).

Speziell wenn Ihr bereits 2D-Spiele programmiert habt, solltet Ihr Euch sehr schnell von folgenden Gedanken trennen: Die Koordinaten, die Ihr seht und angebt, entsprechen in der Regel nicht den Pixeln des Bildschirmes, sondern so genannten Weltkoordinaten. Eine Definition für diese Weltkoordinaten gibt es nicht, denn wie groß diese sind ist dem Programmierer überlassen. Ob Ihr euer Objekt eine Einheit vor Euch und 0,1 Einheit rechts von Euch oder aber 100 Einheiten vor euch und 10 Einheiten neben Euch positioniert ist egal. Die euch zur Verfügung stehende Welt ist grenzenlos ;). Ihr könnt Eure Szene theoretisch unendlich klein oder aber unendlich groß darstellen. Das einzige was euch wirklich daran hindert ist die Größe und Auflösung der Euch zur Verfügung stehenden Typen wie Integer oder Single ;). Der eigentliche Größeneindruck eines Objektes entsteht durch die Geschwindigkeit mit der sich der Betrachter und andere Objekte in der Welt bewegen.

=== Der erste Kontakt ===
Um nun etwas mit OpenGL rendern zu können, müssen wir uns bewusst werden, was die Worldmatrix ist. In dieser Matrix wird festgehalten, wie und wo ein Objekt gezeichnet wird. Das hört sich vielleicht zunächst recht merkwürdig an, lässt sich aber leicht veranschaulichen.

Stellen wir uns vor, die Worldmatrix zeigt auf einen Punkt, an dem ein Objekt gezeichnet werden soll (ganz übel... wir werden später detaillierter darauf eingehen. Sollte es jemand also nach der folgenden Erläuterung nicht verstanden haben, kann er mich selbstverständlich persönlich per Mail zur "Rechenschaft" ziehen oder aber er wirft einen Blick in unser OpenGLWiki :)).

Diesen Punkt setzen wir nun am Anfang in den Mittelpunkt unseres Koordinatensystems. Um oberes Beispiel aufzugreifen: Den Bildschirm. Dies geschieht mit dem Befehl [[glLoadIdentity]] und entspricht einem Reset der Worldmatrix. Theoretisch können wir nun an dieser Stelle etwas zeichnen. Dies würde allerdings dazu führen, dass das Objekt sehr groß oder gar nicht zu sehen ist, weil wir uns eben auch an diesen Stellen befinden. Gehen wir doch einmal 1,5 Einheiten nach links und 6 Einheiten nach hinten!

Hierfür sollte man sich bewusst werden, dass wir in OpenGL praktisch an einen Stuhl gefesselt sind, d.h. wir können uns gar nicht bewegen. Das soll uns aber nicht davon abhalten. Wir brauchen ja nur die ganze Welt so zu bewegen, dass es für uns aussieht, als ob wir uns bewegen. Denn wenn sich alles außer uns nach links bewegt, haben wir den Eindruck, wir wären nach rechts gewandert, right?

Nun aber zu der Bewegung unseres ersten Objektes:
<pascal>glTranslatef(-1.5,0,0);
glTranslatef(0, 0,-6);</pascal>
Dies hat bewirkt, dass sich unser Zeichenstift 1,5 Einheiten nach links (negativer Bereich der X-Achse) und anschließend 6Einheiten nach hinten bewegt hat. Ich habe diesen Fall absichtlich in zwei Schritten gefasst, um es zu verdeutlichen. Sicherlich wäre es einfacher, alles mit nur einem Aufruf von [[glTranslate|glTranslate*]] zu machen:
<pascal>glTranslatef(-1.5, 0,-6);</pascal>
Man beachte, dass in diesem Fall die 6 Schritte nach hinten notwendig sind um ein bisschen Distanz zum Objekt zu bekommen und nicht direkt in ihm zu stehen!

Fertig! Schon haben wir dort unseren "Zeichenstift" positioniert, der nun auf weitere Zeichenkommandos von uns wartet. Das mag sicherlich alles ein wenig verwirrend klingen... testet es am Besten aus und spielt mit den Parametern und erkennt, was gemeint ist :).
== Von Sichtungen... ==
=== Die Büchse der Pandora ===
Nun sind wir aber auch alle scharf darauf, endlich etwas zu rendern und auf dem Bildschirm auszugeben. Dies geschieht z.B. mit folgenden Zeilen:
<pascal>glBegin(GL_TRIANGLES);
glVertex3f(-1,-1, 0);
glVertex3f( 1,-1, 0);
glVertex3f( 0, 1, 0);
glEnd;</pascal>
Wir erkennen hierbei eindeutig eine Art Block. Gerade wir Pascaler sollten diese ja lieben :->. Wir teilen OpenGL mit Hilfe von [[glBegin]] mit, dass wir ein Objekt zeichnen wollen. In diesem Fall übergeben wir den Parameter GL_TRIANGLE, der OpenGL angibt, dass folgende Punkte als ein Dreieck interpretiert werden sollen.

Anschließend folgt ein dreifacher Aufruf von [[glVertex|glVertex3f]]. Jeder Aufruf erzeugt nun einen Punkt (Vertex) in unserem 3D-Raum. Da wir OpenGL bei glBegin mitgeteilt haben, dass diese Punkte zu einem Dreieck zusammengefügt werden sollen wird das auch so getan ;).

Wie wir auf dem Bild erkennen können, wurde unser Dreieck wie erwartet nach links verschoben abgebildet und auch mit einem leichten Abstand zur Kamera, nämlich 6 Einheiten entlang der Z-Achse.
=== Guter Stoff! ===
Nun ... ein wenig trostlos sieht unser Dreieck nun doch aus, oder? Ich habe übrigens damals bei D3D rund eine Woche benötigt, bis ich ein schwarzes Dreieck hatte. Wir haben immerhin schon ein weißes ... aber wir gehen nun einen Schritt weiter und werden das Dreieck schön bunt einfärben.

Bevor nun irgendjemand anfängt und Pixel für Pixel den Bildschirm nach zu pinseln oder gar sein PaintShop bereits offen hat, um die ersten Texturen zu erstellen, sei gestoppt! Es gibt für einfache Einfärbungen in OpenGL eine bessere Methode. Wir definieren einfach für jeden Eckpunkt eine Farbe und OpenGL wird dann sogar eigenständig die Farbverläufe dafür erstellen. Jeder der D3D kennt, wird diese Vorgehensweise bekannt vorkommen und er wird beginnen verzweifelt nach dem FVF zu suchen, um es korrekt zu definieren... Wenn Ihr einen Vertex zeichnet, so rendert OpenGL diesen automatisch "weiß" (Ah huch! Deswegen ist unser Dreieck auch weiß???). Alles was wir nun machen müssen, ist OpenGL mitzuteilen, dass es eine andere Farbe einsetzen soll. Und zwar wird OpenGL diese Farbe für alle folgenden Eckpunkte nutzen, so lange bis von uns ein anderes Kommando kommt.

Der mysteriöse Befehl, um den ich nun schon die ganze Zeit herumschwafle ist [[glColor|glColor*]]:
<pascal>// Alle folgenden Eckpunkte werden rot gefärbt
glColor3f(1,0,0);</pascal>
Wobei jeder Parameter einen Farbwert repräsentiert und zwar nach dem Muster RGB. Es wird ein Wert zwischen 1 und 0 erwartet, wobei eine Eins "volle Farbsättigung" bedeutet. Das heißt in unserem Fall haben wir als Farbe "rot" gesetzt.

Und weil wir schließlich die Welt ein wenig bunter machen und nicht nur das weiße Dreieck rot färben wollten, werden wir nach jedem Eckpunkt eine neue Farbe setzen:
<pascal>glBegin(GL_TRIANGLES);
glColor3f(1, 0, 0); glVertex3f(-1,-1, 0);
glColor3f(0, 0, 1); glVertex3f( 1,-1, 0);
glColor3f(0, 1, 0); glVertex3f( 0, 1, 0);
glEnd;</pascal>
Und dies ist dann unser farbenfrohes Ergebnis. Beeindruckend, wenn man bedenkt, wie wenig Aufwand letztendlich dahinter steckt, oder?

[[bild:tutimg_lektion2_dreieck.gif]]

== Nachwort ==
Wer meine Tutorials kennt weiß, dass zum Abschluß noch immer ein wenig Geblubber von mir kommt (man beachte diese entzückende Wortwahl von meiner einer... hoffe, der Lektor findet es auch amüsant...). (Anm. des Lektors: Und wie!) Schauen wir doch mal stolz auf das zurück, was wir heute erreicht haben! Wir haben OpenGL initialisiert, ein erstes Dreieck auf den Bildschirm gezaubert und dieses in den Farbtopf gesteckt! Das solltet Ihr als ein historisches Ereignis ansehen. Als ich damals mit D3D angefangen habe, brauchte ich, um es mir selbst zu erarbeiten, ca. eine Woche (Das ist jetzt der Moment, in dem Ihr Eure Hände heben solltest und ein lautes "Call me God" aus Euch herauskommen sollte, so dass zumindest Eure unmittelbaren Mitmenschen denken, dass Ihr einen Dachschaden habt!!! Das gehört einfach mit dazu ^__- )

Wie immer solltet Ihr Euch nun hinsetzen und Euch ein wenig mit den Parametern vertraut machen. Speziell bei glTranslate* solltet Ihr ein wenig mit den Parametern experimentieren, damit Ihr seht, was es mit den Matrizen auf sich hat und wie diese funktionieren. Wenn Ihr dann auch denkt, dass Ihr damit vertraut seid, versucht ein wenig mit den einzelnen Vertexpositionen zu experimentieren und verändert diese. Wenn auch das klar ist, setzt Euch in die Ecke und warte sehnsüchtig auf mehr von uns :D! (Anm: die "Ecke" ist nicht die Kneipe nebenan ... :)

Im nächsten Kapitel werden wir dann Matrizen-Hardcore machen ... legt also schon mal Euer Aspirin parat, es wird witzig werden *grunz* :).

Und wie immer freuen wir uns sehr über Feedback. Schreibt uns doch einfach ein paar Worte in unser [http://www.delphigl.com/forum/viewforum.php?f=8 Feedback-Forum]. Sagt was Ihr gut und was hingegen Ihr als schlecht empfunden habt! Auch freuen wir uns immer über Ideen für weitere Tutorials, teilt uns also bitte Eure Ideen mit ;)!

Okay... ich wünsche Euch einen angenehmen Tag / Nacht!

'''Euer''' 
'''Phobeus'''

{{TUTORIAL_NAVIGATION | [[Tutorial_lektion1]] | [[Tutorial_lektion3]]}}

[[Kategorie:Tutorial|Lektion2]]

wglUseFontBitmaps

2005-11-29T12:14:16Z

Lossy eX: /* Beispiel */ Quellcode aufgeräumt

= wglUseFontBitmaps =

 
== Name ==
'''wglUseFontBitmaps''' - Erzeugt aus der Schrifteinstellungen des [[Device Context]] eine Reihe von [[glBitmap]] Befehlen für die Buchstaben und speichert diese in [[Displaylisten]].
 

== Delphi-Spezifikation ==

function wglUseFontBitmaps (DC: HDC; first, count, listBase: DWORD): BOOL;

 

== Parameter ==

{| border="1" rules="all"
! ''DC''
| Ein Display Context mit entsprechenden Font-Einstellungen.
|-
! ''first''
| Mit welchen Zeichen soll begonnen werden
|-
! ''count''
| Anzahl der zu erzeugenden Listen/Zeichen
|-
! ''listBase''
| Der Name/Index der Liste für das erste Zeichen
|}

 

== Beschreibung ==
Die Schrifteinstellungen des [[Display Context]]es werden genutzt, um mit [[glBitmap]]-Befehlen die angebenen Zeichen in [[Displaylisten]] zu speichern.
Wenn ein Fehler auftritt wird statt '''true''', '''false''' zurückgegeben und der Fehler kann über GetLastError abgerufen werden.

 
== Hinweise ==
Jede Display Liste erhält logischerweise nur einen [[glBitmap]] Aufruf.

Da der [[glBitmap]] Befehl genutzt wird ändert sich die Rasterposition nach aufruf einer Liste.

Falls für ein Zeichen in der gewählten Schrift keine Daten vorliegen wird für dieses Zeichen eine leere Displayliste zurückgegeben.

Die durch diese Funktion unter Windows zur Verfügung stehende Schrift hat eine festgelegte Größe und ist logischerweise nur 2D. Möchte man eine 3D-Schrift haben so kann man dafür den Befehl [[wglUseFontOutlines]] benutzen.
 
== Beispiel ==

Zum Erstellen der Bitmapfonts gibt es wie üblich mehrere Wege. Einmal den Weg direkt über die Windowsapi oder den Weg über die Delphiklasse TFont. Das Zeichnen bleibt bei beiden gleich. Aus diesem Grund ist es auch vom Rest ein wenig getrennt.

=== Procedural ===

var
FontLists: Cardinal;
 
procedure CreateLists; // Wird einmal am Anfang aufgerufen
var
CustomFont: HFont;
begin
FontLists := glGenLists(256);
 
// CustomFont := GetStockObject (SYSTEM_FONT);
// Eine Alternative mit der man die Systemschriftart zurück bekommt.
 
CustomFont := CreateFont(
32, // Höhe
0, // Breite 0=Keine Vorgabe
0,
0,
0, // Fett?
0, // Kursiv?
0, // Unterstrichen?
0, // Durchgestrichen?
ANSI_CHARSET,
OUT_TT_PRECIS,
CLIP_DEFAULT_PRECIS,
NONANTIALIASED_QUALITY,
FF_DONTCARE or DEFAULT_PITCH,
'Times New Roman'); // Name der Schrift
 
SelectObject(DC, CustomFont); // Font auf einen Device Context benutzen
wglUseFontBitmaps (DC, 0, 255, FontLists); // Mit selektiertem Font Zeichen erstellen
end;

=== Objekt orientiert ===

var
Font: TFont;
 
procedure CreateLists; // Wird einmal am Anfang aufgerufen
var
CustomFont: HFont;
begin
FontLists := glGenLists(256);
 
Font := TFont.Create; // Instanz einer Fontklasse erstellen
try
Font.Name := 'Times New Roman'; // Name
Font.Size := 32; // Schriftgröße
Font.Style := [fsBold]; // Styles (fsBold, fsItalic, ...)
 
SelectObject(DC, Font.Handle); // Font auf einen Device Context benutzen
wglUseFontBitmaps (DC, 0, 255, FontLists); // Mit selektiertem Font Zeichen erstellen
finally
FreeAndNil(Font); // erstellte Instanz wieder frei geben
end;
end;

=== Bitmapfonts benutzen ===

procedure ShowText(pText: String);
begin
glListBase(FontLists); // Liste auswählen
glCallLists(Length(pText), GL_UNSIGNED_BYTE, Pointer(pText)); // Entsprechende Listen aufrufen
end;
 
procedure Draw; // Zeichen Routine
begin
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
glColor3f(1,0.5,0); // Aktuelle Farbe für glRasterPos festlegen
glRasterPos3f(-0.1,0,-1); // (sichtbare) Rasterposition eintellen
ShowText('OpenGL ');
ShowText('Wiki'); // Steht nach "OpenGL" da glBitmap die Rasterposition verschiebt.
end;

==Siehe auch ==

[[glBitmap]], [[glListBase]], [[glCallLists]], [[wglUseFontOutlines]]

[[Kategorie:WGL|UseFontBitmaps]]

glTexImage

2005-09-30T07:19:09Z

Lossy eX: /* Fehlermeldungen */ Gibt keinen Parameter components

= glTexImage =

 
== Name ==
'''glTexImage''' - Einstellungen zum Texturen zeichnen

 
== Spezifikation ==
procedure '''glTexImage1D'''(''target'': TGLenum; ''level'': TGLint; ''internalformat'': TGLint; ''width'': TGLsizei;
''border'': TGLint; ''format'': TGLenum; ''_type'': TGLenum; '''const''' ''pixels'': PGLvoid); 
procedure '''glTexImage2D'''(''target'': TGLenum; ''level'': TGLint; ''internalformat'': TGLint; ''width'': TGLsizei;
''height'': TGLsizei; ''border'': TGLint; ''format'': TGLenum; ''_type'': TGLenum;
'''const''' ''pixels'': PGLvoid); 
procedure '''glTexImage3D'''(''target'': TGLenum; ''level'': TGLint; ''internalformat'': TGLint; ''width'': TGLsizei;
''height'': TGLsizei; ''depth'': TGLsizei; ''border'': TGLint; ''format'': TGLenum;
''_type'': TGLenum; '''const''' ''pixels'': PGLvoid); 

== Parameter ==
<table border=1 rules=all>
<tr>
<td>''target''</td>
<td>Gibt an, welche Texture erreicht werden soll. Muss je nach Funktionsaufruf '''GL_TEXTURE_1D,GL_TEXTURE_2D''' oder '''GL_TEXTURE_3D''' sein.</td>
</tr>
<tr>
<td>''level''</td>
<td>Gibt den Detailgrad für das gewünschte Bild an. 
''level'' '''0''' ist das Basisbild. Level n ist die n-te Mipmap reduzierung des Bildes.</td>
</tr>
<tr>
<td>''internalformat''</td>
<td>'''1''' für '''R''' '''2''' für '''R''' und '''A''' '''3''' für '''RGB''' '''4''' für '''RGBA'''</td>
</tr>
<tr>
<td>''width'',</td>
<td>Breite = Anzahl der Pixel pro Zeile muss als Wert 2^n (+ 2 * (border) ) für n Integerwerte haben.</td>
</tr>
<tr>
<td>''height'',</td>
<td>Höhe = Anzahl der Zeilen muss als Wert 2^n (+ 2 * (border) ) für n Integerwerte haben</td>
</tr>
<tr>
<td>''depth'',</td>
<td>Tiefe = Anzahl der "Scheiben" muss als Wert 2^n (+ 2 * (border) ) für n Integerwerte haben</td>
</tr>
<tr>
<td>''border'',</td>
<td>Breite des Rahmens || '''0''' oder '''1'''</td>
</tr>
<tr>
<td>''format''</td>
<td>Bestimmt das Format der Pixeldaten. Folgende symbolische Werte werden akzeptiert: 
'''GL_COLOR_INDEX, GL_RED, GL_GREEN, GL_BLUE, GL_ALPHA, GL_RGB, GL_RGBA, GL_LUMINANCE,''' und '''GL_LUMINANCE_ALPHA'''</td>
</tr>
<tr>
<td>''_type''</td>
<td>Bestimmt den Pixeltyp für den Inhalt von ''pixels''. Folgende Typen werden unterstützt: 
'''GL_UNSIGNED_BYTE, GL_BYTE, GL_UNSIGNED_SHORT, GL_SHORT, GL_UNSIGNED_INT, GL_INT, GL_FLOAT, GL_BITMAP'''</td>
</tr>
<tr>
<td>''pixels''</td>
<td>Die Texture-Image Daten vom Typ, der in ''format'' angegeben wurde ( Array wo die Pixel gespeichert sind ) </td>
</tr>
</table>

 

== Beschreibung ==
Texturierung bildet einen bestimmten Teil eines Texturbildes auf alle [[Primitive|Grafikprimitiven]] ab für die Texturierung aktiviert ist.

Je nachdem welche Texturart aktiviert werden soll ruft man [[glEnable]] mit den Parametern '''GL_TEXTURE_1D, GL_TEXTURE_2D''' oder '''GL_TEXTURE_3D''' auf. Die Deaktivierung erfolgt entsprechend mittels [[glDisable]].

Die Texturbilder werden durch die Funktionen '''glTexImage1D, glTexImage2D''' bzw. '''glTexImage3D''' definiert. Die Argumente der Funktionen beschreiben die Eigenschaften des Texturbildes wie z.B. Breite, Höhe, Tiefe (je nach Dimension), Breite des Randes, [[LOD]]-Nummer (siehe [[glTexParameter]]) und Anzahl der unterstützen Farbkomponenten. Die letzten 3 Argumente beschreiben wie das Bild im Speicher abgelegt wird. Die 3 Argumente sind identisch mit denen, die das Pixelformat bei [[glDrawPixels]] steuern.

Die Daten werden aus ''pixels'' als Sequenz von vorzeichenlosen oder -behafteten Byte-, Shortint- oder Longint-Werten oder als Fließkommazahlen einfacher Genauigkeit gelesen. Der Typ wird über ''type'' festgelegt. 
Die ausgelesen Werte werden abhängig von ''format'' gruppiert zu Gruppen mit je einem, zwei, drei oder vier Werten. Diese Gruppen entsprechen einem Element.

Wenn ''type'' gleich '''GL_BITMAP''' ist, werden die Daten als Folge (orig.: "String") von vorzeichenlosen Bytewerten angesehen (wobei ''format'' '''GL_COLOR_INDEX''' sein muss). Jedes Byte des Datenblocks wird als Gruppe von 8 1-Bit Elementen interpretiert. Die Reihenfolge der Bits wird durch '''GL_UNPACK_LSB_FIRST''' (siehe [[glPixelStore]]) festgelegt.

Der ''format'' Parameter bestimmt die Zusammenstellung der Elemente aus ''pixels''. Folgende 9 möglichen Werte kann ''format'' haben:

'''GL_COLOR_INDEX'''
:Jedes Element entspricht einem einzelnen Wert, dem Farbindex. Jeder Index wird in eine Festkommazahl (mit einer unbestimmten Anzahl 0 Bits rechts vom Komma) konvertiert, abhängig von Wert und Vorzeichen von '''GL_INDEX_SHIFT''' bitweise nach rechts bzw. links verschoben und zu GL_INDEX_OFFSET addiert. Dann werden die Indizes durch ihre entsprechenden Werte aus den Tabellen '''GL_PIXEL_MAP_I_TO_R''', '''GL_PIXEL_MAP_I_TO_G''', '''GL_PIXEL_MAP_I_TO_B''' und '''GL_PIXEL_MAP_I_TO_A''' ersetzt und auf das Interval [0, 1] heruntergerechnet.

'''GL_RED'''
:Jedes Element entspricht einer roten Farbkomponente. Der Wert wird in eine Fließkommazahl konvertiert und zu einem RGBA Wert ergänzt, indem man 0.0 für die beiden anderen Farben und 1.0 für den Alphakanal hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_GREEN'''
:Jedes Element entspricht einer grünen Farbkomponente. Der Wert wird in eine Fließkommazahl konvertiert und zu einem RGBA Wert ergänzt, indem man 0.0 für die beiden anderen Farben und 1.0 für den Alphakanal hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_BLUE'''
:Jedes Element entspricht einer blauen Farbkomponente. Der Wert wird in eine Fließkommazahl konvertiert und zu einem RGBA Wert ergänzt, indem man 0.0 für die beiden anderen Farben und 1.0 für den Alphakanal hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_ALPHA'''
:Jedes Element entspricht einer Alpha-Farbkomponente. Der Wert wird in eine Fließkommazahl konvertiert und zu einem RGBA Wert ergänzt, indem man 0.0 für die drei anderen Farben hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_RGB'''
:Jedes Element entspricht den drei RGB-Farbwerten. Die Werte werden in Fließkommazahlen konvertiert und zu einem RGBA Wert ergänzt, indem man 1.0 für den Alphakanal hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_RGBA'''
:Jedes Element enthält alle vier Farbkomponenten. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_LUMINANCE'''
:Jedes Element entspricht einem Helligkeitswert. Der Wert wird in Fließkommazahlen konvertiert und zu einem RGBA Wert ergänzt, indem man den Helligkeitswert drei mal für R, G und B einsetzt und 1.0 für den Alphakanal hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_LUMINANCE_ALPHA'''
:Jedes Element entspricht einem Paar aus Helligkeitswert und Alphawert. Beide Werte werden in Fließkommazahlen konvertiert und zu einem RGBA Wert ergänzt, indem man den Helligkeitswert drei mal für R, G und B einsetzt und den Alphawert hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

Lesen Sie den Artikel [[glDrawPixels]] um eine Beschreibung der zulässigen Werte für ''type'' zu erhalten.

Ein Texturbild kann bis zu 4 Farbkomponenten pro Texturelement ([[Texel]]) besitzen. Dies wird über den Parameter ''internalformat'' geregelt. 
Ein Texturbild welches nur eine Komponente besitzt, beenutzt nur die Rotwerte der aus ''pixels'' extrahierten RGBA Farbe. 
Ein Texturbild mit zwei Komponenten benutzt nur die Rot und Alpha Komponenten. 
Ein Texturbild mit drei Komponenten benutzt nur die Rot, Grün und Blau Komponenten. 
Ein Texturbild mit vier Komponenten benutzt alle RGBA Farbkomponenten. 

 

== Hinweise ==
'''glTexImage3D''' war bis zu OpenGL 1.2 nur eine Erweiterung. Deswegen ist bei manchen Chipsätzen die Funktion nur als '''glTexImage3DEXT''' verfügbar.

Texturierung hat im Farbindexmodus keinen Effekt.

Das Texturbild kann in den selben Datenformaten vorliegen wie die Pixel bei [[glDrawPixels]] ausgenommen '''GL_STENCIL_INDEX''' und '''GL_DEPTH_COMPONENT'''. [[glPixelStore]] und [[glPixelTransfer]] beeinflussen das Texturebil in exakt der Art und Weise, wie sie auch [[glDrawPixels]] beeinflussen.

Eine Textur die 0 Pixel hoch oder breit ist, stellt die NULL-Textur dar. Wenn die NULL-Textur für die LOD-Stufe 0 spezifiziert wird entspricht das Verhalten dem bei deaktivierter Texturierung.

== Änderungen ==
Folgende Erweiterungen hat die Funktion erfahren:

=== Ab OpenGL Version 1.3 ===
[[GL_ARB_texture_cube_map]] definiert weitere 6 2D-Texture-Typen welche als ''target'' angegeben werden können.

 

== Fehlermeldungen ==

'''GL_INVALID_ENUM''' wird generiert wenn ''target'' nicht '''GL_TEXTURE_1D, GL_TEXTURE_2D''' oder '''GL_TEXTURE_3D''' ist. (entsprechend der benutzten Funktion) 

'''GL_INVALID_ENUM''' wird generiert wenn ''format'' ungültige Werte übergeben wurden. Akzeptiert werden alle Formatangaben außer '''GL_STENCIL_INDEX''' und '''GL_DEPTH_COMPONENT''' 

'''GL_INVALID_ENUM''' wird generiert wenn ''type'' keine gültige Typkonstante übergeben wurde. 

'''GL_INVALID_ENUM''' wird generiert wenn GL_BITMAP als ''type'' und '''GL_COLOR_INDEX nicht(!)''' als ''format'' angegeben wurde. 

'''GL_INVALID_VALUE''' wird generiert wenn ''level'' kleiner 0 oder größer ld(max) ist, wobei max der Rückgabewert von '''GL_MAX_TEXTURE_SIZE''' ist. (ld = Logarithmus Dualis = Basis 2). 

'''GL_INVALID_VALUE''' wird generiert wenn für ''internalformat'' etwas anderes als ''1'', ''2'', ''3'' oder ''4'' angegeben wurde. 

'''GL_INVALID_VALUE''' wird generiert wenn ''width'', ''height'' bzw. ''depth'' (je nach Funktion) kleiner als 0 oder größer als 2 + '''GL_MAX_TEXTURE_SIZE''' ist, oder die Bedingung 2^k + 2 * (border) (k=Integerwerte) nich erfüllt. 

'''GL_INVALID_VALUE''' wenn ''border'' nicht ''0'' oder ''1'' ist. 

'''GL_INVALID_OPERATION''' wird generiert wenn eine '''glTexImage'''-Funktion in einem [[glBegin]]- und [[glEnd]]-Block aufgerufen wird. 

== Zugehörige Wertrückgaben ==
[[glGetTexImage]] 
[[glIsEnabled]] mit dem Token '''GL_TEXTURE_1D''', '''GL_TEXTURE_2D''' bzw. '''GL_TEXTURE_2D'''.

 

== Siehe auch ==
[[glTexEnv]], [[glTexGen]], [[glTexSubImage1D]], [[glTexSubImage2D]], [[glTexSubImage3D]], [[glTexParameter]], [[glTexCoord]]

[[Kategorie:GL|TexImage]]

glTexImage

2005-09-30T07:13:41Z

Lossy eX: /* Beschreibung */ Es gibt keinen Parameter Components

= glTexImage =

 
== Name ==
'''glTexImage''' - Einstellungen zum Texturen zeichnen

 
== Spezifikation ==
procedure '''glTexImage1D'''(''target'': TGLenum; ''level'': TGLint; ''internalformat'': TGLint; ''width'': TGLsizei;
''border'': TGLint; ''format'': TGLenum; ''_type'': TGLenum; '''const''' ''pixels'': PGLvoid); 
procedure '''glTexImage2D'''(''target'': TGLenum; ''level'': TGLint; ''internalformat'': TGLint; ''width'': TGLsizei;
''height'': TGLsizei; ''border'': TGLint; ''format'': TGLenum; ''_type'': TGLenum;
'''const''' ''pixels'': PGLvoid); 
procedure '''glTexImage3D'''(''target'': TGLenum; ''level'': TGLint; ''internalformat'': TGLint; ''width'': TGLsizei;
''height'': TGLsizei; ''depth'': TGLsizei; ''border'': TGLint; ''format'': TGLenum;
''_type'': TGLenum; '''const''' ''pixels'': PGLvoid); 

== Parameter ==
<table border=1 rules=all>
<tr>
<td>''target''</td>
<td>Gibt an, welche Texture erreicht werden soll. Muss je nach Funktionsaufruf '''GL_TEXTURE_1D,GL_TEXTURE_2D''' oder '''GL_TEXTURE_3D''' sein.</td>
</tr>
<tr>
<td>''level''</td>
<td>Gibt den Detailgrad für das gewünschte Bild an. 
''level'' '''0''' ist das Basisbild. Level n ist die n-te Mipmap reduzierung des Bildes.</td>
</tr>
<tr>
<td>''internalformat''</td>
<td>'''1''' für '''R''' '''2''' für '''R''' und '''A''' '''3''' für '''RGB''' '''4''' für '''RGBA'''</td>
</tr>
<tr>
<td>''width'',</td>
<td>Breite = Anzahl der Pixel pro Zeile muss als Wert 2^n (+ 2 * (border) ) für n Integerwerte haben.</td>
</tr>
<tr>
<td>''height'',</td>
<td>Höhe = Anzahl der Zeilen muss als Wert 2^n (+ 2 * (border) ) für n Integerwerte haben</td>
</tr>
<tr>
<td>''depth'',</td>
<td>Tiefe = Anzahl der "Scheiben" muss als Wert 2^n (+ 2 * (border) ) für n Integerwerte haben</td>
</tr>
<tr>
<td>''border'',</td>
<td>Breite des Rahmens || '''0''' oder '''1'''</td>
</tr>
<tr>
<td>''format''</td>
<td>Bestimmt das Format der Pixeldaten. Folgende symbolische Werte werden akzeptiert: 
'''GL_COLOR_INDEX, GL_RED, GL_GREEN, GL_BLUE, GL_ALPHA, GL_RGB, GL_RGBA, GL_LUMINANCE,''' und '''GL_LUMINANCE_ALPHA'''</td>
</tr>
<tr>
<td>''_type''</td>
<td>Bestimmt den Pixeltyp für den Inhalt von ''pixels''. Folgende Typen werden unterstützt: 
'''GL_UNSIGNED_BYTE, GL_BYTE, GL_UNSIGNED_SHORT, GL_SHORT, GL_UNSIGNED_INT, GL_INT, GL_FLOAT, GL_BITMAP'''</td>
</tr>
<tr>
<td>''pixels''</td>
<td>Die Texture-Image Daten vom Typ, der in ''format'' angegeben wurde ( Array wo die Pixel gespeichert sind ) </td>
</tr>
</table>

 

== Beschreibung ==
Texturierung bildet einen bestimmten Teil eines Texturbildes auf alle [[Primitive|Grafikprimitiven]] ab für die Texturierung aktiviert ist.

Je nachdem welche Texturart aktiviert werden soll ruft man [[glEnable]] mit den Parametern '''GL_TEXTURE_1D, GL_TEXTURE_2D''' oder '''GL_TEXTURE_3D''' auf. Die Deaktivierung erfolgt entsprechend mittels [[glDisable]].

Die Texturbilder werden durch die Funktionen '''glTexImage1D, glTexImage2D''' bzw. '''glTexImage3D''' definiert. Die Argumente der Funktionen beschreiben die Eigenschaften des Texturbildes wie z.B. Breite, Höhe, Tiefe (je nach Dimension), Breite des Randes, [[LOD]]-Nummer (siehe [[glTexParameter]]) und Anzahl der unterstützen Farbkomponenten. Die letzten 3 Argumente beschreiben wie das Bild im Speicher abgelegt wird. Die 3 Argumente sind identisch mit denen, die das Pixelformat bei [[glDrawPixels]] steuern.

Die Daten werden aus ''pixels'' als Sequenz von vorzeichenlosen oder -behafteten Byte-, Shortint- oder Longint-Werten oder als Fließkommazahlen einfacher Genauigkeit gelesen. Der Typ wird über ''type'' festgelegt. 
Die ausgelesen Werte werden abhängig von ''format'' gruppiert zu Gruppen mit je einem, zwei, drei oder vier Werten. Diese Gruppen entsprechen einem Element.

Wenn ''type'' gleich '''GL_BITMAP''' ist, werden die Daten als Folge (orig.: "String") von vorzeichenlosen Bytewerten angesehen (wobei ''format'' '''GL_COLOR_INDEX''' sein muss). Jedes Byte des Datenblocks wird als Gruppe von 8 1-Bit Elementen interpretiert. Die Reihenfolge der Bits wird durch '''GL_UNPACK_LSB_FIRST''' (siehe [[glPixelStore]]) festgelegt.

Der ''format'' Parameter bestimmt die Zusammenstellung der Elemente aus ''pixels''. Folgende 9 möglichen Werte kann ''format'' haben:

'''GL_COLOR_INDEX'''
:Jedes Element entspricht einem einzelnen Wert, dem Farbindex. Jeder Index wird in eine Festkommazahl (mit einer unbestimmten Anzahl 0 Bits rechts vom Komma) konvertiert, abhängig von Wert und Vorzeichen von '''GL_INDEX_SHIFT''' bitweise nach rechts bzw. links verschoben und zu GL_INDEX_OFFSET addiert. Dann werden die Indizes durch ihre entsprechenden Werte aus den Tabellen '''GL_PIXEL_MAP_I_TO_R''', '''GL_PIXEL_MAP_I_TO_G''', '''GL_PIXEL_MAP_I_TO_B''' und '''GL_PIXEL_MAP_I_TO_A''' ersetzt und auf das Interval [0, 1] heruntergerechnet.

'''GL_RED'''
:Jedes Element entspricht einer roten Farbkomponente. Der Wert wird in eine Fließkommazahl konvertiert und zu einem RGBA Wert ergänzt, indem man 0.0 für die beiden anderen Farben und 1.0 für den Alphakanal hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_GREEN'''
:Jedes Element entspricht einer grünen Farbkomponente. Der Wert wird in eine Fließkommazahl konvertiert und zu einem RGBA Wert ergänzt, indem man 0.0 für die beiden anderen Farben und 1.0 für den Alphakanal hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_BLUE'''
:Jedes Element entspricht einer blauen Farbkomponente. Der Wert wird in eine Fließkommazahl konvertiert und zu einem RGBA Wert ergänzt, indem man 0.0 für die beiden anderen Farben und 1.0 für den Alphakanal hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_ALPHA'''
:Jedes Element entspricht einer Alpha-Farbkomponente. Der Wert wird in eine Fließkommazahl konvertiert und zu einem RGBA Wert ergänzt, indem man 0.0 für die drei anderen Farben hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_RGB'''
:Jedes Element entspricht den drei RGB-Farbwerten. Die Werte werden in Fließkommazahlen konvertiert und zu einem RGBA Wert ergänzt, indem man 1.0 für den Alphakanal hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_RGBA'''
:Jedes Element enthält alle vier Farbkomponenten. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_LUMINANCE'''
:Jedes Element entspricht einem Helligkeitswert. Der Wert wird in Fließkommazahlen konvertiert und zu einem RGBA Wert ergänzt, indem man den Helligkeitswert drei mal für R, G und B einsetzt und 1.0 für den Alphakanal hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_LUMINANCE_ALPHA'''
:Jedes Element entspricht einem Paar aus Helligkeitswert und Alphawert. Beide Werte werden in Fließkommazahlen konvertiert und zu einem RGBA Wert ergänzt, indem man den Helligkeitswert drei mal für R, G und B einsetzt und den Alphawert hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

Lesen Sie den Artikel [[glDrawPixels]] um eine Beschreibung der zulässigen Werte für ''type'' zu erhalten.

Ein Texturbild kann bis zu 4 Farbkomponenten pro Texturelement ([[Texel]]) besitzen. Dies wird über den Parameter ''internalformat'' geregelt. 
Ein Texturbild welches nur eine Komponente besitzt, beenutzt nur die Rotwerte der aus ''pixels'' extrahierten RGBA Farbe. 
Ein Texturbild mit zwei Komponenten benutzt nur die Rot und Alpha Komponenten. 
Ein Texturbild mit drei Komponenten benutzt nur die Rot, Grün und Blau Komponenten. 
Ein Texturbild mit vier Komponenten benutzt alle RGBA Farbkomponenten. 

 

== Hinweise ==
'''glTexImage3D''' war bis zu OpenGL 1.2 nur eine Erweiterung. Deswegen ist bei manchen Chipsätzen die Funktion nur als '''glTexImage3DEXT''' verfügbar.

Texturierung hat im Farbindexmodus keinen Effekt.

Das Texturbild kann in den selben Datenformaten vorliegen wie die Pixel bei [[glDrawPixels]] ausgenommen '''GL_STENCIL_INDEX''' und '''GL_DEPTH_COMPONENT'''. [[glPixelStore]] und [[glPixelTransfer]] beeinflussen das Texturebil in exakt der Art und Weise, wie sie auch [[glDrawPixels]] beeinflussen.

Eine Textur die 0 Pixel hoch oder breit ist, stellt die NULL-Textur dar. Wenn die NULL-Textur für die LOD-Stufe 0 spezifiziert wird entspricht das Verhalten dem bei deaktivierter Texturierung.

== Änderungen ==
Folgende Erweiterungen hat die Funktion erfahren:

=== Ab OpenGL Version 1.3 ===
[[GL_ARB_texture_cube_map]] definiert weitere 6 2D-Texture-Typen welche als ''target'' angegeben werden können.

 

== Fehlermeldungen ==

'''GL_INVALID_ENUM''' wird generiert wenn ''target'' nicht '''GL_TEXTURE_1D, GL_TEXTURE_2D''' oder '''GL_TEXTURE_3D''' ist. (entsprechend der benutzten Funktion) 

'''GL_INVALID_ENUM''' wird generiert wenn ''format'' ungültige Werte übergeben wurden. Akzeptiert werden alle Formatangaben außer '''GL_STENCIL_INDEX''' und '''GL_DEPTH_COMPONENT''' 

'''GL_INVALID_ENUM''' wird generiert wenn ''type'' keine gültige Typkonstante übergeben wurde. 

'''GL_INVALID_ENUM''' wird generiert wenn GL_BITMAP als ''type'' und '''GL_COLOR_INDEX nicht(!)''' als ''format'' angegeben wurde. 

'''GL_INVALID_VALUE''' wird generiert wenn ''level'' kleiner 0 oder größer ld(max) ist, wobei max der Rückgabewert von '''GL_MAX_TEXTURE_SIZE''' ist. (ld = Logarithmus Dualis = Basis 2). 

'''GL_INVALID_VALUE''' wird generiert wenn für ''components'' etwas anderes als ''1'', ''2'', ''3'' oder ''4'' angegeben wurde. 

'''GL_INVALID_VALUE''' wird generiert wenn ''width'', ''height'' bzw. ''depth'' (je nach Funktion) kleiner als 0 oder größer als 2 + '''GL_MAX_TEXTURE_SIZE''' ist, oder die Bedingung 2^k + 2 * (border) (k=Integerwerte) nich erfüllt. 

'''GL_INVALID_VALUE''' wenn ''border'' nicht ''0'' oder ''1'' ist. 

'''GL_INVALID_OPERATION''' wird generiert wenn eine '''glTexImage'''-Funktion in einem [[glBegin]]- und [[glEnd]]-Block aufgerufen wird. 

== Zugehörige Wertrückgaben ==
[[glGetTexImage]] 
[[glIsEnabled]] mit dem Token '''GL_TEXTURE_1D''', '''GL_TEXTURE_2D''' bzw. '''GL_TEXTURE_2D'''.

 

== Siehe auch ==
[[glTexEnv]], [[glTexGen]], [[glTexSubImage1D]], [[glTexSubImage2D]], [[glTexSubImage3D]], [[glTexParameter]], [[glTexCoord]]

[[Kategorie:GL|TexImage]]

glTexImage

2005-09-30T07:04:44Z

Lossy eX: /* Parameter */ Es gibt keinen Parameter Components

= glTexImage =

 
== Name ==
'''glTexImage''' - Einstellungen zum Texturen zeichnen

 
== Spezifikation ==
procedure '''glTexImage1D'''(''target'': TGLenum; ''level'': TGLint; ''internalformat'': TGLint; ''width'': TGLsizei;
''border'': TGLint; ''format'': TGLenum; ''_type'': TGLenum; '''const''' ''pixels'': PGLvoid); 
procedure '''glTexImage2D'''(''target'': TGLenum; ''level'': TGLint; ''internalformat'': TGLint; ''width'': TGLsizei;
''height'': TGLsizei; ''border'': TGLint; ''format'': TGLenum; ''_type'': TGLenum;
'''const''' ''pixels'': PGLvoid); 
procedure '''glTexImage3D'''(''target'': TGLenum; ''level'': TGLint; ''internalformat'': TGLint; ''width'': TGLsizei;
''height'': TGLsizei; ''depth'': TGLsizei; ''border'': TGLint; ''format'': TGLenum;
''_type'': TGLenum; '''const''' ''pixels'': PGLvoid); 

== Parameter ==
<table border=1 rules=all>
<tr>
<td>''target''</td>
<td>Gibt an, welche Texture erreicht werden soll. Muss je nach Funktionsaufruf '''GL_TEXTURE_1D,GL_TEXTURE_2D''' oder '''GL_TEXTURE_3D''' sein.</td>
</tr>
<tr>
<td>''level''</td>
<td>Gibt den Detailgrad für das gewünschte Bild an. 
''level'' '''0''' ist das Basisbild. Level n ist die n-te Mipmap reduzierung des Bildes.</td>
</tr>
<tr>
<td>''internalformat''</td>
<td>'''1''' für '''R''' '''2''' für '''R''' und '''A''' '''3''' für '''RGB''' '''4''' für '''RGBA'''</td>
</tr>
<tr>
<td>''width'',</td>
<td>Breite = Anzahl der Pixel pro Zeile muss als Wert 2^n (+ 2 * (border) ) für n Integerwerte haben.</td>
</tr>
<tr>
<td>''height'',</td>
<td>Höhe = Anzahl der Zeilen muss als Wert 2^n (+ 2 * (border) ) für n Integerwerte haben</td>
</tr>
<tr>
<td>''depth'',</td>
<td>Tiefe = Anzahl der "Scheiben" muss als Wert 2^n (+ 2 * (border) ) für n Integerwerte haben</td>
</tr>
<tr>
<td>''border'',</td>
<td>Breite des Rahmens || '''0''' oder '''1'''</td>
</tr>
<tr>
<td>''format''</td>
<td>Bestimmt das Format der Pixeldaten. Folgende symbolische Werte werden akzeptiert: 
'''GL_COLOR_INDEX, GL_RED, GL_GREEN, GL_BLUE, GL_ALPHA, GL_RGB, GL_RGBA, GL_LUMINANCE,''' und '''GL_LUMINANCE_ALPHA'''</td>
</tr>
<tr>
<td>''_type''</td>
<td>Bestimmt den Pixeltyp für den Inhalt von ''pixels''. Folgende Typen werden unterstützt: 
'''GL_UNSIGNED_BYTE, GL_BYTE, GL_UNSIGNED_SHORT, GL_SHORT, GL_UNSIGNED_INT, GL_INT, GL_FLOAT, GL_BITMAP'''</td>
</tr>
<tr>
<td>''pixels''</td>
<td>Die Texture-Image Daten vom Typ, der in ''format'' angegeben wurde ( Array wo die Pixel gespeichert sind ) </td>
</tr>
</table>

 

== Beschreibung ==
Texturierung bildet einen bestimmten Teil eines Texturbildes auf alle [[Primitive|Grafikprimitiven]] ab für die Texturierung aktiviert ist.

Je nachdem welche Texturart aktiviert werden soll ruft man [[glEnable]] mit den Parametern '''GL_TEXTURE_1D, GL_TEXTURE_2D''' oder '''GL_TEXTURE_3D''' auf. Die Deaktivierung erfolgt entsprechend mittels [[glDisable]].

Die Texturbilder werden durch die Funktionen '''glTexImage1D, glTexImage2D''' bzw. '''glTexImage3D''' definiert. Die Argumente der Funktionen beschreiben die Eigenschaften des Texturbildes wie z.B. Breite, Höhe, Tiefe (je nach Dimension), Breite des Randes, [[LOD]]-Nummer (siehe [[glTexParameter]]) und Anzahl der unterstützen Farbkomponenten. Die letzten 3 Argumente beschreiben wie das Bild im Speicher abgelegt wird. Die 3 Argumente sind identisch mit denen, die das Pixelformat bei [[glDrawPixels]] steuern.

Die Daten werden aus ''pixels'' als Sequenz von vorzeichenlosen oder -behafteten Byte-, Shortint- oder Longint-Werten oder als Fließkommazahlen einfacher Genauigkeit gelesen. Der Typ wird über ''type'' festgelegt. 
Die ausgelesen Werte werden abhängig von ''format'' gruppiert zu Gruppen mit je einem, zwei, drei oder vier Werten. Diese Gruppen entsprechen einem Element.

Wenn ''type'' gleich '''GL_BITMAP''' ist, werden die Daten als Folge (orig.: "String") von vorzeichenlosen Bytewerten angesehen (wobei ''format'' '''GL_COLOR_INDEX''' sein muss). Jedes Byte des Datenblocks wird als Gruppe von 8 1-Bit Elementen interpretiert. Die Reihenfolge der Bits wird durch '''GL_UNPACK_LSB_FIRST''' (siehe [[glPixelStore]]) festgelegt.

Der ''format'' Parameter bestimmt die Zusammenstellung der Elemente aus ''pixels''. Folgende 9 möglichen Werte kann ''format'' haben:

'''GL_COLOR_INDEX'''
:Jedes Element entspricht einem einzelnen Wert, dem Farbindex. Jeder Index wird in eine Festkommazahl (mit einer unbestimmten Anzahl 0 Bits rechts vom Komma) konvertiert, abhängig von Wert und Vorzeichen von '''GL_INDEX_SHIFT''' bitweise nach rechts bzw. links verschoben und zu GL_INDEX_OFFSET addiert. Dann werden die Indizes durch ihre entsprechenden Werte aus den Tabellen '''GL_PIXEL_MAP_I_TO_R''', '''GL_PIXEL_MAP_I_TO_G''', '''GL_PIXEL_MAP_I_TO_B''' und '''GL_PIXEL_MAP_I_TO_A''' ersetzt und auf das Interval [0, 1] heruntergerechnet.

'''GL_RED'''
:Jedes Element entspricht einer roten Farbkomponente. Der Wert wird in eine Fließkommazahl konvertiert und zu einem RGBA Wert ergänzt, indem man 0.0 für die beiden anderen Farben und 1.0 für den Alphakanal hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_GREEN'''
:Jedes Element entspricht einer grünen Farbkomponente. Der Wert wird in eine Fließkommazahl konvertiert und zu einem RGBA Wert ergänzt, indem man 0.0 für die beiden anderen Farben und 1.0 für den Alphakanal hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_BLUE'''
:Jedes Element entspricht einer blauen Farbkomponente. Der Wert wird in eine Fließkommazahl konvertiert und zu einem RGBA Wert ergänzt, indem man 0.0 für die beiden anderen Farben und 1.0 für den Alphakanal hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_ALPHA'''
:Jedes Element entspricht einer Alpha-Farbkomponente. Der Wert wird in eine Fließkommazahl konvertiert und zu einem RGBA Wert ergänzt, indem man 0.0 für die drei anderen Farben hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_RGB'''
:Jedes Element entspricht den drei RGB-Farbwerten. Die Werte werden in Fließkommazahlen konvertiert und zu einem RGBA Wert ergänzt, indem man 1.0 für den Alphakanal hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_RGBA'''
:Jedes Element enthält alle vier Farbkomponenten. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_LUMINANCE'''
:Jedes Element entspricht einem Helligkeitswert. Der Wert wird in Fließkommazahlen konvertiert und zu einem RGBA Wert ergänzt, indem man den Helligkeitswert drei mal für R, G und B einsetzt und 1.0 für den Alphakanal hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_LUMINANCE_ALPHA'''
:Jedes Element entspricht einem Paar aus Helligkeitswert und Alphawert. Beide Werte werden in Fließkommazahlen konvertiert und zu einem RGBA Wert ergänzt, indem man den Helligkeitswert drei mal für R, G und B einsetzt und den Alphawert hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''c'''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

Lesen Sie den Artikel [[glDrawPixels]] um eine Beschreibung der zulässigen Werte für ''type'' zu erhalten.

Ein Texturbild kann bis zu 4 Farbkomponenten pro Texturelement ([[Texel]]) besitzen. Dies wird über den Parameter ''components'' geregelt. 
Ein Texturbild welches nur eine Komponente besitzt, beenutzt nur die Rotwerte der aus ''pixels'' extrahierten RGBA Farbe. 
Ein Texturbild mit zwei Komponenten benutzt nur die Rot und Alpha Komponenten. 
Ein Texturbild mit drei Komponenten benutzt nur die Rot, Grün und Blau Komponenten. 
Ein Texturbild mit vier Komponenten benutzt alle RGBA Farbkomponenten. 

 

== Hinweise ==
'''glTexImage3D''' war bis zu OpenGL 1.2 nur eine Erweiterung. Deswegen ist bei manchen Chipsätzen die Funktion nur als '''glTexImage3DEXT''' verfügbar.

Texturierung hat im Farbindexmodus keinen Effekt.

Das Texturbild kann in den selben Datenformaten vorliegen wie die Pixel bei [[glDrawPixels]] ausgenommen '''GL_STENCIL_INDEX''' und '''GL_DEPTH_COMPONENT'''. [[glPixelStore]] und [[glPixelTransfer]] beeinflussen das Texturebil in exakt der Art und Weise, wie sie auch [[glDrawPixels]] beeinflussen.

Eine Textur die 0 Pixel hoch oder breit ist, stellt die NULL-Textur dar. Wenn die NULL-Textur für die LOD-Stufe 0 spezifiziert wird entspricht das Verhalten dem bei deaktivierter Texturierung.

== Änderungen ==
Folgende Erweiterungen hat die Funktion erfahren:

=== Ab OpenGL Version 1.3 ===
[[GL_ARB_texture_cube_map]] definiert weitere 6 2D-Texture-Typen welche als ''target'' angegeben werden können.

 

== Fehlermeldungen ==

'''GL_INVALID_ENUM''' wird generiert wenn ''target'' nicht '''GL_TEXTURE_1D, GL_TEXTURE_2D''' oder '''GL_TEXTURE_3D''' ist. (entsprechend der benutzten Funktion) 

'''GL_INVALID_ENUM''' wird generiert wenn ''format'' ungültige Werte übergeben wurden. Akzeptiert werden alle Formatangaben außer '''GL_STENCIL_INDEX''' und '''GL_DEPTH_COMPONENT''' 

'''GL_INVALID_ENUM''' wird generiert wenn ''type'' keine gültige Typkonstante übergeben wurde. 

'''GL_INVALID_ENUM''' wird generiert wenn GL_BITMAP als ''type'' und '''GL_COLOR_INDEX nicht(!)''' als ''format'' angegeben wurde. 

'''GL_INVALID_VALUE''' wird generiert wenn ''level'' kleiner 0 oder größer ld(max) ist, wobei max der Rückgabewert von '''GL_MAX_TEXTURE_SIZE''' ist. (ld = Logarithmus Dualis = Basis 2). 

'''GL_INVALID_VALUE''' wird generiert wenn für ''components'' etwas anderes als ''1'', ''2'', ''3'' oder ''4'' angegeben wurde. 

'''GL_INVALID_VALUE''' wird generiert wenn ''width'', ''height'' bzw. ''depth'' (je nach Funktion) kleiner als 0 oder größer als 2 + '''GL_MAX_TEXTURE_SIZE''' ist, oder die Bedingung 2^k + 2 * (border) (k=Integerwerte) nich erfüllt. 

'''GL_INVALID_VALUE''' wenn ''border'' nicht ''0'' oder ''1'' ist. 

'''GL_INVALID_OPERATION''' wird generiert wenn eine '''glTexImage'''-Funktion in einem [[glBegin]]- und [[glEnd]]-Block aufgerufen wird. 

== Zugehörige Wertrückgaben ==
[[glGetTexImage]] 
[[glIsEnabled]] mit dem Token '''GL_TEXTURE_1D''', '''GL_TEXTURE_2D''' bzw. '''GL_TEXTURE_2D'''.

 

== Siehe auch ==
[[glTexEnv]], [[glTexGen]], [[glTexSubImage1D]], [[glTexSubImage2D]], [[glTexSubImage3D]], [[glTexParameter]], [[glTexCoord]]

[[Kategorie:GL|TexImage]]

Tutorial Lektion 4

2005-09-29T13:43:27Z

Lossy eX: /* Tapeten besorgen */

=Texturen, Tapeten und Ihre Tücken=

==Vorwort==
Hi Leute,
kaum zu glauben, aber wahr. Dieses Tutorial wird ausnahmsweise mal etwas mehr Erholung sein. Zumindest am Anfang. Was wir bisher erreicht haben ist ja alles schön, nett, praktisch und auch wichtig als Grundlage, aber wenn wir aus dem Fenster sehen, hören wir die Vöglein zwitschern. Hö? Wir hören was sehend? Es ist tiefste Nacht? Es muss Frühling sein ^__^. 
Und was macht man da Normalweise? Wir kramen herum und machen einen großen Frühjahrsputz die Schränke abziehen und alles schön sauber und ordentlich machen. Hach es dürstet mich richtig danach :D (means *würg*). 
Da unsere Tutorials bisher Gott sei Dank keine dreckige Sache waren, werden wir das mit dem Saubermachen einfach mal wegfallen lassen und uns nur mit einem Tapetenwechsel begnügen. In der Tat werden wir ab jetzt unseren Tutorials mehr grafisches Gewicht zumuten. Endlich haben die blauen Dreiecke ein Ende! Ich wünsche Euch viel Spaß ;).

==Crash-Kurs im Handwerk des Tapezierens==

===Ich verstehe nur "Renovierung"?===
Ich finde es immer wieder erschreckend Leute im Internet zu treffen, die nicht wissen was eine Textur ist ich meine, kennen keinen Kafka, keine Quantenphysik und wissen nicht einmal wo man die Systemsteuerung findet. Wie soll man solch einem Menschen erklären, was eine Textur ist?
Nun, am Besten fangen wir mit einem möglichst praktischen Beispiel an. Texturen sind wie Tapeten. Wir blicken nun zu unserer linken Seite. Der Autor erwartet nun ein DirectMind-Uplink zum Empfangen der visuellen Bildsignale. Dort haben wir eine schöne Wand quadratisch in ihrer Form. Wollen wir diese mit einer Tapete verzieren, gehen wir in den nächsten Baumarkt, suchen uns eine hübsche aus und bringen diese an der Wand an. Natürlich haben wir eine große geholt, und fangen nicht mit kleinen Streifen an. 
Wenn dann alles geklappt hat stehen wir vor dieser Wand und begutachten die Tapete in voller Pracht direkt vor uns. Wir haben die Wand texturiert. Streng genommen machen wir auch bei OpenGL nichts anderes, als ein Bild zu laden und dieses auf eine Fläche zu kleben. Wir werden uns jedoch auf Dauer nicht damit begnügen immer nur quadratische Flächen zu texturieren, sondern durchaus auch mal Dreiecke oder andere Vielecke. Und auch hat man uns Werkzeuge in die Hand gegeben, um diese Textur noch nachträglich an der Wand zu verschieben, ohne dass wir sie abnehmen müssen. Ist doch super. Es lebe die virtuelle Welt!

===Tapezieren leicht gemacht!===
Okay, wir haben lange genug um den heißen Brei herumgeredet und sollten uns nun endlich auf die Arbeit stürzen. Jeder von uns sollte in der Lage sein, ein Quadrat in OpenGL genau vor unserer Nase zu erzeugen.

[[Bild:Tutimg_lektion4_nonetex.gif|thumb|256px|left|Leeres Quadrat]]
Spätestens nun sollte die gleiche Frage aufkommen, wie bei jedem, der zum ersten Mal versucht, eine Tapete an die Wand zu bringen: "Wie rum muss ich das Ding da befestigen?". Immerhin müssen wir uns nicht um den Leim kümmern, das erledigt unsere Grafikkarte bzw. OpenGL für uns ;).

Wer noch nie 3D programmiert hat, wird im ersten Moment vielleicht fälschlicherweise denken, dass man die Position der Textur per Weltkoordinaten definiert. Das hätte allerdings fatale Folgen, sobald sich das Objekt im Raum bewegt. Wir müssten die Position jedes mal neu berechnen. Um eben dieses Problem zu umgehen, geht man in der 3D-Programmierung einen anderen Weg. Man vergibt einfach für jede Ecke eines Objektes eine Koordinate der Textur. OpenGL errechnet dann aus diesen Texturkoordinaten das Stück der Textur, das dann über das gesamt Objekt projiziert wird.

Die Rede ist hierbei vom so genannten UV-Mapping, welches vor allem bei Anfängern ein leichtes Gefühl des Unbehagens auslösen sollte. Es ist jedoch nur halb so wild, wenn man es halbwegs verstanden hat.

Betrachten wir gleich mal folgendes Bild und versuchen, uns in die Problematik hineinzuversetzen. Da Texturen unterschiedliche Größen haben können wurden so genannte Texturkoordinaten eingeführt. Es ist total egal, wie groß eine Textur ist, da sie nur einen Wertebereich von 0 bis 1 haben kann. Das heißt, wenn eine Textur 256x256 groß ist und eine andere 512x512, so haben beide eine maximale Größe von 1. Wir brauchen also das UV-Mapping nicht verändern, selbst wenn ein Objekt eine neue Textur mit anderer Größe erhält!

[[Bild:Tutimg_lektion4_texuv.gif|thumb|256px|right|Textur und leere Quadratfläche]]
Auf diesem Bild sehen wir zum einen die Textur, die wir verwenden wollen, zum anderen das Objekt, auf des "geklebt" werden soll. Natürlich sieht das in der Realität nicht so aus, ich denke aber diese Darstellung erleichtert das Verstehen ;).

Der untere linke Bereich der Textur trägt die Texturkoordinaten von (0 / 0) (d.h. u = 0 und v = 0), der obere linke Bereich (0 / 1), der obere rechte Teil (1 / 1) und schließlich der untere rechte Bereich (1 / 0). Das heißt, alles was wir machen müssen, um auf unser Objekt eine Textur zu kleben, ist dem jeweiligen Eckpunkt unseres Quadrates die entsprechende Texturkoordinate zuzuweisen. Wobei in diesem Sinne korrekt in Anführungszeichnen stehen sollte. Es gibt kein falsches UV-Mapping! Man kann tolle Sachen mit diesen Textur-Koordinaten machen und so z.B. auch eine Textur auf einem Objekt spiegeln. Dafür müssten wir in unserem Beispiel nur die linken und rechten UV-Mapping vertauschen und z.B. für den zweiten Punkt die Koordinaten von (1 / 1) setzen und dafür beim dritten (0/ 1). Genauso würden wir auch die unteren vertauschen. Die UV-Koordinaten, wie sie oben angegeben sind, bedeuten nur, dass die Textur, so wie sie in der Datei vorkommt, auch auf das Objekt geklebt wird. Selbstverständlich ist es auch möglich eine Textur gekachelt aufkleben indem Ihr Texturkoordinaten > 1 vergebt, ebenso wie es möglich ist nur Teile einer Textur zu verwenden. Spielt ruhig ein wenig damit herum, und schaut Euch an was passiert! Auf einige tolle Spielerei kommen wir zum Schluss noch mal zurück :).

[[Bild:Tutimg_lektion4_texuv_02.gif|thumb|256px|right|Textur und leere Quadratfläche]]
Sicherlich brennt es einigen von Euch nun bereits unter den Finger und Ihr fragt "wie kann ich denn die UV-Koordinaten den Eckpunkten der Fläche zuweisen?". Nun, zunächst funktioniert das ähnlich wie bei allen Dingen unter OpenGL. Wir setzen eine UV-Koordinate und solange wir nichts verändern, werden alle Punkte mit diesen Koordinaten versehen, bis wir andere Instruktionen geben. In unserem Fall müssen wir dies natürlich nach jedem Punkt machen. Die Funktion, die dafür verwendet wird heißt glTexCoord. Um also eine Textur auf unserem Quad zu projizieren, benötigen wir folgenden Code:
 
 
 
 
 
<pascal>glBegin(GL_QUADS);
glTexCoord2f(0,0); glVertex3f(-1,-1,0);
glTexCoord2f(0,1); glVertex3f(-1,1,0);
glTexCoord2f(1,1); glVertex3f(1,1,0);
glTexCoord2f(1,0); glVertex3f(1,-1,0);
glEnd;</pascal>

Das klappt doch wunderbar oder? Damit wir die Textur aber auch wirklich genießen können müssen wir Texturing mit Hilfe von glEnable und dem Token GL_TEXTURE_2D aktivieren. Mit Hilfe von glDisable und demselben Token ist es dann auch möglich Objekte zu Zeichnen, die über keine Texturen verfügen. Andernfalls würde nämlich die zuletzt gesetzte Textur und die Texturkoordinaten des letzten glTexCoord-Aufrufs verwendet werden.

Doch eine Kleinigkeit habe ich Euch nun doch noch verschwiegen! Wir müssen natürlich noch die richtige Textur setzen, damit OpenGL überhaupt weiß, was auf diesem Quad gezeichnet werden soll. Dies ist an sich noch relativ einfach, allerdings müssen wir diese auch noch in den Speicher bekommen, damit sie überhaupt zur Verfügung steht. Nun wird's theoretisch ;).

===Tapeten besorgen===
Ich werde jetzt nicht näher darauf eingehen, wie man Texturen erstellt, vielleicht gibt's ja einige Photoshop-Experten unter Euch, die Lust haben, einige Ihrer Tricks den anderen in Form eines Tutorials zu zeigen?

Zunächst einmal müssen wir die uns die eigentlichen Bilddaten besorgen. Wir werden das jetzt in diesem Tutorial mit [[SDL]] machen es gibt jedoch auch die möglichkeit die Daten manuell zu laden das könnt ihr hier nachlesen:
* [[TGA Bilder laden]]
Es gibt allerdings auch Textur loader die euch die nächsten Kapitel abnehmen und das alles für euch machen. glBitmap ist so ein Loader, mehr dazu erfahrt ihr in dem [[Glbitmap_loader|glBitmap]]-Artikel.

Bei SDL rufen wir nur [[IMG_Load]] auf und prüfen dann ob das Laden erfolgreich war. Hierbei sei erwähnt, dass es unter Linux zu Problemen führen kann, wenn ein Programm nicht aus einer Konsole heraus gestartet wurde. In diesem Fall sind die Pfade zu den Texturen nämlich falsch gesetzt und das Laden würde fehlschlagen. Abhilfe schafft man durch das Verwenden von absoluten Pfaden.

<pascal>var
tex : PSDL_Surface;
begin
tex := IMG_Load(ExtractFileDir(paramStr(0))+'/wiki.jpg');
if assigned(tex) then
begin</pascal>

Das war es dann auch schon wir haben die Textur im Speicher Doch was nun?

===Texturen richtig zubereitet===
Nachdem sich unsere Textur nun im Speicher des Computers befindet, geht es darum, daraus auch eine richtige Textur zu machen, damit wir diese in OpenGL anzeigen können. Bisher befinden sich ja nur die Rohdaten im Speicher! Hierfür teilen wir OpenGL mit, dass wir eine neue Textur erzeugen wollen:

<pascal>glGenTextures(1, TexID);</pascal>

TexID ist in diesem Fall ein gluInt, kann aber genauso gut ein Array davon sein, um mehrere Texturen zu erzeugen. Genau dafür wird dann auch der erste Parameter verwendet, der OpenGL mitteilt, wie viele Texturen in dieses Array geschrieben werden sollen. In unserem Fall ist dies eben nur ein Element. Aber was ist ist das für ein Wert in TexID? OpenGL verwaltet die Texturen anhand eindeutiger Namen. glGenTextures ermittelt einen oder mehrere bisher ungenutzte Namen und schreibt diese in TexID. Durch TexId können wir unsere Textur ab sofort also eindeutig identifizieren.

<pascal>glBindTexture(GL_TEXTURE_2D, @TexID);</pascal>

Wir teilen OpenGL mit, dass sich von nun an alle Änderungen und Anweisungen, die sich auf Texturen beziehen auf die Textur TexID beziehen. 
Die folgenden beiden Zeilen sind zwar nicht wirklich nötig, um eine Textur zu erzeugen aber glaubt mir, sie werden ansonsten potthässlich aussehen. Wir werden in einem anderen Tutorial näher auf dessen Bedeutung eingehen, nämlich den so genannten Textur-Filtern. Die momentane Einstellung ist leicht rechenlastig, jedoch auch von recht guter Qualität. Ihr werdet anfangs keine Probleme mit der Geschwindigkeit bekommen ;).

<pascal>glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);</pascal>

Zu guter letzt werden müssen wir die Bildinformationen in unserem TBitmap-Objekt irgendwie OpenGL mitteilen. Dies übernimmt die Funktion glTexImage2D:

<pascal>glTexImage2D(GL_TEXTURE_2D, 0, 3, tex^.w, tex^.h,0, GL_RGB, GL_UNSIGNED_BYTE, tex^.pixels);</pascal>

Der erste Parameter steht für den Typ der Textur. Die Dimension des Typs muss hier mit der des Befehls übereinstimmen (glTexImage2D erlaubt also nur GL_TEXTURE_2D). Der zweite Parameter gibt die Nummer des Level of Detail (LoD) an. Für den Anfang reicht hier der Level 0. Der dritte Parameter gibt an, wie viele Farbkomponenten in dem Bild enthalten sind (1-4). Die zwei folgenden Parameter übermitteln OpenGL die Breite und die Höhe des Bildes. Der sechste Parameter gibt die Breite des Rahmens an. Im siebenten Parameter wird das Format verlangt, in welcher Reihenfolge die einzelnen Farbkomponenten gespeichert sind. Bei Bitmaps ist das immer die Reihenfolge Blau, Grün, Rot. Der Typ, der einzelnen Farbwerte muss im 8. Parameter angegeben werden. Letztendlich müssen im 9. Parameter nur noch die Bildpunkte selbst übergeben werden. 
Mit Hilfe dieser Funktion sollten nur Texturen der Größe 2^n x 2^n erzeugt werden. Andernfalls werdet Ihr die Textur nicht in Ihrer vollen Schönheit, d.h. überhaupt nicht betrachten können. Es gibt jedoch Möglichkeiten Texturen zu laden, die nicht die Größe 2^n entsprechen. Die Funktion [[gluBuild2DMipmaps]] bildet hier beispielsweise eine Alternative. 
Das war es auch schon. Wer mehr über die einzelnen Parameter und Befehle wissen will ist herzlich eingeladen in unserem Wiki umherzustöbern und sein Wissen zu erweitern um später selbst vielleicht einmal ein paar Artikel im Wiki zu veröffentlichen.

Die Daten im Arbeitsspeicher brauchen wir nun nicht mehr. Bei SDL geben wir sie so frei:

<pascal>SDL_FreeSurface(tex);</pascal>

Fassen wir das ganze bei SDL nochmal zusammen:
<pascal>var
tex : PSDL_Surface;
begin
tex := IMG_Load('./wiki.jpg');
if assigned(tex) then
begin
glGenTextures(1, @texture);
glBindTexture(GL_TEXTURE_2D, texture);

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);

// Achtung! Einige Bildformate erwarten statt GL_RGB, GL_BGR. Diese Konstante fehlt in den Standard-Headern
glTexImage2D(GL_TEXTURE_2D, 0, 3, tex^.w, tex^.h,0, GL_RGB, GL_UNSIGNED_BYTE, tex^.pixels);

SDL_FreeSurface(tex);
end;</pascal>

Nun kommt aber bitte nicht auf die Idee die Textur in euerer Hauptschleife wieder und wieder neu zu laden. Es reicht die Textur einmal zu laden und von da an steht sie einem solange zur Verfügung bis man gedenkt sie wieder aus dem Grafikkartenspeicher zu entfernen. 
Das übernimmt die Funktion [[glDeleteTextures]]. glDeleteTextures funktioniert ähnlich wie [[glGenTextures]], nur dass die Texturen entfernt werden. Der erste Parameter gibt die Anzahl der zu löschenden Texturen an, während der zweite Parameter den Namen der Textur bzw. ein Array der Namen mehrerer Texturen verlangt. 
Das ist doch für den Anfang nicht schlecht. Ihr solltet nun in der Lage sein, zumindest einfache Objekte zu texturieren. Das ist eigentlich das gesamte Grundprinzip. Natürlich gestaltet es sich schwieriger, ein komplexeres Objekt mit UV-Koordinaten zu versehen, als ein Quad, aber an der Technik selbst ändert sich nur wenig. Wir werden nun einige Spielereien zeigen, die man mit Texturen machen kann, damit Ihr ein Gefühl dafür bekommt, wie man ein Problem elegant umschiffen kann!

==Die Rückkehr der Matrizen==
===Texturen===
Tja und da ich ein Sadist bin [Anm. des Lektors: Ooooh ja!] werden wir uns nun nochmals den Matrizen zuwenden! Dachtet Ihr etwa, Ihr seid die Dinger schon wieder los? Ich habe Euch im letzten Tutorial angedroht, dass es nicht nur eine Matrix für die "Welt" gibt, sondern auch noch weitere. Unter anderem eben auch für Texturen.

Die Texturmatrix funktioniert streng genommen genauso wie auch die Worldmatrix. Solange wir sie aktiv haben, wird sie von jedem Matrixbefehl berücksichtigt! Einziger wirklicher Unterschied ist, dass sie nicht die Position oder die Form eines Objektes beeinflusst, sondern nur das Rendern der Textur selbst. Hö? Was meint der Kerl bloß damit?! Nun stellt Euch vor, Ihr habt ein Quad und wollt darauf eine Textur bewegen, so dass es aussieht, als würde sie sich von rechts nach links bewegen! Was wir jedoch nicht wollen ist, dass sich das Objekt bewegt, sondern nur, das was darauf zu sehen ist. Stellt Euch vor, Ihr schaut aus einem Fenster und seht einen wolkigen Himmel, der Wind bläst die Wolken von einer Himmelsrichtung zur anderen. Ihr könntet so z.B. das Fenster als Quad nehmen und dann die Textur darauf zeichnen und glaubt mir, die Illusion würde auffliegen, sobald sich das Fenster mit der Textur bewegen soll. Nein, stattdessen bewegen wir nur die Textur auf dem Quad und zwar ohne das UV-Mapping anzutasten. Wir beeinflussen einfach die Art, wie die Textur auf das Quad projiziert werden soll. Dafür dient die Texturmatrix.

Stellen wir uns mal vor, dass wir unser Quad zeichnen und eine Variable X haben, die wir bei jedem Rendervorgang leicht erhöhen. Dies soll die Bewegung darstellen. Alles was wir nun tun müssen ist, die Texturmatrix entsprechend anzupassen.

<pascal>
glMatrixMode(GL_TEXTURE);
glLoadIdentity;
glTranslatef(x,0,0);
glMatrixMode(GL_MODELVIEW);
</pascal>

Das ist bereits der ganze Spuk! Wir teilen OpenGL durch glMatrixMode mit, dass sich ab sofort alle Veränderungen der Matrix nur noch auf die Texturmatrix beziehen sollen. Danach setzen wir diese sofort auf ihren Standardwert zurück. Der Grund hierfür sollte Euch von der Worldmatrix noch in Erinnerung sein. Anschließend ändern wir die Position der Textur auf dem Quad. Würden wir X jedes Mal um 1 Einheit erhöhen, so würde diese Operation ohne Effekt bleiben, da wir die Textur immer um ihre ganze Größe nach links projizieren würden. Würden wir X z.B. bei jedem Vorgang um 0.01 erhöhen, so würde die Textur sich langsam von rechts nach links bewegen. Ich denke, Ihr könnt bereits erahnen, welche Parameter dafür verwendet werden, um eine Textur von unten nach oben zu bewegen ;).

Wichtig ist auf jeden Fall, dass Ihr anschließend mit glMatrixMode wieder die Worldmatrix aktiviert, da sonst alle weiteren Matrixmanipulationen auf die Texturmatrix angewandt werden würden. Denkt nicht, dass die Texturmatrix damit deaktiviert wird! Ab sofort wird auf das Objekt sowohl die World- als auch die Texturmatrix angewendet. Seht Ihr? Das Ganze ist doch gar nicht ganz so schlimm. Es versteht sich auch von selbst, dass Ihr glRotate und glScale ebenfalls darauf anwenden könnt, natürlich auch nach den gleichen Regeln auf die Worldmatrix. Experimentiert am Besten auch etwas mit diesen Einstellungen herum!

==Wir tapezieren unsere Welt mal anders==
===Am Fließband===
Eigentlich sollte an dieser Stelle bereits Schluss sein. Ich wurde allerdings während des Schreibens des Tutorials nach einer Sache gefragt und möchte die Chance nutzen, diese Frage zu beantworten und gleichzeitig das angewandte Wissen der vorhergehenden Lektion etwas zu vertiefen.

Wir haben folgende Problematik: Wir brauchen eine animierte Textur auf einem Objekt. Dies könnte z.B. eine bewegte Lavamasse sein oder irgendwas Glibbriges, was am Boden wabbelt. Oder eben in unserem Fall eine Folge von Zahlen, die wie ein Countdown aufgelistet werden. Sicherlich könnte nun jemand von Euch auf die Idee kommen, viele einzelne Texturen zu laden und diese in einem Array zu speichern. Dies mag auch durchaus sinnvoll sein nicht jedoch, wenn es sich um kleine Bilder handelt (bei uns z.B. 32x32 Pixel).

Auch bei Bitmap-Fonts würde man nie auf die Idee kommen, für jeden Buchstaben eine einzelne Textur zu verwenden, sondern vielmehr eine Textur mit allen Buchstaben darauf erstellen, da dies u.a. den Ladevorgang erheblich beschleunigt! Klingt einleuchtend oder? Aber wie sollen wir dem Programm mitteilen, welcher Teil der Textur auf welche "Ecke" geklebt werden soll? Nun auch hierbei heißt des Lösungs Rätsel [Anm. des Lektors: Er macht's schon wieder. Herrlich] UV-Mapping!

[[Bild:Tutimg_lektion4_numbers.gif]]

Dies ist unsere Textur! Sie hat eine Gesamtlänge von 256x32 Bildpunkten und wie man leicht sehen kann, soll sie aus 8 Teilstücken bestehen. Die V-Koordinate können wir in diesem Fall getrost vernachlässigen, weil sie in diesem Fall immer konstant sein wird, weil wir die ganze Höhe der Textur verwenden wollen. Sie wäre nur dann interessant, wenn wir z.B. noch eine zweite Reihe darunter setzen würden. Ich denke jedoch, dass jemand der das gleich folgende verstanden hat, sofort eine Lösung für diese "Problematik" finden wird ;).

[[Bild:Tutimg_lektion4_numbers2.gif]]

Wichtig ist, dass wir uns bewusst werden, dass eine Textur beim UV-Mapping immer von 0 bis 1 reicht. Um nun die einzelnen Bilder aus einer Textur auf ein Objekt zu setzen, müssen wir nichts anderes machen, als zu errechnen, an welcher Stelle ein Bild anfängt und wo es aufhört. Nur zur Kontrolle, damit es auch jeder begreift: Würden wir nur die erste Hälfte der Textur auf ein Objekt kleben, so müsste unsere U-Koordinate von 0 bis 0.5 reichen. Die zweite Hälfte hingegen von 0.5 - 1.0. Soweit klingt es doch noch alles logisch oder?

Genauso müssen wir auch vorgehen, wenn wir einzelne Bilder auf einem Quad abbilden wollen. In unserem Fall müsste die U-Koordinate von 0 bis 1/8 reichen. Das zweite Bildchen hingegen von 1/8 bis 2/8 etc. D.h. wir wissen, dass jedes unserer Bilder 1/8 "Einheiten" lang ist! Und somit haben wir ja bereits eine Lösung für unser Problem. Um das ganze dynamisch auszudrücken: Wir brauchen nur die Größe der Textur durch die Anzahl der Bilder zu teilen. Bevor jemand einen Denkfehler macht: Es ist hierbei ganz egal, wie groß die Textur wirklich ist (hier 256x32 Pixel). Dank OpenGL errechnen wir das UV-Mapping ja in absoluten Größen.
Nun der Code:

<pascal>
PicLength:= 1 / PicCount;
PicPos:=Round(Pic)*PicLength;
glBegin(GL_QUADS);
glTexCoord2f(PicPos, 1); glVertex3f(-1,1,0);
glTexCoord2f(PicPos + PicLength, 1); glVertex3f(1,1,0);
glTexCoord2f(PicPos + PicLength, 0); glVertex3f(1,-1,0);
glTexCoord2f(PicPos, 0); glVertex3f(-1,-1,0);
glEnd;

Pic:=Pic + MovementValue;
</pascal>

Pic ist in diesem Fall eine Variable vom Typ Single, die langsam erhöht wird. Wir runden den Wert hier, so dass beim Erreichen eines jeden ganzzahligen Wertes das nächste Bild angezeigt wird. Wir multiplizieren die Nummer des anzuzeigenden Bildes mit der Breite eines Bildes, um die Anfangsposition zu erhalten und addieren dann noch eine volle Bildbreite dazu, um die Endposition zu erhalten. Hört sich gewaltig gefährlich an, liegt aber mehr an meinem mangelnden Ausdruck als an der Schwierigkeit dieses Problems ;).

Im Sample werdet Ihr noch sehen, was passiert, wenn man den Wert nicht rundet. Man erhält in diesem Fall einen "flüssigen" Bildübergang. Letztendlich gibt es viele Möglichkeiten, solche Ideen zu implementieren. Nehmt dies einfach als kleineren Gedankenschub und vor allem: Werdet Euch bewusst, was genau dort passiert! Eine Menge toller Dinge lassen sich mit einem guten UV-Mapping erzielen.
Wer noch etwas umherexperimentieren will kann gern versuchen selbes Ziel mit Hilfe der Texturenmatrix zu erreichen. Die Lösung ist verblüffend einfach.

===Terraforming mal anders===
Relativ lange habe ich nach einem guten Beispiel für folgende Problematik gesucht: Ich wollte Euch die UV-Koordinaten etwas näher bringen und Euch zeigen, wofür man sie einsetzen kann. Irgendwie wollte mir nichts Interessantes aus meinem Kopf entspringen bis ich irgendwann in einigen alten Programmen von mir rumgewühlt habe und einen alten Terrainrenderer von mir fand. Schon war die Idee da! Wir schreiben ein kleines Programm, das eine ganz simple, unoptimierte Landschaft rendern wird. Das hört sich sicherlich Anfangs relativ gewaltig an, mit etwas Verständnis für die oberen Probleme sollte dies jedoch kein Problem für Euch sein.

Zuvor allerdings ein paar Gedankenspiele. Zunächst widmen wir uns kurz der Texturiering. Wie würde die simpelste Landschaft aussehen, die wir uns vorstellen können? Richtig! Sie wäre ein einfaches, flach liegendes Quadrat mit einer Textur überzogen, der Wand aus unserem ersten Versuch sehr ähnlich! Dies hat jedoch einen klitzekleinen Nachteil: Wir könnten keine Höhenstufen einbauen und ohne die wäre die Landschaft nur halb so realistisch. Denn wir wollen versuchen, folgende Szene zu zaubern:

[[Bild:Tutimg_lektion4_landscape.gif|thumb|256px|none|eine Lanschaft]]
Um allerdings Höhen einzubinden, müssen wir die Landschaft in viele kleinen Quads unterteilen, die natürlich an Ihren Eckpunkten unterschiedliche Höhen haben, sich jedoch jeweils einige Punkte teilen. Es versteht sich von selbst, dass diese die gleiche Höhe haben müssen, damit die Landschaft auch durchgängig ist und nicht irgendwelche mysteriösen Löcher darauf erscheinen ;).
Auf folgendem Screenshot kann man dies deutlich erkennen:

[[Bild:Tutimg_lektion4_landwire.gif|thumb|256px|left|Gitter Ansicht der Landschaft]]
Technisch gesehen ist das Ganze einfach zu realisieren, da wir nur begreifen müssen, dass alle Quads nebeneinander liegen und sich - bis auf die äußeren alle einen Eckpunkt teilen. Nun müssen wir beim Rendern jeden Eckpunkt nur noch vom angrenzenden Quad lesen und fertig ist die Landschaft. Ich will da nicht näher drauf eingehen, weil es sich hier nicht um ein Tutorial zur Landschaftsgestaltung handelt. Der Code sollte sich eigentlich von selbst erklären.

Vielmehr sollten wir uns einer anderen Problematik widmen! Nämlich wie zur Hölle texturieren wir die Landschaft so, dass sie nicht zur Marke "augenfeindlich" gehört?

[[Bild:Tutimg_lektion4_landscapeerror.gif|thumb|256px|right|wiederkehrende Landschaft]]
Wenn Euer erster Gedanke dabei "Boah, cool!" ist, dann gibt's eins auf die Finger! Das wollen wir doch nicht wie sieht den die Landschaft aus. Eine immer wiederkehrende Landschaft -> man erkennt sofort, dass wir hierbei auf jedes Quad die gleiche Textur geklebt haben. Doch wie schaffen wir es nun, dass wir eine Textur über alle Quads ziehen, so dass die ganze Landschaft mit einer Textur überzogen ist anstatt nur über ein einzelnes Feld?
Nun, des Lösungs Geheimnis [Anm. des Lektors: Ich liebe ihn dafür! Andere lösen Rätsel. Er geheimnist Lösungen] sind eben unsere UV-Koordinaten und einige pfiffige Köpfe unter Euch sollten bereits einen ersten Verdacht haben. Denn die erste Idee sollte es sein, den linken unteren Punkt eine UV-Koordinate von (0/0) zu geben und der rechten oberen (1/1).
Alles was wir nun also machen müssen, ist, uns die entsprechenden UV-Koordinaten für die Quads dazwischen auszurechnen und sie dann den Punkten zuzuweisen. Dafür benötigen wir zunächst die Breite eines Quads. Mit normaler Logik lässt sich folgende Aussage aufstellen.
<pascal>
qw:=1 / XCount
qh:=1 / YCount;
</pascal>
Ein Quad benötigt die Länge von 1 durch die Anzahl der Quads in einer Reihe oder Spalte. Genauso verhält es sich auch mit der Höhe. Nun brauchen wir beim Rendern nur noch dem jeweiligen Quad in einer For-Schleife die entsprechende Koordinate zuzuweisen:
<pascal>
U:=1 / XCount;
V:=1 / YCount;

for y:=0 to YCount-1 do
begin
glPushMatrix;
for x:=0 to XCount-1 do
begin
glBegin(GL_QUADS);
glTexCoord2f(U*x, V*(y+1));
glVertex3f(0, Map[x,y+1], 0);
glTexCoord2f(U*x, V*y);
glVertex3f(0, Map[x,y], 1);
glTexCoord2f(U*(x+1), V*y);
glVertex3f(1, Map[x+1,y], 1);
glTexCoord2f(U*(x+1), V*(y+1));
glVertex3f(1, Map[x+1,y+1], 0);
glEnd;
glTranslatef(1,0,0);
end;
glPopMatrix;
glTranslatef(0,0,-1);
end;
</pascal>
Das sieht nach einem herben Stück Arbeit aus oder? Aber wenn Ihr Euch das ganze mal aufzeichnet und im Kopf durchspielt, wird der Groschen fallen. Denkt mal etwas darüber nach! Wenn es dann doch noch Probleme mit dem Verständnis geben sollte, wird das nächste Kapitel hoffentlich jedes Missverständnis aus dem Wege räumen ;).

==Nachwort==
Okay ich hoffe Ihr fühlt Euch nach der Abarbeitung dieses Tutorials genauso wie ich, nachdem ich es für Euch geschrieben habe nämlich elend. Irgendwie wurde das immer mehr und ich sagte mir immer wieder "nein, dass ist nicht genug. Das muss genauer und anschaulicher werden". Dies ist auch der Grund dafür, warum dieses eines der größten Tutorials mit den meisten Bildern usw geworden ist. Erst sollte es noch etwas mehr werden und dann in mehrere Tutorials aufgespaltet werden, allerdings glaube ich mit diesem Tutorial einen guten Mittelweg zwischen Information und Totlabern gefunden zu haben. Lasst es mich wissen, wie Ihr dazu steht! 
Und bevor die Kritiker gleich wieder alle aus Ihren Löchern kommen und mir sagen, dass einige Bereich einfach als gegeben angenommen werden; denen sei nur gesagt, dass wir u.a. auch versuchen Rücksicht auf Leute zu nehmen, die noch nie 3D programmiert haben und vielleicht Eurem Wissen nicht standhalten können. Daher halte ich es hier für wichtiger, Grundlagen wie UV-Koordinaten und den Einsatz von Texturen zu erklären, als ihnen tausende von Zeilen um die Ohren zu hauen, wie sie die Bytes von der Festplatte in den Arbeitsspeicher laden können. Um jedoch keine Wissenslöcher offen zu lassen: Ihr könnt Euch sicher sein, dass spezielle Tutorials folgen werden, die sich speziell mit dem Laden verschiedener Formate beschäftigen und die genaue Interna (was im Hintergrund abläuft) zu erklären versuchen. Auch das Alpha Blending wird hier mehr zu "Show-Zwecken" verwendet und wird zusammen mit dem Z-Buffer genauer erklärt werden! 
Also bloß keine falsche Hektik! Ich weiß ... einige von Euch sind recht ungeduldig, aber ständiges Nachfragen und Drängeln führt zu nichts. Versucht Fragen lieber ins Forum zu setzen, damit dort ein wenig Leben reinkommt. Denn wenn es dort belebter wird, kommen auch schneller neue Leute und vielleicht sind ja auch welche dabei, die dann das DGL-Team entlasten können. Also nutzt bitte das Forum, anstatt andauernd per ICQ oder Mail irgendwelche Fragen zu stellen! Die Antwort wird auch nicht viel länger auf sich warten lassen. Im Forum jedoch ist alles dokumentiert und auch anderen zugänglich, so dass ich nicht die gleiche Frage bis zu 5 mal am Tag beantworten muss. Sorry aber das geht einem auf die Nerven und vor allem auf die Zeit ;). Schließlich sind wir keine Maschinen sondern Menschen, die auch ein privates Leben haben ^__-.

Glaubt uns, wir investieren einen sehr großen Teil unserer Zeit in dieses Projekt und solch ein Tutorial lässt sich nicht binnen weniger Tage anfertigen. Jeder der so etwas bereits einmal gemacht hat, wird wissen was ich meine. Es muss ein Konzept her, es müssen Samples geschrieben, Screenshots gemacht werden und ein halbwegs verständlicher Text her. Und nichtsdestotrotz soll es am Ende auch noch passen, einem möglichst großen Publikum Wissen vermitteln, am Besten von Schreib- und Sprachfehlern befreit und in einem halbwegs ansehnlichen HTML-Dokument präsentiert werden. Ein langer Weg ;).
Okay, in diesem Sinne, bis bald ;)!
btw: Vielen Dank an Magellan für die Bereitstellung und Integration seiner besonderen Lernleistung.

Euer 
'''Phobeus'''

{{TUTORIAL_NAVIGATION|[[Tutorial_lektion3]]|[[Tutorial_lektion5]]}}

[[Kategorie:Tutorial|Lektion4]]

Text ausgeben

2005-09-12T10:13:56Z

Lossy eX: /* Farbe */

='''Anleitung'''- Wie gebe ich mit OpenGL Text aus.=

Allen Möglichkeiten gemein ist das die Buchstaben in [[Liste]]n gespeichert werden um so per [[glCallLists]] den Text ausgeben zu können.

== Buchstaben aus Pixeln ==

Die primitivste Art Buchtaben auszugeben besteht darin einfach [[glBitmap]] aufzurufen.

Falls das Betriebssystem Windows ist, kann mit [[wglUseFontBitmaps]] aus einer Windows Schrift [[glBitmap]] Befehle generiert, und in einer [[Liste]] abgespeichert werden.

=== Position festlegen ===
Die Position der Ausgabe erfolgt durch [[glRasterPos]], oder besser falls verfügbar durch [[glWindowPos]].

=== Farbe ===
Die [[Farbe]] der Schrift wird zum Zeitpunkt des letzen [[glColor]] Aufrufes festgelegt.

 

== 3D Schriften mit Windows ==

Per [[wglUseFontOutlines]] wird aus einer Windows Schrift für jeden Buchstaben eine Liste erstellt, welche die entsprechenden Polygone enthält.

{|
|+Das kann dann so aussehen:
|[[Bild:WglUseFontOutlines Beispiel.png]]
|}
 

== Schrift aus Texturen ==
(Sogenannte Bitmapfonts)

Benötigt wird für diese Technik eine Textur, auf dem alle 256 Zeichen untergebracht sind. Die Anordnung der Zeichen ist prinzipiell beliebig, nur sollte man dies so tun, dass man nachher leicht die Position der einzelnen Zeichen auf der Textur herausfindet. (z.B. indem man die Zeichen als 16x16 Zeichen Matrix anordnet).

Zusätzliche Informationen über die Breite der Buchstaben, ermöglicht es gleich große Zwischenräume zwischen den einzenen Buchstaben zu haben.
Entsprechende [[Tool]]s erleichtern die Erstellung solcher Texturen.

Die Textur [[Matrix]] wird dann mit [[glScale]] und [[glTranslate]] so manipuliert, dass das mit [[glBegin]], [[glTexCoord]] und [[glVertex]] gezeichnete Rechteck immer nur ein Zeichen enthält.
('''glScale''' ist eigentlich nicht nötig, da ein mit [[glTexCoord]] abgesteckter Texturabschnitt automatisch auf die Größe des unterligenden Polygons (gezeichnet mit [[glBegin]]-[[glEnd]] und [[glVertex]]) gedehnt wird.)

Um nur die Buchstaben ohne den Hintergrund (der Textur) zu sehen sollte dieser mittels [[Blenden|Blending]] oder (wenn man scharfe Kanten möchte) mittels [[glAlphaFunc]] heraus gefiltert werden.

=== Position ===
Das '''Wo''' wird über die Koordinaten der [[Eckpunkt|Eckpunkte]] des unterliegenden Polygons geregelt. Welches Zeichen tatsächlich ausgegeben wird, bestimmen die Texturkoordinaten (übergeben mit [[glTexCoord]]).

=== Farbe ===
Wenn man eine einfarbige Schrift möchte, so empfiehlt es sich die Textur komplett Weiß zu machen, damit man mit [[glColor]] die Textur einfärben kann und damit alle Farben anzeigen lassen kann. Dies kann beispielsweise auch mittels
[[glPixelTransfer]]f( GL_RED_BIAS, 1.0 );
[[glPixelTransfer]]f( GL_GREEN_BIAS, 1.0 );
[[glPixelTransfer]]f( GL_BLUE_BIAS, 1.0 );
vor dem Erstellen der Textur erfolgen.
Der eigentliche Zeichensatz sollte (sofern man einfarbige Schrift möchte) nur den Alpha-Kanal beeinflussen, was beispielsweise mittels
[[gluBuild2DMipmaps]]( GL_TEXTURE_2D, 2, Texturbreite, Texturhoehe, GL_ALPHA, GL_UNSIGNED_BYTE, Pixel );
gemacht werden kann. Zu beachten ist hier, dass 2 oder 4 Farbkomponenten benötigt werden damit die Textur Alphawerte erhält.

Falls der Text nicht im 3 dimensionalen Raum angezeigt werden soll, empfiehlt es sich den [[Tiefentest]] zu deaktivieren und die Projektions Matrix mit [[gluOrtho2D]] neu einzustellen.

 

==Siehe auch==
[[glBegin]], [[glColor]], [[glScale]], [[glTranslate]], [[glTexCoord]], [[glVertex]]

[[Kategorie:Anleitung]]

Diskussion:Low/High-Level

2005-07-07T14:40:46Z

Lossy eX:

Ich finde die Beispiele ein wenig unpassend. Laut der Definition wäre der Code für Highlevel eher für Lowlevel. Wobei ich persönlich beide Codes nach Highlevel einordnen würde, da beide Methoden nun mal Klassen benutzen. Bei dem "Highlevel" Beispiel befinden sich nur alle Parameter im Konstruktor und bei Lowlevel hat man sich sogar die Mühe gemacht properties dafür zu implementieren!?

Oder um es mal an einem Beispiel anzubringen. Im Vergleich glBitmap.pas und die Textures.pas. Die Textures ist eindeutig Lowlevel. Eine Methode zum Laden von Texturen. Die glBitmap ist dort eindeutig Highlevel. Die Textures mag an einigen Stellen schneller sein, dafür '''fehlt''' ihr aber Flexibilität. Speiziell beim Laden und der Handhabung der Texturen. Sie kann nur das was wofür sie geschrieben wurden. Datei rein und TExturid raus. Änderungen können recht leicht nachgepflegt werden. Das ist bei der glBitmap nicht ganz so einfach. Da muss man schon aufpassen, dass es in das System passt. Ich finde Lowlevel ist eher unflexibel, da es nur auf bestimmte Aufgabengebiete zugeschnitten wird wärend Highlevel nun mal viele Verwendungszwecke zur Verfügung stellt. Highlevel geht eher abstrakt an die Aufgaben herran.

Glbitmap loader

2005-07-05T11:39:09Z

Lossy eX:

= glBitmap - Texturenloader =

== Warum das Ganze und wo kann ich sie finden? ==

Früher benutzte ich die glBMP, da sie so "schön" Objekt orientiert war. Leider hatte mein Grafiktreiber zu der Zeit einen Fehler bei der Auswahl des Texturformates. So führte es dazu, dass sobald ich eine Textur mit Alphakanal und dem Standard Texturformat an OpenGL übergab, er als Farbtiefe 16 Bit verwendete. Wenn ich ein Foto genommen hätte wäre mir das wahrscheinlich gar nicht aufgefallen aber dummerweise (oder glücklicherweise) hatte ich aber eine Textur mit einem weichem Farbverlauf. Wie zu erwarten war sah das natürlich alles ziemlich schrecklich aus. Bis dahin kann der Loader ja nichts dafür wenn in einem Treiber ein Fehler existiert. Nur das kuriose an dem Ganzen war, dass meine Textur in Wirklichkeit gar keinen Alphakanal haben durfte. Also habe ich mich auf die Suche nach der Ursache gemacht und bin auch prompt fündig geworden. Der Loader war der Meinung er müsse alle Texturen mit einem Alphakanal versehen ungeachtet der Tatsache ob sie nun einen hatten oder eben nicht. Das ist natürlich eine Sache mit der ich mich nicht abfinden wollte. Kurz darauf begann ich also eine Ableitung der glBMP Texturenklasse zu erstellen und dort musste ich mit Schrecken feststellen, dass die Rechte in der Klasse so ungünstig vergeben wurden, dass ich keine andere Wahl gehabt hätte als direkt die Unit zu editieren. Da ich ungern externe Quellen editiere habe ich für mich die andere Alternative entschieden. Was dabei rausgekommen ist sieht man ja jetzt.

Gefunden werden kann sie entweder im DGL-SDK oder auf der [http://www.dev-center.de/index.php?cat=header&file=glbitmap Webseite] von [[Benutzer:Lossy eX|Lossy eX]].

== Allgemeines und Features ==

Dieser Artikel geht nicht darauf ein was zu tun ist um in OpenGL eine Textur darstellen zu können. In ihm werde ich lediglich darauf eingehen was man tun kann und muss um mittels der glBitmap eine Textur laden zu können. Außerdem werden die verfügbaren Einstellungen und ihre Wirkungen erklärt. Für alles andere wäre es besser das [[Tutorial_lektion4|Tutorial über Texturen]] durchzulesen.

Der wichtigste Unterschied zu den bestehenden Loadern bringe ich gleich einmal als erstes. Die glBitmap legt die Texturen anders im Speicher ab. Um zwar im speziellen meine ich damit die 2D Texturen. Bei bestehenden Loadern werden diese Texturen mit der untersten Zeile zu erst im Speicher abgelegt. In der glBitmap werden sie aber mit der obersten Zeile zu erst abgelegt. Man könnte auch sagen, dass sie bei den bestehenden Loadern auf dem Kopf stehen. Beide Möglichkeiten funktionieren und sind korrekt. Das Einzige was sich in diesem Zusammenhang ändert ist die [[glTexCoord| Adressierung der Texturen]]. Sie müssen entsprechend geändert werden. Sollte das nicht möglich sein so besteht mit der Methode FlipVert die Möglichkeit die Textur zu spiegeln. Näheres in Abschnitt [[Glbitmap_loader#Texturen_konfigurieren|Texturen konfigurieren]]. Im Normalfall sollte das andere Verhalten nicht zu Problemen führen sondern die Arbeit damit vereinfachen und verständlicher gestalten.

Die glBitmap holt sich ihre Daten ausschließlich aus Streams. Das zugrundeliegende Format wird automatisch anhand des Inhaltes der Daten ausgewählt. Es besteht also kein Notwendigkeit daran, dass der Entwickler wissen muss um welches Format es sich in Wirklichkeit handelt.

=== unterstütze Formate ===

* Windows Bitmaps (*.bmp) Wird Automatisch auf 24 Bit gesetzt sollte es kleiner sein.
* JPEG (*.jpg)
* TARGA (*.tga) komprimiert und unkomprimiert, 24 und 32 Bit. Ursprung unten links oder oben links
* Portable Network Graphics (*.png) 24 Bit mit oder ohne Alphakanal. Es wird eine zusätzliche Bibliothek benötigt.
Es besteht auch die Möglichkeit die Bilddaten dynamisch generieren zu lassen oder sie aus einer Instanz der Klasse TBitmap zu laden. Diese Instanz muss dann aber als Pixelformat 24 oder 32 Bit haben.

Um PNGs laden zu können muss eine externe Bibliothek namens [http://pngdelphi.sourceforge.net/ PNGImage] eingebunden und das Define pngimage hinzugefügt werden. Alternativ dazu kann das Define auch in der glBitmap auskommentiert werden.

== Texturen laden ==

Das Laden von Texturen kann auf 2 Weg geschehen. Bei Beiden ist aber zu beachten, dass OpenGL richtig initialisiert worden sein muss bevor man eine Textur erzeugen kann. Was noch sehr wichtig ist. Es sollte niemals eine Textur bei jedem Rendervorgang angelegt und freigegeben werden! Es ist viel effektiver, wenn man die Textur zu beginn lädt und so lange im Speicher behält bis sie nicht mehr benötigt wird. Wenn man sie erst später benötigt, dann kann man sie auch später noch nachladen aber auch dann sollte sie so lange wie nötig existieren.

=== Procedural ===

Hierbei genügt der Aufruf einer einzelnen Methode um eine Textur zu laden und diese an OpenGL zu übergeben. Allerdings auf Grund der Einfachheit steht nur das Laden aus Dateien oder Ressourcen zur Verfügung. Zusätzliche Funktionalität können dabei nicht benutzt werden. Generell empfehle ich immer die Objekt orientierte Variante.

var
Texture: TGLuint;

LoadTexture('myTex\Wall.bmp', Texture, False); // Datei laden

Damit wird die Datei Wall.bmp geladen und die TextureID wird in die Variable Texture geschrieben. Wenn die Textur dann benötigt wird, dann muss man diese entsprechend mit [[glBindTexture]] binden und das benötigte Texturtarget mit [[glEnable]] aktivieren. Das Target ist üblicherweise GL_TEXTURE_2D. Wenn die Textur nicht mehr benötigt wird sollte sie mit [[glDeleteTextures]] auch wieder frei gegeben werden.

=== Objekt orientiert ===

Dieser Abschnitt beschäftigt sich ausschließlich mit den 2D Texturen. Aber grundsätzlich lässt sich alles hier erwähnte auch auf die 1D Texturen und die Cubemaps übertragen.
Der Objekt orientierte Weg erfordert zwar eine wenig mehr Schreibarbeit aber nur so kann man den vollen Funktionsumfang der glBitmap genießen.

Als Erstes müssen wir eine Instanz der Texturenklasse definieren. Dies tun wir vorzugsweise als Member des Fensters auf dem wir zeichnen.

TForm1 = class(TForm)
// Verschiene Elemente und Events des Fensters
private
fTexture: TglBitmap2D; // Instanz unserer Textur
end;

Nun müssen wir der Textur noch Leben einhauchen.

procedure TForm1.FormShow(Sender: TObject);
begin
// OpenGL Initialisieren

fTexture := TglBitmap2D.Create; // Instanz der Klasse erstellen
fTexture.LoadFromFile('myTex\Wall.bmp'); // Datei laden
fTexture.GenTexture; // geladene Textur an OpenGL übergeben
end;

Für Schreibfaule besteht auch noch die Möglichkeit in einem überladenen Konstruktor einem Dateinamen anzugeben.

fTexture := TglBitmap2D.Create('myTex\Wall.bmp'); // Instanz erstellen und Datei laden
fTexture.GenTexture; // geladene Textur an OpenGL übergeben

In GenTexture wird im Normalfall immer überprüft ob die Textur eine gültige Größe hat. Sollte diese Überprüfung nicht gewünscht sein so kann man diese mit einem optionalen Parameter deaktivieren. Diese Überprüfung testet auch ob die Texturgröße eine Potenz von 2 ist (1, 2, 4, 8, 16 usw.) und wenn nicht ob solche Texturen von dem Rendercontex unterstützt werden.

fTexture.GenTexture(False); // Es wird keine Prüfung der Texturgröße vorgenommen.

Wenn kein Fehler aufgetreten ist und alles so funktioniert hat wie es sein sollte, dann kann die Textur benutzt werden.

fTexture.Bind; // Textur und entsprechendes Target wird aktiviert.

Sollte es nicht gewünscht werden, dass auch gleichzeitig das Target aktiviert wird so muss Bind mit dem Parameter False aufgerufen werden. Damit wird nur noch die Textur gebunden.

Sollte man die Textur einmal nicht mehr benutzen wollen so genügt es entweder eine andere Textur zu binden oder Unbind von der Texturenklasse aufzurufen. Damit wird die Textur mit der TexturID 0 gebunden und das Target deaktiviert. Auch hier existiert wieder der Parameter der es verhindert, dass das Target deaktiviert wird.

Wenn die Anwendung beendet wird müssen wir auch hier unsere Textur wieder frei geben. Dies geschieht so.

fTexture.Free; // Textur wieder frei geben.

Hierbei ist zu beachten, dass dies nach Möglichkeit vor dem Löschen des Rendercontex geschehen sollte, da so die Textur zu einem sinnvollem Zeitpunkt gelöscht werden kann. Wenn der Rendercontex nicht mehr existiert, so sollte die Textur auch nicht mehr existieren und wenn man dann noch einmal versucht sie zu löschen so könnte es zu Problemen führen. Bisher ist mir kein Fall bekannt aber ausschließen kann man es auch nicht. Also zu erst immer die Texturen frei geben und anschließend des Rendercontex löschen.

== Das leidige Thema Alphakanal ==

Es gibt zwei Möglichkeiten einen Alphakanal in eine Textur zu integrieren. Der einfachste und schnellste Weg ist, wenn sich dieser Kanal von Beginn an in die Textur befindet. Dazu wird ein Grafikprogramm benötigt welches so etwas unterstützt und ein Dateiformat welches das Speichern eines Alphakanals ermöglicht. Ein solches Programm ist zum Beispiel [http://www.gimp.org/ Gimp]. Also mögliche Dateiformate kämen TGAs und PNGs in Frage. Alle anderen Formate unterstützen keinen Alphakanal. Sollte man sich für diesen Weg entscheiden so genügt es dann ganz normal die Textur zu laden und zu benutzen und schon besitzen wir einen funktionierenden Alphakanal. Ich persönlich empfehle bis auf wenige Ausnahmen immer diesen Weg.

Nichts desto trotz habe ich ja gesagt, dass es noch eine Möglichkeit gibt. Bei diesem Weg haben wir Alphakanal und RGB Daten in zwei getrennten Bildern vorliegen. Aber wie bekommen wir das jetzt in ein Bild? Dafür bietet die glBitmap die Möglichkeit einen Alphakanal aus einem separaten Bild zu laden. Zu Beginn benötigen wir jedoch wieder eine Instanz der Klasse und es müssen schon normale Bilddaten geladen worden sein. Und ganz Wichtig damit es überhaupt funktioniert. Der Aufruf muss vor GenTexture stattfinden, da sonst die Textur bereits an OpenGL übergeben wurde.

fTexture.AddAlphaFromFile('myTex\Wall_alpha.bmp'); // Alphakanal aus Datei laden

Das war alles nun sind wir im Besitz einer Textur mit einem Alphakanal. Es besteht unter anderem auch die Möglichkeit den Alphakanal aus verschiedenen anderen Quellen zu laden (Resourcen, Streams, TBitmap). Zusätzlich dazu kann man den Kanal aber auch dynamisch erstellen. Dafür existiert die Methode AddAlphaFromFunc. Die Findigen unter euch habe aber bestimmt schon herausgefunden, dass man bei alle Methoden solch eine Function übergeben kann. Näheres dazu findet ihr im Abschnitt e = mc²

Etwas was häufiger gebraucht wird habe ich von Hause aus schon implementiert. Und zwar das Erstellen eines Alphakanals anhand einer Farbe.

fTexture.AddAlphaFromColorKey(Red, Green, Blue, Deviation); // Alphakanal anhand einer Farbe hinzufügen

Dabei wird nur auf vollkommen durchlässig und nicht durchlässig unterschieden. Alle Pixel die die angegebene Farbe besitzen werden dabei als 0 (nicht Sichtbar) in den Alphakanal geschrieben alle anderen erhalten 255 (Sichtbar). Die Deviation bestimmt eine Abweichung um der die Farben abweichen dürfen um trotzdem noch als Transparent erkannt zu werden. Speziell für JPEGs ist das nicht unwichtig, da die Bilder beim Komprimieren leicht abgewandelt werden.

Damit die OpenGL Primitiven jetzt transparent dargestellt werden muss der [[GlAlphaFunc|Alphatest]] oder das [[glBlendFunc|Blending]] aktiviert sein. Sonst nützt einem der Alphakanal nicht sonderlich viel.

Entfernen kann man einen Alphakanal natürlich auch. Dazu genügt der Aufruf von RemoveAlpha. Dieser muss natürlich nicht mit der glBitmap erstellt worden sein. Er kann auch aus einer Datei geladen worden sein.

fTexture.RemoveAlpha; // entfernt den Alphakanal

== Texturen konfigurieren ==

Hier beginnt jetzt der Teil der für die Meisten recht wichtig sein dürfte. Bisher haben wir ja nur Daten geladen und diese an OpenGL übergeben. Nun wollen wir aber ein wenig an den Einstellungen rumschrauben und sehen was wir daraus machen können.

Folgende Einstellungsmöglichkeiten verändern ausschließlich nur das Verhalten der glBitmap. Sie haben keinen Einfluss auf die resultierende Textur.

DeleteTextureOnFree ist vom Typ Boolean und gibt an ob beim Freigeben der Klasse die Texture auch freigegeben wird oder ob weiter existieren darf. Standard wird sie mit freigegeben.

FreeDataAfterGenTexture ist vom Typ Boolean und gibt an ob die Bilddaten nach dem Erzeugen der Textur aus dem Hauptspeicher entfernt werden sollen oder nicht. Im Normalfall werden sie das auch.

Target ist vom Typ Cardinal und bestimmt das OpenGL Target. Wird von den Klassen auf den Standardwert gesetzt und muss nur dann auf einen anderen Wert gesetzt werden, wenn ein anderes Target verwendet werden soll. Zum Beispiel bei der Verwendung von Texture_rectangle. Es sollte aber immer direkt nach dem erstellen gesetzt werden, da die Textur sonst unbrauchbar gemacht werden könnte.

Format ist ein Aufzählungstyp und er erlaubt 4 Werte.
{| {{Prettytable}}
|tfDefault
|Dabei wird das Standardformat des Grafikkartentreibers benutzt. Je nach eingestellter Qualität kann dies 16 oder 32 Bit sein.</td>
|-
|tf16Bit
|Hier wird die Textur in 16Bit abgelegt.
|-
|tf32Bit
|Hier wird die Textur in 32Bit abgelegt.
|-
|tfCompressed
|Bei diesem Format wird zu erst geschaut ob eines der folgenden Kriterien erfüllt ist. Extension GL_ARB_texture_compression, OpenGL Version 1.3 oder die Extension GL_EXT_texture_compression_s3tc. Sollten alle 3 Möglichkeiten nicht funktionieren so wird das Standardformat vom Grafikkartentreiber benutzt.
|}

MipMap ist ebenfalls ein Aufzählungstyp und er erlaubt 3 Werte.
{|{{Prettytable}}
|mmNone
|Wie man vermuten könnte werden hierbei keine Mipmaps erstellt.
|-
|mmMipmap
|Ähnlich wie bei komprimierten Texturen werden zu erst verschiedene neue Möglichkeiten überprüft. Ab OpenGL Version 1.4 oder mit der Extension GL_SGIS_generate_mipmap unterstützt die Grafikkarte ein generieren der [[Mipmaps]]. Das ist natürlich wesentlich schneller als der Weg ausschließlich über die Software. Sollte es keinen anderen Weg geben so werden die [[Mipmaps]] mittels der GLU generiert.
|-
|mmMipmapGlu
|In diesem Falle werden die [[Mipmaps]] ausschließlich mit der GLU erstellt.
|}

Mithilfe der Methoden SetFilter und SetWrap können das Filterverhalten und das Beschränken der Texturkoordinaten angepasst werden. Eine genaue Auflistung möglicher Werte findet man beim Artikel zu [[glTexParameter]]. Das Aufrufen der Methoden ist überall dort möglich wo auch [[gTexParameter]] gültig ist. Mögliche Fehlerhafte Werte werden automatisch auf die vorhandene Textur angepasst. So wird bei SetFilter niemals ein [[MipMaps|MipMap]] bei die Filterung eingestellt wenn keine [[MipMaps]] erzeugt wurden. Das würde sonst dazu führen, dass die Textur nicht dargestellt werden könnte.

FlipVert und FlipHorz sind Methoden die nichts anderes machen als das Bild entlang der entsprechenden Richtung (Vertikal und Horizontal) zu spiegeln. Dies wäre auch mit der Funktionsschnittstelle möglich aber besonders bei FlipVert wäre es unpraktisch da wir so nicht die komplette Zeile am Stück kopieren könnten, sondern nur Pixel für Pixel.

Zum Invertieren des Bildes genügt es die Methode Invert aufzurufen. Sie bekommt zwei boolsche Parameter mit denen man steuern kann was man invertieren möchte. Einen für RGB und einen für den Alphakanal.

Die Methode ToNormalMap wurde implementiert um aus einer 2D Textur eine NormalMap zu erzeugen. Er funktioniert ähnlich wie das NormalMapPlugin für Gimp. Die Methode bekommt 3 Parameter. Der Erste gibt an mit welcher Methode die Normalmap berechnet werden soll. Mögliche Werte hierfür sind
{|{{Prettytable}}
|nm4Samples</td>
|Hierbei werden die jeweils geradlinigen benachbarten Pixel zu gleichen Teilen in die Berechnung einbezogen. (Oben, Unten Recht und Links). Diese Methode ist die einfachste, schnellste und empfindlichste gegenüber Farbvariationen.
|-
|nmSobel
|Mit dieser Methode werden fließen benachbarten Pixel zu gleichen Teilen in die Berechnung ein.
|-
|nm3x3
|Bei diese Methode fließen auch alle benachbarten Pixel in die Berechnung ein. Die diagonalen Pixel werden Doppelt gewertet. Die NormalMap wirkt so ruhiger und nicht so anfällig gegen kleine Farbveränderungen.
|-
|nm5x5
|Diese Methode benutzt eine Matrix von 5*5 Pixeln um Ihre Berechnungen durch zu führen. Je weiter die Punkte vom Mittelpunkt entfernt sind so geringer wird deren Einfluss.
|}

Der zweite Parameter gibt eine Skalierung an. Mögliche Werte hierfür liegen im Bereich von -100 bis 100. Bei einer Skalierung von 0 würde sich die Normalmap Wohlgefallen auflösen, da sie dann praktisch eine gerade Fläche darstellen würde. Die Textur dürfte dann außergewöhnlich gleichfarbig blau werden. 
Mit dem dritten und letzten Parameter kann man die Berechnung der Normalmap von den RGB Werten auf den Alphakanal verschieben. Die Berechnung zieht sich dann nicht mehr die RGB Werte sondern den Alphakanal zu Rate. Der genaue Nutzen davon liegt zwar momentan selber vor mir verborgen aber wer weiß wozu man so etwas später noch gebrauchen kann. ;-)

== e = mc² ==

Hierbei handelt es sich um eine Möglichkeit die Texturdaten zu manipulieren. Die Schnittstelle wurde so gestaltet, dass sie sehr flexibel und typisiert ist. Sprich, dass man immer genau weiß worum es sich handelt und welche Felder unterstützt werden. Eine einfache Handhabung und eine gute Ausführungsgeschwindigkeit waren natürlich auch sehr wichtige Punkte dabei. Finden kann man die Funktionsschnittstelle beim Hinzufügen des Alphakanals oder immer wenn man möchte durch die Methode AddFunc. Es gibt außerdem noch eine Reihe von Funktionen, die intern die Schnittstelle benutzen. Das wären zum Beispiel die Funktionen Invert, AddAlphaFromColokey, ToNormalMap und FillWithColor. Die Klasse TglBitmapNormalMap generiert ihre Texturen zum Beispiel mit der Schnittstelle.

Die Arbeitsweise der Funktionsschnittstelle ist recht einfach. Es wird nichts anderes gemacht als 1 Mal Zeile für Zeile den Pointer eines jeden Pixels an eine Funktion zu Übergeben und darauf zu vertrauen, dass sie das Richtige tut. Um die Ausführung zu Beschleunigen wird ausschließlich mit Pointern gearbeitet. Die Funktionen bekommen die Instanz des Objektes, die Größe, die Position, das Quellpixel, das Zielpixel und einen Pointer auf benutzerdefinierte Daten übergeben. Das ist natürlich eine ganze Menge Holz was da an Daten übergeben aber das ist alles notwendig um die gewünschte Flexibilität erreichen zu können.

Betrachten wir das ganze mal an einem Beispiel. Und zwar dem Aufruf von Invert. Zu erst einmal der Aufruf der Funktion.

if ((UseRGB) or (UseAlpha))
then AddFunc(glBitmapInvertFunc, False, Pointer(Integer(UseAlpha and HasAlpha) shl 1 or Integer(UseRGB)));

In Zeile 1 handelt es sich lediglich um eine kleine Sicherheit. Es bringt ja nichts, wenn man eine Funktion ausführen möchte die keinen Nutzen hat. Zeile 2 Ruft die Methode AddFunc auf. Diese Methode bekommt als erstes unsere Funktion übergeben. Zu deren Aufbau komme ich gleich. Als Zweites bekommt AddFunc gesagt ob sie eine Kopie des Bildes erstellen soll. Für pixelübergreifende Funktionen ist dies unerlässlich, da man sich sonst seine noch benötigten Daten überschreiben würde. Der dritte Wert ist ein Pointer der zusätzliche Informationen hält. In diesem Falle handelt es sich lediglich um ein Bitset bei dem Bit 2 den Alphakanal und Bit 1 die RGB Werte repräsentiert. Es könnte sich dabei aber auch um einen Pointer auf ein Record handeln.

procedure glBitmapInvertFunc(Sender : TglBitmap; const Position, Size: TglBitmapPixelPosition;
const Source, Dest: TglBitmapPixelData; const Data: Pointer);
begin
if (Integer(Data) and $1 > 0) then begin
Dest.ptRed^ := not Dest.ptRed^;
Dest.ptGreen^ := not Dest.ptGreen^;
Dest.ptBlue^ := not Dest.ptBlue^;
end;

if (Integer(Data) and $2 > 0) then begin
Dest.ptAlpha^ := not Dest.ptAlpha^;
end;
end;

Position und Size beinhalten die Aktuelle Position des Pixels und die Größe des Bildes. Das Record TglBitmapPixelPosition beinhält 4 Werte. Fields, X, Y, Z. Fields beschreibt welche Felder überhaupt zur Verfügung stehen. Mögliche Werte Dafür sind ffX, ffY und ffZ. Wofür X, Y und Z stehen erkläre ich jetzt mal nicht, dass sollte jedem klar sein. Bei einem 2D Bitmap sind üblicherweise die Felder X und Y mit leben gefüllt. Das Feld Z liegt brach.

Source und Dest beinhalten die Pixeldaten. Die Records sind ziemlich genau so aufgebaut wie das für die Position. Es gibt einen Wert Fields. Mögliche Werte für ihn sind ffRed, ffGreen, ffBlue und ffAlpha. Diese Felder sind anders als bei bei Position keine richtigen Werte sondern Pointer die Direkt auf die Farbwerte in den Bildern zeigen. Es gibt deswegen Source und Dest, da es ja die Möglichkeit gibt eine Kopie des Bildes zu erstellen. Sollte ohne Kopie gearbeitet werden so sind Source und Dest gleich. Bei hinzufügen eines Alphakanals bezieht sich Source auf die Pixeldaten im dem Quellbild und Dest wie gewohnt auf die Daten im Zielbild.

In dem obigen Beispiel werden die Bits des Parameters Data ausgewertet und die entsprechenden Kanäle negiert. Der Komplexibilität sind kaum Grenzen gesetzt. Alle Wissensdurstigen unter euch sollten sich dann auch mal die Methode ToNormalMap anschauen. Dort werden zwei Funktionen aufgerufen. In der Ersten werden Daten gesammelt mit denen in der Zweiten die Normalmap berechnet wird. Oder auch die Klasse TglBitmapNormalMap. In dieser wird eine generelle Berechnungsroutine aufgerufen. Diese bekommt aber für jede Fläche der Map eine andere interne Methode übergeben. Mit dieser werden dann die Werte für jedes Pixel gefüllt.

Noch ein Wort für alle Geschwindigkeitsfanatiker. Ich hatte ein mal spaßeshalber die Methode FlipHorz nachgebaut und die Geschwindigkeit gemessen. Das Ergebnis hat mich selber sehr angenehm überrascht. Die Hardcodierte super optimierte Methode benötigte bei 300 Aufrufen, auf ein 512x512 Pixel großes Bild ca. 5 Sekunden. Die Methode mit dem Funktionsaufruf benötigte Lediglich 300 ms länger. Ich selber hätte eher mit dem Doppelten der Zeit gerechnet.

== Cubemaps mit glBitmap ==

Das einzige worin sich CubeMaps von 2D Texturen unterscheidet ist das Laden. Aber das ist auch nicht viel komplizierter als bei 2D Texturen. Die Handhabung mit den Texturen (Binden, Frei geben) ist wie bei 2D Texturen weswegen ich das auch nicht noch einmal extra wiederholen werde.

=== Procedural ===

Wie auch bei den 2D Texturen haben wir die Auswahl zwischen zwei möglichen Wegen. Der procedurale Weg unterscheidet sich lediglich in der Anzahl der angegebenen Texturen. Das sind diesmal natürlich ein paar mehr.

var
Texture: TGLuint;

// Cubemaps laden
LoadCubeMap('xpos.bmp', 'xneg.bmp', 'ypos.bmp', 'yneg.bmp', 'zpos.bmp', 'zneg.bmp', Texture, False);

Die ersten 6 Parameter geben die jeweils 6 Texturen an. Die Namen der Parameter geben auch gleichzeitig deren Ziel an. Also immer schön auf die Reihenfolge achten. In dem Siebten wird die Textur ID geschrieben und der Achte gibt an ob aus Resourcen geladen werden soll oder nicht.

=== Objekt orientiert ===

Der Objekt orientierte Weg gestaltet sich dieses mal ein wenig schreibintensiver. Es müssen ja auch schließlich 6 Texturen geladen werden. Aber das kann man auch praktischerweise in eine Schleife packen. Das praktische daran ist, dass wir alles mit nur einer Klasseninstanz lösen können (und auch müssen).

fCubeMap := TglBitmapCubeMap.Create; // Instanz der Klasse erstellen
fCubeMap.LoadFromFile('xpos.jpg'); // Datei Laden

Die Textur wird normal angelegt und es wird wie gewöhnt ein Bild in den Speicher der Klasse geladen. Dieses Bild verhält sich wie jedes andere Bild. Es kann also wie gewöhnt manipuliert werden. Zum Beispiel durch die Funktionsschnittstelle.

fCubeMap.GenerateCubeMap(GL_TEXTURE_CUBE_MAP_POSITIVE_X); // Einzelnen Teil übergeben

Wenn die Textur also bereit zum Übergeben ist, dann müssen wir GenerateCubeMap mit dem entsprechenden Teil der Cubemap aufrufen. In diesem Falle ist es die positive X Achse. Das müssen wir dann natürlich noch mit allen anderen Maps machen. Also Bild laden, evtl bearbeiten und dann an OpenGL übergeben. Die Reihenfolge der Maps spielt hierbei keine Rolle. Wichtig ist nur, dass sie die selbe Auflösung und das selbe Format haben. Die Methode GenTexture steht bei dieser Klasse nicht zur Verfügung, da beim ersten Aufruf von GenerateCubeMap automatisch die OpenGL Textur erzeugt wird. Die CubeMap ist nur dann einsetzbar, wenn alle Maps erfolgreich mit Daten versorgt wurden.

Beim Binden der CubeMap existiert ein zusätzlicher Parameter mit dem man die Aktivierung der automatische Generation der Texturkoordinaten deaktivieren kann. Standard ist dieses eingeschalten. Ähnlich wie beim Binden einer Textur. Dort kann man verhindern, dass das Target aktiviert wird.

== Normalmaps mit glBitmap ==

NormalMaps sind nichts anderes als Spezielle Cubemaps. Sie dienen dazu um Per Pixel Normale auch auf Systemen ohne Shaderhardware zu ermöglichen. Benutzt werden kann das zum Beispiel bei Bumpmapping mit [[GL_ARB_texture_env_dot3]].

=== Procedural ===

Wie auch bei den 2D Texturen und Cubemaps haben wir die Auswahl zwischen zwei möglichen Wegen. Da diese Texturen dynamisch generiert werden fällt die Anzahl der Parameter ziemlich gering aus. Sie besteht lediglich aus einer Texturgröße. In diesem Falle haben die resultierenden Texturen eine Größe von 32x32 Pixeln. Der zweite Parameter ist ein altbekannter von uns. Er ermöglicht es uns eine TexturID zu empfangen. Auf die Handhabung mit dieser ID gehe ich nicht noch einmal ein, da das oberhalb schon oft genug besprochen wurde.

var
Texture: TGLuint;

// Normalmaps erzeugen
LoadNormalMap(32, Texture);

=== Objekt orientiert ===

Dieser Weg ist etwa genau so schreibintensiv wie der Procedurale. Hierbei wird eine Normalmap erstellt bei der einzelnen Texturen eine Größe von 32x32 Pixeln haben.

fNormalMap := TglBitmapNormalMap.Create; // Instanz der Klasse erstellen
fNormalMap.GenerateNormalMap(32); // Normalmap erzeugen

Erstaunlich aber wahr. Das war bereits alles. Von nun an kann die Textur wie jede andere CubeMap auch verwendet werden.

== Bekannte Probleme und Einschränkungen ==

Vor einer Weile wurde im Forum die Frage gestellt warum die glBitmap beim Laden eines BMPs einen "Stream Read Error" produziert. Da das Bitmap nun mal ein sehr einfaches Format ist hat mich das auch sehr stark verwundert. Nach langem hin und her Rätseln kam ich dann dennoch darauf was das Problem war. Es lag daran, dass das Bitmap mit MS Paint abgespeichert wurde. Dieser war aber der Meinung er müsse im Bitmapheader eine Größe angeben die 2 Bytes größer war als die eigentlichen Daten. Diese 2 Bytes wurden auch aufgefüllt aber leider ist das TBitmap, welches ich zum Laden verwende, nicht so tolerant um darüber hinweg zu sehen. Und so bekommt man einen Fehler beim Laden. Den selben Fehler würde man auch bekommen wenn man das Bild in einem TImage anzeigen wollte.

Abhelfen kann man dies in dem man ein [http://www.gimp.org/ alternatives Grafikprogramm (Gimp)] verwendet oder das Bild einmal mit dem Bildbetrachter [http://www.irfanview.de/ IrfanView] öffnet und abspeichert.

Es muss nicht bei jedem mit MS Paint abgespeicherten Bild auftreten.

Glbitmap loader

2005-07-05T11:35:09Z

Lossy eX: /* glBitmap - Texturenloader */ 's durch s ersetzt.

{{unvollständig}}
= glBitmap - Texturenloader =

== Warum das Ganze und wo kann ich sie finden? ==

Früher benutzte ich die glBMP, da sie so "schön" Objekt orientiert war. Leider hatte mein Grafiktreiber zu der Zeit einen Fehler bei der Auswahl des Texturformates. So führte es dazu, dass sobald ich eine Textur mit Alphakanal und dem Standard Texturformat an OpenGL übergab, er als Farbtiefe 16 Bit verwendete. Wenn ich ein Foto genommen hätte wäre mir das wahrscheinlich gar nicht aufgefallen aber dummerweise (oder glücklicherweise) hatte ich aber eine Textur mit einem weichem Farbverlauf. Wie zu erwarten war sah das natürlich alles ziemlich schrecklich aus. Bis dahin kann der Loader ja nichts dafür wenn in einem Treiber ein Fehler existiert. Nur das kuriose an dem Ganzen war, dass meine Textur in Wirklichkeit gar keinen Alphakanal haben durfte. Also habe ich mich auf die Suche nach der Ursache gemacht und bin auch prompt fündig geworden. Der Loader war der Meinung er müsse alle Texturen mit einem Alphakanal versehen ungeachtet der Tatsache ob sie nun einen hatten oder eben nicht. Das ist natürlich eine Sache mit der ich mich nicht abfinden wollte. Kurz darauf begann ich also eine Ableitung der glBMP Texturenklasse zu erstellen und dort musste ich mit Schrecken feststellen, dass die Rechte in der Klasse so ungünstig vergeben wurden, dass ich keine andere Wahl gehabt hätte als direkt die Unit zu editieren. Da ich ungern externe Quellen editiere habe ich für mich die andere Alternative entschieden. Was dabei rausgekommen ist sieht man ja jetzt.

Gefunden werden kann sie entweder im DGL-SDK oder auf der [http://www.dev-center.de/index.php?cat=header&file=glbitmap Webseite] von [[Benutzer:Lossy eX|Lossy eX]].

== Allgemeines und Features ==

Dieser Artikel geht nicht darauf ein was zu tun ist um in OpenGL eine Textur darstellen zu können. In ihm werde ich lediglich darauf eingehen was man tun kann und muss um mittels der glBitmap eine Textur laden zu können. Außerdem werden die verfügbaren Einstellungen und ihre Wirkungen erklärt. Für alles andere wäre es besser das [[Tutorial_lektion4|Tutorial über Texturen]] durchzulesen.

Der wichtigste Unterschied zu den bestehenden Loadern bringe ich gleich einmal als erstes. Die glBitmap legt die Texturen anders im Speicher ab. Um zwar im speziellen meine ich damit die 2D Texturen. Bei bestehenden Loadern werden diese Texturen mit der untersten Zeile zu erst im Speicher abgelegt. In der glBitmap werden sie aber mit der obersten Zeile zu erst abgelegt. Man könnte auch sagen, dass sie bei den bestehenden Loadern auf dem Kopf stehen. Beide Möglichkeiten funktionieren und sind korrekt. Das Einzige was sich in diesem Zusammenhang ändert ist die [[glTexCoord| Adressierung der Texturen]]. Sie müssen entsprechend geändert werden. Sollte das nicht möglich sein so besteht mit der Methode FlipVert die Möglichkeit die Textur zu spiegeln. Näheres in Abschnitt [[Glbitmap_loader#Texturen_konfigurieren|Texturen konfigurieren]]. Im Normalfall sollte das andere Verhalten nicht zu Problemen führen sondern die Arbeit damit vereinfachen und verständlicher gestalten.

Die glBitmap holt sich ihre Daten ausschließlich aus Streams. Das zugrundeliegende Format wird automatisch anhand des Inhaltes der Daten ausgewählt. Es besteht also kein Notwendigkeit daran, dass der Entwickler wissen muss um welches Format es sich in Wirklichkeit handelt.

=== unterstütze Formate ===

* Windows Bitmaps (*.bmp) Wird Automatisch auf 24 Bit gesetzt sollte es kleiner sein.
* JPEG (*.jpg)
* TARGA (*.tga) komprimiert und unkomprimiert, 24 und 32 Bit. Ursprung unten links oder oben links
* Portable Network Graphics (*.png) 24 Bit mit oder ohne Alphakanal. Es wird eine zusätzliche Bibliothek benötigt.
Es besteht auch die Möglichkeit die Bilddaten dynamisch generieren zu lassen oder sie aus einer Instanz der Klasse TBitmap zu laden. Diese Instanz muss dann aber als Pixelformat 24 oder 32 Bit haben.

Um PNGs laden zu können muss eine externe Bibliothek namens [http://pngdelphi.sourceforge.net/ PNGImage] eingebunden und das Define pngimage hinzugefügt werden. Alternativ dazu kann das Define auch in der glBitmap auskommentiert werden.

== Texturen laden ==

Das Laden von Texturen kann auf 2 Weg geschehen. Bei Beiden ist aber zu beachten, dass OpenGL richtig initialisiert worden sein muss bevor man eine Textur erzeugen kann. Was noch sehr wichtig ist. Es sollte niemals eine Textur bei jedem Rendervorgang angelegt und freigegeben werden! Es ist viel effektiver, wenn man die Textur zu beginn lädt und so lange im Speicher behält bis sie nicht mehr benötigt wird. Wenn man sie erst später benötigt, dann kann man sie auch später noch nachladen aber auch dann sollte sie so lange wie nötig existieren.

=== Procedural ===

Hierbei genügt der Aufruf einer einzelnen Methode um eine Textur zu laden und diese an OpenGL zu übergeben. Allerdings auf Grund der Einfachheit steht nur das Laden aus Dateien oder Ressourcen zur Verfügung. Zusätzliche Funktionalität können dabei nicht benutzt werden. Generell empfehle ich immer die Objekt orientierte Variante.

var
Texture: TGLuint;

LoadTexture('myTex\Wall.bmp', Texture, False); // Datei laden

Damit wird die Datei Wall.bmp geladen und die TextureID wird in die Variable Texture geschrieben. Wenn die Textur dann benötigt wird, dann muss man diese entsprechend mit [[glBindTexture]] binden und das benötigte Texturtarget mit [[glEnable]] aktivieren. Das Target ist üblicherweise GL_TEXTURE_2D. Wenn die Textur nicht mehr benötigt wird sollte sie mit [[glDeleteTextures]] auch wieder frei gegeben werden.

=== Objekt orientiert ===

Dieser Abschnitt beschäftigt sich ausschließlich mit den 2D Texturen. Aber grundsätzlich lässt sich alles hier erwähnte auch auf die 1D Texturen und die Cubemaps übertragen.
Der Objekt orientierte Weg erfordert zwar eine wenig mehr Schreibarbeit aber nur so kann man den vollen Funktionsumfang der glBitmap genießen.

Als Erstes müssen wir eine Instanz der Texturenklasse definieren. Dies tun wir vorzugsweise als Member des Fensters auf dem wir zeichnen.

TForm1 = class(TForm)
// Verschiene Elemente und Events des Fensters
private
fTexture: TglBitmap2D; // Instanz unserer Textur
end;

Nun müssen wir der Textur noch Leben einhauchen.

procedure TForm1.FormShow(Sender: TObject);
begin
// OpenGL Initialisieren

fTexture := TglBitmap2D.Create; // Instanz der Klasse erstellen
fTexture.LoadFromFile('myTex\Wall.bmp'); // Datei laden
fTexture.GenTexture; // geladene Textur an OpenGL übergeben
end;

Für Schreibfaule besteht auch noch die Möglichkeit in einem überladenen Konstruktor einem Dateinamen anzugeben.

fTexture := TglBitmap2D.Create('myTex\Wall.bmp'); // Instanz erstellen und Datei laden
fTexture.GenTexture; // geladene Textur an OpenGL übergeben

In GenTexture wird im Normalfall immer überprüft ob die Textur eine gültige Größe hat. Sollte diese Überprüfung nicht gewünscht sein so kann man diese mit einem optionalen Parameter deaktivieren. Diese Überprüfung testet auch ob die Texturgröße eine Potenz von 2 ist (1, 2, 4, 8, 16 usw.) und wenn nicht ob solche Texturen von dem Rendercontex unterstützt werden.

fTexture.GenTexture(False); // Es wird keine Prüfung der Texturgröße vorgenommen.

Wenn kein Fehler aufgetreten ist und alles so funktioniert hat wie es sein sollte, dann kann die Textur benutzt werden.

fTexture.Bind; // Textur und entsprechendes Target wird aktiviert.

Sollte es nicht gewünscht werden, dass auch gleichzeitig das Target aktiviert wird so muss Bind mit dem Parameter False aufgerufen werden. Damit wird nur noch die Textur gebunden.

Sollte man die Textur einmal nicht mehr benutzen wollen so genügt es entweder eine andere Textur zu binden oder Unbind von der Texturenklasse aufzurufen. Damit wird die Textur mit der TexturID 0 gebunden und das Target deaktiviert. Auch hier existiert wieder der Parameter der es verhindert, dass das Target deaktiviert wird.

Wenn die Anwendung beendet wird müssen wir auch hier unsere Textur wieder frei geben. Dies geschieht so.

fTexture.Free; // Textur wieder frei geben.

Hierbei ist zu beachten, dass dies nach Möglichkeit vor dem Löschen des Rendercontex geschehen sollte, da so die Textur zu einem sinnvollem Zeitpunkt gelöscht werden kann. Wenn der Rendercontex nicht mehr existiert, so sollte die Textur auch nicht mehr existieren und wenn man dann noch einmal versucht sie zu löschen so könnte es zu Problemen führen. Bisher ist mir kein Fall bekannt aber ausschließen kann man es auch nicht. Also zu erst immer die Texturen frei geben und anschließend des Rendercontex löschen.

== Das leidige Thema Alphakanal ==

Es gibt zwei Möglichkeiten einen Alphakanal in eine Textur zu integrieren. Der einfachste und schnellste Weg ist, wenn sich dieser Kanal von Beginn an in die Textur befindet. Dazu wird ein Grafikprogramm benötigt welches so etwas unterstützt und ein Dateiformat welches das Speichern eines Alphakanals ermöglicht. Ein solches Programm ist zum Beispiel [http://www.gimp.org/ Gimp]. Also mögliche Dateiformate kämen TGAs und PNGs in Frage. Alle anderen Formate unterstützen keinen Alphakanal. Sollte man sich für diesen Weg entscheiden so genügt es dann ganz normal die Textur zu laden und zu benutzen und schon besitzen wir einen funktionierenden Alphakanal. Ich persönlich empfehle bis auf wenige Ausnahmen immer diesen Weg.

Nichts desto trotz habe ich ja gesagt, dass es noch eine Möglichkeit gibt. Bei diesem Weg haben wir Alphakanal und RGB Daten in zwei getrennten Bildern vorliegen. Aber wie bekommen wir das jetzt in ein Bild? Dafür bietet die glBitmap die Möglichkeit einen Alphakanal aus einem separaten Bild zu laden. Zu Beginn benötigen wir jedoch wieder eine Instanz der Klasse und es müssen schon normale Bilddaten geladen worden sein. Und ganz Wichtig damit es überhaupt funktioniert. Der Aufruf muss vor GenTexture stattfinden, da sonst die Textur bereits an OpenGL übergeben wurde.

fTexture.AddAlphaFromFile('myTex\Wall_alpha.bmp'); // Alphakanal aus Datei laden

Das war alles nun sind wir im Besitz einer Textur mit einem Alphakanal. Es besteht unter anderem auch die Möglichkeit den Alphakanal aus verschiedenen anderen Quellen zu laden (Resourcen, Streams, TBitmap). Zusätzlich dazu kann man den Kanal aber auch dynamisch erstellen. Dafür existiert die Methode AddAlphaFromFunc. Die Findigen unter euch habe aber bestimmt schon herausgefunden, dass man bei alle Methoden solch eine Function übergeben kann. Näheres dazu findet ihr im Abschnitt e = mc²

Etwas was häufiger gebraucht wird habe ich von Hause aus schon implementiert. Und zwar das Erstellen eines Alphakanals anhand einer Farbe.

fTexture.AddAlphaFromColorKey(Red, Green, Blue, Deviation); // Alphakanal anhand einer Farbe hinzufügen

Dabei wird nur auf vollkommen durchlässig und nicht durchlässig unterschieden. Alle Pixel die die angegebene Farbe besitzen werden dabei als 0 (nicht Sichtbar) in den Alphakanal geschrieben alle anderen erhalten 255 (Sichtbar). Die Deviation bestimmt eine Abweichung um der die Farben abweichen dürfen um trotzdem noch als Transparent erkannt zu werden. Speziell für JPEGs ist das nicht unwichtig, da die Bilder beim Komprimieren leicht abgewandelt werden.

Damit die OpenGL Primitiven jetzt transparent dargestellt werden muss der [[GlAlphaFunc|Alphatest]] oder das [[glBlendFunc|Blending]] aktiviert sein. Sonst nützt einem der Alphakanal nicht sonderlich viel.

Entfernen kann man einen Alphakanal natürlich auch. Dazu genügt der Aufruf von RemoveAlpha. Dieser muss natürlich nicht mit der glBitmap erstellt worden sein. Er kann auch aus einer Datei geladen worden sein.

fTexture.RemoveAlpha; // entfernt den Alphakanal

== Texturen konfigurieren ==

Hier beginnt jetzt der Teil der für die Meisten recht wichtig sein dürfte. Bisher haben wir ja nur Daten geladen und diese an OpenGL übergeben. Nun wollen wir aber ein wenig an den Einstellungen rumschrauben und sehen was wir daraus machen können.

Folgende Einstellungsmöglichkeiten verändern ausschließlich nur das Verhalten der glBitmap. Sie haben keinen Einfluss auf die resultierende Textur.

DeleteTextureOnFree ist vom Typ Boolean und gibt an ob beim Freigeben der Klasse die Texture auch freigegeben wird oder ob weiter existieren darf. Standard wird sie mit freigegeben.

FreeDataAfterGenTexture ist vom Typ Boolean und gibt an ob die Bilddaten nach dem Erzeugen der Textur aus dem Hauptspeicher entfernt werden sollen oder nicht. Im Normalfall werden sie das auch.

Target ist vom Typ Cardinal und bestimmt das OpenGL Target. Wird von den Klassen auf den Standardwert gesetzt und muss nur dann auf einen anderen Wert gesetzt werden, wenn ein anderes Target verwendet werden soll. Zum Beispiel bei der Verwendung von Texture_rectangle. Es sollte aber immer direkt nach dem erstellen gesetzt werden, da die Textur sonst unbrauchbar gemacht werden könnte.

Format ist ein Aufzählungstyp und er erlaubt 4 Werte.
{| {{Prettytable}}
|tfDefault
|Dabei wird das Standardformat des Grafikkartentreibers benutzt. Je nach eingestellter Qualität kann dies 16 oder 32 Bit sein.</td>
|-
|tf16Bit
|Hier wird die Textur in 16Bit abgelegt.
|-
|tf32Bit
|Hier wird die Textur in 32Bit abgelegt.
|-
|tfCompressed
|Bei diesem Format wird zu erst geschaut ob eines der folgenden Kriterien erfüllt ist. Extension GL_ARB_texture_compression, OpenGL Version 1.3 oder die Extension GL_EXT_texture_compression_s3tc. Sollten alle 3 Möglichkeiten nicht funktionieren so wird das Standardformat vom Grafikkartentreiber benutzt.
|}

MipMap ist ebenfalls ein Aufzählungstyp und er erlaubt 3 Werte.
{|{{Prettytable}}
|mmNone
|Wie man vermuten könnte werden hierbei keine Mipmaps erstellt.
|-
|mmMipmap
|Ähnlich wie bei komprimierten Texturen werden zu erst verschiedene neue Möglichkeiten überprüft. Ab OpenGL Version 1.4 oder mit der Extension GL_SGIS_generate_mipmap unterstützt die Grafikkarte ein generieren der [[Mipmaps]]. Das ist natürlich wesentlich schneller als der Weg ausschließlich über die Software. Sollte es keinen anderen Weg geben so werden die [[Mipmaps]] mittels der GLU generiert.
|-
|mmMipmapGlu
|In diesem Falle werden die [[Mipmaps]] ausschließlich mit der GLU erstellt.
|}

Mithilfe der Methoden SetFilter und SetWrap können das Filterverhalten und das Beschränken der Texturkoordinaten angepasst werden. Eine genaue Auflistung möglicher Werte findet man beim Artikel zu [[glTexParameter]]. Das Aufrufen der Methoden ist überall dort möglich wo auch [[gTexParameter]] gültig ist. Mögliche Fehlerhafte Werte werden automatisch auf die vorhandene Textur angepasst. So wird bei SetFilter niemals ein [[MipMaps|MipMap]] bei die Filterung eingestellt wenn keine [[MipMaps]] erzeugt wurden. Das würde sonst dazu führen, dass die Textur nicht dargestellt werden könnte.

FlipVert und FlipHorz sind Methoden die nichts anderes machen als das Bild entlang der entsprechenden Richtung (Vertikal und Horizontal) zu spiegeln. Dies wäre auch mit der Funktionsschnittstelle möglich aber besonders bei FlipVert wäre es unpraktisch da wir so nicht die komplette Zeile am Stück kopieren könnten, sondern nur Pixel für Pixel.

Zum Invertieren des Bildes genügt es die Methode Invert aufzurufen. Sie bekommt zwei boolsche Parameter mit denen man steuern kann was man invertieren möchte. Einen für RGB und einen für den Alphakanal.

Die Methode ToNormalMap wurde implementiert um aus einer 2D Textur eine NormalMap zu erzeugen. Er funktioniert ähnlich wie das NormalMapPlugin für Gimp. Die Methode bekommt 3 Parameter. Der Erste gibt an mit welcher Methode die Normalmap berechnet werden soll. Mögliche Werte hierfür sind
{|{{Prettytable}}
|nm4Samples</td>
|Hierbei werden die jeweils geradlinigen benachbarten Pixel zu gleichen Teilen in die Berechnung einbezogen. (Oben, Unten Recht und Links). Diese Methode ist die einfachste, schnellste und empfindlichste gegenüber Farbvariationen.
|-
|nmSobel
|Mit dieser Methode werden fließen benachbarten Pixel zu gleichen Teilen in die Berechnung ein.
|-
|nm3x3
|Bei diese Methode fließen auch alle benachbarten Pixel in die Berechnung ein. Die diagonalen Pixel werden Doppelt gewertet. Die NormalMap wirkt so ruhiger und nicht so anfällig gegen kleine Farbveränderungen.
|-
|nm5x5
|Diese Methode benutzt eine Matrix von 5*5 Pixeln um Ihre Berechnungen durch zu führen. Je weiter die Punkte vom Mittelpunkt entfernt sind so geringer wird deren Einfluss.
|}

Der zweite Parameter gibt eine Skalierung an. Mögliche Werte hierfür liegen im Bereich von -100 bis 100. Bei einer Skalierung von 0 würde sich die Normalmap Wohlgefallen auflösen, da sie dann praktisch eine gerade Fläche darstellen würde. Die Textur dürfte dann außergewöhnlich gleichfarbig blau werden. 
Mit dem dritten und letzten Parameter kann man die Berechnung der Normalmap von den RGB Werten auf den Alphakanal verschieben. Die Berechnung zieht sich dann nicht mehr die RGB Werte sondern den Alphakanal zu Rate. Der genaue Nutzen davon liegt zwar momentan selber vor mir verborgen aber wer weiß wozu man so etwas später noch gebrauchen kann. ;-)

== e = mc² ==

Hierbei handelt es sich um eine Möglichkeit die Texturdaten zu manipulieren. Die Schnittstelle wurde so gestaltet, dass sie sehr flexibel und typisiert ist. Sprich, dass man immer genau weiß worum es sich handelt und welche Felder unterstützt werden. Eine einfache Handhabung und eine gute Ausführungsgeschwindigkeit waren natürlich auch sehr wichtige Punkte dabei. Finden kann man die Funktionsschnittstelle beim Hinzufügen des Alphakanals oder immer wenn man möchte durch die Methode AddFunc. Es gibt außerdem noch eine Reihe von Funktionen, die intern die Schnittstelle benutzen. Das wären zum Beispiel die Funktionen Invert, AddAlphaFromColokey, ToNormalMap und FillWithColor. Die Klasse TglBitmapNormalMap generiert ihre Texturen zum Beispiel mit der Schnittstelle.

Die Arbeitsweise der Funktionsschnittstelle ist recht einfach. Es wird nichts anderes gemacht als 1 Mal Zeile für Zeile den Pointer eines jeden Pixels an eine Funktion zu Übergeben und darauf zu vertrauen, dass sie das Richtige tut. Um die Ausführung zu Beschleunigen wird ausschließlich mit Pointern gearbeitet. Die Funktionen bekommen die Instanz des Objektes, die Größe, die Position, das Quellpixel, das Zielpixel und einen Pointer auf benutzerdefinierte Daten übergeben. Das ist natürlich eine ganze Menge Holz was da an Daten übergeben aber das ist alles notwendig um die gewünschte Flexibilität erreichen zu können.

Betrachten wir das ganze mal an einem Beispiel. Und zwar dem Aufruf von Invert. Zu erst einmal der Aufruf der Funktion.

if ((UseRGB) or (UseAlpha))
then AddFunc(glBitmapInvertFunc, False, Pointer(Integer(UseAlpha and HasAlpha) shl 1 or Integer(UseRGB)));

In Zeile 1 handelt es sich lediglich um eine kleine Sicherheit. Es bringt ja nichts, wenn man eine Funktion ausführen möchte die keinen Nutzen hat. Zeile 2 Ruft die Methode AddFunc auf. Diese Methode bekommt als erstes unsere Funktion übergeben. Zu deren Aufbau komme ich gleich. Als Zweites bekommt AddFunc gesagt ob sie eine Kopie des Bildes erstellen soll. Für pixelübergreifende Funktionen ist dies unerlässlich, da man sich sonst seine noch benötigten Daten überschreiben würde. Der dritte Wert ist ein Pointer der zusätzliche Informationen hält. In diesem Falle handelt es sich lediglich um ein Bitset bei dem Bit 2 den Alphakanal und Bit 1 die RGB Werte repräsentiert. Es könnte sich dabei aber auch um einen Pointer auf ein Record handeln.

procedure glBitmapInvertFunc(Sender : TglBitmap; const Position, Size: TglBitmapPixelPosition;
const Source, Dest: TglBitmapPixelData; const Data: Pointer);
begin
if (Integer(Data) and $1 > 0) then begin
Dest.ptRed^ := not Dest.ptRed^;
Dest.ptGreen^ := not Dest.ptGreen^;
Dest.ptBlue^ := not Dest.ptBlue^;
end;

if (Integer(Data) and $2 > 0) then begin
Dest.ptAlpha^ := not Dest.ptAlpha^;
end;
end;

Position und Size beinhalten die Aktuelle Position des Pixels und die Größe des Bildes. Das Record TglBitmapPixelPosition beinhält 4 Werte. Fields, X, Y, Z. Fields beschreibt welche Felder überhaupt zur Verfügung stehen. Mögliche Werte Dafür sind ffX, ffY und ffZ. Wofür X, Y und Z stehen erkläre ich jetzt mal nicht, dass sollte jedem klar sein. Bei einem 2D Bitmap sind üblicherweise die Felder X und Y mit leben gefüllt. Das Feld Z liegt brach.

Source und Dest beinhalten die Pixeldaten. Die Records sind ziemlich genau so aufgebaut wie das für die Position. Es gibt einen Wert Fields. Mögliche Werte für ihn sind ffRed, ffGreen, ffBlue und ffAlpha. Diese Felder sind anders als bei bei Position keine richtigen Werte sondern Pointer die Direkt auf die Farbwerte in den Bildern zeigen. Es gibt deswegen Source und Dest, da es ja die Möglichkeit gibt eine Kopie des Bildes zu erstellen. Sollte ohne Kopie gearbeitet werden so sind Source und Dest gleich. Bei hinzufügen eines Alphakanals bezieht sich Source auf die Pixeldaten im dem Quellbild und Dest wie gewohnt auf die Daten im Zielbild.

In dem obigen Beispiel werden die Bits des Parameters Data ausgewertet und die entsprechenden Kanäle negiert. Der Komplexibilität sind kaum Grenzen gesetzt. Alle Wissensdurstigen unter euch sollten sich dann auch mal die Methode ToNormalMap anschauen. Dort werden zwei Funktionen aufgerufen. In der Ersten werden Daten gesammelt mit denen in der Zweiten die Normalmap berechnet wird. Oder auch die Klasse TglBitmapNormalMap. In dieser wird eine generelle Berechnungsroutine aufgerufen. Diese bekommt aber für jede Fläche der Map eine andere interne Methode übergeben. Mit dieser werden dann die Werte für jedes Pixel gefüllt.

Noch ein Wort für alle Geschwindigkeitsfanatiker. Ich hatte ein mal spaßeshalber die Methode FlipHorz nachgebaut und die Geschwindigkeit gemessen. Das Ergebnis hat mich selber sehr angenehm überrascht. Die Hardcodierte super optimierte Methode benötigte bei 300 Aufrufen, auf ein 512x512 Pixel großes Bild ca. 5 Sekunden. Die Methode mit dem Funktionsaufruf benötigte Lediglich 300 ms länger. Ich selber hätte eher mit dem Doppelten der Zeit gerechnet.

== Cubemaps mit glBitmap ==

Das einzige worin sich CubeMaps von 2D Texturen unterscheidet ist das Laden. Aber das ist auch nicht viel komplizierter als bei 2D Texturen. Die Handhabung mit den Texturen (Binden, Frei geben) ist wie bei 2D Texturen weswegen ich das auch nicht noch einmal extra wiederholen werde.

=== Procedural ===

Wie auch bei den 2D Texturen haben wir die Auswahl zwischen zwei möglichen Wegen. Der procedurale Weg unterscheidet sich lediglich in der Anzahl der angegebenen Texturen. Das sind diesmal natürlich ein paar mehr.

var
Texture: TGLuint;

// Cubemaps laden
LoadCubeMap('xpos.bmp', 'xneg.bmp', 'ypos.bmp', 'yneg.bmp', 'zpos.bmp', 'zneg.bmp', Texture, False);

Die ersten 6 Parameter geben die jeweils 6 Texturen an. Die Namen der Parameter geben auch gleichzeitig deren Ziel an. Also immer schön auf die Reihenfolge achten. In dem Siebten wird die Textur ID geschrieben und der Achte gibt an ob aus Resourcen geladen werden soll oder nicht.

=== Objekt orientiert ===

Der Objekt orientierte Weg gestaltet sich dieses mal ein wenig schreibintensiver. Es müssen ja auch schließlich 6 Texturen geladen werden. Aber das kann man auch praktischerweise in eine Schleife packen. Das praktische daran ist, dass wir alles mit nur einer Klasseninstanz lösen können (und auch müssen).

fCubeMap := TglBitmapCubeMap.Create; // Instanz der Klasse erstellen
fCubeMap.LoadFromFile('xpos.jpg'); // Datei Laden

Die Textur wird normal angelegt und es wird wie gewöhnt ein Bild in den Speicher der Klasse geladen. Dieses Bild verhält sich wie jedes andere Bild. Es kann also wie gewöhnt manipuliert werden. Zum Beispiel durch die Funktionsschnittstelle.

fCubeMap.GenerateCubeMap(GL_TEXTURE_CUBE_MAP_POSITIVE_X); // Einzelnen Teil übergeben

Wenn die Textur also bereit zum Übergeben ist, dann müssen wir GenerateCubeMap mit dem entsprechenden Teil der Cubemap aufrufen. In diesem Falle ist es die positive X Achse. Das müssen wir dann natürlich noch mit allen anderen Maps machen. Also Bild laden, evtl bearbeiten und dann an OpenGL übergeben. Die Reihenfolge der Maps spielt hierbei keine Rolle. Wichtig ist nur, dass sie die selbe Auflösung und das selbe Format haben. Die Methode GenTexture steht bei dieser Klasse nicht zur Verfügung, da beim ersten Aufruf von GenerateCubeMap automatisch die OpenGL Textur erzeugt wird. Die CubeMap ist nur dann einsetzbar, wenn alle Maps erfolgreich mit Daten versorgt wurden.

Beim Binden der CubeMap existiert ein zusätzlicher Parameter mit dem man die Aktivierung der automatische Generation der Texturkoordinaten deaktivieren kann. Standard ist dieses eingeschalten. Ähnlich wie beim Binden einer Textur. Dort kann man verhindern, dass das Target aktiviert wird.

== Normalmaps mit glBitmap ==

NormalMaps sind nichts anderes als Spezielle Cubemaps. Sie dienen dazu um Per Pixel Normale auch auf Systemen ohne Shaderhardware zu ermöglichen. Benutzt werden kann das zum Beispiel bei Bumpmapping mit [[GL_ARB_texture_env_dot3]].

=== Procedural ===

Wie auch bei den 2D Texturen und Cubemaps haben wir die Auswahl zwischen zwei möglichen Wegen. Da diese Texturen dynamisch generiert werden fällt die Anzahl der Parameter ziemlich gering aus. Sie besteht lediglich aus einer Texturgröße. In diesem Falle haben die resultierenden Texturen eine Größe von 32x32 Pixeln. Der zweite Parameter ist ein altbekannter von uns. Er ermöglicht es uns eine TexturID zu empfangen. Auf die Handhabung mit dieser ID gehe ich nicht noch einmal ein, da das oberhalb schon oft genug besprochen wurde.

var
Texture: TGLuint;

// Normalmaps erzeugen
LoadNormalMap(32, Texture);

=== Objekt orientiert ===

Dieser Weg ist etwa genau so schreibintensiv wie der Procedurale. Hierbei wird eine Normalmap erstellt bei der einzelnen Texturen eine Größe von 32x32 Pixeln haben.

fNormalMap := TglBitmapNormalMap.Create; // Instanz der Klasse erstellen
fNormalMap.GenerateNormalMap(32); // Normalmap erzeugen

Erstaunlich aber wahr. Das war bereits alles. Von nun an kann die Textur wie jede andere CubeMap auch verwendet werden.

== Bekannte Probleme und Einschränkungen ==

Vor einer Weile wurde im Forum die Frage gestellt warum die glBitmap beim Laden eines BMPs einen "Stream Read Error" produziert. Da das Bitmap nun mal ein sehr einfaches Format ist hat mich das auch sehr stark verwundert. Nach langem hin und her Rätseln kam ich dann dennoch darauf was das Problem war. Es lag daran, dass das Bitmap mit MS Paint abgespeichert wurde. Dieser war aber der Meinung er müsse im Bitmapheader eine Größe angeben die 2 Bytes größer war als die eigentlichen Daten. Diese 2 Bytes wurden auch aufgefüllt aber leider ist das TBitmap, welches ich zum Laden verwende, nicht so tolerant um darüber hinweg zu sehen. Und so bekommt man einen Fehler beim Laden. Den selben Fehler würde man auch bekommen wenn man das Bild in einem TImage anzeigen wollte.

Abhelfen kann man dies in dem man ein [http://www.gimp.org/ alternatives Grafikprogramm (Gimp)] verwendet oder das Bild einmal mit dem Bildbetrachter [http://www.irfanview.de/ IrfanView] öffnet und abspeichert.

Es muss nicht bei jedem mit MS Paint abgespeicherten Bild auftreten.

Glbitmap loader

2005-07-05T09:27:54Z

Lossy eX: /* Texturen konfigurieren */

{{unvollständig}}
= glBitmap - Texturenloader =

== Warum das Ganze und wo kann ich sie finden? ==

Früher benutzte ich die glBMP, da sie so "schön" Objekt orientiert war. Leider hatte mein Grafiktreiber zu der Zeit einen Fehler bei der Auswahl des Texturformates. So führte es dazu, dass sobald ich eine Textur mit Alphakanal und dem Standard Texturformat an OpenGL übergab, er als Farbtiefe 16 Bit verwendete. Wenn ich ein Foto genommen hätte wäre mir das wahrscheinlich gar nicht aufgefallen aber dummerweise (oder glücklicherweise) hatte ich aber eine Textur mit einem weichem Farbverlauf. Wie zu erwarten war sah das natürlich alles ziemlich schrecklich aus. Bis dahin kann der Loader ja nichts dafür wenn in einem Treiber ein Fehler existiert. Nur das kuriose an dem Ganzen war, dass meine Textur in Wirklichkeit gar keinen Alphakanal haben durfte. Also habe ich mich auf die Suche nach der Ursache gemacht und bin auch prompt fündig geworden. Der Loader war der Meinung er müsse alle Texturen mit einem Alphakanal versehen ungeachtet der Tatsache ob sie nun einen hatten oder eben nicht. Das ist natürlich eine Sache mit der ich mich nicht abfinden wollte. Kurz darauf begann ich also eine Ableitung der glBMP Texturenklasse zu erstellen und dort musste ich mit Schrecken feststellen, dass die Rechte in der Klasse so ungünstig vergeben wurden, dass ich keine andere Wahl gehabt hätte als direkt die Unit zu editieren. Da ich ungern externe Quellen editiere habe ich für mich die andere Alternative entschieden. Was dabei rausgekommen ist sieht man ja jetzt.

Gefunden werden kann sie entweder im DGL-SDK oder auf der [http://www.dev-center.de/index.php?cat=header&file=glbitmap Webseite] von [[Benutzer:Lossy eX|Lossy eX]].

== Allgemeines und Features ==

Dieser Artikel geht nicht darauf ein was zu tun ist um in OpenGL eine Textur darstellen zu können. In ihm werde ich lediglich darauf eingehen was man tun kann und muss um mittels der glBitmap eine Textur laden zu können. Außerdem werden die verfügbaren Einstellungen und ihre Wirkungen erklärt. Für alles andere wäre es besser das [[Tutorial_lektion4|Tutorial über Texturen]] durchzulesen.

Der wichtigste Unterschied zu den bestehenden Loadern bringe ich gleich einmal als erstes. Die glBitmap legt die Texturen anders im Speicher ab. Um zwar im speziellen meine ich damit die 2D Texturen. Bei bestehenden Loadern werden diese Texturen mit der untersten Zeile zu erst im Speicher abgelegt. In der glBitmap werden sie aber mit der obersten Zeile zu erst abgelegt. Man könnte auch sagen, dass sie bei den bestehenden Loadern auf dem Kopf stehen. Beide Möglichkeiten funktionieren und sind korrekt. Das Einzige was sich in diesem Zusammenhang ändert ist die [[glTexCoord| Adressierung der Texturen]]. Sie müssen entsprechend geändert werden. Sollte das nicht möglich sein so besteht mit der Methode FlipVert die Möglichkeit die Textur zu spiegeln. Näheres in Abschnitt [[Glbitmap_loader#Texturen_konfigurieren|Texturen konfigurieren]]. Im Normalfall sollte das andere Verhalten nicht zu Problemen führen sondern die Arbeit damit vereinfachen und verständlicher gestalten.

Die glBitmap holt sich ihre Daten ausschließlich aus Streams. Das zugrundeliegende Format wird automatisch anhand des Inhaltes der Daten ausgewählt. Es besteht also kein Notwendigkeit daran, dass der Entwickler wissen muss um welches Format es sich in Wirklichkeit handelt.

=== unterstütze Formate ===

* Windows Bitmaps (*.bmp) Wird Automatisch auf 24 Bit gesetzt sollte es kleiner sein.
* JPEG (*.jpg)
* TARGA (*.tga) komprimiert und unkomprimiert, 24 und 32 Bit. Ursprung unten links oder oben links
* Portable Network Graphics (*.png) 24 Bit mit oder ohne Alphakanal. Es wird eine zusätzliche Bibliothek benötigt.
Es besteht auch die Möglichkeit die Bilddaten dynamisch generieren zu lassen oder sie aus einer Instanz der Klasse TBitmap zu laden. Diese Instanz muss dann aber als Pixelformat 24 oder 32 Bit haben.

Um PNG's laden zu können muss eine externe Bibliothek namens [http://pngdelphi.sourceforge.net/ PNGImage] eingebunden und das Define pngimage hinzugefügt werden. Alternativ dazu kann das Define auch in der glBitmap auskommentiert werden.

== Texturen laden ==

Das Laden von Texturen kann auf 2 Weg geschehen. Bei Beiden ist aber zu beachten, dass OpenGL richtig initialisiert worden sein muss bevor man eine Textur erzeugen kann. Was noch sehr wichtig ist. Es sollte niemals eine Textur bei jedem Rendervorgang angelegt und freigegeben werden! Es ist viel effektiver, wenn man die Textur zu beginn lädt und so lange im Speicher behält bis sie nicht mehr benötigt wird. Wenn man sie erst später benötigt, dann kann man sie auch später noch nachladen aber auch dann sollte sie so lange wie nötig existieren.

=== Procedural ===

Hierbei genügt der Aufruf einer einzelnen Methode um eine Textur zu laden und diese an OpenGL zu übergeben. Allerdings auf Grund der Einfachheit steht nur das Laden aus Dateien oder Ressourcen zur Verfügung. Zusätzliche Funktionalität können dabei nicht benutzt werden. Generell empfehle ich immer die Objekt orientierte Variante.

var
Texture: TGLuint;

LoadTexture('myTex\Wall.bmp', Texture, False); // Datei laden

Damit wird die Datei Wall.bmp geladen und die TextureID wird in die Variable Texture geschrieben. Wenn die Textur dann benötigt wird, dann muss man diese entsprechend mit [[glBindTexture]] binden und das benötigte Texturtarget mit [[glEnable]] aktivieren. Das Target ist üblicherweise GL_TEXTURE_2D. Wenn die Textur nicht mehr benötigt wird sollte sie mit [[glDeleteTextures]] auch wieder frei gegeben werden.

=== Objekt orientiert ===

Dieser Abschnitt beschäftigt sich ausschließlich mit den 2D Texturen. Aber grundsätzlich lässt sich alles hier erwähnte auch auf die 1D Texturen und die Cubemaps übertragen.
Der Objekt orientierte Weg erfordert zwar eine wenig mehr Schreibarbeit aber nur so kann man den vollen Funktionsumfang der glBitmap genießen.

Als Erstes müssen wir eine Instanz der Texturenklasse definieren. Dies tun wir vorzugsweise als Member des Fensters auf dem wir zeichnen.

TForm1 = class(TForm)
// Verschiene Elemente und Events des Fensters
private
fTexture: TglBitmap2D; // Instanz unserer Textur
end;

Nun müssen wir der Textur noch Leben einhauchen.

procedure TForm1.FormShow(Sender: TObject);
begin
// OpenGL Initialisieren

fTexture := TglBitmap2D.Create; // Instanz der Klasse erstellen
fTexture.LoadFromFile('myTex\Wall.bmp'); // Datei laden
fTexture.GenTexture; // geladene Textur an OpenGL übergeben
end;

Für Schreibfaule besteht auch noch die Möglichkeit in einem überladenen Konstruktor einem Dateinamen anzugeben.

fTexture := TglBitmap2D.Create('myTex\Wall.bmp'); // Instanz erstellen und Datei laden
fTexture.GenTexture; // geladene Textur an OpenGL übergeben

In GenTexture wird im Normalfall immer überprüft ob die Textur eine gültige Größe hat. Sollte diese Überprüfung nicht gewünscht sein so kann man diese mit einem optionalen Parameter deaktivieren. Diese Überprüfung testet auch ob die Texturgröße eine Potenz von 2 ist (1, 2, 4, 8, 16 usw.) und wenn nicht ob solche Texturen von dem Rendercontex unterstützt werden.

fTexture.GenTexture(False); // Es wird keine Prüfung der Texturgröße vorgenommen.

Wenn kein Fehler aufgetreten ist und alles so funktioniert hat wie es sein sollte, dann kann die Textur benutzt werden.

fTexture.Bind; // Textur und entsprechendes Target wird aktiviert.

Sollte es nicht gewünscht werden, dass auch gleichzeitig das Target aktiviert wird so muss Bind mit dem Parameter False aufgerufen werden. Damit wird nur noch die Textur gebunden.

Sollte man die Textur einmal nicht mehr benutzen wollen so genügt es entweder eine andere Textur zu binden oder Unbind von der Texturenklasse aufzurufen. Damit wird die Textur mit der TexturID 0 gebunden und das Target deaktiviert. Auch hier existiert wieder der Parameter der es verhindert, dass das Target deaktiviert wird.

Wenn die Anwendung beendet wird müssen wir auch hier unsere Textur wieder frei geben. Dies geschieht so.

fTexture.Free; // Textur wieder frei geben.

Hierbei ist zu beachten, dass dies nach Möglichkeit vor dem Löschen des Rendercontex geschehen sollte, da so die Textur zu einem sinnvollem Zeitpunkt gelöscht werden kann. Wenn der Rendercontex nicht mehr existiert, so sollte die Textur auch nicht mehr existieren und wenn man dann noch einmal versucht sie zu löschen so könnte es zu Problemen führen. Bisher ist mir kein Fall bekannt aber ausschließen kann man es auch nicht. Also zu erst immer die Texturen frei geben und anschließend des Rendercontex löschen.

== Das leidige Thema Alphakanal ==

Es gibt zwei Möglichkeiten einen Alphakanal in eine Textur zu integrieren. Der einfachste und schnellste Weg ist, wenn sich dieser Kanal von Beginn an in die Textur befindet. Dazu wird ein Grafikprogramm benötigt welches so etwas unterstützt und ein Dateiformat welches das Speichern eines Alphakanals ermöglicht. Ein solches Programm ist zum Beispiel [http://www.gimp.org/ Gimp]. Also mögliche Dateiformate kämen TGA's und PNG's in Frage. Alle anderen Formate unterstützen keinen Alphakanal. Sollte man sich für diesen Weg entscheiden so genügt es dann ganz normal die Textur zu laden und zu benutzen und schon besitzen wir einen funktionierenden Alphakanal. Ich persönlich empfehle bis auf wenige Ausnahmen immer diesen Weg.

Nichts desto trotz habe ich ja gesagt, dass es noch eine Möglichkeit gibt. Bei diesem Weg haben wir Alphakanal und RGB Daten in zwei getrennten Bildern vorliegen. Aber wie bekommen wir das jetzt in ein Bild? Dafür bietet die glBitmap die Möglichkeit einen Alphakanal aus einem separaten Bild zu laden. Zu Beginn benötigen wir jedoch wieder eine Instanz der Klasse und es müssen schon normale Bilddaten geladen worden sein. Und ganz Wichtig damit es überhaupt funktioniert. Der Aufruf muss vor GenTexture stattfinden, da sonst die Textur bereits an OpenGL übergeben wurde.

fTexture.AddAlphaFromFile('myTex\Wall_alpha.bmp'); // Alphakanal aus Datei laden

Das war alles nun sind wir im Besitz einer Textur mit einem Alphakanal. Es besteht unter anderem auch die Möglichkeit den Alphakanal aus verschiedenen anderen Quellen zu laden (Resourcen, Streams, TBitmap). Zusätzlich dazu kann man den Kanal aber auch dynamisch erstellen. Dafür existiert die Methode AddAlphaFromFunc. Die Findigen unter euch habe aber bestimmt schon herausgefunden, dass man bei alle Methoden solch eine Function übergeben kann. Näheres dazu findet ihr im Abschnitt e = mc²

Etwas was häufiger gebraucht wird habe ich von Hause aus schon implementiert. Und zwar das Erstellen eines Alphakanals anhand einer Farbe.

fTexture.AddAlphaFromColorKey(Red, Green, Blue, Deviation); // Alphakanal anhand einer Farbe hinzufügen

Dabei wird nur auf vollkommen durchlässig und nicht durchlässig unterschieden. Alle Pixel die die angegebene Farbe besitzen werden dabei als 0 (nicht Sichtbar) in den Alphakanal geschrieben alle anderen erhalten 255 (Sichtbar). Die Deviation bestimmt eine Abweichung um der die Farben abweichen dürfen um trotzdem noch als Transparent erkannt zu werden. Speziell für JPEG's ist das nicht unwichtig, da die Bilder beim Komprimieren leicht abgewandelt werden.

Damit die OpenGL Primitiven jetzt transparent dargestellt werden muss der [[GlAlphaFunc|Alphatest]] oder das [[glBlendFunc|Blending]] aktiviert sein. Sonst nützt einem der Alphakanal nicht sonderlich viel.

Entfernen kann man einen Alphakanal natürlich auch. Dazu genügt der Aufruf von RemoveAlpha. Dieser muss natürlich nicht mit der glBitmap erstellt worden sein. Er kann auch aus einer Datei geladen worden sein.

fTexture.RemoveAlpha; // entfernt den Alphakanal

== Texturen konfigurieren ==

Hier beginnt jetzt der Teil der für die Meisten recht wichtig sein dürfte. Bisher haben wir ja nur Daten geladen und diese an OpenGL übergeben. Nun wollen wir aber ein wenig an den Einstellungen rumschrauben und sehen was wir daraus machen können.

Folgende Einstellungsmöglichkeiten verändern ausschließlich nur das Verhalten der glBitmap. Sie haben keinen Einfluss auf die resultierende Textur.

DeleteTextureOnFree ist vom Typ Boolean und gibt an ob beim Freigeben der Klasse die Texture auch freigegeben wird oder ob weiter existieren darf. Standard wird sie mit freigegeben.

FreeDataAfterGenTexture ist vom Typ Boolean und gibt an ob die Bilddaten nach dem Erzeugen der Textur aus dem Hauptspeicher entfernt werden sollen oder nicht. Im Normalfall werden sie das auch.

Target ist vom Typ Cardinal und bestimmt das OpenGL Target. Wird von den Klassen auf den Standardwert gesetzt und muss nur dann auf einen anderen Wert gesetzt werden, wenn ein anderes Target verwendet werden soll. Zum Beispiel bei der Verwendung von Texture_rectangle. Es sollte aber immer direkt nach dem erstellen gesetzt werden, da die Textur sonst unbrauchbar gemacht werden könnte.

Format ist ein Aufzählungstyp und er erlaubt 4 Werte.
<table border="0" rules="all">
<tr>
<td>tfDefault</td>
<td>Dabei wird das Standardformat des Grafikkartentreibers benutzt. Je nach eingestellter Qualität kann dies 16 oder 32 Bit sein.</td>
</tr>
<tr>
<td>tf16Bit</td>
<td>Hier wird die Textur in 16Bit abgelegt.</td>
</tr>
<tr>
<td>tf32Bit</td>
<td>Hier wird die Textur in 32Bit abgelegt.</td>
</tr>
<tr>
<td>tfCompressed</td>
<td>Bei diesem Format wird zu erst geschaut ob eines der folgenden Kriterien erfüllt ist. Extension GL_ARB_texture_compression, OpenGL Version 1.3 oder die Extension GL_EXT_texture_compression_s3tc. Sollten alle 3 Möglichkeiten nicht funktionieren so wird das Standardformat vom Grafikkartentreiber benutzt.</td>
</tr>
</table>

MipMap ist ebenfalls ein Aufzählungstyp und er erlaubt 3 Werte.
<table border="0" rules="all">
<tr>
<td>mmNone</td>
<td>Wie man vermuten könnte werden hierbei keine Mipmaps erstellt.</td>
</tr>
<tr>
<td>mmMipmap</td>
<td>Ähnlich wie bei komprimierten Texturen werden zu erst verschiedene neue Möglichkeiten überprüft. Ab OpenGL Version 1.4 oder mit der Extension GL_SGIS_generate_mipmap unterstützt die Grafikkarte ein generieren der [[Mipmaps]]. Das ist natürlich wesentlich schneller als der Weg ausschließlich über die Software. Sollte es keinen anderen Weg geben so werden die [[Mipmaps]] mittels der GLU generiert.</td>
</tr>
<tr>
<td>mmMipmapGlu</td>
<td>In diesem Falle werden die [[Mipmaps]] ausschließlich mit der GLU erstellt.</td>
</tr>
</table>

Mithilfe der Methoden SetFilter und SetWrap können das Filterverhalten und das Beschränken der Texturkoordinaten angepasst werden. Eine genaue Auflistung möglicher Werte findet man beim Artikel zu [[glTexParameter]]. Das Aufrufen der Methoden ist überall dort möglich wo auch [[gTexParameter]] gültig ist. Mögliche Fehlerhafte Werte werden automatisch auf die vorhandene Textur angepasst. So wird bei SetFilter niemals ein [[MipMaps|MipMap]] bei die Filterung eingestellt wenn keine [[MipMaps]] erzeugt wurden. Das würde sonst dazu führen, dass die Textur nicht dargestellt werden könnte.

FlipVert und FlipHorz sind Methoden die nichts anderes machen als das Bild entlang der entsprechenden Richtung (Vertikal und Horizontal) zu spiegeln. Dies wäre auch mit der Funktionsschnittstelle möglich aber besonders bei FlipVert wäre es unpraktisch da wir so nicht die komplette Zeile am Stück kopieren könnten, sondern nur Pixel für Pixel.

Zum Invertieren des Bildes genügt es die Methode Invert aufzurufen. Sie bekommt zwei boolsche Parameter mit denen man steuern kann was man invertieren möchte. Einen für RGB und einen für den Alphakanal.

Die Methode ToNormalMap wurde implementiert um aus einer 2D Textur eine NormalMap zu erzeugen. Er funktioniert ähnlich wie das NormalMapPlugin für Gimp. Die Methode bekommt 3 Parameter. Der Erste gibt an mit welcher Methode die Normalmap berechnet werden soll. Mögliche Werte hierfür sind
<table border="0" rules="all">
<tr>
<td>nm4Samples</td>
<td>Hierbei werden die jeweils geradlinigen benachbarten Pixel zu gleichen Teilen in die Berechnung einbezogen. (Oben, Unten Recht und Links). Diese Methode ist die einfachste, schnellste und empfindlichste gegenüber Farbvariationen.</td>
</tr>
<tr>
<td>nmSobel</td>
<td>Mit dieser Methode werden fließen benachbarten Pixel zu gleichen Teilen in die Berechnung ein.</td>
</tr>
<tr>
<td>nm3x3</td>
<td>Bei diese Methode fließen auch alle benachbarten Pixel in die Berechnung ein. Die diagonalen Pixel werden Doppelt gewertet. Die NormalMap wirkt so ruhiger und nicht so anfällig gegen kleine Farbveränderungen.</td>
</tr>
<tr>
<td>nm5x5</td>
<td>Diese Methode benutzt eine Matrix von 5*5 Pixeln um Ihre Berechnungen durch zu führen. Je weiter die Punkte vom Mittelpunkt entfernt sind so geringer wird deren Einfluss.</td>
</tr>
</table>
Der zweite Parameter gibt eine Skalierung an. Mögliche Werte hierfür liegen im Bereich von -100 bis 100. Bei einer Skalierung von 0 würde sich die Normalmap Wohlgefallen auflösen, da sie dann praktisch eine gerade Fläche darstellen würde. Die Textur dürfte dann außergewöhnlich gleichfarbig blau werden. 
Mit dem dritten und letzten Parameter kann man die Berechnung der Normalmap von den RGB Werten auf den Alphakanal verschieben. Die Berechnung zieht sich dann nicht mehr die RGB Werte sondern den Alphakanal zu Rate. Der genaue Nutzen davon liegt zwar momentan selber vor mir verborgen aber wer weiß wozu man so etwas später noch gebrauchen kann. ;-)

== e = mc² ==

Hierbei handelt es sich um eine Möglichkeit die Texturdaten zu manipulieren. Die Schnittstelle wurde so gestaltet, dass sie sehr flexibel und typisiert ist. Sprich, dass man immer genau weiß worum es sich handelt und welche Felder unterstützt werden. Eine einfache Handhabung und eine gute Ausführungsgeschwindigkeit waren natürlich auch sehr wichtige Punkte dabei. Finden kann man die Funktionsschnittstelle beim Hinzufügen des Alphakanals oder immer wenn man möchte durch die Methode AddFunc. Es gibt außerdem noch eine Reihe von Funktionen, die intern die Schnittstelle benutzen. Das wären zum Beispiel die Funktionen Invert, AddAlphaFromColokey, ToNormalMap und FillWithColor. Die Klasse TglBitmapNormalMap generiert ihre Texturen zum Beispiel mit der Schnittstelle.

Die Arbeitsweise der Funktionsschnittstelle ist recht einfach. Es wird nichts anderes gemacht als 1 Mal Zeile für Zeile den Pointer eines jeden Pixels an eine Funktion zu Übergeben und darauf zu vertrauen, dass sie das Richtige tut. Um die Ausführung zu Beschleunigen wird ausschließlich mit Pointern gearbeitet. Die Funktionen bekommen die Instanz des Objektes, die Größe, die Position, das Quellpixel, das Zielpixel und einen Pointer auf benutzerdefinierte Daten übergeben. Das ist natürlich eine ganze Menge Holz was da an Daten übergeben aber das ist alles notwendig um die gewünschte Flexibilität erreichen zu können.

Betrachten wir das ganze mal an einem Beispiel. Und zwar dem Aufruf von Invert. Zu erst einmal der Aufruf der Funktion.

if ((UseRGB) or (UseAlpha))
then AddFunc(glBitmapInvertFunc, False, Pointer(Integer(UseAlpha and HasAlpha) shl 1 or Integer(UseRGB)));

In Zeile 1 handelt es sich lediglich um eine kleine Sicherheit. Es bringt ja nichts, wenn man eine Funktion ausführen möchte die keinen Nutzen hat. Zeile 2 Ruft die Methode AddFunc auf. Diese Methode bekommt als erstes unsere Funktion übergeben. Zu deren Aufbau komme ich gleich. Als Zweites bekommt AddFunc gesagt ob sie eine Kopie des Bildes erstellen soll. Für pixelübergreifende Funktionen ist dies unerlässlich, da man sich sonst seine noch benötigten Daten überschreiben würde. Der dritte Wert ist ein Pointer der zusätzliche Informationen hält. In diesem Falle handelt es sich lediglich um ein Bitset bei dem Bit 2 den Alphakanal und Bit 1 die RGB Werte repräsentiert. Es könnte sich dabei aber auch um einen Pointer auf ein Record handeln.

procedure glBitmapInvertFunc(Sender : TglBitmap; const Position, Size: TglBitmapPixelPosition;
const Source, Dest: TglBitmapPixelData; const Data: Pointer);
begin
if (Integer(Data) and $1 > 0) then begin
Dest.ptRed^ := not Dest.ptRed^;
Dest.ptGreen^ := not Dest.ptGreen^;
Dest.ptBlue^ := not Dest.ptBlue^;
end;

if (Integer(Data) and $2 > 0) then begin
Dest.ptAlpha^ := not Dest.ptAlpha^;
end;
end;

Position und Size beinhalten die Aktuelle Position des Pixels und die Größe des Bildes. Das Record TglBitmapPixelPosition beinhält 4 Werte. Fields, X, Y, Z. Fields beschreibt welche Felder überhaupt zur Verfügung stehen. Mögliche Werte Dafür sind ffX, ffY und ffZ. Wofür X, Y und Z stehen erkläre ich jetzt mal nicht, dass sollte jedem klar sein. Bei einem 2D Bitmap sind üblicherweise die Felder X und Y mit leben gefüllt. Das Feld Z liegt brach.

Source und Dest beinhalten die Pixeldaten. Die Records sind ziemlich genau so aufgebaut wie das für die Position. Es gibt einen Wert Fields. Mögliche Werte für ihn sind ffRed, ffGreen, ffBlue und ffAlpha. Diese Felder sind anders als bei bei Position keine richtigen Werte sondern Pointer die Direkt auf die Farbwerte in den Bildern zeigen. Es gibt deswegen Source und Dest, da es ja die Möglichkeit gibt eine Kopie des Bildes zu erstellen. Sollte ohne Kopie gearbeitet werden so sind Source und Dest gleich. Bei hinzufügen eines Alphakanals bezieht sich Source auf die Pixeldaten im dem Quellbild und Dest wie gewohnt auf die Daten im Zielbild.

In dem obigen Beispiel werden die Bits des Parameters Data ausgewertet und die entsprechenden Kanäle negiert. Der Komplexibilität sind kaum Grenzen gesetzt. Alle Wissensdurstigen unter euch sollten sich dann auch mal die Methode ToNormalMap anschauen. Dort werden zwei Funktionen aufgerufen. In der Ersten werden Daten gesammelt mit denen in der Zweiten die Normalmap berechnet wird. Oder auch die Klasse TglBitmapNormalMap. In dieser wird eine generelle Berechnungsroutine aufgerufen. Diese bekommt aber für jede Fläche der Map eine andere interne Methode übergeben. Mit dieser werden dann die Werte für jedes Pixel gefüllt.

Noch ein Wort für alle Geschwindigkeitsfanatiker. Ich hatte ein mal spaßeshalber die Methode FlipHorz nachgebaut und die Geschwindigkeit gemessen. Das Ergebnis hat mich selber sehr angenehm überrascht. Die Hardcodierte super optimierte Methode benötigte bei 300 Aufrufen, auf ein 512x512 Pixel großes Bild ca. 5 Sekunden. Die Methode mit dem Funktionsaufruf benötigte Lediglich 300 ms länger. Ich selber hätte eher mit dem Doppelten der Zeit gerechnet.

== Cubemaps mit glBitmap ==

Das einzige worin sich CubeMaps von 2D Texturen unterscheidet ist das Laden. Aber das ist auch nicht viel komplizierter als bei 2D Texturen. Die Handhabung mit den Texturen (Binden, Frei geben) ist wie bei 2D Texturen weswegen ich das auch nicht noch einmal extra wiederholen werde.

=== Procedural ===

Wie auch bei den 2D Texturen haben wir die Auswahl zwischen zwei möglichen Wegen. Der procedurale Weg unterscheidet sich lediglich in der Anzahl der angegebenen Texturen. Das sind diesmal natürlich ein paar mehr.

var
Texture: TGLuint;

// Cubemaps laden
LoadCubeMap('xpos.bmp', 'xneg.bmp', 'ypos.bmp', 'yneg.bmp', 'zpos.bmp', 'zneg.bmp', Texture, False);

Die ersten 6 Parameter geben die jeweils 6 Texturen an. Die Namen der Parameter geben auch gleichzeitig deren Ziel an. Also immer schön auf die Reihenfolge achten. In dem Siebten wird die Textur ID geschrieben und der Achte gibt an ob aus Resourcen geladen werden soll oder nicht.

=== Objekt orientiert ===

Der Objekt orientierte Weg gestaltet sich dieses mal ein wenig schreibintensiver. Es müssen ja auch schließlich 6 Texturen geladen werden. Aber das kann man auch praktischerweise in eine Schleife packen. Das praktische daran ist, dass wir alles mit nur einer Klasseninstanz lösen können (und auch müssen).

fCubeMap := TglBitmapCubeMap.Create; // Instanz der Klasse erstellen
fCubeMap.LoadFromFile('xpos.jpg'); // Datei Laden

Die Textur wird normal angelegt und es wird wie gewöhnt ein Bild in den Speicher der Klasse geladen. Dieses Bild verhält sich wie jedes andere Bild. Es kann also wie gewöhnt manipuliert werden. Zum Beispiel durch die Funktionsschnittstelle.

fCubeMap.GenerateCubeMap(GL_TEXTURE_CUBE_MAP_POSITIVE_X); // Einzelnen Teil übergeben

Wenn die Textur also bereit zum Übergeben ist, dann müssen wir GenerateCubeMap mit dem entsprechenden Teil der Cubemap aufrufen. In diesem Falle ist es die positive X Achse. Das müssen wir dann natürlich noch mit allen anderen Maps machen. Also Bild laden, evtl bearbeiten und dann an OpenGL übergeben. Die Reihenfolge der Maps spielt hierbei keine Rolle. Wichtig ist nur, dass sie die selbe Auflösung und das selbe Format haben. Die Methode GenTexture steht bei dieser Klasse nicht zur Verfügung, da beim ersten Aufruf von GenerateCubeMap automatisch die OpenGL Textur erzeugt wird. Die CubeMap ist nur dann einsetzbar, wenn alle Maps erfolgreich mit Daten versorgt wurden.

Beim Binden der CubeMap existiert ein zusätzlicher Parameter mit dem man die Aktivierung der automatische Generation der Texturkoordinaten deaktivieren kann. Standard ist dieses eingeschalten. Ähnlich wie beim Binden einer Textur. Dort kann man verhindern, dass das Target aktiviert wird.

== Normalmaps mit glBitmap ==

NormalMaps sind nichts anderes als Spezielle Cubemaps. Sie dienen dazu um Per Pixel Normale auch auf Systemen ohne Shaderhardware zu ermöglichen. Benutzt werden kann das zum Beispiel bei Bumpmapping mit [[GL_ARB_texture_env_dot3]].

=== Procedural ===

Wie auch bei den 2D Texturen und Cubemaps haben wir die Auswahl zwischen zwei möglichen Wegen. Da diese Texturen dynamisch generiert werden fällt die Anzahl der Parameter ziemlich gering aus. Sie besteht lediglich aus einer Texturgröße. In diesem Falle haben die resultierenden Texturen eine Größe von 32x32 Pixeln. Der zweite Parameter ist ein altbekannter von uns. Er ermöglicht es uns eine TexturID zu empfangen. Auf die Handhabung mit dieser ID gehe ich nicht noch einmal ein, da das oberhalb schon oft genug besprochen wurde.

var
Texture: TGLuint;

// Normalmaps erzeugen
LoadNormalMap(32, Texture);

=== Objekt orientiert ===

Dieser Weg ist etwa genau so schreibintensiv wie der Procedurale. Hierbei wird eine Normalmap erstellt bei der einzelnen Texturen eine Größe von 32x32 Pixeln haben.

fNormalMap := TglBitmapNormalMap.Create; // Instanz der Klasse erstellen
fNormalMap.GenerateNormalMap(32); // Normalmap erzeugen

Erstaunlich aber wahr. Das war bereits alles. Von nun an kann die Textur wie jede andere CubeMap auch verwendet werden.

== Bekannte Probleme und Einschränkungen ==

Vor einer Weile wurde im Forum die Frage gestellt warum die glBitmap beim Laden eines BMP's einen "Stream Read Error" produziert. Da das Bitmap nun mal ein sehr einfaches Format ist hat mich das auch sehr stark verwundert. Nach langem hin und her Rätseln kam ich dann dennoch darauf was das Problem war. Es lag daran, dass das Bitmap mit MS Paint abgespeichert wurde. Dieser war aber der Meinung er müsse im Bitmapheader eine Größe angeben die 2 Bytes größer war als die eigentlichen Daten. Diese 2 Bytes wurden auch aufgefüllt aber leider ist das TBitmap, welches ich zum Laden verwende, nicht so tolerant um darüber hinweg zu sehen. Und so bekommt man einen Fehler beim Laden. Den selben Fehler würde man auch bekommen wenn man das Bild in einem TImage anzeigen wollte.

Abhelfen kann man dies in dem man ein [http://www.gimp.org/ alternatives Grafikprogramm (Gimp)] verwendet oder das Bild einmal mit dem Bildbetrachter [http://www.irfanview.de/ IrfanView] öffnet und abspeichert.

Es muss nicht bei jedem mit MS Paint abgespeicherten Bild auftreten.

Glbitmap loader

2005-07-05T08:54:49Z

Lossy eX: /* Normalmaps Procedural */

{{unvollständig}}
= glBitmap - Texturenloader =

== Warum das Ganze und wo kann ich sie finden? ==

Früher benutzte ich die glBMP, da sie so "schön" Objekt orientiert war. Leider hatte mein Grafiktreiber zu der Zeit einen Fehler bei der Auswahl des Texturformates. So führte es dazu, dass sobald ich eine Textur mit Alphakanal und dem Standard Texturformat an OpenGL übergab, er als Farbtiefe 16 Bit verwendete. Wenn ich ein Foto genommen hätte wäre mir das wahrscheinlich gar nicht aufgefallen aber dummerweise (oder glücklicherweise) hatte ich aber eine Textur mit einem weichem Farbverlauf. Wie zu erwarten war sah das natürlich alles ziemlich schrecklich aus. Bis dahin kann der Loader ja nichts dafür wenn in einem Treiber ein Fehler existiert. Nur das kuriose an dem Ganzen war, dass meine Textur in Wirklichkeit gar keinen Alphakanal haben durfte. Also habe ich mich auf die Suche nach der Ursache gemacht und bin auch prompt fündig geworden. Der Loader war der Meinung er müsse alle Texturen mit einem Alphakanal versehen ungeachtet der Tatsache ob sie nun einen hatten oder eben nicht. Das ist natürlich eine Sache mit der ich mich nicht abfinden wollte. Kurz darauf begann ich also eine Ableitung der glBMP Texturenklasse zu erstellen und dort musste ich mit Schrecken feststellen, dass die Rechte in der Klasse so ungünstig vergeben wurden, dass ich keine andere Wahl gehabt hätte als direkt die Unit zu editieren. Da ich ungern externe Quellen editiere habe ich für mich die andere Alternative entschieden. Was dabei rausgekommen ist sieht man ja jetzt.

Gefunden werden kann sie entweder im DGL-SDK oder auf der [http://www.dev-center.de/index.php?cat=header&file=glbitmap Webseite] von [[Benutzer:Lossy eX|Lossy eX]].

== Allgemeines und Features ==

Dieser Artikel geht nicht darauf ein was zu tun ist um in OpenGL eine Textur darstellen zu können. In ihm werde ich lediglich darauf eingehen was man tun kann und muss um mittels der glBitmap eine Textur laden zu können. Außerdem werden die verfügbaren Einstellungen und ihre Wirkungen erklärt. Für alles andere wäre es besser das [[Tutorial_lektion4|Tutorial über Texturen]] durchzulesen.

Der wichtigste Unterschied zu den bestehenden Loadern bringe ich gleich einmal als erstes. Die glBitmap legt die Texturen anders im Speicher ab. Um zwar im speziellen meine ich damit die 2D Texturen. Bei bestehenden Loadern werden diese Texturen mit der untersten Zeile zu erst im Speicher abgelegt. In der glBitmap werden sie aber mit der obersten Zeile zu erst abgelegt. Man könnte auch sagen, dass sie bei den bestehenden Loadern auf dem Kopf stehen. Beide Möglichkeiten funktionieren und sind korrekt. Das Einzige was sich in diesem Zusammenhang ändert ist die [[glTexCoord| Adressierung der Texturen]]. Sie müssen entsprechend geändert werden. Sollte das nicht möglich sein so besteht mit der Methode FlipVert die Möglichkeit die Textur zu spiegeln. Näheres in Abschnitt [[Glbitmap_loader#Texturen_konfigurieren|Texturen konfigurieren]]. Im Normalfall sollte das andere Verhalten nicht zu Problemen führen sondern die Arbeit damit vereinfachen und verständlicher gestalten.

Die glBitmap holt sich ihre Daten ausschließlich aus Streams. Das zugrundeliegende Format wird automatisch anhand des Inhaltes der Daten ausgewählt. Es besteht also kein Notwendigkeit daran, dass der Entwickler wissen muss um welches Format es sich in Wirklichkeit handelt.

=== unterstütze Formate ===

* Windows Bitmaps (*.bmp) Wird Automatisch auf 24 Bit gesetzt sollte es kleiner sein.
* JPEG (*.jpg)
* TARGA (*.tga) komprimiert und unkomprimiert, 24 und 32 Bit. Ursprung unten links oder oben links
* Portable Network Graphics (*.png) 24 Bit mit oder ohne Alphakanal. Es wird eine zusätzliche Bibliothek benötigt.
Es besteht auch die Möglichkeit die Bilddaten dynamisch generieren zu lassen oder sie aus einer Instanz der Klasse TBitmap zu laden. Diese Instanz muss dann aber als Pixelformat 24 oder 32 Bit haben.

Um PNG's laden zu können muss eine externe Bibliothek namens [http://pngdelphi.sourceforge.net/ PNGImage] eingebunden und das Define pngimage hinzugefügt werden. Alternativ dazu kann das Define auch in der glBitmap auskommentiert werden.

== Texturen laden ==

Das Laden von Texturen kann auf 2 Weg geschehen. Bei Beiden ist aber zu beachten, dass OpenGL richtig initialisiert worden sein muss bevor man eine Textur erzeugen kann. Was noch sehr wichtig ist. Es sollte niemals eine Textur bei jedem Rendervorgang angelegt und freigegeben werden! Es ist viel effektiver, wenn man die Textur zu beginn lädt und so lange im Speicher behält bis sie nicht mehr benötigt wird. Wenn man sie erst später benötigt, dann kann man sie auch später noch nachladen aber auch dann sollte sie so lange wie nötig existieren.

=== Procedural ===

Hierbei genügt der Aufruf einer einzelnen Methode um eine Textur zu laden und diese an OpenGL zu übergeben. Allerdings auf Grund der Einfachheit steht nur das Laden aus Dateien oder Ressourcen zur Verfügung. Zusätzliche Funktionalität können dabei nicht benutzt werden. Generell empfehle ich immer die Objekt orientierte Variante.

var
Texture: TGLuint;

LoadTexture('myTex\Wall.bmp', Texture, False); // Datei laden

Damit wird die Datei Wall.bmp geladen und die TextureID wird in die Variable Texture geschrieben. Wenn die Textur dann benötigt wird, dann muss man diese entsprechend mit [[glBindTexture]] binden und das benötigte Texturtarget mit [[glEnable]] aktivieren. Das Target ist üblicherweise GL_TEXTURE_2D. Wenn die Textur nicht mehr benötigt wird sollte sie mit [[glDeleteTextures]] auch wieder frei gegeben werden.

=== Objekt orientiert ===

Dieser Abschnitt beschäftigt sich ausschließlich mit den 2D Texturen. Aber grundsätzlich lässt sich alles hier erwähnte auch auf die 1D Texturen und die Cubemaps übertragen.
Der Objekt orientierte Weg erfordert zwar eine wenig mehr Schreibarbeit aber nur so kann man den vollen Funktionsumfang der glBitmap genießen.

Als Erstes müssen wir eine Instanz der Texturenklasse definieren. Dies tun wir vorzugsweise als Member des Fensters auf dem wir zeichnen.

TForm1 = class(TForm)
// Verschiene Elemente und Events des Fensters
private
fTexture: TglBitmap2D; // Instanz unserer Textur
end;

Nun müssen wir der Textur noch Leben einhauchen.

procedure TForm1.FormShow(Sender: TObject);
begin
// OpenGL Initialisieren

fTexture := TglBitmap2D.Create; // Instanz der Klasse erstellen
fTexture.LoadFromFile('myTex\Wall.bmp'); // Datei laden
fTexture.GenTexture; // geladene Textur an OpenGL übergeben
end;

Für Schreibfaule besteht auch noch die Möglichkeit in einem überladenen Konstruktor einem Dateinamen anzugeben.

fTexture := TglBitmap2D.Create('myTex\Wall.bmp'); // Instanz erstellen und Datei laden
fTexture.GenTexture; // geladene Textur an OpenGL übergeben

In GenTexture wird im Normalfall immer überprüft ob die Textur eine gültige Größe hat. Sollte diese Überprüfung nicht gewünscht sein so kann man diese mit einem optionalen Parameter deaktivieren. Diese Überprüfung testet auch ob die Texturgröße eine Potenz von 2 ist (1, 2, 4, 8, 16 usw.) und wenn nicht ob solche Texturen von dem Rendercontex unterstützt werden.

fTexture.GenTexture(False); // Es wird keine Prüfung der Texturgröße vorgenommen.

Wenn kein Fehler aufgetreten ist und alles so funktioniert hat wie es sein sollte, dann kann die Textur benutzt werden.

fTexture.Bind; // Textur und entsprechendes Target wird aktiviert.

Sollte es nicht gewünscht werden, dass auch gleichzeitig das Target aktiviert wird so muss Bind mit dem Parameter False aufgerufen werden. Damit wird nur noch die Textur gebunden.

Sollte man die Textur einmal nicht mehr benutzen wollen so genügt es entweder eine andere Textur zu binden oder Unbind von der Texturenklasse aufzurufen. Damit wird die Textur mit der TexturID 0 gebunden und das Target deaktiviert. Auch hier existiert wieder der Parameter der es verhindert, dass das Target deaktiviert wird.

Wenn die Anwendung beendet wird müssen wir auch hier unsere Textur wieder frei geben. Dies geschieht so.

fTexture.Free; // Textur wieder frei geben.

Hierbei ist zu beachten, dass dies nach Möglichkeit vor dem Löschen des Rendercontex geschehen sollte, da so die Textur zu einem sinnvollem Zeitpunkt gelöscht werden kann. Wenn der Rendercontex nicht mehr existiert, so sollte die Textur auch nicht mehr existieren und wenn man dann noch einmal versucht sie zu löschen so könnte es zu Problemen führen. Bisher ist mir kein Fall bekannt aber ausschließen kann man es auch nicht. Also zu erst immer die Texturen frei geben und anschließend des Rendercontex löschen.

== Das leidige Thema Alphakanal ==

Es gibt zwei Möglichkeiten einen Alphakanal in eine Textur zu integrieren. Der einfachste und schnellste Weg ist, wenn sich dieser Kanal von Beginn an in die Textur befindet. Dazu wird ein Grafikprogramm benötigt welches so etwas unterstützt und ein Dateiformat welches das Speichern eines Alphakanals ermöglicht. Ein solches Programm ist zum Beispiel [http://www.gimp.org/ Gimp]. Also mögliche Dateiformate kämen TGA's und PNG's in Frage. Alle anderen Formate unterstützen keinen Alphakanal. Sollte man sich für diesen Weg entscheiden so genügt es dann ganz normal die Textur zu laden und zu benutzen und schon besitzen wir einen funktionierenden Alphakanal. Ich persönlich empfehle bis auf wenige Ausnahmen immer diesen Weg.

Nichts desto trotz habe ich ja gesagt, dass es noch eine Möglichkeit gibt. Bei diesem Weg haben wir Alphakanal und RGB Daten in zwei getrennten Bildern vorliegen. Aber wie bekommen wir das jetzt in ein Bild? Dafür bietet die glBitmap die Möglichkeit einen Alphakanal aus einem separaten Bild zu laden. Zu Beginn benötigen wir jedoch wieder eine Instanz der Klasse und es müssen schon normale Bilddaten geladen worden sein. Und ganz Wichtig damit es überhaupt funktioniert. Der Aufruf muss vor GenTexture stattfinden, da sonst die Textur bereits an OpenGL übergeben wurde.

fTexture.AddAlphaFromFile('myTex\Wall_alpha.bmp'); // Alphakanal aus Datei laden

Das war alles nun sind wir im Besitz einer Textur mit einem Alphakanal. Es besteht unter anderem auch die Möglichkeit den Alphakanal aus verschiedenen anderen Quellen zu laden (Resourcen, Streams, TBitmap). Zusätzlich dazu kann man den Kanal aber auch dynamisch erstellen. Dafür existiert die Methode AddAlphaFromFunc. Die Findigen unter euch habe aber bestimmt schon herausgefunden, dass man bei alle Methoden solch eine Function übergeben kann. Näheres dazu findet ihr im Abschnitt e = mc²

Etwas was häufiger gebraucht wird habe ich von Hause aus schon implementiert. Und zwar das Erstellen eines Alphakanals anhand einer Farbe.

fTexture.AddAlphaFromColorKey(Red, Green, Blue, Deviation); // Alphakanal anhand einer Farbe hinzufügen

Dabei wird nur auf vollkommen durchlässig und nicht durchlässig unterschieden. Alle Pixel die die angegebene Farbe besitzen werden dabei als 0 (nicht Sichtbar) in den Alphakanal geschrieben alle anderen erhalten 255 (Sichtbar). Die Deviation bestimmt eine Abweichung um der die Farben abweichen dürfen um trotzdem noch als Transparent erkannt zu werden. Speziell für JPEG's ist das nicht unwichtig, da die Bilder beim Komprimieren leicht abgewandelt werden.

Damit die OpenGL Primitiven jetzt transparent dargestellt werden muss der [[GlAlphaFunc|Alphatest]] oder das [[glBlendFunc|Blending]] aktiviert sein. Sonst nützt einem der Alphakanal nicht sonderlich viel.

Entfernen kann man einen Alphakanal natürlich auch. Dazu genügt der Aufruf von RemoveAlpha. Dieser muss natürlich nicht mit der glBitmap erstellt worden sein. Er kann auch aus einer Datei geladen worden sein.

fTexture.RemoveAlpha; // entfernt den Alphakanal

== Texturen konfigurieren ==

Hier beginnt jetzt der Teil der für die Meisten recht wichtig sein dürfte. Bisher haben wir ja nur Daten geladen und diese an OpenGL übergeben. Nun wollen wir aber ein wenig an den Einstellungen rumschrauben und sehen was wir daraus machen können.

Folgende Einstellungsmöglichkeiten verändern ausschließlich nur das Verhalten der glBitmap. Sie haben keinen Einfluss auf die resultierende Textur.

DeleteTextureOnFree ist vom Typ Boolean und gibt an ob beim Freigeben der Klasse die Texture auch freigegeben wird oder ob weiter existieren darf. Standard wird sie mit freigegeben.

FreeDataAfterGenTexture ist vom Typ Boolean und gibt an ob die Bilddaten nach dem Erzeugen der Textur aus dem Hauptspeicher entfernt werden sollen oder nicht. Im Normalfall werden sie das auch.

Target ist vom Typ Cardinal und bestimmt das OpenGL Target. Wird von den Klassen auf den Standardwert gesetzt und muss nur dann auf einen anderen Wert gesetzt werden, wenn ein anderes Target verwendet werden soll. Zum Beispiel bei der Verwendung von Texture_rectangle. Es sollte aber immer direkt nach dem erstellen gesetzt werden, da die Textur sonst unbrauchbar gemacht werden könnte.

Format ist ein Aufzählungstyp und er erlaubt 4 Werte.
<table border="0" rules="all">
<tr>
<td>tfDefault</td>
<td>Dabei wird das Standardformat des Grafikkartentreibers benutzt. Je nach eingestellter Qualität kann dies 16 oder 32 Bit sein.</td>
</tr>
<tr>
<td>tf16Bit</td>
<td>Hier wird die Textur in 16Bit abgelegt.</td>
</tr>
<tr>
<td>tf32Bit</td>
<td>Hier wird die Textur in 32Bit abgelegt.</td>
</tr>
<tr>
<td>tfCompressed</td>
<td>Bei diesem Format wird zu erst geschaut ob eines der folgenden Kriterien erfüllt ist. Extension GL_ARB_texture_compression, OpenGL Version 1.3 oder die Extension GL_EXT_texture_compression_s3tc. Sollten alle 3 Möglichkeiten nicht funktionieren so wird das Standardformat vom Grafikkartentreiber benutzt.</td>
</tr>
</table>

MipMap ist ebenfalls ein Aufzählungstyp und er erlaubt 3 Werte.
<table border="0" rules="all">
<tr>
<td>mmNone</td>
<td>Wie man vermuten könnte werden hierbei keine Mipmaps erstellt.</td>
</tr>
<tr>
<td>mmMipmap</td>
<td>Ähnlich wie bei komprimierten Texturen werden zu erst verschiedene neue Möglichkeiten überprüft. Ab OpenGL Version 1.4 oder mit der Extension GL_SGIS_generate_mipmap unterstützt die Grafikkarte ein generieren der [[Mipmaps]]. Das ist natürlich wesentlich schneller als der Weg ausschließlich über die Software. Sollte es keinen anderen Weg geben so werden die [[Mipmaps]] mittels der GLU generiert.</td>
</tr>
<tr>
<td>mmMipmapGlu</td>
<td>In diesem Falle werden die [[Mipmaps]] ausschließlich mit der GLU erstellt.</td>
</tr>
</table>

Mithilfe der Methoden SetFilter und SetWrap können das Filterverhalten und das Beschränken der Texturkoordinaten angepasst werden. Eine genaue Auflistung möglicher Werte findet man beim Artikel zu [[glTexParameter]]. Das Aufrufen der Methoden ist überall dort möglich wo auch [[gTexParameter]] gültig ist. Mögliche Fehlerhafte Werte werden automatisch auf die vorhandene Textur angepasst. So wird bei SetFilter niemals ein [[MipMaps|MipMap]] bei die Filterung eingestellt wenn keine [[MipMaps]] erzeugt wurden. Das würde sonst dazu führen, dass die Textur nicht dargestellt werden könnte.

FlipVert und FlipHorz sind Methoden die nichts anderes machen als das Bild entlang der entsprechenden Richtung (Vertikal und Horizontal) zu spiegeln. Dies wäre auch mit der Funktionsschnittstelle möglich aber besonders bei FlipVert wäre es unpraktisch da wir so nicht die komplette Zeile am Stück kopieren könnten, sondern nur Pixel für Pixel.

Zum Invertieren des Bildes genügt es die Methode Invert aufzurufen. Sie bekommt zwei boolsche Parameter mit denen man steuern kann was man invertieren möchte. Einen für RGB und einen für den Alphakanal.

== e = mc² ==

Hierbei handelt es sich um eine Möglichkeit die Texturdaten zu manipulieren. Die Schnittstelle wurde so gestaltet, dass sie sehr flexibel und typisiert ist. Sprich, dass man immer genau weiß worum es sich handelt und welche Felder unterstützt werden. Eine einfache Handhabung und eine gute Ausführungsgeschwindigkeit waren natürlich auch sehr wichtige Punkte dabei. Finden kann man die Funktionsschnittstelle beim Hinzufügen des Alphakanals oder immer wenn man möchte durch die Methode AddFunc. Es gibt außerdem noch eine Reihe von Funktionen, die intern die Schnittstelle benutzen. Das wären zum Beispiel die Funktionen Invert, AddAlphaFromColokey, ToNormalMap und FillWithColor. Die Klasse TglBitmapNormalMap generiert ihre Texturen zum Beispiel mit der Schnittstelle.

Die Arbeitsweise der Funktionsschnittstelle ist recht einfach. Es wird nichts anderes gemacht als 1 Mal Zeile für Zeile den Pointer eines jeden Pixels an eine Funktion zu Übergeben und darauf zu vertrauen, dass sie das Richtige tut. Um die Ausführung zu Beschleunigen wird ausschließlich mit Pointern gearbeitet. Die Funktionen bekommen die Instanz des Objektes, die Größe, die Position, das Quellpixel, das Zielpixel und einen Pointer auf benutzerdefinierte Daten übergeben. Das ist natürlich eine ganze Menge Holz was da an Daten übergeben aber das ist alles notwendig um die gewünschte Flexibilität erreichen zu können.

Betrachten wir das ganze mal an einem Beispiel. Und zwar dem Aufruf von Invert. Zu erst einmal der Aufruf der Funktion.

if ((UseRGB) or (UseAlpha))
then AddFunc(glBitmapInvertFunc, False, Pointer(Integer(UseAlpha and HasAlpha) shl 1 or Integer(UseRGB)));

In Zeile 1 handelt es sich lediglich um eine kleine Sicherheit. Es bringt ja nichts, wenn man eine Funktion ausführen möchte die keinen Nutzen hat. Zeile 2 Ruft die Methode AddFunc auf. Diese Methode bekommt als erstes unsere Funktion übergeben. Zu deren Aufbau komme ich gleich. Als Zweites bekommt AddFunc gesagt ob sie eine Kopie des Bildes erstellen soll. Für pixelübergreifende Funktionen ist dies unerlässlich, da man sich sonst seine noch benötigten Daten überschreiben würde. Der dritte Wert ist ein Pointer der zusätzliche Informationen hält. In diesem Falle handelt es sich lediglich um ein Bitset bei dem Bit 2 den Alphakanal und Bit 1 die RGB Werte repräsentiert. Es könnte sich dabei aber auch um einen Pointer auf ein Record handeln.

procedure glBitmapInvertFunc(Sender : TglBitmap; const Position, Size: TglBitmapPixelPosition;
const Source, Dest: TglBitmapPixelData; const Data: Pointer);
begin
if (Integer(Data) and $1 > 0) then begin
Dest.ptRed^ := not Dest.ptRed^;
Dest.ptGreen^ := not Dest.ptGreen^;
Dest.ptBlue^ := not Dest.ptBlue^;
end;

if (Integer(Data) and $2 > 0) then begin
Dest.ptAlpha^ := not Dest.ptAlpha^;
end;
end;

Position und Size beinhalten die Aktuelle Position des Pixels und die Größe des Bildes. Das Record TglBitmapPixelPosition beinhält 4 Werte. Fields, X, Y, Z. Fields beschreibt welche Felder überhaupt zur Verfügung stehen. Mögliche Werte Dafür sind ffX, ffY und ffZ. Wofür X, Y und Z stehen erkläre ich jetzt mal nicht, dass sollte jedem klar sein. Bei einem 2D Bitmap sind üblicherweise die Felder X und Y mit leben gefüllt. Das Feld Z liegt brach.

Source und Dest beinhalten die Pixeldaten. Die Records sind ziemlich genau so aufgebaut wie das für die Position. Es gibt einen Wert Fields. Mögliche Werte für ihn sind ffRed, ffGreen, ffBlue und ffAlpha. Diese Felder sind anders als bei bei Position keine richtigen Werte sondern Pointer die Direkt auf die Farbwerte in den Bildern zeigen. Es gibt deswegen Source und Dest, da es ja die Möglichkeit gibt eine Kopie des Bildes zu erstellen. Sollte ohne Kopie gearbeitet werden so sind Source und Dest gleich. Bei hinzufügen eines Alphakanals bezieht sich Source auf die Pixeldaten im dem Quellbild und Dest wie gewohnt auf die Daten im Zielbild.

In dem obigen Beispiel werden die Bits des Parameters Data ausgewertet und die entsprechenden Kanäle negiert. Der Komplexibilität sind kaum Grenzen gesetzt. Alle Wissensdurstigen unter euch sollten sich dann auch mal die Methode ToNormalMap anschauen. Dort werden zwei Funktionen aufgerufen. In der Ersten werden Daten gesammelt mit denen in der Zweiten die Normalmap berechnet wird. Oder auch die Klasse TglBitmapNormalMap. In dieser wird eine generelle Berechnungsroutine aufgerufen. Diese bekommt aber für jede Fläche der Map eine andere interne Methode übergeben. Mit dieser werden dann die Werte für jedes Pixel gefüllt.

Noch ein Wort für alle Geschwindigkeitsfanatiker. Ich hatte ein mal spaßeshalber die Methode FlipHorz nachgebaut und die Geschwindigkeit gemessen. Das Ergebnis hat mich selber sehr angenehm überrascht. Die Hardcodierte super optimierte Methode benötigte bei 300 Aufrufen, auf ein 512x512 Pixel großes Bild ca. 5 Sekunden. Die Methode mit dem Funktionsaufruf benötigte Lediglich 300 ms länger. Ich selber hätte eher mit dem Doppelten der Zeit gerechnet.

== Cubemaps mit glBitmap ==

Das einzige worin sich CubeMaps von 2D Texturen unterscheidet ist das Laden. Aber das ist auch nicht viel komplizierter als bei 2D Texturen. Die Handhabung mit den Texturen (Binden, Frei geben) ist wie bei 2D Texturen weswegen ich das auch nicht noch einmal extra wiederholen werde.

=== Procedural ===

Wie auch bei den 2D Texturen haben wir die Auswahl zwischen zwei möglichen Wegen. Der procedurale Weg unterscheidet sich lediglich in der Anzahl der angegebenen Texturen. Das sind diesmal natürlich ein paar mehr.

var
Texture: TGLuint;

// Cubemaps laden
LoadCubeMap('xpos.bmp', 'xneg.bmp', 'ypos.bmp', 'yneg.bmp', 'zpos.bmp', 'zneg.bmp', Texture, False);

Die ersten 6 Parameter geben die jeweils 6 Texturen an. Die Namen der Parameter geben auch gleichzeitig deren Ziel an. Also immer schön auf die Reihenfolge achten. In dem Siebten wird die Textur ID geschrieben und der Achte gibt an ob aus Resourcen geladen werden soll oder nicht.

=== Objekt orientiert ===

Der Objekt orientierte Weg gestaltet sich dieses mal ein wenig schreibintensiver. Es müssen ja auch schließlich 6 Texturen geladen werden. Aber das kann man auch praktischerweise in eine Schleife packen. Das praktische daran ist, dass wir alles mit nur einer Klasseninstanz lösen können (und auch müssen).

fCubeMap := TglBitmapCubeMap.Create; // Instanz der Klasse erstellen
fCubeMap.LoadFromFile('xpos.jpg'); // Datei Laden

Die Textur wird normal angelegt und es wird wie gewöhnt ein Bild in den Speicher der Klasse geladen. Dieses Bild verhält sich wie jedes andere Bild. Es kann also wie gewöhnt manipuliert werden. Zum Beispiel durch die Funktionsschnittstelle.

fCubeMap.GenerateCubeMap(GL_TEXTURE_CUBE_MAP_POSITIVE_X); // Einzelnen Teil übergeben

Wenn die Textur also bereit zum Übergeben ist, dann müssen wir GenerateCubeMap mit dem entsprechenden Teil der Cubemap aufrufen. In diesem Falle ist es die positive X Achse. Das müssen wir dann natürlich noch mit allen anderen Maps machen. Also Bild laden, evtl bearbeiten und dann an OpenGL übergeben. Die Reihenfolge der Maps spielt hierbei keine Rolle. Wichtig ist nur, dass sie die selbe Auflösung und das selbe Format haben. Die Methode GenTexture steht bei dieser Klasse nicht zur Verfügung, da beim ersten Aufruf von GenerateCubeMap automatisch die OpenGL Textur erzeugt wird. Die CubeMap ist nur dann einsetzbar, wenn alle Maps erfolgreich mit Daten versorgt wurden.

Beim Binden der CubeMap existiert ein zusätzlicher Parameter mit dem man die Aktivierung der automatische Generation der Texturkoordinaten deaktivieren kann. Standard ist dieses eingeschalten. Ähnlich wie beim Binden einer Textur. Dort kann man verhindern, dass das Target aktiviert wird.

== Normalmaps mit glBitmap ==

NormalMaps sind nichts anderes als Spezielle Cubemaps. Sie dienen dazu um Per Pixel Normale auch auf Systemen ohne Shaderhardware zu ermöglichen. Benutzt werden kann das zum Beispiel bei Bumpmapping mit [[GL_ARB_texture_env_dot3]].

=== Procedural ===

Wie auch bei den 2D Texturen und Cubemaps haben wir die Auswahl zwischen zwei möglichen Wegen. Da diese Texturen dynamisch generiert werden fällt die Anzahl der Parameter ziemlich gering aus. Sie besteht lediglich aus einer Texturgröße. In diesem Falle haben die resultierenden Texturen eine Größe von 32x32 Pixeln. Der zweite Parameter ist ein altbekannter von uns. Er ermöglicht es uns eine TexturID zu empfangen. Auf die Handhabung mit dieser ID gehe ich nicht noch einmal ein, da das oberhalb schon oft genug besprochen wurde.

var
Texture: TGLuint;

// Normalmaps erzeugen
LoadNormalMap(32, Texture);

=== Objekt orientiert ===

Dieser Weg ist etwa genau so schreibintensiv wie der Procedurale. Hierbei wird eine Normalmap erstellt bei der einzelnen Texturen eine Größe von 32x32 Pixeln haben.

fNormalMap := TglBitmapNormalMap.Create; // Instanz der Klasse erstellen
fNormalMap.GenerateNormalMap(32); // Normalmap erzeugen

Erstaunlich aber wahr. Das war bereits alles. Von nun an kann die Textur wie jede andere CubeMap auch verwendet werden.

== Bekannte Probleme und Einschränkungen ==

Vor einer Weile wurde im Forum die Frage gestellt warum die glBitmap beim Laden eines BMP's einen "Stream Read Error" produziert. Da das Bitmap nun mal ein sehr einfaches Format ist hat mich das auch sehr stark verwundert. Nach langem hin und her Rätseln kam ich dann dennoch darauf was das Problem war. Es lag daran, dass das Bitmap mit MS Paint abgespeichert wurde. Dieser war aber der Meinung er müsse im Bitmapheader eine Größe angeben die 2 Bytes größer war als die eigentlichen Daten. Diese 2 Bytes wurden auch aufgefüllt aber leider ist das TBitmap, welches ich zum Laden verwende, nicht so tolerant um darüber hinweg zu sehen. Und so bekommt man einen Fehler beim Laden. Den selben Fehler würde man auch bekommen wenn man das Bild in einem TImage anzeigen wollte.

Abhelfen kann man dies in dem man ein [http://www.gimp.org/ alternatives Grafikprogramm (Gimp)] verwendet oder das Bild einmal mit dem Bildbetrachter [http://www.irfanview.de/ IrfanView] öffnet und abspeichert.

Es muss nicht bei jedem mit MS Paint abgespeicherten Bild auftreten.

Glbitmap loader

2005-07-04T14:26:48Z

Lossy eX: /* Normalmaps mit glBitmap */

{{unvollständig}}
= glBitmap - Texturenloader =

== Warum das Ganze und wo kann ich sie finden? ==

Früher benutzte ich die glBMP, da sie so "schön" Objekt orientiert war. Leider hatte mein Grafiktreiber zu der Zeit einen Fehler bei der Auswahl des Texturformates. So führte es dazu, dass sobald ich eine Textur mit Alphakanal und dem Standard Texturformat an OpenGL übergab, er als Farbtiefe 16 Bit verwendete. Wenn ich ein Foto genommen hätte wäre mir das wahrscheinlich gar nicht aufgefallen aber dummerweise (oder glücklicherweise) hatte ich aber eine Textur mit einem weichem Farbverlauf. Wie zu erwarten war sah das natürlich alles ziemlich schrecklich aus. Bis dahin kann der Loader ja nichts dafür wenn in einem Treiber ein Fehler existiert. Nur das kuriose an dem Ganzen war, dass meine Textur in Wirklichkeit gar keinen Alphakanal haben durfte. Also habe ich mich auf die Suche nach der Ursache gemacht und bin auch prompt fündig geworden. Der Loader war der Meinung er müsse alle Texturen mit einem Alphakanal versehen ungeachtet der Tatsache ob sie nun einen hatten oder eben nicht. Das ist natürlich eine Sache mit der ich mich nicht abfinden wollte. Kurz darauf begann ich also eine Ableitung der glBMP Texturenklasse zu erstellen und dort musste ich mit Schrecken feststellen, dass die Rechte in der Klasse so ungünstig vergeben wurden, dass ich keine andere Wahl gehabt hätte als direkt die Unit zu editieren. Da ich ungern externe Quellen editiere habe ich für mich die andere Alternative entschieden. Was dabei rausgekommen ist sieht man ja jetzt.

Gefunden werden kann sie entweder im DGL-SDK oder auf der [http://www.dev-center.de/index.php?cat=header&file=glbitmap Webseite] von [[Benutzer:Lossy eX|Lossy eX]].

== Allgemeines und Features ==

Dieser Artikel geht nicht darauf ein was zu tun ist um in OpenGL eine Textur darstellen zu können. In ihm werde ich lediglich darauf eingehen was man tun kann und muss um mittels der glBitmap eine Textur laden zu können. Außerdem werden die verfügbaren Einstellungen und ihre Wirkungen erklärt. Für alles andere wäre es besser das [[Tutorial_lektion4|Tutorial über Texturen]] durchzulesen.

Der wichtigste Unterschied zu den bestehenden Loadern bringe ich gleich einmal als erstes. Die glBitmap legt die Texturen anders im Speicher ab. Um zwar im speziellen meine ich damit die 2D Texturen. Bei bestehenden Loadern werden diese Texturen mit der untersten Zeile zu erst im Speicher abgelegt. In der glBitmap werden sie aber mit der obersten Zeile zu erst abgelegt. Man könnte auch sagen, dass sie bei den bestehenden Loadern auf dem Kopf stehen. Beide Möglichkeiten funktionieren und sind korrekt. Das Einzige was sich in diesem Zusammenhang ändert ist die [[glTexCoord| Adressierung der Texturen]]. Sie müssen entsprechend geändert werden. Sollte das nicht möglich sein so besteht mit der Methode FlipVert die Möglichkeit die Textur zu spiegeln. Näheres in Abschnitt [[Glbitmap_loader#Texturen_konfigurieren|Texturen konfigurieren]]. Im Normalfall sollte das andere Verhalten nicht zu Problemen führen sondern die Arbeit damit vereinfachen und verständlicher gestalten.

Die glBitmap holt sich ihre Daten ausschließlich aus Streams. Das zugrundeliegende Format wird automatisch anhand des Inhaltes der Daten ausgewählt. Es besteht also kein Notwendigkeit daran, dass der Entwickler wissen muss um welches Format es sich in Wirklichkeit handelt.

=== unterstütze Formate ===

* Windows Bitmaps (*.bmp) Wird Automatisch auf 24 Bit gesetzt sollte es kleiner sein.
* JPEG (*.jpg)
* TARGA (*.tga) komprimiert und unkomprimiert, 24 und 32 Bit. Ursprung unten links oder oben links
* Portable Network Graphics (*.png) 24 Bit mit oder ohne Alphakanal. Es wird eine zusätzliche Bibliothek benötigt.
Es besteht auch die Möglichkeit die Bilddaten dynamisch generieren zu lassen oder sie aus einer Instanz der Klasse TBitmap zu laden. Diese Instanz muss dann aber als Pixelformat 24 oder 32 Bit haben.

Um PNG's laden zu können muss eine externe Bibliothek namens [http://pngdelphi.sourceforge.net/ PNGImage] eingebunden und das Define pngimage hinzugefügt werden. Alternativ dazu kann das Define auch in der glBitmap auskommentiert werden.

== Texturen laden ==

Das Laden von Texturen kann auf 2 Weg geschehen. Bei Beiden ist aber zu beachten, dass OpenGL richtig initialisiert worden sein muss bevor man eine Textur erzeugen kann. Was noch sehr wichtig ist. Es sollte niemals eine Textur bei jedem Rendervorgang angelegt und freigegeben werden! Es ist viel effektiver, wenn man die Textur zu beginn lädt und so lange im Speicher behält bis sie nicht mehr benötigt wird. Wenn man sie erst später benötigt, dann kann man sie auch später noch nachladen aber auch dann sollte sie so lange wie nötig existieren.

=== Procedural ===

Hierbei genügt der Aufruf einer einzelnen Methode um eine Textur zu laden und diese an OpenGL zu übergeben. Allerdings auf Grund der Einfachheit steht nur das Laden aus Dateien oder Ressourcen zur Verfügung. Zusätzliche Funktionalität können dabei nicht benutzt werden. Generell empfehle ich immer die Objekt orientierte Variante.

var
Texture: TGLuint;

LoadTexture('myTex\Wall.bmp', Texture, False); // Datei laden

Damit wird die Datei Wall.bmp geladen und die TextureID wird in die Variable Texture geschrieben. Wenn die Textur dann benötigt wird, dann muss man diese entsprechend mit [[glBindTexture]] binden und das benötigte Texturtarget mit [[glEnable]] aktivieren. Das Target ist üblicherweise GL_TEXTURE_2D. Wenn die Textur nicht mehr benötigt wird sollte sie mit [[glDeleteTextures]] auch wieder frei gegeben werden.

=== Objekt orientiert ===

Dieser Abschnitt beschäftigt sich ausschließlich mit den 2D Texturen. Aber grundsätzlich lässt sich alles hier erwähnte auch auf die 1D Texturen und die Cubemaps übertragen.
Der Objekt orientierte Weg erfordert zwar eine wenig mehr Schreibarbeit aber nur so kann man den vollen Funktionsumfang der glBitmap genießen.

Als Erstes müssen wir eine Instanz der Texturenklasse definieren. Dies tun wir vorzugsweise als Member des Fensters auf dem wir zeichnen.

TForm1 = class(TForm)
// Verschiene Elemente und Events des Fensters
private
fTexture: TglBitmap2D; // Instanz unserer Textur
end;

Nun müssen wir der Textur noch Leben einhauchen.

procedure TForm1.FormShow(Sender: TObject);
begin
// OpenGL Initialisieren

fTexture := TglBitmap2D.Create; // Instanz der Klasse erstellen
fTexture.LoadFromFile('myTex\Wall.bmp'); // Datei laden
fTexture.GenTexture; // geladene Textur an OpenGL übergeben
end;

Für Schreibfaule besteht auch noch die Möglichkeit in einem überladenen Konstruktor einem Dateinamen anzugeben.

fTexture := TglBitmap2D.Create('myTex\Wall.bmp'); // Instanz erstellen und Datei laden
fTexture.GenTexture; // geladene Textur an OpenGL übergeben

In GenTexture wird im Normalfall immer überprüft ob die Textur eine gültige Größe hat. Sollte diese Überprüfung nicht gewünscht sein so kann man diese mit einem optionalen Parameter deaktivieren. Diese Überprüfung testet auch ob die Texturgröße eine Potenz von 2 ist (1, 2, 4, 8, 16 usw.) und wenn nicht ob solche Texturen von dem Rendercontex unterstützt werden.

fTexture.GenTexture(False); // Es wird keine Prüfung der Texturgröße vorgenommen.

Wenn kein Fehler aufgetreten ist und alles so funktioniert hat wie es sein sollte, dann kann die Textur benutzt werden.

fTexture.Bind; // Textur und entsprechendes Target wird aktiviert.

Sollte es nicht gewünscht werden, dass auch gleichzeitig das Target aktiviert wird so muss Bind mit dem Parameter False aufgerufen werden. Damit wird nur noch die Textur gebunden.

Sollte man die Textur einmal nicht mehr benutzen wollen so genügt es entweder eine andere Textur zu binden oder Unbind von der Texturenklasse aufzurufen. Damit wird die Textur mit der TexturID 0 gebunden und das Target deaktiviert. Auch hier existiert wieder der Parameter der es verhindert, dass das Target deaktiviert wird.

Wenn die Anwendung beendet wird müssen wir auch hier unsere Textur wieder frei geben. Dies geschieht so.

fTexture.Free; // Textur wieder frei geben.

Hierbei ist zu beachten, dass dies nach Möglichkeit vor dem Löschen des Rendercontex geschehen sollte, da so die Textur zu einem sinnvollem Zeitpunkt gelöscht werden kann. Wenn der Rendercontex nicht mehr existiert, so sollte die Textur auch nicht mehr existieren und wenn man dann noch einmal versucht sie zu löschen so könnte es zu Problemen führen. Bisher ist mir kein Fall bekannt aber ausschließen kann man es auch nicht. Also zu erst immer die Texturen frei geben und anschließend des Rendercontex löschen.

== Das leidige Thema Alphakanal ==

Es gibt zwei Möglichkeiten einen Alphakanal in eine Textur zu integrieren. Der einfachste und schnellste Weg ist, wenn sich dieser Kanal von Beginn an in die Textur befindet. Dazu wird ein Grafikprogramm benötigt welches so etwas unterstützt und ein Dateiformat welches das Speichern eines Alphakanals ermöglicht. Ein solches Programm ist zum Beispiel [http://www.gimp.org/ Gimp]. Also mögliche Dateiformate kämen TGA's und PNG's in Frage. Alle anderen Formate unterstützen keinen Alphakanal. Sollte man sich für diesen Weg entscheiden so genügt es dann ganz normal die Textur zu laden und zu benutzen und schon besitzen wir einen funktionierenden Alphakanal. Ich persönlich empfehle bis auf wenige Ausnahmen immer diesen Weg.

Nichts desto trotz habe ich ja gesagt, dass es noch eine Möglichkeit gibt. Bei diesem Weg haben wir Alphakanal und RGB Daten in zwei getrennten Bildern vorliegen. Aber wie bekommen wir das jetzt in ein Bild? Dafür bietet die glBitmap die Möglichkeit einen Alphakanal aus einem separaten Bild zu laden. Zu Beginn benötigen wir jedoch wieder eine Instanz der Klasse und es müssen schon normale Bilddaten geladen worden sein. Und ganz Wichtig damit es überhaupt funktioniert. Der Aufruf muss vor GenTexture stattfinden, da sonst die Textur bereits an OpenGL übergeben wurde.

fTexture.AddAlphaFromFile('myTex\Wall_alpha.bmp'); // Alphakanal aus Datei laden

Das war alles nun sind wir im Besitz einer Textur mit einem Alphakanal. Es besteht unter anderem auch die Möglichkeit den Alphakanal aus verschiedenen anderen Quellen zu laden (Resourcen, Streams, TBitmap). Zusätzlich dazu kann man den Kanal aber auch dynamisch erstellen. Dafür existiert die Methode AddAlphaFromFunc. Die Findigen unter euch habe aber bestimmt schon herausgefunden, dass man bei alle Methoden solch eine Function übergeben kann. Näheres dazu findet ihr im Abschnitt e = mc²

Etwas was häufiger gebraucht wird habe ich von Hause aus schon implementiert. Und zwar das Erstellen eines Alphakanals anhand einer Farbe.

fTexture.AddAlphaFromColorKey(Red, Green, Blue, Deviation); // Alphakanal anhand einer Farbe hinzufügen

Dabei wird nur auf vollkommen durchlässig und nicht durchlässig unterschieden. Alle Pixel die die angegebene Farbe besitzen werden dabei als 0 (nicht Sichtbar) in den Alphakanal geschrieben alle anderen erhalten 255 (Sichtbar). Die Deviation bestimmt eine Abweichung um der die Farben abweichen dürfen um trotzdem noch als Transparent erkannt zu werden. Speziell für JPEG's ist das nicht unwichtig, da die Bilder beim Komprimieren leicht abgewandelt werden.

Damit die OpenGL Primitiven jetzt transparent dargestellt werden muss der [[GlAlphaFunc|Alphatest]] oder das [[glBlendFunc|Blending]] aktiviert sein. Sonst nützt einem der Alphakanal nicht sonderlich viel.

Entfernen kann man einen Alphakanal natürlich auch. Dazu genügt der Aufruf von RemoveAlpha. Dieser muss natürlich nicht mit der glBitmap erstellt worden sein. Er kann auch aus einer Datei geladen worden sein.

fTexture.RemoveAlpha; // entfernt den Alphakanal

== Texturen konfigurieren ==

Hier beginnt jetzt der Teil der für die Meisten recht wichtig sein dürfte. Bisher haben wir ja nur Daten geladen und diese an OpenGL übergeben. Nun wollen wir aber ein wenig an den Einstellungen rumschrauben und sehen was wir daraus machen können.

Folgende Einstellungsmöglichkeiten verändern ausschließlich nur das Verhalten der glBitmap. Sie haben keinen Einfluss auf die resultierende Textur.

DeleteTextureOnFree ist vom Typ Boolean und gibt an ob beim Freigeben der Klasse die Texture auch freigegeben wird oder ob weiter existieren darf. Standard wird sie mit freigegeben.

FreeDataAfterGenTexture ist vom Typ Boolean und gibt an ob die Bilddaten nach dem Erzeugen der Textur aus dem Hauptspeicher entfernt werden sollen oder nicht. Im Normalfall werden sie das auch.

Target ist vom Typ Cardinal und bestimmt das OpenGL Target. Wird von den Klassen auf den Standardwert gesetzt und muss nur dann auf einen anderen Wert gesetzt werden, wenn ein anderes Target verwendet werden soll. Zum Beispiel bei der Verwendung von Texture_rectangle. Es sollte aber immer direkt nach dem erstellen gesetzt werden, da die Textur sonst unbrauchbar gemacht werden könnte.

Format ist ein Aufzählungstyp und er erlaubt 4 Werte.
<table border="0" rules="all">
<tr>
<td>tfDefault</td>
<td>Dabei wird das Standardformat des Grafikkartentreibers benutzt. Je nach eingestellter Qualität kann dies 16 oder 32 Bit sein.</td>
</tr>
<tr>
<td>tf16Bit</td>
<td>Hier wird die Textur in 16Bit abgelegt.</td>
</tr>
<tr>
<td>tf32Bit</td>
<td>Hier wird die Textur in 32Bit abgelegt.</td>
</tr>
<tr>
<td>tfCompressed</td>
<td>Bei diesem Format wird zu erst geschaut ob eines der folgenden Kriterien erfüllt ist. Extension GL_ARB_texture_compression, OpenGL Version 1.3 oder die Extension GL_EXT_texture_compression_s3tc. Sollten alle 3 Möglichkeiten nicht funktionieren so wird das Standardformat vom Grafikkartentreiber benutzt.</td>
</tr>
</table>

MipMap ist ebenfalls ein Aufzählungstyp und er erlaubt 3 Werte.
<table border="0" rules="all">
<tr>
<td>mmNone</td>
<td>Wie man vermuten könnte werden hierbei keine Mipmaps erstellt.</td>
</tr>
<tr>
<td>mmMipmap</td>
<td>Ähnlich wie bei komprimierten Texturen werden zu erst verschiedene neue Möglichkeiten überprüft. Ab OpenGL Version 1.4 oder mit der Extension GL_SGIS_generate_mipmap unterstützt die Grafikkarte ein generieren der [[Mipmaps]]. Das ist natürlich wesentlich schneller als der Weg ausschließlich über die Software. Sollte es keinen anderen Weg geben so werden die [[Mipmaps]] mittels der GLU generiert.</td>
</tr>
<tr>
<td>mmMipmapGlu</td>
<td>In diesem Falle werden die [[Mipmaps]] ausschließlich mit der GLU erstellt.</td>
</tr>
</table>

Mithilfe der Methoden SetFilter und SetWrap können das Filterverhalten und das Beschränken der Texturkoordinaten angepasst werden. Eine genaue Auflistung möglicher Werte findet man beim Artikel zu [[glTexParameter]]. Das Aufrufen der Methoden ist überall dort möglich wo auch [[gTexParameter]] gültig ist. Mögliche Fehlerhafte Werte werden automatisch auf die vorhandene Textur angepasst. So wird bei SetFilter niemals ein [[MipMaps|MipMap]] bei die Filterung eingestellt wenn keine [[MipMaps]] erzeugt wurden. Das würde sonst dazu führen, dass die Textur nicht dargestellt werden könnte.

FlipVert und FlipHorz sind Methoden die nichts anderes machen als das Bild entlang der entsprechenden Richtung (Vertikal und Horizontal) zu spiegeln. Dies wäre auch mit der Funktionsschnittstelle möglich aber besonders bei FlipVert wäre es unpraktisch da wir so nicht die komplette Zeile am Stück kopieren könnten, sondern nur Pixel für Pixel.

Zum Invertieren des Bildes genügt es die Methode Invert aufzurufen. Sie bekommt zwei boolsche Parameter mit denen man steuern kann was man invertieren möchte. Einen für RGB und einen für den Alphakanal.

== e = mc² ==

Hierbei handelt es sich um eine Möglichkeit die Texturdaten zu manipulieren. Die Schnittstelle wurde so gestaltet, dass sie sehr flexibel und typisiert ist. Sprich, dass man immer genau worum es sich handelt und welche Felder unterstützt werden. Eine einfache Handhabung und eine gute Ausführungsgeschwindigkeit waren natürlich auch sehr wichtige Punkte dabei. Finden kann man die Funktionsschnittstelle bei dem Hinzufügen des Alphakanals oder immer wenn man möchte durch die Methode AddFunc. Es gibt außerdem noch eine Reihe von Funktionen, die intern die Schnittstelle benutzen. Das wären zum Beispiel die Funktionen Invert, AddAlphaFromColokey, ToNormalMap und FillWithColor. Die Klasse TglBitmapNormalMap generiert ihre Texturen zum Beispiel mit der Schnittstelle.

Die Arbeitsweise der Funktionsschnittstelle ist recht einfach. Es wird nichts anderes gemacht als 1 Mal Zeile für Zeile den Pointer eines jeden Pixels an eine Funktion zu Übergeben und darauf zu vertrauen, dass sie das Richtige tut. Um die Ausführung zu Beschleunigen wird ausschließlich mit Pointern gearbeitet. Die Funktionen bekommen die Instanz des Objektes, die Größe, die Position, das Quellpixel, das Zielpixel und einen Pointer auf benutzerdefinierte Daten übergeben. Das ist natürlich eine ganze Menge Holz was da an Daten übergeben aber das ist alles notwendig um die gewünschte Flexibilität erreichen zu können.

Betrachten wir das ganze mal an einem Beispiel. Und zwar dem Aufruf von Invert. Zu erst einmal der Aufruf der Funktion.

if ((UseRGB) or (UseAlpha))
then AddFunc(glBitmapInvertFunc, False, Pointer(Integer(UseAlpha and HasAlpha) shl 1 or Integer(UseRGB)));

In Zeile 1 handelt es sich lediglich um eine kleine Sicherheit. Es bringt ja nichts, wenn man eine Funktion ausführen möchte die keinen Nutzen hat. Zeile 2 Ruft die Methode AddFunc auf. Diese Methode bekommt als erstes unsere Funktion übergeben. Zu deren Aufbau komme ich gleich. Als Zweites bekommt AddFunc gesagt ob sie eine Kopie des Bildes erstellen soll. Für pixelübergreifende Funktionen ist dies unerlässlich, da man sich sonst seine noch benötigten Daten überschreiben würde. Der dritte Wert ist ein Pointer der zusätzliche Informationen hält. In diesem Falle handelt es sich lediglich um ein Bitset bei dem Bit 2 den Alphakanal und Bit 1 die RGB Werte repräsentiert. Es könnte sich dabei aber auch um einen Pointer auf ein Record handeln.

procedure glBitmapInvertFunc(Sender : TglBitmap; const Position, Size: TglBitmapPixelPosition;
const Source, Dest: TglBitmapPixelData; const Data: Pointer);
begin
if (Integer(Data) and $1 > 0) then begin
Dest.ptRed^ := not Dest.ptRed^;
Dest.ptGreen^ := not Dest.ptGreen^;
Dest.ptBlue^ := not Dest.ptBlue^;
end;

if (Integer(Data) and $2 > 0) then begin
Dest.ptAlpha^ := not Dest.ptAlpha^;
end;
end;

Position und Size beinhalten die Aktuelle Position des Pixels und die Größe des Bildes. Das Record TglBitmapPixelPosition beinhält 4 Werte. Fields, X, Y, Z. Fields beschreibt welche Felder überhaupt zur Verfügung stehen. Mögliche Werte Dafür sind ffX, ffY und ffZ. Wofür X, Y und Z stehen erkläre ich jetzt mal nicht, dass sollte jedem klar sein. Bei einem 2D Bitmap sind üblicherweise die Felder X und Y mit leben gefüllt. Das Feld Z liegt brach.

Source und Dest beinhalten die Pixeldaten. Die Records sind ziemlich genau so aufgebaut wie das für die Position. Es gibt einen Wert Fields. Mögliche Werte für ihn sind ffRed, ffGreen, ffBlue und ffAlpha. Diese Felder sind anders als bei bei Position keine richtigen Werte sondern Pointer die Direkt auf die Farbwerte in den Bildern zeigen. Es gibt deswegen Source und Dest, da es ja die Möglichkeit gibt eine Kopie des Bildes zu erstellen. Sollte ohne Kopie gearbeitet werden so sind Source und Dest gleich. Bei hinzufügen eines Alphakanals bezieht sich Source auf die Pixeldaten im dem Quellbild und Dest wie gewohnt auf die Daten im Zielbild.

In dem obigen Beispiel werden die Bits des Parameters Data ausgewertet und die entsprechenden Kanäle negiert. Der Komplexibilität sind kaum Grenzen gesetzt. Alle Wissensdurstigen unter euch sollten sich dann auch mal die Methode ToNormalMap anschauen. Dort werden zwei Funktionen aufgerufen. In der Ersten werden Daten gesammelt mit denen in der Zweiten die Normalmap berechnet wird. Oder auch die Klasse TglBitmapNormalMap. In dieser wird eine generelle Berechnungsroutine aufgerufen. Diese bekommt aber für jede Fläche der Map eine andere interne Methode übergeben. Mit dieser werden dann die Werte für jedes Pixel gefüllt.

Noch ein Wort für alle Geschwindigkeitsfanatiker. Ich hatte ein mal spaßeshalber die Methode FlipHorz nachgebaut und die Geschwindigkeit gemessen. Das Ergebnis hat mich selber sehr angenehm überrascht. Die Hardcodierte super optimierte Methode benötigte bei 300 Aufrufen, auf ein 512x512 Pixel großes Bild ca. 5 Sekunden. Die Methode mit dem Funktionsaufruf benötigte Lediglich 300 ms länger. Ich selber hätte eher mit dem Doppelten der Zeit gerechnet.

== Cubemaps mit glBitmap ==

Das einzige worin sich CubeMaps von 2D Texturen unterscheidet ist das Laden. Aber das ist auch nicht viel komplizierter als bei 2D Texturen. Die Handhabung mit den Texturen (Binden, Frei geben) ist wie bei 2D Texturen weswegen ich das auch nicht noch einmal extra wiederholen werde.

=== Procedural ===

Wie auch bei den 2D Texturen haben wir die Auswahl zwischen zwei möglichen Wegen. Der procedurale Weg unterscheidet sich lediglich in der Anzahl der angegebenen Texturen. Das sind diesmal natürlich ein paar mehr.

var
Texture: TGLuint;

// Cubemaps laden
LoadCubeMap('xpos.bmp', 'xneg.bmp', 'ypos.bmp', 'yneg.bmp', 'zpos.bmp', 'zneg.bmp', Texture, False);

Die ersten 6 Parameter geben die jeweils 6 Texturen an. Die Namen der Parameter geben auch gleichzeitig deren Ziel an. Also immer schön auf die Reihenfolge achten. In dem Siebten wird die Textur ID geschrieben und der Achte gibt an ob aus Resourcen geladen werden soll oder nicht.

=== Objekt orientiert ===

Der Objekt orientierte Weg gestaltet sich dieses mal ein wenig schreibintensiver. Es müssen ja auch schließlich 6 Texturen geladen werden. Aber das kann man auch praktischerweise in eine Schleife packen. Das praktische daran ist, dass wir alles mit nur einer Klasseninstanz lösen können (und auch müssen).

fCubeMap := TglBitmapCubeMap.Create; // Instanz der Klasse erstellen
fCubeMap.LoadFromFile('xpos.jpg'); // Datei Laden

Die Textur wird normal angelegt und es wird wie gewöhnt ein Bild in den Speicher der Klasse geladen. Dieses Bild verhält sich wie jedes andere Bild. Es kann also wie gewöhnt manipuliert werden. Zum Beispiel durch die Funktionsschnittstelle.

fCubeMap.GenerateCubeMap(GL_TEXTURE_CUBE_MAP_POSITIVE_X); // Einzelnen Teil übergeben

Wenn die Textur also bereit zum Übergeben ist, dann müssen wir GenerateCubeMap mit dem entsprechenden Teil der Cubemap aufrufen. In diesem Falle ist es die positive X Achse. Das müssen wir dann natürlich noch mit allen anderen Maps machen. Also Bild laden, evtl bearbeiten und dann an OpenGL übergeben. Die Reihenfolge der Maps spielt hierbei keine Rolle. Wichtig ist nur, dass sie die selbe Auflösung und das selbe Format haben. Die Methode GenTexture steht bei dieser Klasse nicht zur Verfügung, da beim ersten Aufruf von GenerateCubeMap automatisch die OpenGL Textur erzeugt wird. Die CubeMap ist nur dann einsetzbar, wenn alle Maps erfolgreich mit Daten versorgt wurden.

Beim Binden der CubeMap existiert ein zusätzlicher Parameter mit dem man die Aktivierung der automatische Generation der Texturkoordinaten deaktivieren kann. Standard ist dieses eingeschalten. Ähnlich wie beim Binden einer Textur. Dort kann man verhindern, dass das Target aktiviert wird.

== Normalmaps mit glBitmap ==

NormalMaps sind nichts anderes als Spezielle Cubemaps. Sie dienen dazu um Per Pixel Normale auch auf Systemen ohne Shaderhardware zu ermöglichen. Benutzt werden kann das zum Beispiel bei Bumpmapping mit [[GL_ARB_texture_env_dot3]].

=== Procedural ===

Wie auch bei den 2D Texturen und Cubemaps haben wir die Auswahl zwischen zwei möglichen Wegen. Da diese Texturen dynamisch generiert werden fällt die Anzahl der Parameter ziemlich gering aus. Sie besteht lediglich aus einer Texturgröße. In diesem Falle haben die resultierenden Texturen eine Größe von 32x32 Pixeln. Der zweite Parameter ist ein altbekannter von uns. Er ermöglicht es uns eine TexturID zu empfangen. Auf die Handhabung mit dieser ID gehe ich nicht noch einmal ein, da das oberhalb schon oft genug besprochen wurde.

var
Texture: TGLuint;

// Normalmaps erzeugen
LoadTexture(32, Texture);

=== Objekt orientiert ===

Dieser Weg ist etwa genau so schreibintensiv wie der Procedurale. Hierbei wird eine Normalmap erstellt bei der einzelnen Texturen eine Größe von 32x32 Pixeln haben.

fNormalMap := TglBitmapNormalMap.Create; // Instanz der Klasse erstellen
fNormalMap.GenerateNormalMap(32); // Normalmap erzeugen

Erstaunlich aber wahr. Das war bereits alles. Von nun an kann die Textur wie jede andere CubeMap auch verwendet werden.

== Bekannte Probleme und Einschränkungen ==

Vor einer Weile wurde im Forum die Frage gestellt warum die glBitmap beim Laden eines BMP's einen "Stream Read Error" produziert. Da das Bitmap nun mal ein sehr einfaches Format ist hat mich das auch sehr stark verwundert. Nach langem hin und her Rätseln kam ich dann dennoch darauf was das Problem war. Es daran, dass das Bitmap mit MS Paint abgespeichert wurde. Dieser war aber der Meinung er müsse im Bitmapheader eine Größe angeben die 2 Bytes größer war als die eigentlichen Daten. Diese 2 Bytes wurden auch aufgefüllt aber leider ist das TBitmap, welches ich zum Laden verwende, nicht so tolerant um über darüber hinweg zu sehen. Und so bekommt man einen Fehler beim Laden. Den selben Fehler würde man auch bekommen wenn man das Bild in einem TImage anzeigen wollte.

Abhelfen kann man dies in dem man ein [http://www.gimp.org/ alternatives Grafikprogramm (Gimp)] verwendet oder das Bild einmal mit dem Bildbetrachter [http://www.irfanview.de/ IrfanView] öffnet und abspeichert.

Es muss nicht bei jedem mit MS Paint abgespeicherten Bild auftreten.

Glbitmap loader

2005-07-04T14:03:37Z

Lossy eX:

{{unvollständig}}
= glBitmap - Texturenloader =

== Warum das Ganze und wo kann ich sie finden? ==

Früher benutzte ich die glBMP, da sie so "schön" Objekt orientiert war. Leider hatte mein Grafiktreiber zu der Zeit einen Fehler bei der Auswahl des Texturformates. So führte es dazu, dass sobald ich eine Textur mit Alphakanal und dem Standard Texturformat an OpenGL übergab, er als Farbtiefe 16 Bit verwendete. Wenn ich ein Foto genommen hätte wäre mir das wahrscheinlich gar nicht aufgefallen aber dummerweise (oder glücklicherweise) hatte ich aber eine Textur mit einem weichem Farbverlauf. Wie zu erwarten war sah das natürlich alles ziemlich schrecklich aus. Bis dahin kann der Loader ja nichts dafür wenn in einem Treiber ein Fehler existiert. Nur das kuriose an dem Ganzen war, dass meine Textur in Wirklichkeit gar keinen Alphakanal haben durfte. Also habe ich mich auf die Suche nach der Ursache gemacht und bin auch prompt fündig geworden. Der Loader war der Meinung er müsse alle Texturen mit einem Alphakanal versehen ungeachtet der Tatsache ob sie nun einen hatten oder eben nicht. Das ist natürlich eine Sache mit der ich mich nicht abfinden wollte. Kurz darauf begann ich also eine Ableitung der glBMP Texturenklasse zu erstellen und dort musste ich mit Schrecken feststellen, dass die Rechte in der Klasse so ungünstig vergeben wurden, dass ich keine andere Wahl gehabt hätte als direkt die Unit zu editieren. Da ich ungern externe Quellen editiere habe ich für mich die andere Alternative entschieden. Was dabei rausgekommen ist sieht man ja jetzt.

Gefunden werden kann sie entweder im DGL-SDK oder auf der [http://www.dev-center.de/index.php?cat=header&file=glbitmap Webseite] von [[Benutzer:Lossy eX|Lossy eX]].

== Allgemeines und Features ==

Dieser Artikel geht nicht darauf ein was zu tun ist um in OpenGL eine Textur darstellen zu können. In ihm werde ich lediglich darauf eingehen was man tun kann und muss um mittels der glBitmap eine Textur laden zu können. Außerdem werden die verfügbaren Einstellungen und ihre Wirkungen erklärt. Für alles andere wäre es besser das [[Tutorial_lektion4|Tutorial über Texturen]] durchzulesen.

Der wichtigste Unterschied zu den bestehenden Loadern bringe ich gleich einmal als erstes. Die glBitmap legt die Texturen anders im Speicher ab. Um zwar im speziellen meine ich damit die 2D Texturen. Bei bestehenden Loadern werden diese Texturen mit der untersten Zeile zu erst im Speicher abgelegt. In der glBitmap werden sie aber mit der obersten Zeile zu erst abgelegt. Man könnte auch sagen, dass sie bei den bestehenden Loadern auf dem Kopf stehen. Beide Möglichkeiten funktionieren und sind korrekt. Das Einzige was sich in diesem Zusammenhang ändert ist die [[glTexCoord| Adressierung der Texturen]]. Sie müssen entsprechend geändert werden. Sollte das nicht möglich sein so besteht mit der Methode FlipVert die Möglichkeit die Textur zu spiegeln. Näheres in Abschnitt [[Glbitmap_loader#Texturen_konfigurieren|Texturen konfigurieren]]. Im Normalfall sollte das andere Verhalten nicht zu Problemen führen sondern die Arbeit damit vereinfachen und verständlicher gestalten.

Die glBitmap holt sich ihre Daten ausschließlich aus Streams. Das zugrundeliegende Format wird automatisch anhand des Inhaltes der Daten ausgewählt. Es besteht also kein Notwendigkeit daran, dass der Entwickler wissen muss um welches Format es sich in Wirklichkeit handelt.

=== unterstütze Formate ===

* Windows Bitmaps (*.bmp) Wird Automatisch auf 24 Bit gesetzt sollte es kleiner sein.
* JPEG (*.jpg)
* TARGA (*.tga) komprimiert und unkomprimiert, 24 und 32 Bit. Ursprung unten links oder oben links
* Portable Network Graphics (*.png) 24 Bit mit oder ohne Alphakanal. Es wird eine zusätzliche Bibliothek benötigt.
Es besteht auch die Möglichkeit die Bilddaten dynamisch generieren zu lassen oder sie aus einer Instanz der Klasse TBitmap zu laden. Diese Instanz muss dann aber als Pixelformat 24 oder 32 Bit haben.

Um PNG's laden zu können muss eine externe Bibliothek namens [http://pngdelphi.sourceforge.net/ PNGImage] eingebunden und das Define pngimage hinzugefügt werden. Alternativ dazu kann das Define auch in der glBitmap auskommentiert werden.

== Texturen laden ==

Das Laden von Texturen kann auf 2 Weg geschehen. Bei Beiden ist aber zu beachten, dass OpenGL richtig initialisiert worden sein muss bevor man eine Textur erzeugen kann. Was noch sehr wichtig ist. Es sollte niemals eine Textur bei jedem Rendervorgang angelegt und freigegeben werden! Es ist viel effektiver, wenn man die Textur zu beginn lädt und so lange im Speicher behält bis sie nicht mehr benötigt wird. Wenn man sie erst später benötigt, dann kann man sie auch später noch nachladen aber auch dann sollte sie so lange wie nötig existieren.

=== Procedural ===

Hierbei genügt der Aufruf einer einzelnen Methode um eine Textur zu laden und diese an OpenGL zu übergeben. Allerdings auf Grund der Einfachheit steht nur das Laden aus Dateien oder Ressourcen zur Verfügung. Zusätzliche Funktionalität können dabei nicht benutzt werden. Generell empfehle ich immer die Objekt orientierte Variante.

var
Texture: TGLuint;

LoadTexture('myTex\Wall.bmp', Texture, False); // Datei laden

Damit wird die Datei Wall.bmp geladen und die TextureID wird in die Variable Texture geschrieben. Wenn die Textur dann benötigt wird, dann muss man diese entsprechend mit [[glBindTexture]] binden und das benötigte Texturtarget mit [[glEnable]] aktivieren. Das Target ist üblicherweise GL_TEXTURE_2D. Wenn die Textur nicht mehr benötigt wird sollte sie mit [[glDeleteTextures]] auch wieder frei gegeben werden.

=== Objekt orientiert ===

Dieser Abschnitt beschäftigt sich ausschließlich mit den 2D Texturen. Aber grundsätzlich lässt sich alles hier erwähnte auch auf die 1D Texturen und die Cubemaps übertragen.
Der Objekt orientierte Weg erfordert zwar eine wenig mehr Schreibarbeit aber nur so kann man den vollen Funktionsumfang der glBitmap genießen.

Als Erstes müssen wir eine Instanz der Texturenklasse definieren. Dies tun wir vorzugsweise als Member des Fensters auf dem wir zeichnen.

TForm1 = class(TForm)
// Verschiene Elemente und Events des Fensters
private
fTexture: TglBitmap2D; // Instanz unserer Textur
end;

Nun müssen wir der Textur noch Leben einhauchen.

procedure TForm1.FormShow(Sender: TObject);
begin
// OpenGL Initialisieren

fTexture := TglBitmap2D.Create; // Instanz der Klasse erstellen
fTexture.LoadFromFile('myTex\Wall.bmp'); // Datei laden
fTexture.GenTexture; // geladene Textur an OpenGL übergeben
end;

Für Schreibfaule besteht auch noch die Möglichkeit in einem überladenen Konstruktor einem Dateinamen anzugeben.

fTexture := TglBitmap2D.Create('myTex\Wall.bmp'); // Instanz erstellen und Datei laden
fTexture.GenTexture; // geladene Textur an OpenGL übergeben

In GenTexture wird im Normalfall immer überprüft ob die Textur eine gültige Größe hat. Sollte diese Überprüfung nicht gewünscht sein so kann man diese mit einem optionalen Parameter deaktivieren. Diese Überprüfung testet auch ob die Texturgröße eine Potenz von 2 ist (1, 2, 4, 8, 16 usw.) und wenn nicht ob solche Texturen von dem Rendercontex unterstützt werden.

fTexture.GenTexture(False); // Es wird keine Prüfung der Texturgröße vorgenommen.

Wenn kein Fehler aufgetreten ist und alles so funktioniert hat wie es sein sollte, dann kann die Textur benutzt werden.

fTexture.Bind; // Textur und entsprechendes Target wird aktiviert.

Sollte es nicht gewünscht werden, dass auch gleichzeitig das Target aktiviert wird so muss Bind mit dem Parameter False aufgerufen werden. Damit wird nur noch die Textur gebunden.

Sollte man die Textur einmal nicht mehr benutzen wollen so genügt es entweder eine andere Textur zu binden oder Unbind von der Texturenklasse aufzurufen. Damit wird die Textur mit der TexturID 0 gebunden und das Target deaktiviert. Auch hier existiert wieder der Parameter der es verhindert, dass das Target deaktiviert wird.

Wenn die Anwendung beendet wird müssen wir auch hier unsere Textur wieder frei geben. Dies geschieht so.

fTexture.Free; // Textur wieder frei geben.

Hierbei ist zu beachten, dass dies nach Möglichkeit vor dem Löschen des Rendercontex geschehen sollte, da so die Textur zu einem sinnvollem Zeitpunkt gelöscht werden kann. Wenn der Rendercontex nicht mehr existiert, so sollte die Textur auch nicht mehr existieren und wenn man dann noch einmal versucht sie zu löschen so könnte es zu Problemen führen. Bisher ist mir kein Fall bekannt aber ausschließen kann man es auch nicht. Also zu erst immer die Texturen frei geben und anschließend des Rendercontex löschen.

== Das leidige Thema Alphakanal ==

Es gibt zwei Möglichkeiten einen Alphakanal in eine Textur zu integrieren. Der einfachste und schnellste Weg ist, wenn sich dieser Kanal von Beginn an in die Textur befindet. Dazu wird ein Grafikprogramm benötigt welches so etwas unterstützt und ein Dateiformat welches das Speichern eines Alphakanals ermöglicht. Ein solches Programm ist zum Beispiel [http://www.gimp.org/ Gimp]. Also mögliche Dateiformate kämen TGA's und PNG's in Frage. Alle anderen Formate unterstützen keinen Alphakanal. Sollte man sich für diesen Weg entscheiden so genügt es dann ganz normal die Textur zu laden und zu benutzen und schon besitzen wir einen funktionierenden Alphakanal. Ich persönlich empfehle bis auf wenige Ausnahmen immer diesen Weg.

Nichts desto trotz habe ich ja gesagt, dass es noch eine Möglichkeit gibt. Bei diesem Weg haben wir Alphakanal und RGB Daten in zwei getrennten Bildern vorliegen. Aber wie bekommen wir das jetzt in ein Bild? Dafür bietet die glBitmap die Möglichkeit einen Alphakanal aus einem separaten Bild zu laden. Zu Beginn benötigen wir jedoch wieder eine Instanz der Klasse und es müssen schon normale Bilddaten geladen worden sein. Und ganz Wichtig damit es überhaupt funktioniert. Der Aufruf muss vor GenTexture stattfinden, da sonst die Textur bereits an OpenGL übergeben wurde.

fTexture.AddAlphaFromFile('myTex\Wall_alpha.bmp'); // Alphakanal aus Datei laden

Das war alles nun sind wir im Besitz einer Textur mit einem Alphakanal. Es besteht unter anderem auch die Möglichkeit den Alphakanal aus verschiedenen anderen Quellen zu laden (Resourcen, Streams, TBitmap). Zusätzlich dazu kann man den Kanal aber auch dynamisch erstellen. Dafür existiert die Methode AddAlphaFromFunc. Die Findigen unter euch habe aber bestimmt schon herausgefunden, dass man bei alle Methoden solch eine Function übergeben kann. Näheres dazu findet ihr im Abschnitt e = mc²

Etwas was häufiger gebraucht wird habe ich von Hause aus schon implementiert. Und zwar das Erstellen eines Alphakanals anhand einer Farbe.

fTexture.AddAlphaFromColorKey(Red, Green, Blue, Deviation); // Alphakanal anhand einer Farbe hinzufügen

Dabei wird nur auf vollkommen durchlässig und nicht durchlässig unterschieden. Alle Pixel die die angegebene Farbe besitzen werden dabei als 0 (nicht Sichtbar) in den Alphakanal geschrieben alle anderen erhalten 255 (Sichtbar). Die Deviation bestimmt eine Abweichung um der die Farben abweichen dürfen um trotzdem noch als Transparent erkannt zu werden. Speziell für JPEG's ist das nicht unwichtig, da die Bilder beim Komprimieren leicht abgewandelt werden.

Damit die OpenGL Primitiven jetzt transparent dargestellt werden muss der [[GlAlphaFunc|Alphatest]] oder das [[glBlendFunc|Blending]] aktiviert sein. Sonst nützt einem der Alphakanal nicht sonderlich viel.

Entfernen kann man einen Alphakanal natürlich auch. Dazu genügt der Aufruf von RemoveAlpha. Dieser muss natürlich nicht mit der glBitmap erstellt worden sein. Er kann auch aus einer Datei geladen worden sein.

fTexture.RemoveAlpha; // entfernt den Alphakanal

== Texturen konfigurieren ==

Hier beginnt jetzt der Teil der für die Meisten recht wichtig sein dürfte. Bisher haben wir ja nur Daten geladen und diese an OpenGL übergeben. Nun wollen wir aber ein wenig an den Einstellungen rumschrauben und sehen was wir daraus machen können.

Folgende Einstellungsmöglichkeiten verändern ausschließlich nur das Verhalten der glBitmap. Sie haben keinen Einfluss auf die resultierende Textur.

DeleteTextureOnFree ist vom Typ Boolean und gibt an ob beim Freigeben der Klasse die Texture auch freigegeben wird oder ob weiter existieren darf. Standard wird sie mit freigegeben.

FreeDataAfterGenTexture ist vom Typ Boolean und gibt an ob die Bilddaten nach dem Erzeugen der Textur aus dem Hauptspeicher entfernt werden sollen oder nicht. Im Normalfall werden sie das auch.

Target ist vom Typ Cardinal und bestimmt das OpenGL Target. Wird von den Klassen auf den Standardwert gesetzt und muss nur dann auf einen anderen Wert gesetzt werden, wenn ein anderes Target verwendet werden soll. Zum Beispiel bei der Verwendung von Texture_rectangle. Es sollte aber immer direkt nach dem erstellen gesetzt werden, da die Textur sonst unbrauchbar gemacht werden könnte.

Format ist ein Aufzählungstyp und er erlaubt 4 Werte.
<table border="0" rules="all">
<tr>
<td>tfDefault</td>
<td>Dabei wird das Standardformat des Grafikkartentreibers benutzt. Je nach eingestellter Qualität kann dies 16 oder 32 Bit sein.</td>
</tr>
<tr>
<td>tf16Bit</td>
<td>Hier wird die Textur in 16Bit abgelegt.</td>
</tr>
<tr>
<td>tf32Bit</td>
<td>Hier wird die Textur in 32Bit abgelegt.</td>
</tr>
<tr>
<td>tfCompressed</td>
<td>Bei diesem Format wird zu erst geschaut ob eines der folgenden Kriterien erfüllt ist. Extension GL_ARB_texture_compression, OpenGL Version 1.3 oder die Extension GL_EXT_texture_compression_s3tc. Sollten alle 3 Möglichkeiten nicht funktionieren so wird das Standardformat vom Grafikkartentreiber benutzt.</td>
</tr>
</table>

MipMap ist ebenfalls ein Aufzählungstyp und er erlaubt 3 Werte.
<table border="0" rules="all">
<tr>
<td>mmNone</td>
<td>Wie man vermuten könnte werden hierbei keine Mipmaps erstellt.</td>
</tr>
<tr>
<td>mmMipmap</td>
<td>Ähnlich wie bei komprimierten Texturen werden zu erst verschiedene neue Möglichkeiten überprüft. Ab OpenGL Version 1.4 oder mit der Extension GL_SGIS_generate_mipmap unterstützt die Grafikkarte ein generieren der [[Mipmaps]]. Das ist natürlich wesentlich schneller als der Weg ausschließlich über die Software. Sollte es keinen anderen Weg geben so werden die [[Mipmaps]] mittels der GLU generiert.</td>
</tr>
<tr>
<td>mmMipmapGlu</td>
<td>In diesem Falle werden die [[Mipmaps]] ausschließlich mit der GLU erstellt.</td>
</tr>
</table>

Mithilfe der Methoden SetFilter und SetWrap können das Filterverhalten und das Beschränken der Texturkoordinaten angepasst werden. Eine genaue Auflistung möglicher Werte findet man beim Artikel zu [[glTexParameter]]. Das Aufrufen der Methoden ist überall dort möglich wo auch [[gTexParameter]] gültig ist. Mögliche Fehlerhafte Werte werden automatisch auf die vorhandene Textur angepasst. So wird bei SetFilter niemals ein [[MipMaps|MipMap]] bei die Filterung eingestellt wenn keine [[MipMaps]] erzeugt wurden. Das würde sonst dazu führen, dass die Textur nicht dargestellt werden könnte.

FlipVert und FlipHorz sind Methoden die nichts anderes machen als das Bild entlang der entsprechenden Richtung (Vertikal und Horizontal) zu spiegeln. Dies wäre auch mit der Funktionsschnittstelle möglich aber besonders bei FlipVert wäre es unpraktisch da wir so nicht die komplette Zeile am Stück kopieren könnten, sondern nur Pixel für Pixel.

Zum Invertieren des Bildes genügt es die Methode Invert aufzurufen. Sie bekommt zwei boolsche Parameter mit denen man steuern kann was man invertieren möchte. Einen für RGB und einen für den Alphakanal.

== e = mc² ==

Hierbei handelt es sich um eine Möglichkeit die Texturdaten zu manipulieren. Die Schnittstelle wurde so gestaltet, dass sie sehr flexibel und typisiert ist. Sprich, dass man immer genau worum es sich handelt und welche Felder unterstützt werden. Eine einfache Handhabung und eine gute Ausführungsgeschwindigkeit waren natürlich auch sehr wichtige Punkte dabei. Finden kann man die Funktionsschnittstelle bei dem Hinzufügen des Alphakanals oder immer wenn man möchte durch die Methode AddFunc. Es gibt außerdem noch eine Reihe von Funktionen, die intern die Schnittstelle benutzen. Das wären zum Beispiel die Funktionen Invert, AddAlphaFromColokey, ToNormalMap und FillWithColor. Die Klasse TglBitmapNormalMap generiert ihre Texturen zum Beispiel mit der Schnittstelle.

Die Arbeitsweise der Funktionsschnittstelle ist recht einfach. Es wird nichts anderes gemacht als 1 Mal Zeile für Zeile den Pointer eines jeden Pixels an eine Funktion zu Übergeben und darauf zu vertrauen, dass sie das Richtige tut. Um die Ausführung zu Beschleunigen wird ausschließlich mit Pointern gearbeitet. Die Funktionen bekommen die Instanz des Objektes, die Größe, die Position, das Quellpixel, das Zielpixel und einen Pointer auf benutzerdefinierte Daten übergeben. Das ist natürlich eine ganze Menge Holz was da an Daten übergeben aber das ist alles notwendig um die gewünschte Flexibilität erreichen zu können.

Betrachten wir das ganze mal an einem Beispiel. Und zwar dem Aufruf von Invert. Zu erst einmal der Aufruf der Funktion.

if ((UseRGB) or (UseAlpha))
then AddFunc(glBitmapInvertFunc, False, Pointer(Integer(UseAlpha and HasAlpha) shl 1 or Integer(UseRGB)));

In Zeile 1 handelt es sich lediglich um eine kleine Sicherheit. Es bringt ja nichts, wenn man eine Funktion ausführen möchte die keinen Nutzen hat. Zeile 2 Ruft die Methode AddFunc auf. Diese Methode bekommt als erstes unsere Funktion übergeben. Zu deren Aufbau komme ich gleich. Als Zweites bekommt AddFunc gesagt ob sie eine Kopie des Bildes erstellen soll. Für pixelübergreifende Funktionen ist dies unerlässlich, da man sich sonst seine noch benötigten Daten überschreiben würde. Der dritte Wert ist ein Pointer der zusätzliche Informationen hält. In diesem Falle handelt es sich lediglich um ein Bitset bei dem Bit 2 den Alphakanal und Bit 1 die RGB Werte repräsentiert. Es könnte sich dabei aber auch um einen Pointer auf ein Record handeln.

procedure glBitmapInvertFunc(Sender : TglBitmap; const Position, Size: TglBitmapPixelPosition;
const Source, Dest: TglBitmapPixelData; const Data: Pointer);
begin
if (Integer(Data) and $1 > 0) then begin
Dest.ptRed^ := not Dest.ptRed^;
Dest.ptGreen^ := not Dest.ptGreen^;
Dest.ptBlue^ := not Dest.ptBlue^;
end;

if (Integer(Data) and $2 > 0) then begin
Dest.ptAlpha^ := not Dest.ptAlpha^;
end;
end;

Position und Size beinhalten die Aktuelle Position des Pixels und die Größe des Bildes. Das Record TglBitmapPixelPosition beinhält 4 Werte. Fields, X, Y, Z. Fields beschreibt welche Felder überhaupt zur Verfügung stehen. Mögliche Werte Dafür sind ffX, ffY und ffZ. Wofür X, Y und Z stehen erkläre ich jetzt mal nicht, dass sollte jedem klar sein. Bei einem 2D Bitmap sind üblicherweise die Felder X und Y mit leben gefüllt. Das Feld Z liegt brach.

Source und Dest beinhalten die Pixeldaten. Die Records sind ziemlich genau so aufgebaut wie das für die Position. Es gibt einen Wert Fields. Mögliche Werte für ihn sind ffRed, ffGreen, ffBlue und ffAlpha. Diese Felder sind anders als bei bei Position keine richtigen Werte sondern Pointer die Direkt auf die Farbwerte in den Bildern zeigen. Es gibt deswegen Source und Dest, da es ja die Möglichkeit gibt eine Kopie des Bildes zu erstellen. Sollte ohne Kopie gearbeitet werden so sind Source und Dest gleich. Bei hinzufügen eines Alphakanals bezieht sich Source auf die Pixeldaten im dem Quellbild und Dest wie gewohnt auf die Daten im Zielbild.

In dem obigen Beispiel werden die Bits des Parameters Data ausgewertet und die entsprechenden Kanäle negiert. Der Komplexibilität sind kaum Grenzen gesetzt. Alle Wissensdurstigen unter euch sollten sich dann auch mal die Methode ToNormalMap anschauen. Dort werden zwei Funktionen aufgerufen. In der Ersten werden Daten gesammelt mit denen in der Zweiten die Normalmap berechnet wird. Oder auch die Klasse TglBitmapNormalMap. In dieser wird eine generelle Berechnungsroutine aufgerufen. Diese bekommt aber für jede Fläche der Map eine andere interne Methode übergeben. Mit dieser werden dann die Werte für jedes Pixel gefüllt.

Noch ein Wort für alle Geschwindigkeitsfanatiker. Ich hatte ein mal spaßeshalber die Methode FlipHorz nachgebaut und die Geschwindigkeit gemessen. Das Ergebnis hat mich selber sehr angenehm überrascht. Die Hardcodierte super optimierte Methode benötigte bei 300 Aufrufen, auf ein 512x512 Pixel großes Bild ca. 5 Sekunden. Die Methode mit dem Funktionsaufruf benötigte Lediglich 300 ms länger. Ich selber hätte eher mit dem Doppelten der Zeit gerechnet.

== Cubemaps mit glBitmap ==

Das einzige worin sich CubeMaps von 2D Texturen unterscheidet ist das Laden. Aber das ist auch nicht viel komplizierter als bei 2D Texturen. Die Handhabung mit den Texturen (Binden, Frei geben) ist wie bei 2D Texturen weswegen ich das auch nicht noch einmal extra wiederholen werde.

=== Procedural ===

Wie auch bei den 2D Texturen haben wir die Auswahl zwischen zwei möglichen Wegen. Der procedurale Weg unterscheidet sich lediglich in der Anzahl der angegebenen Texturen. Das sind diesmal natürlich ein paar mehr.

var
Texture: TGLuint;

// Cubemaps laden
LoadCubeMap('xpos.bmp', 'xneg.bmp', 'ypos.bmp', 'yneg.bmp', 'zpos.bmp', 'zneg.bmp', Texture, False);

Die ersten 6 Parameter geben die jeweils 6 Texturen an. Die Namen der Parameter geben auch gleichzeitig deren Ziel an. Also immer schön auf die Reihenfolge achten. In dem Siebten wird die Textur ID geschrieben und der Achte gibt an ob aus Resourcen geladen werden soll oder nicht.

=== Objekt orientiert ===

Der Objekt orientierte Weg gestaltet sich dieses mal ein wenig schreibintensiver. Es müssen ja auch schließlich 6 Texturen geladen werden. Aber das kann man auch praktischerweise in eine Schleife packen. Das praktische daran ist, dass wir alles mit nur einer Klasseninstanz lösen können (und auch müssen).

fCubeMap := TglBitmapCubeMap.Create; // Instanz der Klasse erstellen
fCubeMap.LoadFromFile('xpos.jpg'); // Datei Laden

Die Textur wird normal angelegt und es wird wie gewöhnt ein Bild in den Speicher der Klasse geladen. Dieses Bild verhält sich wie jedes andere Bild. Es kann also wie gewöhnt manipuliert werden. Zum Beispiel durch die Funktionsschnittstelle.

fCubeMap.GenerateCubeMap(GL_TEXTURE_CUBE_MAP_POSITIVE_X); // Einzelnen Teil übergeben

Wenn die Textur also bereit zum Übergeben ist, dann müssen wir GenerateCubeMap mit dem entsprechenden Teil der Cubemap aufrufen. In diesem Falle ist es die positive X Achse. Das müssen wir dann natürlich noch mit allen anderen Maps machen. Also Bild laden, evtl bearbeiten und dann an OpenGL übergeben. Die Reihenfolge der Maps spielt hierbei keine Rolle. Wichtig ist nur, dass sie die selbe Auflösung und das selbe Format haben. Die Methode GenTexture steht bei dieser Klasse nicht zur Verfügung, da beim ersten Aufruf von GenerateCubeMap automatisch die OpenGL Textur erzeugt wird. Die CubeMap ist nur dann einsetzbar, wenn alle Maps erfolgreich mit Daten versorgt wurden.

Beim Binden der CubeMap existiert ein zusätzlicher Parameter mit dem man die Aktivierung der automatische Generation der Texturkoordinaten deaktivieren kann. Standard ist dieses eingeschalten. Ähnlich wie beim Binden einer Textur. Dort kann man verhindern, dass das Target aktiviert wird.

== Bekannte Probleme und Einschränkungen ==

Vor einer Weile wurde im Forum die Frage gestellt warum die glBitmap beim Laden eines BMP's einen "Stream Read Error" produziert. Da das Bitmap nun mal ein sehr einfaches Format ist hat mich das auch sehr stark verwundert. Nach langem hin und her Rätseln kam ich dann dennoch darauf was das Problem war. Es daran, dass das Bitmap mit MS Paint abgespeichert wurde. Dieser war aber der Meinung er müsse im Bitmapheader eine Größe angeben die 2 Bytes größer war als die eigentlichen Daten. Diese 2 Bytes wurden auch aufgefüllt aber leider ist das TBitmap, welches ich zum Laden verwende, nicht so tolerant um über darüber hinweg zu sehen. Und so bekommt man einen Fehler beim Laden. Den selben Fehler würde man auch bekommen wenn man das Bild in einem TImage anzeigen wollte.

Abhelfen kann man dies in dem man ein [http://www.gimp.org/ alternatives Grafikprogramm (Gimp)] verwendet oder das Bild einmal mit dem Bildbetrachter [http://www.irfanview.de/ IrfanView] öffnet und abspeichert.

Es muss nicht bei jedem mit MS Paint abgespeicherten Bild auftreten.

Glbitmap loader

2005-07-04T14:02:26Z

Lossy eX:

{{unvollständig}}
= glBitmap - Texturenloader =

== Warum das Ganze und wo kann ich sie finden? ==

Früher benutzte ich die glBMP, da sie so "schön" Objekt orientiert war. Leider hatte mein Grafiktreiber zu der Zeit einen Fehler bei der Auswahl des Texturformates. So führte es dazu, dass sobald ich eine Textur mit Alphakanal und dem Standard Texturformat an OpenGL übergab, er als Farbtiefe 16 Bit verwendete. Wenn ich ein Foto genommen hätte wäre mir das wahrscheinlich gar nicht aufgefallen aber dummerweise (oder glücklicherweise) hatte ich aber eine Textur mit einem weichem Farbverlauf. Wie zu erwarten war sah das natürlich alles ziemlich schrecklich aus. Bis dahin kann der Loader ja nichts dafür wenn in einem Treiber ein Fehler existiert. Nur das kuriose an dem Ganzen war, dass meine Textur in Wirklichkeit gar keinen Alphakanal haben durfte. Also habe ich mich auf die Suche nach der Ursache gemacht und bin auch prompt fündig geworden. Der Loader war der Meinung er müsse alle Texturen mit einem Alphakanal versehen ungeachtet der Tatsache ob sie nun einen hatten oder eben nicht. Das ist natürlich eine Sache mit der ich mich nicht abfinden wollte. Kurz darauf begann ich also eine Ableitung der glBMP Texturenklasse zu erstellen und dort musste ich mit Schrecken feststellen, dass die Rechte in der Klasse so ungünstig vergeben wurden, dass ich keine andere Wahl gehabt hätte als direkt die Unit zu editieren. Da ich ungern externe Quellen editiere habe ich für mich die andere Alternative entschieden. Was dabei rausgekommen ist sieht man ja jetzt.

Gefunden werden kann sie entweder im DGL-SDK oder auf der [http://www.dev-center.de/index.php?cat=header&file=glbitmap Webseite] von [[Benutzer:Lossy eX|Lossy eX]].

== Allgemeines und Features ==

Dieser Artikel geht nicht darauf ein was zu tun ist um in OpenGL eine Textur darstellen zu können. In ihm werde ich lediglich darauf eingehen was man tun kann und muss um mittels der glBitmap eine Textur laden zu können. Außerdem werden die verfügbaren Einstellungen und ihre Wirkungen erklärt. Für alles andere wäre es besser das [[Tutorial_lektion4|Tutorial über Texturen]] durchzulesen.

Der wichtigste Unterschied zu den bestehenden Loadern bringe ich gleich einmal als erstes. Die glBitmap legt die Texturen anders im Speicher ab. Um zwar im speziellen meine ich damit die 2D Texturen. Bei bestehenden Loadern werden diese Texturen mit der untersten Zeile zu erst im Speicher abgelegt. In der glBitmap werden sie aber mit der obersten Zeile zu erst abgelegt. Man könnte auch sagen, dass sie bei den bestehenden Loadern auf dem Kopf stehen. Beide Möglichkeiten funktionieren und sind korrekt. Das Einzige was sich in diesem Zusammenhang ändert ist die [[glTexCoord| Adressierung der Texturen]]. Sie müssen entsprechend geändert werden. Sollte das nicht möglich sein so besteht mit der Methode FlipVert die Möglichkeit die Textur zu spiegeln. Näheres in Abschnitt [[Glbitmap_loader#Texturen_konfigurieren|Texturen konfigurieren]]. Im Normalfall sollte das andere Verhalten nicht zu Problemen führen sondern die Arbeit damit vereinfachen und verständlicher gestalten.

Die glBitmap holt sich ihre Daten ausschließlich aus Streams. Das zugrundeliegende Format wird automatisch anhand des Inhaltes der Daten ausgewählt. Es besteht also kein Notwendigkeit daran, dass der Entwickler wissen muss um welches Format es sich in Wirklichkeit handelt.

=== unterstütze Formate ===

* Windows Bitmaps (*.bmp) Wird Automatisch auf 24 Bit gesetzt sollte es kleiner sein.
* JPEG (*.jpg)
* TARGA (*.tga) unkomprimiert, 24 und 32 Bit. Ursprung unten links oder oben links
* Portable Network Graphics (*.png) 24 Bit mit oder ohne Alphakanal. Es wird eine zusätzliche Bibliothek benötigt.
Es besteht auch die Möglichkeit die Bilddaten dynamisch generieren zu lassen oder sie aus einer Instanz der Klasse TBitmap zu laden. Diese Instanz muss dann aber als Pixelformat 24 oder 32 Bit haben.

Um PNG's laden zu können muss eine externe Bibliothek namens [http://pngdelphi.sourceforge.net/ PNGImage] eingebunden und das Define pngimage hinzugefügt werden. Alternativ dazu kann das Define auch in der glBitmap auskommentiert werden.

== Texturen laden ==

Das Laden von Texturen kann auf 2 Weg geschehen. Bei Beiden ist aber zu beachten, dass OpenGL richtig initialisiert worden sein muss bevor man eine Textur erzeugen kann. Was noch sehr wichtig ist. Es sollte niemals eine Textur bei jedem Rendervorgang angelegt und freigegeben werden! Es ist viel effektiver, wenn man die Textur zu beginn lädt und so lange im Speicher behält bis sie nicht mehr benötigt wird. Wenn man sie erst später benötigt, dann kann man sie auch später noch nachladen aber auch dann sollte sie so lange wie nötig existieren.

=== Procedural ===

Hierbei genügt der Aufruf einer einzelnen Methode um eine Textur zu laden und diese an OpenGL zu übergeben. Allerdings auf Grund der Einfachheit steht nur das Laden aus Dateien oder Ressourcen zur Verfügung. Zusätzliche Funktionalität können dabei nicht benutzt werden. Generell empfehle ich immer die Objekt orientierte Variante.

var
Texture: TGLuint;

LoadTexture('myTex\Wall.bmp', Texture, False); // Datei laden

Damit wird die Datei Wall.bmp geladen und die TextureID wird in die Variable Texture geschrieben. Wenn die Textur dann benötigt wird, dann muss man diese entsprechend mit [[glBindTexture]] binden und das benötigte Texturtarget mit [[glEnable]] aktivieren. Das Target ist üblicherweise GL_TEXTURE_2D. Wenn die Textur nicht mehr benötigt wird sollte sie mit [[glDeleteTextures]] auch wieder frei gegeben werden.

=== Objekt orientiert ===

Dieser Abschnitt beschäftigt sich ausschließlich mit den 2D Texturen. Aber grundsätzlich lässt sich alles hier erwähnte auch auf die 1D Texturen und die Cubemaps übertragen.
Der Objekt orientierte Weg erfordert zwar eine wenig mehr Schreibarbeit aber nur so kann man den vollen Funktionsumfang der glBitmap genießen.

Als Erstes müssen wir eine Instanz der Texturenklasse definieren. Dies tun wir vorzugsweise als Member des Fensters auf dem wir zeichnen.

TForm1 = class(TForm)
// Verschiene Elemente und Events des Fensters
private
fTexture: TglBitmap2D; // Instanz unserer Textur
end;

Nun müssen wir der Textur noch Leben einhauchen.

procedure TForm1.FormShow(Sender: TObject);
begin
// OpenGL Initialisieren

fTexture := TglBitmap2D.Create; // Instanz der Klasse erstellen
fTexture.LoadFromFile('myTex\Wall.bmp'); // Datei laden
fTexture.GenTexture; // geladene Textur an OpenGL übergeben
end;

Für Schreibfaule besteht auch noch die Möglichkeit in einem überladenen Konstruktor einem Dateinamen anzugeben.

fTexture := TglBitmap2D.Create('myTex\Wall.bmp'); // Instanz erstellen und Datei laden
fTexture.GenTexture; // geladene Textur an OpenGL übergeben

In GenTexture wird im Normalfall immer überprüft ob die Textur eine gültige Größe hat. Sollte diese Überprüfung nicht gewünscht sein so kann man diese mit einem optionalen Parameter deaktivieren. Diese Überprüfung testet auch ob die Texturgröße eine Potenz von 2 ist (1, 2, 4, 8, 16 usw.) und wenn nicht ob solche Texturen von dem Rendercontex unterstützt werden.

fTexture.GenTexture(False); // Es wird keine Prüfung der Texturgröße vorgenommen.

Wenn kein Fehler aufgetreten ist und alles so funktioniert hat wie es sein sollte, dann kann die Textur benutzt werden.

fTexture.Bind; // Textur und entsprechendes Target wird aktiviert.

Sollte es nicht gewünscht werden, dass auch gleichzeitig das Target aktiviert wird so muss Bind mit dem Parameter False aufgerufen werden. Damit wird nur noch die Textur gebunden.

Sollte man die Textur einmal nicht mehr benutzen wollen so genügt es entweder eine andere Textur zu binden oder Unbind von der Texturenklasse aufzurufen. Damit wird die Textur mit der TexturID 0 gebunden und das Target deaktiviert. Auch hier existiert wieder der Parameter der es verhindert, dass das Target deaktiviert wird.

Wenn die Anwendung beendet wird müssen wir auch hier unsere Textur wieder frei geben. Dies geschieht so.

fTexture.Free; // Textur wieder frei geben.

Hierbei ist zu beachten, dass dies nach Möglichkeit vor dem Löschen des Rendercontex geschehen sollte, da so die Textur zu einem sinnvollem Zeitpunkt gelöscht werden kann. Wenn der Rendercontex nicht mehr existiert, so sollte die Textur auch nicht mehr existieren und wenn man dann noch einmal versucht sie zu löschen so könnte es zu Problemen führen. Bisher ist mir kein Fall bekannt aber ausschließen kann man es auch nicht. Also zu erst immer die Texturen frei geben und anschließend des Rendercontex löschen.

== Das leidige Thema Alphakanal ==

Es gibt zwei Möglichkeiten einen Alphakanal in eine Textur zu integrieren. Der einfachste und schnellste Weg ist, wenn sich dieser Kanal von Beginn an in die Textur befindet. Dazu wird ein Grafikprogramm benötigt welches so etwas unterstützt und ein Dateiformat welches das Speichern eines Alphakanals ermöglicht. Ein solches Programm ist zum Beispiel [http://www.gimp.org/ Gimp]. Also mögliche Dateiformate kämen TGA's und PNG's in Frage. Alle anderen Formate unterstützen keinen Alphakanal. Sollte man sich für diesen Weg entscheiden so genügt es dann ganz normal die Textur zu laden und zu benutzen und schon besitzen wir einen funktionierenden Alphakanal. Ich persönlich empfehle bis auf wenige Ausnahmen immer diesen Weg.

Nichts desto trotz habe ich ja gesagt, dass es noch eine Möglichkeit gibt. Bei diesem Weg haben wir Alphakanal und RGB Daten in zwei getrennten Bildern vorliegen. Aber wie bekommen wir das jetzt in ein Bild? Dafür bietet die glBitmap die Möglichkeit einen Alphakanal aus einem separaten Bild zu laden. Zu Beginn benötigen wir jedoch wieder eine Instanz der Klasse und es müssen schon normale Bilddaten geladen worden sein. Und ganz Wichtig damit es überhaupt funktioniert. Der Aufruf muss vor GenTexture stattfinden, da sonst die Textur bereits an OpenGL übergeben wurde.

fTexture.AddAlphaFromFile('myTex\Wall_alpha.bmp'); // Alphakanal aus Datei laden

Das war alles nun sind wir im Besitz einer Textur mit einem Alphakanal. Es besteht unter anderem auch die Möglichkeit den Alphakanal aus verschiedenen anderen Quellen zu laden (Resourcen, Streams, TBitmap). Zusätzlich dazu kann man den Kanal aber auch dynamisch erstellen. Dafür existiert die Methode AddAlphaFromFunc. Die Findigen unter euch habe aber bestimmt schon herausgefunden, dass man bei alle Methoden solch eine Function übergeben kann. Näheres dazu findet ihr im Abschnitt e = mc²

Etwas was häufiger gebraucht wird habe ich von Hause aus schon implementiert. Und zwar das Erstellen eines Alphakanals anhand einer Farbe.

fTexture.AddAlphaFromColorKey(Red, Green, Blue, Deviation); // Alphakanal anhand einer Farbe hinzufügen

Dabei wird nur auf vollkommen durchlässig und nicht durchlässig unterschieden. Alle Pixel die die angegebene Farbe besitzen werden dabei als 0 (nicht Sichtbar) in den Alphakanal geschrieben alle anderen erhalten 255 (Sichtbar). Die Deviation bestimmt eine Abweichung um der die Farben abweichen dürfen um trotzdem noch als Transparent erkannt zu werden. Speziell für JPEG's ist das nicht unwichtig, da die Bilder beim Komprimieren leicht abgewandelt werden.

Damit die OpenGL Primitiven jetzt transparent dargestellt werden muss der [[GlAlphaFunc|Alphatest]] oder das [[glBlendFunc|Blending]] aktiviert sein. Sonst nützt einem der Alphakanal nicht sonderlich viel.

Entfernen kann man einen Alphakanal natürlich auch. Dazu genügt der Aufruf von RemoveAlpha. Dieser muss natürlich nicht mit der glBitmap erstellt worden sein. Er kann auch aus einer Datei geladen worden sein.

fTexture.RemoveAlpha; // entfernt den Alphakanal

== Texturen konfigurieren ==

Hier beginnt jetzt der Teil der für die Meisten recht wichtig sein dürfte. Bisher haben wir ja nur Daten geladen und diese an OpenGL übergeben. Nun wollen wir aber ein wenig an den Einstellungen rumschrauben und sehen was wir daraus machen können.

Folgende Einstellungsmöglichkeiten verändern ausschließlich nur das Verhalten der glBitmap. Sie haben keinen Einfluss auf die resultierende Textur.

DeleteTextureOnFree ist vom Typ Boolean und gibt an ob beim Freigeben der Klasse die Texture auch freigegeben wird oder ob weiter existieren darf. Standard wird sie mit freigegeben.

FreeDataAfterGenTexture ist vom Typ Boolean und gibt an ob die Bilddaten nach dem Erzeugen der Textur aus dem Hauptspeicher entfernt werden sollen oder nicht. Im Normalfall werden sie das auch.

Target ist vom Typ Cardinal und bestimmt das OpenGL Target. Wird von den Klassen auf den Standardwert gesetzt und muss nur dann auf einen anderen Wert gesetzt werden, wenn ein anderes Target verwendet werden soll. Zum Beispiel bei der Verwendung von Texture_rectangle. Es sollte aber immer direkt nach dem erstellen gesetzt werden, da die Textur sonst unbrauchbar gemacht werden könnte.

Format ist ein Aufzählungstyp und er erlaubt 4 Werte.
<table border="0" rules="all">
<tr>
<td>tfDefault</td>
<td>Dabei wird das Standardformat des Grafikkartentreibers benutzt. Je nach eingestellter Qualität kann dies 16 oder 32 Bit sein.</td>
</tr>
<tr>
<td>tf16Bit</td>
<td>Hier wird die Textur in 16Bit abgelegt.</td>
</tr>
<tr>
<td>tf32Bit</td>
<td>Hier wird die Textur in 32Bit abgelegt.</td>
</tr>
<tr>
<td>tfCompressed</td>
<td>Bei diesem Format wird zu erst geschaut ob eines der folgenden Kriterien erfüllt ist. Extension GL_ARB_texture_compression, OpenGL Version 1.3 oder die Extension GL_EXT_texture_compression_s3tc. Sollten alle 3 Möglichkeiten nicht funktionieren so wird das Standardformat vom Grafikkartentreiber benutzt.</td>
</tr>
</table>

MipMap ist ebenfalls ein Aufzählungstyp und er erlaubt 3 Werte.
<table border="0" rules="all">
<tr>
<td>mmNone</td>
<td>Wie man vermuten könnte werden hierbei keine Mipmaps erstellt.</td>
</tr>
<tr>
<td>mmMipmap</td>
<td>Ähnlich wie bei komprimierten Texturen werden zu erst verschiedene neue Möglichkeiten überprüft. Ab OpenGL Version 1.4 oder mit der Extension GL_SGIS_generate_mipmap unterstützt die Grafikkarte ein generieren der [[Mipmaps]]. Das ist natürlich wesentlich schneller als der Weg ausschließlich über die Software. Sollte es keinen anderen Weg geben so werden die [[Mipmaps]] mittels der GLU generiert.</td>
</tr>
<tr>
<td>mmMipmapGlu</td>
<td>In diesem Falle werden die [[Mipmaps]] ausschließlich mit der GLU erstellt.</td>
</tr>
</table>

Mithilfe der Methoden SetFilter und SetWrap können das Filterverhalten und das Beschränken der Texturkoordinaten angepasst werden. Eine genaue Auflistung möglicher Werte findet man beim Artikel zu [[glTexParameter]]. Das Aufrufen der Methoden ist überall dort möglich wo auch [[gTexParameter]] gültig ist. Mögliche Fehlerhafte Werte werden automatisch auf die vorhandene Textur angepasst. So wird bei SetFilter niemals ein [[MipMaps|MipMap]] bei die Filterung eingestellt wenn keine [[MipMaps]] erzeugt wurden. Das würde sonst dazu führen, dass die Textur nicht dargestellt werden könnte.

FlipVert und FlipHorz sind Methoden die nichts anderes machen als das Bild entlang der entsprechenden Richtung (Vertikal und Horizontal) zu spiegeln. Dies wäre auch mit der Funktionsschnittstelle möglich aber besonders bei FlipVert wäre es unpraktisch da wir so nicht die komplette Zeile am Stück kopieren könnten, sondern nur Pixel für Pixel.

Zum Invertieren des Bildes genügt es die Methode Invert aufzurufen. Sie bekommt zwei boolsche Parameter mit denen man steuern kann was man invertieren möchte. Einen für RGB und einen für den Alphakanal.

== e = mc² ==

Hierbei handelt es sich um eine Möglichkeit die Texturdaten zu manipulieren. Die Schnittstelle wurde so gestaltet, dass sie sehr flexibel und typisiert ist. Sprich, dass man immer genau worum es sich handelt und welche Felder unterstützt werden. Eine einfache Handhabung und eine gute Ausführungsgeschwindigkeit waren natürlich auch sehr wichtige Punkte dabei. Finden kann man die Funktionsschnittstelle bei dem Hinzufügen des Alphakanals oder immer wenn man möchte durch die Methode AddFunc. Es gibt außerdem noch eine Reihe von Funktionen, die intern die Schnittstelle benutzen. Das wären zum Beispiel die Funktionen Invert, AddAlphaFromColokey, ToNormalMap und FillWithColor. Die Klasse TglBitmapNormalMap generiert ihre Texturen zum Beispiel mit der Schnittstelle.

Die Arbeitsweise der Funktionsschnittstelle ist recht einfach. Es wird nichts anderes gemacht als 1 Mal Zeile für Zeile den Pointer eines jeden Pixels an eine Funktion zu Übergeben und darauf zu vertrauen, dass sie das Richtige tut. Um die Ausführung zu Beschleunigen wird ausschließlich mit Pointern gearbeitet. Die Funktionen bekommen die Instanz des Objektes, die Größe, die Position, das Quellpixel, das Zielpixel und einen Pointer auf benutzerdefinierte Daten übergeben. Das ist natürlich eine ganze Menge Holz was da an Daten übergeben aber das ist alles notwendig um die gewünschte Flexibilität erreichen zu können.

Betrachten wir das ganze mal an einem Beispiel. Und zwar dem Aufruf von Invert. Zu erst einmal der Aufruf der Funktion.

if ((UseRGB) or (UseAlpha))
then AddFunc(glBitmapInvertFunc, False, Pointer(Integer(UseAlpha and HasAlpha) shl 1 or Integer(UseRGB)));

In Zeile 1 handelt es sich lediglich um eine kleine Sicherheit. Es bringt ja nichts, wenn man eine Funktion ausführen möchte die keinen Nutzen hat. Zeile 2 Ruft die Methode AddFunc auf. Diese Methode bekommt als erstes unsere Funktion übergeben. Zu deren Aufbau komme ich gleich. Als Zweites bekommt AddFunc gesagt ob sie eine Kopie des Bildes erstellen soll. Für pixelübergreifende Funktionen ist dies unerlässlich, da man sich sonst seine noch benötigten Daten überschreiben würde. Der dritte Wert ist ein Pointer der zusätzliche Informationen hält. In diesem Falle handelt es sich lediglich um ein Bitset bei dem Bit 2 den Alphakanal und Bit 1 die RGB Werte repräsentiert. Es könnte sich dabei aber auch um einen Pointer auf ein Record handeln.

procedure glBitmapInvertFunc(Sender : TglBitmap; const Position, Size: TglBitmapPixelPosition;
const Source, Dest: TglBitmapPixelData; const Data: Pointer);
begin
if (Integer(Data) and $1 > 0) then begin
Dest.ptRed^ := not Dest.ptRed^;
Dest.ptGreen^ := not Dest.ptGreen^;
Dest.ptBlue^ := not Dest.ptBlue^;
end;

if (Integer(Data) and $2 > 0) then begin
Dest.ptAlpha^ := not Dest.ptAlpha^;
end;
end;

Position und Size beinhalten die Aktuelle Position des Pixels und die Größe des Bildes. Das Record TglBitmapPixelPosition beinhält 4 Werte. Fields, X, Y, Z. Fields beschreibt welche Felder überhaupt zur Verfügung stehen. Mögliche Werte Dafür sind ffX, ffY und ffZ. Wofür X, Y und Z stehen erkläre ich jetzt mal nicht, dass sollte jedem klar sein. Bei einem 2D Bitmap sind üblicherweise die Felder X und Y mit leben gefüllt. Das Feld Z liegt brach.

Source und Dest beinhalten die Pixeldaten. Die Records sind ziemlich genau so aufgebaut wie das für die Position. Es gibt einen Wert Fields. Mögliche Werte für ihn sind ffRed, ffGreen, ffBlue und ffAlpha. Diese Felder sind anders als bei bei Position keine richtigen Werte sondern Pointer die Direkt auf die Farbwerte in den Bildern zeigen. Es gibt deswegen Source und Dest, da es ja die Möglichkeit gibt eine Kopie des Bildes zu erstellen. Sollte ohne Kopie gearbeitet werden so sind Source und Dest gleich. Bei hinzufügen eines Alphakanals bezieht sich Source auf die Pixeldaten im dem Quellbild und Dest wie gewohnt auf die Daten im Zielbild.

In dem obigen Beispiel werden die Bits des Parameters Data ausgewertet und die entsprechenden Kanäle negiert. Der Komplexibilität sind kaum Grenzen gesetzt. Alle Wissensdurstigen unter euch sollten sich dann auch mal die Methode ToNormalMap anschauen. Dort werden zwei Funktionen aufgerufen. In der Ersten werden Daten gesammelt mit denen in der Zweiten die Normalmap berechnet wird. Oder auch die Klasse TglBitmapNormalMap. In dieser wird eine generelle Berechnungsroutine aufgerufen. Diese bekommt aber für jede Fläche der Map eine andere interne Methode übergeben. Mit dieser werden dann die Werte für jedes Pixel gefüllt.

Noch ein Wort für alle Geschwindigkeitsfanatiker. Ich hatte ein mal spaßeshalber die Methode FlipHorz nachgebaut und die Geschwindigkeit gemessen. Das Ergebnis hat mich selber sehr angenehm überrascht. Die Hardcodierte super optimierte Methode benötigte bei 300 Aufrufen, auf ein 512x512 Pixel großes Bild ca. 5 Sekunden. Die Methode mit dem Funktionsaufruf benötigte Lediglich 300 ms länger. Ich selber hätte eher mit dem Doppelten der Zeit gerechnet.

== Cubemaps mit glBitmap ==

Das einzige worin sich CubeMaps von 2D Texturen unterscheidet ist das Laden. Aber das ist auch nicht viel komplizierter als bei 2D Texturen. Die Handhabung mit den Texturen (Binden, Frei geben) ist wie bei 2D Texturen weswegen ich das auch nicht noch einmal extra wiederholen werde.

=== Procedural ===

Wie auch bei den 2D Texturen haben wir die Auswahl zwischen zwei möglichen Wegen. Der procedurale Weg unterscheidet sich lediglich in der Anzahl der angegebenen Texturen. Das sind diesmal natürlich ein paar mehr.

var
Texture: TGLuint;

// Cubemaps laden
LoadCubeMap('xpos.bmp', 'xneg.bmp', 'ypos.bmp', 'yneg.bmp', 'zpos.bmp', 'zneg.bmp', Texture, False);

Die ersten 6 Parameter geben die jeweils 6 Texturen an. Die Namen der Parameter geben auch gleichzeitig deren Ziel an. Also immer schön auf die Reihenfolge achten. In dem Siebten wird die Textur ID geschrieben und der Achte gibt an ob aus Resourcen geladen werden soll oder nicht.

=== Objekt orientiert ===

Der Objekt orientierte Weg gestaltet sich dieses mal ein wenig schreibintensiver. Es müssen ja auch schließlich 6 Texturen geladen werden. Aber das kann man auch praktischerweise in eine Schleife packen. Das praktische daran ist, dass wir alles mit nur einer Klasseninstanz lösen können (und auch müssen).

fCubeMap := TglBitmapCubeMap.Create; // Instanz der Klasse erstellen
fCubeMap.LoadFromFile('xpos.jpg'); // Datei Laden

Die Textur wird normal angelegt und es wird wie gewöhnt ein Bild in den Speicher der Klasse geladen. Dieses Bild verhält sich wie jedes andere Bild. Es kann also wie gewöhnt manipuliert werden. Zum Beispiel durch die Funktionsschnittstelle.

fCubeMap.GenerateCubeMap(GL_TEXTURE_CUBE_MAP_POSITIVE_X); // Einzelnen Teil übergeben

Wenn die Textur also bereit zum Übergeben ist, dann müssen wir GenerateCubeMap mit dem entsprechenden Teil der Cubemap aufrufen. In diesem Falle ist es die positive X Achse. Das müssen wir dann natürlich noch mit allen anderen Maps machen. Also Bild laden, evtl bearbeiten und dann an OpenGL übergeben. Die Reihenfolge der Maps spielt hierbei keine Rolle. Wichtig ist nur, dass sie die selbe Auflösung und das selbe Format haben. Die Methode GenTexture steht bei dieser Klasse nicht zur Verfügung, da beim ersten Aufruf von GenerateCubeMap automatisch die OpenGL Textur erzeugt wird. Die CubeMap ist nur dann einsetzbar, wenn alle Maps erfolgreich mit Daten versorgt wurden.

Beim Binden der CubeMap existiert ein zusätzlicher Parameter mit dem man die Aktivierung der automatische Generation der Texturkoordinaten deaktivieren kann. Standard ist dieses eingeschalten. Ähnlich wie beim Binden einer Textur. Dort kann man verhindern, dass das Target aktiviert wird.

== Bekannte Probleme und Einschränkungen ==

Vor einer Weile wurde im Forum die Frage gestellt warum die glBitmap beim Laden eines BMP's einen "Stream Read Error" produziert. Da das Bitmap nun mal ein sehr einfaches Format ist hat mich das auch sehr stark verwundert. Nach langem hin und her Rätseln kam ich dann dennoch darauf was das Problem war. Es daran, dass das Bitmap mit MS Paint abgespeichert wurde. Dieser war aber der Meinung er müsse im Bitmapheader eine Größe angeben die 2 Bytes größer war als die eigentlichen Daten. Diese 2 Bytes wurden auch aufgefüllt aber leider ist das TBitmap, welches ich zum Laden verwende, nicht so tolerant um über darüber hinweg zu sehen. Und so bekommt man einen Fehler beim Laden. Den selben Fehler würde man auch bekommen wenn man das Bild in einem TImage anzeigen wollte.

Abhelfen kann man dies in dem man ein [http://www.gimp.org/ alternatives Grafikprogramm (Gimp)] verwendet oder das Bild einmal mit dem Bildbetrachter [http://www.irfanview.de/ IrfanView] öffnet und abspeichert.

Es muss nicht bei jedem mit MS Paint abgespeicherten Bild auftreten.

Glbitmap loader

2005-06-22T07:53:31Z

Lossy eX: /* Das leidige Thema Alphakanal */

{{unvollständig}}
= glBitmap - Texturenloader =

== Warum das Ganze und wo kann ich sie finden? ==

Früher benutzte ich die glBMP, da sie so "schön" Objekt orientiert war. Leider hatte mein Grafiktreiber zu der Zeit einen Fehler bei der Auswahl des Texturformates. So führte es dazu, dass sobald ich eine Textur mit Alphakanal und dem Standard Texturformat an OpenGL übergab, er als Farbtiefe 16 Bit verwendete. Wenn ich ein Foto genommen hätte wäre mir das wahrscheinlich gar nicht aufgefallen aber dummerweise (oder glücklicherweise) hatte ich aber eine Textur mit einem weichem Farbverlauf. Wie zu erwarten war sah das natürlich alles ziemlich schrecklich aus. Bis dahin kann der Loader ja nichts dafür wenn in einem Treiber ein Fehler existiert. Nur das kuriose an dem Ganzen war, dass meine Textur in Wirklichkeit gar keinen Alphakanal haben durfte. Also habe ich mich auf die Suche nach der Ursache gemacht und bin auch prompt fündig geworden. Der Loader war der Meinung er müsse alle Texturen mit einem Alphakanal versehen ungeachtet der Tatsache ob sie nun einen hatten oder eben nicht. Das ist natürlich eine Sache mit der ich mich nicht abfinden wollte. Kurz darauf begann ich also eine Ableitung der glBMP Texturenklasse zu erstellen und dort musste ich mit Schrecken feststellen, dass die Rechte in der Klasse so ungünstig vergeben wurden, dass ich keine andere Wahl gehabt hätte als direkt die Unit zu editieren. Da ich ungern externe Quellen editiere habe ich für mich die andere Alternative entschieden. Was dabei rausgekommen ist sieht man ja jetzt.

Gefunden werden kann sie entweder im DGL-SDK oder auf der [http://www.dev-center.de/index.php?cat=header&file=glbitmap Webseite] von [[Benutzer:Lossy eX|Lossy eX]].

== Allgemeines und Features ==

Dieser Artikel geht nicht darauf ein was zu tun ist um in OpenGL eine Textur darstellen zu können. In ihm werde ich lediglich darauf eingehen was man tun kann und muss um mittels der glBitmap eine Textur laden zu können. Außerdem werden die verfügbaren Einstellungen und ihre Wirkungen erklärt. Für alles andere wäre es besser das [[Tutorial_lektion4|Tutorial über Texturen]] durchzulesen.

Der wichtigste Unterschied zu den bestehenden Loadern bringe ich gleich einmal als erstes. Die glBitmap legt die Texturen anders im Speicher ab. Um zwar im speziellen meine ich damit die 2D Texturen. Bei bestehenden Loadern werden diese Texturen mit der untersten Zeile zu erst im Speicher abgelegt. In der glBitmap werden sie aber mit der obersten Zeile zu erst abgelegt. Man könnte auch sagen, dass sie bei den bestehenden Loadern auf dem Kopf stehen. Beide Möglichkeiten funktionieren und sind korrekt. Das Einzige was sich in diesem Zusammenhang ändert ist die [[glTexCoord| Adressierung der Texturen]]. Sie müssen entsprechend geändert werden. Sollte das nicht möglich sein so besteht mit der Methode FlipVert die Möglichkeit die Textur zu spiegeln. Näheres in Abschnitt [[Glbitmap_loader#Texturen_konfigurieren|Texturen konfigurieren]]. Im Normalfall sollte das andere Verhalten nicht zu Problemen führen sondern die Arbeit damit vereinfachen und verständlicher gestalten.

Die glBitmap holt sich ihre Daten ausschließlich aus Streams. Das zugrundeliegende Format wird automatisch anhand des Inhaltes der Daten ausgewählt. Es besteht also kein Notwendigkeit daran, dass der Entwickler wissen muss um welches Format es sich in Wirklichkeit handelt.

=== unterstütze Formate ===

* Windows Bitmaps (*.bmp) Wird Automatisch auf 24 Bit gesetzt sollte es kleiner sein.
* JPEG (*.jpg)
* TARGA (*.tga) unkomprimiert, 24 und 32 Bit. Ursprung unten links oder oben links
* Portable Network Graphics (*.png) 24 Bit mit oder ohne Alphakanal. Es wird eine zusätzliche Bibliothek benötigt.
Es besteht auch die Möglichkeit die Bilddaten dynamisch generieren zu lassen oder sie aus einer Instanz der Klasse TBitmap zu laden. Diese Instanz muss dann aber als Pixelformat 24 oder 32 Bit haben.

Um PNG's laden zu können muss eine externe Bibliothek namens [http://pngdelphi.sourceforge.net/ PNGImage] eingebunden und das Define pngimage hinzugefügt werden. Alternativ dazu kann das Define auch in der glBitmap auskommentiert werden.

== Texturen laden ==

Das Laden von Texturen kann auf 2 Weg geschehen. Bei Beiden ist aber zu beachten, dass OpenGL richtig initialisiert worden sein muss bevor man eine Textur erzeugen kann. Was noch sehr wichtig ist. Es sollte niemals eine Textur bei jedem Rendervorgang angelegt und freigegeben werden! Es ist viel effektiver, wenn man die Textur zu beginn lädt und so lange im Speicher behält bis sie nicht mehr benötigt wird. Wenn man sie erst später benötigt, dann kann man sie auch später noch nachladen aber auch dann sollte sie so lange wie nötig existieren.

=== Procedural ===

Hierbei genügt der Aufruf einer einzelnen Methode um eine Textur zu laden und diese an OpenGL zu übergeben. Allerdings auf Grund der Einfachheit steht nur das Laden aus Dateien oder Ressourcen zur Verfügung. Zusätzliche Funktionalität können dabei nicht benutzt werden. Generell empfehle ich immer die Objekt orientierte Variante.

var
Texture: TGLuint;

LoadTexture('myTex\Wall.bmp', Texture, False); // Datei laden

Damit wird die Datei Wall.bmp geladen und die TextureID wird in die Variable Texture geschrieben. Wenn die Textur dann benötigt wird, dann muss man diese entsprechend mit [[glBindTexture]] binden und das benötigte Texturtarget mit [[glEnable]] aktivieren. Das Target ist üblicherweise GL_TEXTURE_2D. Wenn die Textur nicht mehr benötigt wird sollte sie mit [[glDeleteTextures]] auch wieder frei gegeben werden.

=== Objekt orientiert ===

Dieser Abschnitt beschäftigt sich ausschließlich mit den 2D Texturen. Aber grundsätzlich lässt sich alles hier erwähnte auch auf die 1D Texturen und die Cubemaps übertragen.
Der Objekt orientierte Weg erfordert zwar eine wenig mehr Schreibarbeit aber nur so kann man den vollen Funktionsumfang der glBitmap genießen.

Als Erstes müssen wir eine Instanz der Texturenklasse definieren. Dies tun wir vorzugsweise als Member des Fensters auf dem wir zeichnen.

TForm1 = class(TForm)
// Verschiene Elemente und Events des Fensters
private
fTexture: TglBitmap2D; // Instanz unserer Textur
end;

Nun müssen wir der Textur noch Leben einhauchen.

procedure TForm1.FormShow(Sender: TObject);
begin
// OpenGL Initialisieren

fTexture := TglBitmap2D.Create; // Instanz der Klasse erstellen
fTexture.LoadFromFile('myTex\Wall.bmp'); // Datei laden
fTexture.GenTexture; // geladene Textur an OpenGL übergeben
end;

Für Schreibfaule besteht auch noch die Möglichkeit in einem überladenen Konstruktor einem Dateinamen anzugeben.

fTexture := TglBitmap2D.Create('myTex\Wall.bmp'); // Instanz erstellen und Datei laden
fTexture.GenTexture; // geladene Textur an OpenGL übergeben

In GenTexture wird im Normalfall immer überprüft ob die Textur eine gültige Größe hat. Sollte diese Überprüfung nicht gewünscht sein so kann man diese mit einem optionalen Parameter deaktivieren. Diese Überprüfung testet auch ob die Texturgröße eine Potenz von 2 ist (1, 2, 4, 8, 16 usw.) und wenn nicht ob solche Texturen von dem Rendercontex unterstützt werden.

fTexture.GenTexture(False); // Es wird keine Prüfung der Texturgröße vorgenommen.

Wenn kein Fehler aufgetreten ist und alles so funktioniert hat wie es sein sollte, dann kann die Textur benutzt werden.

fTexture.Bind; // Textur und entsprechendes Target wird aktiviert.

Sollte es nicht gewünscht werden, dass auch gleichzeitig das Target aktiviert wird so muss Bind mit dem Parameter False aufgerufen werden. Damit wird nur noch die Textur gebunden.

Sollte man die Textur einmal nicht mehr benutzen wollen so genügt es entweder eine andere Textur zu binden oder Unbind von der Texturenklasse aufzurufen. Damit wird die Textur mit der TexturID 0 gebunden und das Target deaktiviert. Auch hier existiert wieder der Parameter der es verhindert, dass das Target deaktiviert wird.

Wenn die Anwendung beendet wird müssen wir auch hier unsere Textur wieder frei geben. Dies geschieht so.

fTexture.Free; // Textur wieder frei geben.

Hierbei ist zu beachten, dass dies nach Möglichkeit vor dem Löschen des Rendercontex geschehen sollte, da so die Textur zu einem sinnvollem Zeitpunkt gelöscht werden kann. Wenn der Rendercontex nicht mehr existiert, so sollte die Textur auch nicht mehr existieren und wenn man dann noch einmal versucht sie zu löschen so könnte es zu Problemen führen. Bisher ist mir kein Fall bekannt aber ausschließen kann man es auch nicht. Also zu erst immer die Texturen frei geben und anschließend des Rendercontex löschen.

== Das leidige Thema Alphakanal ==

Es gibt zwei Möglichkeiten einen Alphakanal in eine Textur zu integrieren. Der einfachste und schnellste Weg ist, wenn sich dieser Kanal von Beginn an in die Textur befindet. Dazu wird ein Grafikprogramm benötigt welches so etwas unterstützt und ein Dateiformat welches das Speichern eines Alphakanals ermöglicht. Ein solches Programm ist zum Beispiel [http://www.gimp.org/ Gimp]. Also mögliche Dateiformate kämen TGA's und PNG's in Frage. Alle anderen Formate unterstützen keinen Alphakanal. Sollte man sich für diesen Weg entscheiden so genügt es dann ganz normal die Textur zu laden und zu benutzen und schon besitzen wir einen funktionierenden Alphakanal. Ich persönlich empfehle bis auf wenige Ausnahmen immer diesen Weg.

Nichts desto trotz habe ich ja gesagt, dass es noch eine Möglichkeit gibt. Bei diesem Weg haben wir Alphakanal und RGB Daten in zwei getrennten Bildern vorliegen. Aber wie bekommen wir das jetzt in ein Bild? Dafür bietet die glBitmap die Möglichkeit einen Alphakanal aus einem separaten Bild zu laden. Zu Beginn benötigen wir jedoch wieder eine Instanz der Klasse und es müssen schon normale Bilddaten geladen worden sein. Und ganz Wichtig damit es überhaupt funktioniert. Der Aufruf muss vor GenTexture stattfinden, da sonst die Textur bereits an OpenGL übergeben wurde.

fTexture.AddAlphaFromFile('myTex\Wall_alpha.bmp'); // Alphakanal aus Datei laden

Das war alles nun sind wir im Besitz einer Textur mit einem Alphakanal. Es besteht unter anderem auch die Möglichkeit den Alphakanal aus verschiedenen anderen Quellen zu laden (Resourcen, Streams, TBitmap). Zusätzlich dazu kann man den Kanal aber auch dynamisch erstellen. Dafür existiert die Methode AddAlphaFromFunc. Die Findigen unter euch habe aber bestimmt schon herausgefunden, dass man bei alle Methoden solch eine Function übergeben kann. Näheres dazu findet ihr im Abschnitt e = mc²

Etwas was häufiger gebraucht wird habe ich von Hause aus schon implementiert. Und zwar das Erstellen eines Alphakanals anhand einer Farbe.

fTexture.AddAlphaFromColorKey(Red, Green, Blue, Deviation); // Alphakanal anhand einer Farbe hinzufügen

Dabei wird nur auf vollkommen durchlässig und nicht durchlässig unterschieden. Alle Pixel die die angegebene Farbe besitzen werden dabei als 0 (nicht Sichtbar) in den Alphakanal geschrieben alle anderen erhalten 255 (Sichtbar). Die Deviation bestimmt eine Abweichung um der die Farben abweichen dürfen um trotzdem noch als Transparent erkannt zu werden. Speziell für JPEG's ist das nicht unwichtig, da die Bilder beim Komprimieren leicht abgewandelt werden.

Damit die OpenGL Primitiven jetzt transparent dargestellt werden muss der [[GlAlphaFunc|Alphatest]] oder das [[glBlendFunc|Blending]] aktiviert sein. Sonst nützt einem der Alphakanal nicht sonderlich viel.

Entfernen kann man einen Alphakanal natürlich auch. Dazu genügt der Aufruf von RemoveAlpha. Dieser muss natürlich nicht mit der glBitmap erstellt worden sein. Er kann auch aus einer Datei geladen worden sein.

fTexture.RemoveAlpha; // entfernt den Alphakanal

== Texturen konfigurieren ==

Hier beginnt jetzt der Teil der für die Meisten recht wichtig sein dürfte. Bisher haben wir ja nur Daten geladen und diese an OpenGL übergeben. Nun wollen wir aber ein wenig an den Einstellungen rumschrauben und sehen was wir daraus machen können.

Folgende Einstellungsmöglichkeiten verändern ausschließlich nur das Verhalten der glBitmap. Sie haben keinen Einfluss auf die resultierende Textur.

DeleteTextureOnFree ist vom Typ Boolean und gibt an ob beim Freigeben der Klasse die Texture auch freigegeben wird oder ob weiter existieren darf. Standard wird sie mit freigegeben.

FreeDataAfterGenTexture ist vom Typ Boolean und gibt an ob die Bilddaten nach dem Erzeugen der Textur aus dem Hauptspeicher entfernt werden sollen oder nicht. Im Normalfall werden sie das auch.

Target ist vom Typ Cardinal und bestimmt das OpenGL Target. Wird von den Klassen auf den Standardwert gesetzt und muss nur dann auf einen anderen Wert gesetzt werden, wenn ein anderes Target verwendet werden soll. Zum Beispiel bei der Verwendung von Texture_rectangle. Es sollte aber immer direkt nach dem erstellen gesetzt werden, da die Textur sonst unbrauchbar gemacht werden könnte.

Format ist ein Aufzählungstyp und er erlaubt 4 Werte.
<table border="0" rules="all">
<tr>
<td>tfDefault</td>
<td>Dabei wird das Standardformat des Grafikkartentreibers benutzt. Je nach eingestellter Qualität kann dies 16 oder 32 Bit sein.</td>
</tr>
<tr>
<td>tf16Bit</td>
<td>Hier wird die Textur in 16Bit abgelegt.</td>
</tr>
<tr>
<td>tf32Bit</td>
<td>Hier wird die Textur in 32Bit abgelegt.</td>
</tr>
<tr>
<td>tfCompressed</td>
<td>Bei diesem Format wird zu erst geschaut ob eines der folgenden Kriterien erfüllt ist. Extension GL_ARB_texture_compression, OpenGL Version 1.3 oder die Extension GL_EXT_texture_compression_s3tc. Sollten alle 3 Möglichkeiten nicht funktionieren so wird das Standardformat vom Grafikkartentreiber benutzt.</td>
</tr>
</table>

MipMap ist ebenfalls ein Aufzählungstyp und er erlaubt 3 Werte.
<table border="0" rules="all">
<tr>
<td>mmNone</td>
<td>Wie man vermuten könnte werden hierbei keine Mipmaps erstellt.</td>
</tr>
<tr>
<td>mmMipmap</td>
<td>Ähnlich wie bei komprimierten Texturen werden zu erst verschiedene neue Möglichkeiten überprüft. Ab OpenGL Version 1.4 oder mit der Extension GL_SGIS_generate_mipmap unterstützt die Grafikkarte ein generieren der [[Mipmaps]]. Das ist natürlich wesentlich schneller als der Weg ausschließlich über die Software. Sollte es keinen anderen Weg geben so werden die [[Mipmaps]] mittels der GLU generiert.</td>
</tr>
<tr>
<td>mmMipmapGlu</td>
<td>In diesem Falle werden die [[Mipmaps]] ausschließlich mit der GLU erstellt.</td>
</tr>
</table>

Mithilfe der Methoden SetFilter und SetWrap können das Filterverhalten und das Beschränken der Texturkoordinaten angepasst werden. Eine genaue Auflistung möglicher Werte findet man beim Artikel zu [[glTexParameter]]. Das Aufrufen der Methoden ist überall dort möglich wo auch [[gTexParameter]] gültig ist. Mögliche Fehlerhafte Werte werden automatisch auf die vorhandene Textur angepasst. So wird bei SetFilter niemals ein [[MipMaps|MipMap]] bei die Filterung eingestellt wenn keine [[MipMaps]] erzeugt wurden. Das würde sonst dazu führen, dass die Textur nicht dargestellt werden könnte.

FlipVert und FlipHorz sind Methoden die nichts anderes machen als das Bild entlang der entsprechenden Richtung (Vertikal und Horizontal) zu spiegeln. Dies wäre auch mit der Funktionsschnittstelle möglich aber besonders bei FlipVert wäre es unpraktisch da wir so nicht die komplette Zeile am Stück kopieren könnten, sondern nur Pixel für Pixel.

Zum Invertieren des Bildes genügt es die Methode Invert aufzurufen. Sie bekommt zwei boolsche Parameter mit denen man steuern kann was man invertieren möchte. Einen für RGB und einen für den Alphakanal.

== e = mc² ==

{ Funktionsschnittstelle, Arbeitsweise, Möglichkeiten, Beispiele }

== Cubemaps mit glBitmap ==

Das einzige worin sich CubeMaps von 2D Texturen unterscheidet ist das Laden. Aber das ist auch nicht viel komplizierter als bei 2D Texturen. Die Handhabung mit den Texturen (Binden, Frei geben) ist wie bei 2D Texturen weswegen ich das auch nicht noch einmal extra wiederholen werde.

=== Procedural ===

Wie auch bei den 2D Texturen haben wir die Auswahl zwischen zwei möglichen Wegen. Der procedurale Weg unterscheidet sich lediglich in der Anzahl der angegebenen Texturen. Das sind diesmal natürlich ein paar mehr.

var
Texture: TGLuint;

// Cubemaps laden
LoadCubeMap('xpos.bmp', 'xneg.bmp', 'ypos.bmp', 'yneg.bmp', 'zpos.bmp', 'zneg.bmp', Texture, False);

Die ersten 6 Parameter geben die jeweils 6 Texturen an. Die Namen der Parameter geben auch gleichzeitig deren Ziel an. Also immer schön auf die Reihenfolge achten. In dem Siebten wird die Textur ID geschrieben und der Achte gibt an ob aus Resourcen geladen werden soll oder nicht.

=== Objekt orientiert ===

Der Objekt orientierte Weg gestaltet sich dieses mal ein wenig schreibintensiver. Es müssen ja auch schließlich 6 Texturen geladen werden. Aber das kann man auch praktischerweise in eine Schleife packen. Das praktische daran ist, dass wir alles mit nur einer Klasseninstanz lösen können (und auch müssen).

fCubeMap := TglBitmapCubeMap.Create; // Instanz der Klasse erstellen
fCubeMap.LoadFromFile('xpos.jpg'); // Datei Laden

Die Textur wird normal angelegt und es wird wie gewöhnt ein Bild in den Speicher der Klasse geladen. Dieses Bild verhält sich wie jedes andere Bild. Es kann also wie gewöhnt manipuliert werden. Zum Beispiel durch die Funktionsschnittstelle.

fCubeMap.GenerateCubeMap(GL_TEXTURE_CUBE_MAP_POSITIVE_X); // Einzelnen Teil übergeben

Wenn die Textur also bereit zum Übergeben ist, dann müssen wir GenerateCubeMap mit dem entsprechenden Teil der Cubemap aufrufen. In diesem Falle ist es die positive X Achse. Das müssen wir dann natürlich noch mit allen anderen Maps machen. Also Bild laden, evtl bearbeiten und dann an OpenGL übergeben. Die Reihenfolge der Maps spielt hierbei keine Rolle. Wichtig ist nur, dass sie die selbe Auflösung und das selbe Format haben. Die Methode GenTexture steht bei dieser Klasse nicht zur Verfügung, da beim ersten Aufruf von GenerateCubeMap automatisch die OpenGL Textur erzeugt wird. Die CubeMap ist nur dann einsetzbar, wenn alle Maps erfolgreich mit Daten versorgt wurden.

Beim Binden der CubeMap existiert ein zusätzlicher Parameter mit dem man die Aktivierung der automatische Generation der Texturkoordinaten deaktivieren kann. Standard ist dieses eingeschalten. Ähnlich wie beim Binden einer Textur. Dort kann man verhindern, dass das Target aktiviert wird.

== Bekannte Probleme und Einschränkungen ==

Vor einer Weile wurde im Forum die Frage gestellt warum die glBitmap beim Laden eines BMP's einen "Stream Read Error" produziert. Da das Bitmap nun mal ein sehr einfaches Format ist hat mich das auch sehr stark verwundert. Nach langem hin und her Rätseln kam ich dann dennoch darauf was das Problem war. Es daran, dass das Bitmap mit MS Paint abgespeichert wurde. Dieser war aber der Meinung er müsse im Bitmapheader eine Größe angeben die 2 Bytes größer war als die eigentlichen Daten. Diese 2 Bytes wurden auch aufgefüllt aber leider ist das TBitmap, welches ich zum Laden verwende, nicht so tolerant um über darüber hinweg zu sehen. Und so bekommt man einen Fehler beim Laden. Den selben Fehler würde man auch bekommen wenn man das Bild in einem TImage anzeigen wollte.

Abhelfen kann man dies in dem man ein [http://www.gimp.org/ alternatives Grafikprogramm (Gimp)] verwendet oder das Bild einmal mit dem Bildbetrachter [http://www.irfanview.de/ IrfanView] öffnet und abspeichert.

Es muss nicht bei jedem mit MS Paint abgespeicherten Bild auftreten.

Glbitmap loader

2005-06-22T07:52:23Z

Lossy eX: /* Das leidige Thema Alphakanal */

{{unvollständig}}
= glBitmap - Texturenloader =

== Warum das Ganze und wo kann ich sie finden? ==

Früher benutzte ich die glBMP, da sie so "schön" Objekt orientiert war. Leider hatte mein Grafiktreiber zu der Zeit einen Fehler bei der Auswahl des Texturformates. So führte es dazu, dass sobald ich eine Textur mit Alphakanal und dem Standard Texturformat an OpenGL übergab, er als Farbtiefe 16 Bit verwendete. Wenn ich ein Foto genommen hätte wäre mir das wahrscheinlich gar nicht aufgefallen aber dummerweise (oder glücklicherweise) hatte ich aber eine Textur mit einem weichem Farbverlauf. Wie zu erwarten war sah das natürlich alles ziemlich schrecklich aus. Bis dahin kann der Loader ja nichts dafür wenn in einem Treiber ein Fehler existiert. Nur das kuriose an dem Ganzen war, dass meine Textur in Wirklichkeit gar keinen Alphakanal haben durfte. Also habe ich mich auf die Suche nach der Ursache gemacht und bin auch prompt fündig geworden. Der Loader war der Meinung er müsse alle Texturen mit einem Alphakanal versehen ungeachtet der Tatsache ob sie nun einen hatten oder eben nicht. Das ist natürlich eine Sache mit der ich mich nicht abfinden wollte. Kurz darauf begann ich also eine Ableitung der glBMP Texturenklasse zu erstellen und dort musste ich mit Schrecken feststellen, dass die Rechte in der Klasse so ungünstig vergeben wurden, dass ich keine andere Wahl gehabt hätte als direkt die Unit zu editieren. Da ich ungern externe Quellen editiere habe ich für mich die andere Alternative entschieden. Was dabei rausgekommen ist sieht man ja jetzt.

Gefunden werden kann sie entweder im DGL-SDK oder auf der [http://www.dev-center.de/index.php?cat=header&file=glbitmap Webseite] von [[Benutzer:Lossy eX|Lossy eX]].

== Allgemeines und Features ==

Dieser Artikel geht nicht darauf ein was zu tun ist um in OpenGL eine Textur darstellen zu können. In ihm werde ich lediglich darauf eingehen was man tun kann und muss um mittels der glBitmap eine Textur laden zu können. Außerdem werden die verfügbaren Einstellungen und ihre Wirkungen erklärt. Für alles andere wäre es besser das [[Tutorial_lektion4|Tutorial über Texturen]] durchzulesen.

Der wichtigste Unterschied zu den bestehenden Loadern bringe ich gleich einmal als erstes. Die glBitmap legt die Texturen anders im Speicher ab. Um zwar im speziellen meine ich damit die 2D Texturen. Bei bestehenden Loadern werden diese Texturen mit der untersten Zeile zu erst im Speicher abgelegt. In der glBitmap werden sie aber mit der obersten Zeile zu erst abgelegt. Man könnte auch sagen, dass sie bei den bestehenden Loadern auf dem Kopf stehen. Beide Möglichkeiten funktionieren und sind korrekt. Das Einzige was sich in diesem Zusammenhang ändert ist die [[glTexCoord| Adressierung der Texturen]]. Sie müssen entsprechend geändert werden. Sollte das nicht möglich sein so besteht mit der Methode FlipVert die Möglichkeit die Textur zu spiegeln. Näheres in Abschnitt [[Glbitmap_loader#Texturen_konfigurieren|Texturen konfigurieren]]. Im Normalfall sollte das andere Verhalten nicht zu Problemen führen sondern die Arbeit damit vereinfachen und verständlicher gestalten.

Die glBitmap holt sich ihre Daten ausschließlich aus Streams. Das zugrundeliegende Format wird automatisch anhand des Inhaltes der Daten ausgewählt. Es besteht also kein Notwendigkeit daran, dass der Entwickler wissen muss um welches Format es sich in Wirklichkeit handelt.

=== unterstütze Formate ===

* Windows Bitmaps (*.bmp) Wird Automatisch auf 24 Bit gesetzt sollte es kleiner sein.
* JPEG (*.jpg)
* TARGA (*.tga) unkomprimiert, 24 und 32 Bit. Ursprung unten links oder oben links
* Portable Network Graphics (*.png) 24 Bit mit oder ohne Alphakanal. Es wird eine zusätzliche Bibliothek benötigt.
Es besteht auch die Möglichkeit die Bilddaten dynamisch generieren zu lassen oder sie aus einer Instanz der Klasse TBitmap zu laden. Diese Instanz muss dann aber als Pixelformat 24 oder 32 Bit haben.

Um PNG's laden zu können muss eine externe Bibliothek namens [http://pngdelphi.sourceforge.net/ PNGImage] eingebunden und das Define pngimage hinzugefügt werden. Alternativ dazu kann das Define auch in der glBitmap auskommentiert werden.

== Texturen laden ==

Das Laden von Texturen kann auf 2 Weg geschehen. Bei Beiden ist aber zu beachten, dass OpenGL richtig initialisiert worden sein muss bevor man eine Textur erzeugen kann. Was noch sehr wichtig ist. Es sollte niemals eine Textur bei jedem Rendervorgang angelegt und freigegeben werden! Es ist viel effektiver, wenn man die Textur zu beginn lädt und so lange im Speicher behält bis sie nicht mehr benötigt wird. Wenn man sie erst später benötigt, dann kann man sie auch später noch nachladen aber auch dann sollte sie so lange wie nötig existieren.

=== Procedural ===

Hierbei genügt der Aufruf einer einzelnen Methode um eine Textur zu laden und diese an OpenGL zu übergeben. Allerdings auf Grund der Einfachheit steht nur das Laden aus Dateien oder Ressourcen zur Verfügung. Zusätzliche Funktionalität können dabei nicht benutzt werden. Generell empfehle ich immer die Objekt orientierte Variante.

var
Texture: TGLuint;

LoadTexture('myTex\Wall.bmp', Texture, False); // Datei laden

Damit wird die Datei Wall.bmp geladen und die TextureID wird in die Variable Texture geschrieben. Wenn die Textur dann benötigt wird, dann muss man diese entsprechend mit [[glBindTexture]] binden und das benötigte Texturtarget mit [[glEnable]] aktivieren. Das Target ist üblicherweise GL_TEXTURE_2D. Wenn die Textur nicht mehr benötigt wird sollte sie mit [[glDeleteTextures]] auch wieder frei gegeben werden.

=== Objekt orientiert ===

Dieser Abschnitt beschäftigt sich ausschließlich mit den 2D Texturen. Aber grundsätzlich lässt sich alles hier erwähnte auch auf die 1D Texturen und die Cubemaps übertragen.
Der Objekt orientierte Weg erfordert zwar eine wenig mehr Schreibarbeit aber nur so kann man den vollen Funktionsumfang der glBitmap genießen.

Als Erstes müssen wir eine Instanz der Texturenklasse definieren. Dies tun wir vorzugsweise als Member des Fensters auf dem wir zeichnen.

TForm1 = class(TForm)
// Verschiene Elemente und Events des Fensters
private
fTexture: TglBitmap2D; // Instanz unserer Textur
end;

Nun müssen wir der Textur noch Leben einhauchen.

procedure TForm1.FormShow(Sender: TObject);
begin
// OpenGL Initialisieren

fTexture := TglBitmap2D.Create; // Instanz der Klasse erstellen
fTexture.LoadFromFile('myTex\Wall.bmp'); // Datei laden
fTexture.GenTexture; // geladene Textur an OpenGL übergeben
end;

Für Schreibfaule besteht auch noch die Möglichkeit in einem überladenen Konstruktor einem Dateinamen anzugeben.

fTexture := TglBitmap2D.Create('myTex\Wall.bmp'); // Instanz erstellen und Datei laden
fTexture.GenTexture; // geladene Textur an OpenGL übergeben

In GenTexture wird im Normalfall immer überprüft ob die Textur eine gültige Größe hat. Sollte diese Überprüfung nicht gewünscht sein so kann man diese mit einem optionalen Parameter deaktivieren. Diese Überprüfung testet auch ob die Texturgröße eine Potenz von 2 ist (1, 2, 4, 8, 16 usw.) und wenn nicht ob solche Texturen von dem Rendercontex unterstützt werden.

fTexture.GenTexture(False); // Es wird keine Prüfung der Texturgröße vorgenommen.

Wenn kein Fehler aufgetreten ist und alles so funktioniert hat wie es sein sollte, dann kann die Textur benutzt werden.

fTexture.Bind; // Textur und entsprechendes Target wird aktiviert.

Sollte es nicht gewünscht werden, dass auch gleichzeitig das Target aktiviert wird so muss Bind mit dem Parameter False aufgerufen werden. Damit wird nur noch die Textur gebunden.

Sollte man die Textur einmal nicht mehr benutzen wollen so genügt es entweder eine andere Textur zu binden oder Unbind von der Texturenklasse aufzurufen. Damit wird die Textur mit der TexturID 0 gebunden und das Target deaktiviert. Auch hier existiert wieder der Parameter der es verhindert, dass das Target deaktiviert wird.

Wenn die Anwendung beendet wird müssen wir auch hier unsere Textur wieder frei geben. Dies geschieht so.

fTexture.Free; // Textur wieder frei geben.

Hierbei ist zu beachten, dass dies nach Möglichkeit vor dem Löschen des Rendercontex geschehen sollte, da so die Textur zu einem sinnvollem Zeitpunkt gelöscht werden kann. Wenn der Rendercontex nicht mehr existiert, so sollte die Textur auch nicht mehr existieren und wenn man dann noch einmal versucht sie zu löschen so könnte es zu Problemen führen. Bisher ist mir kein Fall bekannt aber ausschließen kann man es auch nicht. Also zu erst immer die Texturen frei geben und anschließend des Rendercontex löschen.

== Das leidige Thema Alphakanal ==

Es gibt zwei Möglichkeiten einen Alphakanal in eine Textur zu integrieren. Der einfachste und schnellste Weg ist, wenn sich dieser Kanal von Beginn an in die Textur befindet. Dazu wird ein Grafikprogramm benötigt welches so etwas unterstützt und ein Dateiformat welches das Speichern eines Alphakanals ermöglicht. Ein solches Programm ist zum Beispiel [http://www.gimp.org/ Gimp]. Also mögliche Dateiformate kämen TGA's und PNG's in Frage. Alle anderen Formate unterstützen keinen Alphakanal. Sollte man sich für diesen Weg entscheiden so genügt es dann ganz normal die Textur zu laden und zu benutzen und schon besitzen wir einen funktionierenden Alphakanal. Ich persönlich empfehle bis auf wenige Ausnahmen immer diesen Weg.

Nichts desto trotz habe ich ja gesagt, dass es noch eine Möglichkeit gibt. Bei diesem Weg haben wir Alphakanal und RGB Daten in zwei getrennten Bildern vorliegen. Aber wie bekommen wir das jetzt in ein Bild? Dafür bietet die glBitmap die Möglichkeit einen Alphakanal aus einem separaten Bild zu laden. Zu Beginn benötigen wir jedoch wieder eine Instanz der Klasse und es müssen schon normale Bilddaten geladen worden sein. Und ganz Wichtig damit es überhaupt funktioniert. Der Aufruf muss vor GenTexture stattfinden, da sonst die Textur bereits an OpenGL übergeben wurde.

fTexture.AddAlphaFromFile('myTex\Wall_alpha.bmp'); // Alphakanal aus Datei laden

Das war alles nun sind wir im Besitz einer Textur mit einem Alphakanal. Es besteht unter anderem auch die Möglichkeit den Alphakanal aus verschiedenen anderen Quellen zu laden (Resourcen, Streams, TBitmap). Zusätzlich dazu kann man den Kanal aber auch dynamisch erstellen. Dafür existiert die Methode AddAlphaFromFunc. Die Findigen unter euch habe aber bestimmt schon herausgefunden, dass man bei alle Methoden solch eine Function übergeben kann. Näheres dazu findet ihr im Abschnitt e = mc²

Etwas was häufiger gebraucht wird habe ich von Hause aus schon implementiert. Und zwar das Erstellen eines Alphakanals anhand einer Farbe.

fTexture.AddAlphaFromColorKey(Red, Green, Blue, Deviation); // Alphakanal anhand einer Farbe hinzufügen

Dabei wird nur auf vollkommen durchlässig und nicht durchlässig unterschieden. Alle Pixel die die angegebene Farbe besitzen werden dabei als 0 (nicht Sichtbar) in den Alphakanal geschrieben alle anderen erhalten 255 (Sichtbar). Die Deviation bestimmt eine Abweichung um der die Farben abweichen dürfen um trotzdem noch als Transparent erkannt zu werden. Speziell für JPEG's ist das nicht unwichtig, da die Bilder beim Komprimieren leicht abgewandelt werden.

Damit die OpenGL Primitiven jetzt transparent dargestellt werden muss der [[GlAlphaFunc|Alphatest]] oder das [[glBlendFunc|Blending]] aktiviert sein. Sonst nützt einem der Alphakanal nicht sonderlich viel.

Entfernen kann man einen Alphakanal natürlich auch. Dazu genügt der Aufruf von RemoveAlpha. Dieser muss natürlich nicht mit der glBitmap erstellt worden sein. Er kann auch aus einer Datei geladen worden sein.

fTexture.RemoveAlpha; // entfernt den Alphakanal

== Texturen konfigurieren ==

Hier beginnt jetzt der Teil der für die Meisten recht wichtig sein dürfte. Bisher haben wir ja nur Daten geladen und diese an OpenGL übergeben. Nun wollen wir aber ein wenig an den Einstellungen rumschrauben und sehen was wir daraus machen können.

Folgende Einstellungsmöglichkeiten verändern ausschließlich nur das Verhalten der glBitmap. Sie haben keinen Einfluss auf die resultierende Textur.

DeleteTextureOnFree ist vom Typ Boolean und gibt an ob beim Freigeben der Klasse die Texture auch freigegeben wird oder ob weiter existieren darf. Standard wird sie mit freigegeben.

FreeDataAfterGenTexture ist vom Typ Boolean und gibt an ob die Bilddaten nach dem Erzeugen der Textur aus dem Hauptspeicher entfernt werden sollen oder nicht. Im Normalfall werden sie das auch.

Target ist vom Typ Cardinal und bestimmt das OpenGL Target. Wird von den Klassen auf den Standardwert gesetzt und muss nur dann auf einen anderen Wert gesetzt werden, wenn ein anderes Target verwendet werden soll. Zum Beispiel bei der Verwendung von Texture_rectangle. Es sollte aber immer direkt nach dem erstellen gesetzt werden, da die Textur sonst unbrauchbar gemacht werden könnte.

Format ist ein Aufzählungstyp und er erlaubt 4 Werte.
<table border="0" rules="all">
<tr>
<td>tfDefault</td>
<td>Dabei wird das Standardformat des Grafikkartentreibers benutzt. Je nach eingestellter Qualität kann dies 16 oder 32 Bit sein.</td>
</tr>
<tr>
<td>tf16Bit</td>
<td>Hier wird die Textur in 16Bit abgelegt.</td>
</tr>
<tr>
<td>tf32Bit</td>
<td>Hier wird die Textur in 32Bit abgelegt.</td>
</tr>
<tr>
<td>tfCompressed</td>
<td>Bei diesem Format wird zu erst geschaut ob eines der folgenden Kriterien erfüllt ist. Extension GL_ARB_texture_compression, OpenGL Version 1.3 oder die Extension GL_EXT_texture_compression_s3tc. Sollten alle 3 Möglichkeiten nicht funktionieren so wird das Standardformat vom Grafikkartentreiber benutzt.</td>
</tr>
</table>

MipMap ist ebenfalls ein Aufzählungstyp und er erlaubt 3 Werte.
<table border="0" rules="all">
<tr>
<td>mmNone</td>
<td>Wie man vermuten könnte werden hierbei keine Mipmaps erstellt.</td>
</tr>
<tr>
<td>mmMipmap</td>
<td>Ähnlich wie bei komprimierten Texturen werden zu erst verschiedene neue Möglichkeiten überprüft. Ab OpenGL Version 1.4 oder mit der Extension GL_SGIS_generate_mipmap unterstützt die Grafikkarte ein generieren der [[Mipmaps]]. Das ist natürlich wesentlich schneller als der Weg ausschließlich über die Software. Sollte es keinen anderen Weg geben so werden die [[Mipmaps]] mittels der GLU generiert.</td>
</tr>
<tr>
<td>mmMipmapGlu</td>
<td>In diesem Falle werden die [[Mipmaps]] ausschließlich mit der GLU erstellt.</td>
</tr>
</table>

Mithilfe der Methoden SetFilter und SetWrap können das Filterverhalten und das Beschränken der Texturkoordinaten angepasst werden. Eine genaue Auflistung möglicher Werte findet man beim Artikel zu [[glTexParameter]]. Das Aufrufen der Methoden ist überall dort möglich wo auch [[gTexParameter]] gültig ist. Mögliche Fehlerhafte Werte werden automatisch auf die vorhandene Textur angepasst. So wird bei SetFilter niemals ein [[MipMaps|MipMap]] bei die Filterung eingestellt wenn keine [[MipMaps]] erzeugt wurden. Das würde sonst dazu führen, dass die Textur nicht dargestellt werden könnte.

FlipVert und FlipHorz sind Methoden die nichts anderes machen als das Bild entlang der entsprechenden Richtung (Vertikal und Horizontal) zu spiegeln. Dies wäre auch mit der Funktionsschnittstelle möglich aber besonders bei FlipVert wäre es unpraktisch da wir so nicht die komplette Zeile am Stück kopieren könnten, sondern nur Pixel für Pixel.

Zum Invertieren des Bildes genügt es die Methode Invert aufzurufen. Sie bekommt zwei boolsche Parameter mit denen man steuern kann was man invertieren möchte. Einen für RGB und einen für den Alphakanal.

== e = mc² ==

{ Funktionsschnittstelle, Arbeitsweise, Möglichkeiten, Beispiele }

== Cubemaps mit glBitmap ==

Das einzige worin sich CubeMaps von 2D Texturen unterscheidet ist das Laden. Aber das ist auch nicht viel komplizierter als bei 2D Texturen. Die Handhabung mit den Texturen (Binden, Frei geben) ist wie bei 2D Texturen weswegen ich das auch nicht noch einmal extra wiederholen werde.

=== Procedural ===

Wie auch bei den 2D Texturen haben wir die Auswahl zwischen zwei möglichen Wegen. Der procedurale Weg unterscheidet sich lediglich in der Anzahl der angegebenen Texturen. Das sind diesmal natürlich ein paar mehr.

var
Texture: TGLuint;

// Cubemaps laden
LoadCubeMap('xpos.bmp', 'xneg.bmp', 'ypos.bmp', 'yneg.bmp', 'zpos.bmp', 'zneg.bmp', Texture, False);

Die ersten 6 Parameter geben die jeweils 6 Texturen an. Die Namen der Parameter geben auch gleichzeitig deren Ziel an. Also immer schön auf die Reihenfolge achten. In dem Siebten wird die Textur ID geschrieben und der Achte gibt an ob aus Resourcen geladen werden soll oder nicht.

=== Objekt orientiert ===

Der Objekt orientierte Weg gestaltet sich dieses mal ein wenig schreibintensiver. Es müssen ja auch schließlich 6 Texturen geladen werden. Aber das kann man auch praktischerweise in eine Schleife packen. Das praktische daran ist, dass wir alles mit nur einer Klasseninstanz lösen können (und auch müssen).

fCubeMap := TglBitmapCubeMap.Create; // Instanz der Klasse erstellen
fCubeMap.LoadFromFile('xpos.jpg'); // Datei Laden

Die Textur wird normal angelegt und es wird wie gewöhnt ein Bild in den Speicher der Klasse geladen. Dieses Bild verhält sich wie jedes andere Bild. Es kann also wie gewöhnt manipuliert werden. Zum Beispiel durch die Funktionsschnittstelle.

fCubeMap.GenerateCubeMap(GL_TEXTURE_CUBE_MAP_POSITIVE_X); // Einzelnen Teil übergeben

Wenn die Textur also bereit zum Übergeben ist, dann müssen wir GenerateCubeMap mit dem entsprechenden Teil der Cubemap aufrufen. In diesem Falle ist es die positive X Achse. Das müssen wir dann natürlich noch mit allen anderen Maps machen. Also Bild laden, evtl bearbeiten und dann an OpenGL übergeben. Die Reihenfolge der Maps spielt hierbei keine Rolle. Wichtig ist nur, dass sie die selbe Auflösung und das selbe Format haben. Die Methode GenTexture steht bei dieser Klasse nicht zur Verfügung, da beim ersten Aufruf von GenerateCubeMap automatisch die OpenGL Textur erzeugt wird. Die CubeMap ist nur dann einsetzbar, wenn alle Maps erfolgreich mit Daten versorgt wurden.

Beim Binden der CubeMap existiert ein zusätzlicher Parameter mit dem man die Aktivierung der automatische Generation der Texturkoordinaten deaktivieren kann. Standard ist dieses eingeschalten. Ähnlich wie beim Binden einer Textur. Dort kann man verhindern, dass das Target aktiviert wird.

== Bekannte Probleme und Einschränkungen ==

Vor einer Weile wurde im Forum die Frage gestellt warum die glBitmap beim Laden eines BMP's einen "Stream Read Error" produziert. Da das Bitmap nun mal ein sehr einfaches Format ist hat mich das auch sehr stark verwundert. Nach langem hin und her Rätseln kam ich dann dennoch darauf was das Problem war. Es daran, dass das Bitmap mit MS Paint abgespeichert wurde. Dieser war aber der Meinung er müsse im Bitmapheader eine Größe angeben die 2 Bytes größer war als die eigentlichen Daten. Diese 2 Bytes wurden auch aufgefüllt aber leider ist das TBitmap, welches ich zum Laden verwende, nicht so tolerant um über darüber hinweg zu sehen. Und so bekommt man einen Fehler beim Laden. Den selben Fehler würde man auch bekommen wenn man das Bild in einem TImage anzeigen wollte.

Abhelfen kann man dies in dem man ein [http://www.gimp.org/ alternatives Grafikprogramm (Gimp)] verwendet oder das Bild einmal mit dem Bildbetrachter [http://www.irfanview.de/ IrfanView] öffnet und abspeichert.

Es muss nicht bei jedem mit MS Paint abgespeicherten Bild auftreten.

Glbitmap loader

2005-06-22T07:35:41Z

Lossy eX: /* Texturen konfigurieren */

Glbitmap loader

2005-06-22T07:14:59Z

Lossy eX: /* Allgemeines und Features */

Texture Loader

2005-06-22T07:08:57Z

Lossy eX: /* Bestehende Texture Loader */

=Texture Loader=

==Was ist das?==
Der '''Texture Loader''' ist ein Tool, welches das Verwalten von Texturen erleichtern soll. 
Sobald man Texturen in seinen Projekten verwenden will, benötigt man einen '''Texture Loader'''.

==Was macht ein Texture Loader?==
Er lädt Texturen! 
So einfach wie es klingt ist es aber nicht. '''Texture Loader''' sind meist recht vielfältige Tools. Viele von ihnen ermöglichen es dem Nutzer Bilder verschiedener Bildformate (wie z.B. *.jpg, *.tga, *.png etc) zu Laden und als Texture zur Verfügung zu stellen.

Man kann sich leicht vorstellen, dass der '''Texture Loader''' für jedes Bildformat seine Ladeprocedur anpassen muss. (Ein nicht zu unterschätzender Aspect, wenn man selber einmal einen '''Texture Loader''' schreiben will.)

==Wie schreibe ich einen Texture Loader?==
Am besten gar nicht! 
Es gibt schon eine Menge leistungsfähige '''Texture Loader'''. (z.B. "glBitmap.pas" welcher aus der DGL Comunity stammt.) Wenn die Funktionen von keinem Loader deinen Ansprüchen genügen, dann nimm den der diesen am nächsten kommt und erweitere ihn entsprechend.

Wenn es unabdingbar ist, dass der '''Texture Loader''' selber geschrieben sein muss, dann hier ein paar Tips:
* Verwende für die Texturen Klassen
* Ermögliche das Laden aus Streams. Damit wird dein Loader vielseitiger.
* Die wichtigsten Bildformate für Texturen sind *.bmp, *.jpg, *.tga, *.png
* Informationen zu den Bildformaten findest du auf [http://www.wotsit.org wotsit.org]

(Es kann nie schaden sich einmal den Code eines bestehenden '''Texture Loader''' anzusehen.)

Außerdem sind die folgenden Befehle sicherlich wichtig:

==Wichtige OpenGL Befehle==

[[glGenTextures]], [[glDeleteTextures]], [[glBindTexture]], [[glTexParameter]], [[glTexImage1D]], [[glTexImage2D]], [[glTexEnv]], [[glTexGen]]

==Bestehende Texture Loader==
(Loader für Delphi)
{| border="1" rules="all"
! Name (Link) || Features, Beschreibung
|- valign="top"
|[[Glbitmap_loader|glBitmap.pas]]  
|'''Pro'''
*Ist objektorientiert und verfügt über ein leicht erweiterbares Klassenmodel
*Benutzt von Hause aus die [[DGLOpenGL.pas]]
*Lädt seine Daten ausschließlich aus Streams. Er bietet aber für so ziemlich alle Fälle bereits eine Kappselung. So zum Beispiel für Dateien, Resourcen (Name oder ID) oder aber auch für TBitmaps.
*Unterscheidet anhand des Inhaltes welches Format ihm vor liegt.
*Bietet verschiedene Möglichkeiten die Texturen vor dem Generieren zu Manipulieren. Es besteht die Möglichkeit eine Methode zu übergeben die für jedes Pixel aufgerufen wird.
*Alphakanal kann mit hilfe einer übergebbaren Methode erzeugt werden.
*Texturen können dynamisch erzeugt werden (Mit hilfe der selben Methoden wie beim Manipulieren)
*Texturen werden ausschließlich so generiert wie sie dem Loader vorliegen. Es wir kein Alphakanal erstellt wenn keiner in der Textur vorhanden ist.
'''Contra'''
*Projekte werden durch die verwendenten Biblioheken größer als dem ein oder anderen lieb ist
*Klassenschnittstelle kann auf unerfahrene Entwickler, aufgrund ihrer Größe, verwirrend wirken. Wer allerdings grundlegende Kenntnisse in OOP hat wird problemlos eine Textur erstellen/laden und binden können.
|- valign="top"
|[http://www.sulaco.co.za/opengl5.htm##bmp Textures.pas]
|Von der Textures.pas existieren die verschiedensten Modifikationen. Unter anderem auch eine die Texturen aus Streams laden kann. Diese Versionen sind aber alle nicht offiziel und werden auch nicht publiziert.
'''Pro'''
*Sehr einfache Schnittstelle. Besteht aus einer einzigen Methode die einen Datei oder Resourcenamen entgegen nimmt und eine TexturID zurück liefert
*Anwendung wird nicht so groß, da auf einen Großteil der Bibliotheken von Delphi verzichtet wurde
*Importiert die benötigten OpenGL Methoden zum generieren statisch. Somit ist der Loader unabhängig von dem benutzten OpenGL Header.
'''Contra'''
*Ist nicht in der Lage aus Streams zu laden
*Erkennt den Dateitypen ausschließlich anhand des Datei oder Resourcenamen. Bei Resourcen muss eine Endung angegeben werden die von dem Loader wieder abgeschnitten wird.
*Die Texturen werden immer mit einem einheitlichen Format generiert. Je nach Anpassumg im Quelltext wird entweder immer ein Alphakanal erzeugt oder eben nicht.
|- valign="top"
|glBMP.pas
|Die ursprüngliche Seite des Autors ist leider nicht mehr verfügbar, der Loader kann aber aus dem [[DGL-SDK]] bezogen werden.

Bei der glBMP.pas handelt es sich lediglich um die Textures.pas bei der die grundlegenden Funktionalität übernommen und in eine (relativ bescheidene) Klassenstruktur gepackt und erweitert wurde.

'''Pro'''
*Ist objektorientiert
*Bietet verschiedene Möglichkeiten die Texturen vor dem Generieren zu Manipulieren.
*Alphakanal kann mit hilfe einer übergebbaren Methode erzeugt werden.
'''Contra'''
*Klassenmodel lässt sich nicht erweitern ohne in die bestehenden Quellen einzugreifen
*Bitmapdaten der Textur befinden sich auch nach dem Generieren der Textur im Clientspeicher
*Ist nicht in der Lage aus Streams zu laden
*Erkennt den Dateitypen ausschließlich anhand des Dateinamen.
*Kann ausschließlich nur Dateien laden.
*Die Texturen werden immer mit einem einheitlichen Format generiert. Texturen werden immer mit Alphakanal erzeugt.
|}

Glbitmap loader

2005-06-16T14:37:48Z

Lossy eX: /* Warum das Ganze und wo kann ich sie finden? */

Glbitmap loader

2005-06-16T13:35:04Z

Lossy eX:

Glbitmap loader

2005-06-16T13:19:45Z

Lossy eX:

Glbitmap loader

2005-06-16T13:14:15Z

Lossy eX:

Glbitmap loader

2005-06-16T13:04:37Z

Lossy eX: Link angepasst

Glbitmap loader

2005-06-16T11:32:53Z

Lossy eX: /* Das leidige Thema Alphakanal */

Glbitmap loader

2005-06-16T11:27:11Z

Lossy eX:

Glbitmap loader

2005-06-16T11:19:01Z

Lossy eX:

{{unvollständig}}

[http://www.dev-center.de/ |meiner Webseite]