300 likes | 380 Views
Lecture 9. Handling Exceptions 3D graphics Help Options More on Events, Producers/Consumers . DND 3 Demo AnimCursor Demo Q&A. Final. Dealing with Exceptions. Exceptions as a way of life. Can’t avoid them when doing File I/O, external processes, or networking.
E N D
Lecture 9 • Handling Exceptions • 3D graphics • Help Options • More on Events, Producers/Consumers. • DND 3 Demo • AnimCursor Demo • Q&A. Final.
Dealing with Exceptions • Exceptions as a way of life. • Can’t avoid them when doing File I/O, external processes, or networking. • Catch block should restore program to a “continuable”state. • In most cases, the user must be notified of the failure. Often a “retry” option should be offered.
try { // Input filename 1 // Input filename 2 // exec(movecommand+“ ”+f1+“ ”+f2) // capture output from process // refresh directory windows involved. } catch (FileNotFoundException e) { String mesg = e.getLocalizedMessage(); if (mesg == null); mesg = DEFAULT_FNF_MESSAGE; JOptionPane.showMessageDialog(mesg); } catch (IOException e) { //... }
Notifying the User • Throwable.getLocalizedMessage() gets a locale-specific message for the error. • Exceptions do not always provide good messages. If you know more precisely what the problem is, tell the user. • Provide default messages.
try { // ... // exec(movecommand1); backup f2(undo) // exec(movecommand2); // capture outputs // refresh directory windows involved. } catch (Exception e) { JOptionPane.showMessageDialog(mesg); // What if movecommand1 was done? }
Don’t catch, prevent! • When possible, catch Exceptions before they occur. • Example: In “move” command, user gives a non-existent source filename. This should be checked for immediately, and the move command should be aborted with a warning message (and option to correct filename).
3D Graphics, Overview • Internal representation of a 3D environment. • Representation of “screen location” within the context of the above. • Rendering mechanism to display screen view based on both the above. • Methods of manipulating all the above. For each of these, there are many methods!
3D: Internal Model • Primary object is a Surface (2-dimensional manifold). • Surfaces are usually represented as a “quilt” made up of triangular or polygonal pieces. • Each vertex of these is represented by an (x,y,z) triple of real numbers. • Each piece also has a color attribute.
3D: Screen as Window • As with 2D graphics, we think of the screen as corresponding to a particular 2-dimensional window within the model. For 3D graphics, we also must include a point representing the eyes of the user. This point and rectangle together determine the “viewable” area which is to be displayed on-screen.
3D Internals Eye Screen Surfaces
The Visible Cone • Each point on the screen corresponds to a ray, from the eye through the point, extending infinitely onward. • Each rectangle on the screen corresponds to a “rectangular cone” of points, which lie on rays from the eye through the points in the rectangle. • “Visible cone” = cone for entire screen.
Ideal on-screen image • Surfaces which intersect the visible cone are potentially visible. Principal: light rays reflected from surfaces within the visible cone can pass through the window, reaching the eye. • Closer surfaces block farther surfaces. For each screen point, take the first surface struck by its ray.
Actual on-screen image • Can’t check every point in screen. • Find first surface for each integer point in screen rectangle. • Color pixel by averaging the 4 colors of its corners. • Alternative approach often used: draw each polygon on screen, working back-to-front (z-ordering).
Colors & Paints • The previous approach is pretty good at displaying shapes of surfaces. We assumed the color of each polygon was given to us. More likely, it is not. • Prefer to deduce the screen image from a “Paint” applied to the surface. Texture-mapping is the art of rendering such an image.
Level-coloring • To emphasize differences in depth between polygons, often want the coloration to depend on distance from eye. Simplest scheme: color darkens to black; darkness increases with distance. Fog effect is reverse: farther=whiter. • Base color and brightness can be specified for each surface.
Texture-mapping • Slightly more complicated than displaying TexturePaints, because the polygon which is painted may be at an oblique angle to the screen. • Conversion is affine transformation. Polygon Eye Screen
Operations on 3D model • Change of view • Can be thought of as moving the eye and screen, or moving everything else. • Can also think of as changing coordinate system. The screen rectangle defines an x and a y axis, and the eye defines a z-axis. • Any 2 coordinate systems are related by an affine transformation, just as in 2D case. Completely described by a 4x4 matrix.
Operations on 3D model II • Translating and rotating individual surfaces or pieces of surfaces requires applying an affine transformation to all the vertices defining those surfaces.
Proper 3D support • High-level constructs for creating surfaces and specifying Paints on surfaces. • Trivial view support: you specify only where the eye and screen are. • VRML support. • 3D affine transformations on Surfaces. • Fast performance.
Hardware support • Many video cards provide support for high-speed graphics operations. So do some microprocessors (Pentium, AMD). • Generally, this means special hardware commands for defining, transforming, and displaying 3D surfaces, often with texture-mapped paints. • Performance++. Standards??.
Ray-tracing • Idea: simulate real life. Rays of light emanate from various sources, and are reflected, absorbed, and scattered to varying extents by each surface. • Proceeds in steps. Initially, only lights are lit, and all surfaces are jet black. Each step re-evaluates the light from each surface, based on previous step.
Ray-tracing • Can produce almost photo-realistic images, especially when combined with texture-mapping. • Very computationally intensive (slow).
Existing 3D Systems, I • OpenGL (faq): (home page). Introduced in 1992. Not open-source, yes 3rd party, platform independent. • DirectX: Microsoft’s multimedia suite. • Both of these are medium-level langs, designed as intermediaries between programs and acceleration hardware.
Existing 3D systems, II • Java3D: still in alpha-beta-testing at Sun. Follows VRML’s approach. • VRML: multi-participant interactive simulations. Invented 1994, latest standard VRML97. VRML 2.0 soon. • Nodes may be sounds, images, 3D surfaces, web sites, affine transformations. • Nodes are arranged in “scene graphs.”
Advanced Help • Topic Selector • Use a JTabbedPane or CardLayout to offer more than one topic selection method. • Table of Contents • Use a JTree to present hierarchically arranged help topics. • Searchable Index • Store topics as string, search with String.indexOf()
History Tools Preferences Hypertext, Expandable Nodes Card Layout ToolTip Topic Selector Topic Display
Events, Sources, Listeners Source Listener(s) listener added to the source new event Event pass reference to event process the event new event Event pass reference to event process the event
Events • For each “event” a single Event is created, and all registered Listeners are given a reference to this Event. • Listeners are not generally aware of the event source. After the event happens, they can discover the source by interacting with the Event itself. (Event.getSource).
Producers and Consumers • Similar to Sources and Listeners, except that production is not generally a result of an external user action. • Producer notifies consumers when the produced item is ready by invoking a special method, rather than using the event mechanism. Consumers need not all be treated the same way.