Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Hi TAN TOH FEI, > I tried to render a volume graphics in my Unix workstation (512MB memory). > The best resolution I can get is 128x128x128 voxels (float data type). If I > try to use 256x256x256 voxels, the system gave me the "OutOfMemory" > Exception. > > I execute my program as below: > > % Java -mx384m myprogram > > Note: I did try with different memory number such as 448, 256 etc. > > According to my calculation (float data is 4 bytes), memory needed should be > (256 x 256 x 256 x 4) = 64MB. > > Can anyone help me in this context? No major programs are being executed at > the background of the workstation. Volume rendering must store the pixels in six different organizations, which it switches between as you rotate the volume. If you watch closely as you rotate in Test61 you'll see it switch. So you really need 6 * 64MB = 384MB. The memory inefficiency of the old versions of Java3D may even double that. Once the Java3D team gets the bugs out of version 1.2.1, hopefully we'll be able to use its better memory management features. Cheers, Bill ---------------------------------------------------------- Bill Hibbard, SSEC, 1225 W. Dayton St., Madison, WI 53706 hibbard@xxxxxxxxxxxxxxxxx 608-263-4427 fax: 608-263-6738 http://www.ssec.wisc.edu/~billh/vis.html
visad archives: