Mattline1

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.

Yes, it is fair. The quality of a product is distinct from it's price, a bad product is a bad product. A review or critique exists to inform future customers of the product they're purchasing, given (hopefully) accurate reviews that customer can then determine if they think the game is worth the price. In order to make that decision accurately, honest reviews are required. If those reviews are heavily critical, even of cheap products, then so be it.

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.