 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> That's completely right - but as the text says this distributed
> rendering framework is not limited to file system based communication.
Until you actually provide alternative scripts, it is.
It is not up to your applications users to build upon it for you, especially
with (and if for no other reason than) the current not-quite-a-licence.
Either release it as open source or don't, not some ambiguous half way
house.
--
Rick
Kitty5 NewMedia http://Kitty5.com
POV-Ray News & Resources http://Povray.co.uk
TEL : (+44) 0845 1083740 - ICQ : 15776037
PGP Public Key : http://pgp.kitty5.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4060902f@news.povray.org>,
"Rick [Kitty5]" <ric### [at] kitty5 com> wrote:
> Christopher James Huff wrote:
> > No it's not. Bloat means more to transfer over the network, and it has
> > no advantages over sending binary information.
>
> Bloat also compresses well.
Sure...add a bunch of junk to get a better compression ratio. The binary
format will still be smaller after compression, if you need to compress
it. High compressability isn't really something to strive for...in fact,
it could be a sign that your format contains too much redundancy.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
> it could be a sign that your format contains too much redundancy.
But in this instance, effiency isn't whats important. Common middle ground
for converting from and to is, and if said middle ground is an open format,
so much the better.
--
Rick
Kitty5 NewMedia http://Kitty5.com
POV-Ray News & Resources http://Povray.co.uk
TEL : (+44) 0845 1083740 - ICQ : 15776037
PGP Public Key : http://pgp.kitty5.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rick [Kitty5] wrote:
>
> I would have to render the image at 16200x10200
>
> Now, on the fastest single CPU I have, said image takes a day to render at
> 1024x768
>
> How long would it take to render the poster size image (that is more than 10
> times bigger) ?
About 210 times as long. This is not specific to POV-Ray, it is the
same for any other raytracer (so much for 'povray doesn't scale').
> Far to long, especially if you concider that its easy to make an image that
> takes longer than a day to render at desktop resolutions.
>
> And all this assumes that I will only have to render said poster sized image
> once, how do I keep a client who wants to see a series of proofs and make
> changes - tell them it could take months because povray doesn't scale!
>
> "POV is not a suitable tool" and "simply isn't practical" are very clearly
> valid statements.
Please reread what i wrote about it. You write that you can't use tools
that distribute a render via file system for reasons specific to your
situation but you generally say "for professional print work, ... , POV
is not a suitable tool" a few sentences later. I don't want to get
personal here but this to me seems quite clearly either ignorant or
malicious.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 21 Mar. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> Please reread what i wrote about it. You write that you can't use tools
> that distribute a render via file system for reasons specific to your
> situation but you generally say "for professional print work, ... , POV
> is not a suitable tool" a few sentences later. I don't want to get
> personal here but this to me seems quite clearly either ignorant or
> malicious.
Oh come on! Distributing via a shared filesystem is an almighty kludge if
ever there was one. great for proof of concept, pointless for anything
beyond your users lan.
--
Rick
Kitty5 NewMedia http://Kitty5.com
POV-Ray News & Resources http://Povray.co.uk
TEL : (+44) 0845 1083740 - ICQ : 15776037
PGP Public Key : http://pgp.kitty5.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rick [Kitty5]" <ric### [at] kitty5com> wrote in message
news:40609ba0@news.povray.org...
> Oh come on! Distributing via a shared filesystem is an almighty kludge if
> ever there was one. great for proof of concept, pointless for anything
> beyond your users lan.
What about imp (http://www.imp.org)? Obviously they are doing distributed
rendering beyond the user's filesystem... ??
Although, it /would/ be nice if POV supported Distributed/MT processing
somehow. I just feel it isn't going to happen ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40609ba0@news.povray.org>, ric### [at] kitty5com says...
> Christoph Hormann wrote:
> > Please reread what i wrote about it. You write that you can't use tools
> > that distribute a render via file system for reasons specific to your
> > situation but you generally say "for professional print work, ... , POV
> > is not a suitable tool" a few sentences later. I don't want to get
> > personal here but this to me seems quite clearly either ignorant or
> > malicious.
>
> Oh come on! Distributing via a shared filesystem is an almighty kludge if
> ever there was one. great for proof of concept, pointless for anything
> beyond your users lan.
>
>
Well.. Then code something better, like they said.
As I understand it things like photons and radiosity are computed once
globally for the image. No way you can really get around this, but the
same data can be used by several engines, so... How about a set of TCP/IP
sockets. You set the first copy of POVRay to serve the critical data to
the others and the other to receive it. Then each takes the 'section' of
the image its told to handle and renders it based on the precomputed data
done by the server. You could have that version track the line by line
final result from the others, just the statistics from them or even run
multiple scenes through several different available groups of machines.
It wouldn't be perfect, since photons and radiosity data must be
precomputer by the 'server', but everything else, once these are
computed, should be scalable to any number of copies of POV-Ray as
needed, making the final render far faster.
That is what I would consider doing, if I had a clue how to write decent
C or make any of it work. Feel free to use or reject it as you wish, but
I am not going to code it and if you are not going to either, then
neither of us should complain about someone else not doing it.
--
void main () {
call functional_code()
else
call crash_windows();
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> What about imp (http://www.imp.org)? Obviously they are doing distributed
> rendering beyond the user's filesystem... ??
Animations only, clients are passed whole frames.
--
Rick
Kitty5 NewMedia http://Kitty5.com
POV-Ray News & Resources http://Povray.co.uk
TEL : (+44) 0845 1083740 - ICQ : 15776037
PGP Public Key : http://pgp.kitty5.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rick [Kitty5]" <ric### [at] kitty5com> wrote in message
news:4060ca55@news.povray.org...
> Mike Raiford wrote:
> Animations only, clients are passed whole frames.
Could this not be adapted to send a partial frame (ala SMPOV) to the
clients? i.e. the client would need all of the POV files and associated
resources, in addition to a string containing which region to render... this
gives what IMP is doing to rendering single frames in a large format...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40611ef1$1@news.povray.org> , Darren New <dne### [at] sanrrcom>
wrote:
>> As I understand it things like photons and radiosity are computed once
>> globally for the image. No way you can really get around this, but the
>> same data can be used by several engines, so...
>
> I think the question is two-fold.
>
> 1) What is computed globally that can't be saved in a file after
> computation and before the final render?
>
> 2) How automated do you want it?
I think Rick wants what is known as the ideal implementation of "grid
computing" - of course not even research projects have created such software
systems...
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
|
|
| |
| |
|
|
|
|
| |
