You mean, a matrix may have holes?
If all cells are of the same datatype, and same planecount, and row
sizes are constant between columns (etc to higher dimensions), why
would there be any holes? Or, if you're talking about the output
matrix, since it would be a 1xM matrix only the dimstride[0] matters
(which should be sizeof(datatype)*planecount). I'm only asking
because I don't understand. I wondered whether perhaps nD matrices
are actually sets of distinct 2D matrices and therefore not
contiguous in memory?
BTW an important point is that I do not need to worry about the order
of the cells (so long as the plane order remains constant), so
however the 'flattening' of the matrix re-orders them, I do not mind.
But I really would like to find a simple & efficient solution so I
can drive jit.gl.mesh (@draw_mode points) and/or jit.gl.multiple with
3D (and later n-D) matrices.
For Josh's #1 solution, wouldn't it be expensive to include modulus
terms into the expr for a 2-D simulation of 3-D, not to mention
making the expression itself a degree more difficult to read and
interact with? What I'm making is going to be for other people to
use, so I'd like to avoid unnecessary complications.
I tried to write something in C, but I think I would need to spend
quite a bit more time getting to know the Jitter SDK. Some kind of
recursive function call per dimension to copy each cell one by one
from source to destination, resulting in a 1xM matrix, seems the
solution, but I wouldn't want to do this if there is a more efficient
solution.
Thanks
On Apr 17, 2007, at 10:23 PM, Wesley Smith wrote:
> Not necessarily because of the potential difference between
>
> dim*planecount*sizeof(datatype)
>
> and
>
> dimstride
>
> data from dimension to dimension isn't guaranteed to be tightly packed
> except for within a row.
>
> wes
>
> On 4/18/07, Graham Wakefield
wrote:
>>
>> I don't get it. I thought that internally, the matrices are all
>> stored in a
>> single array, so an N-D matrix is stored sequentially, thus for
>> example a
>> [jit.matrix 3 char 2 2 2] is accessed like this:
>>
>> [[[r g b] [r g b]] [[r g b] [r g b]]] [[[r g b] [r g b]] [[r g b]
>> [r g b]]]
>>
>> but is actually stored in memory like this:
>>
>> [r g b r g b r g b r g b r g b r g b r g b r g b]
>>
>> Since the actual size of memory isn't changing, only the matrix_info
>> interface, shouldn't I be able to 'change the header' without
>> touching the
>> data?
>>
>>
>> On Apr 17, 2007, at 9:07 PM, Wesley Smith wrote:
>>
>> You can use it to do the 2D slices for you, but not a oneshot
>> conversion. At a minimum, you'll need a for loop across the 3rd
>> dimension.
>>
>> wes
>>
>> On 4/17/07, Graham Wakefield
wrote:
>>
>> Ok I see now that this won't work, because of different
>> dimstrides. So,
>> next Q: can I use _matrix_conv_info to do the dirty work, or do I
>> really
>> need to manually write out for loops?
>>
>>
>> On Apr 17, 2007, at 8:45 PM, Graham Wakefield wrote:
>>
>> Hmm, I'd like to do this efficiently. Sounds like a simple jitter
>> external;
>> but my matrix SDK knowledge is rusty...
>>
>> Can I simply pass the data from input to output
>>
>> jit_object_method(out_matrix,_jit_sym_data,in_bp);
>>
>> and change the out_minfo.dim[0] key to be equiv. in_minfo.dim[0] *
>> in_minfo.dim[1] * in_minfo.dim[2] etc., out_minfo.dimcount = 1,
>> and so on,
>> followed by
>>
>> err = (t_jit_err) jit_object_method(out_matrix, _jit_sym_setinfo_ex,
>> &out_minfo);
>>
>> Or do I need to manually copy the data in for loops?
>>
>> Thanks
>>
>> On Apr 17, 2007, at 6:40 PM, Joshua Kit Clayton wrote:
>>
>>
>>
>> On Apr 17, 2007, at 5:12 PM, Graham Wakefield wrote:
>>
>>
>> I'm trying to feed a 3D matrix (NxNxN), the output of a jit.expr,
>> as data
>> for jit.gl.multiple and/or jit.gl.mesh. Since neither multiple
>> nor mesh
>> support 3D matrices, I'm wondering if there's a way to efficiently
>> convert a
>> 3D matrix of arbitrary size to a 2D matrix (e.g. Nx(NxN)). I
>> can't figure
>> it out.
>>
>> #1, you should be able to convert your expr to a 2D expression to
>> begin with
>> (thinking of the large 2D matrix as a tiling of a 3D matrix).
>>
>> However, if that doesn't work for you, you'll probably want to use
>> jit.matrix and something like the following email client JS (or
>> patcher
>> equivalent)...watch for typos and or other oversights in the
>> following as I
>> didn't take the time to test.
>>
>> dest.adapt = 0;
>> dest.dim = [width, height*depth];
>> dest.usesrcdim = 1;
>> dest.usedstdim = 1;
>>
>> for (i=0;i
>> {
>> dest.srcdimstart = [0, 0, i];
>> dest.srcdimend = [width-1, height-1, i];
>> dest.dstdimstart = [0, i*height];
>> dest.srcdimend = [width-1, (i*height) + (height-1)];
>>
>> dest.frommatrix(source);
>> }
>>
>> Unfortunately jit.scanwrap doesn't work for > 2 dimensions, which
>> would be
>> ideal for this sort of job.
>>
>> -Joshua
>>
>> grrr waaa
>> www.grahamwakefield.net
>>
>>
>>
>>
>>
>> grrr waaa
>> www.grahamwakefield.net
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> grrr waaa
>> www.grahamwakefield.net
>>
>>
>>
>>
>>
>>
>>
grrr waaa
www.grahamwakefield.net