YafaRay v3.5.1 (2020-07-13)

---------------------------
* MacOS: found/fixed root cause of Blender python segfault 11 and ruby SketchUp Make 2017 "incompatible version" problems
* MacOS: fixed Qt5 menus. Toolbar not fixed yet, hiding it for now.
* XML parser: fix build broken when XMLImport and XML Loader are disabled (and no dependencies on LibXML2/ZLib)
* Build info: made it less verbose (it was getting too long in some platforms) and added dash between platform and compiler when there is a platform (like MinGW)
* Logging: fixed HTML log display of jpg and png images
* Ruby Qt bindings: change name to avoid collisions in linux python "import yafqt" between yafqt.py and yafqt.so

YafaRay v3.5.0 (2020-07-10)

---------------------------
* IMPORTANT: Removal of *all* Boost dependencies. I've implemented new Unicode File management and new ImageFilm/PhotonMap saving/loading system.
   - All functionality depending on Boost has been rewritten from scratch to be able to remove Boost altogether.
   - Implemented Unicode UTF8/UTF16 conversions for strings in POSIX and Windows systems
   - Implemented Unicode UTF8/UTF16 file handling classes for Unicode paths in POSIX and Windows systems
   - In the process of that implementation I fixed some issues that were pending for a long time:
        - Now almost all files (including logs) are handled with the new file_t interface, so all works when using Unicode paths (logs were not correctly saved sometimes in Windows)
        - No longer need for temporary files when using OpenEXR files with Unicode paths.
   - Implemented new system to save / load ImageFilm and Photon Maps. The files generated with previous versions of YafaRay are *no longer valid* for this new method.
        - I think the new system is faster and generates smaller files (still big, depending on the amount of info)
        - Only drawback for now, when loading photon maps it has to regenerate the photon search KD tree, which is no longer saved in the photon map file.
        - No longer need to have a separate binary/text format for portability. In principle it should work the same in Linux/Windows, etc.
        - Endianness could be an issue for non-Intel/AMD platforms like ARM, to be investigated in the future, but that's a problem for another day.
   - Removed all SysInfo Boost code and replaced it by a "CMake-building" generation. Renamed sysinfo classes as build_info.

* IMPORTANT: CMake: made LibXML2 / ZLib optional. New CMake flag "WITH_XMLImport" to enable LibXML2. Now all the dependencies are finally optional and pure YafaRay library can be built without any dependencies.
* IMPORTANT: general header files de-coupling and cleanup, some old unused and broken code deleted
* Changing documentation extension to Markdown *.md
* Bidirectional integrator: adding integrator information to log and badge
* Bidirectional integrator: fixed transparent shadows, as requested in https://github.com/YafaRay/Blender-Exporter/issues/38
* SPPM: fixed memory corruption when using startx, starty not zero, as requested in https://github.com/YafaRay/Blender-Exporter/issues/41 and https://github.com/YafaRay/Blender-Exporter/issues/40
* XML Parser: added XML SAX parsing error diagnostic messages, as requested in https://github.com/YafaRay/Core/issues/121
* Added back -pthread flag for gcc/g++ compilation to fix FreeBSD builds To fix FreeBSD build as requested in https://github.com/YafaRay/Core/issues/113
* Removed some warnings for GCC. Also removed some Clang warnings as requested by https://github.com/YafaRay/Core/issues/110
* Fixed some source file comments license boilerplate to remove wrongly encoded characters that were confusing some IDEs
* CMake: unifying all cmake-generated headers, simplifying code. Threads: moved runtime detection to dedicated class
* OpenCV Denoise: better encapsulation and code reuse, at the expense of slower processing
* Renamed yafsystem/sharedlibrary_t by a (clearer) dynamic_library/dynamicLoadedLibrary_t
* Git: added .gitignore to ignore all "hidden" files starting with "." (i.e. IDE generated files)
* Swig Ruby: avoid -Wsign-compare warning.

