[Radiance-general] Generating alpha channels using vwrays and rtrace

[Greg Ward]

That's the general idea.  I suppose you could try to generate it automatically.  You could also have a final substitution that matches anything non-numeric as a catch-all for materials you don't name in a regex.  E.g:

s/^mat1	/0.35	/
s/^mat2	/1.0	/
s/^mat3	/0.0	/
s/^mat4	/0.75	/
s/^[^.0-9][^	]*	/0.0	/

Note that what appear to be spaces above are actually tabs, including the "[^	]" bit in the last line (very important).

Make sense?
-Greg

> From: Jack de Valpine <jedev at visarc.com>
> Date: February 25, 2012 11:08:31 AM PST
> 
> Hey Greg,
> 
> Many thank! So in this method alphas.txt is a file that you generate by hand of material names and values using regex notation?
> 
> -Jack
> 
> On 2/25/2012 12:28 PM, Greg Ward wrote:
>> Hi Jack,
>> 
>> It would be nice if rcalc were smart about strings, but all it can really do is pass them from one place in the input to another place in the output.  It never looks at them, really, and none of the operations supports strings.
>> 
>> Regarding your second idea of including the material along with the value, you can do this with rcalc as written.  You would have to go for an ascii output, like so:
>> 
>> vwrays -ff [args] | rtrace -h `vwrays -d [args]` -ffa -omv [rargs] octree | sed -f alphas.txt>  alphaval.txt
>> 
>> The file "alphas.txt" would contain something like:
>> 
>> s/^mat1	/0.35	/
>> s/^mat2	/1.0	/
>> s/^mat3	/0.0	/
>> s/^mat4	/0.75	/
>> [etc.]
>> 
>> This would replace each material with an associated alpha value.  From there, you would have to convert to 16-bit RGBA or something if you wanted to load it into Photoshop, and I think you would need a C program for that.  Alternately, you could split the file using rcalc and pvalue like so:
>> 
>> rcalc -e '$1=$1' -of alphaval.txt | pvalue -h -y $YRES +x $XRES -df -b>  alpha.hdr
>> rcalc -e '$1=$2;$2=$3;$3=$4' -of alphaval.txt | pvalue -h -y $YRES +x $XRES -df>  image.hdr
>> 
>> Photoshop can load, convert, and combine HDR files, though you probably have to change from 32-bit to 16-bit mode when you do.  Just make sure not to use any of the fancy tone-mappers when you do....
>> 
>> I'm not sure the above would be any faster than Iebele's current method, but it would avoid separate rtrace steps.  This permits you to use the -pj option of vwrays safely, as you won't risk sampling one object in one run and another object in another.  (Pseudorandom sequences should guarantee this in any case, but I'm not sure they do on all systems.)
>> 
>> Cheers,
>> -Greg