Presentation is loading. Please wait.

Presentation is loading. Please wait.

OpenGL 3 Angel: Chapter 2 OpenGL Programming and Reference Guides, other sources. ppt from Angel, AW, etc. CSCI 6360/4360.

Similar presentations


Presentation on theme: "OpenGL 3 Angel: Chapter 2 OpenGL Programming and Reference Guides, other sources. ppt from Angel, AW, etc. CSCI 6360/4360."— Presentation transcript:

1 OpenGL 3 Angel: Chapter 2 OpenGL Programming and Reference Guides, other sources. ppt from Angel, AW, etc. CSCI 6360/4360

2 Questions from last week?

3 Overview… Review of event driven architecture – GLUT, callbacks, etc. Other interactive program techniques and elements Text –Bitmap and stroke Display Lists –Retained mode graphics Picking –Select objects from the display Bitwise manipulation, e.g., XOR for non-erasure –Rubberbanding Design of interactive programs Preview of the OpenGL pipeline transformations … next few weeks

4 Review Window system and graphics system Event driven control flow … hopefully, this will be boring

5 GLUT GLU GL GLX, AGL or WGL X, Win32, Mac O/S software and/or hardware application program OpenGL Motif widget or similar Software Org. – Window & Graphics Systems Window system controls/manages window creation, appearance, messages (event queue), etc. –Has its own API for programming, with and without accessing OpenGL Graphics system controls graphics display hardware –Here, OpenGL – GL and its utilities, GLU window system graphics system

6 GLUT GLU GL GLX, AGL or WGL X, Win32, Mac O/S software and/or hardware application program OpenGL Motif widget or similar Software Org. – Window & Graphics Systems Window system controls/manages window creation, appearance, messages (event queue), etc. –Has its own API for programming, with and without accessing OpenGL Graphics system controls graphics display hardware –Here, OpenGL – GL and its utilities, GLU window system graphics system

7 GLUT GLU GL GLX, AGL or WGL X, Win32, Mac O/S software and/or hardware application program OpenGL Motif widget or similar Software Org. – Window & Graphics Systems GLUT - layer for access to both window and graphics systems –GLUT uses GLU and GL for graphics Controls operating and window systems primarily through GLX, AGL, WGL Callback functions are means GLUT uses to “shield programmer from intricacies of direct event loop programming” window system graphics system

8 GLUT, Qt GLU GL GLX, AGL or WGL X, Win32, Mac O/S software and/or hardware application program OpenGL Motif widget or similar Software Org. – Window & Graphics Systems Qt also provides access to both window and graphics system –Widely used and robust, e.g., Google Earth –Many more widgets –Tradeoff: Flexibility (not all window system calls available) window system graphics system

9 Window Manager Distributes Events to Appropriate Event Queues E.g., mouse move across multiple programs –Information about input event distributed to all programs, e.g., mouse x, y –Every program has an event queue Program 1Program 2Program 3 Event queue 1Event queue 2Event queue 3 Wndproc 1Wndproc 2Wndproc 3

10 GLUT Callback Functions Called when various event occur – “encapsulates” messages WndProc (HWND hwnd, UINT iMsg, WPARAM wParam, LPARAM lParam)// front message of event queue { switch (iMsg)// note switch structure – handles and returns { // several “raw” messages result in glut callback being executed case WM_LBUTTONDOWN : // myMouse (button, state, x, y); - one function several “raw” messages case WM_LBUTTONUP : // named in glutMouseFunc case WM_RBUTTONDOWN :. : x = LOWORD (lParam); y = HIWORD (lParam); TextOut (hdc, 20, 200, szBuffer, nLength);// write x and y locations (BTW, later see GLUT) return 0 ; case WM_CREATE : // message when program starts : case WM_SIZE : // message when window size changed case WM_MOUSEMOVE : x = LOWORD (lParam); y = HIWORD (lParam); // “decode” lParam to get x and y locations : return 0 ; } return DefWindowProc (hwnd, iMsg, wParam, lParam) ;// default handling of events, if not here }

11 GLUT Callback Functions Called when various event occur – “encapsulates” messages WndProc (HWND hwnd, UINT iMsg, WPARAM wParam, LPARAM lParam)// front message of event queue { switch (iMsg)// note switch structure – handles and returns { // several “raw” messages result in glut callback being executed case WM_LBUTTONDOWN : // myMouse (button, state, x, y); - one function several “raw” messages case WM_LBUTTONUP : // named in glutMouseFunc case WM_RBUTTONDOWN :. : x = LOWORD (lParam); y = HIWORD (lParam); TextOut (hdc, 20, 200, szBuffer, nLength);// write x and y locations return 0 ; case WM_CREATE : // named in glutDisplayFunc// message when program starts : case WM_SIZE : // named in glutReshapeFunc// message when window size changed case WM_MOUSEMOVE :// named in glutMotionFunc x = LOWORD (lParam); y = HIWORD (lParam); // “decode” lParam to get x and y locations : return 0 ; } return DefWindowProc (hwnd, iMsg, wParam, lParam) ;// default handling of events, if not here }

