Search Unity

  1. Unity 2019.2 is now released.
    Dismiss Notice

Unity Enlighten deprecation and replacement solution

Discussion in 'Global Illumination' started by Jesper-Mortensen, Jun 19, 2019.

  1. Jesper-Mortensen

    Jesper-Mortensen

    Unity Technologies

    Joined:
    Mar 15, 2013
    Posts:
    196
    Due to Geomerics shutting down Enlighten as a product, Unity is required to remove Enlighten.

    Unity will continue support for Enlighten in the built-in renderer as it currently exists today (as-is, with no new platform support). The 2020 LTS will be the last version to contain Enlighten functionality for the built-in renderer, and it is fully removed in 2021.1.

    Projects authored with HD RP Preview Enlighten functionality will continue to be supported as it currently exists today (as-is, with no new platform support) in 2019 LTS, with full removal of Enlighten functionality from HD RP in 2020.1.

    Our Lighting team has been focused on making a robust solution to replace Enlighten Baking over the last year as well as provide great alternatives for the fast workflow possible with real-time Enlighten pathway through improved baking. The CPU Progressive Lightmapper is production-ready. Our GPU-based Progressive Lightmapper is used widely now with a great set of features and is targeted to be production-ready in the 2020.1 release. We’re continuing to add improvements, focusing on highly-iterative workflows, with every release. For example, in Unity 2019.1, we’ve added NVIDIA® OptiX™-based AI denoising, which gives you noise-free lightmaps up to 10x faster than before and many other features targeted for easier, more intuitive workflows and faster iteration for artists.

    In 2019.2, we’re adding Intel® Open Image Denoise, which makes this fast iteration functionality available on all Editor platforms for our users. We’re also adding sophisticated sampling methods to improve baking iteration speed such as multiple importance sampling from offline rendering which gives you clean bakes when using HDRI environments. We’re improving the control of lightmap layouts by letting you specify the number of lightmaps you want, and more convenient artist options. If there is any feature parity missing from Progressive Lightmapper in order for you to make the transition please give us feedback on our Global Illumination forum.

    Light Probe workflows will receive significant attention over the coming releases. Light Probes offer great quality of lighting and flexibility for authoring - they do not require UVs and they are fast to compute. We’re working on workflows to enable easier Light Probe placement with volumes and automatically place Light Probes for terrains. We are also adding support for streaming light probe data sets to make workflows better suited for streamed worlds and large team development.

    We are also fully committed to delivering a real-time GI replacement solution in 2021.1. The Unity team has a solid plan to solve this complex problem the right way, with great artists workflow and optimal runtime performance for 2021.1.

    We understand it is frustrating if you are affected by this. Deprecating features is not something we do lightly. This is not the outcome we wanted. We are committed to providing great workflows for authoring lighting, whether for baking or for real-time global illumination. Please join us over in the Global Illumination forum and discuss this with us, we are here to help you make the transition.
     
    Cynicat, transat, ROBYER1 and 10 others like this.
  2. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    5,747
    Silicon Studio asked for too much money?

    My sympathies to anyone that has a sizeable project that is built around Enlighten.
     
    id0, keeponshading, kristoof and 2 others like this.
  3. Jesper-Mortensen

    Jesper-Mortensen

    Unity Technologies

    Joined:
    Mar 15, 2013
    Posts:
    196
    Enlighten has had a good run for the money, some of the best looking titles have shipped using it. However, some of the underlying principles means that it is not a good fit moving forward.

    Enlighten is largely surface based, requires a global pre-computation phase and is limited to diffuse transport with no real support for physically based non-opaque materials. Some of the drivers moving forward are:
    • Fast iteration: Time-to-first-pixel needs to be fast, cannot have a lengthy pre-compute step.
    • Easy authoring: We need to remove the dependency on authoring suitable UVs and other surface based authoring.
    • Dynamic worlds: In addition to dynamic materials and lighting setup, we have to support dynamic geometry (eg. for procedural games).
    • Unified lighting: The lighting container needs to be decoupled from surfaces. This allows all scene elements to use the same lighting including volumetrics and participating media.
    • Large worlds: Due to the sheer size of levels today we need an easy way to to do localized light transport where what is lit and what is affecting that lighting is decoupled.
    • Source access: We need to have full access to all source in-house. So that we can independently drive development forward, fix bugs and support future platforms. This is arguably the most important point.
    For these reasons we have decided that the best course of action is to no longer pursue software we have limited control over and move on.

    That said the feature set that is available now will be supported until 2023 (via 2020 LTS), and we are happy to support you in the transition.
     
    Zarconis, Elecman, Cynicat and 15 others like this.
  4. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,334
    Hi @Jesper-Mortensen great news! But bad for us. We'd invested significant time into our HDRP title's lighting. It was last night actually, that I finally put the finishing touches to our enlighten realtime GI. This included automatic probe placement, automatic mesh setup and automatic mesh parameters.

    It was the end of a 3 year puzzle of on and off R&D where I wanted to automate the entire enlighten workflow and I didn't know Unity's plans.

    Pretty sure because of the above timings you mention, this issue really does affect us, in a poor way. So it's better to just remove what we are doing. It's sad but it is what it is and I will accept it on the chin without drama.

    I will ask if you'll ship a package for HDRP users like me? I just lost a ton of work - no fault of your own - my fault 100% because I didn't get any information back soon enough and failed to act soon enough.

    But anyway, will you be shipping a package replacement or similar (early experimental of course) for HDRP users using your new solution? I would love to be included if only because this really did hit our project in the glowing balls :/
     
    Alverik likes this.
  5. Jesper-Mortensen

    Jesper-Mortensen

    Unity Technologies

    Joined:
    Mar 15, 2013
    Posts:
    196
    So sorry to hear that! So just to reiterate the 2019.4 (LTS) will keep the current functionality (in HDRP), so if you are shipping before 2022 you should be ok.

    We are working away at a replacement and will share news as soon as we have something in a presentable state.

    May I ask what kind of platforms you are shipping your Enlighten projects on? And if you are using realtime GI in the game or just to accelerate authoring in the Editor?
     
    Alverik and hippocoder like this.
  6. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,334
    Realtime full open world game (third and first person) for ps4 and above (it's a minor exclusive before being ported to desktop/other consoles). Would really love to test for you if possible though. Really!

    It's using GI for realtime purposes not editor.
     
  7. konsic

    konsic

    Joined:
    Oct 19, 2015
    Posts:
    633
    Can I ask for realtime GI with no-bake required and which isn't based on raytracing?
     
  8. Jesper-Mortensen

    Jesper-Mortensen

    Unity Technologies

    Joined:
    Mar 15, 2013
    Posts:
    196
    When you say raytracing I will assume you mean "hardware raytracing" as in needing a GPU that supports hardware accelerated DXR (or Vulkan-RT)? Yes, we are exploring options for that too. But it is too early to tell if that is viable at scale.
     
  9. elbows

    elbows

    Joined:
    Nov 28, 2009
    Posts:
    2,226
    DDGI? I got wind of some Unity experiments with that in April via the rtpv branch of HDRP on github, but I knew I shouldnt make any assumptions about Unity plans from that alone.

    DDGI: https://morgan3d.github.io/articles/2019-04-01-ddgi/

    An example of a rtpv branch commit from April that tipped me off about DDGI: https://github.com/Unity-Technologi...mmit/e919caa6b2557583f8b60ce93b3b6fba34bf4dfd
     
    Vincent13122 and alia_0 like this.
  10. konsic

    konsic

    Joined:
    Oct 19, 2015
    Posts:
    633
    Does this require DXR library?
     
  11. neoshaman

    neoshaman

    Joined:
    Feb 11, 2011
    Posts:
    4,190
    DDGI solve the leaking problem of GI based lightprobe volume by adding a clever visibility data per probe. It doesn't solve raytracing per see. RTXN is just the way in which we update the DDGI proposed structure (in this case lightprobe volume), any other solution would work just fine too. And because of what property GI has (notably low frequency), updating that structure in realtime can be done in way that are good enough visually.

    So my guess is that unity is exploring way to use that insight and generalize it beyond the current DDGI.

    My only question, can this be backport to opengl es 2.0 level of harware, what about cheap and weak hardware?

    At that level updating the probe is the most costly operation, that is how do you sense the world around you.


    Here come some rambling :rolleyes:
     
    Last edited: Jun 21, 2019
    Vincent13122 likes this.
  12. OCASM

    OCASM

    Joined:
    Jan 12, 2011
    Posts:
    239
    On the contrary, please base it on ray tracing. Sure, today only NVIDIA supports hardware ray tracing but next year both consoles and desktop AMD cards will support it too so by 2021 it will be ubiquitous.

    Looking at the list of requirements @Jesper-Mortensen posted, ray tracing covers them all:

    Fast iteration: yes.
    Easy authoring: yes.
    Dynamic worlds: yes.
    Unified lighting: yes.
    Large worlds: yes.
    Source access: yes.

    Some may argue that voxels are a good alternative but due to being a fixed grid and having a max resolution they have issues with leaking, artifacts on curved surfaces and small objects not even taken into account. Working around them prevents fulfilling the "easy authoring" condition. RT on the other hand has no such issues.

    It's also a proven tech in an actual shipped game. Metro Exodus already supports both diffuse and specular GI in large worlds at 1080p @ 60fps (max settings). The game has it enabled only for the sunlight due adding the functionality late in the game and the artists not having the time to adjust the levels but the developers showed a couple of demos at the GDC demonstrating interior lighting and it's quite the leap in quality.

    Edit: here's a video from the presentation with one of the artists talking in favor of ray tracing:



    https://news.developer.nvidia.com/global-illumination-in-metro-exodus/

    Last but not least, Unity's main competitor already supports RT. It'd be a shame if Unity was left in the dust.
     
    Last edited: Jun 22, 2019
  13. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    5,747
    Feel free to delete if it's too off-topic, but... How is it your fault "100%"?

    When Enlighten was bought by Silicon Studio (or, they bought the development and licensing rights), people here (me included) asked what that means for the Unity integration.

    We got no reply (and that's fine, maybe there wasn't a reply to give at the time).

    Maybe you could argue the writing was on the wall and you should have seen it coming. And... Maybe. But for all we've known, Unity today could have announced a new partnership with Silicon Studios (and frankly, after the very recent Silicon Studio announcement about new updates etc I was even half expecting it would happen) and then retroactively, sticking with Enlighten would have been the correct choice.

    I appreciate your aversion to drama, and I agree it's definitely not the dev's fault, but the phrase "my fault 100%" reads like Stockholm syndrome talk.

    I argue that you could, or actually, should, feel at least mildly annoyed.

    I'm hoping Unity will release a preview of the new GI solution as soon as possible, if not publicly, at least to people that have built their games around Enlighten, so you can start prototyping you new lighting solution ASAP.

    I will not have any use for it for the foreseeable future, since I make smaller games and I really like high density lightmaps, but I know that having a significant part of your game be in limbo for reasons outside your control feels awful, so I'm hoping Unity comes up with something really fast. (or at least faster than it took the progressive lightmapper to reach production readiness :p )
     
  14. Rich_A

    Rich_A

    Joined:
    Nov 22, 2016
    Posts:
    151
    I'd be entirely fine with a DXR-capable GPU being a requirement to use HDRP as a developer for lighting.
     
    OCASM likes this.
  15. sqallpl

    sqallpl

    Joined:
    Oct 22, 2013
    Posts:
    214
    Great to hear that!

    Is this solution planned for all pipelines? HDRP, LRP and built in?

    From your post I assume that at this moment your plan is to release this in a production ready state in 2021.1. Are there any plans for releasing preview packages (like many other packages, including rendering pipelines) of this solution in the 2019 or 2020 cycles? I'm interested in packages for HDRP but I'm sure people who use other pipelines are curious too. I'm also sure that a lot of people would want to use this much earlier than it's in production ready state, even if it won't be perfectly optimized and just with the basic features and settings.

    Do you plan to release it as an external package or add this as a feature to the pipelines?
     
  16. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,334
    It's not Stockholm syndrome, it's Copenhagen syndrome... get it right!

    Joking aside, what I mean is that it is always the developer's fault because ultimately we do control the decisions we make. I did not expect Enlighten to get dumped for HDRP but sh** happens so I either have a clean break and get on with it or kick up a stink.

    If I could ask for something it would be a lot more transparency from Unity. I know it's bad practise to develop against semi-unknowns and I know that no answer = total unknown.

    So it's my fault, IMHO.
     
    Alverik, zombiegorilla and SugoiDev like this.
  17. keeponshading

    keeponshading

    Joined:
    Sep 6, 2018
    Posts:
    313
    Only some thoughts and workflow examples which are working great and use the power of long years of development and some great open source examples.

    I must go some steps back and trying to come back to realtime GI at the end because i think there i some other common missunderstanding what is really needed to get the results paired with a dangerous reinventing of the wheel.

    The following examples try to show that a realtime raytraced preview should be the beginnig of every workflow when it comes to lightmapping and extended lightprobes stuff up to realtime GI.

    Example 1) SubstanceDesigner

    Switch from raytraced iray to realtime visualisation empowerd by a perfect post processing yebis stack, author your materials. What you see is "pbr" perfect and what you get. Bake it down.

    Example 2) Blender Cycles and EEVEE

    Switch from
    Cycles raytraced Full feature GI

    Cycles.JPG
    to

    EEVEE realtime rendering. What you see it what you get in both world.
    Model, author your node based pbr disney material and bake it down.
    All under final post processing.


    EEvEE.JPG


    EEvEE_Probes.JPG

    model from katarn66:




    These two methods have in common,

    You can switch forward and backward from full featured raytraced GI to realtime rendering in seconds and bake down your stuff.
    Out of my experience you only can reach fast true photrealism this way. Fast physical based iterations.

    Why is using Substance Designer Iray and Yebis? Why did they not tried to develop their own solution?
    Simply because they know how much work an iray is.Same for Yebis. Both together around 20 years of development or more.

    Same with Blender Cycles. I think it comes close to this. Mass OpenSource development since 6+ years, great performance and platform independency. Now directly connected over perfect node based material concept with EEVEE.

    So i think there is something to learn and probably some chances to use this 2 exapmples and build on top of this.

    Another good example is Bakery who has no realtime preview yet but delievers an outstanding solution for lightmapping through divide and conquer.


    So where is the deal to map HDRP and LWRP Shaders, Env IBL, Procedural Sky to Blender Cycles and give realtime Visualisation in Viewport and when you are satisfied bake it down to textures , reflection probe,light probes, occlusion probes .and some nicer future stuff what could be the real unity core competency...

    You could use the massiv development power of an great open source tech you probably cannot develop with your lightmapping team the next 5+ years.
    On as many CPU and GPU nodes you want. Because it s free.

    Using similar approch to IRAY like Substance should be possible too.

    Simply skip your blackboxed lighting asset and connect a ScriptableBakePipeline with professionell solutions like above.
    You should be out of preview soon and you could concentrate on real workflow issues and generate outstanding realtime GI stuff of the perfect calculated rayrtraced FullGI precalculation which is solved.

    edit 25.07:
    fyi.some last weeks softfacts
    https://www.blender.org/press/epic-...r-foundation-with-1-2-million-epic-megagrant/
    https://www.blender.org/press/ubisoft-joins-blender-development-fund/

    edit 29.07
    Cycles got some OptiX RTX optimisation from NVidia today.

    https://code.blender.org/2019/07/accelerating-cycles-using-nvidia-rtx/

    Also OptiX Denoiser is now part of the Driver and now free for Open Source integration according to the GPL.
     
    Last edited: Jul 29, 2019
    gz7190, elias_t, larex39 and 2 others like this.
  18. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    5,747
    Eh, we do control the choices, but they're somehow less important when someone else controls the options we have. (plus, all options turn out to be more or less the same thing)

    At least that's what telltale games have taught me! :p
     
  19. konsic

    konsic

    Joined:
    Oct 19, 2015
    Posts:
    633
  20. keeponshading

    keeponshading

    Joined:
    Sep 6, 2018
    Posts:
    313
    You could also rebuild and sell different perpetuum mobile constructions you find on youtube on paetron.
     
  21. neoshaman

    neoshaman

    Joined:
    Feb 11, 2011
    Posts:
    4,190
    That's screen space, diffuse only, with no out of screen captures and no material response. It assume color brightness on teh screen is light, so it's only an approximation.

    I think the goal is online (in game) GI not just baking stuff. Also they need internal solution to have continuity with their state of the art shading research.

    <speculation>
    I have been thinking about how they could achieve their result since they laid down their constraint (no LM!, vast dynamic world!, no dedicated harware?). I was wondering if a volume solution as caching (lppv) + local BVH (linear morton bvh) + farfield cubemap light buffer? Basically the weak spot of GPU RTGI is the update (raytracing the scene) BVH have random access which don't help the nature of gpu architecture to cope

    One way is to go compute and have cheap local operation, but bvh are global and shared. So the solution is to fit a BVH in a way that would fit the gpu, ie local and less random. Turns out that a similar problem was posed with voxel, and Samuli laine proposed a stackless octree traversal with a gpu friendly layout, storing octree adress per point in a bitfield. I wonder if unity did the same with teh BVH? I read during my research about linear BVH using morton encoding, they are less efficient that top down construction but suitable for RT construction.

    I was thinking that if you reduce the scope of the BVH, it would be faster to compute and to build, make it accessible to dynamic world. Also since we are using LPPV we can cache and async teh update like in DDGI, and we don't need the visibility texture as the bvh already does it (probably faster to cache it with bvh update too)?

    Another idea is to use a cubemap buffer for far field, that's an Idea I had to use for my (environment only) GI test (still pending) because I have limited texture size and precision (diffuse only, no mat, low "rays"), I found that rendering the farfield into a "global far field cubemap" help communicating with different LMGI unit. Since we need less precision we could raytrace against that map and keep teh bvh update tick rate fast around the view.

    That would probably work on any hardware with compute ability.

    I can't do any of this anyway :p
    </speculation>


    EDIT: another random idea on the spot
    LPPV seems costly now I know the plenoptic fonction do away with the Z in convex space (even in some non convex case), we could probably have just an array of cubemap as it's an empty 3d array and we still can fill the interior by rewriting the mipmap anyway, and it's cheap to adress.

    There is probably another support structure formulation to find, for example (random idea) a coarse 3d index array , so you can hash cheaply the position and then it contain index of closest "cubemap face tile" so we can have concave space mapping and avoid spending the full resolution for duplicate faces across neighbor cubemap, and each face also have a depth buffer so they can place the probe (sh pixel) closer to structure, which also mean we can use the distance to sample the mip and get a "cone sampling" for cheap. Probably can do away with the 3d index texture and just use trigger boxes? Also that would be a way to do away with LM and just have an array of faces? But then How do I reliably sample the hemisphere of each point, since I have now many indirection (the box probably connect to neighbor box, so we need to search through them, which is problematic).
     
    Last edited: Jun 25, 2019
  22. OCASM

    OCASM

    Joined:
    Jan 12, 2011
    Posts:
    239
    It should be exclusive to the HDRP so it's well optimized and not held back by the limitations of the LDRP. That's the point of having different pipelines in the first place. For the LDRP they could have a different, cheaper technique like LPVs.
     
    Lex4art, Rich_A and joshcamas like this.
  23. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    736
    Or maybe having it modular so different features could require different features in the render pipeline to be implemented? Then HDRP could have the fancy bois
     
    neoshaman likes this.
  24. OCASM

    OCASM

    Joined:
    Jan 12, 2011
    Posts:
    239
    It depends on the level of integration required to achieve the best performance and quality. Surface level effects can be implemented in both pipelines relatively easily but stuff that taps into the innards of the pipelines can't. Unity would have to build and optimize two different versions of the effect and that's assuming the LDRP is even compatible with it. It's better to use different techniques tailored and optimized for each pipeline. High-end stuff for the HDRP, medium-low end stuff for the LDRP.
     
    joshcamas likes this.
  25. id0

    id0

    Joined:
    Nov 23, 2012
    Posts:
    287
    Well thank you very much! I still remember how just a couple of years ago you were promoting it as a new word! blah blah blah, it's exiting! blah blah blah. And as soon as everyone got used to it, well, let's remove it!
     
  26. Jesper-Mortensen

    Jesper-Mortensen

    Unity Technologies

    Joined:
    Mar 15, 2013
    Posts:
    196
    We introduced Enlighten in 2015 and are retiring it in 2023. It's had a good run but its a different time now.

    So to answer questions about DXR. We are investing in DXR (and Vulkan RT) going forward. This of course is not limited to realtime reflections, AO and shadows, but will also include other GI effects. It is early days and we are still working on laying the foundation in order to support this well.

    We also need to support all the platforms out there that do not have hardware ray tracing available. So we will be improving the current pipelines we have and extend them beyond lightmaps. We have been working on extending the usability of light probes and will continue doing so going forward, they are flexible, stream well and do not require specific authoring like UVs. They also span a large set of platforms, in the continuum between baked light probes and realtime updated light probes.

    To address HDRP and LWRP support we are going to integrate the features that make sense for the pipeline in question. Some features require hardware capabilities not available in LWRP so those will have to remain HDRP only. Also, the pipelines are quite different in nature so to integrate efficiently we need to do it separately for each pipeline in order to achieve optimum performance. Both HDRP and LWRP are super important to us so we are striving to develop a rounded set of features that play well with the use cases of each pipeline.
     
  27. keeponshading

    keeponshading

    Joined:
    Sep 6, 2018
    Posts:
    313
    But how you solve the Full Featured Global Illumination equation to feed your different needs?

    Unreal VRAY,
    Unity Octane,
    Substance Iray
    could do this, but are closed source and have strange pricing per node. Should end similar to Enlighten and are probably good choices for industrial use.

    Your own development? Really don t see the ressources at Unity at the moment. More important. Unity needs an workable best in class solution soon. Any "solver" above needed lots of dev power.

    Blender Cycles Standalone is free, unlimited scalable and
    have a look on Bocs Shot and Bocs Lightmapper in Unity forums. A one man show who shows how easy it is to solve this equation on open source base.

    Then feed calculation results to your different needs.

    furthermore
    It could calculate LightMaps for Built In RP, HDRP and LWRP in some minutes. Gives you everything to feed lightprobes and reflection probes or base stuff for realtime GI.
    It can bake you Bent Normal Maps, Transmission and Translucent Maps or other advanced SSS stuff for HDRP.
    It can bake you every FullGI pass combination out. It can bake you every PBR texture combination out.....
    It gives you direct realtime preview of an full featured GI calculation in seconds with optix enabled and it is out of preview since around 5 years.


    Would be nice to hear what your thoughts about that.
     
    Last edited: Jul 1, 2019
  28. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    5,747
    The progressive lightmapper?
     
  29. keeponshading

    keeponshading

    Joined:
    Sep 6, 2018
    Posts:
    313
    The Progressive is a small subset of the solutions described above.
    Progessive L is in development since 2016. See video.

    and his current status is far far behind something you can use in production e.g. when compared to a one man s solution called Bakery.

    Think it became really dangerous for Unity to further trying reinventing this wheel whith current ressources and knowledge mostly because requirements on baking has changed.
    What happened in 3 years of development?
    I try with a lot of effort to use it but after some time you go back to Bakery or I bake in Blender in combination with Enlighten.

    Meantime. 2019. Without Bakery there would be the only way to leave Unity.
    But the problem with bigger processes is to trust in an solution developed by one person.
    So Bakery is a piece of art and without i think many peoples had left unity during the the last year.

    Meantime we have something like a Unity Bake Gate.

    Now comes the Enlighten deprecation. A solution who worked will be replaced by an ?.

    So i only tried to show some logical alternatives.

    Unity is in hard competiton these days. The SRP in special HDRP is a big step forward but to fully land the efforts made they must be an fast working solution for baking too.
     
    Last edited: Jul 1, 2019
  30. Mauri

    Mauri

    Joined:
    Dec 9, 2010
    Posts:
    1,490
    I'd rather have a solution done by Unity than relying on just another third-party asset (which might get deprecated at some point - see what happened to SEGI).
    Bakery looks cool, but it also has its flaws. For instance, it doesn't support AMD GPUs for baking.
     
  31. Jesper-Mortensen

    Jesper-Mortensen

    Unity Technologies

    Joined:
    Mar 15, 2013
    Posts:
    196
    We are developing in-house solutions in order to maintain full control. That way we don't have to deprecate anything going forward. Also, we can easily add support for new light types in HDRP for example and adapt to Unity as it is changing.

    Progressive Lightmapper (CPU) is out of preview. GPU support is out of preview next year, it is currently (19.2) faster than any other baker we've tried (see this technical blog). We've added support for Optix denoising, and Intel Open Image Denoise. More is happening on the denoising front. Our solutions work on all platforms and are agnostic to GPU vendor.
     
  32. keeponshading

    keeponshading

    Joined:
    Sep 6, 2018
    Posts:
    313
    That sounds great and i hope you see the need and the chance to open current solution more for custom implementations like you did with SRP and SBuildP.

    Giving full access to all Lightmaps and Realtime GI parameters via Shadergraph would be an amazing start in SRP's.
    I even think a SBakeP is really needed.
     
    OCASM likes this.
  33. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,334
    Well good luck with it then. Probes have sucked forever for all but the most basic things so it'll be nice to have probes not pee light through 1m thick walls.
     
  34. keeponshading

    keeponshading

    Joined:
    Sep 6, 2018
    Posts:
    313
    A time of day variant of the main fps sample level would be a nice test scenario.
     
  35. Jesper-Mortensen

    Jesper-Mortensen

    Unity Technologies

    Joined:
    Mar 15, 2013
    Posts:
    196
    Indeed one of the things we are looking into as a requirement for using probes more extensively.
     
  36. sqallpl

    sqallpl

    Joined:
    Oct 22, 2013
    Posts:
    214
    @Jesper-Mortensen
    Do you plan to start releasing HDRP realtime GI solutions in a preview state in 2019 and 2020 HDRP releases?
     
    Last edited: Jul 3, 2019
  37. Jesper-Mortensen

    Jesper-Mortensen

    Unity Technologies

    Joined:
    Mar 15, 2013
    Posts:
    196
    As soon as we have something ready for external testing we will get back to you.
     
  38. elbows

    elbows

    Joined:
    Nov 28, 2009
    Posts:
    2,226
    How come they seem to be killing it in 2019.3 version of HDRP?

    eg:

    https://github.com/Unity-Technologi...mmit/460569620f729ed84e5d19854fccb44374c92711

    Apologies if I got the wrong end of the stick about this.
     
    hippocoder likes this.
  39. jRocket

    jRocket

    Joined:
    Jul 12, 2012
    Posts:
    479
    I've never cared much for Enlighten, especially the lightmapper which was a big step back from Beast- so I am not sad to see it go. The most exiting part of this announcement is the automatic light probe placement.
     
    Thomas-Pasieka likes this.
  40. jjejj87

    jjejj87

    Joined:
    Feb 2, 2013
    Posts:
    265
    Jesper, no offense, but quoting this from your post

    We are also fully committed to delivering a real-time GI replacement solution in 2021.1. The Unity team has a solid plan to solve this complex problem the right way, with great artists workflow and optimal runtime performance for 2021.1.

    If you actually have a plan, please share it with us so that we can work around it. All things aside, we really need to be able to plan our project timeline and workload.

    Also, when you said 2021.1, did you mean
    • first public preview version will be released by 2021.1 and thus requiring another year for it to be production ready? or
    • an actual full release of GI replacement that is ready for production?
    I ask because the two are very different.

    Thanks in advance.
     
  41. francois85

    francois85

    Joined:
    Aug 11, 2015
    Posts:
    564
    Can we get a table showing Unity versions and what is feature are available.
     
  42. AFrisby

    AFrisby

    Joined:
    Apr 14, 2010
    Posts:
    212
    To be honest, I've never been a huge fan of Enlighten; it's slow and produces monstrously huge data files that need to be rebuilt regularly, and was initially a monumental step down from Beast (still is today IMO) - so I'm not particularly sad about this.

    I would ask for a few things in the future replacement however;
    1. Data stability. Conventional lightmaps can be re-used between Unity versions without a rebake cycle (lightmaps we baked in the Beast days theoretically with a little C# mangling to remap the UV coordinates can be imported into 2018/2019.) Rebakes are not fun, and often change the output with version changes.
    2. Runtime Editing. Some capacity for run-time alteration or ideally, generation. At minimum, please expose the underlying data structures to script, so we can integrate our own methods of this.
    3. Good device support. This is going to be incompatible with DXR for the time being, but at least baked lightmaps are fast/quick/cheap, and will run on a toaster. DXR looks fantastic, but isn't going to be everywhere for 5-10 years.
    Thanks!
     
  43. Adam-Bailey

    Adam-Bailey

    Joined:
    Feb 17, 2015
    Posts:
    229
    Yeah, given that the current real-time GI runs on mobile devices and the like it would be nice to know if that isn't going to be the case going forward.
     
  44. Jesper-Mortensen

    Jesper-Mortensen

    Unity Technologies

    Joined:
    Mar 15, 2013
    Posts:
    196
    It's staying in 2019.4 LTS for HDRP and 2020.4 LTS for built-in. For HDRP we are hiding it for new projects (in 2019.3) and enabling it only when upgrading a project to steer folks away from starting new projects using Enlighten.
     
    elbows likes this.
  45. keeponshading

    keeponshading

    Joined:
    Sep 6, 2018
    Posts:
    313
    Only to show how serious you should take the situation.

    This week i received two messages. What would you do in case you need realtime GI for your upcoming or current projekts.

    Unity ( see first post in this thread)

    ....
    "Unity will continue support for Enlighten in the built-in renderer as it currently exists today (as-is, with no new platform support). The 2020 LTS will be the last version to contain Enlighten functionality for the built-in renderer, and it is fully removed in 2021.1.

    Projects authored with HD RP Preview Enlighten functionality will continue to be supported as it currently exists today (as-is, with no new platform support) in 2019 LTS, with full removal of Enlighten functionality from HD RP in 2020.1.
    ......
    We are also fully committed to delivering a real-time GI replacement solution in 2021.1. The Unity team has a solid plan to solve this complex problem the right way, with great artists workflow and optimal runtime performance for 2021.1.
    .....


    Unreal

    To our valued customers,

    We have released the latest version of Enlighten global illumination for UE4.
    This release is a major step forward for Enlighten and the next to last step leading up to the big 3.10 SDK update.
    There are a number of major developments in this version you can read about below.

    If you are interested in evaluating this updated UE4 version or learning more about Enlighten and the upcoming SDK update, please feel free to contact us via the inquiry form on the Enlighten website or to the team directly.

    Enlighten 3.09, Unreal Engine version 4.22 release

    Modern engines like Unreal Engine are now transitioning away from traditional inefficient methods of drawing meshes on the CPU. This addresses a major bottleneck which has long caused headaches for teams who work with massive worlds. Moving mesh drawing closer to the GPU also opens up many exciting options including real-time ray-tracing.

    Unreal Engine 4.22 brings a number of exciting major features, such as support for real-time ray-tracing and mesh drawing optimizations. In particular the new Mesh Drawing Pipeline now enables draw call merging. The engine can now automatically identify mesh draw calls that are identical and merge them into a single draw call.

    Because Enlighten is deeply integrated within the Unreal Engine renderer we had to carefully re-design some key areas of the implementation. While this was a significant undertaking, it provided an opportunity to revisit and update Enlighten rendering code to take full advantage of recent Unreal Engine renderer improvements. Enlighten for UE4 now fully supports the new mesh drawing pipeline to enable efficient draw call merging in combination with Enlighten indirect lighting.

    These changes also lay the groundwork for use of Enlighten in combination with real-time ray-tracing in Unreal Engine. The changes to support draw call merging are a key building block for making Enlighten lighting data available to ray-tracing shaders. This brings us a step closer to our vision for the combination of high accuracy real-time ray-traced effects with Enlighten global illumination. We will be presenting more about this combination in the future as our research progresses.

    The Enlighten team

    So. No. I think it is not enough trying to deliver a replacement for 2021.1. and support Enlighten as it today, 2019.
     
    jjejj87 likes this.
  46. Jesper-Mortensen

    Jesper-Mortensen

    Unity Technologies

    Joined:
    Mar 15, 2013
    Posts:
    196
    We are looking towards solutions that can support a wider variety of GI than a partially prebaked solution can. Our aim is to also support large worlds, procedurally generated worlds and destruction.
     
  47. Vincent13122

    Vincent13122

    Joined:
    Oct 26, 2014
    Posts:
    36
    Sounds great! My game has a lot of dynamic lights, instantiated big moving objects, characters and lots of clutter which would be impossible with baked realtime gi, so I'm really looking forward to this!
     
  48. fherbst

    fherbst

    Joined:
    Jun 24, 2012
    Posts:
    206
    While not really using Enlighten much these days, I was wondering about the first sentence ("Due to Geomerics shutting down Enlighten as a product, Unity is required to remove Enlighten.") since other companies are heavily using it.

    Any comments on this? (from the comments section here https://www.gamefromscratch.com/post/2019/07/03/Unity-Removing-Enlighten-Support.aspx)

    Michael Joseph Prefontaine • 7 hours ago
    I am the Global lead at Silicon Studio and the biz side PM of the Enlighten team. I can provide more information from our side.
    When we initially purchased Enlighten in 2017 we approached Unity to provide support, but were told bluntly they had zero interest and had already invested in developing solutions to replace Enlighten as soon as possible.
    Geomerics is indeed shutting down all operation. However Enlighten is not at all dead. A large amount of the technical issues stated in the forum are also due to Unity owning an older version of the SDK, as many of those issues have been not only solved but surpassed.
    We are currently developing a large range of updates including next gen consoles, which we are very far along with, and STADIA, which we were announced as a partner publicly at GDC 2019 in the Google presentation. We are also working on ray-tracing technology and a number of other SDK updates with new features. We will be releasing the 3.10 SDK update this summer.
    We were equally shocked and have officially asked for a retraction.
    You may contact me for further info.
     
    joshcamas and OCASM like this.
  49. elbows

    elbows

    Joined:
    Nov 28, 2009
    Posts:
    2,226
    Ah yes I was just about to post about that, having just found it myself.

    I actually support Unitys decision to move away from Enlighten, but I never support misleading public comments or lengthy gaps between internal decisions that affect us being made, and us actually getting to hear about it.

    I'm not impressed!
     
  50. neoshaman

    neoshaman

    Joined:
    Feb 11, 2011
    Posts:
    4,190
    I mean people had been complaining for years about enlighten, it's proof they are listening to what we complain about.

    There is enough breakthrough recently for RTGI (hat's how I got a bit carried early oups lol.) that unity could/should handle their own anyway. T


    :D It's just that they will still leave me alone in the dust lol, my market is choke full of cheap ogles 2.0 gpu (and some cheap weak 3.0) :( I don't think they will cover that anymore.