Just a quick update... I've been making some great progress with transmitted specular for IBL!

These screenshots will look a little strange (I mean that black borders & grainyness), because it's a debugging rendering mode.

I've got the split-term stuff going; and it looks like it should be practical. I'd prefer to avoid having yet another cubemap, so maybe there's some way to just reuse the reflection filtered cubemap. Its seems reasonable to say that the filtering should be similar. We just need some way to calculate the amount of blurriness that is correct for transmissions.

Speaking of that, I've been thinking the type of filtering that is applied to the specular map. More on that later.

Next week I'll post some proper screenshots & a whole lot of details!

I made some interesting observations while doing this, I've got a bunch of new changes and improvements for IBL. Check out the "experimental" branch for now.

BTW, the node diagram for the GGX BSDF equation looks a little nicer now --

I've included a few Gradle scripts in the XLE distribution. This is mostly just a simple set of tools I use for my own testing. But you may find it useful for your own needs.

Of course this system isn't designed to be 100% robust and fool proof. Actually, it's just a few simple scripts. But it is scalable and flexible.

Gradle

At heart, an "asset path" is some system that can identify changed assets, recognize processing working that needs to be performed with those assets, and schedule that work.

For example, we might have an asset for a sky background texture. Various processing tools need to pre-filter this texture so it can be used for image based lighting. Whenever the texture changes (or when the processing tools change) we want to execute the processing steps and produce intermediate assets.

XLE does some processing at runtime. But that is only practical for short processing steps. Expensive processing steps need some other solution.

So we need some build system to manage assets and dependences. Are requirements are similar to build systems we use for code. But most code-oriented build systems don't work well for assets.

I picked Gradle because of it's procedural nature. It allows us to specify input assets -- but also to give instructions to the build path on how to handle that object. For example, we need to tell the build path if a texture is a sky texture, a normals texture, or some other type... That kind of thing just falls out of Gradle very easily.

Executing Gradle

First, you need to install Gradle, from: http://gradle.org/gradle-download/

In Tools/AssetPath, we have the "settings.gradle" root project file. Also, this folder contains some "groovy" source files that contain gradle task type implementations. So, there is a task type for processing sky textures -- which basically just involves executing a number of command line operations.

I've modified the lighting equations to allow for transmitted (as well as reflected) specular for dynamic lightings. Transmitted specular means the light is on the opposite side of the object, but light is coming through the object towards the viewer.

This is important for thin materials (such as leaves)

No transmitted specular:

With transmitted specular:

Here the amount of transmission is maybe slightly too high -- but it shows the effect well. This works particularly well with shadowed directional lights and geometry using order independent transparency. The above screenshot is exactly that situation. The tree leaves are rendered with stochastic transparency (which works particularly well for this model). So we get a nice halo effect around the edges of the tree.

And, if you look closely, you can see that the tree shadowing is blocking the transmitted specular, giving a volumetric look.

This model is built in a way to create a lot of noise in the normals. As you can see here:

Normals point in every direction, and there is a lot of local variation.

The master branch has just been updated! It now includes a major new tool, called the MaterialTool. This is a dedicated app for building materials and applying them to objects, and includes some cool new features...

In XLE, most material information can be authored in standard graphics packages (like 3DS Max, Maya, Substance Painter, etc). In particular, the most critical material values (color, roughness, specular & metal) can come directly from standard packages.

But in cases we want to add custom information to models, or even develop custom shaders for complex materials. This is were the MaterialTool comes in. There is some functionality in common with the ModelViewer and LevelEditor tools -- but the MaterialTool provides a convenient focused tool for this kind of work.

Basic functionality

Our core functionality allows us to preview a model (much like the ModelViewer, with various rendering modes), click on materials and then change their properties (such as opacity, translucency modes, and various shader flags).

This works within the Sony ATF framework, and so we have all of the handy features from the LevelEditor, such as:

• detachable, arrangeable windows
• IronPython scripting and cvar access
• interface skinning, keyboard rebinding, etc...
• and, of course, it's all very extensible C# code, convenient for adding custom features