Thanks Andy! Makes sense, have to align the interior piece as well so the right energy is transferred through.
This solved the issues I was having.
···
From: Andrew McNeil [mailto:[email protected]]
Sent: Friday, April 18, 2014 4:06 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation
Chris,
Your view settings for genklemsamp look appropriate. You also need to rotate the angular bins in your view matrix simulation. You can do this with the -b argument:
-b 'kbin(0,0,1,1,1,0)'
first three values are from the -vd in genklemsamp and the last three values are from the -vu option.
You can use any number of sky divisions, but the number of sky divisions must be the same when generating the sky matrix and daylight matrix. If they are not the same then matrix multiplication won't work.
Andy
On Fri, Apr 18, 2014 at 11:15 AM, Chris Coulter <[email protected]<mailto:[email protected]>> wrote:
To confirm BSDF orientation in the 3-phase steps:
If I have a skylight where the CFS is rotated -45 in the plane of the glass to align w/ site rotation, the daylightmatrix command should look something like this:
genklemsamp -vd 0 0 1 -vu 1 1 0 dmx_surf.rad | rcontrib -c 1000 -ab 2 -ad 1024 -e MF:1 -f reinhart.cal -b rbin -bn Nrbins -m sky_glow model_3ph.oct > daylightmatrix.dmx
I previously had the -vu as 0 1 0, but realized that setting the vu as noted above is probably used to correctly orient the bsdf within the skylight - right? The standard application of a vertical aperture would typically be -vu 0 0 1 (or not expressed, as this would be the default) unless this has a similar orientation adjustment. I know the Direct Sun Coeff Matrix uses physical geomtry w/ the BSDF primative that is oriented in the material description. I realized that my first pass at the daylight matrices didn't account for any rotation and this seems to be the most logical case of how to apply.
Also, is it ok to change the number of sky divisions to MF:2 or higher? I know the klems patches are 145, but didn't know if there was something that would be incorrect in the matrix multiplication stages? I guess maybe it isn't as critical as generally you're trying to make the sun patches smaller, which is what the 5-phase method introduces. Maybe an increase in the accuracy of the diffuse calcs...? If it is acceptable, this would be both in the gendaymtx sky matrix and the daylight matrix pieces (view matrix uses klems)?
Confirmation, or corrections, are greatly appreciated. I'm trying to troubleshoot data and looking into all aspects...
Thanks
Chris
_____________________________________________
From: Chris Coulter [mailto:[email protected]]
Sent: Tuesday, March 04, 2014 11:40 AM
To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation
Thanks, Greg. I knew I had previously changed the ulimit, and verified it was higher than default. I was at 4096 - close but radiance isn't horseshoes or hand grenades.
Chris
From: Greg Ward [mailto:[email protected]]
Sent: Monday, March 03, 2014 12:47 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation
Hi Chris,
Looking at the command you quoted, the "-opn" option to rtrace should be "-opN" for better efficiency, but this isn't what's causing the "broken pipe" error. That indicates that rcontrib is refusing input before rtrace is done supplying it.
The only think I can think of is that you are running out of file descriptors. If using "-e MF:2" instead of "-e MF:6" solves the problem, then this is the most likely cause. The MF:6 setting requires 5186 descriptors. Quoting Thomas Bleicher from a Feb. 2007 post:
On Mac OS X the max number of open files is limited to 256 per
user process. That's pretty low and not sufficient for any subdivision
of the Tregenza sky pattern.
To change the open files limit (on OS X!) I created a file
"/etc/launchd.conf" with the line "limit maxfiles 1024 unlimited"
and I set the kernel limit with "sysctl -w kern.maxfiles=1024".
After a reboot I could set the shell's limit with "ulimit -n 1024".
This can go into your ".profile" if you're going to use it a lot.
Unfortunately, the method for changing the number of allowed descriptors varies from one system to the next. Good luck!
Best,
-Greg
From: Chris Coulter <[email protected]<mailto:[email protected]>>
Date: February 27, 2014 3:47:22 PM PST
That's good to hear...I was just about to upload some images asking for clarification.
Follow-up to the 5-phase process:
I'm using a small CFS model to generate my BSDF, do I need to create an array with the actual geometry covering the full aperture for the Direct Sun Contribution (Cds)?
For rendering - It seems so, otherwise I don't see how the shadow rays are traced that get piped to rcontrib. model_nosuns.oct doesn't have the proxy surface, only physical geometry.
For calc points - Maybe? The model_suns.oct has both physical geometry and proxied geometry.
Although, when I try the as the tutorial states, I get a "rtrace: Broken Pipe" error. My tensor tree BSDF has an error for 110.9% rear reflection.
Just to verify that wasn't an issue, I doubled back to the files used in Andy's tutorial, I also get the error. Code run there was:
vwrays -c 4 -pj 1 -fa -vf views/back.vf -x 500 -y 500 | rtrace -h- -opn -faa -ab 0 octs/model_nosuns.oct | \
rcontrib `vwrays -vf views/back.vf -x 500 -y 500 -d` -n 7 -fac -fo -o viewpics_ds/back_%04d.hdr \
-e MF:6 -f reinhart.cal -b rbin -bn Nrbins -m solar -c 4 -I -ab 1 -ad 100 -dt 0 -dc 1 -lw 1e-2 octs/model_suns.oct
My standard build is the HEAD from 26SEP13, but also tried one from last week (2/21) with no success.
General question if 5-phase is unable to work without full geometry for the CFS, are we then limited to only systems that can be modeled (ie, no lenses, laser cut panels, etc)?
Sorry if I'm all over the place, I started writing this mail at 3p.
Chris
From: Andrew McNeil [mailto:[email protected]]
Sent: Thursday, February 27, 2014 1:54 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation
Chris,
A few weeks ago somebody alerted me to a bug in BSDFViewer for tensor tree BSDFs that flips the transmission front and back. So your tensor tree BSDF is probably fine. My stupid utility has a bug. I'll let you know when I've fixed it and posted a new version.
Andy
On Thu, Feb 27, 2014 at 6:43 AM, Chris Coulter <[email protected]<mailto:[email protected]>> wrote:
Andy/David/Rob - Thanks for the encouragement and suggestions.
I've been working through trying to troubleshoot as I go along. Studying it in a 10m cube so I can easily understand how the light is being redistributed rather than in my full model. I also found that running the CFS through genBSDF with an all black material helpful to digest that specular transmission is occurring as expected.
Andy's reminder that +Z is "in" the space was helpful in making me understand why the Klems bsdf seemed backwards. Now my tensor tree bsdf seems backwards using the same geometry - which is unnerving. I'm reworking the process and will post updates, and inevitably more questions. I was finally able to get Andy's BSDF Viewer to compile in Ubuntu - it was much easier once I realized the network had been disabled and then resolved my proxy issues for the compiler's dependencies. I forgot about bsdf2rad, will look into it.
David, your note was clear. Thanks. My system is grid a 10mm cubes fit into skylights that are 4m x 8m or larger. I think the edge condition can be ignored in the BSDF calculation.
Thanks again all for help here and in the tutorials, presentations, code, etc. Once I can confirm my results are wrong and its not as much of a user error as it likely is, I'll post more info/questions.
Chris
-----Original Message-----
From: Guglielmetti, Robert [mailto:[email protected]<mailto:[email protected]>]
Sent: Wednesday, February 26, 2014 11:40 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] BSDF orientation and implementation
Hi Chris,
What Andy said! To that end, I would add that tools like objview (for visualizing your CFS geometry) and bsdf2rad (for visualizing the BSDF distribution) are very useful for getting comfortable with your generated BSDFs. I am working on a little "test room" model, a la the ltview script but for CFS instead of luminaries. When it's sensible I'll post some results. It's very helpful to visualize these things; Andy's BSDFviewer is awesome, but I also like to mock these things up in Radiance proper so I am certain the functions and the models are are being implemented and oriented correctly, you know what I mean?
- Rob
From: David Geisler-Moroder <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
Reply-To: Radiance discussion <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
Date: Wednesday, February 26, 2014 at 10:34 AM
To: Radiance discussion <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
Subject: Re: [Radiance-general] BSDF orientation and implementation
Hi Chris,
a short note from my side:
Yes, you can import BSDFs of systems into WINDOW and generate new BSDFs including the glass panes of your IGU. Therefore my approach is usually to simulate only the system without any glazing and put the overall system together in WINDOW with the right glass.
Concerning the generation of BSDFs for various applications of a single system you should decide if the kind of system you are simulating is representative for your application. I tend to simulate typical periods of a systems (e.g. for a lamella system you can use the -dim settings to get that right) and model any frame in the geometric model. However, in cases where e.g. the ratio of system thickness to system size dimension is quite high and thus the frame will significantly influence the BSDF, it is better to include the real geometry in the BSDF simulation model. However, you then probably end up generating more than a single BSDF for the same system depending on the applications.
I hope it's somehow clear... if not, let me know and I'll try again 
Cheers,
David
2014-02-26 1:03 GMT+01:00 Andrew McNeil <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>:
Chris,
Everything you write seems correct. One whatch-it I can offer is to make sure you're system is situated properly for the genBSDF run. +Z is into the space, +Y is up. All of the geometry should be in the -Z space. If you don't follow these guidelines you're BSDF will be strange.
Andy
On Tue, Feb 25, 2014 at 8:06 AM, Chris Coulter <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> wrote:
Good morning Gurus!
I have worked through the 3- and 5-phase tutorials in hopes of being able to apply a BSDF to one of my projects. This project will be using micro-louver cellular structures imbedded within an IGU, in both skylights and vertical windows. I think I understand the general process, but wanted to ask a few questions before getting too far down the road...
The skylights and windows are all different sizes and the windows are in multiple orientations (of course). My understanding of the BSDF and seemingly from this mail (http://www.radiance-online.org/pipermail/radiance-general/2011-November/008248.html), I should be able to calculate the BSDF once for my system. I was planning model the louvers as 1m by 1m, but run genBSDF with the -dim arguments smaller than this. Is this the correct approach? Ideally I would not calculate the BSDF for each orientation, assuming that micro-louver geometry does not change.
In my BSDF material definition, I would alter the up vector according to the surface being applied - the up vector matches the BSDF orientation (calculated in xy space) to the specific geometry's orientation (0 0 1 for a window). If the louver are rotated within the IGU assembly (rz -45) for a skylight, I can account for this with the up vector of 1 1 0 (surface normal is 0 0 1). This would hold true for rotation within the vertical apertures as well. Each different up vector would be a different BSDF material.
Lastly, if the glazing properties (VLT) are not defined yet, can I import the BSDF file into Window and create multiple options for IGU's with varying properties? It seems so from David Geisler-Moroder's presentation at the 2012 Workshop (
Attachments:
ATT00001.txt (248 Bytes)
_______________________________________________
Radiance-general mailing list
[email protected]<mailto:[email protected]>
http://www.radiance-online.org/mailman/listinfo/radiance-general
