 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> 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...
It could, but will still suffer radioasity tiling artifacts.
--
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 <40611ef1$1@news.povray.org>, dne### [at] san rrcom says...
> Patrick Elliott 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?
>
True and that is in essence the point.
> 2) How automated do you want it?
>
For myself, if I was using it like that, then 'very' to 'completely'
would be about right. You could do it with scripts (to a limit), but you
start getting a bloody mess:
Program 1 - generates a scene file.
POV-Ray 1 - Generates a Photon and/or Radiosity file.
Script sends file to x number of systems.
Script tells each system it is sent to "start povray with ..."
Hopefully nothing goes wrong.
Personally I would prefer if one server handled everything starting with
step 2, so the only thing that 'can' go wrong should be if one of the
machines the clients are on doesn't respond. Even then, it could be
annoying, but not necessarily critical, since the server end can retry
and in the worst case adjust the image chunks to compensate. But that is
just me.
> So, I think the real question is, "what's the problem?"
>
Probably nothing, but if we wanted to bloody do it manually, we wouldn't
be looking for a better solution. lol Or at least those planning to use
it. I just see it as an interesting possible way to expand the program.
The same thing could be done with a plugin/program combo that waits until
rendering starts and automatically sends out the needed files and
modified .INIs needed to handle it, then kills the original rendering.
But I personally hate plugins (in any program), they often require hacks
to do what you wanted, simply can't do what you need or don't actually
work the way people claim they are supposed to. They also rely in the
questionable theory that the program they plug into will never change its
behaviour or otherwise stop working with the plugin.
I have had some fights over issues like this on another program I use and
there are still things that I am arguing about with the developer,
because the hacks needed to do what I want are complicated, not always
stable or just flat out totally and completely impossible to do as an
external process.
In any case I see this idea as a major advantage if built in. First off,
you don't need to install anything extra, so all you need to start a
render farm is network some computers, install POV-Ray on them and give
the server the IPs of the other machine. Done!
Now.. A TCP/IP for over the internet would be useful though. If the
'server' copy could launch to multiple available groups then a plugin
could be added that lets someone remotely connect with a user name and
password, then send the file to render direct to the server. The server
then immediately passes it to a group on the farm or queues it for later,
then when it does run, tracks the total time and could charge the users
account based on that. This would make sense as an external addon/plugin,
while the basic functionality to network POV-Ray in groups makes more
sense imho if built in.
--
void main () {
call functional_code()
else
call crash_windows();
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4062107a@news.povray.org>,
"Rick [Kitty5]" <ric### [at] kitty5com> wrote:
> > 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...
>
> It could, but will still suffer radioasity tiling artifacts.
One simple solution would be to render overlapping tiles. This doesn't
get rid of the artifacts, but could spread them out enough that you
would need a specifically designed filter to make them visible.
Or you could just turn off gathering of additional radiosity samples
during the render. Have one machine gather the radiosity data and then
transmit it to the other machines (or have multiple machines gather data
and then merge it all together), and just use that. Lower quality, but
no artifacts.
--
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 <cja### [at] earthlinknet> wrote:
> > It could, but will still suffer radioasity tiling artifacts.
> One simple solution would be to render overlapping tiles. This doesn't
> get rid of the artifacts, but could spread them out enough that you
> would need a specifically designed filter to make them visible.
Actually I don't think that would help much. It would just smoothen the
borders of the artifacts, without making them any less visible (besides
slowing down the rendering, of course).
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4062ab6c@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> Actually I don't think that would help much. It would just smoothen the
> borders of the artifacts, without making them any less visible (besides
> slowing down the rendering, of course).
It is basically the same technique used to make tiling textures, and it
works there even with great variation in the portions of the images
being mixed. In this case, the images will be nearly the same, only the
artifacts of the radiosity will be different.
Of course, more overlap not only means better results, but also more
pixels being rendered multiple times, but this method would be simple to
implement and would work with the present radiosity, without the
complications of having to make sure the radiosity data is synchronized.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40609966@news.povray.org>,
"Rick [Kitty5]" <ric### [at] kitty5com> wrote:
> But in this instance, effiency isn't whats important.
Yes, it is. The relatively compact (relative to an XML representation)
scene structures in memory can take up a great deal of space. You can
easily get binary files of several hundred MB, or XML files of over a GB.
> Common middle ground
> for converting from and to is, and if said middle ground is an open format,
> so much the better.
But XML isn't a format, it's a markup language. Even if you put your
data in XML, other programs will need to know how to handle that data in
order to make use of it. You just have a bulkier, less efficient method
of transferring data.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> SAMBA *is* client-server over tcp/ip. So ... what do you *actually* need?
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)
Most of what I would like isn't exactly hard to do, the biggest problem is
how povray renders a tile.
IMO if its possible to render a portion of an image, and that portion is not
100% identical to the same portion when rendered as part of a whole image.
Its Pov thats needs fixing.
Anyway, since you asked - I want a server to accept rendering jobs. clients
to talk to server and request parts of current job, said parts are then
sent back to server on completion.
job submission is seperate from the server.
Server tracks allotted jobs and will always aim to maintain 100% client
usage. So, when a job is 90% complete, the same part may be passed to
several clients (that would oitherwise be idle) . This will ensure that the
overall job progress does not depend on a couple of slow clients that were
unlucky enough to get the hardest tiles. Clients will check back with
server during the render to see if the part they are working on is still
required.
Server builds profiles of clients and will try to pass faster/smaller tiles
to slower clients (say, tiles from the outside of an image). Server also
builds profile of job, so when a tile is returned it will score its
neighbours and attempt to build a complexity map of the image (or just play
minesweeper)
Add the ability for servers can talk to and pass jobs to other servers, a
central server database, and clients that can share common job (such as
image maps) amongs themselves and we can have a massive render farm that
anybody can donate cpu cycles to and benifit from.
--
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 <4062f44a@news.povray.org> , "Rick [Kitty5]" <ric### [at] kitty5com>
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...
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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();
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