YafaRay v3.4.4 (2020-05-09)

EDIT 2020-05-13: Fixed Windows builds - previous builds were causing issues with threads due to a problem with one dependency. The Windows builds with "FIXED 2020-05-13" in the file name should work fine.

These are the Standalone binaries. If you want to use YafaRay with Blender 2.79 please use the binaries from the Blender-Exporter here:

https://github.com/YafaRay/Blender-Exporter/releases

---

• Angular camera: modified to add several types of angular projections and to fix new ortographic calculations.

YafaRay v3.4.3 (2020-05-09)

---------------------------
* Angular camera: added "Ortographic" projection.

YafaRay v3.4.2 (2020-05-08)

---------------------------
* Added Equirectangular camera
* Triangle: added "mesh->normals_exported" condition to enable user
defined normals

YafaRay v3.4.1 (2020-04-08)

YafaRay v3.4.1 (2020-04-08)

• Changed documentation to state that any bug reporting and resolution will solely be done in the GitHub Project "Issues" tab. Bugs in the old yafaray.org bugtracker will not be processed anymore.
• Added note about Blender-Exporter only working for Blender v2.7x versions.

YafaRay v3.4.0 (2020-03-22)

Note: don't mind the release date, the project has been mostly inactive for a long time, so only a few (although significant) changes since v3.3.0, but it was about time to give the last changes a proper release version number.

Feature changes/additions:

• New per-material transparency bias for Shiny Diffuse. 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 increase. 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.

Dependencies changes:

• IMPORTANT: Migration from Qt4 to Qt5 as Qt4 reached End of Life
• Dependency on meganz/mingw-std-threads made optional, because it's needed for old MinGW compilers but it causes conflicts with new MinGW compilers, so better to have it as an option in CMake (disabled by default)
• Compatibility fix for Python 3.8

Other changes:

• Silenced some warnings while building in recent versions of gcc.

YafaRay v3.4.0 (2020-03-22)

---------------------------
Note: don't mind the release date, the project has been mostly inactive for a long time, so only a few (although significant) changes since v3.3.0, but it was about time to give the last changes a proper release version number.

Feature changes/additions:
--------------------------
* New per-material transparency bias for Shiny Diffuse. 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 increase. 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.

Dependencies changes:
---------------------
* IMPORTANT: Migration from Qt4 to Qt5 as Qt4 reached End of Life
* Dependency on meganz/mingw-std-threads made optional, because it's needed for old MinGW compilers but it causes conflicts with new MinGW compilers, so better to have it as an option in CMake (disabled by default)
* Compatibility fix for Python 3.8

Other changes:
----------
* Silenced some warnings while building in recent versions of gcc.

YafaRay v3.3.0 (2017-08-22)

---------------------------

Feature changes/additions:
--------------------------
* "Flat Material" option added to Shiny Diffuse, 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.

Bug fixes:
----------
* Bidirectional: fixed transparent background not working, was causing the entire render to have transparent alpha. See: http://www.yafaray.org/community/forum/viewtopic.php?f=15&t=5236
* Bidirectional: fixes (horrible hacks in fact, but...) for unitialized values causing incorrect illumination in scenes
* Fixed hang in Windows 7 when YafaRay is built using Visual Studio 2013.
* Some building fixes

YafaRay v3.2.0 (2017-03-21)

Feature changes/additions in v3.2.0:
------------------------------------
* IMPORTANT: Support for Texture Mipmaps / Ray Differentials, see: http://yafaray.org/node/695
    - Modifier all ImageHandlers to standardise access and make them more flexible. BIG changes to ImageHandlers.
    - Added new Grayscale internal buffers (optional)
    - Reorganized all Interpolation and GetColor code
    - Added MipMap capability to ImageHandlers
    - Added Trilinear MipMap interpolation based on Ray Differentials.
    - Added EWA MipMap interpolation based on Ray Differentials
    - Heavily modified IBL blur function, to use mipmaps with manually calculated mipmap level instead of the previous dedicated "IBL blur" process

