Monday, August 04, 2003

A Little on LOD. Responding to Ben Bederman: Thanks for the additional information on Piccolo's approach to LOD. Here are my thoughts. I think it's useful to make a separation between macro- and micro-LOD. I view micro-LOD as being at the primitive rendering level, and macro as the application level. You are absolutely correct in that every application needs and benefits from micro-level LOD, and that we have _some_ support in the Java2D platform to help us out here (ellipse line segment generation, for example). For any 2.5d UI, though, you pretty much need to know when you get "close" to a node, so you can create additional detail. Creating additional detail can mean populating the scene graph with additional nodes, or it can mean drawing an existing node differently. It can also mean both of those activities. You might also want have more than one gradiation, depending on how complex the node is. Most metrics for the "switch" between levels of detail will involve a pixel-based metric. That is, when a node becomes sufficiently discernible by the viewer, something happens. Working from zoom factors is an indirect way of accomplishing the same thing, and I think it clouds the waters. Ultimately we're dealing in pixels, pushed to the screen (well, if Piccolo were rendering to a vector-based display system that wouldn't be true, but we'll discount that uncommon case for now, unless anybody has an old asteroids machine around they've modified to run Java). So it makes sense to be able to declare a series of thresholds, measured in pixels. The zoom factor is essentially pixels per unit length, so it can perhaps be used the same way. I think if the goal of Piccolo is to make applications as simple as possible to write, then as a writer I want to be able to do something when my node grows to 10x10 visible pixels, then do something again when it grows to 100x100. This is a retreat from the notions of continuous level of detail that are largely prevalent in the 3D world. We do not need such sophistication; I am in complete agreement with you there. To create our simplified thresholding system, I would modify the event handling system to have an additional LODEvent, where that event contains the visibility, distance from the center point of the camera, current zoom factor of a node and the pixel size of that node. One or more pixel/zoom/distance thresholds could be registered with the camera, and/or for nodes. As the node is painted/zoom in upon, appropriate LODEvents are issued. This single mechanism could accomodate a pretty large number of cases. We don't attack the continuous LOD problem, but we do provide a simple mechanism (with a couple of modes) that can be used to achieve the very common cases. In addition, strategies for deferred loading and so forth could be added in the future. The Piccolo core can also be judicious in its issuance of LODEvents, in order to maintain frame rates. The real question, is the added complexity of a system like this worth it, in terms of the base library. I can't really answer that question. I can say that based on my observations, many (if not most) ZUI apps that deal with larger data sets will greatly benefit from not having to recreate such a framework. I am playing with a couple of different domains right now; the first is display of time-based information in a timeline form. The second is financial data set display. I anticipate needing LOD support for the first, but not necessarily for the second (although as the data sets climb in size, it might become necessary). It's entirely appropriate for the interested parties here to come up with this kind of functionality. If something sufficiently good is developed, I think we can make a case for it becoming part of the core. I say "core" because I think some of the events that we need to generate are best handled there, and might be difficult to add as extensions. 12:19:43 AM