Computer Graphics
COMP3421/9415 2021 Term 3 Lecture 7
What did we learn last week?
3D Graphics!
¡ñ 2D to 3D (what we can reuse)
¡ñ 3D Objects ¡ñ Cameras
¡ñ Model/View/Projection Transform(s)
What are we covering today?
Expanding our knowledge of 3D Techniques
¡ñ Scene Graph – organising objects
¡ñ Depth Testing – What’s in front of what?
¡ñ Blending – Rendering Transparency
The Scene Graph
Relativity
Deep Science (not really that deep)
¡ñ There is no absolute position of anything
¡ñ The best we can do is relate things to other things
¡ð CSE is at grid reference K17 in UNSW
¡ð UNSW is on Anzac Pde in Kensington, NSW
¡ð NSW is an Eastern State in Australia
¡ð Australia is at 25.2744¡ã S, 133.7751¡ã E on the Earth
¡ð The Earth is the 3rd planet orbiting the Sun
¡ð The Sun is in the of the Milky Way
¡ð etc etc etc
A hierarchy of relative positions
The previous example is actually very useful to us!
¡ñ A transform is just a relationship between two coordinate spaces
¡ñ Very much like an address of a building in a city
¡ñ We can use this to organise our 3D Scene!
A Scene Graph
Imagine a 3D scene with a simple rendering of a house
¡ñ The World might have the identity matrix transform
¡ñ Each node has a transform relative to its parent node
¡ñ If we change the House’s location, all its children move with it!
¡ñ Generally only leaf nodes will have actual geometry
World
House
Tree
Road
Walls
Window
Glass
Curtains
Why use Scene Graphs?
Simplifies locations of individual vertices
¡ñ Compose multiple hierarchical matrices for positions into a single transform
¡ñ Keep compound objects together
¡ñ Allow objects to be created as separate reusable pieces
¡ñ Allow objects to be attached or detached from other objects
¡ñ Simplify any movement or animations
Another Example
More Complex Scene Graphs can do interesting things . . .
Character
Image credit: Square Enix
Right Arm
Sword
Left Arm
Torso
Right Leg
Left Leg
Head
Camera Hair (no verts)
This isn’t a character with a camera attached, but it’s good to know you can attach objects that aren’t geometry
Different Transforms in a Graph
A Character in a Graph
¡ñ We can specify certain sets of transforms that are poses
¡ñ These can be a specific local transform at each node
¡ñ We could then swap between different poses by choosing different
transforms
¡ð Even moving the sword from the hand to the torso when it’s sheathed
¡ñ If you moved between poses fast enough, you might even be able to do believable animation!
¡ñ We could also constrain transforms to limit certain joint movement etc
Code for Scene Graphs
These are handled before we get to OpenGL
¡ñ We will usually implement these ourselves
¡ñ You’re all familiar with trees, right?
¡ñ Basic idea of node structures with pointers or references to children and
parent nodes
¡ñ Each node will also contain a local transform
Depth Testing
Seeing things that are in front of other things
In the real world . . .
¡ñ This is something we already know
¡ñ Light does not pass through most objects
¡ñ So we only see objects that are closer to us than others
In Polygon Rendering
Vision passing through objects?
¡ñ There is no notion of light moving
¡ñ There is no idea of view being obscured by something else
¡ñ All we did was mathematically project objects into a view space
¡ñ We never checked if something was obscuring something else
¡ñ So in OpenGL, we need something more!
Options for Rendering Depth
Ordering our Triangles Back to Front
¡ñ Simple and potentially clean
¡ñ Render things at the back first
¡ñ Render things at the front afterwards
¡ñ Whatever’s rendered later replaces the earlier objects
¡ñ Are we going to waste a lot of time sorting our triangles?
Time to sort?
Let’s do some simple analysis
¡ñ How much effort would it be to sort the triangles in a scene
¡ð Probably O(nlogn) and associated memory accesses
¡ð Modern AAA games might have 100,000 visible triangles in a single frame
¡ñ Then reorder the index buffer
¡ñ Then pass the new order of triangles to the vertex shader
¡ñ This feels time consuming . . .
¡ñ And we haven’t even started rendering!
Complications
What if ordering triangles is logically impossible?
¡ñ Something is in front of something else if its Z coordinate is higher
¡ñ But a triangle has 3 Z coordinates!
¡ñ Two triangles can overlap so that they’re both in front and behind each
other
¡ñ Which of these two is in front?
z =3
z = 4
z =2
z =1
z =2
z =6
We can’t actually depth sort triangles
Using Depth at the Fragment level
¡ñ If we have triangles (or part of) in front of each other
¡ñ The rasterizer will create a fragment for each triangle
¡ñ This means more than one fragment per pixel!
¡ñ We just need to decide which fragment should be visible
Break Time
Art Styles in Games and Film
¡ñ Realism vs Stylised
¡ñ In films
¡ð The Lego Movie: modelled entirely from bricks, scratches and fingerprints, depth of field
¡ð vs Pixar films: Fantastical world with exaggerated proportions and physics
¡ñ In games
¡ð Red Dead Redemption 2: Realistic lighting and surfacing, replicates real world effects
¡ð vs Genshin Impact: Anime style, consistent to its own world and fantastical
Image credit: Warner Bros
Image credit: Disney Pixar
Image credit: Rockstar Games Image credit: Mihoyo
The Depth Buffer (also known as the Z-Buffer)
A screen sized buffer
¡ñ Like the frame buffer stores colours
¡ñ The Z-buffer stores depths
¡ñ Every fragment that has been processed will
have its colour data and Z depth stored in these buffers
Image credit: Wikipedia User -Zeus-
Checking the Z-buffer
If multiple fragments are trying to apply colour to a pixel
¡ñ The first fragment stores its colour and depth information in the buffers
¡ñ The next fragment tests its depth information against the Z-buffer
¡ñ If it’s closer to the camera, its information replaces what’s in the buffers
¡ñ If it’s not closer, it is discarded
Z Fighting
This is not a Dragonball reference
¡ñ The Z buffer doesn’t have perfect precision
¡ñ Fragments close to each other can “fight” for
whichever is closest
¡ñ This ugly effect is called Z Fighting
¡ñ How do we fix this?
¡ð At an art level: Be careful how close we place objects
¡ð At a Z buffer level: Increase precision the closer (and more
noticeable) objects are to us
Image credit: learnopengl.com
In OpenGL
OpenGL handles this for us!
¡ñ We won’t be implementing a depth buffer
¡ñ OpenGL will do this by default
¡ñ It is possible to enable GL_DEPTH_TEST to play around or write custom
depth code
Blending
Transparency in OpenGL
Blending colours from different fragments
¡ñ If we have the visible fragment
¡ñ And the fragment behind it
¡ñ We can combine their colours to show
transparency
Image credit: learnopengl.com
Alpha
The fourth component of our colour coordinates
¡ñ Red, Green, Blue, Alpha
¡ñ A measure of transparency
¡ñ 1.0 is opaque
¡ñ 0.0 is invisible
Discarding Fragments
Fragments below a visibility threshold won’t appear
¡ñ We can discard a fragment in the frag shader
¡ñ This stops the fragment from rendering
¡ñ We use this in cases where we have a polygon like a
rectangle . . .
¡ñ and it’s only partially filled with visible material
¡ñ Eg: Grass and other foliage or sprites in 2D (also
used in particle systems)
¡ñ Alpha is 1.0 for the grass, but 0.0 in the gaps
Image credit: learnopengl.com
Blending
If we can’t discard a fragment, we’ll need to blend
¡ñ Two fragments in one pixel
¡ñ If the one at the front has alpha < 1.0
¡ñ That means it's transparent and should show some of what's behind
¡ñ We can do this in a pretty simple way:
¡ð front_colour * front_alpha + back_colour * (1.0 - front_alpha)
¡ð There are also other options in OpenGL
¡ñ This mixes the two colours based on how transparent the front one is
Ordering issues?
We can blend, but do we know this works?
¡ñ What happens when the transparent object in front is rendered first?
¡ñ It won't have any information on what's behind it!
¡ñ Order is important
¡ñ All non-transparent objects need to be rendered first
¡ñ After this transparent objects can be rendered
Ordering Issues Fixed? (maybe not!)
Everything ok in this picture?
Image credit: learnopengl.com
Ordering issues
We need to sort the transparent objects from back to front
¡ñ Each transparent object will see the ones behind it before rendering
¡ñ Did we talk earlier about the cost of depth sorting?
¡ñ Yes, transparency is very costly!
¡ñ There are some tricks, but there's nothing easy
Image credit: learnopengl.com
Transparency in OpenGL
Blending in code
¡ñ OpenGL helps us out with blending
¡ñ We can enable GL_BLEND and give a reasonable blend function
¡ñ OpenGL does not help us with rendering order!
¡ñ If we have transparent objects, we must render them AFTER the rest of
the scene
¡ñ We also have to render them in sorted order
What did we learn today?
3D gives us more, but also makes things more complicated
¡ñ Scene Graph
¡ð Organising many objects
¡ð Or organising a complex multi-part object
¡ð Hierarchy of transforms
¡ñ Depth Testing
¡ñ Blending and Transparency