(Draft) Managing 3D Graphics Data : Highlights & Codes

* 이 게시물은 추후 archive될 예정입니다.

• a buffer to a vertex attribute
• directly to a uniform variable

4.1 Buffers and Vertex Attributes

• init()
• display()
• Vertex Buffer Object
• Vertex Array Object
• one will be sufficient
• GLuint vbo[2];
• glGenBuffers(2, vbo);
• We store those IDs in the integer arrays vao and vbo.
• Vertex attributes are generally the first variables declared in a shader.
• this vertex attribute will be receiving values from a buffer
• "layout qualifier"
• identifier 0
• display()
• Now when we execute glDrawArrays(), data in the 0th VBO will be transmitted to the vertex attribute that has a layout qualifier with location 0. This sends the cube vertices to the shader.

4.2 Uniform Variables

• in a uniform variable
• model-view
• projection matrices
• glUniformMatrix4fv()

4.3 Interpolation of Vertex Attributes

• immediately before the fragment shader is rasterization
• primitives defined by vertices are converted to fragments
• remain unchanged
• all values sent through a buffer to a vertex attribute will be interpolated further down the pipeline
• they receive values from a buffer
• they send their values forward toward the next stage in the pipeline
• the following declaration in a vertex shader specifies a vertex attribute named "color" that outputs a vec4
• The transformed vertices will then be automatically output to the rasterizer, with corresponding pixel locations ultimately sent to the fragment shader.
• The pixels in the interior space of the triangle are then filled by interpolating along the horizontal lines connecting the edge pixels.

4.4 Model-View and Perspctive Matrices

• create appropriate transformation matrices and send them to uniform variables
• a Model matrix
• a View matrix
• a Perspective matrix
• in the world coordinate space
• simulate the effect of a camera at a desired location
• we will need to move the objects themselves in the opposite direction
• a transform that provides the 3D effect according to the desired frustum
• A model matrix needs to be created for each model and at each frame.
• The view matrix needs to be created once per frame (because the camera can be moved), but it is the same for all objects rendered during that frame.
• The perspective matrix is created once (in init()), using the screen window's width and height (and desired frustum parameters), and it usually remains unchanged unless the window is resized.
• Build a model matrix based on the model's location and orientation.
• Concatenate the model and view matrices into a single "MV" matrix.
• Send the MV and projection matrices to the corresponding shader uniforms.
• performance can be improved by pre-multiplying the model and view matrices once before sending them to the vertex shader

4.5 Our First 3D Program - A 3D Cube
[Program 4.1 Plain Red Cube]

GitHub - shinerd/ComputerGraphicsProgramming_inOpenGL: Computer Graphics Programming in OpenGL with C++

• loads the cube vertices into the 0th VBO buffer
• once : reading in shader code and building the rendering program, and loading cube vertices into the VBO (by calling setupVertices())
• positions the cube and the camera in the world
• Recall that display() may be called repeatedly and the rate at which it is called is referred to as the frame rate.
• clear the depth buffer before rendering
• this doesn't run the shader program, but it does enable subsequent OpenGL calls to determine the shader's vertex attribute and uniform locations
• include the same block of uniform variable declarations
• the layout qualifier on the incoming vertex attribute position
• by using 0 in the first parameter of the glVertexAttribPointer() function call and in the glEnableVertexAttribArray() function call
• note the right-to-left concatenation order
• include the word "varying" to programmer-defined interpolated vertex attributes

[Program 4.1 + Cube with Interpolated Colors]

GitHub - shinerd/ComputerGraphicsProgramming_inOpenGL: Computer Graphics Programming in OpenGL with C++

• they too are interpolated by the rasterizer
• smoothly
• because they have the same name "varyingColor" in both shaders
• Note that adding this animation illustrates the importance of clearing the depth buffer each time through display() to ensure correct hidden surface removal
• clearing the color buffer as shown; otherwise, the cube will leave a trail as it moves
• the order in which tMat and rMat are listed in the operation is significant

[Program 4.1 ++ Tumbling]

GitHub - shinerd/ComputerGraphicsProgramming_inOpenGL: Computer Graphics Programming in OpenGL with C++

4.6 Rendering Multiple Copies of an Object
[Program 4.1 +++ Multiple Tumbling Cubes]

GitHub - shinerd/ComputerGraphicsProgramming_inOpenGL: Computer Graphics Programming in OpenGL with C++

