Jump to content

Mattline1

Members
  • Content Count

    27
  • Joined

  • Last visited

Community Reputation

40 Excellent

About Mattline1

  • Rank
    Member

Profile Information

  • Gender
    Male

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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?
  2. Mattline1

    PBR update

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

    PBR update

    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>
  4. 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.
  5. Vid of a Wip :)

    1. Show previous comments  6 more
    2. gamecreator

      gamecreator

      Story of our lives eh? Everything is more difficult than we first imagine it. ;) I look forward to reading the post.

    3. shadmar
    4. diedir

      diedir

      well done, great wipeout kind

  6. Mattline1

    Website Updated

    Looks real nice. Information about the engine's features are a lot clearer, gives a much better idea of what it can do.
  7. 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.
  8. 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.
  9. When HDR is enabled do environment probes also get rendered/saved into an HDR format?. I seem to be getting clamping issues (been testing filmic tonemapping).

    1. Show previous comments  1 more
    2. macklebee

      macklebee

      If you are referring to the HDR option inside the editor and not adding a posteffect shader to the scene, then it appears it doesn't work or work properly: http://www.leadwerks.com/werkspace/topic/15473-hdr-bug-in-leadwerks-42/

      also still an open bug with probes which may be related: http://www.leadwerks.com/werkspace/topic/15697-multisamplemode-2-and-environment-probes-problem/

    3. macklebee
    4. Mattline1

      Mattline1

      Ok, thankyou for the info. I've come across some of the issues mentioned in the 2nd post. But if there's no change to the probe format that would explain the artifacts I'm seeing, likely due to LDR probes in an HDR environment. I'll make a suggestion thread with more detail.

  10. 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.
  11. Oh, this is useful information.
  12. The beta GUI is pretty swish, still getting my head round the details but it's already made menus far easier.

    1. Show previous comments  1 more
    2. shadmar

      shadmar

      I tried myself, but my gui always covers the entire screen. Even a button.

    3. Mattline1

      Mattline1

      Still got a way to go, I'm going for a source style menu. Something inoffensive and simple that can be re-used across multiple projects.

      https://1.bp.blogspot.com/-TYm-Ek8JikQ/V8ijCCDuX8I/AAAAAAAAD3E/S-OA0cV3qbgmdbU_g_w3nybjDOuchDHNACLcB/s1600/menus.gif

       

      There's a few little bugs with flickering and clipped widgets, not sure where the tabber flicker is coming from, I've not modified that script. I also can't figure out how to display images, every time I try to...

    4. Josh

      Josh

      Looking good!

  13. 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.
  14. 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.
×
×
  • Create New...