Official Enlighten deprecation and replacement solution

Silicon Studio asked for too much money?

My sympathies to anyone that has a sizeable project that is built around Enlighten.

 

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 :/

 

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.

 

Can I ask for realtime GI with no-bake required and which isn't based on raytracing?

 

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

 

Does this require DXR library?

 

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

 

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.

 

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 )

 

I'd be entirely fine with a DXR-capable GPU being a requirement to use HDRP as a developer for lighting.

 

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?

 

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.

 

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


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.







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.

 

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!

 

https://reshade.me/forum/shader-discussion/5450-ray-tracing-with-reshade-unofficial-guide

Raytraced GI shader which works in dx9 and dx11. It can run on AMD and Nvida card as well.

 

You could also rebuild and sell different perpetuum mobile constructions you find on youtube on paetron.

 

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
</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).

 

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.

 

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

 

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.

 

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!

 

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.

 

The progressive lightmapper?

 

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.

 

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.

 

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.

 

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.

 

A time of day variant of the main fps sample level would be a nice test scenario.

 

@Jesper-Mortensen

Do you plan to start releasing HDRP realtime GI solutions in a preview state in 2019 and 2020 HDRP releases?

 

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.

 

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.

 

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.

 

Can we get a table showing Unity versions and what is feature are available.

 

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!

 

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.

 

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.

 

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!

 

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.​

 

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!

 

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


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.