> > > Hmn, would it be useful or feasible to allow POV to read .zip files
> > > directly? Are there any license restrictions on .zip compression, or any
> > > other reason this wouldn't be done?

	Having done some work in this area, I can make a few comments
	on the technical feasibility, from the point of view of the
	current POV implementation.  My basic goal was to support
	scene parsing from some kind of archived format, to increase
	the granularity of managing scenes across a network.  I got
	as far as implementing a small module that treats unix tar
	files as a virtual file system - that is, you can stuff a
	whole tree of files in a .tar and it preserves long filenames,
	case sensitivity across platforms.  (For me, Win32 and Linux,
	but in principle any platform)  The result of this work is
	currently available at:

	http://www.imp.org/members/tech/rcast/rcast.html

	The issues as far as POV-ray is concerned, are as follows:

	File opening (fopen) in POV is through one global function, 
	which can easily be extended to looking inside archives.
	This function returns a file pointer (FILE *) which means 
	that you either have to extract the file into a temporary
	file on the disk, or use an uncompressed archive such as
	TAR and a return a file pointer already positioned (fseek)
	to the right location in the archive.  However, some code
	(the truetype font impementation comes to mind) involves
	fseek, and is confused by the fact that the beginning of
	the (tar) file is not the beginning of the (ttf) font file
	inside the archive.  One solution is for the truetype code
	to work on a purely relative basis.

	Supporting compressed data I think would be nasty, because
	POV is tied to file pointers (FILE *) rather than buffers
	of data.  Java or C++ style streams come to mind as being
	a neat solution - a layer of abstraction that makes no 
	distinction between a file, console stream, a network
	socket, or a compressed file.  The most obvious work around
	is to extract the archive into temporary files, which are
	cleaned up when POV shuts down.  

	A better solution would be to implement some kind of POV
	file descriptor that provides a layer of abstraction.
	POV code would then need to use a clone of the ANSI C i/o
	API so that compressed data could be supported in a
	transparent kind of manner.

	In terms of arguments about archive format - ZIP, TAR, JAR, GZ
	you're dealing with a fragmented marketplace and a legal 
	minefield.  Gzipped TAR would seem the most logical to me,
	eventhough it still seems fairly badly supported in Windows.
	ZIP is attractive from a "follow the herd" point of view.

	To summarise - yes it can be done, but there are issues
	that would need to be considered carefully.  TAR archives
	can be supported relatively easily because they are
	uncompressed.

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer, Tokyo Dweller
"The Australian Government wants to censor your email."

Post a reply to this message