Lighting Survey - seeking your feedback.

a) Only Precomputed Realtime GI - but never for a commercial project
b) Architectural presentations
c) The realtime-baking process simply takes too long:
When there´s a slight change in the geometry it´s not possible to rebake per object but the whole scene has to be baked again. This kills economic workflows.

And I´m missing baking parameters per object: Setting up different lightmap parameter sets to solve this is cumbersome.

And another feature I´m missing:
Let objects influence others but not getting baked (for speeding up the baking process and minimizing lighting data):
Imagine a box on a plane: The box should influence the plane, but not get baked.
In VRay there are two GI-toggles per object:
- Generate GI
- Recieve GI
It´s that simple.

 

a) we don't use Precomputed Realtime GI at all.
b) mobile games
c) We hate the new lighting!

We have major issues since the new lighting was introduced. I know that it is nice and makes possible to produce this beautiful tech demos but there is no practical use for them and we fell that the mobile games are not ready for it. We have a popular game Sky Force that was build on the old Beast lightmapping system. If you making a mobile game all you want is beautiful baked shadows and some light. After 5.x our workflow collapsed. We are doing a sequel to the game using 5.x and we are unable to reproduce the quality of lighting that we have had before. Moreover, soon we will be unable to update the old game as 4.x is getting dead and we are unable to produce anything that would look like the original game when upgrading the project to 5.x. Please add third checker for the Lighting menu "Good Old Beast Lightmaps".

 

a) I picked I use both. The idea is that static lights with Final Gather would be much higher quality and have much denser GI, so that it looks nice and detailed, then use a few realtime lights on top for the dynamic lights. To have the best of both worlds -> Great looking GI and some realtime GI.

b) Console/mobile.

"Both" has the potential to be great. Having best of both worlds. Great quality for some lights, impressive realtime for other (maybe really low res to get better performance and faster updates). Realtime simply cannot have a high enough resolution to get nice indirect shadows and contact shadows and penumbras. Things that should be possible with baked. If enlighten wasn't terrible. Which it is.

So whatever.

 

a) Both!
b) An array of interactive experiences (for museums, expo's etc) for PC's and tablets, most recently a VR demo.

The most recent project, the VR demo, had to run on a pretty medium PC (GTX 660), making deferred lighting too performance heavy to use in VR. The entire scene was indoors though, requiring many point lights, which obviously can't run in real time in forward either - so baking is the only good option here. The user also had a head mounted spotlight however, so real time precomputed GI added a nice extra bit of polish on top.

Also, even if I could have run the entire thing in real time using deferred lighting, having both baked lighting and good real time lighting working in unison is still very advantageous. Unreal is the prime example of this.

About your point of both systems creating UX confusion though - they definitely do. It starts with the fact that "precomputed realtime" is an oxymoron, which, while correct, only adds to the initial confusion. It's also not easy to find a proper getting started guide that fully explains what both options do and how to use them correctly, how to reduce bake times, what rendering path to choose, etc.

 

Last project was using enlighten but I have stopped doing commercial Unity work and have started a hobby project in 4.6.2

Its totally confusing trying to prelight in Unity 5, and only doing opposite to the community advice do I get any baking whatsoever. I started a precomputed GI bake though for my grandchildren to finish the project (I have no children yet)


Really just dumbing it down tutorial wise and creating start to finish examples of each different setup is whats required, because it seems like there are strong capabilities in different directions, although not mature and complete, rather than just 'Bake and Go'.

Also videos explaining whats not working would be ideal because its incredibly frustrating trying to use these features and finding they just don't work when you approach it "The old way" or logically.

Also the problem of tutorials becoming dated is a bit of an issue. Its like we need one place to go where dated tutorials get updated, and we can find reliable current material to learn stuff like enlighten that is not intuitive.

Also I managed a big(ish) full project, and maybe people don't hit these issues unless they are power users/ doing full sized project stuff. I find when you use features extensively and hit all the bugs, thats when Unity5 does your head in.

Thanks for keeping the journey at your end going, Will!

 

Thank you for giving us this opportunity,

a) We use only baked GI (Precomputed dropped FPS)
b) Mobile platform
c) Win 64bit seems to never crash when baking big scenes whereas in 32bit our Unity would always crash at some point .When doing baking start with lowest setting and gradually increase those numbers,it helps to compute lightmap fast.

We did tried Precomputed GI for realtime shadows for day night cycle,but unfortunately the FPS dropped to 8 whereas with Baked GI we get constant 40FPS on mobile devices.

I would also like to highlight this feature which went missing in Unity 5, Having built in prefabbed lightmap like it used to be in Unity 4 would be insta classic as many of developers routing for procedural environment.

 

a) I voted yes because we'd like to use both but currently we can't because mixed lighting is broken in 5.3 (realtime shadows do not work properly when both Precomputed Realtime GI and Baked GI are enabled).

b) Medical simulation for high end VR (PC, Oculus and Vive).

c) We currently use Precomputed Realtime GI only because mixed lighting is broken but I'll explain below why we'd like to use both.

