Yes I know it's been done before in a special patched version of
povray at some point. But very poorly. (POB format)

Basically, What I'd like to be able to do is compile a scene- with all
it's various include files and image files and data files- into a
single compressed binary file. Or at least into a single in line ascii
file - like say.. a pdf. 

This file would have custom "default" ini file settings inline with it
to. This is all towards the goal of making distributed rendering
easier. This is also partially inspired by the above post about a
napster llike distributed rendering system. 


Basically if you can have a scene- animation or no- compiled into a
single file it makes it easier to send around because the other person
doesn't have to set up the proper include files, all the image files
etc in the right directories for it to even work properly . 


This could possibly even be achieved by making it simple collect all
the files into a zip file- correcting the dependancies, and allowing
it to render directly from a zip file. radiosity data included.

command line options added to the end override the ini file defaults
in the zip file. 


In application to the napster like program proposed above, it could
work like this:


You press a button in the program and it finds the computers on the
network that seem the least taxed at the moment. Then it splits up the
render for each those computers into little bites and sends the
appropriate commandline options with each zip file. 

Then the host computers call up duplicate copies of povray (perhaps
povray is built into it?) To render the packets.


This is probably a really old idea, but one which I'd like to see cos
it'd make big renders much easier to do across multiple computers.

Post a reply to this message

In article <3bd0751f.6193388@news.povray.org> , Ze!nPs### [at] yahoocom  wrote:

> This is probably a really old idea, but one which I'd like to see cos
> it'd make big renders much easier to do across multiple computers.

Just ZIP the scene file(s), it will be as effective.

    Thorsten

Post a reply to this message

On Fri, 19 Oct 2001 20:12:00 +0200, "Thorsten Froehlich"
<tho### [at] trfde> wrote:

>In article <3bd0751f.6193388@news.povray.org> , Ze!nPs### [at] yahoocom  wrote:
>
>> This is probably a really old idea, but one which I'd like to see cos
>> it'd make big renders much easier to do across multiple computers.
>
>Just ZIP the scene file(s), it will be as effective.
>
>    Thorsten


not quite, since you can't say for instance:

povray scene.zip


you have to unzip it first. 
Also when zipping it, you have to find all the files you may have
included. You should keep them all in the same directory as good
practice, yes, but many times this is not practical or convenient. As
a consequence you have to sort through all occurances of those files
in your source code and replace them with the new location. 


Also say, if you used a chris colefax macro, and someone at the other
end doesn't have that macro, they would have to get it and install it
correctly in order to properly render.


So as you can see, Just zipping it is not quite as effective as what I
have in mind.

Post a reply to this message

Ze!nPs### [at] yahoocom wrote:
> 
> Also when zipping it, you have to find all the files you may have
> included. You should keep them all in the same directory as good
> practice, yes, but many times this is not practical or convenient. As
> a consequence you have to sort through all occurances of those files
> in your source code and replace them with the new location.
> 
> Also say, if you used a chris colefax macro, and someone at the other
> end doesn't have that macro, they would have to get it and install it
> correctly in order to properly render.

Reading this i have to say i don't like the idea.  

You won't be able to extract the original code so you can render the
scene, but not study the code - a very questionable advantage.

Maybe some kind of 'parsing protocol' would be good that says what files
are actually being parsed.  From this you can conclude the files that are
required for the scene.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <3bd07e1a.8492982@news.povray.org> , Ze!nPs### [at] yahoocom  wrote:

> Also when zipping it, you have to find all the files you may have
> included.

This is possible without parsing the whole file.  The only restriction is
when a user uses the rarely useful feature of building the include file name
and path on the fly in the scene.  Of course this could also be made
possible, but the  it would be slightly more work 8still no full parser is
required).

I have posted example code to do what you need in p.b.programming, subject
"Finding all #include files in a POV-Ray scene file".

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Ze!nPs### [at] yahoocom wrote:

> This is probably a really old idea, but one which I'd like to see cos
> it'd make big renders much easier to do across multiple computers.

IIRC, this is what the IMP people did, using tar format.
As for distributed rendering, remember that POV uses more than just FPU
cycles, especially memory.
-- 

      __  __ __  __  _
