[RELEASED] Raytrace Lightmaps | ShineSpark - Live Feedback, Subdivision, One Button UV Atlas Packing

ETA on directional lights?

 

I would love to see color bleeding. I can do it post process to some extent but would be nice to make it into the map.

 

@LightingInABottle

We did an overhaul of our scenes in the game, & we encountered a problem...
lightmaps are not being loaded properly in additive scenes
meaning we have a base scene, but other scenes with lightmaps are not properly loaded.
Our programmer is asking if we could load the lightmaps manually & which code we should look out for to modify the code?

 

Hi Colton, I'm glad it is working well for you, sorry about the late reply.

1. I think that it should. Workflow wise it might be better to try to break things up a bit, but in general you can lay out lots of objects into one atlas, which makes working with many objects boil down to working with much fewer maps.

2. This only bakes and affects lightmaps. Anything to do with realtime shadows will remain unchanged.

3. You can definitely have outside lights that don't effect the interior and vice versa purely through shadowing, since the light rays will be stopped by the geometry and not leak through. That being said, for workflow and render times I would guess that working on the maps separately will makes things easier and give you the best results. If you are trying to have maps with both outdoor and indoor lighting, that should also work from the lightmapper since it will use 32 bit .exr files to store the full dynamic range. I'm not sure of the full workflow and all the pieces that might be needed in Unity to make sure the textures aren't converted to non-floats with a clamped range or for something like tone mapping.

4. Technically it will work with overlapping UVs as best as it can. It will render from both parts of the geometry and the map will end up being a mixture of the two areas. I strongly recommend against this, but it is possible you can get away with it in some areas.

If you can automatically layout the individual UVs and save them to your asset the lightmapper will use them. I've experimented with Unity's auto UV layout and it does seem to work, but if it isn't saved with the asset, the next time you load your scene, the map and the UVs won't match up.

 

There is the LightingInABottle component that is used to keep these settings from one save to the next. Is your scene saved and these things are still happening? You should be able to save even while rendering without any problem since the lightmapper doesn't block Unity. You can look at the ID on the LightingInABottle component to see what map it will use as well as look in the render directory to see the maps and their IDs on disk.

The re-mapping of lightmaps comes from a limitation of Unity. Basically Unity doesn't work well with non-sequential lightmaps, it will at least fill them in with black. I'm surprised though that it is causing you problems. If you can send me a test scene (hopefully minimal) at support at shinespark io I can take a look. If I can repeat it I can fix it.

 

I'm not sure what you mean by this, have you turned your bounces up and are still not seeing bounce light? Color bleeding can often take very bright light bouncing into dark areas to really stick out. Many times the effect is more subtle than pronounced.

 

There is a file called LightmapLoading.cs that contains everything used for loading the lightmaps. Your programmer can send me a message at the support address and I can work with him to get him what he needs.

 

I see bounced light, but the color of the material it is bouncing off of is not influencing the light after the bounce.

 

I would suggest using the collection and putting in some unique id to the map so that if the list gets rearranged somehow by removing an index that the maps don't change what meshes are attached to them. If you have 10 maps, each with a mesh assigned to them and all are baked, then remove the mesh from the first map at index 0, all of the subsequent maps will be 'off' by 1 since the meshes now assign to the map above them. So all of your maps are now connected to the wrong meshes.

 

@LightingInABottle
Thanks for the response, also how is the memory usage with your plugin? I see some notes on memory optimization in 1.10. I ask this because using the new progressive light mapper in 5.6 crashes unity with an out of memory error while baking a decent size scene with 16gb of ram.
Cheers,
Colton

 

Crap, you are absolutely right. You just pinpointed an issue that I was incorrectly attributing to camera effects. It appears that all of my mapped surfaces get blown out white when I load an additive mode. I think it is loading the maps into the outgoing scene instead of into the incoming one and when the old scene unloads it blows up the maps or removes them from memory.

 

This is exactly what should be happening. I haven't seen an instance of this in my own tests or heard anyone having this problem yet, so I will need you to help me recreate it to see what the actual problem is.

 

I will need more information to be able to know what the problem is. The only thing I can think of initially is that vertex color might be used, which won't make it into the lightmapper.

 

I'll have to look into this more, I'm not familiar with additive mode yet. My initial thought is that the problem is with the maps not being reloaded at all and a lightmap setting is getting reset. If you use tools->reload lightmaps does it fix the problem?

 

I would need specific numbers to say for sure, but most usage of memory comes from textures and the lightmap buffers. Rendering more samples per pass can also use more memory, though this shouldn't be a problem unless using lots of samples per pass on high resolution maps.

I will say you have more control over exactly what you are rendering lightmaps for and what you are just tracing to. You can also render one map at a time, which can be a huge help as well.

 

