Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>if the 3D canvas has a fixed size you won't win much by using containers. I would avoid allocating the matrix in small chunks as you do, though, and just instead do</p> <pre><code>#define DIM_X 5 #define DIM_Y 12 #define DIM_Z 27 #define SIZE (DIM_X * DIM_Y * DIM_Z) #define OFFS(x, y, z) (x + y * DIM_X + z * (DIM_Y * DIM_X)) </code></pre> <p>and then</p> <pre><code>class 3DImage { private unsigned int pixel_data[SIZE]; int &amp; operator()(int x, int y, int z) { return pixel_data[OFFS(x,y,z)]; } } </code></pre> <p>after which you can do e.g.</p> <pre><code>3DImage img; img(1,1,1) = 10; img(2,2,2) = img(1,1,1) + 2; </code></pre> <p>without having any memory allocation or algorithm overhead. But as some others have noted, the choice of the data structure also depends on what kind of algorithms you are planning to run on the images. You can always however adapt a third-party algorithm e.g. for matrix inversion with a proper facade class if needed; and this flat representation is much faster than the nested arrays of pointers you wrote.</p> <p>If the dimensions are not fixed compile time, you can obviously still use exactly the same approach, it's just that you need to allocate pixel_data dynamically and store the dimensions in the 3DImage object itself. Here's that version:</p> <pre><code>class 3DImage { private unsigned int *pixel_data; unsigned int dim_x, dim_y, dim_z; 3DImage(int xd, int yd, int zd) { dim_x = xd; dim_y = yd; dim_z = zd; pixel_data = new int[dim_x * dim_y * dim_z]; } virtual ~3DImage() { delete pixel_data; } int &amp; operator(int x, int y, int z) { return pixel_data[x + y * dim_x + z * dim_y * dim_x]; } } </code></pre>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload