 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Oh. Well, this ups the complexity quite a bit too.
Its not that complicated to implement a P2P system once you already have
something client-server, Especially as in this instance the central server
model (ala napster) is fine (were not trying to avoid being shut down /
lawsuits)
> Personally, I don't know that I'd want to donate my computer's time to
> someone else's commercial venture, for something like this. Medicine?
> Sure. SETI? Sure. POV traces for posters? Uh....
Posters/large works for print are my specific goal, what other people use
the system for is up to them. Something like you contribute to the farm
(and help render other people's bits, and in return can use it to render
your own works, hopefully getting finished images back faster than you
could manage on your own - what ever said images may be)
Very few POVers are using 100% cpu rendering all the time, so why not let a
fellow POVer benifit from your spare cycles. (and we can all watch the
network grind to a crawl the next time the IRTC do a glass round)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Darren New wrote:
>> Oh. Well, this ups the complexity quite a bit too. Somehow,
>> "professional print work" and "anybody can donate" don't really go
>> together for me.
>
> Hmmm. Maybe I've misunderstood. I interpreted this to mean something
> along the lines of "I run a print-shop, and I'd like to take povray
> input files and print them, but it takes too long." Perhaps you mean
> "I'd like to run a render farm to solve that problem for someone else's
> print shop and contract it out"? That indeed is a different problem to
I just have a desire to render very large images and don't have a way to do
it at the moment without sacrificing certain pov features. I may want to do
some desktop sized renders with lots of glass and photons (that takes ages
at the best of times).
Its a generic problem thats begging for a solution - we have all had renders
that have been abandoned due to impatience!
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> In article <4062f44a@news.povray.org> , "Rick [Kitty5]" <ric### [at] kitty5 com>
> wrote:
>
>> There isn't a rats chance in hell I am exposing samba or windows
>> fileshares to the internet. Security, network overhead and potential file
>> locking issues kill this option stone dead (and thats before you think
>> about the limitations it imposes on the whole process)
>
> The solution to this is called VPN...
IF you can get it working, and it still only addresses a small part ofthe
overall problem.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> My point is that Rick [Kity5] seems to be complaining that POV isn't
> suitable because it doesn't already have the distribution stuff built in
> as robustly as he'd like.
Not in the slightest, I am stating that POV takes to frikin long to render
huges images. Yes there are existing soloutions for distributing a render
(therefore finishing it faster) but they do so at a cost - that cost
usually being radioasity.
> *If* there's nothing in povray that prevents you from rendering
> different scanlines on different computers and getting the same result
> back, it would seem that distributing the render however he wants to
> would do the trick.
Thats the problem. POV returns different results if you render a whole or a
part of an image. All the current options to distribute a render fail when
radioasity is used, you get a tile effect when you put the parts back
together.
>> At the very least, any external solution runs the
>> risk of being abandoned,
>
> Well, if it's open source, that's not much of a problem. Pov-ray runs
> the risk of being abandoned as well. Welcome to the real world. ;-)
If such a system is outside the scope of the official project, there is no
way of ensuring future compatability.
> Again, this is easy to avoid. Release the first version under GPL or
> public domain or BSD or whatever.
Then you will have conflicts with the povray licence.
> Well, then you fix it.
Not that simple, it all depends on what has changed. It could be said that
the adding of radioasity trashed compatability with the (at the time) only
existing distributed system (pvmpov)
Now if pvmpov had been part of the official project that wouldn't have
happened.
> probably cost less to write the software than to buy the first (say) 3
> machines of the render farm.
But the threat of future modifications to the core application breaking the
entire shooting match and leaving someone with a large invetsment is not
going to inspire anyone.
The povray licence isnt exactly helpful either.
> But I'm still waiting to hear from someone whether there's a feature of
> povray that would prevent a distributed render from giving the same
> results and that you can't work around.
radioasity.
The lead on client-server rendering has to come from the official team.
--
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:40640eb5@news.povray.org...
> Its a generic problem thats begging for a solution - we have all had
renders
> that have been abandoned due to impatience!
We have also all had renders going for several days, some have even had
renders for a month or more. Which is why patience is requisite for using
POV-Ray :)
--
...Chambers
http://www.geocities.com/bdchambers79
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40645d87$1@news.povray.org>, dne### [at] sanrrcom says...
> > radioasity.
>
> I thought (in my uninformed listenings) that you could save the
> radiosity data, and tell it not to collect more samples during the
> render. Anyone with actual knowledge know the answer to this one?
>
>
I think you can, but it is impractical, since I believe it will write out
the file, but also attempt to continue to render. Any solution that gets
around this requires using the confusing plugin architecture to interrupt
it before it actually start the render I think. You can't I believe just
tell it 'generate these files and exit'. So can it be done? Yes and no. I
also get the feeling that maybe having those samples may not always
produce identical images from both pieces and a complete image. If that
is the case, then even my idea wouldn't help. This may in fact be the
case, since I am not sure that the 'color' is precomputed, but maybe only
the brightness, so failing to compute the entire image could result in
different results due to this.
--
void main () {
call functional_code()
else
call crash_windows();
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40651522$1@news.povray.org>, dne### [at] sanrrcom says...
> Patrick Elliott wrote:
> > I think you can, but it is impractical, since I believe it will write out
> > the file, but also attempt to continue to render. Any solution that gets
> > around this requires using the confusing plugin architecture to interrupt
> > it before it actually start the render I think.
>
> Nah. You wait until the file it writes out stops changing, then you kill
> the process. Or you let the server trace the first scanline. (Of course,
> all this assumes that radiosity works when you distribute the image to
> start with.)
>
> For that matter, if you wanted to kludge it hard enough, you could do
> the whole thing with just +C, by shipping faked part-finished images to
> all the machines, starting them up, watching how many scanlines of the
> files had been changed, and killing off the render when it got thru as
> many lines as you wanted. You don't even need the +S/+E, technically.
>
I have a personally hatred of kludges. They rarely work as well as a
correct solution. To many moving parts (or processes in this case). lol
Just because a thing can be done, does not mean it shouldn't be done
right.
--
void main () {
call functional_code()
else
call crash_windows();
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
</lurker>
Hello everybody,
I'm new to this group and never posted before, my knowledge about POV-Ray is
really small. That said, I'd wanted to point peoples interrested about the
scripting abilities to a few ressources about Parrot, the next Perl 6 VM:
Parrot's Homepage:
http://www.parrotcode.org/
Parrot's wiki:
http://www.vendian.org/parrot/wiki/
Dan Sugalski's blogs:
http://www.sidhe.org/~dan/blog/
Lurk the newsgroups (read-only):
nntp://news.perl.org/perl.perl6.*
or register to get them via the mailing lists (rw):
http://lists.perl.org/showlist.cgi?name=perl6-all
before you might want to browse them on Active State web site:
http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/perl6-internals
http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/perl6-language
or have a look at Piers Cawley'Summaries of the both lists:
http://dev.perl.org/perl6/list-summaries/
Perl 6 Homepage (it's also parrot related):
http://dev.perl.org/perl6/
I think it may be a good oportunity for POV-Ray to give a look at what's going
on with Parrot, here's some pro/con that were given in this thread about
scripting abilities of POV-Ray (I'm not quoting here, just remembering a few
comments):
Development time: Someone said that POV-Ray developers should spend more time
working on the rendering engine than on the parsing one. This is a really
important statement and delegating the inner working of parsing, compiling,
executing, JITing, Garbage Collecting, multiple platforms support and so on, to
peoples used to do that everyday would be a winner. Net benefits will also raise
from the infrastructure already in place for the scripting language:
tinderboxes, testings, communities already built around the scripting engine.
Though, depending on how one might embed a scripting language, a C/C++ API for
POV-Ray might probably be needed, or POV-Ray specific opcodes. Parrot's
already running inside PostGRES and there's a mod_parrot for Apache, oh and
there's already a Parrot and SDL implementation of tetris...
- Language choice: peoples proposed lua, mono, perl, python, tcl, and other
scripting languages. Here is what's in the languages directory of the last
Parrot's tarball: BASIC, Befunge-93, befunge, bf, cola, conversion, forth, imcc,
jako, m4, miniperl, ook, parrot_compiler, perl6, plot, python, regex, ruby,
scheme, tcl, urm. Some are functional, some not yet, but all those languages are
compiled into parrot's byte code and they can share modules between them. Of
course POV-Ray probably doesn't need all the CPAN modules, but, admit it, 'use
Moon::Phase; use Weather::Underground;' might come handy to add some realistic
features to a scene, no? ;-) And still in the idea of benefitting from other
languages user base, questions like "How do i do function xxx and loop from here
to there?" might be redirected to comp.lang.*.
- Sandboxing: Some people suggested that too much scripting abilities might be
harmful, in the form of trojans, exploits, etc. As every decent scripting
language these days, Parrot will of course support what I/O and opcodes might be
executed. The sand boxing system, which is yet to be worked on, was recently
discussed on the perl6-internals list.
I hope to get some of you interrested in having a look at this promising VM,
going back to shadow mode now...
<luker>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Lurker" <sha### [at] nightcom> wrote in message
news:40664bea@news.povray.org...
> </lurker>
>
> Hello everybody,
>
> I'm new to this group and never posted before, my knowledge about POV-Ray
is
> really small. That said, I'd wanted to point peoples interrested about the
> scripting abilities to a few ressources about Parrot, the next Perl 6 VM:
Hmm... I'm not sure if this will really work. Parrot is a VM for
programming languages; that is, the compiled bytecode is interpreted. Any
kind of compiled byte-code for POV-Ray is, essentially, data rather than
machine instructions. As such, it's hard to justify needing *any*
interpreter other than the rendering engine.
> Development time: Someone said that POV-Ray developers should spend more
time
> working on the rendering engine than on the parsing one.
Just because someone said it, isn't necessarily true. I think work on the
parsing engine is pretty important, at least for complex scenes. Anyway, I
haven't seen work on the parser conflict with work on the renderer, but I
also am not a member of the TAG or the POV team.
> - Language choice: peoples proposed lua, mono, perl, python, tcl, and
other
> scripting languages. Here is what's in the languages directory of the last
You can already use those language to generate POV-Ray scene code, but they
wouldn't work for actually scene files. In fact, most of them would be
worse for scene files than the POV-Ray SDL.
> Of
> course POV-Ray probably doesn't need all the CPAN modules, but, admit it,
'use
> Moon::Phase; use Weather::Underground;' might come handy to add some
realistic
> features to a scene, no? ;-)
This is already possible quite easily with #include files (well, the use
is - writing these features is as difficult as ever, and another
interpreting language won't change that :)
> - Sandboxing: Some people suggested that too much scripting abilities
might be
> harmful, in the form of trojans, exploits, etc. As every decent scripting
While the possibility of a POV-Ray virus has been mentioned, I/O
restrictions seriously limit this threat.
--
...Chambers
http://www.geocities.com/bdchambers79
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40664bea@news.povray.org>, Lurker <sha### [at] nightcom>
wrote:
> Development time: Someone said that POV-Ray developers should spend
> more time working on the rendering engine than on the parsing one.
After it's written, the scene parser wouldn't require that much work,
and writing it in the first place isn't that difficult. Also, the scene
language is part of what makes POV-Ray so useful, throwing away that
advantage would be a huge mistake.
In addition, it would be another thing out of the POV Team's control.
They would have to keep up with version changes, incompatibilities, and
bugs. And before you say that they can fix the bugs themselves because
Parrot is open source, those bugs would be in a completely separate code
base that does far more than what is needed and which is maintained by a
completely different group. People compiling POV-Ray would first have to
have a port of the correct version of Parrot. And, being designed for
scripting languages, Parrot would perform very badly at the kind of
floating point math required for POV-Ray, making it useless for anything
but the scene description itself.
> - Language choice:
Bad idea. It would make exchanging objects and scene code far more
complicated. Support would be far more difficult, and we *would* have to
support it. Coding scenes would be more difficult...none of those
languages are built for it.
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