I did a test, it does reflect color, but man, does that light have to be bright. It is a pretty delicate balance to get it to work. Any way to expose a color bleed property globally?

 

I tried calling the underlying method and also tried manually clicking. It appears to load the previous scenes maps, so I tried a hack of putting all of the target scenes maps into the scene that has no lightmaps, and that almost almost works. It loads the maps but really hoses index 0 for some reason. Most of the maps don't align correctly after the load. There must be something getting loaded either out of order or at the wrong index. It seems to be trying to map a bunch of the meshes on the index 0 map at runtime after an async load.

 

The loading should just take the maps and put them in the lightmap slot that matches their file name. The objects should just take the ID in the Lighting In A Bottle component and make that their lightmapIndex. The loading is as simple as possible on purpose. The remapping is the only more complicated part, but that should only happen in the special circumstance that there is a missing map in the sequence of map names.

I'll tell you as much as I can, but to really dig in I'll need to look at a scene that I can use to recreate what you are seeing.

 

@LightingInABottle
thanks for the response, our programmer will jump right in... & no, reload lightmaps doesn't work.
We also encountered another problem, which i think it could be the 1st earlier problem.. when i load the scene, the lightmaps are inside, it looks beautiful, however when we test the scene, everything becomes so dark... no idea why.
We even check our quality settings, its set at fantastic

i dunnoe whether if has been answered before, if i got 1000 static objects i need to create 1000 ids? cuz previously i was using mesh combiner, now we are using a procedural creator to create our maps, & placing the id script into a parent gameobject which contains some 100 gameobjects in children, wont render *shrugs*

 

I doubt the quality settings will be the factor here. I would check PlayerSettings->Other Settings->Rendering->Color Space is set to and see if that makes a difference.

Every object needs a Lighting In A Bottle component, which is why they are placed automatically. This is what enables saving settings properly and loading the maps. You can always combine geometry and just make sure the UVs don't overlap.

 

@LightingInABottle I sent a project link through PM that has a loading async screen and allows you to change between async and single to see the difference. It gets to the point of loading the scene, everything looks good, then when it unloads the previous scene it loses the maps.

 

I'll take a look, thanks

 

@LightingInABottle
SteamVR locked that setting to linear

 

@LightingInABottle

How would we handle the lightmap loading for additive scenes? As we have a base scene (with the camera) and are loading in scenes e.g scene_part1, scene_part2, is there an API call to load the correct path from the resource folder?

 

I'm going to take a look a this with the test scene I've been given. I had some stuff in the way first. Hopefully it is just a matter of not having dealt with additive scenes and I can get out a version that works with them. Either way I'll keep everyone posted.

 

Hi!
1. When do you plan OSX support?
2. Is the sourcecode available?
3. Do you support rendering in Play Mode?

 

Hi Galfaroth,

1. OS X support is already there.
2. The source for the scripts is available, the source for the C++ .dll that does the rendering is not.
3. Rendering in play mode is not supported, this is an editor extension and does not work in real time.

Let me know if you have any more questions.

 

2. Do you have a special paid licence to obtain the code?
3. Is it technically possible to have Texture2D and yet run it in Play Mode (not necessarily real-time).

 

I have not created a special license yet. We could try to work something out over email if you like.

I don't think there is technically anything preventing it from being used during play mode, but it isn't something I've tested yet. Keep in mind that it is a native shared library and so will only work on Window and OS X right now.

 

Hey, this is a great tool. We've just purchased it and I've been testing setting it up for some of our scenes. We've got a huge outdoor scene with several thousand mesh renderers. Right now we're testing to try and get similar visual results to Enlighten's baked GI using your tool because the control of lightmap altasing and rendering has allowed us to really drop the disc size of our builds.

However we've got a pretty stylized game with emissive materials, point light cookies, a directional light, and heavy emphasis on color bleed. Currently we're baking the GI and using realtime direct light and shadows, so setting up the environment light box (the 5 area lights) is giving me enough as far as ambient and AO is concerned.

What we're really missing with this tool is the ability to bake light from emissive materials and the directional light bounces. Like CaptainMurphy mentioned, an exposed variable for artistic control over color bleed would be incredible.

Anymore information or an eta on any of these features would be hugely appreciated. Thank you so much for any help and for much a nifty tool.

 

I'm really glad you like it and that it's working out.

I'm planning on starting on directional lights soon, I've been working on tools to make development easier.

I think a color bleed knob is a good idea, but I haven't looked into it yet so I don't want to give an ETA. I tried a few things with emissive materials and didn't manage to get them right with some limited time but they are a possibility in the future. Lights don't shadow, so if you can fake emission with area lights, it would still be quicker.

 

