Mattline1

Looks nice! How well does it scale to larger scenes?

That sounds like a great solution. It would cover all seperable filters. Temporal anti-aliasing? That would need the current frame and a re-projected frame based on previous frame and a velocity buffer.

Cool, sounds like it will be easier to set up simple post processing effects. Will it be as flexible as the old system? My main concerns would be with ordering of post effects and how modifiable default effects and settings are. A few questions: Could default post effects be disabled or modified, in case the defaults don't match the art style of a project. Can the amount of blurring be changed? Does the blur just occur on the color map? depth too? Is there still a way to manually blur? Box blur looks very different to a guassian, and both have uses. Are shader settings modifiable at runtime? If bloom, tone mapping, and SSAO are baked into the camera what happens if another post process effect needs to occur in between them, i.e SSR needs to happen before tonemapping. I guess if there's no Lua code running in the rendering thread it will never be as flexible, but the LE4 system was very powerful as a result of it's ability to be heavily controlled via scripting. Being able to manually modify default shader source would answer a lot of these questions, is that still possible?

I have been looking at the EmitEventHook void hookFunction(void* ptr) { // do whatever } System::AddHook(System::EmitEventHook, hookFunction); I can't figure out the correct type for hookFunction's parameter(s). Event* seems the most logical but doesn't appear to be correct, other hooks tend to have pointers to relevant objects. Anyone know the correct parameters?

I removed it from the main repo to speed up download times. The files available under releases have the old demo in.

Main post available here I first presented my PBR work about a year ago, since then I've been tweaking and making improvements. Over the past 6 months Leadwerks has had some great updates for graphics junkies like me .The HDRi and environment probe features look great and have helped with 2 of the main issues with the last PBR system. Now what you see in the editor is what you get in the game, and HDR means proper tonemapping and a wider range of possible light intensities. Both of which are important for realistic PBR. I currently plan on using this for my current project, so expect consistent updates as I battle test it. The current build is available on github. Any issues and suggestions to help improve it are welcome. The project is available from GitHub Limitations / improvements Requires a gamma-correction post process shader. Not a huge issue, adding a pp is pretty easy but still something to remember. Currently the built in environment probes are stored in a low dynamic range. This leads to clamping and precision errors as HDR values move towards extremes. this limits the usefulness of HDR. This is an engine issue. Probes also use simple mipmapping for different roughness values, PBR often performs a convolution on stored cube-maps to better match reflection blurring due to roughness. A fix may be possible for this, but would require C++. </p>

The environments are looking nice. The latest images remind me of small west country english villages. You could perhaps do with some sort of ambient occlusion. It should soften up the ambient light and help with contact shadows.

Looks real nice. Information about the engine's features are a lot clearer, gives a much better idea of what it can do.

In the second image I had modified the sky shader to push values above 1.0. The brighter sky isn't reflected in the probe however. The same happens for any surface where brightness becomes >1, it appears clipped in the probes (often as grey as iris adjustment brings the clipped value down from 1.0, like in the image). The Sponza scene is here (pretty big, because of the textures :/). I had to do a quick convert back from PBR so the specular is a little shiny on most materials. The sponza is a worst case scenario, there is very little direct light so the probes have to do the heavy lifting. I've set the postprocessing to do gamma correction rather than full tonemapping as it's a simpler algorithm and therefore easier to discount as the cause. The artefacts are still visible. the tone-mapping shader is included as well. One last note, increasing the ambient term and rendering environment probes with that higher ambient can alleviate the problem. Though this feels like a workaround, as it ends up in washed out dark areas and means the probes can't be used on their own for nice GI. Hope that all helps.

Lookin' good man!

As in the title, my suggestion is to save and render environment probes into an HDR format whilst the HDR option is checked. The reasoning is below: I have been trying to take advantage of the HDR feature by implementing filmic tonemapping, but have been having issues with artefacts. The issue seems to be that environment probes store values in a low dynamic range. Because of this, when light values become >1 they begin to clip. For very small values the precision is low and causes banding and distortion issues. (see image) In the above, the left image is close to black before tone-mapping is applied, whilst the right image is nearly completely white. If an ambient term is used rather than image based lighting, then no artefacts are present. this suggests the issue is with the precision of the probes not the HDR diffuse image passed to the tone-mapping post process. To note, these issues only become apparent when probes + HDR + custom tone-mapping is used. which is likely an edge case for most Leadwerks users. That said we are unable to fully take advantage of HDR whilst elements of the lighting pipeline (probes) do not support it. Cheers.

Oh, this is useful information.

It's probably light bleeding through the geometry as the directional light switches to a lower resolution shadow map, as it does with distance. If so, the way to fix would be to increase the size of the ceiling csg tile so it overlaps the walls slightly.

Similarly to how you can create variables in lua scripts that appear in the editor, it would be nice to have a function that re-names the texture slots in the material editor based on the chosen shader.

Nice, looking forward to seeing this in the engine.