If I understand you correctly, you want to use prefabs with baked lightmaps in your scene, right?
If so, that’s already possible regardless of which backend you use. I’m attaching a project that allows you to perform what you describe.
In the project, you will find two scenes. Open the scene LightmapInstances and play the scene. Press on left mouse button, all the instantiated spheres are prefabs with baked lightmaps from Progressive Lightmapper.
You can bake your lightmaps in another scene. In the project, you will find another scene called BakeLightmapPrefabs. You will find a baked directional light in the scene and some lightmap static prefabs. What you have to do is to attach PrefabLightmapData.cs as a new component to your prefab, add your prefab to this scene (BakeLightmapPrefabs) and then, press (Assets > Bake Prefab Lightmaps) button (It’s important that you don’t bake the lightmaps using Generate Lighting button but instead, use this custom button).
Now go back and open LightmapInstances scene again and press play, you should see that prefabs read their lightmap data. Another important point to highlight is that this scene also needs lighting data asset, so even if there are no lights, you should still generate the lighting. Lightmaps generated through PrefabLightmapData will overwrite the existing lightmaps in the scene and use the lightmaps you previously generated.
I hope that answers your question. Let us know if this solves your problem.
Kinda. When I do a standalone build for my game, all of the lighting is lost. In UFE, the levels are actually prefabs of your scene… when a standalone build is done you lose ALL of your lightmaps.
And I’ve used a similar script and that stuff doesn’t work correctly
So it looks like it works in the standalone build…but only if I hit play. THANK YOU!! I’ve been trying to get this to work in 5.5 and it is very flaky. Hopefully, I will be able to use this with UFE once they update their toolset to work with this… And it is easy to set up… would it be possible to add an option to this for the Progressive Lightmapper?
Compatibility with earlier versions of Unity is not something we are supporting. With the addition of lightmodes the lighting data is very different. Also, we have removed directional specular. Also, the version of Enlighten (for realtime GI) is different now. There might be some narrow scenario where this would work - but I very much doubt it.
Possibly you could grab the lightmaps and extract the per instance offsets and scale, but again its not something we support.
Is the 3000 object limit is a memory restriction at the moment?
Going forward will additional LOD’s be considered part of the object limit if they are included in the bake data?
Many thanks for all your work on this guys, its a fantastic feature!
Taking a little more time with the progressive lightmapper, and I am still seeing the same issues I ran into before when using this… and I notice that light probed objects will stick out like a sore thumb…
I may as well just stick to just using straight up light maps, just to keep the look consistent… Most of my levels will be small so it is not an issue. Will there be a way to fix this so that I will be able to use light probes on moving objects and it will look consistent?
It is probably because of the way I modelled my dojo level… in pieces… and sorry, I am used to using mentalray so photons always slip out lol…
Here is an image of what I am dealing with. Unless this is the actual behaviour of this, it is probably something I am doing.
I also don’t have textures on my model since they are part of another scene in 5.5 and I don’t feel like bloating my hard drive on the beta…
See that bright light on this corner? Unless this is intended behaviour, I shouldn’t worry too much… my favourite part of this lightmapper… I can see how much time it will take… and the results are always consistent…
My light intensity is 1.5 for the sunlight. In 5.5, I have Shoji screens covering the windows with a transmission shader… and I have no textures in this test
You can use mesh blockers with one texel that are invisible to camera to author your lighting. In progressive lightmapper, it is utmost importance that you have watertight meshes (i.e. vertices of your mesh are welded) to achieve correct results, otherwise you can easily end up with artifacts/unwanted results.
What do you mean by this? Like, adjusting the brightness of your light probes?
What AcidArrow asks is about the indirect intensity of your light source and not the intensity (direct). Have you perhaps modified that value?
Indirect intensity of 4 will generally cause a scene to look incorrect if combined with bright albedo colors. Try dialling that down somewhat. If it is too dark (because not a lot of light is entering) you probably need some fill lights inside if you want it to look brighter. Pieces should be fine, try using the “Texel Validity” visualzation mode in the scene view to see if non-watertight meshes are causing issues. Large visible areas of red would mean there are issues.
I used that feature, and I saw a few bits of red that didn’t bother me much… and also too my goal for this level is to simulate light coming from outside… it’s an old dojo, like the scene from The Matrix, when Morpheus was fighting Neo… In Unity 5.5, the light is dialed down considerably and in its place, I am using tone mapping…
I gave it a shot today and we can’t use it, as long as we don’t have support for transparencies (which is on the roadmap, as I’ve read above).
What I noticed is, that most of our shaders need at least a recompile (change shader file, undo, save) in order to work.
Some didn’t work at all … the meshes just were invisible. Don’t have anymore time left right now to try to fix them.
@Kuba You state, that the lightmapper will be flagged as experimental on release.
What does this mean in terms of enlighten lightmapping?
Will this remain in the build for the whole 5.6 life cycle?
With our current game project, we will be stuck with 5.6 for at least the next 1.5 years (due to the drop of Win 8 support after 5.6) and we need a 100% working lightmapping solution (which enlight right now would be).
