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.
-- 
François DISPOT  --  http://www.wozzeck.net
      __  __ __  __  _
|  | /  \  /  / |_  /  |/
\/\/ \__/ /_ /_ |__ \_ |\

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

"Peter J. Holzer" wrote:
> 
> Only 33 % if you use base 64 encoding. How do you get a factor of 3-4?
> 

I thought of a human readable form.

> 
> 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.

Exactly, it's much more flexible.

> > 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.
> 

Reading integer files cross platform is not difficult, you just have to
take care of the byte order, which is easy and does not take much time,
see for example the png file format.  I don't know any file format which
works this way for floating point numbers.

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

Christoph Hormann wrote:
> 
> "Peter J. Holzer" wrote:
> >
> > Only 33 % if you use base 64 encoding. How do you get a factor of 3-4?
> >
> 
> I thought of a human readable form.

Not very useful for a human to be able to read the value
of the bytes of a PNG or JPG file!  :-)

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

Post a reply to this message

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

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

One way to do this would be to allow base64-encoded data (or similar)
in all places where you can put the name of an image file.

  // Kalle Hasselström

Post a reply to this message

On 2001-10-21 07:13, Christoph Hormann <chr### [at] gmxde> wrote:
> "Peter J. Holzer" wrote:
>> 
>> Only 33 % if you use base 64 encoding. How do you get a factor of 3-4?
>> 
> 
> I thought of a human readable form.

A human readable ASCII form for images? Like PPM ASCII or XPM? You get
much more than a factor of 3-4 for these compared to JPG (I just
converted a 600x600 pixel JPG (83k) to PPM: 4.2M, or a factor of 51!),
and they aren't really human readable except for tiny sizes. 

>> > 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.
> 
> Reading integer files cross platform is not difficult, you just have to
> take care of the byte order, which is easy and does not take much time,
> see for example the png file format.  I don't know any file format which
> works this way for floating point numbers.

Just chose one: IEEE-754 big-endian for example.

Converting between different FP formats usually isn't more than
bitshifting, either. For the common case (IEEE-754 big- or little
endian) you can implement a "fast path" which reads directly or only
swaps bytes, for the rest you can implement a portable C version (this
is not completely trivial, but shouldn't be too difficult either - I
might take a stab at it just as a "proof of concept"). Or you can ignore
them completely, just as you can ignore ones-complement integers and
PDP-endian longs[1].

	hp

[1] Ok, I admit that I don't know any current architecture which doesn't
use strict big/little-endian twos-complement integers, but I know at
least two (Alpha in VAX-compatibility mode, Cray) which don't use
IEEE-754. However, Povray must be compiled in IEEE-754 mode on the Alpha
to work at all (The alpha will trap on denormalized numbers otherwise)
and I don't know enough about the Cray to know if that's a problem.

-- 
   _  | 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

On 2001-10-21 16:14, Peter J. Holzer <hjp### [at] hjpat> wrote:
> On 2001-10-21 07:13, Christoph Hormann <chr### [at] gmxde> wrote:
>> "Peter J. Holzer" wrote:
>> I don't know any file format which works this way for floating point
>> numbers.
> 
> Just chose one: IEEE-754 big-endian for example.

s/chose/choose/, of course.

	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

Peter J. Holzer <hjp### [at] hjpat> wrote:
: A human readable ASCII form for images? Like PPM ASCII or XPM? You get
: much more than a factor of 3-4 for these compared to JPG (I just
: converted a 600x600 pixel JPG (83k) to PPM: 4.2M, or a factor of 51!),

  What a fair comparison. PPM and XPM are uncompressed while JPG is highly
compressed.
  You should have tested uuencoding the JPG.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Well, an option to compile a list of all the include files (including
images and density files) would be nice, with a recursive quality
additionally.    I'll have to look into that code at some point. It
would be a nice feature for say- Povray 3.6(heh, yeah right)  or 4.0 

I would be perfectly happy to be able to include images, in-line with
the code. This would provide at least two immediate advantages I can
see at the moment. 

#1. the possibility of making a single .pov file that doesn't depend
on any other files. 

#2. The possibility of dynamically generating images during the parse
phase.


If this were combined with say, a possible feature for binary file i/o
directives, you could add support for reading in almost any image file
format without having to patch the povray source code. 

I personally don't mind  the file size issues so much. You don't HAVE
to include images in line with the ascii source code, so if file size
is your concern you can just leave the files seperate. 

Triangle meshes consume a lot of file space in ascii format as well.
So it's not really setting a new precedent in that direction.

Yeay! free ramen noodles! I guess I'll end this message now so I can
eat them.

-Zen

Post a reply to this message

On 2001-10-21 19:30, Warp <war### [at] tagpovrayorg> wrote:
> Peter J. Holzer <hjp### [at] hjpat> wrote:
> : A human readable ASCII form for images? Like PPM ASCII or XPM? You
> : get much more than a factor of 3-4 for these compared to JPG (I just
> : converted a 600x600 pixel JPG (83k) to PPM: 4.2M, or a factor of
> : 51!),
>
>   What a fair comparison. PPM and XPM are uncompressed while JPG is
> highly compressed. You should have tested uuencoding the JPG.

Please read the last few messages again. My argument *was* that
base64-encoding (or uuencoding, which is almost the same thing) expands
a file only a factor of 1.33, not by 3-4, as Christoph claimed. But
Christoph corrected me that he was not talking about base64-encoding JPG
but about "human readable" ASCII picture formats.

	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

On Fri, 19 Oct 2001 19:03:11 GMT, Ze!nPs### [at] yahoocom wrote:

>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. 
>

Dunno about the included images, but I guess you could write a .pov
file that (when run) would open a specified .pov file and then start
echoing lines from this input .pov file to a specified output file.
Whenever an "include" is hit, it would open the included file,
start reading from that, outputting its contents to the output file
instead of the "include" statement.

This would result in one .pov file containing verything except for
images and fonts.  I suppose you could write in a macro to list
all images and fonts references that occur in a pov file but that
would be a parse monster.

One other problem, if youy use the technique of having a .pov
file write a temp file and then include the just-created temp
file, the above method would fail.

Interesting problem.

Post a reply to this message

On Thu, 25 Oct 2001 23:43:32 GMT, nospam wrote:
> One other problem, if youy use the technique of having a .pov
> file write a temp file and then include the just-created temp
> file, the above method would fail.

My guess would be that nothing but a full-blown POV parser can predict what
a POV program will do, and that can only do so by running the program and
seeing what happens.  I suspect it's quite easy to map this problem to the
halting problem.

--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}

Post a reply to this message

Ron Parker wrote:
> 
> On Thu, 25 Oct 2001 23:43:32 GMT, nospam wrote:
> > One other problem, if youy use the technique of having a .pov
> > file write a temp file and then include the just-created temp
> > file, the above method would fail.
> 
> My guess would be that nothing but a full-blown POV parser can predict what
> a POV program will do, and that can only do so by running the program and
> seeing what happens.  I suspect it's quite easy to map this problem to the
> halting problem.

Imagine a script outputting to a file which it includes later...

Turing rulez ;-)
-- 
François DISPOT  --  http://www.wozzeck.net
      __  __ __  __  _
|  | /  \  /  / |_  /  |/
\/\/ \__/ /_ /_ |__ \_ |\

Post a reply to this message