PBR Texture support

Component:YafaRay Core
Category:feature request
Assigned:David Bluecame

Dear Yafaray team,

seeing as most texture production providers supply PBR materials, we wanted to know if

Yafaray will be supporting these kind of textures in the NEAR future or if there is a way of making them function correctly.

Best regards and Happy Holidays


ACCA Software S.p.A.



Assigned to:Anonymous» David Bluecame
Status:active» postponed


My roadmap for YafaRay-E is as follows:

* upcoming YafaRay-E v2.0.0 (hopefully will be released over the next weeks): Render Passes, texture RAM optimizations, advanced noise control parameters and a few more changes.

* future YafaRay-E v3.0.0: after I finish v2.0.0 I'm planning to start working on materials to make them more powerful, flexible and realistic. I suppose that will keep me busy for quite some time.


I didn't know about those PBR materials, but perhaps that could be interesting for v3.0.0. Will you please provide more details about what do you want to do that the current YafaRay materials cannot achieve, and where exactly do you believe the PBR materials would provided added value?


Thanks and best regards.


Hi David,
sorry forthe late reply. I hope the season holidays went well and that you have a great 2016.
First of all, I really appreciate the time and attention you put into our technical issues with Yafaray. ACCA made a donation last December because we feel its good to help out when possible.
Getting back to our use with Yafaray, it now seems that most digital artists and anyone involved in the illustration world, whether it be for design purposes, (engineers, architects, etc) or for gaming, is switching to PBR textures (Physically Based Rendering). In Architecture, and therefore in our specific field for software solutions for Architects, an increasing amount of Texture Producers are providing their materials in PBR so we are gradually making this switch in order to allow our clients to use them in their projects and increase the realism of their work.

There are many references online that explain the technology behind it but in terms of our implementation process, it's simply a matter of loading extra texture maps in association with a specific material. (albedo, glossy, bump, alfamask, etc.)

I hope you're going in this direction with Yafaray and would I would like to know if ACCA can help in any way.

Here are just a few references:


Best Regards

John ACCA Development Team


Status:postponed» needs review


Probably you are already aware of this, but just in case: since YafaRay-E v0.1.99-beta3 I we have available an extended range of texturing options. Perhaps part of your PBR requirements could be achieved with those mappings?

You have more information and some example screenshots here:



Please let me know how this fits in your needs for PBR textures. In case those texture options are still not enough for your needs, please give me some examples of materials you need to create where YafaRay falls short with the current material capabilities.


Best regards. David.


Hi, I'm attaching a few PBR texture file together with their relating marmoset resulting image to link: http://www.acca.it/download/files/PBR-Example-Textures.zip

The main issue lies with use of the _G map which really does increase the overal realistic effect of the material. We've also tried the Beta version you suggested us to test but have already seen that these PBR textures currently can't be used fully.
Please let us know if you require further info and how we can help.

Best Regards

John ACCA Software S.p.A.



You don't need to use that beta3 version, that was the first version with the extended mapping capabilities, but any recent YafaRay-E version has those. If you use YafaRay-E v2.0.1 for example you still can use the extended texture mapping.

I have to say that I'm not happy about the current YafaRay materials and I think they need some work to make them better. I will keep PBR in mind when I do that.

However, for the time being, please see the attached XML example (for YafaRay-E v2.0.1). Please test it by editing the XML to point to the folder where you have the brick textures and rendering it. This example will generate several passes, including the pure diffuse, glossy direct, indirect, etc, so you can evaluate how the textures are influencing the final Combined result.

I know it's not the same, but I hope you can somehow use something like this for now.


bricks-yafa-pbr-test1.zip 204.36 KB
yafray [pass combined].png 1.18 MB


Thanks for your reply,

We'll be evaluating your xml file but in general, I think that there's a lot to be done in terms of PBR support. This aspect is crucial for us now.

However, we're sure that you'll be coming up with something in the near, very near future and with our support!! :-)