12 Summary - Events Events – from input devices (usually not result in redraw – call to display) –Most systems have more than one input device, each of which can be triggered at an arbitrary time by a user –Mouse: click one or more buttons –Motion: move mouse –Keyboard: press or release a key Events – from system –Window: resize, expose, iconify (usually do result in redraw – call to display) –Idle: nonevent Define what should be done if no other event is in queue Events – from your program –postRedisplay – new! Each event is put in an event queue –OpenGL uses callback functions to handle events in event queue

13 Control Structure Review Homework as Example Recall, all drawing is done in one function so can handle “redraw” (or refresh) at any time –Vs., e.g., doing partial drawings at various times –At first exposure to event driven programming, this is new – at least degree to which it is done –Requires, then, some signal (message) to redraw System produces signals that result in call to display –E.g., window moved over Postredisplay() is that signal –Your program sends a message to the message queue that results in the program call the display function –In essence “redraw the screen” –In practice “something has changed (or time elapsed), so redraw the screen” –And can have Postredisplay be called within your program to signal “redraw yourself”

14 Review – Glut Event Loop Program defines a display callback function –Here, named mydisplay –Now familiar Every glut program must have a display callback –Executed whenever display must be refreshed, E.g., when window opened –The main function ends with program entering an event loop #include void mydisplay(){ glClear(GL_COLOR_BUFFER_BIT); glBegin(GL_POLYGON); glVertex2f(-0.5, -0.5); glVertex2f(-0.5, 0.5); glVertex2f(0.5, 0.5); glVertex2f(0.5, -0.5); glEnd(); glFlush(); } int main(int argc, char** argv){ glutCreateWindow("simple"); glutDisplayFunc(mydisplay); glutMainLoop(); }

15 Paradigm Control Structure Something happens - an “event” 1. System may cause redraw, i.e., call “myDisplay” E.g., move window off GLUT display function called 2. GLUT callback may handle, if defined E.g., glutMouseFunc - myMouse Update any signals (values) that creating display depends on Draw Display (myDisplay) Event – user, system, program Program’s GLUT callback may change state of program 1 2

16 Paradigm Control Structure Something happens - an “event” 1. System may cause redraw, i.e., call “myDisplay” E.g., move window off GLUT display function called 2. GLUT callback may handle, if defined E.g., glutMouseFunc - myMouse Update any signals (values) that creating display depends on –Often, display needs to be redrawn –Programmer decides and signals this –Program indicates by postRedisplay () Which actually causes system to indicate call to GLUT display function Draw display – because of postRedisplay –GLUT display function Draw Display (myDisplay) Event – user, system, program Program’s GLUT callback may change state of program requiring redraw PostRedisplay() 1 2

17 GLUT Things

18 Text in GLUT When using OpenGL, all the API calls of the window system/manager are available: –E.g., for MS Windows TextOut (… –So, could use system native commands, but at cost of portability GLUT provides portable and reasonably easy to use text Bitmapped –Each character is a fixed size in a matrix of pixels Not pretty, when scaled –Written directly to frame buffer (raster) Eases challenges of scale, e.g., when writing into scene Does not provide for rotating, etc. (applying transformations) to text Stroke –Essentially, rules for generating the characters –Handles scaling –Transformations applied –Have their own challenges, e.g., orientation to the cop

19 Using Bitmap Fonts Pretty easy! –GlutBitmapCharacter (GLUT_BITMAP_8_BY_13, int character) –Also, advances raster position width of character “raster position” is part of OpenGL state –Where next raster primitive will be placed –Set with, e.g., glRasterPos2f() –Use to specify where bitmap to be drawn http://www.opengl.org/resources/code/samples/glut_exampl es/examples/examples.htmlhttp://www.opengl.org/resources/code/samples/glut_exampl es/examples/examples.html : void *font = GLUT_BITMAP_TIMES_ROMAN_24; : GLUT_BITMAP_9_BY_15, GLUT_BITMAP_TIMES_ROMAN_10, GLUT_BITMAP_TIMES_ROMAN_24 : char defaultMessage[] = "GLUT means OpenGL."; char *message = defaultMessage; void output (int x, int y, char *string) { int len, i; glRasterPos2f(x, y); len = (int) strlen(string); for (i = 0; i < len; i++) { glutBitmapCharacter(font, string[i]); } void display(void) { glClear(GL_COLOR_BUFFER_BIT); output(0, 24, "This is written in a GLUT …"); output(100, 100, message); output(50, 145, "(positioned in pixels with ….)"); glutSwapBuffers(); }

20 Window Management Something else pretty straightforward Can in fact create as many windows as like –id = glutCreateWindow( ) idPlanets = glutCreateWindow (“Rotating Planets”) idGalaxy = glutCreateWindow (“Milky Way Galaxy”) –Invoke glutInitDisplay prior to create to set properties different Use window id to select window as current window into which objects rendered –glutSetWindow (id) Can have different display functions, etc. Communication is easy, as all in same name space –Vs. messages, etc. –Can transfer control among windows by having others select as current

21 Display Lists Conceptually similar to a graphics file –Define (name, create), add contents, close In client-server environment, display list is placed on server –Can be redisplayed without sending primitives over network each time –Can also be used in program to not need to re-execute OpenGL immediate and retained mode graphics –Immediate mode graphics In standard OpenGL program, once an object is rendered there is no memory of it and to redisplay it, we must re-execute the code for it to be displayed Can be especially slow if objects complex and sent over a network –Retained mode graphics Alternative is define objects and keep them in some form that can be redisplayed easily Accomplished in OpenGL via display lists

22 Display List Functions and State Creating a display list: ex -> Call a created list: Most OpenGL functions can be put in display lists State changes made inside display list persist after list executed –Efficient to save Can avoid unexpected results by using glPushAttrib and glPushMatrix upon entering a display list, and glPopAttrib and glPopMatrix before exiting –More later, again … GLuint id; void init() { id = glGenLists ( 1 ); glNewList (id, GL_COMPILE ); // OpenGL routines, polygon, etc. glEndList (); } void display () { glCallList ( id ); }

23 Hierarchy and Display Lists Consider model of a car, or robot arm, or anything Objects are hierarchical in that each of several components is part of car object Might, e.g., Create display list for chassis Create display list for wheel To “move” car in scene, translate (more next wk) each element: – glNewList( CAR, GL_COMPILE ); – glCallList( CHASSIS ); – glTranslatef( … ); – glCallList( WHEEL ); – glTranslatef( … ); – glCallList( WHEEL ); – … – glEndList(); Will later consider scene graphs, which encapsulate object information in this way Foundation of much practical cg, e.g., “in hardware”

24 “Picking” or “Hit-testing” or …

25 “Pick” or hit test –Identify an object in the display Fundamental action in user interface Recall, six types of logical input: –Locator: return a position –Pick: return ID of an object –Keyboard: return strings of characters –Stroke: return array of positions –Valuator: return floating point number –Choice: return one of n items In principle, should be simple because mouse gives the x and y position, and should be able to determine to which object(s) a position corresponds to

26 “Picking” or “Hit-testing” or … In practice harder to do Practical difficulties: –OpenGL Pipeline architecture is feed forward, hard to go from screen back to world Object in world, create view from position (transform), clip, map to viewport –Complicated by screen being 2D, world is 3D –Other details E.g., How close does user have to come to object to say selected it? Three approaches: –Create bounding boxes and programmer checks (detail follows) “hit list” –Exploits/use graphics system - “selection mode” –Use a system buffer to store object ids as objects are rendered

27 OpenGL Rendering for Picking Briefest of overviews OpenGL can render in one of three modes selected by glRenderMode(mode) –GL_RENDER: normal rendering to the frame buffer (default) –GL_SELECTION: Each primitive in the view volume generates a hit record that is placed in a name stack which can be examined later –GL_FEEDBACK: provides list of primitives rendered but no output to the frame buffer

28 Selection Mode - briefly First, series of ids set by application program to identify objects –Functions: glSelectBuffer(): specifies name buffer, glInitNames(): initializes name buffer glPushName(id): push id on name buffer, glPopName(): pop top of name buffer glLoadName(id): replace top name on buffer Using selection mode – straightforward in principle, but efficiency –Initialize name buffer, enter selection mode (using mouse) –Render scene with user-defined ids –Reenter normal render mode (returns number of hits) –Examine contents of name buffer (hit records, id and depth information) Changes viewing parameters so that only those primitives near cursor are in altered view volume –Use gluPickMatrix (see text for details)

29 Using 2 nd Buffer and Colors for Picking Call it a trick … (OK, technique) –Besides an object’s “light color”, assign an arbitrary unique color to each object that will be used as an identifier – doesn’t matter what looks like e.g., (1, 0, 0) = polygon on left front of house 5; (1, 0, 0) = polygon on right front of house 5; … Render scene as usual to front buffer (which is displayed, as usual) Render scene again to a (color) buffer other than front buffer so results of rendering are not visible! –Could even use back buffer if not need double buffering –But there are many buffers available to OpenGL Then, get mouse position and use glReadPixels() to read color in second (non-visible) buffer – –Which gives identifier (color) for object (all its polygons) –Which is identifier for object! –… programming as if resources don’t matter

30 Bounding Boxes Extent of an object –Smallest rectangle, aligned with coordinate axes, that contains object –Angel program – at class web site For 2d, easy to determine rectangle in screen coordinates that corresponds to a rectangle point in object or world coordinates For 3d, bounding box is a right parallelepid (box) –Program can associate objects with bounding boxes Hit testing (picking) is process of checking if mouse is within bounding box of objects

31 Testing 2d Extents Checking if mouse is within bounding box of objects Again, full Angel program on class web site Test if mouse (pointer) is in region Recall, –myMouse (button, state, x, y) –button GLUT_LEFT_BUTTON GLUT_MID_BUTTON GLUT_RIGHT_BUTTON –state GLUT_UP GLUT_DOWN –x, y current position Will need data structure to hold extents

32 Testing 2d Extents Checking if mouse is within bounding box of objects Check to see if mouse is “in” the region –Yes, it’s this easy … and crude Void myMouse (btn, state, x, y) { y = wh – y; if (btn==GLUT_LEFT_BUTTON && state == GLUT_DOWN && ( x > 10 && x < 50 ) && ( y > 10 && y < 30 ) ) { // if hit, do things: bHit = TRUE; // probably, set some “signal” postReDisplay(); // probably, cause display to be redrawn } // using information of “signal” }

33 Testing Multiple Extents Searching an array of extents Check if mouse in any of several regions –Array of extents is searched rectObjs[0].left = 10;rectObjs[0].right = 50; rectObjs[0].top = 20;rectObjs[0].bottom = 30; rectObjs[1].left = 10;rectObjs[1].right = 50; rectObjs[1].top = 30;rectObjs[1].bottom = 50; // other assignments nObjects = 3; void myMouse (btn, state, x, y) { y = wh – y; : for (i=0; i<nObjects; i++) { if (btn==GLUT_LEFT_BUTTON && state == GLUT_DOWN && ( x > rectOjs[i].left && x < rectOjs[i].right ) && ( y > rectOjs[i].top && y < rectOjs[i].bottom ) ) { bHit = TRUE; // probably, set some “signals” nObjectPicked=i; postReDisplay(); // probably, cause display to be redrawn break; // using information of “signal” }

34 Angel’s polygon.c – Pick Polygon Polygon pick, …, add, delete –Examples of bounding box pick, data structures, etc. // Angel’s polygon struct // More than you will need for homework typedef struct polygon { int color; /* color index */ bool used; /* TRUE if polygon exists */ int xmin, xmax, ymin, ymax; /* bounding box */ float xc, yc; /* center of polygon */ int nvertices; /* number of vertices */ int x[MAX_VERTICES]; /* vertices */ int y[MAX_VERTICES]; } polygon; int pick_polygon(int x, int y) { // find first polygon in which we are in bounding box int i; for(i=0; i<MAX_POLYGONS; i++) { if(polygons[i].used) if((x>=polygons[i].xmin)&& (x<=polygons[i].xmax)&& (y>=polygons[i].ymin)&& (y<polygons[i].ymax)) { in_polygon = i; moving = TRUE; return(i); } printf("not in a polygon\n"); return(-1); }

35 polygon.c – Polygon follows Cursor fyi – using glutMotionFunc Polygin void myMotion(int x, int y) // name defined in glutMotionFunc { float dx, dy; int i,j; if (moving) // global flag for action to move polygon – set by user { y = wh - y; // invert screen coordinates to world coordinates j = pick_polygon(x, y); // just saw - returns index of polygon (if any) at pointer if (j<0) { printf("not in a polygon\n"); return; } // if not in polygon, j<0, return.. better variable name // if inside polygon, then move polygon - x, y are mouse loc, poly has x, y – so dx,y is distance to move dx = x - polygons[j].xc; dy = y - polygons[j].yc; for(i = 0; i< polygons[j].nvertices; i++) // assign polygon new locations { polygons[j].x[i] += dx; polygons[j].y[i] += dy; } // update bounding box polygons[j].xc += dx; polygons[j].yc += dy; if(dx>0) polygons[j].xmax += dx; else polygons[j].xmin += dx; if(dy>0) polygons[j].ymax += dy; else polygons[j].ymin += dy; glutPostRedisplay(); // cause display redraw with new polygon location }

36 Placing and Aiming OGL Camera Have used default camera location, viewing direction, etc., so far That’s no fun

37 Placing and Aiming OGL Camera Natural to position camera in world space as if real camera 1. Identify the eye point where the camera is located 2. Identify the look-at point that we wish to appear in center of view 3. Identify an up-vector vector oriented upwards in final image Specify camera configuration with: –gluLookAt(ex, ey, ez, ax, ay, az, ux, uy, uz) –3 camera vectors: lookFrom (ex, ey, ez), lookAt (ax, ay, az), vUp (ux, uy, uz) Or, gluLookAt (lookFrom x,y,z, lookAt x,y,z, vUp x,y,z )

38 OpenGL: gluLookAt (a really handy little function) Specify camera configuration with –gluLookAt(ex, ey, ez, ax, ay, az, ux, uy, uz) gluLookAt (lookFrom x,y,z, lookAt x,y,z, vUp x,y,z ) –Note: a utility – glu, not gl Three camera vectors –lookFrom (ex, ey, ez) –lookAt (ax, ay, az) –vUp (ux, uy, uz) Typical Transformation Setup (more later): glMatrixMode(GL_PROJECTION);// which matrix glLoadIdentity();// initialize – recall, make have no affect gluPerspective(fovy, aspect, zNear, zFar);// will be perspective (more later) glMatrixMode(GL_MODELVIEW);// which matrix glLoadIdentity();// initialize gluLookat(ex, ey, ez, ax, ay, az, 0, 1, 0);// easy!

39 gluLookAt Function (from red book) From Red Book …. Function gluLookAt forms required modelview matrix through a simple interface Still need to initialize –Can concatenate with modeling transformations Example: isometric view of cube aligned with axes glMatrixMode(GL_MODELVIEW): glLoadIdentity(); //gluLookAt(ex, ey, ez, ax, ay, az, ux, uy, uz) gluLookAt(1.0, 1.0, 1.0, 0.0, 0.0, 0.0, 0., 1.0. 0.0);

40 Angel Fly Around Example “Fly around” – easy with gluLookAt –Angel example also allows mouse to rotate cube (at class site) or mesh Honolulu data –… or objects –Angel, polygon mesh “Fly around”: –Moves camera –Keeps “look at” same (origin) –Keeps “vUp” same No tilting, etc. of camera Keys change location of camera static GLdouble viewer[]= {0.0, 0.0, 5.0}; void display(void) { glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); glLoadIdentity(); // gluLookAt (lookFrom x,y,z, lookAt x,y,z, vUp x,y,z ) gluLookAt(viewer[0],viewer[1],viewer[2], 0.0, 0.0, 0.0, 0.0, 1.0, 0.0); // draw scene glFlush(); glutSwapBuffers(); }

41 Angel Fly Around Example functions keys and main main(int argc, char **argv) { glutInit(&argc, argv); glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB | GLUT_DEPTH); glutInitWindowSize(500, 500); glutCreateWindow(“fly"); glutReshapeFunc(myReshape); glutDisplayFunc(display); glutKeyboardFunc(keys); glEnable(GL_DEPTH_TEST); glutMainLoop(); } keys(unsigned char key, int x, int y) { // ‘x’, ‘X’, ‘y’, ‘Y’, ‘z’, and ‘Z’ keys // change global array viewer[3] // - used to store viewpoint // // Then, after key input call postredisplay // - signal redraw necessary, // and, hence, display called if(key == 'x') viewer[0]-= 1.0; if(key == 'X') viewer[0]+= 1.0; if(key == 'y') viewer[1]-= 1.0; if(key == 'Y') viewer[1]+= 1.0; if(key == 'z') viewer[2]-= 1.0; if(key == 'Z') viewer[2]+= 1.0; display(); }

42 Camera Fly-around http://www.youtube.com/watch?v=kki1kbmJ8x8 Is the camera moving, or is the globe rotating? Can’t tell! –Recall, “illusion” of computer graphics Either can be implemented –Just saw fly-around -- Movement of camera in world coordinates And, have also seen rotation of objects –Change of object’s orientation in, again, world coordinates A kind of “duality” of display Will see much more –Transformations

43 Preview … Next week will talk about the series of transformations that are the elements of the OpenGL pipeline Following, is the “big picture” Which we will see again –And again And again –And again »And again

44 Recall, Polygon Mesh Representation Interactive computer graphics uses polygon representation of objects for efficiency Wireframe shows only the polygons –Vertex position for every polygon Shading of polygons used to add “realism” –Photorealisism, as well smooth shading environment mapping bump mapping flat shading 42, 64, 91 47, 69, 90

45 Polygon Mesh Representation Each polygon represented by a set of points Operations on these vertices are at core of interactive cg techniques –And, it is the vertices upon which most of the processing in the pipeline is performed –Also, E.g., Gouraud, interpolated, shading simply takes illumination values at vertices as inputs Vertex lists … more later 42, 64, 91 47, 69, 90

46 Recall, Coordinate Systems in Viewing Transformations of these coordinate systems at core of graphics pipeline! Coordinate Systems in the Graphics Pipeline –OCS – object coordinate system –WCS – world coordinate system –VCS – viewing coordinate system –CCS – clipping coordinate system –NDCS - normalized device coordinate system –DCS – device coordinate system And images are formed on the image plane

47 Viewing Thinking about viewing …. –In what is displayed on view plane –Consider moving the viewpoint and consider moving the object (scene) –Object position and/or orientation changed – “Are you or is it moving?!” BTW, frustum Transformations used to create image on screen when an object is viewed Also, OGL viewing based on specification of transformation matrices –Specify a world –Possibly, transform the world –Specify a projection –Clip (exclude from image) part of world –Specify a viewport into the world

48 OpenGL The big picture … in small print ModelView Matrix –Transformation of elements for projection on view plane Projection matrix Clipping Viewport It is points / lines that are sent down the pipeline Rasterization is done at latest possible time –For efficiency

49 Transformations and Coordinate Systems … to Eye/View Coordinate System Coordinate Systems in the Graphics Pipeline –OCS – object coordinate system –WCS – world coordinate system –VCS – viewing coordinate system –CCS – clipping coordinate system –NDCS - normalized device coordinate system –DCS – device coordinate system Series of “viewing transformations” –transforms a point (its coordinates) from world space to eye space –Set these transformation matrices as part of OpenGL programming –Each transformation operates on different spaces and coordinates Model – View – Projection – Perspective Divide - Viewport

50 OpenGL Transformations Viewing process has 2 parts: –Use model-view matrix to switch vertex reps from object frame in which objects defined to their representation in eye/camera frame – eye at origin Allows use of canonical viewing procedures Type of projection (parallel or perspective) and part of world to image (clipping or view volume) Normalization lets clip against simple cube regardless of projection Delay final projection until end –Important for hidden-surface removal to retain depth information as long as possible

51 OpenGL Clip Space In OpenGL clip space, viewing frustum is mapped to a cube that extends from -1 to 1 in x, y, and z –Cube is good for efficient clipping algorithms! –Called normalization, as in “normalize frustum to unit cube” –OpenGL also flips z axis to create a left handed coordinate system during projection –Series of transformations are used to create the unit cube

52 Clipping and Perspective Division Scene's objects are clipped against clip space bounding box –Eliminates objects (and pieces of objects) not visible in image –Efficient clipping algorithms for homogeneous clip space Perspective division divides all by homogeneous coordinates, w (next week) Clip space becomes Normalized Device Coordinate (NDC) space after perspective division

53 Viewport Transformation OpenGL provides function to set up viewport transformation: –glViewport(x, y, width, height) –Maps NDC space to window (screen) space –And we’re done!!!!!!!!! Straightforward: –Though need attend to aspect ratio

54 OpenGL Transformations and Coordinate Systems Should feel reasonably comfortable with changes in coordinate spaces through series of transformations –Both in practical (OpenGL) and (intuitively) theoretical terms Coordinate spaces: Object World Eye Clip NDC Window Transformations: Model View Projections Perspective Divide Viewport

55 OpenGL Transformations and Coordinate Systems Coordinate spaces: Object World Eye Clip NDC Window Transformations: Model View Projections Perspective Divide Viewport Should feel reasonably comfortable with changes in coordinate spaces through series of transformations –Both in practical (OpenGL) and (intuitively) theoretical terms

56 Raster Logic Operations.

57 Recall, Raster Operations As you know, hardware moves from left to right in creating display It is from the creation of (scan) lines that term raster is derived –screen is a raster device Most generally, operations on a screen are called raster operations For our purposes we’ll be concerned with just drawing lines –Though use of bit block transfers (bitblt) is a useful topic, and is discussed later

58 Logic Operations – On the Raster Also recall … To make things show up on screen, “rendering”, “writing”, or “drawing” to/on the screen, requires “operating on the raster”, which is the screen memory Possible to not only produce a screen image (pixel value) that is written –But also which has a value determined by the current pixel value where to be written –Val to be written = f (val to write, val at loc to be written to)

59 Logic Operations – On the Raster Possible to not only produce a screen image (pixel value) that is written –Val to be written = f (val to write, val at loc to be written to) Have so far considered only one way in which to elements are placed in the raster –Just copy what is to written into the raster In fact, able to use contents of raster (Source) to determine what will be in raster (Destination) E.g. above writing 1 above, –new raster value = 1 AND current raster –Either: New is 0 = 1 and current is 0 New is 1 = 1 and current is 1

60 Raster Logic Operations OpenGL There are 16 possible logical operations between two bits All supported by OpenGL –First, enable logical operations glEnable(GL_COLOR_LOGIC_OP) –Choose logical operation glLogicOp(GL_XOR) glLogicOp(GL_COPY) (default) opcoderesulting value GL_CLEAR0 GL_SET1 GL_COPYs GL_COPY_INVERTED!s GL_NOOPd GL_INVERT!d GL_ANDs & d GL_NAND!(s & d) GL_ORs | d GL_NOR!(s | d) GL_XORs ^ d GL_EQUIV!(s ^ d) GL_AND_REVERSEs & !d GL_AND_INVERTED!s & d GL_OR_REVERSEs | !d GL_OR_INVERTED!s | d

61 Raster Operations, Introduction “drawing” to screen entails performing raster operations General form of raster operations considers both the values of the: source (what you specify to draw) destination (what is already on the screen, state of the pixel currently displayed) Boolean operation is performed when write to screen Consider the screen state as represented by 0 (off, black) and 1 (on, white) A black screen: House drawn (in white): 0 0 0 0 0 0 0 0 0 0 0 0 x 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 screen (destination) is replaced with (  ) house (source) – note: value = 1 – blue just to see Symbolically: D  S (no matter what is already on the screen (destination), which we’ll see)

62 General Form OpenGL Raster Operations Generally, some Boolean operation (op) is performed combining existing destination with what is to be written (source) to yield final result at destination – D  S op D General form of raster operations considers both values: –source (what you specify to draw, e.g., color of pixel), –destination (what is already on screen, i.e., state of pixel currently displayed), and –operation (how combine what on screen and what to be drawn) GL_CLEAR0 GL_SET1 GL_COPYs GL_COPY_INVERTED!s GL_NOOPd GL_INVERT!d GL_ANDs & d GL_NAND!(s & d) GL_ORs | d GL_NOR!(s | d) GL_XORs ^ d GL_EQUIV!(s ^ d) GL_AND_REVERSEs & !d GL_AND_INVERTED!s & d GL_OR_REVERSEs | !d GL_OR_INVERTED!s | d

63 Raster Operations, Example of Application, OR Can in fact combine Source and Destination in a number of ways D  S op D, e.g., D  S | D Write (P, or S):1 1 0 0 Boolean Destination (D):1 0 1 0 Operation Drawing Mode Results:1 1 1 0 | “OR”, GL_OR Again, Boolean operation is performed when pen writes to screen Here, rasterop (ROP) applies “OR” logical operation to operands screen and “bitmap” Example: Draw this figure:X 0 1 0 1 1 0 0 1 0 Using example of house, apply (tediously!) rasterop at each pixel – x marks top left: Original screen: After draw: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 1 0 x 0 1 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 1 0 1 1 1 1 0 0 0 0 0 0 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

64 Raster Operations, Another ROP, XOR, 1 Can in fact combine Source and Destination in a number of ways D  S op D, e.g., D  S ^ D Pen (P, or S):1 1 0 0 Boolean Destination (D):1 0 1 0 Operation Drawing Mode 0 1 1 0 P ^ D “XOR”, R2_XORPEN Again, Boolean operation is performed when pen writes to screen Here, apply ROP XOR, and screen appears after write as if sort of “inverts” Example: Draw this figure: 0 0 1 0 1 1 1 1 0 0 1 0 Apply rasterop at each pixel: Original screen: After draw: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 1 0 1 1 0 1 0 0 0 0 0 0 1 1 1 1 1 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

65 Raster Operations, Another ROP, XOR, 2 Can in fact combine Source and Destination in a number of ways D  S op D, e.g., D  S ^ D Pen (P, or S):1 1 0 0 Boolean Destination (D):1 0 1 0 Operation Drawing Mode 0 1 1 0 P ^ D “XOR”, R2_XORPEN Again, Boolean operation is performed when pen writes to screen For XOR when it is applied again, screen is changed back to it’s original image! Example: Draw this figure: 0 0 1 0 1 1 1 1 0 0 1 0 Apply rasterop at each pixel: After 1 st XOR: After 2 nd XOR - back to original!: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 1 0 1 1 0 1 0 0 0 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

66 Raster Operations, Another ROP, XOR, 3 The implication is that a figure can be: 1. Drawn with XOR anyplace (e.g., over other figures) - and figure is visible (though “sort of inverted” where touches other figs) - and other figures are sort of inverted 2. Drawn again with XOR at the same location to restore the original screen! Successive XOR draws and moves allows nondestructive “movement”: Draw with XOR (showing figure), redraw with XOR (erasing figure & restoring old) move to new location Draw with XOR (showing figure), redraw with XOR (erasing figure & restoring old) move to new location :

67 Angel - “Rubberband” Lines Switch to XOR write mode Draw object For line can use first mouse click to fix one endpoint –Then use motion callback to continuously update the second endpoint Each time mouse moved –Redraw line which erases it –Then draw line from fixed first position to new second position At end, switch back to normal drawing mode and draw line initial display draw line with mouse in XOR mode mouse moved to new position first point second point original line redrawn with XOR new line drawn with XOR

68 Homework # 3, 1 In this third programming assignment in OpenGL you will create a program to allow users to pick and delete polygons and animate display. This program builds on the functionality of your second program. However, in light of the discussion of data structures in class and the functionality required for this program, it may make sense to do some redesign of your earlier program. Yeah, it would be nice, were it possible to effectively just add the new functionality, but increasing experience and the requirements of this program may make it worth the redesign of data structures and re-implementation of functionality.

69 Homework, 2 (specifying where to create objects) This program should: 1) Allow the user to specify the placement of an object upon its creation. After the user, through the menu structure, indicates the creation of a figure of a particular form and color, the user then specifies where it will be created. There are surely several ways to do this. Here, let the position of the new figure created be at the next mouse click. By the way, it would be nice to let the user know what state he or she is in, i.e., “position specifying state”, and a way this is often done is by changing the shape of the cursor. For extra credit have a go at that.

70 Homework, 3 (picking and deleting objects) 2) Allow the user to pick objects (polygons) that have been drawn on the screen and delete those figures. Saving and reading of the new state should be possible, as before. In picking, of course, objects may overlap. The object that is visible, i.e., “on top of” or “in front of” another, should be the one that is picked. Figures that are created after others are “on top of” others. With additions and deletions this is more interesting than in your previous program. One interesting thing is that bounding boxes may overlap, and this has implications for how to check selection.

71 Homework, 4 (extra credit) For extra credit: a) Allow user to specify that all the polygons spin. Like Angel’s example. (discussed last week) b) Implement rubber banding, using xor as discussed, when the cursor is moved to pick an object. The fixed point of the rubber band should be the center of the screen and the user should be able to turn on and off rubber banding by a menu selection.

72 Homework #4, 1 (object animation) 1) Animate the initial display of objects, when a file is read. a) Allow the user to select a “fast” or “slow” animation and b) whether objects are animated simultaneously or individually (see below). The animation should begin by drawing all objects at the center of the screen, when a file is read. Then, each figure should move to its former (saved) location. Recall, y = mx + b. Use double buffering. The user can select at start up whether the movement of objects will be one at a time or simultaneously, i.e., –1) each figure in turn might move from the center of the screen to its location, or –2) all figures might move simultaneously toward their locations. –In the latter case there are a host of decisions to be made about how exactly to do that, and, rather than specify all here, just make decisions and document them.

73 Homework, 2 (user directed “fly around”) 2) Allow the user to position the camera so that the view on the display is like a “fly around” of the objects. That is, the camera remains pointed at the origin (or some point), and its position is moved through user input. Using the elementary keyboard input scheme discussed in class and presented in Angel’s programming example is fine.