• 24
• the computations that build the different model matrices (previously inside a loop in display()) into the vertex shader
• we cannot make calls to GLM from inside a shader
• "time factor" from the C++/OpenGL application

[Program 4.2 Instancing - Twenty-Four Animated Cubes]

GitHub - shinerd/ComputerGraphicsProgramming_inOpenGL: Computer Graphics Programming in OpenGL with C++

[Program 4.2 + Instancing - 100,000 Animated Cubes]

GitHub - shinerd/ComputerGraphicsProgramming_inOpenGL: Computer Graphics Programming in OpenGL with C++

4.7 Rendering Multiple Different Models in a Scene

• to use a separate buffer for each model
• new model-view matrix will be generated for each model that we render
• separate calsl to glDrawArrays() for each model
• in many cases we can use the same shaders

[Program 4.3 Cube and Pyramid]

GitHub - shinerd/ComputerGraphicsProgramming_inOpenGL: Computer Graphics Programming in OpenGL with C++

• pryLocX, pyrLocY, and pyrLocZ
• vMat

4.8 Matrix Stacks

• the C++ Standard Template Library (STL) has a class called "stack"
• makes availabe a new entry on the top of the stack
• removes (and returns) the top matrix
• without removing it
• we instead use the push() command to create new matrices at the top of the stack
• VIEW matrix
• model-view matrices
• the sun's MV matrix
• the earth's MV matrix
• which constists of a copy of the sun's MV matrix with the Earth's model matrix transforms applied to it
• the Earth's MV matrix is built by incorporating the planet's transforms into the sun's transforms
• the moon's MV matrix sits on top of the planet's MV matrix and is constructed by applying the moon's model matrix transforms to the planet's MV matrix immediately below it
• should not be allwed to affect the "children"
• sun's rotation
• pushed
• popped
• (planet) revolution
• affect the moon's movement
• remains
• planet's rotation
• local
• does not affect the moon
• it is popped off the stack before drawing the moon
• moon's rotations
• including its axis rotation

[Program 4.4 Simple Solar System Using Matrix Stack]

GitHub - shinerd/ComputerGraphicsProgramming_inOpenGL: Computer Graphics Programming in OpenGL with C++

• The two buffers #0 and #1 contain cube and pyramid vertices respectively.

4.9 Combating "Z-Fighting" Artifacts

• by choosing a pixel's color to be that of the corresponding fragment closest to the camera
• Z-fighting or depth-fighting
• creating terrain or shadows
• limited precision of the values in the depth buffer
• The greater the range between near and far clipping planes used to build the perspective matrix, the more likely two objects' points with similar (but not equal) actual depths will be represented by the same numeric value in the depth buffer.
• due to the effect of the perspective transform, changing the near clipping plane value can have a greater impact on the likelihood of Z-fighting artifacts than making an equivalent change in the far clipping plane

4.11.2 Pre-Computing the Perspective Matrix

• move the computation of the perspective matrix into the init() function
• resizes the window
• the following to the main(), just before the call to init()

[Program 4.4 with Optimization (glfwWindowSizeCallback)]

GitHub - shinerd/ComputerGraphicsProgramming_inOpenGL: Computer Graphics Programming in OpenGL with C++

4.11.3 Back-Face Culling

• they would be overwritten by hidden surface removal anyway), and thus there is no reason to rasterize or render them.
• "cull" (not render)
• By default, face culling is disabled, so if you want OpenGL to cull back-facing triangles, you must enable it.
• Triangles whose vertices progress in a clockwise direction (as viewed from the OpenGL camera) are back-facing, and are not rendered.
• winding order
• Since by default OpenGL assumes the winding order is counter-clockwise, if a model is designed to be displayed with a clockwise winding order, it is up to the programmer to call gl_FrontFace(GL_CW) to account for this if back-face culling is enabled.
• Note that in the case of GL_TRIANGLE_STRIP, the winding order of each triangle alternates. OpenGL compensates for this by "flipping" the vertex sequence when building each successive triangle, as follows: 0-1-2, then 2-1-3, 2-3-4, 4-3-5, 4-5-6, and so on.
• when we want to see the inside of a 3D model, or when using transparency

Supplemental Notes

• uniform block
• Uniform blocks can even be set up to receive data from buffers.
• shader storage block
• a buffer into wich a shader can write