HanProgressReportAugust08
From Immersive Visualization Lab Wiki
Contents |
Deadline
- Aug/11/2008
- new class restructuring
- Sep/22/2008
- deadline
TODO
- automatic adjustment of # of bricks loaded at each frame
- revert to memory pool instead of pixel buffer object pool..
- re-add prefetching thread
- implement budget based algorithm
- mipmapped video support
* measuring performance for each step
- find bottlenecks
- with preloaded data: 40~50 fps, 0.025 ~ 0.02 sec/frame
- without preloading: around 10 fps, 0.1 sec/frame....:(
* prefetching next frames
* point of interest (check paper again)
* prefetching bricks?
* test on starcave by this weekend
- multi-volume support
* mesh generation - generating a mesh for multivolumes under one constraint - memory size
* rendering - multi-volume rendering
o new rendering algorithm: need to manage multi bricks overlaps with several bricks!
* time-series multivolume rendering - need to handle multi timesteps
26 Tu
- 65MB/s in a starcave node
- 11 bricks / frame
- implemented a new algorithm to dynamically adjust the total number of bricks rendered at each frame
- if the current frame rate is high enough, we increase the number of bricks
- if the current frame rate is low enough, we decrease the number of bricks
- with the algorithm, flickering due to the frequent changes of the number of bricks happens..
- the parameter, how much we should increase/decrease the number, needs some tuning....
25 Mon
- Measured data loading time: 0.1 sec/frame reading O(10) bricks
- wrote a short program reading sequentially
- took 137 seconds for 6.5GB, 1200 files of multi-resolution tornado data
- 47MB/s :(
- tested with files in local disk
- with this number, there will be no benefit by prefetching..
- wrote a short program reading sequentially
- HDD benchmark
- HDD benchmark 2
- Let's say we have 50MB/s bandwidth..
- one brick is 128 * 128 * 3 byte = 48 KB
- 50MB/s/(30 frames/s) = 1.66MB/frame = 34 bricks / frame if we *only* consider loading time..
- Assume we need 0.025 second / frame for rendering + all the other steps
- to achieve 30 frames / second, rendering time will take 0.75 seconds, what is left (0.25 seconds) can be used for data loading
- as the data loading time is 4 times smaller than the first case,
- 34 bricks/frame/4 = 8 bricks / frame
12 Tues
- we can control the quality of image rendered
- parameterize voxel to pixel ratio
- parameterize the total number of bricks loaded at each frame
- need more performance measurements...
10 Sun
- reimplemented covise plugin with the new MipMapVideoLib
- tested on covise
- 30 fps when cached
- below 10 fps when first played
09 Sat
- tested with 750 frames
- 2M pixel screen
- horrible performance 3~5 fps without caching
- second run (with cache) achieves around 30~50 frames per second
08 Fri
- debugged the bug
- tested with 200 tornado data frames and it plays interactively
- nearest neighbor interpolation causes lots of aliasing especially on lines and edges
- no prefetching or asynchronous I/O was used
- trying to come up with an algorithm that limits the total number of bricks loaded at each frame
- heuristic. there can be a smarter algorithm than one in octreemizer..
- don't know how much this would impact the overall performance
- generating 600 frames
07 Thur
- refine and debug frame window
- debugging frame window..
- data isn't changing...
06 Weds
Done
- generated tornado tiff data sets
- implemented frame window - need test!!!!!
- opening next 10 frames
- closing previous 10 frames
- activating/deactivating BrickReaders
- grpof to find bottlenecks
- no bad calls, which means my system is IO bounded. =(
August/05/2008 (Tu)
- multi-volume support
* user interface - need to be able to manipulate one volume at a time * new class structures? like in virvo/multirend
- dynamic change in volume control UI
- hide/show according to volume selection
August/01/2008 (Fri)
Done
- finalized the interface between MipMapVideo library and GUI part
