Blender  V3.3
sky_model.h
Go to the documentation of this file.
1 /* SPDX-License-Identifier: BSD-3-Clause
2  * Copyright 2012-2013 Lukas Hosek and Alexander Wilkie. All rights reserved. */
3 
4 /* ============================================================================
5 
6 This file is part of a sample implementation of the analytical skylight and
7 solar radiance models presented in the SIGGRAPH 2012 paper
8 
9 
10  "An Analytic Model for Full Spectral Sky-Dome Radiance"
11 
12 and the 2013 IEEE CG&A paper
13 
14  "Adding a Solar Radiance Function to the Hosek Skylight Model"
15 
16  both by
17 
18  Lukas Hosek and Alexander Wilkie
19  Charles University in Prague, Czech Republic
20 
21 
22  Version: 1.4a, February 22nd, 2013
23 
24 Version history:
25 
26 1.4a February 22nd, 2013
27  Removed unnecessary and counter-intuitive solar radius parameters
28  from the interface of the colourspace sky dome initialization functions.
29 
30 1.4 February 11th, 2013
31  Fixed a bug which caused the relative brightness of the solar disc
32  and the sky dome to be off by a factor of about 6. The sun was too
33  bright: this affected both normal and alien sun scenarios. The
34  coefficients of the solar radiance function were changed to fix this.
35 
36 1.3 January 21st, 2013 (not released to the public)
37  Added support for solar discs that are not exactly the same size as
38  the terrestrial sun. Also added support for suns with a different
39  emission spectrum ("Alien World" functionality).
40 
41 1.2a December 18th, 2012
42  Fixed a mistake and some inaccuracies in the solar radiance function
43  explanations found in ArHosekSkyModel.h. The actual source code is
44  unchanged compared to version 1.2.
45 
46 1.2 December 17th, 2012
47  Native RGB data and a solar radiance function that matches the turbidity
48  conditions were added.
49 
50 1.1 September 2012
51  The coefficients of the spectral model are now scaled so that the output
52  is given in physical units: W / (m^-2 * sr * nm). Also, the output of the
53  XYZ model is now no longer scaled to the range [0...1]. Instead, it is
54  the result of a simple conversion from spectral data via the CIE 2 degree
55  standard observer matching functions. Therefore, after multiplication
56  with 683 lm / W, the Y channel now corresponds to luminance in lm.
57 
58 1.0 May 11th, 2012
59  Initial release.
60 
61 
62 Please visit http://cgg.mff.cuni.cz/projects/SkylightModelling/ to check if
63 an updated version of this code has been published!
64 
65 ============================================================================ */
66 
67 /*
68 
69 This code is taken from ART, a rendering research system written in a
70 mix of C99 / Objective C. Since ART is not a small system and is intended to
71 be inter-operable with other libraries, and since C does not have namespaces,
72 the structures and functions in ART all have to have somewhat wordy
73 canonical names that begin with Ar.../ar..., like those seen in this example.
74 
75 Usage information:
76 ==================
77 
78 
79 Model initialization
80 --------------------
81 
82 A separate ArHosekSkyModelState has to be maintained for each spectral
83 band you want to use the model for. So in a renderer with 'num_channels'
84 bands, you would need something like
85 
86  ArHosekSkyModelState * skymodel_state[num_channels];
87 
88 You then have to allocate and initialize these states. In the following code
89 snippet, we assume that 'albedo' is defined as
90 
91  double albedo[num_channels];
92 
93 with a ground albedo value between [0,1] for each channel. The solar elevation
94 is given in radians.
95 
96  for ( unsigned int i = 0; i < num_channels; i++ )
97  skymodel_state[i] =
98  arhosekskymodelstate_alloc_init(
99  turbidity,
100  albedo[i],
101  solarElevation
102  );
103 
104 Note that starting with version 1.3, there is also a second initialization
105 function which generates skydome states for different solar emission spectra
106 and solar radii: 'arhosekskymodelstate_alienworld_alloc_init()'.
107 
108 See the notes about the "Alien World" functionality provided further down for a
109 discussion of the usefulness and limits of that second initialization function.
110 Sky model states that have been initialized with either function behave in a
111 completely identical fashion during use and cleanup.
112 
113 Using the model to generate skydome samples
114 -------------------------------------------
115 
116 Generating a skydome radiance spectrum "skydome_result" for a given location
117 on the skydome determined via the angles theta and gamma works as follows:
118 
119  double skydome_result[num_channels];
120 
121  for ( unsigned int i = 0; i < num_channels; i++ )
122  skydome_result[i] =
123  arhosekskymodel_radiance(
124  skymodel_state[i],
125  theta,
126  gamma,
127  channel_center[i]
128  );
129 
130 The variable "channel_center" is assumed to hold the channel center wavelengths
131 for each of the num_channels samples of the spectrum we are building.
132 
133 
134 Cleanup after use
135 -----------------
136 
137 After rendering is complete, the content of the sky model states should be
138 disposed of via
139 
140  for ( unsigned int i = 0; i < num_channels; i++ )
141  arhosekskymodelstate_free( skymodel_state[i] );
142 
143 
144 CIE XYZ Version of the Model
145 ----------------------------
146 
147 Usage of the CIE XYZ version of the model is exactly the same, except that
148 num_channels is of course always 3, and that ArHosekTristimSkyModelState and
149 arhosek_tristim_skymodel_radiance() have to be used instead of their spectral
150 counterparts.
151 
152 RGB Version of the Model
153 ------------------------
154 
155 The RGB version uses sRGB primaries with a linear gamma ramp. The same set of
156 functions as with the XYZ data is used, except the model is initialized
157 by calling arhosek_rgb_skymodelstate_alloc_init.
158 
159 Solar Radiance Function
160 -----------------------
161 
162 For each position on the solar disc, this function returns the entire radiance
163 one sees - direct emission, as well as in-scattered light in the area of the
164 solar disc. The latter is important for low solar elevations - nice images of
165 the setting sun would not be possible without this. This is also the reason why
166 this function, just like the regular sky dome model evaluation function, needs
167 access to the sky dome data structures, as these provide information on
168 in-scattered radiance.
169 
170 CAVEAT #1: in this release, this function is only provided in spectral form!
171  RGB/XYZ versions to follow at a later date.
172 
173 CAVEAT #2: (fixed from release 1.3 onwards)
174 
175 CAVEAT #3: limb darkening renders the brightness of the solar disc
176  inhomogeneous even for high solar elevations - only taking a single
177  sample at the centre of the sun will yield an incorrect power
178  estimate for the solar disc! Always take multiple random samples
179  across the entire solar disc to estimate its power!
180 
181 CAVEAT #4: in this version, the limb darkening calculations still use a fairly
182  computationally expensive 5th order polynomial that was directly
183  taken from astronomical literature. For the purposes of Computer
184  Graphics, this is needlessly accurate, though, and will be replaced
185  by a cheaper approximation in a future release.
186 
187 "Alien World" functionality
188 ---------------------------
189 
190 The Hosek sky model can be used to roughly (!) predict the appearance of
191 outdoor scenes on earth-like planets, i.e. planets of a similar size and
192 atmospheric make-up. Since the spectral version of our model predicts sky dome
193 luminance patterns and solar radiance independently for each waveband, and
194 since the intensity of each waveband is solely dependent on the input radiance
195 from the star that the world in question is orbiting, it is trivial to re-scale
196 the wavebands to match a different star radiance.
197 
198 At least in theory, the spectral version of the model has always been capable
199 of this sort of thing, and the actual sky dome and solar radiance models were
200 actually not altered at all in this release. All we did was to add some support
201 functionality for doing this more easily with the existing data and functions,
202 and to add some explanations.
203 
204 Just use 'arhosekskymodelstate_alienworld_alloc_init()' to initialize the sky
205 model states (you will have to provide values for star temperature and solar
206 intensity compared to the terrestrial sun), and do everything else as you
207 did before.
208 
209 CAVEAT #1: we assume the emission of the star that illuminates the alien world
210  to be a perfect blackbody emission spectrum. This is never entirely
211  realistic - real star emission spectra are considerably more complex
212  than this, mainly due to absorption effects in the outer layers of
213  stars. However, blackbody spectra are a reasonable first assumption
214  in a usage scenario like this, where 100% accuracy is simply not
215  necessary: for rendering purposes, there are likely no visible
216  differences between a highly accurate solution based on a more
217  involved simulation, and this approximation.
218 
219 CAVEAT #2: we always use limb darkening data from our own sun to provide this
220  "appearance feature", even for suns of strongly different
221  temperature. Which is presumably not very realistic, but (as with
222  the unaltered blackbody spectrum from caveat #1) probably not a bad
223  first guess, either. If you need more accuracy than we provide here,
224  please make inquiries with a friendly astro-physicst of your choice.
225 
226 CAVEAT #3: you have to provide a value for the solar intensity of the star
227  which illuminates the alien world. For this, please bear in mind
228  that there is very likely a comparatively tight range of absolute
229  solar irradiance values for which an earth-like planet with an
230  atmosphere like the one we assume in our model can exist in the
231  first place!
232 
233  Too much irradiance, and the atmosphere probably boils off into
234  space, too little, it freezes. Which means that stars of
235  considerably different emission colour than our sun will have to be
236  fairly different in size from it, to still provide a reasonable and
237  inhabitable amount of irradiance. Red stars will need to be much
238  larger than our sun, while white or blue stars will have to be
239  comparatively tiny. The initialization function handles this and
240  computes a plausible solar radius for a given emission spectrum. In
241  terms of absolute radiometric values, you should probably not stray
242  all too far from a solar intensity value of 1.0.
243 
244 CAVEAT #4: although we now support different solar radii for the actual solar
245  disc, the sky dome luminance patterns are *not* parameterised by
246  this value - i.e. the patterns stay exactly the same for different
247  solar radii! Which is of course not correct. But in our experience,
248  solar discs up to several degrees in diameter (! - our own sun is
249  half a degree across) do not cause the luminance patterns on the sky
250  to change perceptibly. The reason we know this is that we initially
251  used unrealistically large suns in our brute force path tracer, in
252  order to improve convergence speeds (which in the beginning were
253  abysmal). Later, we managed to do the reference renderings much
254  faster even with realistically small suns, and found that there was
255  no real difference in skydome appearance anyway.
256  Conclusion: changing the solar radius should not be over-done, so
257  close orbits around red supergiants are a no-no. But for the
258  purposes of getting a fairly credible first impression of what an
259  alien world with a reasonably sized sun would look like, what we are
260  doing here is probably still o.k.
261 
262 HINT #1: if you want to model the sky of an earth-like planet that orbits
263  a binary star, just super-impose two of these models with solar
264  intensity of ~0.5 each, and closely spaced solar positions. Light is
265  additive, after all. Tattooine, here we come... :-)
266 
267  P.S. according to Star Wars canon, Tattooine orbits a binary
268  that is made up of a G and K class star, respectively.
269  So ~5500K and ~4200K should be good first guesses for their
270  temperature. Just in case you were wondering, after reading the
271  previous paragraph.
272 */
273 
278 #ifndef __SKY_MODEL_H__
279 #define __SKY_MODEL_H__
280 
281 #ifdef __cplusplus
282 extern "C" {
283 #endif
284 
286 
287 // Spectral version of the model
288 
289 /* ----------------------------------------------------------------------------
290 
291  ArHosekSkyModelState struct
292  ---------------------------
293 
294  This struct holds the pre-computation data for one particular albedo value.
295  Most fields are self-explanatory, but users should never directly
296  manipulate any of them anyway. The only consistent way to manipulate such
297  structs is via the functions 'arhosekskymodelstate_alloc_init' and
298  'arhosekskymodelstate_free'.
299 
300  'emission_correction_factor_sky'
301  'emission_correction_factor_sun'
302 
303  The original model coefficients were fitted against the emission of
304  our local sun. If a different solar emission is desired (i.e. if the
305  model is being used to predict skydome appearance for an earth-like
306  planet that orbits a different star), these correction factors, which
307  are determined during the alloc_init step, are applied to each waveband
308  separately (they default to 1.0 in normal usage). This is the simplest
309  way to retrofit this sort of capability to the existing model. The
310  different factors for sky and sun are needed since the solar disc may
311  be of a different size compared to the terrestrial sun.
312 
313 ---------------------------------------------------------------------------- */
314 
315 typedef struct SKY_ArHosekSkyModelState {
317  double radiances[11];
318  double turbidity;
319  double solar_radius;
322  double albedo;
323  double elevation;
325 
326 /* ----------------------------------------------------------------------------
327 
328  arhosekskymodelstate_alloc_init() function
329  ------------------------------------------
330 
331  Initializes an #ArHosekSkyModelState struct for a terrestrial setting.
332 
333 ---------------------------------------------------------------------------- */
334 
336  const double atmospheric_turbidity,
337  const double ground_albedo);
338 
339 /* ----------------------------------------------------------------------------
340 
341  arhosekskymodelstate_alienworld_alloc_init() function
342  -----------------------------------------------------
343 
344  Initializes an ArHosekSkyModelState struct for an "alien world" setting
345  with a sun of a surface temperature given in 'kelvin'. The parameter
346  'solar_intensity' controls the overall brightness of the sky, relative
347  to the solar irradiance on Earth. A value of 1.0 yields a sky dome that
348  is, on average over the wavelengths covered in the model (!), as bright
349  as the terrestrial sky in radiometric terms.
350 
351  Which means that the solar radius has to be adjusted, since the
352  emissivity of a solar surface with a given temperature is more or less
353  fixed. So hotter suns have to be smaller to be equally bright as the
354  terrestrial sun, while cooler suns have to be larger. Note that there are
355  limits to the validity of the luminance patterns of the underlying model:
356  see the discussion above for more on this. In particular, an alien sun with
357  a surface temperature of only 2000 Kelvin has to be very large if it is
358  to be as bright as the terrestrial sun - so large that the luminance
359  patterns are no longer a really good fit in that case.
360 
361  If you need information about the solar radius that the model computes
362  for a given temperature (say, for light source sampling purposes), you
363  have to query the 'solar_radius' variable of the sky model state returned
364  *after* running this function.
365 
366 ---------------------------------------------------------------------------- */
367 
369  const double solar_elevation,
370  const double solar_intensity,
371  const double solar_surface_temperature_kelvin,
372  const double atmospheric_turbidity,
373  const double ground_albedo);
374 
376 
378  double theta,
379  double gamma,
380  double wavelength);
381 
382 // CIE XYZ and RGB versions
383 
385  const double albedo,
386  const double elevation);
387 
389  const double albedo,
390  const double elevation);
391 
393  double theta,
394  double gamma,
395  int channel);
396 
397 // Delivers the complete function: sky + sun, including limb darkening.
398 // Please read the above description before using this - there are several
399 // caveats!
400 
402  double theta,
403  double gamma,
404  double wavelength);
405 
406 /* Nishita improved sky model */
407 
408 void SKY_nishita_skymodel_precompute_texture(float *pixels,
409  int stride,
410  int start_y,
411  int end_y,
412  int width,
413  int height,
414  float sun_elevation,
415  float altitude,
416  float air_density,
417  float dust_density,
418  float ozone_density);
419 
420 void SKY_nishita_skymodel_precompute_sun(float sun_elevation,
421  float angular_diameter,
422  float altitude,
423  float air_density,
424  float dust_density,
425  float *r_pixel_bottom,
426  float *r_pixel_top);
427 
428 #ifdef __cplusplus
429 }
430 #endif
431 
432 #endif // __SKY_MODEL_H__
_GL_VOID GLfloat value _GL_VOID_RET _GL_VOID const GLuint GLboolean *residences _GL_BOOL_RET _GL_VOID GLsizei height
_GL_VOID GLfloat value _GL_VOID_RET _GL_VOID const GLuint GLboolean *residences _GL_BOOL_RET _GL_VOID GLsizei GLfloat GLfloat GLfloat GLfloat const GLubyte *bitmap _GL_VOID_RET _GL_VOID GLenum const void *lists _GL_VOID_RET _GL_VOID const GLdouble *equation _GL_VOID_RET _GL_VOID GLdouble GLdouble blue _GL_VOID_RET _GL_VOID GLfloat GLfloat blue _GL_VOID_RET _GL_VOID GLint GLint blue _GL_VOID_RET _GL_VOID GLshort GLshort blue _GL_VOID_RET _GL_VOID GLubyte GLubyte blue _GL_VOID_RET _GL_VOID GLuint GLuint blue _GL_VOID_RET _GL_VOID GLushort GLushort blue _GL_VOID_RET _GL_VOID GLbyte GLbyte GLbyte alpha _GL_VOID_RET _GL_VOID GLdouble GLdouble GLdouble alpha _GL_VOID_RET _GL_VOID GLfloat GLfloat GLfloat alpha _GL_VOID_RET _GL_VOID GLint GLint GLint alpha _GL_VOID_RET _GL_VOID GLshort GLshort GLshort alpha _GL_VOID_RET _GL_VOID GLubyte GLubyte GLubyte alpha _GL_VOID_RET _GL_VOID GLuint GLuint GLuint alpha _GL_VOID_RET _GL_VOID GLushort GLushort GLushort alpha _GL_VOID_RET _GL_VOID GLenum mode _GL_VOID_RET _GL_VOID GLint GLsizei width
_GL_VOID GLfloat value _GL_VOID_RET _GL_VOID const GLuint GLboolean *residences _GL_BOOL_RET _GL_VOID GLsizei GLfloat GLfloat GLfloat GLfloat const GLubyte *bitmap _GL_VOID_RET _GL_VOID GLenum const void *lists _GL_VOID_RET _GL_VOID const GLdouble *equation _GL_VOID_RET _GL_VOID GLdouble GLdouble blue _GL_VOID_RET _GL_VOID GLfloat GLfloat blue _GL_VOID_RET _GL_VOID GLint GLint blue _GL_VOID_RET _GL_VOID GLshort GLshort blue _GL_VOID_RET _GL_VOID GLubyte GLubyte blue _GL_VOID_RET _GL_VOID GLuint GLuint blue _GL_VOID_RET _GL_VOID GLushort GLushort blue _GL_VOID_RET _GL_VOID GLbyte GLbyte GLbyte alpha _GL_VOID_RET _GL_VOID GLdouble GLdouble GLdouble alpha _GL_VOID_RET _GL_VOID GLfloat GLfloat GLfloat alpha _GL_VOID_RET _GL_VOID GLint GLint GLint alpha _GL_VOID_RET _GL_VOID GLshort GLshort GLshort alpha _GL_VOID_RET _GL_VOID GLubyte GLubyte GLubyte alpha _GL_VOID_RET _GL_VOID GLuint GLuint GLuint alpha _GL_VOID_RET _GL_VOID GLushort GLushort GLushort alpha _GL_VOID_RET _GL_VOID GLenum mode _GL_VOID_RET _GL_VOID GLint GLsizei GLsizei GLenum type _GL_VOID_RET _GL_VOID GLsizei GLenum GLenum const void *pixels _GL_VOID_RET _GL_VOID const void *pointer _GL_VOID_RET _GL_VOID GLdouble v _GL_VOID_RET _GL_VOID GLfloat v _GL_VOID_RET _GL_VOID GLint GLint i2 _GL_VOID_RET _GL_VOID GLint j _GL_VOID_RET _GL_VOID GLfloat param _GL_VOID_RET _GL_VOID GLint param _GL_VOID_RET _GL_VOID GLdouble GLdouble GLdouble GLdouble GLdouble zFar _GL_VOID_RET _GL_UINT GLdouble *equation _GL_VOID_RET _GL_VOID GLenum GLint *params _GL_VOID_RET _GL_VOID GLenum GLfloat *v _GL_VOID_RET _GL_VOID GLenum GLfloat *params _GL_VOID_RET _GL_VOID GLfloat *values _GL_VOID_RET _GL_VOID GLushort *values _GL_VOID_RET _GL_VOID GLenum GLfloat *params _GL_VOID_RET _GL_VOID GLenum GLdouble *params _GL_VOID_RET _GL_VOID GLenum GLint *params _GL_VOID_RET _GL_VOID GLsizei stride
const int state
SKY_ArHosekSkyModelState * SKY_arhosekskymodelstate_alienworld_alloc_init(const double solar_elevation, const double solar_intensity, const double solar_surface_temperature_kelvin, const double atmospheric_turbidity, const double ground_albedo)
void SKY_arhosekskymodelstate_free(SKY_ArHosekSkyModelState *state)
Definition: sky_model.cpp:267
double SKY_arhosekskymodel_solar_radiance(SKY_ArHosekSkyModelState *state, double theta, double gamma, double wavelength)
void SKY_nishita_skymodel_precompute_sun(float sun_elevation, float angular_diameter, float altitude, float air_density, float dust_density, float *r_pixel_bottom, float *r_pixel_top)
struct SKY_ArHosekSkyModelState SKY_ArHosekSkyModelState
double SKY_arhosek_tristim_skymodel_radiance(SKY_ArHosekSkyModelState *state, double theta, double gamma, int channel)
double SKY_arhosekskymodel_radiance(SKY_ArHosekSkyModelState *state, double theta, double gamma, double wavelength)
Definition: sky_model.cpp:272
double SKY_ArHosekSkyModelConfiguration[9]
Definition: sky_model.h:285
SKY_ArHosekSkyModelState * SKY_arhosekskymodelstate_alloc_init(const double solar_elevation, const double atmospheric_turbidity, const double ground_albedo)
SKY_ArHosekSkyModelState * SKY_arhosek_rgb_skymodelstate_alloc_init(const double turbidity, const double albedo, const double elevation)
void SKY_nishita_skymodel_precompute_texture(float *pixels, int stride, int start_y, int end_y, int width, int height, float sun_elevation, float altitude, float air_density, float dust_density, float ozone_density)
SKY_ArHosekSkyModelState * SKY_arhosek_xyz_skymodelstate_alloc_init(const double turbidity, const double albedo, const double elevation)
Definition: sky_model.cpp:305
double emission_correction_factor_sky[11]
Definition: sky_model.h:320
SKY_ArHosekSkyModelConfiguration configs[11]
Definition: sky_model.h:316
double emission_correction_factor_sun[11]
Definition: sky_model.h:321