slides.

CS580
(CG Rendering)
Saty Raghavachary
Course Overview
Basics of rendering
HW 1
HW 2
HW 3
HW 4
HW 5
HW 6
Advanced topics
Applications
Term Project
5 students/team
What Will be Covered?
Computer Graphics
Graphics Design
Image package
Photoshop
Modeling
3D Studio Max
package
CAD package
Auto CAD
Animation package
Flash, Digimation
Applications
Video
Games
Virtual
Reality
Animation
Web Design
Visualization
Movie
Effects
3D Graphics
Algorithms
Research
Introduction to Computer Graphics (CG)
– Graphics process
– Applications
Introduction to CG
• Define Computer Graphics…
The technology associated with the use of
computer technology to convert created or
collected data into visual representations
Model
Rendering  focus of course
Display
Graphics Process
Geometric
Model
Scene
Model
Surface
Model
Rendering
Xform,
Light,
Shade, &
Rasterize
Image
Display
Geometry Modeling
• There are many ways to describe
geometry
– Explicit geometry:
Triangle meshes, Patches, Subdivision surfaces,…
– Implicit geometry:
Surface defined by x2 + y2 + z2 = 10
Fractal sets, procedural definition, …
– Volume data
Samples from MRI, ultra-sound, simulation…
Example of Triangle Meshes
Making Models
3D scanner
Model libraries
Interaction
Computer vision
Geometric
Modeling
Points, Lines,
Surfaces, …
Rendering
Making Surface Models
Scanner
Image libraries
Camera
Paint
Surface
Parameters
Color, BRDF,
Opacity, …
Rendering
Rendering
Geometric Model
Rendering
Transformation
Image generation
IG = (lighting, shading,
scan conversion)
Surface Model
+
=
Image
Display
Image Display
Rendering
Image Representation
Optical Modulation
Pixel array,
Stroke list, NC cut list,
…
CRT, LCD, Plasma,
Ink, Solid material
Digital Images: pixels
Frame Buffer
Frame Buffer
A block of memory,
dedicated that contains the
pixel array to be passed to
the optical display system
Each pixel encodes color or
other properties (e.g.,
opacity)
Frame Buffer Concepts
Pixel:
One element of frame buffer
- uniquely accessible point in image
Resolution: Width x Height (in pixels)
- 640x480, 1280x1024, 1920x1080
Color depth: Number of bits per-pixel in the buffer
- 8, 16, 24, 32-bits for RGBA
Buffer size:
Total memory allocated for buffer
Frame Buffer Opacity
Alpha
Used for compositing or merging images
Alpha channel – added to color
Holds the alpha value for every pixel
8 bit range: 0 (transparent) – 255 (opaque)
How Much Memory?
Buffer size = width * height *color depth
For example:
If width=640, height=480, color depth=24 bits
Buffer size = 640 * 480 * 3 = 921,600 bytes
If
width=1920, height=1080, color depth=24 bits
Buffer size = 1920 * 1080 * 3 = 6,220,800 bytes
Display Device
• CRT (Cathode Ray Tube)
• LCD (Liquid Crystal Displays)
• Plasma, Projection, HMD,
Volumetric, …
Important Features:
size, resolution, field of view, pixelpitch, color range, brightness,
refresh-rate, black level, update mode
(e.g., interlacing, …), distortion
Interaction
• Interaction is an important component of
graphics applications
• Think about input devices in two ways:
Physical device – that can be described by
their real-world physical properties
(mouse, keyboard, joystick…)
Logical Device – application abstraction
Physical Device
3D Interaction Device
Logical Device Types
• String
– Returns ASCII strings
• Locator
– Returns position and or orientation (6DOF for both)
• Pick
– Returns the identifier of object
• Choice
– Returns a choice that has been selected from a number of
options
• Dial
– Returns analog input (continuous control)
• Stroke
– Returns an array of locations
Applications
Movie Effects
"Geri's Game"
Academy Award-winning of the best animated
short film, 1997.
“Jurassic Park”
Three Academy Awards® for its groundbreaking visual and sound effects
Game
“Tekken Tag Tournament”
Playstation 2
Visualization
Simulation
Medical Visualization
Engineering
- Computer Aided Design (CAD)
Graphics on the Web
Immersion
- Virtual Reality
- Augmented Reality
- Natural Interaction
Course pages
• Notes etc. page : http://wwwbcf.usc.edu/~saty/edu/courses/CS580
• LMS: Desire2Learn – http://courses.uscden.net
HW 1
• Display object (due 1 week) (~1 hr)
– walk through .h, .c, and .ske files
• Data Application Renderer Display
– Work backwards – always see an output
– Start with Display
hw1.txt (1)
CS 580 Assignment 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 disp.h.
Both of these are found in the zip file hw1.zip.
There are several other files there that may be useful.
disp.ske
Your task for this assignment is is to flesh out the functions
in disp.ske and rename it as disp.c.
app1.c This application is complete and calls the display routines
you will write. Just use it.
rects
A data file used by app1. You should be able to figure it out.
output1 A sample ppm-format result image which can be viewed by
i_view. It is created by running "app1 < rects > output1".
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 so that "xv" can be used to display and convert them. ppm files are
color image files that have an ascii header with xs and ys image-dimensions and a
binary 3-byte pixel format:
P6 xs yx 255\n
rgbrgbrgbrgb...
A sample ppm header might be: P6 512 480 255\n. This would be correct for an image
with 512 pixels horizontally and 480 pixels vertically.
Display objects hide the organization of pixel memory and its allocation from the
application and renderer. Only applications create, free, and flush Displays. Display
class and size are determined by the application. Pixels are written by the Renderer
using the Put call. Defining the API interfaces makes the application and Renderer
library display-independent.
See the disp.skel file for a complete description of the API.
App1.c (1)
#include <stdio.h>
#include <Gz.h>
main()
{
GzDisplay
*display;
int
i, j;
int
xRes, yRes, class; /* display parameters */
int
status;
status = 0;
/*
* initialize the display and the renderer
*/
status |= GzNewDisplay(&display, GZ_RGBAZ_DISPLAY, 512, 512);
status |= GzGetDisplayParams(display, &xRes, &yRes, &class);
status |= GzInitDisplay(display); /* init for new frame */
if (status) exit(GZ_FAILURE);
App1.c (2)
{
int ulx, uly, lrx, lry, r, g, b;
while( fscanf(stdin, "%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++) {
GzPutDisplay(display, i, j, r, g, b, 1, 0);
}
}
}
}
GzFlushDisplay(display);
/* write out or update display */
/*
* Clean up and exit
*/
status |= GzFreeDisplay(display);
if (status)
exit(GZ_FAILURE);
else
exit(GZ_SUCCESS);
Gz.h
/*
* Gz.h - include file for rendering library
* CSCI 580 USC
*/
/*
* display classes
*/
#define GZ_RGBAZ_DISPLAY
/*
/*
* renderer classes
*/
#define GZ_Z_BUFFER_RENDER
* As far as the application is concerned, the renderer
* and the display are of type void *.
* Naturally, the rendering and display routines will define
* them however they wish.
1
1
*/
#ifndef DISPLAY_CODE
typedef void *GzDisplay;
#endif
#ifndef RENDERER_CODE
typedef void *GzRender;
#endif
/*
* universal constants
*/
#define GZ_SUCCESS
0
#define GZ_FAILURE
1
typedef int
typedef int
typedef void
typedef float
GzRenderClass;
GzDisplayClass;
*GzPointer;
GzColor[3];
typedef short GzIntensity;
/* 0-4095 in lower 12-bits for RGBA */
typedef int
clipping */
GzDepth;
#define RED 0
#define GREEN 1
#define BLUE 2
#define X
#define Y
#define Z
0
1
2
/* signed z for
/* array indicies for color vector */
/* array indicies for position vector */
Disp.h
/*
* disp.h -- include file for Display
* USC csci 580
*/
/* define general RGBAZ display pixel-type */
typedef struct {
GzIntensity red;
GzIntensity green;
GzIntensity blue;
GzIntensity alpha;
GzDepth
z;
} GzPixel;
/* define a display type */
typedef struct {
unsigned short
xres;
unsigned short
yres;
GzDisplayClass
class;
short
open;
GzPixel *fbuf; /* frame buffer array */
} GzDisplay;
/* put some bounds on size in case of error */
#define MAXXRES 1024
#define MAXYRES 1024
/* simplify fbuf indexing */
Notes:
• Pixel structure holds anything
we will need – we use what we
need for each class of display
• Display structure is complete
data about the display – should
be able to make as many displays
as app wants to.
• Mark Display as Open (1) when
it’s properly initialized – test it
before use.
• Do bounds checking and logical
correction or error management
•xres, yres
•Intensity (RGBA)
#define
DISPLAY_CODE
#include
#include
#include
<stdio.h>
<Gz.h>
<disp.h>
Disp.ske
int GzNewDisplay(display, class, xRes, yRes)
GzDisplay
**display;
GzDisplayClass
class;
int
xRes;
int
yRes;
{
/* create a display:
-- allocate memory for indicated class and resolution
-- pass back pointer to GzDisplay object in display
*/
}
int GzFreeDisplay(display)
GzDisplay
{
/* clean up, free memory */
}
*display;
int GzGetDisplayParams(display, xRes, yRes, class)
GzDisplay
*display;
int
*xRes;
int
*yRes;
GzDisplayClass
*class;
{
/* pass back values for an open display */
}
int GzInitDisplay(display)
GzDisplay
*display;
{
/* set everything to some default values - start a new frame */
int GzPutDisplay(display, i, j, r, g, b, a, z)
GzDisplay
*display;
int
i;
int
j;
GzIntensity
r;
GzIntensity
g;
GzIntensity
b;
GzIntensity
a;
GzDepth
z;
{
/* write pixel values into the display */
}
int GzGetDisplay(display, i, j, r, g, b, a, z)
GzDisplay
*display;
int
i;
int
j;
GzIntensity
*r;
GzIntensity
*g;
GzIntensity
*b;
GzIntensity
*a;
GzDepth
*z;
{
/* pass back pixel value in the display */
/* check display class to see what vars are valid */
}
int GzFlushDisplay(display)
GzDisplay
*display;
{
/* write pixels out to ppm file based on display class -- "P6 %d %d 255\n"
*/
}
Notes: just fill in the functions…
Flush call is a PPM file write and/or
a windows image copy
rects
10
300
-100
222
250
100
50
55
222
-50
250
200
200
511
600
270
400
300
320
444
270
588
500
300
3200
900
3333
4321
2180
4000
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 256x256 image
4320
4200
2212
834
1209
5000
3254
2189
2121
1898
5333
444
HW1 pitfalls
•
•
Careful with pointers
Bounds check the parameters of the display functions
– pixel coords – ignore off-screen coordinate commands
– pixel GzIntensity values – clamp to 0-4095 within 16-bit short
•
Flush command requires conversion of GzIntensity to 8-bit rgb component
– Drop LS 4-bits by right-shifting and then use low byte of GzIntensity value
GzIntensity is a 16 bit signed short
15 14 13 12 11 10
9
8
7
6
5
4
3
2
1
0
We allow a range of 12-bits (0-4095) for valid values. Upper 4-bits are always zeros.
0
0
0
0
a
b
c
d
e
f
g
h
i
j
k
l
We convert to 8-bits (0-255) for required PPM (or screen) format. Right shift 4-times with zero-fill
0
0
0
0
0
0
0
0
a
b
c
d
e
f
g
h
g
h
Final 8-bit unsigned color (rgb) is created by casting (copy) to an unsigned char
a
b
c
d
e
f