Hi to all on the list,
this is my first message to the list although I have followed for a quite long time. I have the impresson that all the experts are on this list and so I have the hope that someone can help me with my problem.
At the moment I am working on a quite big model. I exported it from 3DS to Radiance with the help of ConRad an got about 570000 faces. The octree is 162MB. I use Radiance 3.1.20 on a Linux Cluster.
The model runs fine as long as I render small pictures up to about 1000x1000 pixels. But if I try to render larger pictures I get results as the attached one. The dark area on the left of the picture is wrong. Mappings and lighting is lost.
This Picture was done on the cluster with the help of rpiece. The renderings starts on the right upper corner and ends on the left lower. It is allways so that this errors happen in areas of the picture which are rendered later. I also have tried to render it on one single engine and got a simmilar effect again more to the end of the picture.
Does anybody have any idea what is wrong here?
Many thanks and best regards
Martin Klingler
···
----------------------------------------------------------------
Lichttechnik Martin Klingler
Kaplanstrasse 2
A-6063 Rum/Innsbruck
Tel ++43-512-206057
Fax ++43-512-206047
email mkli@netway.at
Martin:
There is some diagnostic/descriptive information that could be helpful to allow people to better understand what is going on and suggest possible solutions:
* What is the configuration of your cluster? How many nodes? What clustering mechanism (nfs or something more advanced)?
* Which version of the Linux kernel are you using? Correct functioning of rpiece is dependent on file locking. So depending on the kernel and cluster configuration this may be part of your problem.
* How is the scene configured? What kind of lighting is used? How many lights?
* How long does the image take to render (on a single machine at small size vs large size on the cluster)?
It would also be helpful if you could also provide an example of the image as it should "correctly" appear (perhaps one of the smaller renderings that you have successfully produced). This way people can better understand what is going on in the scene. In all honesty, while the octree may appear to be large, 570,000 polygons is not a lot of
geometry for Radiance.
Regards,
-Jack de Valpine
Martin Klingler wrote:
···
Hi to all on the list,
this is my first message to the list although I have followed for a quite long time. I have the impresson that all the experts are on this list and so I have the hope that someone can help me with my problem.
At the moment I am working on a quite big model. I exported it from 3DS to Radiance with the help of ConRad an got about 570000 faces. The octree is 162MB. I use Radiance 3.1.20 on a Linux Cluster.
The model runs fine as long as I render small pictures up to about 1000x1000 pixels. But if I try to render larger pictures I get results as the attached one. The dark area on the left of the picture is wrong. Mappings and lighting is lost.
This Picture was done on the cluster with the help of rpiece. The renderings starts on the right upper corner and ends on the left lower. It is allways so that this errors happen in areas of the picture which are rendered later. I also have tried to render it on one single engine and got a simmilar effect again more to the end of the picture.
Does anybody have any idea what is wrong here?
Many thanks and best regards
Martin Klingler
----------------------------------------------------------------
Lichttechnik Martin Klingler
Kaplanstrasse 2
A-6063 Rum/Innsbruck
Tel ++43-512-206057
Fax ++43-512-206047
email mkli@netway.at
------------------------------------------------------------------------
Name: KL21z3.jpg
KL21z3.jpg Type: JPEG Image (image/jpeg)
Encoding: base64
--
# John E. de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
Hi Martin !
Somehow this reminds me of something. Last year I produced some big renderings on a Linux-Cluster, too, and once I got a weird result looking quite similar to yours. (It's a pity that I've already deleted the picture, so there's no comparison possible anymore.)
Altogether I've put my experience into the following words: "If things take too long, they go wrong."
So that's from the heart. Now back to a more rational strategy:
possible crucial points
- that ... lock manager.
rpiece depends on it, as John already pointed out (or was it Jack ? by the way, John, or Jack, are you Jack or are you John ?) The Linux-Version of the lock manager is not comparable to the UNIX one, (maybe this has already changed ??) , as I understood it, the Linux one doesn't really distinguish between read and write, anyway, the shared file
gets messed up
- the model
try to separate it into several smaller octrees. When looking at your image I wonder where the 162 MB are, perhaps there is some way of optimising the model, too ?
- parameters/light sources (again, already asked by John)
I have the assumption, that is has to do something with the time needed (see above), which depends of course strongly on those two points. I rendered pictures of 7000 x 5000 pixels and higher on octrees summing up to 20-50 MB without problems (on a 5-node cluster), but when things lasted longer than two days, several blocks "faded away" into dark
gray. (By the way, I used an especially developed PVM-based parallel Radiance, so I don't have the lock-manager problem.)
So long for now. It would be interesting to get some more Information, the things John asked for. Then in return - maybe- more advice is possible. Lets see..
-Carsten
Hi Martin,
Your rpiece result with dark blocks is what I might expect if the output buffer position gets off by one byte, though I would expect the colors to shift dramatically as well. I might be able to give you some better help if you can compress the picture file and put it on a website somewhere that I can retrieve it. I looked at the rpiece code, and there are plenty of places where NFS could screw up, or it may be that there is a detail about the fcntl() file locking call I don't know, and it ends up modifying what I supposed was a read-only parameter.
It's also possible that there is a bug I fixed a long time ago in rpiece, and you just need the newer version. Try downloading the latest (3.4) release of Radiance from http://radsite.lbl.gov/radiance and do a diff between the src/util/rpiece.c file there and the one in your code tree. Send it to me.
-Greg
···
From: Martin Klingler <mkli@netway.at>
Date: Wed Apr 10, 2002 12:31:41 AM US/Pacific
To: gward@lmi.net
Subject: AW: problem reading attachment
Hi Greg,
many thanks for your answer.
I have tried this but it looks like that something is wrong with my mail encoding or simmilar. I can not read my messages on the maillist archive.
On the other hand, I got a replay to my first message from Marina. She was able to read the message and also to read the attachment, so I am quite confused at the moment.
Maybe You have the possibility to have a short look at my problem?
In every case I have attached the picture and this was my message:
Hi Martin,
Now that you mention it, I think this is not a bug in rpiece, but a bug I fixed in the expression evaluation code. After 2^32 evaluations, the expression clock was wrapping and causing expression results to go stale (expressions are anything from a .cal file, including picture mapping coordinates and sky functions). This would have the effect you noticed on large pictures, but wouldn't affect shorter renderings.
This bug has been fixed in version 3.4, and you should rerun your simulation with the new version to check if the problem goes away. Be sure to pick up the 3.4.1 patch release while you're at it.
-Greg
···
From: Martin Klingler <mkli@netway.at>
Date: Fri Apr 12, 2002 04:52:21 AM US/Pacific
To: gward@lmi.net
Subject: AW: Re: Problem with big pictures
Hi Greg,
attached you find the picture file and also the result of the diff between the version I use und 3.4.
Do you really think that is has to do with rpiece. I get a simmilar error, loss of illumination and picture mapping, if I do the same pictue on one computer just with rpict.
Best regards
Martin
Great -- I'm very relieved that this was the problem.
-Greg
···
Begin forwarded message:
From: Martin Klingler <mkli@netway.at>
Date: Fri Apr 26, 2002 05:25:26 AM US/Pacific
To: gward@lmi.net
Subject: AW: Re: Re: Problem with big pictures
Hi Greg,
thanks a lot, that was the problem.
It took me quite a long time to update my production system, but now the first rendering just finished after 50 hours and it looks fine.
Best regards
Martin
----------------------------------------------------------------
Lichttechnik Martin Klingler
Kaplanstrasse 2
A-6063 Rum/Innsbruck
Tel ++43-512-206057
Fax ++43-512-206047
email mkli@netway.at
-----Urspr�ngliche Nachricht-----
Von: gward@lmi.net
An: Klingler Martin
Datum: 12.04.2002 19:40:28
Betreff: Re: Re: Problem with big pictures
Hi Martin,
Now that you mention it, I think this is not a bug in rpiece, but a bug
I fixed in the expression evaluation code. After 2^32 evaluations, the
expression clock was wrapping and causing expression results to go stale
(expressions are anything from a .cal file, including picture mapping
coordinates and sky functions). This would have the effect you noticed
on large pictures, but wouldn't affect shorter renderings.
This bug has been fixed in version 3.4, and you should rerun your
simulation with the new version to check if the problem goes away. Be
sure to pick up the 3.4.1 patch release while you're at it.
-Greg
From: Martin Klingler <mkli@netway.at>
Date: Fri Apr 12, 2002 04:52:21 AM US/Pacific
To: gward@lmi.net
Subject: AW: Re: Problem with big pictures
Hi Greg,
attached you find the picture file and also the result of the diff
between the version I use und 3.4.
Do you really think that is has to do with rpiece. I get a simmilar
error, loss of illumination and picture mapping, if I do the same
pictue on one computer just with rpict.
Best regards
Martin