 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I can't prove anything but somehow I feel below can cause some kind of error
(crash, bad image, etc). I wonder about radiosity in animation. I have SCENE.POV
script with scene of animation with radiosity. Then I start two instances of
POV-Ray:
first: +KFF100 +EF50 +ISCENE.POV
second: +KFF100 +SF51 +ISCENE.POV
but during trace proces there is only one file SCENE.RCA. Is it good behavior ?
Both images are different - objects move. I don't use save/load feature of
radiosity but I can imagine somebody can. Shouldn't RCA file be named like
currently rendered image ? Of course I'm talking about 3.5.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Włodzimierz ABX Skiba <abx### [at] babilon org> wrote:
> but during trace proces there is only one file SCENE.RCA. Is it good behavior ?
> Both images are different - objects move. I don't use save/load feature of
> radiosity but I can imagine somebody can. Shouldn't RCA file be named like
> currently rendered image ? Of course I'm talking about 3.5.
That's exactly how it works. It uses one file for the radiosity data tree.
When the rendering finishes, it deletes this temporary file.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8 Apr 2002 13:13:28 -0400, Warp <war### [at] tagpovrayorg> wrote:
> > but during trace proces there is only one file SCENE.RCA. Is it good behavior ?
> > Both images are different - objects move. I don't use save/load feature of
> > radiosity but I can imagine somebody can. Shouldn't RCA file be named like
> > currently rendered image ? Of course I'm talking about 3.5.
>
> That's exactly how it works. It uses one file for the radiosity data tree.
> When the rendering finishes, it deletes this temporary file.
but... is it safe when two applications write data to one RCA file ?
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
so running multiple versions of the same filename (in the same path,
on the same machine, of course) with different data parallel will
work wrong ... Is this what you said?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jan Walzer <jan### [at] lzernet> wrote:
> so running multiple versions of the same filename (in the same path,
> on the same machine, of course) with different data parallel will
> work wrong ... Is this what you said?
POV-Ray does not support parallel rendering. Thus collisions can happen.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Włodzimierz ABX Skiba <abx### [at] babilonorg> wrote:
> but... is it safe when two applications write data to one RCA file ?
POV-Ray is not designed to perform parallel raytracing.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
but it would be a "minor" change (in the next MegaPov, of course) to build
a hash 'bout the parsed Code, and its "variables" to have a unique identifier
for this File, one could append ....
... but thats probably just a silly idea (Hey, its early morning here, isn't it ? ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 9 Apr 2002 09:01:15 +0200, "Jan Walzer" <jan### [at] lzernet> wrote:
> but it would be a "minor" change (in the next MegaPov, of course) to build
> a hash 'bout the parsed Code, and its "variables" to have a unique identifier
> for this File, one could append ....
unique identifier is a name of current image becouse it contains number of
frame.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8 Apr 2002 15:59:31 -0400, Warp <war### [at] tagpovrayorg> wrote:
> > but... is it safe when two applications write data to one RCA file ?
>
> POV-Ray is not designed to perform parallel raytracing.
so another thing to do for me in patching time
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
what if someone makes use of some "external-parameters" such as current
time/date, to make a nice watch ? ...
... and maybe, he doesn't want an animation ... ? ... and he starts it
at different times while the first one is still running ...
So what is left, if the filename (and "frame") is the same ?
hence I said, that probably a hash of a memdump (after parsing) is
necessary, to create a unique ID
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 9 Apr 2002 15:24:56 +0200, "Jan Walzer" <jan### [at] lzernet>
wrote:
>hence I said, that probably a hash of a memdump (after parsing) is
>necessary, to create a unique ID
An MD5 checksum of all the memory reserved by POV right after parsing
:)
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Peter Popov" <pet### [at] vipbg> wrote:
> An MD5 checksum of all the memory reserved by POV right after parsing
> :)
thats what I meant ...
... but wouldn't the creation of this MD5 mean, that the memory reserved
by POV will change? ... doesn't that make the MD5 invalid ?
... no ? .. ok ... then do so ...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 08 Apr 2002 14:22:23 +0200, W�odzimierz ABX Skiba <abx### [at] babilonorg>
wrote:
> I can't prove anything but somehow I feel below can cause some kind of error
> (crash, bad image, etc). I wonder about radiosity in animation. I have SCENE.POV
> script with scene of animation with radiosity. Then I start two instances of
> POV-Ray:
> first: +KFF100 +EF50 +ISCENE.POV
> second: +KFF100 +SF51 +ISCENE.POV
> but during trace proces there is only one file SCENE.RCA. Is it good behavior ?
> Both images are different - objects move. I don't use save/load feature of
> radiosity but I can imagine somebody can. Shouldn't RCA file be named like
> currently rendered image ? Of course I'm talking about 3.5.
Have anybody tested something similiar for OS on cluster of computers? with
3.5 or 3.1 ? I'm interested in results. Thanks.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
I have been rendering radiosity images on clusters for a few weeks now.
I am doing *absolutely nothing* to prevent/deal with the supposed
"artifacts" that distributed radiosity rendering creates. I cannot see
any rendering artifacts. Could someone please explain what these
artifacts would look like & possibly point them out in the following
images?
http://homepages.ucalgary.ca/~psmacmur/images/poppy640.png
This was rendered with SMPOV in 16 horizonal strips (Tiled 1x16)
http://homepages.ucalgary.ca/~psmacmur/images/beanstalk_potted_500x700.png
This was rendered on several computers but i forget which or how many:
http://homepages.ucalgary.ca/~psmacmur/images/beanstalk_potted_filter_1500x2100.jpg
This hi-res version of the previous model was rendered in 4 horizontal
strips on SGIs using distribution/reassembly code based on Paul
Bourke's:
http://astronomy.swin.edu.au/~pbourke/povray/parallel/
All use radiosity in conjunction with a very large dense area light.
"Włodzimierz ABX Skiba" wrote:
>
> On Mon, 08 Apr 2002 14:22:23 +0200, Włodzimierz ABX Skiba <abx### [at] babilonorg>
> wrote:
> > I can't prove anything but somehow I feel below can cause some kind of error
> > (crash, bad image, etc). I wonder about radiosity in animation. I have SCENE.POV
> > script with scene of animation with radiosity. Then I start two instances of
> > POV-Ray:
> > first: +KFF100 +EF50 +ISCENE.POV
> > second: +KFF100 +SF51 +ISCENE.POV
> > but during trace proces there is only one file SCENE.RCA. Is it good behavior ?
> > Both images are different - objects move. I don't use save/load feature of
> > radiosity but I can imagine somebody can. Shouldn't RCA file be named like
> > currently rendered image ? Of course I'm talking about 3.5.
>
> Have anybody tested something similiar for OS on cluster of computers? with
> 3.5 or 3.1 ? I'm interested in results. Thanks.
>
> ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 20 Jan 2004 15:27:52 -0700, Peter MacMurchy wrote:
What a beautiful plants, and, indeed, I cannot see artifacts too.
But I have to ask: how do you generate these plants...do you happen
to be linked to the L-systems group ?
Willem
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I have been rendering radiosity images on clusters for a few weeks now.
> I am doing *absolutely nothing* to prevent/deal with the supposed
> "artifacts" that distributed radiosity rendering creates. I cannot see
> any rendering artifacts. Could someone please explain what these
> artifacts would look like & possibly point them out in the following
> images?
I don't know, but it is easy to test: render the same image using a
single computer and a cluster and calculate the difference of the two
images. If you get only zeros, then there is no difference.
Severi S.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter MacMurchy wrote:
> Hello,
>
> I have been rendering radiosity images on clusters for a few weeks now.
> I am doing *absolutely nothing* to prevent/deal with the supposed
> "artifacts" that distributed radiosity rendering creates. I cannot see
> any rendering artifacts. Could someone please explain what these
> artifacts would look like & possibly point them out in the following
> images?
> [...]
These images already look quite near to the correct lighting solution -
in such cases the problems of tiled renders without sharing radiosity
data will of course diminish because all tiles converge to the same
correct solution.
Still it will be quite inefficient not to share the data because this
way many calculations are redundant.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thank you! Yes, indeed, the plants' skeletons are generated using
L-systems, which are coded in the locally-developed L-Studio. The
output of the L-systems are then passed to my research software, which
generates subdivision surfaces.
Willem de Wilde wrote:
> On Tue, 20 Jan 2004 15:27:52 -0700, Peter MacMurchy wrote:
>
> What a beautiful plants, and, indeed, I cannot see artifacts too.
>
> But I have to ask: how do you generate these plants...do you happen
> to be linked to the L-systems group ?
>
> Willem
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I can't speak to clustering, but the screens you link to (very nice,
BTW) are not ones prone to radiosity artifacts. You have strong
textures and mostly curved surfaces both of which tend to hide lighting
imperfections. If you want to find where artifacts may have occurred
use a plane white texture in one of your renders. That tends to make
any artifacts stand out.
Peter MacMurchy wrote:
> Hello,
>
> I have been rendering radiosity images on clusters for a few weeks now.
> I am doing *absolutely nothing* to prevent/deal with the supposed
> "artifacts" that distributed radiosity rendering creates. I cannot see
> any rendering artifacts. Could someone please explain what these
> artifacts would look like & possibly point them out in the following
> images?
>
> http://homepages.ucalgary.ca/~psmacmur/images/poppy640.png
> This was rendered with SMPOV in 16 horizonal strips (Tiled 1x16)
>
> http://homepages.ucalgary.ca/~psmacmur/images/beanstalk_potted_500x700.png
> This was rendered on several computers but i forget which or how many:
>
> http://homepages.ucalgary.ca/~psmacmur/images/beanstalk_potted_filter_1500x2100.jpg
> This hi-res version of the previous model was rendered in 4 horizontal
> strips on SGIs using distribution/reassembly code based on Paul
> Bourke's:
> http://astronomy.swin.edu.au/~pbourke/povray/parallel/
>
> All use radiosity in conjunction with a very large dense area light.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
