Hi List!
Finally, I've put my email address onto this list, nice to have
radiance-online.org!
And here's my first question:
I am trying to render a quite complex model (imported from CAD, and
there are no
instances, so it takes a lot of memory). If I try to get better quality
and higher
resolution, rpict gives me an error:
[...]rpict: 6581491 rays, 49,87% after... [...]
rpict: consistency - address not found in avlmemi
rad: error rendering view 1
I did this on a netfinity with a lot of ram and two pIII-833. But in
fact, the
machine is a fileserver... so is this error the result of insufficient
memory?
I have installed 3r2p11. On Linux 2.4.4 (SuSE 7.0).
BTW, as I know that Georg Mischler is on the list: dxf2rad is a great
way to import
data from formZ!!! I wrote dxfr14 and translated it with dxf2rad, it
works perfectly!
So this is an alternative besides the obj-way and the
3ds/mgf/rad-conversion.
Thank You, CU, Lars.
BTW: I just found patch 20, I never found it on the ftp. I will try
this, too.
Hi List!
Says the person who still owes me a materials tutorial for
Rayfront... 
And here's my first question:
I am trying to render a quite complex model (imported from CAD,
and there are no instances, so it takes a lot of memory). If I
try to get better quality and higher resolution, rpict gives me
an error:
[...]rpict: 6581491 rays, 49,87% after... [...]
rpict: consistency - address not found in avlmemi
rad: error rendering view 1
I did this on a netfinity with a lot of ram and two pIII-833. But
in fact, the machine is a fileserver... so is this error the
result of insufficient memory?
I have installed 3r2p11. On Linux 2.4.4 (SuSE 7.0).
Radiance 3.2 is "experimental" and was never officially released.
Technically, this error points to corrupted ambient data.
Your problem will most likely go away when you try with 3R1p20.
BTW, as I know that Georg Mischler is on the list: dxf2rad is a
great way to import data from formZ!!! I wrote dxfr14 and
translated it with dxf2rad, it works perfectly!
So this is an alternative besides the obj-way and the
3ds/mgf/rad-conversion.
Cool!
Is there anything you need to set up correctly on the formZ side
for this to work? In particular, does formZ automatically create
seperate layers, so that dxf2rad can use different modifier
names? You could earn yourself at least a pat on the back and
a honorable mention by writing a very short description of the
exact procedure for my web site.
Have fun!
-schorsch
···
--
Georg Mischler -- simulations developer -- schorsch at schorsch.com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
Hi!
Georg Mischler wrote:
> Hi List!
Says the person who still owes me a materials tutorial for
Rayfront...
Sorry... I haven't been able due to a lot of problems - e.g. buggy
versions of radiance, the fact that Rayfront doesn't run on alphas
(and for the last months, I only had an alpha, no intel), my bad
planning...
> I have installed 3r2p11. On Linux 2.4.4 (SuSE 7.0).
Radiance 3.2 is "experimental" and was never officially released.
Ooops, again.. I already tried 3.2, but this time, I meant 3r1p11
(the official download link). And p20 gives me the same.
Technically, this error points to corrupted ambient data.
Your problem will most likely go away when you try with 3R1p20.
It doesn't, and that seams to be a problem of memory. I can observe
very nice the free mem going down and the use of radiance going up
...
I just put the p20 source on my alpha, which has enough memory (512MB),
compiled it (I have put a new entry in makeall, containing some options
like -mcpu=ev56 etc for some speed and started the next try. At the
moment, I have rad saying 38%...
Cool!
Is there anything you need to set up correctly on the formZ side
for this to work?
I will send some screenshots when I am at university. I am at my own
machine at the moment, and I don't have formZ here.
CU, Lars.
Hi!
"Lars O. Grobe" wrote:
I just put the p20 source on my alpha, which has enough memory (512MB),
compiled it (I have put a new entry in makeall, containing some options
like -mcpu=ev56 etc for some speed and started the next try. At the
moment, I have rad saying 38%...
Still the same problem, and I get very big ambfiles, about 10 MB. I
think I will try to reduce the model... but it is still a problem, as
I just wanted to test for a project with larger models.
At the moment, I work with a 4MB octree-file.
CU, Lars.
Hi!
It's me again... I had an error in my rif-file. The zone was wrong,
as during the import, units changed from meters to centimeters.
So, I have a model of 1500 x 1500 x 1500, and the zone was
15 x 15 x 15... maybe this caused errors. I just corrected it.
I hope it works now...
CU, Lars.
I don't know quite how to reply to a thread to get the subject right, so
I entered this manually and it may end up in the wrong place. (Help, Peter!)
The rpict error you are getting is due to a broken qsort() routine that
infiltrated the GNU library and keeps resufacing on various versions of
Linux. I'm not sure which ones have it and which ones don't, so the
only thing I can suggest is recompiling ambient.o using the following switch:
-Dtracktime=0
This will turn off the ambient sorting optimization, which won't affect
results but will eliminate this problem. The faulty zone in the .rif
file is not the problem.
Hope this helps!
-Greg
Greg Ward wrote:
I don't know quite how to reply to a thread to get the subject right, so
I entered this manually and it may end up in the wrong place. (Help, Peter!)
The archiver keeps track of the message IDs, so that simply replying
to a message will usually put the reply in the right (indented) place.
Of course, if you just joined and don't have the original message,
then you'll have to live with generating a new thread.
The rpict error you are getting is due to a broken qsort() routine that
infiltrated the GNU library and keeps resufacing on various versions of
Linux. I'm not sure which ones have it and which ones don't, so the
only thing I can suggest is recompiling ambient.o using the following switch:
-Dtracktime=0
This will turn off the ambient sorting optimization, which won't affect
results but will eliminate this problem. The faulty zone in the .rif
file is not the problem.
Ah, finally the official way, so I won't have to publish that old
workaround anymore.
Thanks!
-schorsch
···
--
Georg Mischler -- simulations developer -- schorsch at schorsch.com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
· YªÝº-xhÙ'£
®×¡£hêeÊÚ¶ÞiÛhëm
ë.n7¶¸ Û(!éíz·¶¬©îjYrjwb¶f²zwn¦)í
ì+¢x)§éi=ë^¦Ø^êeÉ»¶â²Ê&{Zµ©¢²È§÷¶êÞyYÆ«r¯zÅ[{Z¶f¢f§ÛZ}êìÛººÞÙrjZai!ú.ÛaÉX§X¬¶f§ja«ÞºÇºV§uù^Æ&åzØZaz»(~Üã2¥êì¢v¥±È^vé^Ëhvazê`§^¡ûazÊ·«zëvÚ+º{az¶©Üzåw¬×¨Çézºì/z»"¢{¢»az¨±ªÞé^jǦ·¬ºf)Zµë.g«ÛM5:wÁær鮫^vj+zIèÂWê'²+^Áéez+az¸Z½æ¬yªÜ
û§rبú+¶Èb½ê+hPéÞ«h¬Ú*'z¬²è zËb¢{0
«_y«në-¡§]¶aË"µêey«ëfzIèÀ÷z³ÞµêÀ¦&§éç{ͪbjx¬yø`uï¸÷¾µã<×m÷Óakjéá¡÷«"{-Ûyú+JZ¬IÞ®ÊË^Àû÷]4·¢nêà
