 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] lzer net>
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
>
> 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
|
|
| |
| |
|
|
|
|
| |