One important use case is that for reasons that aren't entirely clear to me, Ambient Occlusion baking appears to be tied to Baked GI. We are trying to light an indoor scene so we have no skylight, primary lighting is from emissive panels on the ceiling and placed spot lights over the operating table. Baked ambient occlusion is really helpful to make objects in the scene that are not directly lit by the spotlights and are getting their lighting from the emissive panels, enlighten bounced GI, light probes and reflection probes look 'grounded'. We're currently using a bit of a hack and using a 'fake' directional light casting dynamic shadows to get the grounding for these static objects but we'd rather not have to pay that cost if we could just use baked ambient occlusion or baked shadows.

Performance is very important for VR but we are also going for high end visuals in our product. For static background / scenery objects, fully baked GI and shadows would be a nice option to have. It's not as needed for us right now as baked ambient occlusion but it would be nice to be able to use Precomputed Realtime GI in select areas where we want to be able to dynamically adjust lighting and still get bounced lighting and static Baked GI in the background where the lighting can be fixed. Technically the lighting won't quite be 'right' but I believe we could set up our scenes in a way that the effect of bounced Realtime GI would drop off before we switched to Baked GI and get a good visual result without paying the full expense.

Really the issue comes down to ambient occlusion / shadows on static objects. For our scenes, fully static lights are ok but we'd certainly like to be able to adjust light color / intensity at runtime if the cost is not prohibitive (e.g. turning lights off and on, having animated emissive screens / displays). If it's a choice between GI (bounce lighting) and dynamic lights we'll pick GI though. The promise of Enlighten is that you can get both. We don't really need to be able to move lights in our scenes so for static objects (most of the environment and background elements in our scenes) we don't really want to pay the cost of dynamic / runtime shadows. Given our lighting (area lights etc.) we also want pretty soft shadows so baked shadows are often visually preferable to dynamic.

If I was designing a custom lighting system for our use case, I'd probably want something like enlighten with multiple additional baked shadow / occlusion maps for static objects. Ideally I'd be able to do things like assign a channel in a baked shadow map to a group of lights (e.g. all our ceiling panel lights) at a much higher resolution than the maps for the Precomputed Realtime GI and at runtime have enlighten combine that (static, because light positions are fixed) with the Realtime GI information so I could get nice baked shadows / occlusions for static objects while still being able to adjust light color / intensity at runtime. I might have two or three of these baked shadow / occlusion maps in a scene associated with different groups of lights (ceiling panels, overhead spotlights, maybe a window or wall display). Dynamic objects would still need dynamic shadows and light probes but we have relatively few, relatively small fully dynamic objects.

 

a) Only Baked GI
b) Mobile games
c) Can't get the results we got in Beast. Artist are really disappointed. You Unity guys already know that is worst than Beast for baking.

 

"Yes, I / we use both for.. reasons I promise to post in reply!"

Reasons?

I am making a game where I want (the performance of) shadows to be baked into static meshes... Like the ground and trees. However I want dynamic shadows on my few dynamic game objects. I want the world to be shadowed at all distances and I want the (performance of the) sunlight's dynamic shadow when not extended to infinity.

Isn't this the whole point of using both systems together? This is what I want to use it for however the system appears to be quite broken

Are you guys gonna fix it? I kinda need to change course if you don't intend on fixing it. Obviously it impacts my project (visualy and asset creation wise) in a huge way.

Oh, and It's for Oculus, Vive, and PSVR.

 

""a) Only Precomputed Realtime GI - but never for a commercial project
b) Architectural presentations
c) The realtime-baking process simply takes too long:
When there´s a slight change in the geometry it´s not possible to rebake per object but the whole scene has to be baked again. This kills economic workflows.

And I´m missing baking parameters per object: Setting up different lightmap parameter sets to solve this is cumbersome.



this.!

 

Small moonlighting indie developer working on several projects. Unity Pro license.

Mixed Baked GI + Precomputed Realtime GI:

For WebGL machinima with interactive elements (think shorter but better animated visual novels). I want scenery to look the best it possibly can. I use baked lighting with hand-optimized lightmap UVs for the static meshes and realtime GI so I can have cool lighting, like carrying a glowing gem out of a cave, blue/red police lights through windows, fireplace being lit, etc. - I could probably fake a lot of the radiosity with additional lights since my scenes are scripted, but actual GI with shadows is nicer

Things look pretty bad currently (5.4 b10) - both dynamically lit and baked objects suddenly go bright then normal again depending on camera angle, dynamic shadows don't fit in with baked shadows at any strength setting, dynamic objects don't receive shadows from other dynamic objects and and and...​

Precomputed Realtime GI only:

For an action adventure game involving several cave systems and surface areas and sunlight changes depending on the time of day. Can't use baked lighting because of that and because I'm aiming at a 100-200 MiB download, not 8 GiB.

This is working well so far.​

 

a) I use neither. Honest. That doesn't mean I don't want to though.
b) I create asset store content both on the low and very high end. The high end one is my current project.
c) All dynamic deferred lighting. I create fake fill and bounce with point lights. Good reliance on reflection probes, SSAO, and good PBR materials.

