Tor Olav Kristensen wrote:

>>I also read this on the documentation. Now I came across another program
>>called df3maker and it takes text version of the data and outputs the
>>binary version. I know how to create the binary file, but I have a doubt
>>regarding its format. I found the data below at the df3maker web site:
>>
>>4,3,5
>>0,50,50,0
>>50,100,100,50
>>0,50,50,0
>>10,100,100,10
>>100,200,200,100
>>10,100,100,10
>>50,150,150,50
>>150,255,255,150
>>50,150,150,50
>>10,100,100,10
>>100,200,200,100
>>10,100,100,10
>>0,50,50,0
>>50,100,100,50
>>0,50,50,0
>>
>>Ok, I understand the 4, 3 and 5, which are the dimensions of the cube in
>>x, y and z respectively. My question is how do we come up with the data
>>values? In the docs it had x*y*z, does it mean that each cell is the
>>result of multiplying x, y and z? For instance the second value 50, is
>>it the result of this multiplication?
> 
> ......
> 
> I would guess (without knowing anything about
> the text/file format for df3maker)

The format is the one shown above.

>that the
> data in the text above is organized like this:
> 
> #declare Densities =
> array [5][3][4] {
>   {
>     {   0,  50,  50,   0 },
>     {  50, 100, 100,  50 },
>     {   0,  50,  50,   0 }
>   },
>   {
>     {  10, 100, 100,  10 },
>     { 100, 200, 200, 100 },
>     {  10, 100, 100,  10 }
>   },
>   {
>     {  50, 150, 150,  50 },
>     { 150, 255, 255, 150 },
>     {  50, 150, 150,  50 }
>   },
>   {
>     {  10, 100, 100,  10 },
>     { 100, 200, 200, 100 },
>     {  10, 100, 100,  10 }
>   },
>   {
>     {   0,  50,  50,   0 },
>     {  50, 100, 100,  50 },
>     {   0,  50,  50,   0 }
>   }
> }
> 
> (I use POV syntax, because we all
> know it.)

> This would mean that the density
> within the "cell" with coordinates
> x = 0, y = 1 and z = 2 is:
> 
> Densities[2][1][0] = 150
> 
> (The value 4*3*5= 60 would be the
> number of "cells" in the cube, and
> therefore the number of densities
> in your list above.)

Hi Tor, thanks for your reply. I was having the array the other way 
round. that is densities[x][y][z]. You are right as I was looking at the 
source code of df3maker and that is how it reads the values from the file.

Now, my understanding of the cube is that we have a collection of xy 
planes for each value of z. Is that correct?

In the docs also says that the size of the cube will always be unit, 
which means that it doesn't matter the dimensions found in the df3 files 
because they all are going to be scaled to a value between 0 and 1, right?

I also read MegaPov 0.6 docs which says that it can generate df3 files.
Also that it supports 16 bits data as well as 8 bits, right? Is it still 
available on MegaPov 1.0? Anyone?


Now one last question. How does the rendering actually work? I mean is 
it similar to heightfields where the higher the value the higher its 
height? Is it how it works?


>>Another question is regarding the tga2df3 converter. How does the 2D
>>grid of pixels found in a tga picture translate to a 3D grid?
> 
> 
> This program operates on several TGA-
> pictures to make one single density
> file.
> 
> Each TGA-picture represents a cut(?)
> through the object. And the light-
> ness/darkness in the pictures repre-
> sents the denisity in the corre-
> sponding region (or "cell").
> 
> So the Width and Height dimensions
> (number of pixels in each direction)
> of the TGA-pictures represents the
> width and height of the cube con-
> taining the object. The number of
> TGA-pictures represents the depth of
> the cube.
> 
> Each picture represents a layer of
> "cells". The number of cells that
> each represents is Width*Height.
> 
> And the total number of "cells" that
> all the TGA pictures represents is
> Width*Height*NrOfPictures.
> 
> 
> So if you were to produce a density
> file for a brain, you would need many
> pictures, each of a different cut of
> a real brain.

This one is pretty clear now. Thanks for the explanation. This is what I 
was talking about above. The pictures are the xy planes which correspond 
to each value of z.
When I downloaded the software I thought that we would use a single 
image just like heightfields. That's why I was wondering how can we 
translate the values of a xy plane to a cube.

Anyway, you guys have been very helpful.

Thanks a lot.

All the best

Fidel.

Post a reply to this message