Enlighten In Unity 5 :/
polycounter lvl 9
Very unimpressed so far and thought it'd be worth getting a post up to find out other peoples experiences are. It's a real shame because Enlighten seems great as a real time solution and it looks great in frostbite.
But right now as a baking solution in Unity its very very broken - This is a massive issue for the Unity guys because most people that are using unity are making Mobile games and have no chance of getting games working with real time lighting! We really heavily one the quality of our light bakes to boost the quality of the look of the art work - its a big kick in the teeth when are are unable to produce the quality we saw with Beast in Unity 4.
Guess I'm just curious about how others are finding it, what issues they have and what they are currently doing to work around them. We have now moved onto serious discussions about how we could do our light bakes in Modo or how we can try to hack beast back into Unity 5... We are that desperate.
I'll also share a quick screen grab of front page of the Unity GI sub forum. A lot of people are unhappy - there is a real sense that this tech was added to make a great looking stage demo on a high end PC with very little thought about the end users who's big focus is mobile development.
But right now as a baking solution in Unity its very very broken - This is a massive issue for the Unity guys because most people that are using unity are making Mobile games and have no chance of getting games working with real time lighting! We really heavily one the quality of our light bakes to boost the quality of the look of the art work - its a big kick in the teeth when are are unable to produce the quality we saw with Beast in Unity 4.
Guess I'm just curious about how others are finding it, what issues they have and what they are currently doing to work around them. We have now moved onto serious discussions about how we could do our light bakes in Modo or how we can try to hack beast back into Unity 5... We are that desperate.
I'll also share a quick screen grab of front page of the Unity GI sub forum. A lot of people are unhappy - there is a real sense that this tech was added to make a great looking stage demo on a high end PC with very little thought about the end users who's big focus is mobile development.
Replies
I really hope they fix all this asap.
It's frustrating because we don't really have a dedicated tech artist and, as an indie, we don't have much room for an engine wizard. Although I'm best suited to do the work on my team, it's still not my wheelhouse. I'm really hoping my next project is on another engine - I miss playing with UE4. Hell, there are things that the source engine handled better!
From what I've read, Unity Tech is aware of the problems but they're not high priority.
U5 users should remember that now you have to set lightmap resolution of an object in two places: the old slider (which is for baked) and GI resolution (a dropdown list below).
Lt_Commander: good to know thanks. So you use Preserve UVs tick box? Or it's a different thing you're talking about?
But the payoff is well enough to work with it I think, With Blender's Texture Atlasing addon it makes things easier and being able to bake quality lightmaps in minutes rather than a day or more is a plus. Also by using blender our team can split the load and we can all bake lightmaps on different computers to get things done faster.
Here is a screenshot of one of my Cycles Lightmap tests.
The biggest gotcha I've found is the "Auto" or "Continuous Bake" check box(depending on version). If you leave it checked it's a nicer workflow for making changes, but if you are working with a team(over version control) it will not cache the lightmaps with the scene in Assets. You have to uncheck "Auto" and then click bake. It won't rebake(Unless you made changes), it will save the light maps out as .exrs in the scene folder. Now it can be shared with a team. If Auto is left on the other members of the team will have to rebake from scratch.
I've run into issues with the auto light map UV settings in Enlighten too, however Unity's FBX imnporter has a Generate Lightmap UV options. On one of the Unity forums people were saying that an angle of 120 gets pretty decent results and so far I can't complain. Rather than manually assigning lightmap UVs in a modeling program, give that a shot. Unity uses a bunch of different channels for different lighting things. When I find the doc link I'll post it.
Unlike in UE4, I couldn't find any way to look at the generated map flats - I had no idea what the sliders were doing in reality. Because of that and the insane difference between my own vs auto-geneated results, I have lost all faith in that feature.
Also, here's what the different UV channels are for: http://forum.unity3d.com/threads/quick-setup-for-starting-enlighten.309609/
UV0 is typical UVs
UV1 is Baked GI
UV2 is Realtime GI
UV3 is open.
We're doing bakes off of procedural level generation, so I have very little control over the end result of the overall lightmap layout - the plan is to be as hands off for the last pass as possible since we'd ideally want end user servers to generate and bake their own levels as a single button press without our input (hopefully).
Thanks for the info on UV2.
Unity 5 has changed a bunch of packing so our old method of doing these things does not work - along with the general bad quality / broken baking its been a massive kick in the teeth for the team
Probably not entirely related to Enlighten, but it's used at the same time.
StormyBA: Sad to hear. It sounds like a crazy amount of work.
We had another packing optimization problem: Beast allowed for rectangle lightmap UVs. Enlighten leaves the rest of the square empty
Modo makes doing Lightmap UV's mega easy, particularly with buildings and environment props ie, Lots of squares and few organic shapes. Again, made a massive difference to the final quality of the product. All I do.....
Atlas Unwrap
Relax
Rotate Vertical
Pack
Done
Takes about 10 seconds! The UV tools in modo completely blow the competition out of the water. Well worth checking out.
StormyBA: thanks for the tip. I'm going to have to check that out. Are those in 801? I'm got an 801 floating licence I can grab, I don't use it much though. Also, Max's Flatten Mapping can work well enough most times too.
To get the best speed out of it you really do need to customize the interface a bit. You can create star menu's much like maya has - I have one with all my UV tools, hit space and it all pops up
There are some other sneaky tricks working with a few different types of pack settings to not adjust scale. You can then say put -50% resolution on unimportant objects and pack again. Its pretty win and got some great results on CSR + Classics.
So a quick example - bit of a tunnel / car park type env.. Did an atlas, Relax, Rotate to vertical + pack.. This was the results.
Another nice feature is you can show relitive scale / distortion in the UV editor... all colour coded for ease of use! Really quickly shows up any dodgy bits of UVing
Thoughts? I dont know much about this kind of thing and perhaps some other people do!
Mesh Toolkit is the best I've found.
https://www.assetstore.unity3d.com/en/#!/content/18552
There's also Export2Maya, but it failed for me in Unity 5.
http://forum.unity3d.com/threads/export2maya-export-unity-scene-to-maya-scene-file.235241/
Also looked at the ExportOBJ sample, but that doesn't support vertex color, which I need.
http://wiki.unity3d.com/index.php?title=ExportOBJ
It'd be great to be able to transfer a mesh from unity 5 into unity 4, maybe bringing the unity 5 lightrig - do a bake and bring it back in? I believe that unity call's in these renders anyrate. It might be that you could reroute unity 5 to use beast.
Thanks for reporting this.
PS: I am compiling a document on UV handling related to GI in Unity (https://goo.gl/bHsCyq)
Must say we are still struggling a fair bit, especially now we have important regular builds that need bakes and given the system a real hammering. The results are so random and the quality is still bad.
I can definitely see how frustrating it would be with anything more complex than this.
The only way to see the complete render time is to open the Unity Editor log file and look for both the Bake time and the Precompute time. You can open the Editor log from the options button of the Console tab.
Problems for Baked GI:
1. The main issue we have been facing is render times for Baked GI. Baking a level with Default-VeryLowResolution can take north of 8+ hours for one of our levels. And this is no where near ship quality.
2. Another huge issue is the number and visibility of seams created at bake time. This is do to the way the second lightmap UV channel is being split. You can see these if you make a simple scene with sphere on a plane and bake. The sphere will have several seams since it's box mapped by default. The "Edge Stitching" from the document above just doesn't work.
Solution:
We've been able to get a acceptable bake times and minimal seams with this solution. (Though the results are far from perfect, and no where near Unity 4 quality.)
To speed up bake times select all Lightmap Static objects, open the Lighting tab, then go to Object, uncheck Preserve UVs and change Auto UV Max Distance from 0.5 to 50 and Angle from 89 to 180. This will reduce quality, but tremendously decrease render time.
This is because you have reduced the number of UV Charts calculated in lighting. You can see the UV Charts in the render modes at the top left of the Scene view. A better name for UV Charts would be "Light Emitting Surfaces". The UVs are simply used as a way to tag polygons, and have nothing to do to the way textures are applied to the models. A default box is 6 UV Charts, hence it's the cost of 6 lights at render time. Changing it's settings to the above will make it cost one light. In practice this reduced the Precompute phase of one of our levels from 4 hours to 30 minutes. The Bake time remains unchanged about 3 hours.
This solution also fixes the number of visible seems because each UV Chart is emitting light and the seams are not blended. That's why the sphere in the above example has seems. The seams are not visible if using Realtime GI, but we need Baked GI for performance reasons.
Other problems:
3. The Auto UV settings above help bake times and reduce the number of seams, but lighting quality suffers a little. If you have an object half in shadow and half in light in one UV Chart, the entire surface will bounce light from one particular spot instead of averaging the entire UV Charts surface. You can fix this a little by adjusting the Auto UV settings per object, but you'll be re-introducing problem 2.
4. There seems to be no super-sampling happening at render time. So an object casting a shadow on another object or itself is going to look super jaggy. The only workaround is to up your resolution, but see problem 1.
5. Ambient Light, unlike every other ambient light feature, cast light inward as if it was a solid color Image Based Light. In Unity 4, Max, and Maya ambient light is more of a minimum light value. If you have an indoor scene, ambient light in Unity 5 is useless.
6. Realtime lights are baked with Baked GI. This is because Realtime lights affect the Precompute phase, and the Precompute is used in the Bake phase. We had to make a simple script to enable lights on Start().
7. Light probes don't match Baked GI, but they do match Realtime GI. This problem is intensified the more you use lights above 1 intensity.
Hope this info helps!
The light probes issue is dealt with in 5.3 beta, also lightmapped terrain is broken if doing additive level loading. Since when a new scene loads in, its terrains will reference the wrong lightmap id's
well i have direct contact with unity, so been getting them to fix a lot of light related issues blocking my work. Problem is most of these issues they say they cant backport to 5.1 or 5.2, and im not too keen on the idea of using a 5.3 beta for production
ya the problem with light probes seem to be resolved, giving you results closer to what the lightmaps are. What im still fighting with is issues with light-mapped terrains when doing additive scene loading.
its a rock and a hard place. Since it is really hard to deal with large projects in the old 32bit unity 4 with it always crashing the editor due to lack of memory.
I can so for the most part, it works now, and 5.3 should resolve a lot of lighting problems. But im still finding issues with doing additive level loading and lightmaps. For levels loaded the normal way everything seems to work ok skankerzero.
You just need to try and get bake times down, which i did by using probes to light most small objects as opposed to giving them lightmaps, than greatly taking down the lightmap scale on terrians and really customizing light-map scale per object. This helped reduce baking time as well as optimizing the amount of lightmap texture space needed.
The other issue i have been hitting, is doing 2 sets of lightmaps, since there is a day and night to the games im working on level. This is possible to due but is very hacky and required my own code to do so.
I have the exact same problem. Can't use lightprobes cause using Application.LoadLevelAdditiveAsync() makes them totally black. I can't understand why...
i tried using Lightmapping.BakeLightprobesonly (or something similar) and it doesn't seems to work.
If you find a solution don't forget me
To get around this, i have a little editor script that iterates over all my additive scenes, grabs the light probe positions, and the light probe coeffecients, than goes into my first scene and combines all that data into it.
Does your script do the job?
In terms of light map UV's changing... Sounds like the plan is to bake the environment into one mega mesh, spit that out to freeze all those light map UV's and then bake. Will mean having live working scenes and then game scenes which are baked. Not really ideal but having had conversations with other developers it seems like it is going to be less of a head ache and will achieve better results in the long run.
It works really well, but we hit a few snags that prevented us from using it in development.
We could have found solutions for all these, but gameplay comes first.
Creates a dirty lightmap, its just a random color on each object in the uv's
It spits out an obj file
Lastly it projects all of our albedo texture detail onto the uv2's and saves into a new texture. This is of course a low resolution representation of the world's detail but it is enough info for the color bouncing.
From here we just bake in modo.
So light probe wise, rather then imaged based lighting we just have a solid color and range. The character can be lit by 2 at any one time but we are traveling through the environment very fast so its easy enough to ground the player.
For reflections, we have gone down a cube map route. We place an object in the scene to fill the interior of a building for example and bake the cube map for that box. As a player you then travel through that cube map rather then the cube map traveling with you ?hope that makes sense). Our scene will have a bunch of these and the cubemaps blends and switches as you travel through them. Again not as accreate as reflection probes but very cheap and the speed we are traveling means we can get away with it. We are hoping to incorporate this into our pbr workflow soon as well rather then the directional lightmap.
Correct me if I'm wrong though, would you not be baking light and reflection probes in unity after you have applied the lightmap?
Some seams here and there, to solve this I just give those objects a bit more scale in the lightmap, and they disappear.
With our style we don't need a dense probe grid, so that seems to help keep the cost down.
The worst issue I've had so far is with shadow bleeds, where flat meshes are butting up against flat terrain... i.e. a cliff mesh stuck into a plateau in a terrain. Need to cover with deco meshes I guess. (We convert terrains into meshes too as a pre process, to reduce the cost)
Otherwise the baker hasn't been bad. We're not stressing it much though.