Just one thing, could you please provide the same file in Blender format please ?


John, ACCA Software S.p.A.


I think this won't be too difficult to implement since YafaRay is already a phisically based montecarlo engine and it does observe energy conservation rules and our scalar texturing needs a deep review anyway. I will try to write a complete proposal about this.

My work · Grey18 workflow · Sampling strategy · [url=http://www.yafaray.org/node/816]SPPM



I've attached the .blend file.

A proposal with the requirements would be great indeed, as it would provide us with the details we need to ensure we make the correct changes.

Also, at this moment my main focus is materials/texturing, so this is a great time to do all this work.

Best regards.

bricks-yafa-pbr.blend 577.29 KB



please keep us updated on this matter..





Priority:normal» critical


I'm not sure if this may help but there's a lot of useful info here: http://www.marmoset.co/toolbag/learn/pbr-conversion

With regard, please note that we are currently looking for PBR support and refer to textures available at www.gametextures.com in our tests. They work very well but would like to load them in Yafaray too...


Whatever info you require, we'd be delighted to help.


John. ACCA


A good starting point about the whole PB shading theory is here: http://blog.selfshadow.com/publications/s2014-shading-course/

paticularly the "frosbite" paper

My work · Grey18 workflow · Sampling strategy · [url=http://www.yafaray.org/node/816]SPPM


Looking a those documents, I find nothing but familiar terms YafaRay is using since it was refactored in 2005. YafaRay, Lux and the PBRT engine Lux forks from are actually the first engines based on the PBRT book and the first ones to use features referred to as "phisically based shading" on these papers, like the fact that our materials are a mutually exclusive balance between diffuse and specular components that follow energy conservation rules, or the fact that the higher the exponent is, the more reflective becomes a material. For instance, the coated glossy material follows energy conservation rules in the sense that the three components (diffuse, specular glossy, coated mirror) will never reflect more light that the surface gets and that if one is reflecting 100% of incoming light, for instance coated mirror at grazing angles with high fresnel, the other components will just disappear.

This does not mean that YafaRay can not improve, on the contrary I believe current microfacet models used in YafaRay can possibly be improved a lot, for instance diffuse component darkening at grazing angles in glossy material. So it is really a matter of naming conventions and providing a compatibility layer for PBR textures to load in YafaRay.

From this paper:

  • Energy conservation: yes, YafaRay follows energy conservation rules.
  • Albedo: I suppose this is the color map, though in YafaRay we have means to map diffuse reflection strength independently from chroma values, although it remains to be tested.
  • Microsurface: Exponent mapping, recently implemented in YafaRay.
  • Reflectivity: Mirror amount in YafaRay.
  • Fresnel: IOR mapping, recently implemented in YafaRay, but on the document of reference fresnell is used in balance with glossyness which I do not understand very well, so more investigation is needed in this area. In YafaRay, a fresnell mirror can be layered on a diffuse component without needing microfacet specular aka glossy at all. Maybe is a similat concept of our coated glossy material.

Besides, YafaRay implements diffuse microfacet mapping aka orent-nayar sigma mapping, which makes a difference for "phisically based" texturing as they call it on these papers IMO. Once the compatibilty layer is implemented of course we need testing to see if YafaRay delivers but the basic concepts are already there.

My work · Grey18 workflow · Sampling strategy · [url=http://www.yafaray.org/node/816]SPPM



I fully agree with Álvaro. From what I've read it seems that PBR textures are more a challenge for game engines that are full of non-physical tricks to make them fast enough for realtime. For a full render engine as YafaRay it should not be that complicated to make the PBR work fine.

I would suggest doing this in several stages:

*  Short/medium term: minimal changes and tests to make sure the materials and textures "just work" for the PBR. I would do a review of the current system to fix any obvious problems. For example, I would like to review the current texture system as Álvaro said is a bit strange. Also I've seen some materials like glossy have glossy effect even if the glossy reflection amount is set to 0.0, which is not correct. So my first objective will be to do this.

* Medium/long term: full review of the materials and texture system to fix the current problems we have (like suboptimal glossy implementation), perhaps add or improve other shaders like diffuse, making sure that Fresnel works fine and also to add/improve texture mapping options like the AO, and solve any problems with the Bump/Normal texture mapping.


Hi, David & Alvaro,

First of all, thank you both very much for your posts.

Alvaro's detailed analysis is deeply appreciated and we are very sure that with such competence on the matter, PBR support will soon be fully implemented and that the Yafaray engine has the potential to evolve correctly towards this direction.

Secondly, we hope that the activities described by David will fit into the development pipeline and therefore become decisive for a first implementation and test. Please keep us posted on this in terms of progress.

As already stressed previously, we hope to support this implementation.

.....continue with the great work!


Best Regards

John - ACCA


Hi John can you provide a typical texture pack or several ones for some materials and renders about how should they should look like please? Also we could use material settings screenshots in their original app. to see how settings translate from one app. to the other.

My work · Grey18 workflow · Sampling strategy · [url=http://www.yafaray.org/node/816]SPPM



Yes, we already sent a group of textures. Here's the link for download:


These have the various Texture Maps and the Final result too.


If you require others, please send me a private email address.

Best Regards

John - ACCA


Hi John, I have several questions about the texture packs you've posted

One question, what's the difference between a _alb and _d map in the metal example? Since neither of them is greyscale then I suppose they are not mapping a scalar value but color in either diffuse or specular component, am I right? Which one is mapping what?

Also in that texture package, there is a _mask map, what is the purpose of this map?

Also the _h map is the equivalent of the bump map, am I right? 

Why two normal maps are provided in the metal and other packages, _n and _nY+. I suppose the second is given as an option for engines that use inverted green channels in normal maps, am I right?

Are these suffixes standar practice for PBR textures? Which one is the expected workflow for the engines when using these textures, would they have to "read" the suffixes and load textures in the corresponding map to value or read all textures from a zip files at once and load all of the in the corresponding map to values? If not, then we will have to change naming conventions in YafaRay so users can identify them. Can you describe which "user" workflow is needed to be supported?

My proposal is the same as David, identify one by one the main changes needed to support these texture packages, open a feature request for each of them.

My work · Grey18 workflow · Sampling strategy · [url=http://www.yafaray.org/node/816]SPPM


"One question, what's the difference between a _alb and _d map in the metal example? Since neither of them is greyscale then I suppose they are not mapping a scalar value but color in either diffuse or specular component, am I right? Which one is mapping what?"

The albedo mad doesn't contain any shading effects on the material and is neutral but maps the specular map's color. _d doesn't map anything.

"Also in that texture package, there is a _mask map, what is the purpose of this map?"

The _mask map determines different material effects within the same texture.  (example: I may have a texture where wooden planks are divided by strips of metal. In this case the mask map may be usefule to define which parts are metallic and which aren't in relation to the metalness workflow). I'll look into this more however!!

"the _h map is the equivalent of the bump map, am I right?"

The height map is much more intense and isn't exactly a Bump map as such. I'll have a look at this in more detail!

"Why two normal maps are provided in the metal and other packages, _n and _nY+. I suppose the second is given as an option for engines that use inverted green channels in normal maps, am I right?"

Yes, you're right. It's an inverted green channel.

"Are these suffixes standar practice for PBR textures? Which one is the expected workflow for the engines when using these textures, would they have to "read" the suffixes and load textures in the corresponding map to value or read all textures from a zip files at once and load all of the in the corresponding map to values? If not, then we will have to change naming conventions in YafaRay so users can identify them. Can you describe which "user" workflow is needed to be supported?"

These suffixes change from produced to producer although their scope is the same. In various other PBR textures, produced by others, you may find _reflective instead of _G (glossy).

My proposal is the same as David, identify one by one the main changes needed to support these texture packages, open a feature request for each of them.

I'll look into workflow aspects in more detail but based on the above, please suggest your ideal procedure in relation to your needs.


Best Regards



The _mask map determines different material effects within the same texture.  (example: I may have a texture where wooden planks are divided by strips of metal. In this case the mask map may be usefule to define which parts are metallic and which aren't in relation to the metalness workflow). I'll look into this more however!!

This is supported in YafaRay with the stencil feature though in that particular example which is "Metal_ChromeScratched" I wonder which textures are actually being composited.

My work · Grey18 workflow · Sampling strategy · [url=http://www.yafaray.org/node/816]SPPM


For instance support for _ao maps is something that is not yet implemented. Do you think John it would be a good candidate for a feature request?

As you describe it, loading these textures is a manual thing for users, I would not worry too much about naming conventions for now, in the sense that we users can always get by using some good documentation about it. I worry more about units and getting the same scalar strength in the PB texture creation suite than in YafaRay. In that regard I guess we could adapt YafaRay to new standards as long as they are better than the ones we have been using so far.

Another feature request could be this: http://www.yafaray.org/node/320 since YafaRay can only mix diffuse color channels with stencil masks and I guess in these layer based texture creation suites, mask can be used for more than diffuse color mapping. It would be great if we can know what other "map to" channels stencil should be able to work on so David can focus better about his work.

My work · Grey18 workflow · Sampling strategy · [url=http://www.yafaray.org/node/816]SPPM


Not quite sure which other chanells the stencil (_mask) map can be "mapped to" but seeing as most of our PBR textures are supplied by www.gametextures.com - please have a look at these reference tutorials where you can see how they map each of these channels.

1 - https://www.gametextures.com/using-gametextures-in-unreal-engine-4/ (section 8)

2 - https://www.gametextures.com/using-gametextures-in-unreal-engine-4-part-2/ (section 10)


Hope this helps in some way.


Best Regards



I will try Marmoset free trial to see the real posibilities of PB texturing in that software and what would needed to be implemented. However, supporting node-based texturing workflows without a node-based UI editor will be difficult, particularly for complex materials and general debugging. However, YafaRay is pretty much ready for node-based texturing workflows since internally already works that way and it is XML supported (XML texturing blocks = nodes). I will post my results withing some days.

My work · Grey18 workflow · Sampling strategy · [url=http://www.yafaray.org/node/816]SPPM


Let me be clear.

We're not looking for a node based editor since this would turn out to be incoherent with our user experience. What is required is that the individual texture maps, as supplied in the PBR format (see gametextures for example) need to linked up "in the background. Each of these maps can then be tweaked up according to what kind of end result the user is looking for.

Node based texture editing isn't required at this stage.


Best rEgards



Ok got it ! lets try anyway

My work · Grey18 workflow · Sampling strategy · [url=http://www.yafaray.org/node/816]SPPM


Hi John

I am trying right now with marmoset toolbag and the first question that comes to my mind is that indeed there are PB texturing file formats which are *.tbmat for Toolbag, *.sbsar for Substance and *.vmt for Valve. These material file formats store not only texture inputs for each material feature but also base colors, blending values etc. These file formats store also other material properties not defined by textures like type of of specular reflections and other material properties not supported by YafaRay right now. My question is whether you would need to support reading these material file formats or only working on texture inputs? These material file formats use markup language but supporting them is going to be lot of work for David so it would be great if we can outline bare mininum needs to start from.

My work · Grey18 workflow · Sampling strategy · [url=http://www.yafaray.org/node/816]SPPM


Hi, don't worry about this, we only need texture inputs.

Best regards 



I have found no significative differences for albedo, mirror mapping and glossy mapping. Both YafaRay and Marmoset Toolbag produce similar results:

YafaRay diffuse color mapping (left) and Marmoset albedo mapping (right)
YafaRay mirror mapping (left) and Marmoset mirror mapping (right)
YafaRay Glossy amount mapping (left) and Marmoset Blinn mapping (right)

The differences you see is because they are not using exactly the same shading models but results are fairly similar and there is not any luminance shift. There is a problem though with exponent mapping reported here. There are more issues though, for example the fact that all scalar values in Marmoset Toolbag (and in Substance I guess) use a 0-1 range while in YafaRay some scalar values use other ranges, like exponent which is 1-10000 or IOR which is 1-30. I wonder if a feature request could be normalising all scalar values in YafaRay materials to 0-1 range and what kind of consequences it would have.

My work · Grey18 workflow · Sampling strategy · [url=http://www.yafaray.org/node/816]SPPM


This is a little energy conservation test, in which diffuse and specular channels are mapped at the same time. Both more or less manage energy the same, there are differences due to using different reflection models. You can see an example of that in this post.

YafaRay energy conservation (left) versus Marmoset Toolgbag (right)

PD: there is a simple test to see whether a render engine is doing energy conservancy, which is changing diffuse color while specular reflection is 100%. If nothing changes then is doing it right.

My work · Grey18 workflow · Sampling strategy · [url=http://www.yafaray.org/node/816]SPPM



Materials will be my next step. From the conversation above I don't yet understand well what's needed to be changed in YafaRay to comply with this Feature Request.

If you could tell me exactly what are the exact problems with the current materials and what's needed (the more detailed and specific, the better) I will try to implement this for the next version.

Best regards!


Hello David,

I'm John ACCA Software, unfortunately I was absent several months for personal reasons from work. I wanted to ask what kind of progress has been made on YafaRay in recent months. Also, I would be grateful if you could provide documentation of things done and how to implement them in XML files. This would allow us to add new features and make integrations making Edificius even more powerful!

Regarding PBR materials I send you some links where you will find several useful information to implement it in YafaRay:


 http://www.pbrt.org/fileformat.html (N.B. If you need this book we can buy us and ship it to you!)

https://de45xmedrsdbp.cloudfront.net/Resources/files/2013SiggraphPresentationsNotes-26915738.pdf (<-UE4 PBR implementation details)








Thanks for the help they give me Best regards

John ACCA Software S.p.A.


Thank you very much, John. Finally I've arrived to the material improvements stagw now so I will try to implement this. I will keep you informed of any progress.

About recent news, what's the last version you know about? I've released version 3 (v3.1.1-beta at the moment) with many changes respect to Eperimental v2.1.1, for example.


Thanks Dave,

we're currently working with v.1.1.0. so we need to catch up a lot with regard to documentation to implement the latest improvements. I would really appreciate it if you could send me info with regard to how to setup the xml parameters appropriately for communication with Edificius.

Best Regards




Hello, John.

The amount of changes between YafaRay Experimental v1.1.0 and YafaRay v3.1.1-beta is... significant. I've been unable to keep the documentation and examples up-to-date, I apologize for that. The list of changes are in the YafaRay v3.1.1-beta build README file. Some of the changes are related to the Blender Exporter, but most of them affect the Core YafaRay code.

Perhaps the best way for you to see the current YafaRay state and features would be to use Blender v2.78 and the current YafaRay v3.1.1-beta build. You can export to .xml as well to see the values of the parameters generated by the Blender exporter.

Today, I downloaded and installed Edificius (with the 30day trial license) in Windows 7 64bit and I replaced the included YafaRay v1.1.0 with v3.1.1-beta, without any obvious issues.

From the many changes, I would highlight the next for you:

* Texture optimization option: Using one of the ACCA website examples, YafaRay used approx. 2,000MB RAM. With the new v3.1.1-beta and adding the Texture optimization option to the .xml manually, the YafaRay RAM usage with the same scene was reduced to around just 400MB RAM (!!). I think that could be significant for you.

To add the optimization option, for each texture please add this:

<texture name="Texture_0" >
[blah blah blah]
   <texture_optimization sval="optimized" />
[blah blah blah]

* Image autosave, for example if you want to show a preview of the image being rendered. To enable this, add these lines to the "render" section of the .xml:

    <images_autosave_interval_seconds fval="10"/>
    <images_autosave_interval_type sval="time-interval"/>
    <tiles_order sval="centre"/>

You can select another interval in seconds (floating point value) but keep in mind that the shorter the interval, the longer the rendering will take.

* Image denoising option. To enable it, add this to the "render" section:

    <denoiseEnabled bval="true"/>
    <denoiseHCol ival="5"/>
    <denoiseHLum ival="5"/>
    <denoiseMix fval="0.8"/>

* Sending a CTRL+C to YafaRay allows it to end the rendering. It will save the "incompletely rendered image", in case you want to add that "Cancel Render" option to Edificius.

* Support for multi-threaded photon mapping generation. This is automatic in YafaRay v3.1.1-beta, you don't need to do anything to the .xml file. However, I've seen that the .xml file generated by Edificius sets the threads to "24". Rendering with more threads than CPU cores does not help and could actually render slower than using fewer threads. I would suggest you just remove the "thread" option or set it to "-1" (automatic detection of CPU cores to determine the number of threads)

* Faster multithread rendering in Windows. I used a library that renders multithread with a lot less "thread overhead" so for simple scenes it should render faster than before. For complex renders it will not change much. No need to make changes to the xml file.

* Fixed HDRI lightning. It had several bugs that caused incorrect lighting and fireflies. It should be more correct now with less noise.

* HDRI smart blur to reduce noise: this option keeps the original HDRI for background and reflections with full detail but internally blurs it for lighting to be smoother. In the "world" section add, for example:

<smartibl_blur fval="0.15"/>

This could reduce realism a little bit but the reduction in noise may be worth it.

* Shadow casting control (I think you asked for this). You can adjust it for the "world" section like this. You can control it independently if you have sky with sun. If you have HDRI images, the cast_shadows_sun has no effect.

    <cast_shadows bval="true"/>
    <cast_shadows_sun bval="true"/>

* Render passes. You can define render passes with a new section you can put, for example after the "render" section. For example:

[blah blah]

<render_passes name="render_passes">
    <pass_RenderPass_1 sval="diffuse"/>
    <pass_RenderPass_2 sval="indirect"/>
    <pass_RenderPass_3 sval="reflect"/>
    <pass_RenderPass_4 sval="mist"/>
    <pass_RenderPass_5 sval="z-depth-norm"/>
    <pass_RenderPass_6 sval="debug-normal-geom"/>


You can setup up to 32 passes (from pass_RenderPass_1 til pass_RenderPass_32). This will generate a separate image for each render pass, but of course will slowdown the render. The full list of available render passes in v3.1.1-beta is:



There are many other improvements, these are just some significant ones so you can do some tests. I hope you like them. Please let me know if they work for you.


Back to PBR support, I'm currently studying YafaRay's material system. I'm at the early stages, but I hope to be able to improve some materials and hopefully add some "PBR-style" options in the near future. I will keep you posted.


Hi Dave,

first of all, thanks for taking the time to answer all those issues and for sending the precious info.

Very helpful and we appreciate it. We'll be trying these new features out in the upcoming days and keep you informed.

I hope you can continue working on introducing new features and optimizations. It helps us to believe in your effort more and more.

If you send me your email address, used for registering Edificius, we'll activate a six month educational license for you so you can continue to test Your beta versions with the software directly. You can send it to snake3435@gmail.com


Best Regards

ACCA dev team


I think that the option to reuse a photon map for subsequent frames could be useful when users render an indoor animatiom

My work · Grey18 workflow · Sampling strategy · [url=http://www.yafaray.org/node/816]SPPM


Status:needs review» active


Version:» <none>
Component:Code» YafaRay Core
Status:active» needs work


Status:needs work» postponed