Announcement

Collapse
No announcement yet.

Working emissive materials in RTGI (with screenshots)

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Cyberpunk scene (no lights, just emissive materials):

    Before:
    Click image for larger version  Name:	CaptureBefore.JPG Views:	1 Size:	447.5 KB ID:	1662734
    After:
    Click image for larger version  Name:	tempsnip.jpg Views:	1 Size:	251.1 KB ID:	1662735

    Comment


      #17
      Hey TommyBear ! I've just now noticed Epic's reply on your Pull Request, and I must say, I'm really disheartened.

      The project I'm involved in relies hugely on emissive lighting support on geometry, baked using GPU Lightmass, and any migration over to DXR would require this same functionality.
      I tested your code change here, and it just worked! And worked very well indeed. There was negligible impact on adding a new geometry-based light source.

      I just wanted to say thanks for your efforts on this (should-be default in my opinion) feature.

      I'm having difficulty in determining what 'noise generator' means, have you got any insight into what Epic meant in their reply?
      GI Noise is relatively bad in the current state of DXR implementation in UE4, but I don't know how that would relate specifically to your approach, which simply adds a new light source, it doesn't create any noise that doesn't exist with point/spot lights. Unless I'm misunderstanding something?

      Cheers!

      Comment


        #18
        TommyBear Hey, thanks for your help the other day! I got this up and running and it produced the best results out of Unreal Engine’s DXR implementation that I’ve seen to date, with the only noise in the scene being the direct result of the Engine’s work-in-progress denoiser. I have no idea the real reason behind Epic’s denial of your pull request (I found their explanation unconvincing) but I hope they get back to you with better clarity than we saw in the comment.

        We’re all rooting for you! Great work!

        Comment


          #19
          Hey guys, I have read the comment from the dev and the meaning of "noise generator" there is that the implementation made was introducing "more noise". I would need to look at the whole code to understand better if that is indeed an impact, but hey that won't stop us to inject that code on a built from source engine and enjoy it. Since there are so many things still at work by Epic in relation to raytracing there is a chance this "more noise" is appearing on a code not yet submitted to GitHub involving reflections and denoisers, which we would probably get access soon when 4.24 code starts to appear there with more frequency and so it would be easier to understand if this implementation from TommyBear is breaking things.

          There is still chance for this in my opinion, but one thing is doing PR on a code which is stable, another thing is doing it on a frequently worked code like the rendering module is being for the last months. I got several things I would like to try, but it is really troublesome do something and the chances of it becoming trash because of a change in the engine happen.

          Kudos for TommyBear !
          Nilson Lima
          Technical Director @ Rigel Studios Ltda - twitter: @RigelStudios
          Join us at Discord: https://discord.gg/uFFSEXY

          UE4 Marketplace: Cloudscape Seasons
          supporting: Community FREE Ocean plugin

          Comment


            #20
            Hi Tommy,

            Sorry for your frustration, you deserve a more detailed explanation that what we provided initially. The reason we decided not integrate this pull request is because we have plans to modify that area significantly to make it more performant. Your pull request is indeed correct and adds funcionality that surely users will find welcome. In fact, your implementation is familiar to us: we do pretty much the same in the reference path tracer (pathtracing.ush) for dealing with emissive geometry.

            That technique is suitable for interactive rendering but slow for real time, where ray budgets are very low. In fact as you saw yourself you need to increase the amount of samples a lot, cranking it up to 30spp or more to get good results in simple scenes. We have plans to improve our light sampling techniques in the 4.24-4.25 time frame and these improvement will bring this funtionality together with other enhancements. We prefer not to integrate pull request that could collide with the changes we are already working on this particular area. Of course, you all are very welcome to integrate this pull request into your code base in the meantime.

            Again, thanks so much for your pull request and sorry for not giving you a more detailed answer before.

            Regards,

            Juan

            Comment


              #21
              Originally posted by Juan Canada View Post
              Hi Tommy,

              Sorry for your frustration, you deserve a more detailed explanation that what we provided initially. The reason we decided not integrate this pull request is because we have plans to modify that area significantly to make it more performant. Your pull request is indeed correct and adds funcionality that surely users will find welcome. In fact, your implementation is familiar to us: we do pretty much the same in the reference path tracer (pathtracing.ush) for dealing with emissive geometry.

              That technique is suitable for interactive rendering but slow for real time, where ray budgets are very low. In fact as you saw yourself you need to increase the amount of samples a lot, cranking it up to 30spp or more to get good results in simple scenes. We have plans to improve our light sampling techniques in the 4.24-4.25 time frame and these improvement will bring this funtionality together with other enhancements. We prefer not to integrate pull request that could collide with the changes we are already working on this particular area. Of course, you all are very welcome to integrate this pull request into your code base in the meantime.

              Again, thanks so much for your pull request and sorry for not giving you a more detailed answer before.

              Regards,

              Juan
              Perfect. Thank you Juan for the explanation This makes sense. Is the intention to handle sampling of material light contributions also, not just emissive geometry? It's a distinction for me because of the detail you can get from any animated material light source versus a large flat light geo light.

              Anyway, thank you very much for replying. All the best!

              Tommy.

              Comment


                #22
                Hi Tommy, I'd just like to say a massive thank you for making this possible. I make heavy use of emissive lighting in my projects, and it was really disappointing that the stock Ray Tracing implementation doesn't support it. I have a couple of quick questions if that's ok?

                Does this support GI bounce for emissive lighting? I think I'm only seeing direct lighting from emissives.

                I get no Ray Tracing at all on spline meshes (not even path tracing), which I'm assuming is something Epic need to add to the RT engine itself?

                Thanks again, and I've included I scene I'm working on which is lit 100% by RT emissives

                Dan Govier

                Comment

                Working...
                X