commit 3d366b1a3045d2447408b00c1819da399ba8af4a
parent adcbbf4dbd3b1b909a8056bd265bf19622ac63ce
Author: Matsuda Kenji <ftvda283@gmail.com>
Date: Mon, 13 Sep 2021 09:24:57 +0900
update hello triangle
Diffstat:
2 files changed, 447 insertions(+), 1 deletion(-)
diff --git a/definitions b/definitions
@@ -0,0 +1,431 @@
+(bi)linear filtering
+2D array textures
+3D modeling tools
+AO
+Ambient lighting
+Application Programming Interface
+BRDF
+BRDF integration
+Bitangent
+Blending
+Blinn-Phong
+Bloom
+Breakout
+Cook-Torrance BRDF
+Deferred shading
+Definition
+Diffuse lighting
+Framebuffers
+Fresnel
+Fresnel-Schlick
+G-buffer
+GLSL
+GLSL lang validator
+GameState
+Gaussian blur
+Gimbal lock
+Gouraud shading
+Gram-Schmidt process
+Gramm-Schmidt process
+Hammersley Sequence
+Lambertian diffuse
+LookAt
+Monte Carlo integration
+Multiple Render Targets (MRT)
+N-dimensional
+Normal
+OIT
+OpenGL Shading Language
+Parallax Mapping with Offset Limiting
+Parallax Occlusion Mapping
+Percentage-closer filtering
+Phong lighting model
+Phong shading
+Pythagoras theorem
+Quasi-Monte Carlo integration
+Reinhard tone mapping
+Relief Parallax Mapping
+Renderbuffer objects
+Riemann sum
+Smith's method
+Specular lighting
+SpriteRenderer
+TBN
+Tangent
+Translation
+Uniforms
+VAO
+VBO
+Van Der Corput
+accum
+albedo
+aliasing
+aligned offset
+alpha
+alpha test
+ambient lighting
+ambient occlusion
+angle
+anti-aliasing
+approximate
+attachment
+attenuation
+attribute divisor
+automatic exposure adjustment
+axis-aligned bounding box
+back facing
+back-facing
+banding
+base alignment
+base reflectivity
+baseline
+batched
+biased
+bidirectional reflective distribution function
+binding points
+bitmap font
+blend
+blend equation
+blending
+blends
+blitting
+block name
+bloom
+blur
+brick
+buffer target
+built-in
+built-in variables
+bump mapping
+camera
+camera space
+capture
+clamp
+clamps
+clip coordinates
+clip space
+clipped
+clipping
+clipping volume
+clockwise
+collision detection
+collision resolution
+collision shapes
+color buffer
+column-major ordering
+commutative
+complete
+component-wise
+composite
+conductor
+constant
+context
+converge
+convoluting
+convolution
+core-profile
+counter-clockwise
+cross product
+cube map
+cull
+cutoff
+data oriented design
+debug output
+default framebuffer
+deferred lighting
+deferred rendering
+deltatime
+depth buffer
+depth condition
+depth map
+depth testing
+depth values
+destination factor
+dielectric
+dielectrics
+diffuse map
+dimensions
+direction
+direction vector
+directional light
+directional shadow mapping
+discard
+displacement mapping
+dot product
+dynamic environment mapping
+early depth testing
+edge-detection
+element
+element buffer objects
+emission map
+energy conservation
+environment mapping
+epsilon
+equirectangular map
+exact
+exit condition
+explode
+extension
+eye adaptation
+eye space
+face
+face culling
+far
+faster rate of convergence
+field of view
+fixed function pipeline
+floating point framebuffer
+format
+forward rendering
+forward shading
+fov
+fragment interpolation
+fragment shader
+frame
+framebuffer
+front facing
+front-facing
+frustum
+functions
+fur
+game object
+gamma
+gamma correction
+geometry pass
+geometry shader
+global
+global illumination
+glow effect
+glyphs
+graphics pipeline
+halfway vector
+height map
+hemisphere
+high dynamic range
+homogeneous coordinate
+identity matrix
+image based lighting
+immediate mode
+importance sampling
+incident
+indexed drawing
+inner
+instance count
+instance name
+instanced arrays
+instances
+instancing
+integral
+interface block
+interface blocks
+interleaved
+internalformat
+interpolates
+inverse-square law
+invocation count
+irradiance
+irradiance map
+jagged edges
+kernel
+kill
+law of large numbers
+layered rendering
+light caster
+light volumes
+lighting pass
+linear
+linear depth buffer
+link
+local coordinates
+local memory limited occupancy
+local space
+low dynamic range
+low-discrepancy sequences
+magnifying
+magnitude
+material
+matrix
+mesh
+metallic
+metallic workflow
+metalness
+microfacets
+minifying
+mipmaps
+model
+multiple render targets
+multisample anti-aliasing
+multisample buffer
+near
+nearest neighbor
+noise pattern
+non-uniform
+normal distribution function
+normal incidence
+normal map
+normal mapping
+normal matrix
+normal vector
+normal-oriented hemisphere
+normal/bump maps
+normalized device coordinates
+normalizing
+object
+object outlining
+objects
+occlusion factor
+off-screen rendering
+offset
+omnidirectional shadow maps
+opaque type
+order independent transparency
+order-independent transparency
+ordered transparency
+origin of rotation
+orthogonal
+orthographic
+outer
+parallax mapping
+parallel
+particle
+particle emitter
+particle generator
+pass-through
+percentage-closer filtering
+perspective
+perspective division
+perspective projection
+perspective projection matrix
+peter panning
+physically based rendering
+pitch
+point
+point lights
+position vector
+post-processing
+pre-compute
+pre-filtered environment map
+preprocessor directives
+primitive assembly
+primitives
+probability density function
+projection
+projection matrix
+projects
+quadratic
+quaternions
+radiance
+radiometry
+rasterization stage
+rate of convergence
+ray
+re-orthogonalize
+read-only
+recursively
+reflectance equation
+reflected
+reflection
+reflection maps
+reflection probes
+reflection vector
+reflects
+refraction
+refractive indices
+render loop
+renderbuffer
+resolve
+resource manager
+revealage
+right-angle
+roll
+rotation axis
+roughness
+sRGB
+sample point
+sampler
+sampling
+scalar
+scatter
+scattering
+scene graph
+screen coordinates
+screen-space ambient occlusion
+screen-space coordinates
+separating axis theorem
+shader program
+shaders
+shadow acne
+shadow bias
+shadow map
+shadow mapping
+shadow volumes
+shared
+sharpen
+shininess
+signed distance field fonts
+single responsibility principle
+skybox
+smoothness
+solid angle
+source
+space partitioning algorithms
+spacing
+spawns
+specular lobe
+split sum approximation
+spotlight
+sprite
+state-changing
+state-using
+std140
+stencil buffer
+stencil test
+stencil value
+sticky paddle
+strafe
+stride
+stuck
+subsamples
+subsurface scattering
+super sample anti-aliasing
+swizzling
+tangent space
+target
+texel
+texture
+texture coordinate
+texture filtering
+texture unit
+tightly packed
+tile-based deferred shading
+tone mapping
+transform
+transparency
+triangle_strip
+tuple
+two-pass Gaussian blur
+uber
+unbiased
+uniform block
+uniform block index
+uniform block layout
+uniform buffer objects
+uniform scale
+unit vector
+uv-mapping
+vertex
+vertex array object
+vertex attribute
+vertex attributes
+vertex buffer objects
+vertex shader
+view
+view coordinates
+view matrix
+viewport transform
+winding order
+wireframe mode
+world coordinates
+yaw
+z-buffer
+z-fighting
diff --git a/translation/Getting-started/Hello-Triangle.html b/translation/Getting-started/Hello-Triangle.html
@@ -516,53 +516,68 @@ if(!success) {
<li>次の引数はデータを正規化するかどうか指定します。データ型が整数（intやbyte）であり、かつこの引数を<var>GL_TRUE</var>にした場合、整数のデータは浮動小数点数に変換される際に<code>0</code>（符号付きの場合は<code>-1</code>）と<code>1</code>の間に納まるように正規化されます。今回は関係ありませんので<var>GL_FALSE</var>にしておきます。</li>
<li>The fifth argument is known as the <def>stride</def> and tells us the space between consecutive vertex attributes. Since the next set of position data is located exactly 3 times the size of a <code>float</code> away we specify that value as the stride. Note that since we know that the array is tightly packed (there is no space between the next vertex attribute value) we could've also specified the stride as <code>0</code> to let OpenGL determine the stride (this only works when values are tightly packed). Whenever we have more vertex attributes we have to carefully define the spacing between each vertex attribute but we'll get to see more examples of that later on.</li>
-
+ <li>五番目の引数は<def>ストライド</def>と呼ばれるもので、連続する二つの頂点属性間の距離をあらわします。ある位置データから次の位置データまではちょうど<code>float</code>三つ分あるので、その値を指定します。頂点データの配列は稠密（頂点属性どうしの間に隙間がない）ので、<code>0</code>を指定してOpenGLがストライドを決定するようにすることもできます（データが稠密であるときにのみ有効です）。より多くの頂点属性がある場合は頂点属性間の距離をより慎重に設定しなければなりません。そのような例は後で詳しく紹介します。</li>
<li>The last parameter is of type <code>void*</code> and thus requires that weird cast. This is the <def>offset</def> of where the position data begins in the buffer. Since the position data is at the start of the data array this value is just <code>0</code>. We will explore this parameter in more detail later on</li>
+ <li>最後の引数は<code>void*</code>型なのでこのように奇妙な変換が必要です。これはバッファにおける位置データの開始位置で<def>オフセット</def>と呼ばれます。位置データはデータ配列の頭に位置しますので今回この値は<code>0</code>です。この引数についても後で詳しく解説します。</li>
</ul>
<note>
Each vertex attribute takes its data from memory managed by a VBO and which VBO it takes its data from (you can have multiple VBOs) is determined by the VBO currently bound to <var>GL_ARRAY_BUFFER</var> when calling <fun><function id='30'>glVertexAttribPointer</function></fun>. Since the previously defined <var>VBO</var> is still bound before calling <fun><function id='30'>glVertexAttribPointer</function></fun> vertex attribute <code>0</code> is now associated with its vertex data.
+頂点属性のデータはVBOが管理するメモリから読まれます。VBOは複数定義することができますが、<fun><function id='30'>glVertexAttribPointer</function></fun>を呼び出したときデータを読むのは現在<var>GL_ARRAY_BUFFER</var>に紐付いているVBOからです。以前定義したVBOが<fun><function id='30'>glVertexAttribPointer</function></fun>を呼び出す時点でまだ紐付いているので、頂点属性<code>0</code>はその頂点データに対応します。
</note>
<p>
Now that we specified how OpenGL should interpret the vertex data we should also enable the vertex attribute with <fun><function id='29'><function id='60'>glEnable</function>VertexAttribArray</function></fun> giving the vertex attribute location as its argument; vertex attributes are disabled by default. From that point on we have everything set up: we initialized the vertex data in a buffer using a vertex buffer object, set up a vertex and fragment shader and told OpenGL how to link the vertex data to the vertex shader's vertex attributes. Drawing an object in OpenGL would now look something like this:
+頂点データの解釈方法を設定したので、こんどは<fun><function id='29'><function id='60'>glEnable</function>VertexAttribArray</function></fun>を、その引数に頂点属性の位置を渡して呼び出すことにより頂点属性を有効化します（頂点属性はデフォルトで無効です）。これですべてのセットアップが完了しました: 頂点データを頂点バッファオブジェクトを用いてバッファ上に初期化し、頂点シェーダーとフラグメントシェーダーをセットアップし、頂点データと頂点シェーダー上の頂点属性との対応付けを指定しました。以上をまとめると、OpenGLでの描画は以下のようになります:
</p>
<pre><code>
// 0. copy our vertices array in a buffer for OpenGL to use
+// 0. 頂点の配列をOpenGLが利用できるようにバッファにコピー
<function id='32'>glBindBuffer</function>(GL_ARRAY_BUFFER, VBO);
<function id='31'>glBufferData</function>(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW);
// 1. then set the vertex attributes pointers
+// 1. 頂点属性のポインタをセット
<function id='30'>glVertexAttribPointer</function>(0, 3, GL_FLOAT, GL_FALSE, 3 * sizeof(float), (void*)0);
<function id='29'><function id='60'>glEnable</function>VertexAttribArray</function>(0);
// 2. use our shader program when we want to render an object
+// 2. 作成したシェーダープログラムを描画に利用
<function id='28'>glUseProgram</function>(shaderProgram);
// 3. now draw the object
+// 3. 描画
someOpenGLFunctionThatDrawsOurTriangle();
</code></pre>
<p>
We have to repeat this process every time we want to draw an object. It may not look like that much, but imagine if we have over 5 vertex attributes and perhaps 100s of different objects (which is not uncommon). Binding the appropriate buffer objects and configuring all vertex attributes for each of those objects quickly becomes a cumbersome process. What if there was some way we could store all these state configurations into an object and simply bind this object to restore its state?
+この作業を描画のたびに繰返す必要があります。現状そんなに大変そうに思えませんが、これが例えば5つの頂点属性と100種類のオプジェクトだったらどうでしょう。この状況はそんなに有り得ないものではありません。バッファオブジェクトと適切に紐付け、すべての頂点属性ををれぞれのオブジェクトで設定するのは面倒です。もしこのような設定を保存しておけるオブジェクトがあり、それを紐付けるだけで保存した設定を読み込めたらどんなに楽でしょう。
</p>
<h3>Vertex Array Object</h3>
+<h3>頂点配列オブジェクト</h3>
<p>
A <def>vertex array object</def> (also known as <def>VAO</def>) can be bound just like a vertex buffer object and any subsequent vertex attribute calls from that point on will be stored inside the VAO. This has the advantage that when configuring vertex attribute pointers you only have to make those calls once and whenever we want to draw the object, we can just bind the corresponding VAO. This makes switching between different vertex data and attribute configurations as easy as binding a different VAO. All the state we just set is stored inside the VAO.
+<def>頂点配列オブジェクト</def>（あるいは<def>VAO</def>）は頂点バッファオブジェクトと同様に紐付けることができ、それ以降の操作はそのVAOの内部に保存されます。これには大きな利点があります。頂点属性のポインターの設定を一度だけしておけば描画時には対応するVAOを紐付けるだけですむのです。別の頂点データと属性の設定を行き来する場合も、VAOの紐付けだけで完結するので簡単です。設定したすべての状態がVAO内に保存されます。
</p>
<warning>
Core OpenGL <strong>requires</strong> that we use a VAO so it knows what to do with our vertex inputs. If we fail to bind a VAO, OpenGL will most likely refuse to draw anything.
+core OpenGLを利用する場合、OpenGLに頂点データの扱い方を指示するためにVAOが<strong>必要</strong>です。VAOの紐付けに失敗した場合、OpenGLはおそらく一切の描画を拒否します。
</warning>
<p>
A vertex array object stores the following:
+VAOは以下のものを保持します:
</p>
<ul>
<li>Calls to <fun><function id='29'><function id='60'>glEnable</function>VertexAttribArray</function></fun> or <fun>glDisableVertexAttribArray</fun>.</li>
+ <li><fun><function id='29'><function id='60'>glEnable</function>VertexAttribArray</function></fun>や<fun>glDisableVertexAttribArray</fun>の呼び出し。</li>
<li>Vertex attribute configurations via <fun><function id='30'>glVertexAttribPointer</function></fun>.</li>
+ <li><fun><function id='30'>glVertexAttribPointer</function></fun>による頂点属性の設定。</li>
<li>Vertex buffer objects associated with vertex attributes by calls to <fun><function id='30'>glVertexAttribPointer</function></fun>.</li>
+ <li><fun><function id='30'>glVertexAttribPointer</function></fun>により頂点属性に紐付いた頂点バッファオブジェクト。</li>
</ul>
<img src="/img/getting-started/vertex_array_objects.png" class="clean" alt="Image of how a VAO (Vertex Array Object) operates and what it stores in OpenGL"/>
