 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
As a result of some discussion on the IMP
technical discussion list, there has been
some preliminary investigation into
supporting TAR archives from POV.
The advantages are:
Minimal POV installation - povray.exe, includes.tar
Modularisation of large pov scenes.
Modularisation of libraries.
Download-and-render without extraction.
Technical Issues
Support compression?
Parsers that use fseek?
I've attached more detailed discussion.
Your comments or interest are invited.
------------------------------------------------------
Date: Tue, 02 Feb 1999 15:15:40 +1100
From: Nigel Stewart <nig### [at] eisa netau>
Subject: Re: [TECH] Proposal - PVA Fileformat Specification
>>> The PVA (PovRay Archive) fileformat is proposed
>>> as a means of modularisation of POV scene
>>> files.
TarFs, ExTar
----------------------------------------------------
TarFs is a C++ class representing a tar archive.
FILE *TarFs::file(char *filename,const char *mode = "rt")
Create a C FILE pointer to read a file from the
tar archive.
istream *TarFs::istream(char *filename,ios_base::openmode mode = ios::in)
Create a C++ input stream object to read a file from
tar archive.
----------------------------------------------------
Extar is a command-line program to extract a file
within tar archive to standard output.
For Example:
C:\Data\Nigel\devel\tarlib>tar cvf test.tar tmp
tmp/
tmp/test.txt
tmp/test2.txt
C:\Data\Nigel\devel\tarlib>extar test.tar
tmp/test.txt
tmp/test2.txt
C:\Data\Nigel\devel\tarlib>extar test.tar tmp/test.txt
Hello World
C:\Data\Nigel\devel\tarlib>
----------------------------------------------------
Applications -
PovRay support for concept of library.
IMP datafile encapsulation.
Game datafile supporting read-only random access.
Email datafile supporting arbitrary append.
Virtual read-only filesystem for Linux.
Tar archive browsing for WWW. (CGI ExTar)
-------------------------------------------------------------------------
Date: Thu, 04 Feb 1999 01:17:49 +1100
From: Nigel Stewart <nig### [at] eisanetau>
Subject: [TECH] POV Support for TAR Filesystem
I had a quick-hack attempt at supporting tar
files from POV-ray. It works nicely, except
for TTF fonts, which are parsed using fseek. (**)
POV, INC and PNG files within tar files have
worked without a hitch.
What does all this mean?
Well, it means that a 'minimalist' POV install
is one .exe file, plus one .tar file with all
the include files. There is no dependency on
environment variables, or registry settings
to find libraries - which makes it easy to
install, zero configuration, and no
interaction with other POV installations.
Also, a renderfarmer only needs to download
ONE tar archive into the directory to
start rendering. (Plus a command line,
which can be in the TAR as well...)
So, my conclusion is that having a custom
IMP POV compilation is feasible, has real
advantages, (we can use any patches that we
like) and is likely to have minimal impact
on render farmers. It is also very portable.
My 0.02 for today.
(Oh, and hacking around in the POV source
is pretty educational/interesting too!)
(**) TarLib provides a file pointer
offset to the correct location in
the TAR file, but using fseek
can depend on offset zero being
at the start of the file, rather
than start of Tar file.
---------------------------------
| | scene.pov | ...
----------------------------------
^
\ beginning of "scene.pov"
^
\ fseek is relative to tar file
--------------------------------------------------------------------
Date: Thu, 04 Feb 1999 20:54:29 +1100
From: Nigel Stewart <nig### [at] eisanetau>
Subject: Re: [TECH] POV Support for TAR Filesystem
TAR Files
---------
Generic. Tar has a long history, is well supported,
and well understood. The actual format of
the headers are weird, but proven.
Simple. Tar is a "chunked" format, files are stored
contiguously and uncompressed.
Compression
-----------
Directly supporting compressed archives is undesirable
in terms of simplicity and efficency. Fancy languages
like Java or C++ allow you filter streams, so that
decompression is hidden from the parser. I do not
know of a clean and efficient way of doing this in
C. (Either parse from memory buffer, or extract file
to temporary directory on the fly).
Also, it's worth considering that POV already supports
compressed files such as PNG.
Also, do we want to spend CPU time on decompression
for every frame of animation?
Also, would it more appropriate to support POV parsing
of .pov.gz (".pgz") or .inc.gz (".igz"), independent
of tar file support?
In summary - We can do it, but do we WANT to do it?
Portability of JAR
-------------------
JAR is portable in the sense that it works on any
Java supported platform. TAR is portable in the
sense that things like WINZIP support it. My
impression is that the average raytracer is going
to be equally unfamiliar with TAR and JAR.
If compression is appropriate to the application,
let's use JAR. However, I do not think there
will be a good return on the investment of time
and energy.
Perhaps there is someone from the broader
POV community who would do the work on
zlib-based compression. Would anyone
object to making a report to pov.programming?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
> As a result of some discussion on the IMP
> technical discussion list, there has been
> some preliminary investigation into
> supporting TAR archives from POV.
>
>
>
> Portability of JAR
> -------------------
>
> JAR is portable in the sense that it works on any
> Java supported platform. TAR is portable in the
> sense that things like WINZIP support it. My
> impression is that the average raytracer is going
> to be equally unfamiliar with TAR and JAR.
>
> If compression is appropriate to the application,
> let's use JAR. However, I do not think there
> will be a good return on the investment of time
> and energy.
>
> Perhaps there is someone from the broader
> POV community who would do the work on
> zlib-based compression. Would anyone
> object to making a report to pov.programming?
Just to help clarify things a little, JAR files are mainly just ZIP files
that are constrained not to use the patented compression. They only use the
zlib compression (which happens to be included in POV-Ray already). Thus any
JAR file is a valid ZIP file, and can be created and accessed with standard
tools.
To further help things, although there is no RFC or such on .ZIP files, but
PKWare does have an application note describing the format.
See http://www.pkware.com/appnote.html
Just use that along with the info on the JAR format itself:
http://java.sun.com/products/jdk/1.2/docs/guide/jar/index.html
One issue to note is the manifest file that is optionally present.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I guess I missed something. For the most part I don't see the point.
There are shell-out calls that you can use for this stuff in your ini
files. I do it all the time for animations. Most of what you described
can be done with pre- and -post -frame and -scene commands.
The cool thing is the idea of putting all the standard .inc files, etc.
into
one big file (kinda like a library file?) But then you'd either have to
have
a double call (#include "textures.inc" from pov_official.jar vs.
#include "cooltext.inc" from funky_stuff.jar) or else still have a
library path
type thing, only make it intelligent enough to search through all the
.jar's,
tar's, tgz's, tar.gz's, tar.bz2's, .zip's and God knows what else people
might
come up with that is public domain.
It seems that most of what you want is already there with the
shell-outs, and
people can use whatever they have on their system that way.
But then, I've probably missed the point, as I often do.
My 2 Canadian cents worth.
--
Carl Bartels, Department of Chemistry, Mcgill University, to reply to
me,
just kill a and 5 from the email name, Montreal, QC, cAnAdA
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>I guess I missed something. For the most part I don't see the point.
Okay, here are the major advantages:
* Totally portable file-names, time/date, integrity checking.
* Easier management for 3rd party modules.
* Ability to take a fully-functional pov source snap-shot.
* Simpler installation, less registry/variable dependence. (*)
The filename resolution issue is not yet resolved.
At the moment, POV simply looks in the current
directory and treats each tar file as an entry in
the library path. This might not be the best policy -
I'm still thinking about it... The intention is to support
this transparently - it should make no difference
if you are rendering from a real filesystem or a
tar filesystem.
Compression is under consideration - Pov already
includes the zlib library, so gzip or JAR support would
not introduce much new code. My feeling is that
a case needs to be made for the parse-time expense
vs. space savings. Also, it might be cleaner to support
compressed pov/inc as preferrable to compressing an
entire archive.
(*) I'm considering a way to include the standard includes
and a few test scenes into the povray binary, so that the
minimal povray install is one file. Copy-and-run. Delete to
uninstall. (Life should always be so simple.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I did miss something. sorry.
Nigel Stewart wrote:
>
> Okay, here are the major advantages:
>
> * Totally portable file-names, time/date, integrity checking.
This would be great.
> * Easier management for 3rd party modules.
> * Ability to take a fully-functional pov source snap-shot.
> * Simpler installation, less registry/variable dependence. (*)
I'm tempted to start a flame war but won't. Lets just say that I
strongly agree with any move to reduce the use (direct or indirect) of
registry files Regedit on the few occasions when I do boot my computer
into Windows. Of course, .rc files can be a pain on Linux too.
> The filename resolution issue is not yet resolved.
> At the moment, POV simply looks in the current
> directory and treats each tar file as an entry in
> the library path. This might not be the best policy -
> I'm still thinking about it... The intention is to support
> this transparently - it should make no difference
> if you are rendering from a real filesystem or a
> tar filesystem.
OK. If you tar a directory tree, do the subdirectory levels get
searched. If so, are they treated as subdirs? Here's what I mean...
You want to make a tar of a whole tree you've made and nicely organized
that looks like this:
/include
/include/incs
/include/pots
/include/maps
/include/maps/hot
/include/maps/cold
/include/ttfs
/include/df3s
Would a file in /include/maps/hot be treated as being in a subdirectory
of a subdirectory or would it just get treated as a file with /'s in
it's name? I'd advocate the later. It may sound nuts to have subdirs
in a library tar like that, but I'm sure someone will try it.
BTW, how does tar (gpl'd I think) get along with POV license-wise?
> Compression is under consideration - Pov already
> includes the zlib library, so gzip or JAR support would
> not introduce much new code. My feeling is that
> a case needs to be made for the parse-time expense
> vs. space savings. Also, it might be cleaner to support
> compressed pov/inc as preferrable to compressing an
> entire archive.
There was an earlier thred about making a binary file format of parsed
scenes. It would be kinda cool if that goes of to put parsed .inc files
into the tar. That way, you kill a whole pile of parse time for anyone
who includes a lot of stuff from these.
Three more potential problems...
1) Documentation: If all the includes come as one big tar (or
whatever) file, then people won't be able to peruse them the way they
can now so a whole new pile of documentation will have to made available
stating what's in each include file. (Big PITA when it comes to stuff
like shapes.inc) It may require some sort of standardization of the
include files. (I'd be willing to volunteer for that). Personally, I
don't use the standard includes much anymore, but they were an
increadable help when I was learning back on POV 2.whateveritwas. The
loss of the ability to see their guts would be a big blow to new users.
2) Home-brews: There'd have to be some sort of utility (hardwired into
POV or released separately) so that people could make their own
modules. And of course, it would have to work on several platforms.
3) Conflicts: Suppose you define Big_red_texture in one .inc file and
then redefine it in another one later. You then put both of them in the
tar. Depending on how you do file resolution this could confuse either
pov or the user (either pov will freak, or else 50% of the time the user
will not get what they wanted because it took Big_red_texture from the
other .inc)
Well, now that I've said all that...I like the idea afterall. If you
want someone else to test a patch on Linux, let me know.
Cheers!
--
Carl Bartels, Department of Chemsitry, Mcgill University, to reply to
me,
just kill a and 5 from the email name, Montreal, QC, cAnAdA
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 09 Feb 1999 19:12:44 -0500, Carl Bartels
<cab### [at] bravo436chemmcgillca> wrote:
>BTW, how does tar (gpl'd I think) get along with POV license-wise?
GPL doesn't get along well with POV at all. GLPL looks like it might
be compatible. But IIRC, the idea was to start with the documentation
for the tar file format and go from there, not using any preexisting
code.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>BTW, how does tar (gpl'd I think) get along with POV license-wise?
As Ron Parker suggests, TAR is simple enough that the parsing code
is pretty simple. My licencing terms are even lefter than GPL - basically
no restrictions at all - Pov team can treat my work as they see fit.
I've used C++, which may be an issue - But I'm working in a
experimental/prototype mindset - I'll surrender STL only
for a real good reason.. :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> The filename resolution issue is not yet resolved.
>
>OK. If you tar a directory tree, do the subdirectory levels get
>searched. If so, are they treated as subdirs?
Yes, as it stands, subdirectories are treated properly.
For example, I've bundled the Galaxy include file
into a tar:
N:\devel\Pov31b>tar tvf galaxy.tar
drwxrwxrwx 0/0 0 Feb 07 00:56 1999 galaxy/
-rw-rw-rw- 0/0 2242 Aug 09 00:00 1998 galaxy/AllObjs.pov
-rw-rw-rw- 0/0 885 Aug 09 00:00 1998 galaxy/DnmcOpts.pov
-rw-rw-rw- 0/0 11395 Aug 09 00:00 1998 galaxy/GALAXY.BG
-rw-rw-rw- 0/0 42412 Aug 09 00:00 1998 galaxy/Galaxy.htm
-rw-rw-rw- 0/0 9780 Feb 05 14:51 1999 galaxy/GALAXY.INC
-rw-rw-rw- 0/0 35742 Aug 09 00:00 1998 galaxy/GALAXY.OBJ
-rw-rw-rw- 0/0 3884 Aug 09 00:00 1998 galaxy/GALAXY.SF
-rw-rw-rw- 0/0 1025 Feb 07 00:58 1999 galaxy/Rand.ini
-rw-rw-rw- 0/0 339 Feb 07 00:21 1999 galaxy/Rand.pov
-rw-rw-rw- 0/0 1048 Aug 09 00:00 1998 galaxy/Readme.txt
-rw-rw-rw- 0/0 1481 Aug 09 00:00 1998 galaxy/Trifid.pov
From the command line:
povray +Igalaxy/Trifid.pov +w630 +h480 +OTrifid
There is a bit of a catch though, to put files in a subdirectory,
each pov/inc needs to look for "galaxy/galaxy.inc" rather than
just for "galaxy.inc". It's my thought that POV should also
search the directory of the _current file_ to more easily
support this kind of modularisation.
>1) Documentation: If all the includes come as one big tar (or
>whatever) file, then people won't be able to peruse them the way they
>can
Yes I agree this is a draw-back. You can browse the tar with
Winzip.... But what would be really nice would be a hyperlinked
and indexed version of the standard includes, as HTML or
windows HLP. It makes me grumpy to search for the include
directory in windows, and a man page or java-doc style solution
would be much more useful. (And complement the
existing documentation very nicely)
>2) Home-brews: There'd have to be some sort of utility (hardwired into
>POV or released separately) so that people could make their own
>modules. And of course, it would have to work on several platforms.
Any port of command-line tar will. It's not a job
we need to worry about.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Nigel Stewart" <nigels> wrote:
: There is a bit of a catch though, to put files in a subdirectory,
: each pov/inc needs to look for "galaxy/galaxy.inc" rather than
: just for "galaxy.inc". It's my thought that POV should also
: search the directory of the _current file_ to more easily
: support this kind of modularisation.
Section 6.2.3.2
Library Paths
Library_Path=path Add path to list of library paths
+Lpath Same as Library_Path=path
POV-Ray looks for files in the current directory. If it does not find a
file it needs it looks in various other library directories which you
specify. POV-Ray does not search your operating system path. It
only searches the current directory and directories which you
specify with this option. For example the standard include files are
usually kept in one special directory. You tell POV-Ray to look
there with...
Library_Path=c:\povray3\include
You must not specify any final path separators ("\" or "/") at the end.
Multiple uses of this option switch do not override previous
settings. Up to ten unique paths may be specified. If you specify the
exact same path twice it is only counts once. The current directory
will be searched first followed by the indicated library directories in
the order in which you specified them.
--
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11 Feb 1999 15:06:30 -0500, Nieminen Mika <war### [at] cctutfi> wrote:
>"Nigel Stewart" <nigels> wrote:
>: There is a bit of a catch though, to put files in a subdirectory,
>: each pov/inc needs to look for "galaxy/galaxy.inc" rather than
>: just for "galaxy.inc". It's my thought that POV should also
>: search the directory of the _current file_ to more easily
>: support this kind of modularisation.
>
>POV-Ray looks for files in the current directory. If it does not find a
>file it needs it looks in various other library directories which you
>specify.
There's a difference between "directory of the current file" and
"current directory". If I have this directory structure:
.:
-rw------- foo.pov
drwx------ Includes/
Includes:
-rw------- bar.inc
-rw------- baz.inc
and foo.pov #includes "Includes/bar.inc" and bar.inc #includes
"baz.inc", it would be nice if POV would first look in the
directory in which bar.inc resides (i.e. ./Includes/) when looking
for baz.inc. I believe this is how my C compiler does it, except
that it probably doesn't look in ./ at all.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
