Holodeck file byte order?

Are holodeck files byte-order dependent? If so, and I suspect it is so, can I convert them from one order to another?

Randolph

Hi Randolph,

The only files I know of that are byte-order dependent in Radiance are the depth files produced by the -z option of rpict, which are raw dumps of the 32-bit floating point numbers with no header. Holodecks should be completely portable between systems -- even more so than octrees, which have some system-dependent integer sizes which prevent them from being ported between some 32-bit and 64-bit processor architectures.

Are you having some problems sharing holodecks across machines?

-Greg

···

From: Randolph Fritz <[email protected]>
Date: Wed May 21, 2003 3:50:21 PM US/Pacific
To: [email protected]
Subject: [Radiance-general] Holodeck file byte order?
Reply-To: [email protected]

Are holodeck files byte-order dependent? If so, and I suspect it is so, can I convert them from one order to another?

Randolph

From: Randolph Fritz <[email protected]>
Date: Wed May 21, 2003 3:50:21 PM US/Pacific
To: [email protected]
Subject: [Radiance-general] Holodeck file byte order?
Reply-To: [email protected]

Are holodeck files byte-order dependent? If so, and I suspect it is so, can I convert them from one order to another?

Randolph

My apologies. Randolph is correct -- unlike other Radiance binary files, holodeck files are in fact byte-order dependent. I totally forgot about that! At one time, I intended to make them byte-order independent like other files, but the cost associated with byte-swapping on i/o is much higher for holodecks than for other file types because it is done repeatedly. Right now, holodeck "beams" are read and written with the system read() and write() calls (actually my readbuf() and writebuf() variations), which is very fast an efficient. If you add to this a byte-swapping step, you more than double the CPU cost of these operations, so supporting holodecks with different byte orders is not really a good idea.

(More comments with Randolph's messages below.)

From: Randolph Fritz <[email protected]>
Date: Wed May 21, 2003 6:41:55 PM US/Pacific
To: Greg Ward <[email protected]>
Subject: Re: Holodeck file byte order?

Did you set the binary transfer mode in ftp (or whatever you used to transfer it)? Some transfer programs will look at the first few hundred bytes of the file and decide it's a text file and use a text protocol based on the info header.

I used scp; I don't expect those behaviors with scp. Still...I'll do some checksums.

From: Randolph Fritz <[email protected]>
Date: Wed May 21, 2003 8:09:47 PM US/Pacific
To: Greg Ward <[email protected]>
Subject: Re: Holodeck file byte order?

ummmm...can a holodeck file have "holes"?

No.

From: Randolph Fritz <[email protected]>
Date: Wed May 21, 2003 10:15:17 PM US/Pacific
To: Greg Ward <[email protected]>
Subject: Re: Holodeck file byte order?

And the answer is...

getw() and putw() are byte-order dependent and rholo uses them to read and write its magic number.

And now I remember the reason for this. I wanted byte-order dependence in the magic number so I would detect when the byte-order was incompatible. What we really need then is a utility that will detect this and do an appropriate byte-swap on the file. A slight modification on the "rhcopy" program should do it, where it detects the swapped magic number and performs byte-swapping during copy. That way, we wouldn't pay the penalty during rendering of constantly swapping bytes on input and output.

I'll look into this some more next week.
-Greg

···

Begin forwarded message:

On Wednesday, May 21, 2003, at 05:38 PM, Greg Ward wrote: