"scott" <sco### [at] scottcom> wrote:
> > Scott - thats good news... I dialogued with a programmer in a games forum,
> > and
> > he indicated the same thing a few minutes ago. Just to verify: you are
> > using
> > VC++Express under WinVista? (and if it matters, I am using WinVista Home
> > Premium 64 bit).
>
> I am using it mainly under WinVista Business 64bit, but also have installed
> and used it under Vista Pro 32bit and XP Pro 32bit.
>
> > There is something in the MSDN forums about problems UNinstalling
> > VC++Express
> > under Vista. Possibly (hopefully) a rare problem.
>
> Don't know about that because I have never tried to uninstall it :-)
>
> > Okay then, I will dig further into the MSDN forums, and educate myself
> > (bugs,
> > problems, work-around, etc) before I decide... looks like I juts might end
> > uop
> > downloading & installing it.
>
> Well it's always worth a try, just give it a go and see what happens.

Thanks for reply & info, Scott.

Post a reply to this message

JeffBTX wrote:
> "What you've thrown together"; can it handle 16 and 32 bit DF3s? (just

Yes. It makes two scans thru the input, first figuring out the largest X, Y, 
  Z, and voxel value, then building the right sized output file with the 
right number of bytes to hold the highest voxel.

I fear I've already screwed around too much this morning, so it might wait 
until the weekend before I can run some samples thru it just to make sure I 
didn't have any dumb bugs.

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

Warp wrote:
> (The graphical interface
> designer can only be used with C++.NET, 

The reason for that is the GUI elements are .NET components. And the 
designer looks at the metadata in the components to know how to help you 
"design" with them.  Plus, when you drop a control on the page, it actually 
invokes the code to draw itself, for example.  Not the sort of thing that's 
easy to do with native code that has no metadata in it.

Do you happen to know if it does plain C also? I was going to do this 
program in C, but then I just kind of said "screw it" and did it in Tcl.

Maybe next time I'll do it in Python just to practice. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> JeffBTX wrote:
> > "What you've thrown together"; can it handle 16 and 32 bit DF3s? (just
>
> Yes. It makes two scans thru the input, first figuring out the largest X, Y,
>   Z, and voxel value, then building the right sized output file with the
> right number of bytes to hold the highest voxel.
>
> I fear I've already screwed around too much this morning, so it might wait
> until the weekend before I can run some samples thru it just to make sure I
> didn't have any dumb bugs.
>
> --
>    Darren New, San Diego CA, USA (PST)
>    There's no CD like OCD, there's no CD I knoooow!

No problem, no rush. For me, its just a hobby - I'll be eager to download & try
it whenever.

I tried an interim solution; I still maintain a *DOS* computer. Back in 2002 or
so, I was frustrated with trying to get certain DOS games & apps that I was
rather fond of to run properly (and in some cases to run at all); "DOSBox" is
NOT an "all-in-one" solution. I contacted a local "mom & pop" computer store,
they specialize in hardware repair, and recycling old equipment into working
platforms... they have a good reputation and they are reliable. So I had a
Pentium-166 machine "built"; NO modem, initially it had 16 Mb Ram (I've since
expanded it to the max it can support, 192 Mb), initially it had an 850 Mb HD
(I've since swapped that out to a 2 Gb HD; the max that DOS recognizes), NO 3D
VidCard - just an SVGA chip w/ 2 Mb VRAM. A legacy SoundBlaster Pro 8 bit
soundcard. Etc. A 100 watt power supply (chuckle).

Installed POVRay 3.1g on the "antique" (just to fiddle around with - not
absolutely necessary for what I'm doing).

I *DO* have a couple of compilers and an assembler for that one (Borland C++
3.0, DJGPP, TASM)... so I made a short, simple program that creates a
100x100x100 8 bit DF3 (blank), total file size = 1000006 bytes, and I can
transfer that to my "mainstream" computer via 3" floppy disk (I have no other
way to move things between these two computers... so I am restricted to file
sizes of ~ 1.44 Mb or less).

Did some experiments w/ a hex editor on the 1-meg DF3 on my "modern system",
some renders in POVRay 3.6.1c. Works great so far; just did some simple
constructs "by hand", calculating the voxel coords. Next I'll write code on the
DOS machine to write data into the DF3, from textfiles as previously
mentioned... and I might fiddle with algorithms to directly model clouds and
tornadoes into the DF3 (which I *started* to do a few years ago).

So far, 100x100x100 / 1 Meg / 8 bit DF3s SEEM sufficient for clouds and
tornadoes. I might change my mind later (probably will...). If I ever get into
modeling water with DF3s (ETC) I'll certainly need something better.

BTW, I hate to be the source of misinformation; earlier in the 6th post in this
thread I said :
"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."

As it happens, thats due to interpolation, so it makes sense. If an *exact
corner* (and probably edges) are filled in a DF3, and in the DF3 statement if
interpolate 0 is specified, there are no artifacts. interpolate 1 leads to some
artifacting. interpolate 2 = "real darn wacky". So its advisable to leave
corners and edges clear, do all the "plotting" in the DF3 1 voxel away from
corners, edges and faces.

Thanks for your efforts, Darren, and I will keep an eye out for your proggy when
you get it finished - much appreciated.

Post a reply to this message

Try this
http://darren.s3.amazonaws.com/MakeDF3.zip
About 6.5 meg with the test data in it.
The big test file was made with makebigtest.tcl, which should be clear to 
any programmer even if they don't know Tcl.

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Try this
> http://darren.s3.amazonaws.com/MakeDF3.zip
> About 6.5 meg with the test data in it.
> The big test file was made with makebigtest.tcl, which should be clear to
> any programmer even if they don't know Tcl.
>
> --
>    Darren New, San Diego CA, USA (PST)
>    There's no CD like OCD, there's no CD I knoooow!

Darren; thanks, I downloaded the package and checked it out a few minutes ago.
Have NOT tried to render out of it yet... just looked at the DF3s (and was
puzzled); I think that there are minor errors, resulting in the wrong file size
for DF3s.

To review; the six byte header in a DF3 file is of the form XX xx YY yy ZZ zz.

NOTE that this is "1-base"... a 10x10x10, 8 bit (one byte per voxel) DF3 will
have the header (in hex):
00 0A 00 0A 00 0A (... or 0 10 0 10 0 10 in base 10).

A 100x100x100 8 bit DF3 header would be (in hex):
00 64 00 64 00 64

From the standard POVray distribution, check out "spiral.df3" (an 8 bit DF3, one
byte per voxel. Used by the "galaxy.pov" media example). The header is:
00 32 00 32 00 05 (in base 10, thats 0 50 0 50 0 5)
.... which is 50x50x5.
If you add it up; 50x50x5 = 12,500. Add 6 bytes for the header, = 12506. And
indeed spiral.df3 is 12,506 bytes long.

When converting XYZ coordinates into an offset for the DF3 file to set data for
a voxel, then it is ZERO-base... rather than 1-base as in the header. If you
have a 50x50x50 8 bit DF3, the header would be 00 32 00 32 00 32. BUT when
calculating coordinates-to-voxel-offset, you need to count it as 0 to 49, not 1
to 50. If an input text file then *assumes* 1 to 50, you have to subtract 1 from
each coordinate before calculating the offset. Otherwise, maybe the text file
assumes zero-to-max, so then you don't have to worry about it.

In your ZIP file, test-position.df3 has the header : 00 62 00 62 00 62
(98*98*98). Okay, 98*98*98 = 941,192. Add 6 bytes for the header = 941198. BUT
test-position.df3 is 950901 bytes long.

bigtest.df3 has a header of 00 81 00 63 00 9F, or 129x99x159. 129*99*159 =
2,030,589; so this is obviously NOT an 8 bit DF3, it looks like a 32 bit
4-byte-per-voxel DF3. Multiply 2,030,589 x 2, for a 16 bit file size. Multiply
it by 2 again for a 32 bit file size. Thats 8,122,356. Add 6 bytes for the
header, = 8,122,362. BUT bigtest.df3 is 8,173,966 bytes long.

I haven't looked at the source(s)...(yet)... but probably this has to do with
calculating the headers, probably NOT using 1-MaxDim in the headers; instead
0-MaxDim-1 was used. OR it is some other error that is occuring when
calculating coords... too many bytes are being written to the DF3s.

bigtest.df3 is 51,604 bytes too long. test-position.df3 is 9703 bytes too long.

.... hope that helps track it down...

Post a reply to this message

Darren;

.... at first I thought that the headers might be off by -1 (without bothering to
recalculate file sizes), but that doesn't work either.

I looked at the source... I don't know Tcl, but I could follow it, for the most
part. DarnIt, I'm too tired right now to trace it mentally. My eyes are red and
bleery, too much coffee and I was working on my own experiments all evening.

There are a couple of spots that "look like they might be trouble spots", but I
can't QUITE follow the logic (mentally tracing "okay, this variable is THIS, ok
now it's THIS, and then THAT happens...) - I would have to sleep on it. I can
take another look tomorrow, unless you have it figured out by then.

- Laters

Post a reply to this message

JeffBTX wrote:
> .... at first I thought that the headers might be off by -1 (without bothering to
> recalculate file sizes), but that doesn't work either.

The header may very well be off by one or some such. Basically, the range is 
from zero to whatever the largest x, y, and z in the file is. I'll have to 
look again when I'm awake and won't be dragged away at random.

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

JeffBTX wrote:
> .... at first I thought that the headers might be off by -1 (without bothering to
> recalculate file sizes), but that doesn't work either.

I found it. When it calculated the size, it returned
    x, y, z, bytes
instead of
    maxx, maxy, maxz, bytes

Now the file sizes come out to what they should be.
Files are all still indexed starting at zero.

http://darren.s3.amazonaws.com/MakeDF3.zip

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> JeffBTX wrote:
> > .... at first I thought that the headers might be off by -1 (without bothering to
> > recalculate file sizes), but that doesn't work either.
>
> I found it. When it calculated the size, it returned
>     x, y, z, bytes
> instead of
>     maxx, maxy, maxz, bytes
>
> Now the file sizes come out to what they should be.
> Files are all still indexed starting at zero.
>
> http://darren.s3.amazonaws.com/MakeDF3.zip
>
> --
>    Darren New, San Diego CA, USA (PST)
>    There's no CD like OCD, there's no CD I knoooow!

Darren;

I just downloaded it and UNZipped it a few minutes ago;

Both test-position.df3 and bigtest.df3 are the proper file size, given the
header info. So Far So Good.

I checked the voxel positions in test-position.df3. They seem to be perfect, the
offsets are what they should be and I verified with a hex editor.

So Far So Good again, congratulations, it seems to be fixed.

test-position.df3 seems to render properly, except that the 4th point; XYZ =
49,98,49 (should be "at the top" of the media cube, centered in X and Z, maxed
in Y) doesn't show up. The calculated offset is 77A16h, and indeed that offset
contains FFh / 255. It just doesn't show up when I render it (?). The other 4
voxels appear to be just fine, they are in the right position and their
relative intensities appear to be correct.

For bigtest.df3, NOTHING shows when I try to render it(?).

I dunno - I am using emission with a color of "White"... (and including
colors.inc) and using a multiplier, such as:
emission White
or
emission White*10
or
emission White*50

.... but that 4th point does not appear from test-position.df3, and bigtest.df3
appears to be just an empty transparent cube when I render it.

Odd!

I wonder (this random thought just hit me)... I wonder if voxel info from DF3's
is considered to be *SIGNED* data in POVRay (3.6.1c)? But only sometimes, for 8
bit DF3's? Why does just the 4th point not show up? That might be a clue for
bigtest.df3 appearing to be empty, if voxel values for 32 bit DF3s is
considered to be *signed data*, and POVray is seeing "negative voxels"...
dunno, I haven't looked at any of the voxel info in bigtest.df3 yet.

Also... I am noticing weird things happening with voxels at corners / edges /
faces in any case... I am dialoging on this in two other threads (New Users and
Binaries - > Images). I haven't checked for recent feedback in those sections
just yet...

I will experiment some more.

Post a reply to this message