Announcement

Collapse
No announcement yet.

Global Illumination alternatives

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

    Originally posted by joshezzell View Post
    This doesn't work properly though. The way it's setup doesn't make it an easy workflow choice.
    yea i agree, workflow is clunky, but it's at least an option to consider.

    Originally posted by diegor View Post
    Can you further elaborate on this , do you mean that that cube maps have to be carefully placed in lighted areas , in that case , what can be done to improve this system , aside from better dynamic cubemaps , maybe automatic placement of them
    No the problem in a workflow one. You cannot specify unless you write code how and when to update reflection captures, and you have no clear way to choose which illumination condition to sample using a gui.
    This means building stuff by empirical steps, doing operations in series one step at a time, as there's no official workflow.
    So yes, we have the feature, but it's not really that usable.
    Needs an official panel in the spherical capture actor details with a workflow that users can interact with, otherwise it will be strictly limited to scripting/coding, and since it's a visual thing it's not the best use case.

    Comment


      even if building an automated placement system would be very difficult , exposing the creation of new reflection captures via blueprints and c++ with parameters such as refresh rate would be the only change necesary to the engine , so is a posibility .

      Besides what is the diference betwen cryengine emplementation and unrea┬┤ls that makes the latters workflow very clunky , assumig that the former is not , becuase if it is too , how it was choosen as the primary gi system of a 3A engine.

      Also here is another way of using cubemaps to obtain global ilumination and while this document outdated and slower than the tecnique we were talking about,since this one places cubemaps evenly across , while under my understanding the currently used captured the information around areas with direct ilumiantion is worth reading http://citeseerx.ist.psu.edu/viewdoc...=10.1.1.95.946, unless both are the same , and i am wrong.
      Last edited by diegor; 04-17-2015, 05:53 PM.

      Comment


        UE4 already has pre-convolved cubemaps for GI, that's part of what static GI is in the first place. And the entire point of other "GI" solutions is to get it to work in realtime, which while you can do pre-placed cubemaps and re-light them in realtime, if you're quite clever and willing to make tradeoffs, you can forget about rendering entire cubemaps in realtime unless you're only doing one.

        Besides, cubemaps alone for GI have a ton of problems with lightleak and placement and parallax and etc. etc. that ideally, a better realtime GI solution wouldn't have.

        Comment


          Okay , i see your point , but ideally the changes that i mentioned earlier could be included , and the parallax problems could be resolved using parallax corrected cube maps , which in simple words gives the cubemaps a parallax map that bumps and breaks the ilution of the cubemap being just 6 flat surfaces https://seblagarde.wordpress.com/201...ected-cubemap/ http://forum.unity3d.com/threads/has...apping.113784/ check this posts , the first one also gives more details about image based lightning

          Both of these ideas would be veryuseful for reflection mapping especially the second one , since it would make reflections much more beleivable and using them for gi would incur in very little changes , basically just apliying reflection maps with the direct lightning to all objects , instead of the reflective ones and blurring them or using lower resolution mip map for the rough objects .

          But still do not understand how expensive are cubemaps , i thought that they were cheaper , because they are hardware accelerated , after all the 13 yers old thecnique of my previous post uses them semi dinamiclly .

          They can be rendered at much lower resolution as stated earlier , only when the scene changes and across frames ; with a much lower polygon lod ; they could even do without bilinear filtering and maybe , just maybe without any texture if the direct lightning is painted onto the polygons.

          And again why can cryengiene eaas use it, even if only for static lightning , which i have my doubts against , since it still has a dynamic day/night cycle and supports dynamic destruction and geometry cache(i dont know if both are the same for the renderer , maybe geometry cache can use some sort of precomputation ,since is a predefined playback of geometry across a number of frames.
          Last edited by diegor; 04-17-2015, 09:44 PM.

          Comment


            It seems like meshes painted with the foliage tool don't appear to be affected by DFGI (even when the instance option for DF is checked), anyone else have the same problem? (in-editor everything looks fine, but upon "play" only manually placed meshes retain the correct lighting) Can't see why this ought to be a problem & want to avoid manually planting a forest..

            Comment


              Originally posted by Ravneson View Post
              It seems like meshes painted with the foliage tool don't appear to be affected by DFGI (even when the instance option for DF is checked), anyone else have the same problem? (in-editor everything looks fine, but upon "play" only manually placed meshes retain the correct lighting) Can't see why this ought to be a problem & want to avoid manually planting a forest..
              The foliage code disables DFGI. You have to edit the source to enable this.

              But why do you want to do this? DFGI is meant to be used at a distance, not close up?

              Comment


                Originally posted by hallatore View Post
                The foliage code disables DFGI. You have to edit the source to enable this.

                But why do you want to do this? DFGI is meant to be used at a distance, not close up?
                Ah, that would explain it.. any clue as to what & how to edit the necessaries? I'm currently working on a purely cinematic project & the effect of DFGI in-editor when used also close up is working visually quite well in a forest scene.

                edit: I'm quite new to UE, so very much open for a better recommendation of how to use DFGI/GI in general.
                Last edited by Ravneson; 04-18-2015, 09:04 AM.

                Comment


                  Originally posted by Ravneson View Post
                  Ah, that would explain it.. any clue as to what & how to edit the necessaries? I'm currently working on a purely cinematic project & the effect of DFGI in-editor when used also close up is working visually quite well in a forest scene.

                  edit: I'm quite new to UE, so very much open for a better recommendation of how to use DFGI/GI in general.

                  Can you use Cascaded Shadow Maps and turn up the distance?
                  Last edited by hallatore; 04-18-2015, 02:23 PM.

                  Comment


                    Originally posted by hallatore View Post
                    The foliage code disables DFGI. You have to edit the source to enable this.

                    But why do you want to do this? DFGI is meant to be used at a distance, not close up?
                    This doesn't even make sense. DFGI is supposed to be used close up. It's GI. It makes more of a difference up close then it will at a distance. Also, Epic used it in their Kite demo and it affected the trees. I hope they make it affect foliage (with options to disable it on foliage for those that need it) because it's kinda pointless for some types of projects otherwise. Not all of us want or have the skill to compile from source and make the edits that are needed to do this.
                    --
                    Joshua
                    Multimedia Artist, Druid Gameworks
                    www.joshuaezzell.com
                    www.druidgameworks.com

                    Comment


                      Originally posted by joshezzell View Post
                      This doesn't even make sense. DFGI is supposed to be used close up. It's GI. It makes more of a difference up close then it will at a distance. Also, Epic used it in their Kite demo and it affected the trees. I hope they make it affect foliage (with options to disable it on foliage for those that need it) because it's kinda pointless for some types of projects otherwise. Not all of us want or have the skill to compile from source and make the edits that are needed to do this.
                      Compiling from Source isn't as hard to do as you think:

                      KITATUS
                      "Information shouldn't be behind a paywall, It should be free for all!"

                      Comment


                        Originally posted by hallatore View Post
                        The foliage code disables DFGI. You have to edit the source to enable this.

                        But why do you want to do this? DFGI is meant to be used at a distance, not close up?
                        I believe you're mistaken DFGI(Global illumimation, reflected light from object DFs affects lighting of the scene) with DFSS(Soft shadows)
                        SuperGrid: Marketplace Page | Feedback Thread | Demo | Website
                        Level design and prototyping for newbies

                        Comment


                          Originally posted by zeOrb View Post
                          I believe you're mistaken DFGI(Global illumimation, reflected light from object DFs affects lighting of the scene) with DFSS(Soft shadows)
                          That is most likely the case.
                          Here is the code I was reffering to. But as statet it might not be causing the problem described.

                          //@todo - take the settings from a UFoliageType object. For now, disable distance field lighting on grass so we don't hitch.
                          component->bAffectDistanceFieldLighting = false;

                          Comment


                            hallatore, upping CSS distance had no effect I'm afraid. The following screenshot shows the difference: (in-editor on the right, "play" on the left)
                            Click image for larger version

Name:	Skjermbilde-2015-04-19-08.14.jpg
Views:	1
Size:	708.1 KB
ID:	1074717

                            Also, if I understand you correctly, would changing that quoted value above to "= true" make a difference? (in the source code I'm guessing? not entirely a stranger to compiling, but no coder either) Also, is it the DFSS that's missing here, rather than the GI?

                            Comment


                              Originally posted by Ravneson View Post
                              hallatore, upping CSS distance had no effect I'm afraid. The following screenshot shows the difference: (in-editor on the right, "play" on the left)
                              Also, if I understand you correctly, would changing that quoted value above to "= true" make a difference? (in the source code I'm guessing? not entirely a stranger to compiling, but no coder either) Also, is it the DFSS that's missing here, rather than the GI?
                              This has nothing with what I stated above, this is something else.

                              Are your lights set to movable? And what happens if you turn up the intensity on the skylight?

                              This is my scene with/without the skylight set to movable.

                              Click image for larger version

Name:	nJUzEPK.jpg
Views:	1
Size:	212.6 KB
ID:	1074722

                              Click image for larger version

Name:	kv0oT61.jpg
Views:	1
Size:	178.7 KB
ID:	1074723

                              Comment


                                Skylight is moveable & changing intensity upwards only makes the "miscolouring" worse. Here's a screenshot (from in "play") showing a manually placed tree on the right vs. one placed with the foliage tool on the left. As you can see the DF lighting seems to work just fine as long as the meshes in question aren't placed with the foliage tool (it could be I've missed something essential though).

                                Click image for larger version

Name:	Skjermbilde-2015-04-19-12.35.jpg
Views:	2
Size:	797.2 KB
ID:	1074734
                                Last edited by Ravneson; 04-19-2015, 12:16 PM.

                                Comment

                                Working...
                                X