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.

It's a subtle issue, but around the edges of objects lit by an environment probe is a thin line of pixels, the colour of the pixels is determined by the diffuse buffer. This doesn't occur when anti-aliasing is disabled. Example: In the following image I modified the probe shader to simply fill it's volume with a solid colour. object boundaries within the volume display correctly (#2). However, where object edges meet areas that fall outside the volume, the artefacts are visible(#1). By looking at the edges close up it seems that material buffers are anti-aliased but the probe shader result is not, notice the jagged edge highlighted by the green line. (Speculation here, but I guess there is some kind of masking happening to cull pixels that fall outside the probes volume in worldspace. If so my guess would be aliasing on that mask is causing the issue. Unfortunately I don't think I can fix this purely in the shader.) It's not a huge issue, but can result in a quite visible outline on reflective objects.

Sounds good, that'll solve the issue. But I guess making the materials additive will introduce brightening on overlapping probes. Is it not possible to render the probes prior to other lights rather than as a post process? they could then use max blend without other lights affecting the result, then switch back to additive for the dynamic lights. Or is there performance concerns attributed with that?

In the following post by josh, it is mentioned that light from ambient probes is blended using glBlendEquation(GL_MAX); http://www.leadwerks.com/werkspace/blog/1/entry-1681-ambient-lighting-research/ Is it possible to modify this functionality? I've been trying to port my PBR work over to the new environment probes system and have found them to be very useful, but this issue causes some quite noticeable artifacts. as shown below. The reflection should still be visible even underneath the suns light. There is commented out code within the probe shader labelled additive blending, but it doesn't produce correct results. Nor can I see how an in shader solution could work, given that the shader is clamped with glBlendEquation(GL_MAX); Any solutions? if this can be sorted without c++ it'll remove the "gotchas" from the PBR work.

I've been having a quick look at this, seems pretty solid. I liked the settings loading from the first version and the input system looks like a useful extension of it.

I recently got round to checking this template out, it's so useful! Just little things like the prefab objects(lights, cameras etc..) it makes the process of building levels much smoother. Love the work you've done with this

Looks pretty fantastic. Nice to see the parallax correction as well, it adds so much to the final result.

Looks good! The hiding of dynamic objects is a nice touch, I hadn't thought to filter by mass.

I love these kinds of threads, its always interesting to see the small projects people are working on. Here's my contribution, I've been carrying on working on PBR and thought it'd be nice to show it off with Crytek's Sponza.

As per Rastar's suggestion, I've updated the metalness to be stored in a 4bit grayscale image. this frees up the alpha value so transparent objects and decals should work properly. https://1.bp.blogspot.com/-6B4XhAJ-VX8/Vs3swgt5k2I/AAAAAAAADr0/84VdRDnuhkM/s1600/4bitMetalness.png The compression is quite lossy, but once the other maps are applied it's not really noticeable.

@genebris I've been looking at Leadwerks project templates system, I will probably try and get that working over the next day or so, that should simplify setup. You'll be able to generate a new project with everything already setup then.