* Path Tracing integrator: added new Russian Roulette parameter to speed up path tracing, see: http://www.yafaray.org/node/775
    The relevant parameter will be "russian_roulette_min_bounces".
    - If this parameter is set to 0, russian roulette will be enabled.
    - If set to the same value specified in depth (max bounces), russian roulette will be disabled
    - If set to a value between 0 and max bounces, then russian roulette will only start be applied after this number of bounces, so we can get decent sampling in dark areas for example and get a good speedup with less noise.
    - Lower values of this parameter will result in faster (but somewhat noisier) renders.

* yafaray-xml: better autodetection of plugins path, but in some cases "-pp" may still be needed

* Building system: many changes to make the building process easier and more integrated with Git

* Building system: standalone builds generated again

* Building system: added building instructions and test scenes

* QT4 support reintroduced and updated for YafaRay v3, but still in a basic state, many features not available yet for the Qt interface

* Re-added ability to generate Sketchup plugins again

* Texture mapping: allow MirrorX,MirrorY even when Repeat = 1

Bug fixes in v3.2.0:
--------------------
* IMPORTANT: Path/Photon OneDirectLight - attempt to sample lights more uniformly, see: http://www.yafaray.org/node/803
This has been a significant bug, that went unnoticed for a very long time and was causing severe artifacts in Photon Mapping and Path Tracing when lights were not uniformly lighting the scene. Now with this fix, renders should be much more correct and hopefully more realistic!

* IMPORTANT: all integrators, SPPM and path roulette: Fixing non-randomness repetitive patterns, see: http://www.yafaray.org/node/792
Another important bug that went unnoticed for a very long time. A lack of randomness caused severe patterns in BiDirectional integrator and probably some artifacts (in less extent) in the others. We hope this change helps to achieve more correct and realistic results now.

* IMPORTANT: big changes to textures interpolation and colorspace processing, see: http://yafaray.org/node/787
    - I found out that YafaRay was doing the texture interpolation *after* decoding the texels color space. This was causing significant differences in color between standard bilinear/bicubic and when using trilinear or EWA mipmaps.

    - The Core code has been modified so from v3.2.0 onwards all internal image buffers will be converted to "linear RGB" during the texture loading process. That will allow a correct color interpolation process, and probably slightly faster than before. Hopefully this should improve color fidelity respect to the original texture images used for the scene.

    - Also, all textures will be "optimized" by default. I think it's clear by now that optimized textures greatly improve memory usage and apparently don't cause slowdowns (might even make it slightly faster due to reduced RAM access?). To accomodate the extra color information necessary to store "linear RGB" values in the optimized buffers, their size will be around 20-25% bigger respect to v3.1.1, therefore a RAM usage increase will happen now compared with previous versions.

    - For optimal results, from now on the user will be responsible for selecting correct ColorSpaces for all textures, including bump map, normal map, etc. For example for Non-RGB / Stencil / Bump / Normal maps, etc, textures are typically already linear and the user should select "linearRGB" in the texture properties, but if the user (by mistake) keeps the default sRGB for them, YafaRay will (incorrectly) apply the sRGB->LinearRGB conversion causing the values to be incorrect. However, I've added a "fail safe" so for any "float" textures, bump maps, normal maps, etc, when getting colors after interpolatio YafaRay will to a "inverse" color conversion to the original Color Space. This way, even a mistake in user's color space selection in bump maps, normal maps, etc, will not cause any significant problems in the image as they will be converted back to their original color space. However, in this case rendering will be slower and potential artifacts can appear due to interpolation taking place in the wrong color space. For optimal results, the user must select correctly the color space for all textures.

* Bidirectional integrator changes:
    - Will be supported again, although will be considered "unstable" until the (many) issues it has are completely fixed.
    - Fixed issue with excessive brightness that happened after render finished.

* Fix for SPPM sudden brightness change when reaching approx 4,300 million photons. See: http://www.yafaray.org/node/772

