Difference between revisions of "HanProgressReportAugust08"

From Immersive Visualization Lab Wiki
Jump to: navigation, search
(→‎August/01/2008 (Wed))
 
(38 intermediate revisions by one user not shown)
Line 1: Line 1:
 
[[HanProgressReport|UP]]
 
[[HanProgressReport|UP]]
−
=== August/01/2008 (Wed) ===
+
==== Deadline ====
 +
* Aug/11/2008
 +
** new class restructuring
 +
* Sep/22/2008
 +
** deadline
 +
 
 +
==== TODO ====
 +
* PRELOADING
 +
    - preload data: load as much data as possible before starting playing, to fully utilize memory cache.
 +
    - make sure to correctly count the number of bricks that is being loaded at each frame
 +
    - load up to level 2 from level 5
 +
    - make sure the eviction takes place on old frames
 +
 
 +
* PLUGIN
 +
    - change plugin so that initialization step takes place when "load data" is selected. Now it loads everything when opencover starts
 +
 
 +
* BUGS
 +
    - it seems there's a bug in generating mesh! find and fix it!! => decided to reimplement view frustum culling, copy from a tutorial..
 +
 
 +
* THINKABOUT
 +
    - revert to memory pool instead of pixel buffer object pool..
 +
    - * re-add prefetching thread
 +
    - * implement budget based algorithm
 +
 
 +
* PERFORMANCE
 +
    * measuring performance for the following step
 +
      - LOADING, preload miss
 +
      - # bricks loaded
 +
      - # brick upper bound
 +
      - meshing generation
 +
      - rendering
 +
 
 +
      - 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)
 +
 
 +
 
 +
* 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
 +
 
 +
=== 31 Sun ===
 
----
 
----
−
* hmm
+
* reimplementing and debugging view frustum culling test
  
 +
=== 27 Wed ===
 +
----
 +
* debugging...
 +
** wrong viewport coordinates, unnecessarily large number of rendered bricks...
 +
** working on..
 +
 +
* symptom: when zoomed in, it does not show higher resolution
 +
* cause 1 for the symptom: the number of rendered brick is 40 even if only one brick is shown on the screen
 +
* cause 2 for the cause 1: to determine the visibility of a brick, I computes viewport coordinates of bricks. some of the values were negative
 +
* cause 3 for the cause 2: projection matrix seems ugly? viewport and modelview matrix have the correct values and there is no numerical issue in computing matrix-matrix multiplication and matrix-vector multiplication. Also, only the projection matrix can have negative values.
 +
* If the plane is parallel to xy-plane, it computes the correct viewport values. If tilted, it starts giving negative values. Maybe viewport computation only works when an object is perpendicular to z-axis?
 +
* Anyway, that was the reason why we have lower frame rate when we tilt the plane. Now we have better performance, although I need to further investigate why the computation is incorrect.. Also, check the performance again, rendering time must have been shortened and we have more time to spend on loading.
 +
 +
=== 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..
 +
* [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..
 +
** 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 ====
 
==== Done ====
 
* finalized the interface between MipMapVideo library and GUI part
 
* finalized the interface between MipMapVideo library and GUI part

Latest revision as of 14:04, 7 September 2008

UP

Contents

Deadline

  • Aug/11/2008
    • new class restructuring
  • Sep/22/2008
    • deadline

TODO

  • PRELOADING 
   - preload data: load as much data as possible before starting playing, to fully utilize memory cache.
   - make sure to correctly count the number of bricks that is being loaded at each frame
   - load up to level 2 from level 5
   - make sure the eviction takes place on old frames
  • PLUGIN 
   - change plugin so that initialization step takes place when "load data" is selected. Now it loads everything when opencover starts
  • BUGS 
   - it seems there's a bug in generating mesh! find and fix it!! => decided to reimplement view frustum culling, copy from a tutorial..
  • THINKABOUT 
   - revert to memory pool instead of pixel buffer object pool..
   - * re-add prefetching thread
   - * implement budget based algorithm
  • PERFORMANCE 
   * measuring performance for the following step
     - LOADING, preload miss
     - # bricks loaded
     - # brick upper bound
     - meshing generation
     - rendering

     - 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)


  • 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

31 Sun

  • reimplementing and debugging view frustum culling test

27 Wed

  • debugging...
    • wrong viewport coordinates, unnecessarily large number of rendered bricks...
    • working on..
  • symptom: when zoomed in, it does not show higher resolution
  • cause 1 for the symptom: the number of rendered brick is 40 even if only one brick is shown on the screen
  • cause 2 for the cause 1: to determine the visibility of a brick, I computes viewport coordinates of bricks. some of the values were negative
  • cause 3 for the cause 2: projection matrix seems ugly? viewport and modelview matrix have the correct values and there is no numerical issue in computing matrix-matrix multiplication and matrix-vector multiplication. Also, only the projection matrix can have negative values.
  • If the plane is parallel to xy-plane, it computes the correct viewport values. If tilted, it starts giving negative values. Maybe viewport computation only works when an object is perpendicular to z-axis?
  • Anyway, that was the reason why we have lower frame rate when we tilt the plane. Now we have better performance, although I need to further investigate why the computation is incorrect.. Also, check the performance again, rendering time must have been shortened and we have more time to spend on loading.

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..
  • 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
Retrieved from "http://ivl.calit2.net/wiki/index.php?title=HanProgressReportAugust08&oldid=2746"