Mobile graphic exam, 2007-10-16, 8-13 1a: With a GPU it is easier to exploit parallel processing, get better image quality, and get better energy-efficiency. This is because the GPU is a streaming processor. Also, you do not use the CPU for graphics, and hence the CPU can be used for other things. 1b: M3G is an open API, open for everyone, and for every platform. If you want to reach many customers, this is the way to go. M3g is targeted towards higher quality rendering with hardware. M3G has a full scene-graph which makes it easier to do hierarchical animation, and to maintain larger worlds. 1c: Today, the angle-per-pixel is smaller for a mobile device compared to a desktop display, and hence the image quality should be higher on a desktop. The display resolution has increased rapidly for mobiles, but the physical size remains about the same. 1d: When texture minification occurs, you access texels with large distances inbetween, and hence there is no use for texture caching. Mipmapping on the other hand, accesses one or more levels in the mipmapping hierarchy, and these levels are selected such that you visit neighboring texels when walking to the next pixel on the triangle. 2a: 1) float + fixed, 2) eliminate redundant api calls, eliminate api calls which are seldom used. 3) compact API, efficient, OpenGL too big! OpenGL ES <50kB! 2b: earth.addChild(moon); sun.addChild(earth); myWorld.addChild(sun); 2c: First strip: 5 3 4 1 2 0, i.e., start with vertex f, then, d, e, etc. Second strip: 11 10 7 9 8 8 7 6, notice that when we use the second "8", we introduce a triangle with zero area, but it makes it possible to avoid restarting with a new strip. 3a: A mobile device is powered by batteries, and memory accesses are the operations that use the most energy. Heat must dissipate into the air. Cannot use fans -- no room, and inconvenient for the user. 3b: Texture compression is done on read-only data (images), and it does not matter much if it takes a few minutes to compress an image. Buffer compression operates on the color buffer, depth buffer, or the stencil buffer, and these are read and write buffers. Texture compression is almost always lossy. This does not work without major modifications for buffers, and hence if compression does not work, we need a fallback so that the data can be sent uncompressed. Whether a tile is compressed or not is indicated by a tile table, where a few bits indicates how it is compressed, cleared, or not compressed. Buffer compression does not save memory, only bandwidth. Texture compression saves both. 3c: You need a mechanism that controls the accumulated amount of error in a tile. This could be a four-bit value, for example, indicating the amount of error so far. When a threshold has been reached, you can revert to non-lossy compression. 3d: Assume 4 bytes for color, depth, texture d=6 gives o=2.5 (approximately) B = d*Z_r + o * (Z_w + C_w + 2* m* 4 * T_r) cost(Z) = 6 + 2.5 = 8.5 cost(C) = 2.5 cost(T) = 2.5 * 4 * 2* m = 20*0.25=5 4a: Ideally, we would like to have an analytical solution, where we compute the areas covered by the different triangles, and which color each areas has. Since this includes texturing, and since many triangles can overlap a pixel, this becomes a very difficult problem. 4b: texture, screen-space, shader aliasing, time 4c: put the sample points at different locations vertically, preferably with the same distance between (vertical distance) 4d: See lecture notes. 5a: Two points: (ax,ay) to (bx,by). The line equation is on the form: c*X+d*Y+e=0 (avoiding a and b as parameters as the points are called a and b). The line equation can be written as: X(t) = ax + (bx-ax)*t , Y(t) = ay + (by-ay)*t , where t is in [0,1] Rewrite as: (X - ax)/(bx-ax) = t (Y - ay)/(by-ay) = t Set them equal gives: (X-ax)*(by-ay)-(Y-ay)*(bx-ax) = 0 This gives c, d, and e. Another way of doing it: All points that lie exactly on the line must fullfil c*X+d*Y+e=0, and this means also that if you compute the direction from a point on the line to the starting point (ax,ay), you get a direction: (X,Y)-(ax,ay) This direction must be perpendicular to the normal of the line. The normal is simply (bx,by)-(ax,ay) = (bx-ax,by-ay) rotated 90 degrees, which gives us the normal as: N=(-(by-ay),bx-ax) So, the line equation then becomes: N*((X,Y)-(ax,ay)) = 0 This again gives c,d,e. 5b: A point in a triangle divides the triangle into three areas, A0,A1,A2, with the entire triangle area A=A0+A1+A2 The barycentric coordinates are: (A1,A2,A0)/A See slide 36 and 37 in Lecture L4.pdf. 5c: See slide 18, L4.pdf. 6a: The delay stream implements a form of depth peeling, where one layer (in sorted order) is handled back to front. It is a multi-pass algorithm, where you store all visible transparent fragements, and then in each pass you find the most distant surface for each pixel. After the delay, you blend to the frame buffer. If a triangle has unprocessed pixels, it is reinserted into the delay, From Aila et al's paper: The depth peeling procedure using one frame buffer and one depth buffer proceeds as follows: 1. Scan the OIT stream and mark all hidden pixels as processed. Remove fully processed triangles from the stream. 2. At this point, the remaining surfaces are visible. Peel (a-b) until the OIT stream is empty: (a) Clear the depth buffer, scan the OIT stream and store the most distant depth value for each pixel. (b) Scan the OIT stream again and for each pixel blend the surface with a depth value equaling the stored depth value. Mark processed pixels and remove fully pro- cessed triangles. 6b: (a*b) uses 2+3=5 fractional bits. (c*d) uses 6+2=8 fractional bits. To add these terms, we need to shift a*b so that is also has 8 fractional bits: ((a*b)<<3) + (c*d) --> 8 fractional bits in total. 6c: You may have a lenticular display, where a film of half-cylinders has been "glued" onto an LCD-display, with several pixels under each cylinder. With two pixels under a cylinder, you get a stereo effect, but you have have more views than that to provide motion parallax. With n views, it typically costs n times as much rendering time. However, with clever algorithms this can be reduced a lot due to that that images are very similar.