74 Homework, 3 (extra credit) Also for extra credit, allow the user more options for positioning and aiming the camera in addition to the functionality of 2) above, –e.g., aim the camera at other positions than the origin, allow “tilting” of the camera by changing the up vector, etc. Having the camera “fly” by itself through some course would be interesting, as well. Of course, in essentially all applications mouse movement, often with button presses is used to position and aim the camera, and implementing this sort of interaction would also be an extra credit activity interesting to pursue.

75 Design of Interactive Programs Recall, your OpenGL term project … Angel –“Defining what characterizes a good interactive program is difficult, but recognizing and appreciating a good interactive program is easy. Such programs include features such as these:” 1. A smooth display, showing neither flicker nor any artifacts of the refresh process 2. A variety of interactive devices on the display 3. A variety of methods for entering and displaying information 4. An easy-to-use interface that does not require substantial effort to learn 5. Feedback to the user 6. Tolerance for user errors 7. A design that incorporates consideration of both the visual and motor properties of the human

76 “Design of Interactive Programs”

77 Bottom line, for interactive programs (and most are) computer graphics (and algorithms, etc.) are only one part of a system to be used by a human toward the end of accomplishing some goal, gaining insight, entertaining him/herself, etc. Designing programs that are interactively good is important Field of human computer interaction considers this explicitly Interactivity issues close to computer graphics –Historically, “interactive computer graphics” –In cg, the role of the human in computing is hard to miss “The field of HCI is an active one, and we will not shortchange you by condensing it into a few pages”

