Transcript PowerPoint
Interactive Simulation of Fire in Virtual Building Environments Richard Bukowski and Carlo Séquin Walkthru Project University of California, Berkeley Presentation ©2001 Brenden Schubert Recap: Simulating Gasses • Warped Blobbies • u/ t= v • ( u) – (u•• )u – p• • 'dis-kre^-tizd The Walkthru System • Virtual environment exploration system using Cells and Portals • Targeted for several million polygon models, but actual number doesn’t really matter • Cell/Portal visibility is precalculated The CFAST System • Consolidated model of Fire And Smoke Transport • Developed at the National Institute of Standards and Technology • Cells and Portals (Volumes and Vents) • Attributes are tracked within each volume – Temperatures, ignition times, gas concentrations • At the core: just another Differential Equation Solver How they store environments • Walkthru: – Major occluders (cell boundaries) – Detail objects (furniture, etc.) associated with cell(s) they are in – Precise geometry (3d polygonal model) • CFAST: – – – – Volumes: floor/ceiling height, area of floor Vents: orientation, area, height above floor Chemical data for objects Position information for ducts, sprinklers, etc. How they store environments Walkthru: CFAST: That’s all the graphics – It’s just a system architecture/integration project from here • Simulator (CFAST) & Visualizer (Walkthru) – Decide on the features of the combined system – Design a data format conversion – Develop a communications protocol • Allow for as low as 3KB/s communication between the visualizer and simulator The Simulation Data Set • Three level hierarchical structure: – Time ‘slice’ – seconds elapsed – Cell or Volume – identifier (pointer, maybe?) – Subvolumes (“chunks”) – integer-indexed chunks • Discretized piece of simulation data reflecting a given volume of space at a given time • Basic unit of data transmission between simulator and visualizer – Ideally, CFAST would be able to simulate per chunk each timeslice, but I don’t think it did (at least not in 1997) • Fire chunk contains info about each fire • Cell chunk contains info about entire cell • User definable – other types and attributes can be added Real-time Channels (or, to those who know them best, RTCs) • 2-way asynchronous data channel • Two bit streams in each direction – Data stream – Command stream • Implemented on top of sockets System Architecture Diagram Visualization • Time controlled by VCR controls or slider – Disabling slider increases performance (why?) • Position controlled by walking around • Autopause: – Mechanism to prevent jerkiness by pausing visualization for a moment (while buffer is refilled) – Activated at beginning and whenever view-time catches up to simulation time Simulation • The Simulation Manager: – Organizes simulation data output by CFAST – For “overlapping” data, most recent supersedes older data • Allows correction + approximation – Some degree of caching (depending on CPU and memory available) Just-In-Time Data Transmission • Physical simulators tend to be bursty – Such as sets of solutions for volumes in a given timeslice (rather then each volume’s data sequentially) • If we use large buffers… • If we use a single bypass channel… • Key: The more buffering, the larger the potential packet latency • So, use as little buffer as possible: near-starvation Dealing with Bursty Data • The Bandwidth Manager – Available (average) bandwidth: b KB/s – Wakeup frequency: f – Sends the highest priority b/f KB of data at each wakeup Choosing Chunks • The Ideal – Chunk Importance Function • Visible chunks are most important • After that, a chunk’s importance is higher the shorter the time until it could potentially be visible • The Hack (or, if you prefer, “approximation”) – Visibility Set • Currently visible or visible in the next few frames (i.e. positive time velocity) are highest priority • Currently visible or visible in the last few frames (i.e. negative time velocity) are next highest priority (why?) • All other chunks are of tertiary importance Results • Naïve implementation (oldest-data-first) for choosing chunks results in many autopauses • Visibility-guided strategy (prioritize chunks in the direction of movement higher) does better • Bandwidth-managed-importance case (very small buffer, fraction-of-a-second wakeups) produces almost no autopauses – The autopauses it does produce are short (1-2 seconds max) compared to the previous two approaches (autopauses up to 90 and up to 30 seconds, respectively) Conclusions • Cell-and-portal subdivision pays off – Size of entire model doesn’t really matter anymore – Permits subdivision into chunks and efficient grouping and prioritization of chunks • Just-in-time, near-starvation data transmission is good • Allows use of low bandwidth links (28.8 kbps modem) • Minimizes simulation delay at sudden changes in view • Walkthru/CFAST integration is a really cool idea – Leisurely walk through a burning building sounds fun – Visualization of heat or toxins in the environment – Simulation is fairly accurate (despite graphic quality)