 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>There's a difference between "directory of the current file" and
>"current directory".
Yes, that is exactly what I'm talking about. POV currently
has a policy that everything should be in the library include
path, but if you have a filename collision, the resolution
strategy is not well defined. I think using
#include "std/colors.inc"
#include "foo/colors.inc"
Is better than being careful to name files carefully to avoid
collision. Files included from "std/colors.inc" should be
taken from the "std" directory in preference to anywhere
else. This improves the prospect of proper modularisation
of POV scenes and libraries.
I don't think C works this way, but I think it is the way
that POV-ray _should_ work... :-)
In order of preference, POV searches the following
directories for an included file:
1. The directory of the current file.
2. The current directory.
3. Each directory in the list of library directories.
Which is the same policy as present, with (1) inserted.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Here is an example run of povray on Windows NT,
using tar filesystems, and determining the
complete dependency set of the scene. You can
see some recent screen shots on:
http://www.imp.org/members/scene/test_a/scripta.html
-------------------------------------------
bash-2.02$ ls *.tar
galaxy.tar planets.tar planetss.tar spline.tar
include.tar planetsl.tar scenes.tar
bash-2.02$ ls *.exe
ExTar.exe Pal2PovColour.exe PovRay.exe PovRayD.exe
bash-2.02$ nice ./povray -Iscripta
Persistence of Vision(tm) Ray Tracer Version 3.1a.unsupported
Unofficial version compiled by:
Nigel Stewart (nig### [at] eisa netau)
The POV-Ray Team(tm) is not responsible for supporting this version.
Copyright 1998 POV-Ray Team(tm)
[snip]
Parsing.........
[snip]
Rendering...
[snip]
Dependencies:
------------------------------------------------------
ScriptA.spl
SolarSys.inc
colors.inc
galaxy/GALAXY.BG
galaxy/GALAXY.OBJ
galaxy/GALAXY.SF
milkyway.inc
planets/EthMapS.png
planets/JupMapS.png
planets/MarMapS.png
planets/MerMapS.png
planets/MooMapS.png
planets/NepMapS.png
planets/PluMapS.png
planets/SatMapS.png
planets/UraMapS.png
planets/VenCldS.png
planets/VenMapS.png
planets/planets.inc
scripta.pov
skies.inc
spline/Spline.inc
title2.inc
------------------------------------------------------
Reclaiming memory
bash-2.02$
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
There is now a web-page describing "Imp Pov", a povray 3.1
compilation with a few extra features for network rendering.
http://www.imp.org/members/tech/rcast/rcast.html
Binaries for Win32 and Linux are available.
Features:
* Passive render-farm mode "+N" for rendering farming
The network rendering mode waits for configuration files in INI
format to be placed in the incoming directory. Outputs are placed
in the outgoing directory.
* TAR file as read-only file-system
Packing scene files into a TAR archive allows long filenames, and
case sensitive filenames across every platform. It also simplifies
scene distribution, and allows modules to be packaged and
distributed conveniently.
* Automatic scene dependency reporting
Pov-ray will report the set of files required to render a scene.
Ultimately, this feature will be developed to provide render
farmers with the minimal set of files required for a each frame of
animation.
* Command-line interface
No user interface is included for the sake of portability. It
should be simple to layer a GUI on top of the network rendering
mode, by manipulating the file queues and writing some state
information to a file from povray.
* Different directory searching policy
Currently, pov requires every directory to be included in the
library search path in order to find include files. IMP POV
implements a 'relative to current file' search, so that files in
the same directory as the current one are found first. This means
you can include a module using an absolute path: #include
"galaxy/galaxy.inc" and files it depends on this will be expected
in the galaxy directory.
This reduces the amount of library configuration, and also reduces
the chances that included filenames will collide. (For example, a
local "colors.inc" vs the global "colors.inc")
--
Nigel Stewart (nig### [at] eisanetau) http://www.eisa.net.au/~nigels/
Postgrad Research Student, RMIT University, Melbourne, Australia
All extremists should be taken out and shot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
There is now a web-page describing "Imp Pov", a povray 3.1
compilation with a few extra features for network rendering.
http://www.imp.org/members/tech/rcast/rcast.html
Binaries for Win32 and Linux are available.
Features:
* Passive render-farm mode "+N" for rendering farming
The network rendering mode waits for configuration files in INI
format to be placed in the incoming directory. Outputs are placed
in the outgoing directory.
* TAR file as read-only file-system
Packing scene files into a TAR archive allows long filenames, and
case sensitive filenames across every platform. It also simplifies
scene distribution, and allows modules to be packaged and
distributed conveniently.
* Automatic scene dependency reporting
Pov-ray will report the set of files required to render a scene.
Ultimately, this feature will be developed to provide render
farmers with the minimal set of files required for a each frame of
animation.
* Command-line interface
No user interface is included for the sake of portability. It
should be simple to layer a GUI on top of the network rendering
mode, by manipulating the file queues and writing some state
information to a file from povray.
* Different directory searching policy
Currently, pov requires every directory to be included in the
library search path in order to find include files. IMP POV
implements a 'relative to current file' search, so that files in
the same directory as the current one are found first. This means
you can include a module using an absolute path: #include
"galaxy/galaxy.inc" and files it depends on this will be expected
in the galaxy directory.
This reduces the amount of library configuration, and also reduces
the chances that included filenames will collide. (For example, a
local "colors.inc" vs the global "colors.inc")
--
Nigel Stewart (nig### [at] eisanetau) http://www.eisa.net.au/~nigels/
Postgrad Research Student, RMIT University, Melbourne, Australia
All extremists should be taken out and shot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Um, Nigel, sir? Did you forget this needs a ID and password to get in?
Or did you realize that when you posted this URL...? ;)
Nigel Stewart wrote:
>
> There is now a web-page describing "Imp Pov", a povray 3.1
> compilation with a few extra features for network rendering.
>
> http://www.imp.org/members/tech/rcast/rcast.html
>
> Binaries for Win32 and Linux are available.
>
> Features:
>
> * Passive render-farm mode "+N" for rendering farming
> The network rendering mode waits for configuration files in INI
> format to be placed in the incoming directory. Outputs are placed
> in the outgoing directory.
> * TAR file as read-only file-system
> Packing scene files into a TAR archive allows long filenames, and
> case sensitive filenames across every platform. It also simplifies
> scene distribution, and allows modules to be packaged and
> distributed conveniently.
> * Automatic scene dependency reporting
> Pov-ray will report the set of files required to render a scene.
> Ultimately, this feature will be developed to provide render
> farmers with the minimal set of files required for a each frame of
> animation.
> * Command-line interface
> No user interface is included for the sake of portability. It
> should be simple to layer a GUI on top of the network rendering
> mode, by manipulating the file queues and writing some state
> information to a file from povray.
> * Different directory searching policy
> Currently, pov requires every directory to be included in the
> library search path in order to find include files. IMP POV
> implements a 'relative to current file' search, so that files in
> the same directory as the current one are found first. This means
> you can include a module using an absolute path: #include
> "galaxy/galaxy.inc" and files it depends on this will be expected
> in the galaxy directory.
> This reduces the amount of library configuration, and also reduces
> the chances that included filenames will collide. (For example, a
> local "colors.inc" vs the global "colors.inc")
>
>
> --
> Nigel Stewart (nig### [at] eisanetau) http://www.eisa.net.au/~nigels/
> Postgrad Research Student, RMIT University, Melbourne, Australia
> All extremists should be taken out and shot.
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/homepage.htm
mailto:inv### [at] aolcom?Subject=PoV-News
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Carl Bartels wrote:
> 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
AFAIK future zlibs will understand .bz2.
IIRC the tar interface (which I don't know) would just have
to call "gzopen" instead of "open", the [de]compression would
then happen transparently. I have no idea whether zlib provides
all the other stream-related functions that the tar interface
needs.
I'd say that .jar and .zip are not necessary - just tell the users
with nonstandard machines how to get and install tar and gzip.
Non-programmers on PCs might be happier with winzip, which can
only extract tar, but not create it - but this is not a problem
for them.
Besides, pkzip is only shareware, not completely free, which might
cause legal problems in strange circumstances.
I'm not aware about the legal status of .jar.
I'd keep the #include statements as they are, and have them
search unpacked files first, then look into archives (this way
users can unpack single files, modify them and have them used
automatically).
Another possibility would be a syntax like
#include "[includes]/metals.inc"
where [includes] means to look for a file includes.tar
or includes.tar.gz and find /metals.inc inside of that.
(I intentionally wrote [includes], not [includes.tar]
in order to have this resolved automatically).
To save space, I add an answer to some more postings of
this thread here as well:
> 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.
Since everybody is supposed to have tar and gzip installed on
his machine, he can unpack the individual files. This also solves
the second topic (Home-brews).
Definition conflicts are a problem already now - somebody
recently reported funny effects when including both golds.inc
and metals.inc (which define slightly different things with the
same name).
CPU time needed for decompression is IMHO not a problem:
People with slow machines can decompress them manually
and use a big includes.tar instead of a small includes.tar.gz.
I'd leave the decision to the user.
Ralf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ralf Muschall wrote:
> Carl Bartels wrote:
>
> > 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
>
> AFAIK future zlibs will understand .bz2.
>
> IIRC the tar interface (which I don't know) would just have
> to call "gzopen" instead of "open", the [de]compression would
> then happen transparently. I have no idea whether zlib provides
> all the other stream-related functions that the tar interface
> needs.
>
> I'd say that .jar and .zip are not necessary - just tell the users
> with nonstandard machines how to get and install tar and gzip.
> Non-programmers on PCs might be happier with winzip, which can
> only extract tar, but not create it - but this is not a problem
> for them.
>
> Besides, pkzip is only shareware, not completely free, which might
> cause legal problems in strange circumstances.
> I'm not aware about the legal status of .jar.
Yes, but there are completely free implementations of .zip file handlers.
.jar files are open. They just take the .zip format, add an optional file
(manifest.mf), and specify that you can only use the non-patented compression
(thus avoiding legal issues). Any valid .jar file is a valid .zip file.
BTW, tar on Windows platforms (especially winzip) can cause big headaches
with EOL conversions.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jon A. Cruz wrote:
> Ralf Muschall wrote:
> BTW, tar on Windows platforms (especially winzip) can cause big headaches
> with EOL conversions.
Agreed, but this only requires POVray to understand the EOLs of the
other system. Hackers who want to edit the manually extracted files
will probably be able to say something like :%s/^V^M// or M-% C-q C-m
in their editor.
Thats also why I think it is not necessary to care much about the
existence of tar.exe, gzip.exe etc. on DOSen or MACs - non-hackers
simply won't need it (since povray does all the work), hackers will
know how to obtain it, and the GPL absolutely excludes any kind of
legal hassles that might occur with other archivers (except .zip and
.jar, as I learned from your response).
Ralf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ralf Muschall wrote:
> Jon A. Cruz wrote:
> > Ralf Muschall wrote:
>
> > BTW, tar on Windows platforms (especially winzip) can cause big headaches
> > with EOL conversions.
>
> Agreed, but this only requires POVray to understand the EOLs of the
> other system. Hackers who want to edit the manually extracted files
> will probably be able to say something like :%s/^V^M// or M-% C-q C-m
> in their editor.
But there are some other problems. Such as Windows versions of tools doing
automatic EOL conversion as a default, and on files that it should not be
doing it to (I've had problems with .BMP files extracted from a tar before).
Once you've done EOL conversions on a binary, kiss the 'restore' goodbye.
Mangling textures for renderings is not a nice thing.
Not that I'm saying this is likely to cause widespread massive riots, but it
does exist and should be considered.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
