From: Dave Akers (dla@engr.sgi.com)
Date: 11/30/2000 12:02:26
Hi Matthias,
It is possible in some cases to use external data for the brick data.
(You have the choice between calling voAppearanceActions::dataAlloc, or
simply calling voBrick::setDataPtr().) However, setDataPtr() does assume
that all of the data being provided is contiguously stored in memory. As
you point out, if your voxel data is stored in one long contiguous array,
then the data for individual bricks of this array won't necessarily occupy
contiguous regions in memory. Note that they _would_ be contiguous if you
bricked in the Z dimension only.
Another complication comes up in texture interleaving. For better
download performance and texture memory usage, Volumizer will sometimes
interleave the data contained in pairs of bricks. This is done in the
voAppearanceActions::volumeOptimize() method, which _does_ affect the
brick data itself.
If you're willing/able to keep two copies of your data in physical
memory - one for Volumizer and one for the rest of your app, then that
would be the best solution. Otherwise you can try to make things work by
bricking only in Z and making sure not to interleave the data.
It also depends somewhat on the kinds of operations you are performing
on your data. Are you modifying the texture data during your application,
or just reading it? Can the operations you are performing be done on a
brick-by-brick basis? If so you might be able to avoid the overhead of the
getVoxelAddr() method by just doing pointer arithmetic.
Lastly - are you using 2D textures or just 3D textures?
Dave
On Tue, 28 Nov 2000, Matthias Harders wrote:
> Hello,
>
> in my application I have to access the voxel data
> for additional tasks apart from the visual rendering.
> As accessing the data by "getVoxelAddr" is not very
> efficient, I would like to maintain my own voxel data
> management. I would be glad, if you could tell me, what
> the best approach to this problem is.
>
> >From my point of view, I need the following steps:
>
> * Load the 3D data into my own memory structure
> (probably a long one-dimensional array). The data
> should be stored in x,y,z order.
>
> * Use Volumizer to determine the correct brick sizes, etc.
>
> * To get the pointer to the data, replace in the function
> "myReadBrickIfl" the line
>
> sts = file->getTile(xBrickOrigin, yBrickOrigin, iz,
> xBrickSize, yBrickSize, 1, ptr, &cfg);
>
> with my own code, that finds the pointer to the requested
> data in my memory structure. Unfortunately, there might
> be a problem, if the brick requests sizes, which are only
> a part of the full x,y length.
>
> Do you think, this is the right approach? Is Volumizer
> internally changing any of the data that is sent to a brick
> or can I still use it for my other calculations?
>
> Any input you could give me on this issue is greatly
> appreciated.
>
> Thank you,
>
> Matthias Harders
>
> --
>
> ---------------------------------------------------------------------
> Matthias Harders M. Sc. Computer Science
> Gloriastrasse 35, Room F81 Communication Technology Lab
> CH-8092 Zuerich Image Science Group
> Switzerland ETH Zuerich
> Tel. ++ 41 1 632 52 79 Fax ++ 41 1 632 11 99
> ---------------------------------------------------------------------
>
This archive was generated by hypermail 2b29 : Thu Nov 30 2000 - 13:46:46 PST