Does anyone else get this after baking some lightmaps? It seems that it will cause the lightmaps to become emissive just randomly. The texture is fine, the material doesn't have anything emissive on it, but it glows. If (while running) I disable and reenable a LIABID component, it seems to fix it. Something of a pain to do that in runtime.

Here is the deck with a previous LIAB lightmap.


Here it is after doing a new bake.


It is baffling me. Somehow this happened before and it fixed itself without any other intervention, but I have no clue how it did it.

 

My guess would be that either the lightmaps are getting set to something other than non-directional or that the colorspace is getting switched.

If you are loading scenes through scripts you can always make sure the lightmaps are reloaded with:

liab.LightmapLoading.ForceInitLightmaps();

 

Can you PLEASE fix the issue of it removing the lightmap assignment if it has no meshes assigned to it? I just had a mesh get disconnected from a crash and I am now 'off' on 80+ lightmaps and the only way I can fix it is to rename 80+ maps to match the new indexes.

 

Is this issue something I can repeat in the scene that you sent me? Last time I mentioned I need a scene or some other way to recreate this to be able to fix it.

I need that because I'm not immediately sure how this happens. The LightingInABottleId component has a number on it that is the index of the lightmap it will load. If the Id is 6, it should load up the map with 6 in its name. There is a remapping of lightmap file names and component Ids if there are any missing since Unity needs lightmaps to be sequential.

Without much information to go on it sounds like there might be issues with the lightmap files being remapped but the Unity file not being saved. One thing that might help would be to save often as well as saving to a new version of your file often.

The lightmapper will create a new directory for each version so you can always have old versions of your scene with matching lightmap files.

 

This is what I am having happen. Because it is using the collection index as the key it can cause it to go nuts if one of the indexes shifts. It needs to be changed to use a different key instead of the index of the collection so that the map and the meshes connect through some other method besides that index id.

 

From your video I think I've been able to recreate this. I used 3 maps, turned off 0 and 1, then took out the geometry from 0. This made 1 remap to 0 and use the old map from 0 when it should use the old map from 1. It will be at least a week before a fix makes it out to the store though, since the it usually takes about 5 days for Unity to approve a new version.

 

Directional lights are coming along. Here you can see their sharp shadows, uniformity along the ground plane and 2 bounces.

 

Alright, I am getting closer to figuring out what causes this weird 'blown out' lightmap issue.

I had baked about 30 maps, maybe more and noticed that all of the new maps were blown out white in play mode. So after a few hours of going crazy and trying to figure out what the issue was (and no, LightmapLoading.ForceInitLightmaps() does not fix it, there is something intrinsically wrong with the map load, not with something in LIAB that I can tell).

So after much head scratching I gave up and wiped my temp cache in the project and did a full Reimport on the project. BAM, fixed. So, as a test I did a new lightmap to see if I could recreate it (in 5.6.1f1 Pro). I selected one of the lower detail maps and did a new Render in the LIAB panel. Bam, it is broke in play mode again.

So, here are my findings:
Object in Edit mode after baking new map


Object in Play mode after baking a new map


The global map is correct in play and edit mode


The Object map is not...
(Play mode, blown out white)


(Edit Mode, correct lightmap)


Soooooooooo....
I tried reimporting just the affected map, with no change, then tried a reimport of the entire Resources/[scenename] folder, then it fixes the blown out map. So, take that for what you will, it may be a Unity issue, or a problem with the Unity cache and how the maps are being created and connected. Hopefully this will help someone else that runs into this down the road.

 

I've only been able to recreate this so far inside the texture map viewers (the light mapper gui texture previews and Unity's lighting window texture previews). I've had to bake the maps with PlayerSettings->Color Space set to Gamma, then switch to Linear and press play without baking again. Even then, the viewport looks fine and only the texture preview windows get bright. It also seems to not be consistent which leads me to think it might be a caching issue as well.

 

Hey All,
Does this extension take into consideration normal maps? With Unity's default lighting when you set all your lights to baked, all the normal maps disappear and objects look terrible :S
Thanks,
Colton

 

Hi Colton,

This doesn't take into account the normal maps on objects when baking. It doesn't mess with your normal maps, so dynamic lights will still shade with the mapped normals.

 

Thanks for the prompt response!

 

@LightingInABottle The new version is just throwing errors over and over in 5.6.1f1

Code (CSharp):

1. DllNotFoundException: ENABLE_RUNTIME_NAVMESH_BUILDING
2. liab.LightmapLoading.GetTexture2DFromFile (System.String filepath) (at Assets/shinespark/LightingInABottle/Scripts/LightmapLoading.cs:141)
3. liab.LightmapLoading.GetLightmap (Int32 idx, Boolean useAsset) (at Assets/shinespark/LightingInABottle/Scripts/LightmapLoading.cs:404)
4. liab.LightmapLoading.LoadImgsEditor (UnityEngine.LightmapData[]& lmds, System.Collections.Generic.HashSet`1 forceNew) (at Assets/shinespark/LightingInABottle/Scripts/LightmapLoading.cs:423)
5. liab.LightmapLoading.CreateLightmaps (System.Collections.Generic.Dictionary`2& remapTable, System.Collections.Generic.HashSet`1 forceNew) (at Assets/shinespark/LightingInABottle/Scripts/LightmapLoading.cs:564)
6. liab.LightmapLoading.InitLightmaps (Int32 min) (at Assets/shinespark/LightingInABottle/Scripts/LightmapLoading.cs:586)
7. liab.LightmapLoading.ForceInitLightmaps (Int32 min) (at Assets/shinespark/LightingInABottle/Scripts/LightmapLoading.cs:615)
8. liab.liabmain.Update () (at Assets/shinespark/LightingInABottle/Editor/Plugins/liabmain.cs:1711)
9. System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection/MonoMethod.cs:222)
10. Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation.
11. System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection/MonoMethod.cs:232)
12. System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection/MethodBase.cs:115)
13. UnityEditor.HostView.Invoke (System.String methodName, System.Object obj) (at C:/buildslave/unity/build/Editor/Mono/HostView.cs:262)
14. UnityEditor.HostView.Invoke (System.String methodName) (at C:/buildslave/unity/build/Editor/Mono/HostView.cs:255)
15. UnityEditor.HostView.SendUpdate () (at C:/buildslave/unity/build/Editor/Mono/HostView.cs:330)
16. UnityEditor.EditorApplication.Internal_CallUpdateFunctions () (at C:/buildslave/unity/build/artifacts/generated/common/editor/EditorApplicationBindings.gen.cs:249)

It is happening and showing for pretty much every folder in the project. Any ideas?

 

This DLL is not from me, so that is separate from this issue.

I don't get any errors on a brand new scene or on a previous, more complex scene.

The line that throws the error is a call to a C++ function that reads the header information from the .exr.

I will need more information from you.
1. Are you using .exr files saved from another program?
2. Are you sure the permissions haven't changed on the files it is trying to load?
3. If neither of these leads to a fix, I will need either a scene or an .exr that can't be loaded, whichever I can use to recreate this.

 

The DLL name is actually arbitrary, it was happening on every item in the project regardless of whether it was even a DLL at all. It was throwing it on images, files, etc as long as the LIAB window was open (and only if it was open). Anyhow, it was finally fixed, yeesh, the Unity import process is driving me nuts some days. I had to close the project and wipe out not only the shinespark folder but also all of the temp and library files too. If ANY of them were left in the project after updating LIAB it causes it to throw those DLL errors. A full reimport didn't fix it, but killing all temp files and starting from scratch got me a lot closer.

I noticed in the release notes that it has directional mapping. Is that in the released 1.11 version? I don't see any directional type maps, at least not the type I am used to with Unity baking.

 

I need to be clear here, that LIAB was not giving DLL errors according to the output you posted. That was a different DLL not being found that isn't part of this asset. On a fresh import Unity may run the scripts before loading the .dll, just means a restart, but that doesn't seem like the problem you had. It also does not deal with the Library directory directly at all. My best guess is that this was a Unity caching and/or file permissions issue. Did you try reimporting all assets? That may save deleting directories manually.

This release added directional light support, not Unity's directional light mapping format.

 

Well the only thing that changed was updating to the new version of LIAB. All of the errors were the same message of a dll not found and referencing the code snippet above the exact same, other than the name at the top. I reimported everything, restarted Unity multiple times, removed the shinespark and reimported the asset multiple times, etc. It just would not let go of something that was causing an issue until I removed the shinespark folder, the library, and the temp. After starting Unity and importing LIAB it gave me more errors, a restart of Unity after that and it was working.

I misread the Directional notes then. I was excited that it was directional maps. Doh!

 

Unity not loading the other .dll files and LIAB not being able to load the .exr files are likely two symptoms of a deeper issue. The LIAB scripts only make use of a single .dll so I can't think of a way it would cause problems for the others loading. If you can recreate the problem let me know and I'll dig into it.

 

Hi! Just purchased your asset. And this far is great timesaver for me. But I have one issue with it. When I hit play, lightmap seams to change and become way too bright. I am using Unity 5.5.1f1. Please help/ Maybe I missed some settings or something?

EDIT:
Hmmm. It looks like if I switch to linear color space - everything works ok. But in gamma space, lightmaps always looks "washed out" in play mode. We are working on project for mobile, and gamma space is only option