Darren New <dne### [at] sanrrcom> wrote:
> JeffBTX wrote:
>
> Boop me some test files and I'll give what I've written a whirl.
> Right now my code assumes you start at offset zero, not one, and that each
> line has four values on it (x,y,z,v). Bop me a test file like that and I'll
> see what comes out, then pass you the code when it's working.
>
> > I've checked on Microsoft Visual C++ Express. Free, but you have to register it
>
> You don't have to register it, by the way.
>
>
> --
>    Darren New, San Diego CA, USA (PST)
>    There's no CD like OCD, there's no CD I knoooow!

Ooops - Thanks, Darren, I don't have any test files at the moment, but I'll post
something off-the-top-of-my-head (what was THAT doing up there?) in a moment.

I am getting back into POVRay after a long hiatus (actually just started
yesterday), using: "version 3.6.1.msvc8.win64". Previously, I used POVRay 3.5
on an older machine (WinME). I've had this computer since 2007 (Win Vista Home
Premium 64). I am just now getting back into it; when I lost my previous
computer in an accident, I had started some work modeling tornadoes with .DF3
files.

The procedure I am using (at present, with a calculator (for hex conversion) and
a *hex editor* of all things);

The offset into the DF3 is x + (y*MaxDim) + (z*MaxDim*MaxDim) + 6 (6 for the DF3
header)
.... if using "zero base" coords (zero to Max Dimension-1, versus 1 to MaxDim),
assuming a symmetrical cube shape (otherwise for 1-base, it is (x-1) +
((y-1)*MaxDim) + ((z-1)*MaxDim*MaxDim) + 6).

Doing it this way the render of a DF3 is *exactly* as visualized (x = LeftRight,
y=UpDown, z=ForwardBack). (I think the TGA2DF3 utility "reverses" an axis in an
unexpected way, if I recall... its been a while since I used it. Not a BIG
problem.... ). Orientation was one of my concerns when I started experimenting
yesterday morning.

BUT because of my limitations (no compiler) I've only used 10x10x10 and
100x100x100 DF3s in my first couple of experiments.

A simple test, though... for say, a 100x100x100 DF3 (8 bit) ... to test
orientation, play with density a little (this will be zero based; coords 0 to
99, 8 bit data values);

1,1,1,127
3,1,1,64
49,49,49,255
49,98,49,255
98,98,98,32

.... so that is 1 voxel away from the forward left corner and 1 away from the
front face... then a blank voxel to the right, and then another voxel; density
127 and 64

.... a voxel in the middle and one on "on top", full density.

.... and finally a somewhat faint density 32 voxel that is 1 away from the back
right corner.

The reason for NOT putting pixels AT corners and edges is that I've noticed
artifacts... a kind of "edge-wrapping"/"bleeding" that occurs if you place a
voxel in a corner (and I assume an edge). The "opposite" corner also shows some
density, when it shouldn't. This is another topic, and I've thought about
posting / asking about it, but it's obvious what is happening.

"What you've thrown together"; can it handle 16 and 32 bit DF3s? (just
curious... most of the time of course 8 bit would be used, and 8 bit is
suitable for almost every purpose. Perhaps all purposes. I'm not experienced
enough yet).

-Thanks
- Jeff

Post a reply to this message