* Fixed bug that caused many extra render passes to be generated in some cases

* Fixed crash when using Blender Exporter and Core with Ruby bindings support enabled

* Image Texture Interpolation fixes, see: http://www.yafaray.org/node/783

* Angular camera: fixed wrong renders due to incorrect default clipping, see: http://yafaray.org/node/779

* Fixed EXR MultiLayer image file saving

* Fixed uninitialized values generated by Ambient Occlusion sampling

* Several other fixes and improvements, especially for the building system and tools for developers.

v3.2.0-ALPHA21, still in developers testing

*   IMPORTANT: Path/Photon OneDirectLight - attempt to sample lights more uniformly

    As reported in http://www.yafaray.org/node/803 there are artifacts in the path tracing and photon mapping algorithms when there is more than one light.

    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...

*   IMPORTANT: all integrators, SPPM and path roulette: Fixing non-randomness repetitive patterns
    As described in http://www.yafaray.org/node/792 I discovered lack of randomness in the bidirectional integrator.

    I found out that it was caused by an insufficiently random "seeding" of the random_t pnrg object. For example during first AA pass, offset = 0 so it the pnrg object was seeded with value "123" for each tile causing the artifact detected in the bidir integrator.

    However, and even when it's not obviously visible, I also believe it affected the SPPM integrator as well because of the same issue. Therefore I proceeded to add more randomness to the pnrg seeding for all integrators, including SPPM. I hope this also improves russian roulette randomness.

    This change should not cause ill effects and should be beneficial in my opinion, but it's difficult to know for sure. We need to keep an eye on this to ensure no new issues happen now.

*   Path Tracing: russian roulette for faster path renders controlled by parameter min_bounces

    * If this parameter is set to 0, russian roulette will be enabled.
    * If set to the same value specified in depth (max bounces), russian roulette will be disabled
    * If set to a value between 0 and max bounces, then russian roulette will only start be applied after this number of bounces, so we can get decent sampling in dark areas for example and get a good speedup with less noise.

    The lower this parameter is, the more speed and more noise.

    Path Tracing integrator: added new Russian Roulette parameter to speed up path tracing

*   *   IMPORTANT: big changes to textures interpolation changes to imagehandlers. Now all imagebuffers are internally linear and optimized by default.

    To solve the problem detected at http://yafaray.org/node/787 where I found out that YafaRay is doing the texture interpolation *after* decoding the texels color space. This was causing significant differences in color between standard bilinear/bicubic and when using trilinear or EWA mipmaps.

    I believe that the correct way to interpolate textures is to decode color space into linear space every time a texel is read, before the texels are used for interpolation. That way the interpolation is calculated correctly in linear color space.

    From now on the user will be responsible for selecting correct ColorSpaces for all textures, including bump map, normal map, etc. For example for Non-RGB / Stencil / Bump / Normal maps, etc, textures are typically already linear and the user should select "linearRGB" in the texture properties, but if the user (by mistake) keeps the default sRGB for them, YafaRay will (incorrectly) apply the sRGB->LinearRGB conversion causing the values to be incorrect. However, I've added a "fail safe" so for any "float" textures, bump maps, normal maps, etc, when getting colors after interpolatio YafaRay will to a "inverse" color conversion to the original Color Space. This way, even a mistake in user's color space selection in bump maps, normal maps, etc, will not cause any significant problems in the image as they will be converted back to their original color space. However, in this case rendering will be slower and potential artifacts can appear due to interpolation taking place in the wrong color space. For optimal results, the user must select correctly the color space for all textures.

*   Textures will be "optimized" by default. I think it's clear by now that optimized textures greatly improve memory usage and apparently don't cause slowdowns (might even make it slightly faster due to reduced RAM access?)

*   Fixed uninitialized values generated by Ambient Occlusion sampling