78 Which might be better?

79 HCI: Guidelines, Principles, and Theories Intuition is not bad, it’s just not all there is… –Intuition, after all, comes from (successful, hopefully) experience But, there is a wealth of bad interfaces Guidance for designers and developers –from guidelines, principles, and theories Theories Guidelines Principles

80 Guidelines, Principles, and Theories Guidelines –Specific and practical Cure for design problems, caution dangers, shared language and terminology –Accumulates (and encapsulates) past experience and best practices “blinking is bad, never use it” –Often enforces common procedures –May be: too specific, incomplete, hard to apply, and sometimes wrong –Lowest level Principles –Mid-level –Help analyze and compare design alternatives High level theories and models –Goal is to describe objects and actions with consistent terminology Allowing comprehensible explanations to support communication and teaching –Other theories are predictive E.g., reading, pointing, and typing times Theories Guidelines Principles

81 Guidelines – Examples, Apple Cursor appearance –http://developer. apple.com/docu mentation/User Experience/Con ceptual/OSXHI Guidelines/http://developer. apple.com/docu mentation/User Experience/Con ceptual/OSXHI Guidelines/

82 Guidelines – Examples, Microsoft Selection http://msdn.microsoft. com/library/en- us/dnwue/html/welco me.asp/http://msdn.microsoft. com/library/en- us/dnwue/html/welco me.asp/

83 Principles - Jakob Nielsen Jakob Nielsen –www.useit.comwww.useit.com –Nielsen-Norman Group Consulting, etc –Usability Engineering, among best known books –Recommended: Usability 101: Introduction to Usability –hwww.useit.com/alertbox/200308 25.htmlttp://hwww.useit.com/alertbox/200308 25.htmlttp:// Top Ten Mistakes in Web Design –http://www.useit.com/alertbox/9605.htmlhttp://www.useit.com/alertbox/9605.html

84 Nielsen’s Principles for Usable Design Meet expectations –1. Match the real world –2. Consistency & standards –3. Help & documentation User is the boss –4. User control & freedom –5. Visibility of system status –6. Flexibility & efficiency Handle errors –7. Error prevention –8. Recognition, not recall –9. Error reporting, diagnosis, and recovery Keep it simple –10. Aesthetic & minimalist design

85 Questions?

86 End.


Download ppt "OpenGL 3 Angel: Chapter 2 OpenGL Programming and Reference Guides, other sources. ppt from Angel, AW, etc. CSCI 6360/4360."

Similar presentations


Ads by Google