 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
I have started some work on converting the PVM patched POV-Ray over to
jxta.
Jxta is a p2p protocol (www.jxta.org).
Following the basic pvm structure that is in the pvm patch:
My thought is that a group of slave peers can join a farm, retrieve
rendering assignments, and post the results back to the farm. A Master,
joins the farm, posts work assignments, and retrieves results.
My main work with jxta is involved with jxtaSpaces, a distributed shared
memory service which creates a distributed tuple-space (similiar to
javaSpaces, Linda, ...). POV_Ray seemed like a good demonstration use
of that concept. (jxtaspaces.jxta.org)
I was wondering:
(1) is there any interest on this list in this project
(2) any volunteers to help test/criticize/suggest/B&Moan/...
Comments:
The current jxta platform is java based.
The current jxta platform is extremely beta.
I am about 75% finished with a proof of concept (aka hack) that uses
java/C communication emulating the pvm patch.
tom dengler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi
Tom Dengler wrote:
>
> Hi,
> I have started some work on converting the PVM patched POV-Ray over to
> jxta.
> Jxta is a p2p protocol (www.jxta.org).
never heard of that. how do you pronounce that? :)
> Following the basic pvm structure that is in the pvm patch:
> My thought is that a group of slave peers can join a farm, retrieve
> rendering assignments, and post the results back to the farm. A Master,
> joins the farm, posts work assignments, and retrieves results.
>
> My main work with jxta is involved with jxtaSpaces, a distributed shared
> memory service which creates a distributed tuple-space (similiar to
> javaSpaces, Linda, ...). POV_Ray seemed like a good demonstration use
> of that concept. (jxtaspaces.jxta.org)
>
> I was wondering:
> (1) is there any interest on this list in this project
> (2) any volunteers to help test/criticize/suggest/B&Moan/...
(1) yes
(2) yes
i have a similar project, just in case you want to compare
it with yours.. that one does the job in perl and povdos
on a tcp/ip network; i use a somewhat xml-ish message
syntax to pass files around.
- see my .sig, there you'll find it.
i will have a look at this jxta stuff first - after i'll
had some sleep :) - but keep me informed, please!
gimi
--
http://www.psico.ch/
povray remote render server:
http://www.psico.ch/prs.shtml
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
gimi wrote:
> Tom Dengler wrote:
> > Jxta is a p2p protocol (www.jxta.org).
>
> never heard of that. how do you pronounce that? :)
jucks tah (as in juxtapose)
> i have a similar project, just in case you want to compare
> it with yours.. that one does the job in perl and povdos
> on a tcp/ip network; i use a somewhat xml-ish message
> syntax to pass files around.
> gimi
>
> --
> http://www.psico.ch/
> povray remote render server:
> http://www.psico.ch/prs.shtml
I took a quick look. I don't know perl well enough to see how it
compares? I started with a base of the povray3.1g and the pvm patch.
The pvm patch allows a frame render to be split into 32x32 pixel
blocks. These blocks are the basis of distributetion.
I would guess that the major difference would be that the pvm model is
standardized, and the pvm patch has a bit of history to it. This
history presumes some level of prior user debugging.
The jxta layer would bring a 'standardized' protocol to the table, but
probably more importantly, the ability to self-discover peer machines
that are participating in the rendering process. In a way of
comparison, Napster/Gnutella is a p2p network facilitating the
search/discovery of mp3 files; a jxta-povray would facilitate the
search/discovery of rendering resources.
tom
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom Dengler wrote:
> I took a quick look. I don't know perl well enough to see how it
> compares? I started with a base of the povray3.1g and the pvm patch.
> The pvm patch allows a frame render to be split into 32x32 pixel
> blocks. These blocks are the basis of distributetion.
Just in case it saves you some time while debugging... be aware that the
"usual" PVM patch carries a good load of serious bugs which have been
fixed in the PvMegapov version, but these fixes were never backported.
Anyway the principles work (at least for 3.1; we'll see in a few months
how deep the main loop modifications in 3.5 are and thus how impossible
it will be to maintain the patch).
At least it is much better than using external scripting...
--
__ __ __ __ _
| | / \ / / |_ / |/
\/\/ \__/ /_ /_ |__ \_ |\
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Francois Dispot wrote:
> Just in case it saves you some time while debugging... be aware that the
> "usual" PVM patch carries a good load of serious bugs which have been
> fixed in the PvMegapov version, but these fixes were never backported.
> Anyway the principles work (at least for 3.1; we'll see in a few months
> how deep the main loop modifications in 3.5 are and thus how impossible
> it will be to maintain the patch).
> At least it is much better than using external scripting...
Thanks for the heads-up Francois.
I downloaded the pvmegasrc.010311.tar.bz2 file, which has the #ifdef
PVMPOV stuff in it. Is this available as a patch to some base MegaPov
source?
tom
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom Dengler wrote:
> I was wondering:
> (1) is there any interest on this list in this project
Yes.
> (2) any volunteers to help test/criticize/suggest/B&Moan/...
Yes.
I'm finally getting life to settle down a little, so I can get back into
the fun world of POV-Ray.
BTW, I'm a software engineer with over 10 years experience, and doing
professional Java for 5 or so.
--
Wind the Frog!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
