Difference between revisions of "HanProgressReportAugust08"
From Immersive Visualization Lab Wiki
(→25 Mon) |
(→25 Mon) |
||
| Line 30: | Line 30: | ||
*** with this number, there will be no benefit by prefetching.. | *** with this number, there will be no benefit by prefetching.. | ||
* [http://www.wizdforums.co.uk/showthread.php?t=1475| HDD benchmark] | * [http://www.wizdforums.co.uk/showthread.php?t=1475| HDD benchmark] | ||
| + | * [http://www.tomshardware.com/charts/hard-disks/average-read-transfer-performance,658.html| HDD benchmark 2] | ||
* Let's say we have 50MB/s bandwidth.. | * Let's say we have 50MB/s bandwidth.. | ||
** one brick is 128 * 128 * 3 byte = 48 KB | ** one brick is 128 * 128 * 3 byte = 48 KB | ||
Revision as of 20:28, 25 August 2008
Contents |
Deadline
- Aug/11/2008
- new class restructuring
- Sep/22/2008
- deadline
TODO
- 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
- 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?
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
