 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott <sha### [at] hotmailcom> wrote:
> In article <40625573$1@news.povray.org>, dne### [at] sanrrcom says...
> > Patrick Elliott wrote:
> > If you're complaining that it's not already available for free, then it
> > doesn't sound like you're involved in professional print work at all. :-)
> >
> No I am not. But if I did get into it, I would prefer a cheap and usable
> solution, not weeks spent trying to get something done that will work.
> Yes, you can do all this now, but it requires either using POV-Ray's
> plugin stuff, of which only 3 people have ever made one. QuietPOV, which
> is little more than a alternate way to start things up, the Moray Plugin
> that you can't get the source on and a totally non-functioning example
> you can use to base your own from. Most of the stuff in the plugin system
> no one has a clue how to use.
>
> In any case, I was just talking about how I would do it, if I had a clue
> how to do so. I was replying to someone else's comment about such a thing
> not existing and suggesting how some of it might work, if anyone even did
> manage to design it. But I have an aversion to plugin/external program
> solutions for "basic" functionality, so didn't suggest such as a
> possibility initially. At the very least, any external solution runs the
> risk of being abandoned, ending up non-free (which for me is a non-
> starter for even trying it) or eventually becomes useless as changes to
> the program it was designed for make it stop working. Something built in
> has less of a chance of this happening.
>
> Maybe I am just strange or something, but sometimes I think about
> solutions to *other people's* problems. Admittedly this seems to be
> something rare and almost unheard of in open source, where 90% of stuff
> that gets made is what the designer needed, not what they spent a few
> minutes considering someone else may actually find more usable...
>
> --
> void main () {
> call functional_code()
> else
> call crash_windows();
> }
any updates on the grid computing front using POV since you guys had this
conversation?
24 hours rendering one image so far on a celeron 2.9 GHZ machine with 2GB
RAM... and counting...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
