[Radiance-general] Re: water - any news???

[Greg Ward]

Hi Guilio,

If you're really going to attempt this, I can offer a few more  
pointers.  For the underwater bin computations, you want bin numbers  
to correspond to colorpict pixels in scanline order.  For the floor  
of the pool, you might define the following bin definition based on a  
5x15 meter bottom with the origin at (0,0):

FloorXres : 50;
FloorYres : 150;
FloorWidth : 5 {meters};
FloorOrigX : 0;
FloorHeight : 15 {meters};
FloorOrigY : 0;
floor_bin = floor(FloorYres*(Py - FloorOrigY)/FloorHeight  + .5) 
*FloorXres
			+ floor(FloorXres*(Px - FloorOrigX)/FloorWidth + .5);

The same approach would be used for the walls of the pool, with  
slightly different coordinate mappings.  You could put all these  
together in the same file, call it "pool_coords.cal".  The rtcontrib  
command line would resemble this:

	vwrays -vf pool_par.vf -x 1000 -y 1000 -ff \
		| rtcontrib -V+ -ff -f pool_coords.cal \
			-b floor_bin -bn 7500 -o '!total -if22500 | pvalue -r -h +Y 150 +X  
50 -df > floor_caustics.pic' -m floor \
			-b s_wall_bin -bn 3000 -o '!total -if9000 | pvalue -r -h +Y 30 +X  
100 -df > s_wall_caustics.pic' -m s_wall \
			-b n_wall_bin -bn 3000 -o '!total -if9000 | pvalue -r -h +Y 30 +X  
100 -df > n_wall_caustics.pic' -m n_wall \
			-b e_wall_bin -bn 5000 -o '!total -if15000 | pvalue -r -h +Y 50 +X  
100 -df > e_wall_caustics.pic' -m e_wall \
			-b w_wall_bin -bn 5000 -o '!total -if15000 | pvalue -r -h +Y 50 +X  
100 -df > w_wall_caustics.pic' -m w_wall \
			pool.oct

I made up the dimensions for the other surfaces, but I hope this  
makes sense.  The actual view you use and resolution out of vwrays  
doesn't much matter, as it just gets summed up by "total" into the  
appropriate images.  Note that the standard compile of "total" won't  
work, since it has a hard limit of 256 for the number of columns, and  
we're trying to sum RGB for each pixel, here.  So, you'll have to  
recompile it and set MAXCOL to 22500 or greater to get this to work.   
If it does, maybe I'll consider a little rewrite of the utility to  
take away the column limit and make it dynamic.  Bit of a hassle, but  
possibly worth it.  I couldn't figure out how else to get this kind  
of result without a lot of scripting.

I expect most of the time in this command to be spent sending data  
between rtcontrib and the 5 "total" processes.  The actual ray  
tracing part will shrink to insignificance.

Best of luck!
-Greg

------
Demostration of rtcontrib in two stages.  The first computes
contributions as a function of angle from a window (divided into
three sections) and three skylights connected to a light pipe.
The second stage computes the incidence of sky illumination on these
portholes, and the results are combined.  There are two main scripts,
run like so:

runrtcont.csh
runsums.csh

The first handles the two main stages, whose results are put into
src_cont/ and src_dc/ respectively.  The second script combines
the results into daylight coefficient pictures in the dc_cont/
folder.  A final script combines these into a result for a particular
date and time, e.g.:

sumpicture.csh 5 10 14:00PDT -g .12 > sunny5_10_14.pic


-------------- next part --------------
A non-text attachment was scrubbed...
Name: runrtcont.csh
Type: application/octet-stream
Size: 2774 bytes
Desc: not available
Url : http://radiance-online.org/pipermail/radiance-general/attachments/20071114/700c7f2b/runrtcont-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: runsum.csh
Type: application/octet-stream
Size: 572 bytes
Desc: not available
Url : http://radiance-online.org/pipermail/radiance-general/attachments/20071114/700c7f2b/runsum-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sumpicture.csh
Type: application/octet-stream
Size: 374 bytes
Desc: not available
Url : http://radiance-online.org/pipermail/radiance-general/attachments/20071114/700c7f2b/sumpicture-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: comp_pcargs.csh
Type: application/octet-stream
Size: 1454 bytes
Desc: not available
Url : http://radiance-online.org/pipermail/radiance-general/attachments/20071114/700c7f2b/comp_pcargs-0001.obj
-------------- next part --------------

> From: "Giulio Antonutto" <Giulio.Antonutto at arup.com>
> Date: November 14, 2007 9:48:43 AM PST
>
> Greg,
> this is a great idea!
> We will definitely look into it (perhaps not today but soon enough).
> rtcontrib is just surprising every day with its potential...
> thanks for your help,
> and thanks for calling it 'not easy'...
> this make a failure less of a problem
> :-)
> Ciao
> G.
>
> -----Original Message-----
> From: radiance-general-bounces at radiance-online.org
> [mailto:radiance-general-bounces at radiance-online.org] On Behalf Of  
> Greg
> Ward
> Sent: 14 November 2007 04:02
>
> Hi Guilio,
>
> I'm still catching up with e-mail after a week's absence.  This one
> also required some thought...
>
> It would be a fair amount of work, but it's possible to use rtcontrib
> to give you a nice incident light field on the bottom of a swimming
> pool.  You could then model this as a glow source and see it
> reflected back through the wavy dielectric surface of the water.  If
> you were extra-ambitious, you could even model the water's surface as
> a height field, but it would have to be really choppy for that to
> even matter, visually.
>
> I would have to spend some time to create an example of this
> approach, but the basic idea is to flag the surfaces defining the
> underwater portion of the pool so they can gather rays using
> rtcontrib.  You would have to also define bin numbers corresponding
> to pixels in (5) low-resolution images you would create and map back
> onto the surfaces for subsequent rendering.  The rays given to
> rtcontrib would correspond to the solar radiation on a rectangle
> covering the pool's surface.  Normalization for this data would
> require a bit of math as well, but it's all doable.  I won't call it
> easy.
>
> -Greg