*   IMPORTANT: Initial support for Texture Mipmaps / Ray Differentials. BIG changes to ImageHandlers
     * Modifier all ImageHandlers to standardise access and make them more flexible
     * Added new Grayscale internal buffers (optional)
     * Reorganized all Interpolation and GetColor code
     * Added MipMap capability to ImageHandlers
     * Added Trilinear MipMap interpolation based on Ray Differentials.
     * Added EWA MipMap interpolation based on Ray Differentials
     * Heavily modified IBL blur function, to use mipmaps with manually calculated mipmap level instead of the previous dedicated "IBL blur" process

    All these changes are SIGNIFICANT and could cause new bugs... we have to closely monitor

*   Fixed EXR MultiLayer image file saving

*   Angular camera: fixed wrong renders due to incorrect default clipping
    As stated in http://yafaray.org/node/779 there was a problem in the Angula Camera rendering. In many cases, the background was shown instead of the surrounding objects.
    I've found the problem in the default clipping plane calculation for the camera, when no clipping is supposed to happen. By default, the far clipping distance is set to -1.f, which normally allows rays to travel without clipping as they are not supposed to go behind the camera.
    However for angular cameras, rays can actually go behind the camera when using wide angles. In those cases, the rays were incorrectly clipped at a distance of 1.f units behind the camera position.
    So, I've set a new default far clipping distance for the angular camera, using a very high negative value. I hope this will allow all rays (in front and behind the camera) to travel without clipping.

*   Image Texture Interpolation fixes
    Proposed fixes to solve the problems described in http://www.yafaray.org/node/783

    The fixes solve the problem with the strange stripes at top and left of the texture.

    Also, the changes implement extra code to take into account texture edge interpolation differently when:
    * Texture is alone (clip), extended or checkered. In this case, the edges are interpolated against themselves
    * Texture is repeated. In this case the way the edges are interpolated depends on the MirrorX/MirrorY parameters. Depending on these params, the edges are interpolated against the opposite edge (normal) or the same edge (mirrored).

*   Texture mapping: allow MirrorX,MirrorY even when Repeat = 1

*   Added building instructions for several platforms and scenarios

*   Qt support reintroduced and updated for YafaRay v3, but still in a basic state, many features not available yet for the Qt interface

*   CMake/Swig: modified Ruby interface to avoid Blender crash with Ruby bindings enabled

*   CMake: IMPORTANT change/updates to the building system. Versioning integration with Git. Standardisation of paths. Re-introduction of standalone builds and improvements to runtime search of libraries.
    Several changes have been introduced to the CMake building system to:
    * Integrate versioning with Git for automatic versioning of builds based on the current Git tags.
    * Standardisation of installation paths for different OS. Now, the plugins will always be installed in the folder "yafaray-plugins", no matter if it's installed as a pure Core release to the bin/lib system folders or as a Blender add-on.
    * Removed the automatic Blender-Exporter git deletion+download every time Core was built as a Blender add-on. This made rebuilds and tests very slow and cumbersome. Also, using "rm -rf" in the CMake building process is a risky and non-portable process. Now, the developer *must* download manually the Blender-Exporter using git and in the UserConfig.txt file, the path to the Blender-Exporter code *must* be specified. It's a little more inconvenient the first time, but I think it's much more convenient for subsequent rebuilds and tests.
    * Added CMake option for searching for libraries in an alternate location.
    * Removed findOpenCV CMake module that was not working too well (old, outdated maybe?). Without it, it seems finding the OpenCV files is easier in general. However in some cases it might be necessary to set the path to the OpenCV libraries manually.
    * For MacOSX, added option to select the Framework in the UserConfig.txt file for convenience
    *yafaray-xml: better autodetection of plugins path, but in some cases "-pp" may still be needed

*   Fix bug that caused many extra render passes to be generated in some cases

*   Fix for SPPM sudden brightness change when reaching approx 4,300 million photons
    As reported in http://www.yafaray.org/node/772  when SPPM accumulates a total of 4,300 million photons approximately, the scene brightness changes very suddenly.