Both GI bakes are slow, and the fact that I have to go through a longer-than-acceptable lightmap load/rebake on scenes opening in the editor seals the deal for me. With regard to bake time, sure, you can get a more iterative process by dropping the parameters low, but you'll end up with something too different at higher detail levels.

 

a) I am using both of them.
b) I am making a PC project 3rd person RPG
c) well, i use a lot of 3D and scripts from asset store. Some assets are created for unity 4 and without any regards to Enlighten requirements. I've no idea if this is an issue, I suspect it does impact the process of baking. But my greatest problem is an outdoor environment where I hit a wall with the lightmapping, Last attempt took more than 24 hours and I killed it because of errors. One will think a i7 4GHz and 32GB of memory will suffice for such task, but just today I've tried a small cave environment and it took hours to complete. Learning the baking process by doing is a no deal and the resources of learning are very scarce on the net.

 

a)We actually use all 3 versions depending on what we are doing. )Precomputed only, Baked GI only, Mixed)
b) Specifically for Mixed - Tends to be for visuals and fly throughs. Sometimes we are creating high fidelity shots or renders. We create alot of "training apps" and are actually trying to move the rendering pipeline into unity so that real time and renders match. (looking forward to the sequencer)
c) The main reason is that lum polys sometimes give unaccurate rendering (for example a strip light along a piece of furniture) In these cases we are forced to use Area lights to get a clean bake as precomputed GI doesn't give the results we are looking for w emissive polys. Emmsive polys just don't always give the results needed and can be inaccurate. Cranking up the res of precomputed just makes it noisey. If we had "good" real time area lights we probably wouldn't have to use mixed in this case.

Baked GI is used for web gl and mobile. Precomputed is for renders (with mixed Bake GI). I also tend to use Precomputed just for initial lighting pass to quickly get a feel for the scene.

 

Mixed lighting has been broken ever since the release of 5.0. I use realtime lighting in areas with terrains and trees, as speedtrees cannot be lightmapped. I try and bake lightmaps on architecture, but final gather always causes an out of memory error (I have 32gb of ram) and baking without final gather is full of errors. For PC/console

 

a) real time GI only
b) abstract/futuristic racing game, PC/Console
c) ...

we started out using baked lightmaps, because this was what we used in the past and we though we didn't need the "real time" part and thus never gave it much attention. We pretty quickly though ran into the known issues with lightmaps, that baked and realtime mixed lights don't work as well as the common sampling problems and finding the right lightmap resolutions.

Looking for alternatives, we tried real time GI with great success. The information that was missing for us, was that it is a radiosity based solution, which has many advantages in our case. The real time aspect is completely irrelevant for us (besides being able to tweak it in the editor), and I guess it is for most people.

 

a) Precomputed Realtime GI
b) Archviz for desktop and VR, high end hardware
c) Never went back to Baked after introduction of Realtime, great use in this kind of applications: interactive colors and roughness values of materials, time of day and light's intensity. Generally pretty satisfied with implementation, runtime costs and light distribution when used correctly, besides one bug that I still encounter: 807565 (attached picture, visible on ceiling)

 

I'd love to use either of them, but the Enlighten system is very broken.
We do very complex Arch Viz scenes, lots of polys, 10 to 15 million on average.
I have yet to get a bake to work. It's just stalls and there are no reasons why it stalls.
For anything but simple scenes it's useless.
If Unity 5+ gave feedback as to why the bake has stalled, it meant we could actually use it...maybe.
As it is, it's useless and broken for us.

 

a) I would LIKE to use both mostly because I want to bake AO into the level to avoid expensive SSAO, but use realtime precomputed gi and realtime shadows. Currently I don't because, well, it doesn't work well.

b) a small ish open world game for PS4

c) nothing much other than I'd like scenario a to work, but if it doesn't, I'll figure out a way to bake AO into verts anyway. Not the end of the world. Probably better for perf anyway.

 

I finally got Real time GI to work by going in and manually adjusting all the building objects in our scene, it took all night, but hey, it finally worked. I had to set the light map scale for each object by hand until the "object size in atlas has reached is max" no longer shows.
This enlighten workflow is a Cluster F&*k of gigantic proportions for complex scenes.
I saved and reopened our Unity file (had to bake up you know) and now the Rel Time GI info has gona away and I have to reset a whole bunch of date.
I am a little Pi#*ed to say the least.
Enlighten is garbage until you get the many many many bugs fixed.

 

This is something to consider for Enlighten.
Real documentation and error reporting. I had to go though dozens of error reports to get a way of trouble shooting
the issues I had for why things weren't working or stalling.
This work flows needs more user feedback for possible issues so the user can go in and make adjustments to keep things moving.

 

I know, but it's what we have to deal with in our industry (Not games)
We have very powerful machines and videos cards to compensate.
Not ideal, but not traditional gaming either.

 

Follow up. SOOO. Elighten is working out a little better for us now that I go in and set the lightmap scale for all objects, using the error message as a guide to how large. Set each object lower until the error goes away.
It's not ideal but it works. The Enlighten tools are still crap IMHO, but at least we are getting results now.

 

After upgrading to 5.4.1, my baking problems solved. and for more test i switch back to unity 5.3.4. and it crashed again during bake.