You need a -bn option. The new version of rtcontrib (now called rcontrib) prints an error message when it's missing. The original version attempts to muddle through, but can create incomplete output in the process.
-Greg
···
From: kyle konis <[email protected]>
Date: June 30, 2012 2:00:33 PM PDT
Having sorted out my Radiance v4.1 installation, i am proceeding along
in AXEL's rtcontrib tutorial and have encountered a bizarre error when
i try to render the 145 + 1 images (p.16) that make up the sky
hemisphere:
vwrays -ff vw | rtcontrib @rtc\.opt \-ffc \\
(vwrays -d $vw) -V+ -f tregenza.cal -b tbin \
-o images/patches/p%03d.hdr \
-m sky_glow testroom_whitesky.oct
All of the 146 images are about 1.4 MB, but when i try to open them in
Photosphere, i get the following error message :
"Truncated file: unexpected EOF (scanline 597)"
Is there something obvious i am missing here?
It appears that others have successfully worked their way through this
section, so perhaps again it is a setting on my machine.
However, i have SUCCEEDED in generating the 146 images for an interior
view from Andy's 3-phase tutorial (uses many of the same scene files)
as such:
vwrays -ff -vf views/back.vf -x 600 -y 600 | \
rtcontrib `vwrays -vf views/back.vf -x 600 -y 600 -d` -ffc \
-fo -o images/vmx/window_%03d.hdr \
-f cal/klems_int.cal -b kbinS -bn Nkbins -m windowlight \
-ab 2 -ad 1000 -ds .15 -lw 1e-4 model_vmx.oct
Any suggestions would be appreciated !
-Kyle
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
Hi Kyle,
Patch 0 is indeed the ground plane. If you didn't specify a ground in your scene description (i.e., no source with negative-Z) then this will be black. Photosphere doesn't know what to do when you give it a black HDR image.
-Greg
···
From: kyle konis <[email protected]>
Date: June 30, 2012 4:37:07 PM PDT
I have added the -bn option and now have a good batch of sky subdivisions.
vwrays -ff vw | rtcontrib \-bn 146 @rtc\.opt \-ffc \\
(vwrays -d $vw) -V+ -f tregenza.cal -b tbin \
-o images/patches/p%03d.hdr \
-m sky_glow testroom_whitesky.oct
and a nice visualization with Andy's previous response to Ji:
cnt 146 | rcalc -e '$1=rand(recno);$2=rand(recno+.3);$3=rand(recno+.7)' | \
dctimestep ./images/patches/p%03d.hdr > ./images/sky_colorcomb.hdr
...
I am still a bit confused regarding patch p000.hdr
When i attempt to open in Photosphere, i get : "Cannot map HDR pixels
in MapSubimage"
Since the sky only needs 145 patches, the purpose of this p000.hdr is
a mystery. (Although i recall reading something about is purpose late
last night . . . a placeholder for the ground reflection if it is
added . . . ?)
-Kyle
You can check if an image is all-black by running "pextrem" on it and checking the output.
-Greg
···
From: Ji Zhang <[email protected]>
Date: June 30, 2012 9:44:55 PM PDT
Dear list, following Kyle's post:
I was trying to render an image for the view from the back of the room regarding the contribution from each of the 145 sky patches (Axel's tutorial pp. 17)
The 146 individual sky patches hdr sterographic images are stored in the "145_patches_rcontrib" directory.
Then I ran the following bash shell script:
DIMS=600
vw="-x $DIMS -y $DIMS -vf ./views/back.vf"
vwrays -ff vw | rcontrib \-bn 146 @\./rtc\.opt \\
\-fo \-ffc (vwrays -d $vw) -f tregenza.cal -b tbin \
-o ./145_patches_rcontrib/p%03d.hdr -m sky_glow \
-w ./testroom_whitesky.oct
Each of the 146 sky patch hdr images was replaced by a room view rendering. However, some of the hdr images seem to have problem and can't be open with PhotoSphere, such as p001-008, p024-038, p054-066, p080-090, p104-113, p123-129, p137-140, and p144
May I ask if this is because no contribution from these specific sky patches to the visible surfaces can be identified from this point of view at the back of the room (e.g. the sky patch is "behind" the vertical window plane judging from the change of the shadow pattern of the renderings) ?
Thanks!
- Ji