CS580
CS580
Computer Graphics Rendering
Overview
Ulrich Neumann
What Will be Covered?
Image package
Photoshop
CAD package
Graphics Design
Applications
Computer Graphics
Auto CAD
Modeling package
3D Studio Max
Animation package
Flash, Digimation
3D Graphics
Video
Virtual
Reality
Animation
Visualization
Movie
Effects
Games
Algorithms
Research
Web Design
*
Talk about different requirements for real-time vs. Non-real-time
Time, quality
Target Course Audience
Application programmer
Use a library (OpenGL, Java)
What does the call do?
Build graphics apps
Graphics developer
Create or extend a library for others to use
How does the function work?
Design and create a function to do …X…
*
Introduction to CG
Computer Graphics…
The technology to convert created or collected data into visual representations
Model
Render focus of this course
Display
*
CS580 Course Structure
Core rendering algorithms
Advanced topics
Term Project
per team
HW 1
HW 2
HW 3
HW 4
HW 5
HW 6
Exam 1 ——
Exam 2 ——
Graphics Process
Rendering
Transform, Light, Shade, & Rasterize
Surface Model
Image Display
Geometric Model
Scene Model
64.bin
Geometry Modeling
There are many ways to describe or represent geometry
Explicit geometry:
Triangle meshes, Patches, Subdivision surfaces,…
Implicit geometry:
Sphere surface defined by x2 + y2 + z2 = 10
Fractal sets, procedural definition, …
Volume data:
Samples from MRI, ultra-sound, simulation…
Example of Triangle Meshes
65.psd
66.unknown
Making Geometric Models
Rendering
3D scanner
Computer vision
Model libraries
Interaction
Geometric Modeling
Points, Lines, Surfaces, …
Making Surface (Appearance) Models
Rendering
Scanner
Paint
Image libraries
Camera
Surface Parameters
Color, BRDF, Opacity, …
Rendering
Rendering
Transformation
Lighting and Shading
Scan Conversion or Rasterization
Surface Model
Geometric Model
+
=
Image Display
70.bin
71.bin
72.bin
Image Display
scene models and rendering algorithms
Image representation in memory devices
display device
Rendering
Image Representation
Pixel array,
Stroke list, NC cut list, …
Optical Modulation
CRT, LCD, Plasma, Ink, 3D fab
Digital Images: pixels
*
76.bin
77.bin
78.bin
Frame Buffer
Frame Buffer
A block of dedicated memory, that contains the pixel data that is passed to the display system
Data for each pixel encodes color and/or other properties (e.g., opacity)
Frame Buffer Concepts
Pixel: One element of a frame buffer
• a uniquely addressable point in an image
Pixel depth: Number of bytes per-pixel in the buffer
• e.g., 8-bits (1 byte) for each of
RGBA (Red, Green, Blue, Alpha) = 4 bytes/pixel
Resolution: Width × Height (in pixels)
• e.g., 640×480, 1280×1024, 1920×1080, 3840×2160
Buffer size: Total memory allocated for frame buffer
• width × height × pixel depth
Frame Buffer Z Value
A Z-buffer is required by a popular algorithm for solving the hidden-surface removal (HSR) problem
Think of the pixel Z value as the distance from the camera to the surface “seen” in that pixel
Each pixel holds a Z value in addition to color and alpha
Often, Z-values at pixels are a 32-bit signed integer (4 bytes)
More details when we get to hidden surface removal lectures and HW2
Note that pixels in the FB can also hold other intermediate calculation values in addition to color and Z values
Leads to “deep” pixels – whole data structures per pixel
How Much Frame Buffer Memory?
Frame Buffer Size = Width × Height × Depth
Width × Height = the image resolution (# of pixels)
Depth is the amount of data stored at each pixel (# of bytes)
For example:
Let width=640 and height=480 (a common small image size for webcams)
Let each pixel hold 24-bits of color (8-bits for each of R, G, B)
Let alpha be an 8-bit value and let Z be 32-bits
Then: Frame Buffer Size = 640 × 480 × (24 + 8 + 32 bits)
= 640 × 480 × 64 bits = 640 × 480 × 8 bytes
= 2,457,600 bytes
Display Devices
CRT (Cathode Ray Tube),
LCD (Liquid Crystal Displays), Plasma, Projection, HMD, Volumetric 3D, Stereo, …
Important Parameters:
size, resolution, field of view, pixel-pitch, color range, brightness, refresh-rate, black level, update mode (e.g., interlaced), distortion, …
*
Applications: Movie Effects
“Jurassic Park”
Three Academy Awards® for its ground-breaking visual and sound effects
“Geri’s Game”
Academy Award-winning of the best animated short film, 1997.
Games
Visualization
Simulation
83.bin
Medical Visualization
84.bin
Engineering
Immersion
Virtual Reality
Augmented Reality
Natural Interaction
HW 1
Display functions (due 1 week) (~1 hr)
Browse .h, .c, and .cpp files of HW1.zip
You only need to fill in functions of rend.cpp
Data Application Renderer Display
Start by building display functions
Work backwards so you always see an output
hw1.txt (1)
During the course of the assignments, you will build a small but useful graphics library. We’ll call it the Gz library, and all functions, vars, etc, will be named accordingly.
Certain standards will apply to make the code interfaces consistent. Consistency will be established by prepared include files and an Application Program Interface (API).
The include files you need for this assignment are Gz.h and rend.h.
Both of these are found in the zip file HW1.zip.
There are several other files there that may be useful.
rend.cpp Your task for this assignment is to flesh out the functions in rend.cpp and compile and execute the complete app.
Application.cpp Defines pointers for renderer and frame buffer. Just use this module – do not change it.
Application1.cpp This application is complete and calls the display functions you will write. Browse it and understand it. Don’t modify it, just use it.
rects A data file used by Application1. You should be able to figure it out.
output_sample.ppm A ppm-format result image which can be viewed with Irfanview. A similar file should be created by running your HW1 code. Your background color may vary from the sample.
hw1.txt (2)
All displays are addressed by pixel coordinates, and accept or return pixel values. Upper left pixel is (x=0, y=0). x increases to the right, and y increases downward (raster order).
A flush operation writes the accumulated pixels to a disk file. Disk files will be in the “ppm” file format. A ppm file has an ascii header with xs and ys image-dimensions and a binary 3-byte pixel format:
P6 xs ys 255\r
rgbrgbrgbrgb…
A sample ppm header is: P6 512 480 255\r. This would be correct for an image with 512 pixels horizontally and 480 pixels vertically.
Download IrfanView for viewing PPM files (many others work too)
The flush operation also copies the display pixels to the screen framebuffer – note these pixels are written in bgr-order. See the code comments for details.
Renderer objects hide the organization of pixel memory and its allocation from the application and renderer. In HW1, only the application creates, frees, and flushes the Renderer. The renderer buffer size is determined by the application.
The number of pixels in the GzRender frame buffer should be same as the number of pixels in the GzRender pixel buffer.
Pixels are written by using the Put call. Defining the API interfaces makes the Application and Renderer library display-device independent.
See the rend.cpp file for a complete description of the API
Application1 Pixel Drawing
… some initialization
… then read input file and draw pixels into display buffer
int ulx, uly, lrx, lry, r, g, b;
while( fscanf(infile, “%d %d %d %d %d %d %d”,
&ulx, &uly, &lrx, &lry, &r, &g, &b) == 7) {
for (j = uly; j <= lry; j++) {
for (i = ulx; i <= lrx; i++) {
m_pRender->GzPut(i, j, r, g, b, 1, 0);
}
}
}
m_pRender->GzFlushDisplay2File(outfile); /* write out display pixels to ppm file*/
m_pRender->GzFlushDisplay2FrameBuffer(); // write out or update display pixels to MS Windows frame buffer
Gz.h
/* universal constants */
#define GZ_SUCCESS 0
#define GZ_FAILURE 1
#define RED 0 /* array indices for color vector */
#define GREEN 1
#define BLUE 2
#define X 0 /* array indices for 3D vectors */
#define Y 1
#define Z 2
#define U 0 /* array indices for texture coords */
#define V 1
/**********************/
/* Boundary constants */
#define MAXXRES 1024 /* put bound on size in case of error */
#define MAXYRES 1024
Gz.h
/* Types and Structures used by the renderer */
typedef void *GzPointer;
typedef float GzColor[3];
typedef short GzIntensity;
/* 0-4095 in lower 12-bits of 16-bit short allocated for each RGBA component */
typedef int GzDepth; /* signed int z for clipping */
#ifndef GZ_PIXEL
typedef struct {
GzIntensity red;
GzIntensity green;
GzIntensity blue;
GzIntensity alpha;
GzDepth z;
} GzPixel;
#define GZ_PIXEL
#endif;
Note:
Pixel structure holds everything we need in the frame buffer
Do bounds checking and logical correction or error management of
xres, yres (image size)
GzIntensity (RGB values)
rend.cpp (1)
GzRender::GzRender(int xRes, int yRes)
{
/* HW1.1 create a MS Windows frame buffer
— allocate memory for 3 bytes(B,G,R) per-pixel at indicated resolution
— Use as startup initialization for all HW */
}
GzRender::~GzRender()
{
/* HW1.2 clean up, free buffer memory */
}
int GzRender::GzDefault()
{
/* HW1.3 set pixel buffer to some default values */
— Start of frame initialization for all HW
return GZ_SUCCESS;
}
int GzRender::GzPut(int i, int j, GzIntensity r, GzIntensity g, GzIntensity b, GzIntensity a, GzDepth z)
{
/* HW1.4 write pixel values into the buffer */
return GZ_SUCCESS;
}
int GzRender::GzGet(int i, int j, GzIntensity *r, GzIntensity *g, GzIntensity *b, GzIntensity *a, GzDepth *z)
{
/* HW1.5 retrieve a pixel information from the pixel buffer */
return GZ_SUCCESS;
}
rend.cpp (2)
int GzRender::GzFlushDisplay2File(FILE* outfile)
{
/* HW1.6 write image to ppm file — “P6 %d %d 255\r” */
return GZ_SUCCESS;
}
int GzRender::GzFlushDisplay2FrameBuffer()
{
/* HW1.7 write pixels to framebuffer:
– put the pixels into the MS Win frame buffer
– CAUTION: when storing the pixels into the frame buffer, the order is blue, green, and red
– NOT red, green, and blue !!!
*/
return GZ_SUCCESS;
}
rects
10 50 200 320 3200 4320 3254
300 55 511 444 900 4200 2189
-100 222 600 270 3333 2212 2121
222 -50 270 588 4321 834 1898
250 250 400 500 2180 1209 5333
100 200 300 300 4000 5000 444
470 180 999 999 4100 2030 620
-100 -100 40 150 200 1000 3000
Output image
PPM file format has an ascii header
followed by 8-bit binary pixel color values
in raster order (UL to LR)
For example:
P6 256 256 255\nRGBRGBRGB….
Produces a 256×256 image
Note that background color is your choice – it doesn’t have to match this image
HW1 pitfalls
Bounds check the parameters passed to the display functions
pixel coords – ignore off-screen coordinate commands
pixel GzIntensity values – clamp to 0-4095 within 16-bit short
Both Flush commands requires conversion of GzIntensity to 8-bit rgb component bytes
Drop LS 4-bits by right-shifting and then use low byte of GzIntensity value
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
0
0
0
0
a
b
c
d
e
f
g
h
i
j
k
l
0
0
0
0
0
0
0
0
a
b
c
d
e
f
g
h
GzIntensity is a 16 bit signed short
We allow a range of 12-bits (0-4095) for valid values. Upper 4-bits are always zeros.
We convert to 8-bits (0-255) for required PPM (or screen) format. Right shift 4-times with zero-fill
Final 8-bit unsigned color (rgb) is created by casting (copy) to an unsigned char
a
b
c
d
e
f
g
h