Commits on Aug 26, 2018
  1. Cleanup: Integrators header files

    Michele Castigliego
    Michele Castigliego committed Aug 26, 2018
Commits on Jul 26, 2018
  1. Merge pull request #108 from yurivict/dl-fix

    DavidBluecame committed Jul 26, 2018
    Use the cmake feature ${CMAKE_DL_LIBS} instead of hardcoded -ldl.
Commits on Jul 23, 2018
  1. Merge pull request #109 from yurivict/freebsd-compatibility

    DavidBluecame committed Jul 23, 2018
    FreeBSD compatibilty patch
Commits on Jul 21, 2018
  1. FreeBSD compatibilty patch

    yurivict committed Jul 21, 2018
Commits on Dec 1, 2017
  1. Update INSTALL

    DavidBluecame committed Dec 1, 2017
    Correct list and add minimum version numbers
  2. Merge pull request #105 from jonasstein/patch-1

    DavidBluecame committed Dec 1, 2017
    List of dependencies
Commits on Nov 28, 2017
  1. List of dependencies

    jonasstein committed Nov 28, 2017
    copied the dependencies from
    A complete overview on the dependencies (including the versions) is important for distributors. 
    We would like to package this for Gentoo linux. (
Commits on Nov 1, 2017
Commits on Oct 31, 2017
  1. New per-material transparency bias for Shiny Diffuse

    DavidBluecame committed Oct 31, 2017
    When there are objects with many transparent surfaces stacked close together (such as leaves in a tree) sometimes black artifacts appear if the ray reaches the maximum depth.
    This can be solved by increasing the maximum ray depth, but the render times will increase very significantly.
    Therefore I've added two new parameters for the Shiny Diffuse material to try to achieve a "trick", which is not realistic and may cause other artifacts but that should prevent the black areas without having to increase the maximum ray depth so much.
    * transparentbias_factor  : this floating point value is 0.0 by default (disabled). If this value is >0.0 the function is enabled. In that case, an additional "bias" will be added to each ray when it hits a transparent surface. If the ray hits a transparent surface, the next secondary ray will not start exactly after that surface but after this bias factor. So, subsequent transparent surfaces can be skipped and not rendered, but the objects behind will be rendered (unless they are too close to them, in that case they might not be rendered!)
    * transparentbias_multiply_raydepth  : this boolean values is false by default. If the factor is used and this is disabled, the factor will be just added to each secondary ray initial position. If this parameter is enabled, the "bias" for each ray will be multiplied by the ray depth. That way, the first few surfaces will be rendered giving a better "density" but the further the secondary rays are generated, the bigger the bias will be.
    I got interesting results with factor = 1.0 and multiply_raydepth = true. However, even solving the black areas problems, the resulting image will have other artifacts due to some surfaces not being rendered. USE WITH CARE!!
Commits on Aug 22, 2017
Commits on Jul 13, 2017
  1. Merge pull request #104 from olafhering/master

    DavidBluecame committed Jul 13, 2017
    build fixes
  2. Wrap asmSqrt because fsqrt is x86 only

    olafhering committed Jul 13, 2017
    Signed-off-by: Olaf Hering <>
  3. Remove executable bit from plain files

    olafhering committed Jul 13, 2017
    Signed-off-by: Olaf Hering <>
Commits on May 27, 2017
  1. Fix for YafaRay hangs in Windows 7 when built with Visual Studio 2013

    DavidBluecame committed May 27, 2017
    This is a very strange issue reported here:
    When built with Visual Studio 2013, YafaRay works fine for example in
    Windows 10 64bit but it hangs totally in Windows 7 64bit when executing yafaray-xml
    After a deep investigation I believe this is caused by a strange
    difference in the way Windows 7 manages threads. This is affecting for
    some reason the thread locking in the YafLog object in Windows 7 causing
    a race/deadlock somewhere (unclear where or why!).
    I have solved this problem by removing the YafLog mutex locks when
    YafaRay is built with Visual Studio. The only downside is that sometimes
    the log messages might get garbled when using multithread, but that
    should not be a problem for the rendering itself, only for the log
    messages and log files.
Commits on May 19, 2017
  1. "Flat Material" option added to Shiny Diffuse

    DavidBluecame committed May 19, 2017
    Requested by a certain user. Flat Material is a special non-photorealistic material that does not multiply the surface color by the cosine of the angle with the light, as happens in real life. Also, if receive_shadows is disabled, this flat material does no longer self-shadow. For special applications only.
Commits on Apr 29, 2017
  1. Updated CHANGELOG

    DavidBluecame committed Apr 29, 2017
Commits on Apr 8, 2017
Commits on Apr 3, 2017
  1. Bidirectional: fixed transparent background not working

    DavidBluecame committed Apr 3, 2017
    It was causing the entire render to have transparent alpha. See:
Commits on Mar 22, 2017
Commits on Mar 21, 2017
Commits on Mar 18, 2017
  1. Bidirectional: replaced "deprecated" by "unstable"

    DavidBluecame committed Mar 18, 2017
    The bidirectional integrator will be supported again and will be improved in the future. However for now it's quite unstable and does not work correctly yet.
Commits on Mar 14, 2017
Commits on Mar 11, 2017
  1. IMPORTANT: Path/Photon OneDirectLight - attempt to sample lights more…

    DavidBluecame committed Mar 11, 2017
    … uniformly
    As reported in there are artifacts in the path tracing and photon mapping algorithms when there is more than one light.
    I found that the allegedly "random" sampling of lights in the "estimateOneDirectLight" was not sampling all lights in the scene with the same probability. It was (incorrectly I think) sampling more often the first light, and less often the last light in the lights vector. As the result of each sample is multiplied by the number of lights, it caused the lighting to be non-uniform.
    First I attempted to use a "randomized" approach to solve this, but it increased the noise (not too much, but it was noticeable). So I decided to try to improve the sampling using the current Halton sampling algorithm. I found that the input to the algorithm was not correlative enough, having many "jumps" that probably caused the wrong Halton outputs. Therefore I decided to change the input data and use an almost purely correlative numbering for each sample (having separate correlative numbers, one per thread). This seems to improve the noise and still give similar results no matter how many lights are used, and a more uniform light sampling.
    This is a very significant change. I would expect scenes to be a little bit noisier now, but having a much more correct lighting when there is more than one light in the scene.
    In any case we need to keep an eye on this and perhaps fine tune it more or even revert it back completely and look for another solution. For now I will leave it this way and see what happens...
  2. Logging: added statistics component, to gather accumulated stats for …

    DavidBluecame committed Mar 11, 2017
    For statistical analysis, a way to log accumulated and statistical values has been implemented. If used, every time YafaRay saves images it will also save (to the same location) a file "xxx_stat.csv" with the names, indexes and values of the variables included in the stats. The csv file can be easily opened in a spreadsheet application for analysis.
    Usage is, for example, to set a new variable in the stat or to add a value to an existing variable:
    yafLog.statsAdd("variable_name", value_to_add);
    Or, to store indexed variables:
    yafLog.statsAdd("matrix_name", value_to_add, index_of_element_in_matrix);
    Then, at any point, to print the list of variables and their values (not recommended, better just open the csv file!):
    or, to sort the results:
    To clear the stats:
    To create a "bucket" system to analyze the value distribution of a variable, use:
    yafLog.statsIncrementBucket("variable_name", variable_value, bucket_width);
    If not specified, the bucket_width by default is 1.0, for analyzing for example the distribution of integer values.
Commits on Mar 9, 2017
Commits on Mar 8, 2017
Commits on Mar 7, 2017