|  | /  \  /  / |_  /  |/
\/\/ \__/ /_ /_ |__ \_ |\

Post a reply to this message

See, the way I envision povray SDL working is like postscript- except
for 3d graphics. 


Povray should allow for including an image directly into the source
file.  

So that everything can be collapsed into a single file, including all
the images and the include files that everyone might not have. 

This can be an ascii file.  Maybe you can have an option to collapse
it both into ascii, and the compressed binary form. And an option to
convert easily between the two, since you all seem to have a problem
with not being able to look at the source code of a scene. 

Perhaps there was a standard binary equivilent for each object - such
as mesh2, which would greatly benefit from say, being able to have a
triangle mesh binary file that you can call directly into a scene
using an #include directive or something similar. 

Sure all of this can probably be done by hand, but that's not the
point. The point is not having to do it all by hand and just having a
single button you can press that will compile it into a single
collapsed file suitable for distribution, without all the problems
that come with requiring multiple files to render a scene. 

And have no doubt, there are problems with it.

Post a reply to this message

Presented this way, this is rather convincing.
Work on it and come back for POV 4?

-- 
Adrien Beau   adr### [at] freefr   http://adrien.beau.free.fr/

Post a reply to this message

Ze!nPs### [at] yahoocom wrote:
> 
> See, the way I envision povray SDL working is like postscript- except
> for 3d graphics.
> 
> Povray should allow for including an image directly into the source
> file.

Note that this would blow up the size at least by factor 3-4 with ascii.

> So that everything can be collapsed into a single file, including all
> the images and the include files that everyone might not have.

I'm still not sure what you would gain with that.  If the include files
are your own, you can easily put them together by hand since you probably
know which ones you use.  If not, there are important copyright issues you
will have to think about, not everyone will allow you to put his include
files in such a package.

> [...]
> Perhaps there was a standard binary equivilent for each object - such
> as mesh2, which would greatly benefit from say, being able to have a
> triangle mesh binary file that you can call directly into a scene
> using an #include directive or something similar.

Remember that floating point numbers in binaries are not platform
independant.

> Sure all of this can probably be done by hand, but that's not the
> point. The point is not having to do it all by hand and just having a
> single button you can press that will compile it into a single
> collapsed file suitable for distribution, without all the problems
> that come with requiring multiple files to render a scene.

I think if you find out the included files with the code Thorsten posted
(or with a parsing protocol like i suggested) and automatically zip these
files together, this would be not more work than a hardcoded function
inside POV and it would be much more flexible.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

On 2001-10-20 18:35, Christoph Hormann <chr### [at] gmxde> wrote:
> Ze!nPs### [at] yahoocom wrote:
>> 
>> See, the way I envision povray SDL working is like postscript- except
>> for 3d graphics.
>> 
>> Povray should allow for including an image directly into the source
>> file.
> 
> Note that this would blow up the size at least by factor 3-4 with ascii.

Only 33 % if you use base 64 encoding. How do you get a factor of 3-4?


>> So that everything can be collapsed into a single file, including all
>> the images and the include files that everyone might not have.
> 
> I'm still not sure what you would gain with that. If the include
> files are your own, you can easily put them together by hand since
> you probably know which ones you use.

If you want to automate the process (e.g., for distributing a render
over several computers) having to maintain a list of files is
cumbersome. However, I think that having Povray to generate a list of
all the files it read is enough for that task. It also has the advantage
that you can easily generate Makefile rules from the output.

>> Perhaps there was a standard binary equivilent for each object - such
>> as mesh2, which would greatly benefit from say, being able to have a
>> triangle mesh binary file that you can call directly into a scene
>> using an #include directive or something similar.
> 
> Remember that floating point numbers in binaries are not platform
> independant.

Neither are integers. If you define a portable binary format, you will
have to define the format of all its components, too. 

	hp


-- 
   _  | Peter J. Holzer    | Oder glaubst du "Bugtraq" waere eine
|_|_) | Sysadmin WSR       | Science-Fiction TV-Serie ueber Schaben
| |   | hjp### [at] hjpat         | im Weltall?
__/   | http://www.hjp.at/ |	-- Juergen P. Meier in dcsm

Post a reply to this message