algorithmic modeling for Rhino


Question: Would it be correct to say that the VSC component calculation can also be interpreted as Sky View Factor?

Maybe it is the hour, but i'm getting confused here.



Views: 2580

Replies are closed for this discussion.

Replies to This Discussion


I like your idea of using VSC to calculate a Sky View Factor. Unfortunately, because VSC is affected by glazing properties and reflected light, the same sky view could result in different VSC values if the model material properties change.


If you removed all of your glass and calculated a single ray (ab-0) run under uniform sky conditions, that might work. I never use VSC, so I might be off here, but that sounds reasonable. What do you think?



Thanks for the "support" Leland :-)

At least i see that someone else sees the logic behind the thinking.

VSC is the only DL component that doesn't have a radParameters input. The ab setting for this calculation is set to 1, so one bounce is OK, no matter the properties of the materials (even mirror glazed).

So i think the component can be also used for SVF.

Judge Mostapha?



The Shadingmask gives a point in space SVF, but having a map of this parameter is nicer and probably more useful for design/research purposes.


From the papers that I have read on urban heat island (where sky view is important for modeling the escape of long wave radiation from urban canyons to the sky at night), I had always understood skyview and VSC to be synonymous. Mostapha will hopefully help confirm this soon.

Thanks Chris,

In the meantime i've been doing some tests with the Shadingmask component just to compare results with the VSC's. So far no good correlation. The differences are pretty big, sometimes beyond 15-20%.

Being the SVF a completely geometrical calculation (no sky influence) i was hopping the results will be in the same order of numbers (also played with the resolution of the Shadingmask but no improvement). Makes me think that maybe the -ab = 1 in the VSC is the cause. So maybe for SVF this parameter should be set to 0, as Leland said ...?


Hi all, The methodology for the component as mentioned in description is based on this Radiance post ( The post suggests ab=1 for some technical reasons but it's not really convincing.

Abraham. Can you post results of your study? That might be helpful to understand what's going on.

Here you go Mostapha.

You'll get the map on the ground surface. There i plot the VSC results.

After that i check random points with the ShadingMask (manually).



Hi Chris,

I'm checking the version of LB_viewAnalysis you released today. I see the option of SVF (great).

In the process the component gives an error (red component) regarding the viewPtsWeights missing (line 526). I solved it temporary changing the variable name for "1". I see that this variable shows in some other places as a parameter but not as a variable influencing the calculations. So i assume it can be deleted from the component.

I'll keep checking and will report results here.



OK. I've been checking a bit the viewAnalysis regarding the SVF.

The results vary a bit from those of the LB_shadingMask (1-2%), which a see a s good consistency. This is great. I can say that the VSC doesn't show a good agreement with this SVF, so even though the logic can be similar they don't converge.

For consistency between the viewAnalysis and shadingMask the viewResolution_ and the _skyDensity_ inputs, accordingly, represent the same resolution value? The first part of the description says so, but just want to be sure. Maybe the input name can be similar (i assume that viewRessolution applies only to SVF analysis)?




The error was a bug that I have just fixed:

Thank you, as always, for finding these issues before anyone else does.

The results with the view component should be equivalent to the LB_shadingMask as I am using the exact same method of projecting vectors to the center of the sky patches.  The only thing that I can think might be causing the 1-2% discrepancy is that Mostapha might be accounting for the areas of the sky patches and I am just assuming that each sky patch is of equal area to the others.  If anyone has any strong feeling about accounting for the areas of the sky patches, let me know and I can work it in.  I know that Tregenza originally divided them that way to have as equal areas as possible so I thought that I might be safe with the assumption.

The skyDensity and viewResolution inputs are the same parameter from the perspective of the LB_LB component that generates the patches/vectors.  I used the more general term "viewResolution" since I am using the evenly distributed vectors for other types of view analysis (like spherical view) and not just sky view.

How far off is the agreement with the VSC component?  Radiance is going to use the stoichastic method, which is going to be different than projecting the same evenly distributed view vectors.  If it's really far from a high resolution view study, maybe we need to look into the HB_VSC code.


Hi Chris,

The error was not fixed. I'm still having this:

Runtime error (UnboundNameException): name 'viewPtsWeights_' is not defined
  line 531, in script

with the Jan 8 version. You left in line 531 the variable viewPtsWeights, which is not in the inputs anymore. For now i changed the code giving "1" instead the variable, so the component can run, but i know that viewPtsWeights shows in other places.

The differences with VSC go between 5 to 20% or more (depending if the sample point is more exposed to the sky). This is really far away.

I'm good with the other explanations.



I'm attaching the example i'm using for this case.








  • Add Photos
  • View All

© 2019   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service