1 / 18

Challenges for Remote Visualization: Remote Viz Is Really Large Data Viz

Sam Uselton Center for Applied Scientific Computing Lawrence Livermore National Lab October 25, 2001. Challenges for Remote Visualization: Remote Viz Is Really Large Data Viz. Remote Viz == Large Data Viz. The Real Problem is TIME, not Distance.

libby-goff
Download Presentation

Challenges for Remote Visualization: Remote Viz Is Really Large Data Viz

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Sam UseltonCenter for Applied Scientific ComputingLawrence Livermore National LabOctober 25, 2001 Challenges for Remote Visualization: Remote Viz Is Really Large Data Viz

  2. Remote Viz == Large Data Viz • The Real Problem is TIME, not Distance. • Large : Defined Relative to Available Resources • Data Size vs Bandwidth • Data Size vs Memory • Data Size vs Storage • Examples of “TOO MUCH” • 56Kb Modem vs 10’s of MegaBytes • 10Mb EtherNet vs GigaBytes • Gigabit EtherNet vs 100’s of GigaBytes

  3. Some Issues are NOT Visualization Specific • How are Remote Sites Accessed? • Find Relevant Data? Same. • Demonstrate Authorization? Same. • Access Content? Same? • Can Security Be Guaranteed? • Same Security Requirements? • Implementation Issues?

  4. Visualization Activity : A Model • Get Data • Find • Demonstrate Authorization • Select / Extract / Derive Data • Describe Visualization • Mapping to Geometric, Visual and Other Attributes • Scene, Viewing and Rendering Attributes • Generate Images

  5. Visualization Activity : A Model • Get Data • Find • Demonstrate Authorization • Select / Extract / Derive Data • Describe Visualization • Mapping to Geometric, Visual and Other Attributes • Scene, Viewing and Rendering Attributes • Generate Images • Interaction: • Mapping Controls to Dynamic Attributes • Manipulate Controls

  6. Remote Exploration is Harder Than Remote Presentation • Exploration Requires Interactive Choices • Interactions Affected By Latency (AND Bandwidth) • Time (of course) • Consistency (!) • Multiple Times • Variability of Impact • By Interaction Mode: • Haptic Head Tracking Hand Tracking • Indirect Manipulation Command Line • By Individual and Expectation

  7. Direct Approach: Fixed Bandwidth Requirement (Good) High Bandwidth Requirement (BAD) MegaPixel Workstation 1M pixels x 3 Bytes x 60 hz = 180 MB / sec IBM T220 High Resolution LCD (or a Tiled Display) 9M pixels x 3 Bytes x 30 hz = 810 MB /sec Large Tiled Displays too. Alternatives: Distribute Images

  8. Alternatives: Distribute Images … Cleverly • Smaller Windows • or lower resolution • Generic Compression (example) • Processing Overhead at BOTH ENDS

  9. Alternatives: Distribute Images … Cleverly • Application Specific Compression (examples) • Better Compression (Sometimes) • Less Overhead (Sometimes) • Batch Mode: Make Movies, ftp, then Play Locally • OR … Make CDs and Ship

  10. Alternatives: Distribute the Data • Large Data Means Long Delay • Increasing Chances of Failures • Large Data May Exceed Local Resources • Memory, Storage, … • … and Wasteful When Some (Most?) Data Is Not Used • Batch Mode: Make TarBalls, ftp, then Play Locally • OR … Make CDs and Ship

  11. Alternatives: Distribute Graphics Information • Geometry, Colors, Textures, … • Local Control of View • Solves Latency Problem for Viewing Changes • Render Using Local Hardware • Fast and Cheap • Appropriate for Local Display • MAY Use Less Total Bandwidth, But Slower Starting

  12. Alternatives: Distribute Geometry and App Data • Local Control of View • Local Color Mapping ... • Local Quantitative Querying ... • BUT MORE DATA - Impacting Both Time and Storage

  13. Alternatives: Distribute SOME Geometry • View Dependence • View Culling • Level-of-Detail • Occlusion Culling • Progressive • Interruptable

  14. Alternatives: Distribute Some DATA • View Dependent & Progressive • Trickier: Some Sort-First Processing • Extract Geometry Locally • Lower Latency for Changing Geometry (Good) • Heavier Processing Load at Lighter Resource (Bad) • Interruptable

  15. Alternatives: What Works Best ? • It Depends !! • Time varying data, • Data ”Over There" vs Data ”All Around Me" • Dynamic View vs • Dynamic Parameter Mapping vs • Dynamic Geometry Selection • Systems Should Support Multiple Alternatives

  16. Comments On “Immersion” • Dynamic Head Tracking Controlling View of Scene • Powerful Qualitative Impact on Viewer (Good) • Stringent Latency Demands, Double Images (BAD) • Very Useful for Training and Planning • Less Important for Analytical Tasks

  17. Comments On Collaboration • Group Activity Models: • Presenter(s) and Audience • Simultaneous Independent Activities • Tightly Coordinated Joint Tasks • Asynchronous Activities • Which Modes Are Needed For Particular Uses? • How to Move Between Models ? • How to Decide ? • How to Indicate ?

  18. Acknowledgements • David Metz and KGO-TV for Video of the 2001 San Francisco Grand Prix Bicycle Race. • ASCI VIEWS, especially the LLNL visualization team. • This work was performed under the auspices of the U.S. Department of Energy by University of California Lawrence Livermore National Laboratory under contract No. W-7405-Eng-48. UCRL - PRES-144889

More Related