Can we bypass the initial lightmap.data asset ?

[JAMS49]

So I have checked out that I can manually bake the lightmap in the scene and then store it using the lightmap switcher , when I switch it to day and night , I have scene that it actually replace the lightmap.data asset of the empty day scene on the baked lightmap tab . are those lightmap.data asset which are assigned automatically when switching between day and night are alone enough to properly arrange the lightmaps of the scene? because I have a large scene , I baked it and it's lightmap.data asset (before i've stored the bake info into another scene) is sooo large , like 370 mb or something , which causes crash in mobile for being too big . can I get rid of it somehow?

[laurenth-personal]

You can indeed remove the initial lighting data asset reference from the scene. Just go to the lighting window and click the lighting data asset reference and press delete on your keyboard. This will not include those data when loading the scene (ambient light will be applied) and then only load the lighting data when using the lightmap switching tool. You will have to do this after every lighting bake though since the asset will be referenced again after each bake.

[laurenth-personal]

Just thinking now that the problem with this is the light probes. They won't load correctly if your scene doesn't contain any initially. This might be possible to fix by calling this after loading the light probes : https://docs.unity3d.com/ScriptReference/LightProbes.Tetrahedralize.html You don't need this function if the number of light probes is always the same, but if it changes (and removing the lighting data asset will make it change from 0 to something when you load) you need to call this function.

[laurenth-personal]

I could include this in the tool, but I'm not sure when. I would need time to test it.

[JAMS49]

I could include this in the tool, but I'm not sure when. I would need time to test it.

Thanks a lot !

You can indeed remove the initial lighting data asset reference from the scene. Just go to the lighting window and click the lighting data asset reference and press delete on your keyboard. This will not include those data when loading the scene (ambient light will be applied) and then only load the lighting data when using the lightmap switching tool. You will have to do this after every lighting bake though since the asset will be referenced again after each bake.

Thanks a lot for the reply , I was actually losing my hope that i can never actually run it on devices below 8 gb ram. Im feeling calm that you replied. But when I delete that 370 mb lighting data asset and play my scene , and click on lighting 1 or lighting 2 , lightmaps switches but they arent properly arranged on the gameobjects at all , random lightmap scales/arrangement on the renderers and I get a message

You can indeed remove the initial lighting data asset reference from the scene. Just go to the lighting window and click the lighting data asset reference and press delete on your keyboard. This will not include those data when loading the scene (ambient light will be applied) and then only load the lighting data when using the lightmap switching tool. You will have to do this after every lighting bake though since the asset will be referenced again after each bake.

I have already did it several times , but whenever I switch between lighting 1 or lighting 2, the lightmaps indeed loads, but do not get arranged correctly on the objects , and I get an error message , But when I keep the reference of that 370 mb lightmap data asset initialy befolre playing , everything works fine, that's why im finding a way to get rid of it somehow, i mean not to get required to put the the huge lightmap data asset on the reference box iniially before polaying or building. here are some screenshots to show you.

[JAMS49]

I could include this in the tool, but I'm not sure when. I would need time to test it.

Thanks a lot , It's be a big life saver for memory , I dont wanna break your valuable time, I would just eagerly wait for a solution, it'd be very kind of you buddy. and I have lightprobes same and unchanged in all the scene, i mean constant number and same positions. I just wanna get rid of that 370 mb extra elephant crashing my build. and I have a last question, as I have a big openworld scene, does unity loads all the lightmaps in memory during playtime? i mean i have total 210 lightmaps total size 292 mb, I divided the whole scene in 64 chunks that enables and get disbaled based on player's position , not everywhere i need those all 210 lightmaps , maximum 10 lightmaps are required in each chunk , somewhere it';s just 2-3 that covers all the renderers in that chunk becauise i have used baked tag on the objects of each chunks to ensure that the objects within the chunks doesnt share any lightmap of another chunk's objects , thus 64 baked tags , and lightmaps are well arranged in 64 chunks objects , any way to just load the lightmaps of the objects of that specific chunks only ? instead of loading whole 210 lightmaps on the play? that would be a huge saving of memory , Im so grateful for your reply. Thanks )

[JAMS49]

I could include this in the tool, but I'm not sure when. I would need time to test it.

Hey any update?

[laurenth-personal]

Hello, after a bit of testing it looks like I could work around the initial lighting data asset easily for light probes. For lightmaps I would need a bit more work. Would an intermediate fix for lightprobes only be useful to you ?

[laurenth-personal]

Forget that, the lightmap setup was buggy due to some unfinished code. It should now be fixed. There is no new release on package manager yet, the changes are only on the github repository's master branch. Can you test if it works for you ? I'll close this when you confirm the fix and when I have time to make a proper release.

[JAMS49]

Forget that, the lightmap setup was buggy due to some unfinished code. It should now be fixed. There is no new release on package manager yet, the changes are only on the github repository's master branch. Can you test if it works for you ? I'll close this when you confirm the fix and when I have time to make a proper release.

lightmaps are swapping and scaling correctly on the renderers now , also the lightprobes and environment reflection also working correctly , all without putting the static scene lightmap.data asset on the reference of baked lighting tab. so I thought that I can now just delete the lightmap.data asset ., so I did., but then I get one problem, the lightmap swapping works correctly , also the reflction too , but the only problem left is the lightprobes arent loading at all , are lightprobes still dependent on that lightmap.data asset that I have deleted? thanks a lot , at least now the scaling of the lightmaps are correctly working )) hooyah!

[laurenth-personal]

Hello, thanks for the feedback. Yes the probes were still contained in the lightingdata asset, this is now fixed and they will be stored in the scene. I tried your repro steps and my change fixed it, but can you please confirm it works for you too ?

[JAMS49]

Hello, thanks for the feedback. Yes the probes were still contained in the lightingdata asset, this is now fixed and they will be stored in the scene. I tried your repro steps and my change fixed it, but can you please confirm it works for you too ?

Huge thanks buddy !!! at last it works 100% properly as expected , the lightmap swapping , accurate scaling on the renderers , swapping of lightprobes and reflections everything works just fine without the need of that primary lightmap.data asset . I have deleted that entire lightmap.data asset from the project and everything just works cool without it , neat! It saved me a 370 mb memory footprint which is huge for mobile games. Thanks a lot again, I can confirm that everything is fine now. It'd be better to update it in the package manager finally.

[JAMS49]

Hello, thanks for the feedback. Yes the probes were still contained in the lightingdata asset, this is now fixed and they will be stored in the scene. I tried your repro steps and my change fixed it, but can you please confirm it works for you too ?

Could you please update the package ? I'd badly need the modified version for my own project.

[laurenth-personal]

Hello, I'll start preparing the new version.

[laurenth-personal]

The new version is up on open upm. Thank you for your patience and your feedbacks 👍

[JAMS49]

The new version is up on open upm. Thank you for your patience and your feedbacks 👍

The new version is up on open upm. Thank you for your patience and your feedbacks 👍

Hey , again there is problem with the scaling of the lightmaps on the renderers, lightmaps are not arranged properly on the objects at all. It happens when the initial lightmap.data asset is on the reference . and when I do that without keeping it ,. lightmaps arent placed on any objects at all i.e the whole scene has absolutely zero lightmaps. any clue what's the problem?

[JAMS49]

Hello, I'll start preparing the new version.

I have tested it in a new empty project , The scaling is not working somehow , here is an warning I get in the console

Im sorry for the hassle , but the system worked very well in your master repository , but not working in other projects

[JAMS49]

probably it's something with the project setting , I will look into it

Edt 1: when Im switching your repository project into android platform , this problem occurs . when it's on windows platform, everything is fine as expected. is there any problem switching it in android platform?

[laurenth-personal]

This is caused by static batching being enabled in your project.When using my test project it’s disabled, but if you import the package in your project you have to disable it yourself (project settings/player) This is only problematic if you have different lightmap resolutions on the different lighting scenarios. If the resolution is always the same you don’t need to apply renderer scale and offset.Le 24 août 2024 à 09:13, Jubaer Al Meraj @.***> a écrit : probably it's something with the project setting , I will look into it

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you modified the open/close state.Message ID: @.***>

[JAMS49]

This is caused by static batching being enabled in your project.When using my test project it’s disabled, but if you import the package in your project you have to disable it yourself (project settings/player) This is only problematic if you have different lightmap resolutions on the different lighting scenarios. If the resolution is always the same you don’t need to apply renderer scale and offset.Le 24 août 2024 à 09:13, Jubaer Al Meraj @.> a écrit : probably it's something with the project setting , I will look into it —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you modified the open/close state.Message ID: @.>

I have just tested a scene with two cubes , and lighting 1 scene has a directional light and lighting 2 scene has a point light , both resolutions are same and use the same lighting setting and baked result size are same too, still not working with static batching checked. previously I didnt have this problem I was aware that I have to carefully set up the lighting so that it comes out with same resolution , size and same lightmap scaling despite of different lighting setup, previous version worked properly checking the static batching in project setting, now in that same scene, it show that scaling issue due to the static batching checked. even in my little test with two simple cuibes, same lightmap resolution , the lightmaps are misarranged. Im extremely sorry for the hassle but im afraid other users will face the same trouble even if they properly set up scenes with same resolution and renderer scaling .

[laurenth-personal]

Can you try disabling "Apply lightmap scale and offset" ? that should prevent the warning. That being said, I might need to do something else to support this + no lighting data asset

[JAMS49]

Can you try disabling "Apply lightmap scale and offset" ? that should prevent the warning. That being said, I might need to do something else to support this + no lighting data asset

Hi I tried what you said , still it fails to arrange the lightmaps properly in the scene objects . even if I have the initial lighting data asset in the reference , still broken arrangement . I have static batching unchecked too, and not using static batching utility either . I reset up the light swapping system in the scene, still same failure . But reflection and light probes are working correctly I have checked them , according to my idea , i know ehere is shadow and lights , I did check the light probe, it's working fine , But only the problem is now misarrangement of lightmaps. It's now worse than previous version, the previous version at least could arrange the lightmaps , light probes an reflections properly with the need of lighting data asset and even static batching checked because my 2 lighting scenerio use same lightmap resolutions and same object scaling values lightmap atlas. in this latest version lightmap isnt arranged corectly even if I disable static batching . I think there is something a bit wrong.

[JAMS49]

Any updates or correction?

On Sat, 24 Aug 2024, 18:21 Laurent, @.***> wrote:

Can you try disabling "Apply lightmap scale and offset" ? that should prevent the warning

— Reply to this email directly, view it on GitHub https://github.com/laurenth-personal/lightmap-switching-tool/issues/39#issuecomment-2308376124, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQQZMINELXHHVIETFXIPN4LZTB3F3AVCNFSM6AAAAABLOU7MDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBYGM3TMMJSGQ . You are receiving this because you authored the thread.Message ID: @.*** com>

[laurenth-personal]

Hello, I am publishing a new version. This should help with terrain or multiple terrains. Terrain is not the same as a renderer and it was poorly handled in the code. This should be improved now. Also I found when there is no lighting data asset, lightmap scale and offset are reset on all renderers. I have not found a solution for this, I don't know if there is one besides not using static batching.

[JAMS49]

Im not actually using any terrain here, what you see are actually meshes not any terrain itself. But you can also test with something little, like two or three cubes, same resolution, you can clearly see how it's not working with static batching checked. and Yeah, Im not using terrain at all.

On Tue, 27 Aug 2024, 01:56 Laurent, @.***> wrote:

Hello, sorry about that. I see you are using terrain, do you use several terrains ? That part of the code is pretty bad.

— Reply to this email directly, view it on GitHub https://github.com/laurenth-personal/lightmap-switching-tool/issues/39#issuecomment-2310969804, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQQZMIJ23NOEOEXRWI3N6MTZTOB5BAVCNFSM6AAAAABLOU7MDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJQHE3DSOBQGQ . You are receiving this because you authored the thread.Message ID: @.*** com>

[laurenth-personal]

Hello, I have tried on a more recent version of unity (2022+) and with several light maps (4 lightmaps). I can see the indices of the light maps are stored incorrectly in the different scenarios. A dirty workaround could be to increase the maximum size of your light maps if it's possible to fit all in one. I would like to investigate this issue but I don't have the time before the weekend.

Le mar. 27 août 2024 à 06:02, Jubaer Al Meraj @.***> a écrit :

Im not actually using any terrain here, what you see are actually meshes not any terrain itself. But you can also test with something little, like two or three cubes, same resolution, you can clearly see how it's not working with static batching checked. and Yeah, Im not using terrain at all.

On Tue, 27 Aug 2024, 01:56 Laurent, @.***> wrote:

Hello, sorry about that. I see you are using terrain, do you use several terrains ? That part of the code is pretty bad.

— Reply to this email directly, view it on GitHub < https://github.com/laurenth-personal/lightmap-switching-tool/issues/39#issuecomment-2310969804>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AQQZMIJ23NOEOEXRWI3N6MTZTOB5BAVCNFSM6AAAAABLOU7MDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJQHE3DSOBQGQ>

. You are receiving this because you authored the thread.Message ID: @.*** com>

— Reply to this email directly, view it on GitHub https://github.com/laurenth-personal/lightmap-switching-tool/issues/39#issuecomment-2311525151, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFUMAT3B5JWX736Z5Q2YE5LZTP26LAVCNFSM6AAAAABLOU7MDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJRGUZDKMJVGE . You are receiving this because you modified the open/close state.Message ID: @.*** .com>

[laurenth-personal]

Hello, I managed to reproduce some issues with the lightmap indices, and some issues I think caused by the back tracking of the current lighting scenario. These 2 should be fixed in the new version and I hope those were the issues you were having.

In the end, I think it's not possible to totally remove the lighting data asset because the lightmap scale and offset of the renderers seem to be stored there and not on the meshrenderers. In the editor it's possible to apply lightmap scale and offset on awake before static batching is applied, but in a standalone build the assets are probably already batched together when the scene loads and it's impossible to change anything, if the lighting data asset is not there they will just use the default lightmap scale and offset for all the objects.

[JAMS49]

Hi, Sorry for the late reply, I was curious what happens if static batching isnt setup in build. Instead of it, Im using static batching utility which means, I will batch those in Runtime when only needed. but Before that, it will be okay without lightmap data asset?

On Sat, 31 Aug 2024, 22:05 Laurent, @.***> wrote:

Hello, I managed to reproduce some issues with the lightmap indices, and some issues I think caused by the back tracking of the current lighting scenario. These 2 should be fixed in the new version and I hope those were the issues you were having.

In the end, I think it's not possible to totally remove the lighting data asset because the lightmap scale and offset of the renderers seem to be stored there and not on the meshrenderers. In the editor it's possible to apply lightmap scale and offset on awake before static batching is applied, but in the build the assets are probably already batched together when the scene loads and it's impossible to change anything, if the lighting data asset is not there they will just use the default lightmap scale and offset for all the objects.

— Reply to this email directly, view it on GitHub https://github.com/laurenth-personal/lightmap-switching-tool/issues/39#issuecomment-2322946153, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQQZMIJ5PFT6D4RUPLQSUYDZUHSTTAVCNFSM6AAAAABLOU7MDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRSHE2DMMJVGM . You are receiving this because you authored the thread.Message ID: @.*** com>

[laurenth-personal]

I have exposed a new public function that should help with runtime static batching : ApplyDataRendererInfo(int index) You can either call this before runtime batching, or LoadLightingScenario. That way, your renderers have the correct lightmap scale and offset before doing the batching. Hopefully it will bake the lightmap scale and offset in the batched geometry as it does when there is a lighting data asset.

[JAMS49]

Thanks a lot, It seems to be a great solution, I will check it out.)

On Thu, 5 Sep 2024, 02:09 Laurent, @.***> wrote:

I have exposed a new public function that should help with runtime static batching : ApplyDataRendererInfo(int index) You can either call this before runtime batching, or LoadLightingScenario. That way, your renderers have the correct lightmap scale and offset before doing the batching. Hopefully it will bake the lightmap scale and offset in the batched geometry as it does when there is a lighting data asset.

— Reply to this email directly, view it on GitHub https://github.com/laurenth-personal/lightmap-switching-tool/issues/39#issuecomment-2329880691, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQQZMIPYOQQEF5FU3S7VH7LZU5SG3AVCNFSM6AAAAABLOU7MDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRZHA4DANRZGE . You are receiving this because you authored the thread.Message ID: @.*** com>

[JAMS49]

Hi , Im back to work , I have updated the package but the "store" button is missing. Generally I avoid rebaking the lightmap which took me almost 23 hrs to bake the whole world , so, I just place the baked lightmap data asset on the reference and click on store, the lightmap and other datas are thus cached as expected. , can you please add that button?

On Thu, Sep 5, 2024 at 3:07 AM JAMS @.***> wrote:

Thanks a lot, It seems to be a great solution, I will check it out.)

On Thu, 5 Sep 2024, 02:09 Laurent, @.***> wrote:

I have exposed a new public function that should help with runtime static batching : ApplyDataRendererInfo(int index) You can either call this before runtime batching, or LoadLightingScenario. That way, your renderers have the correct lightmap scale and offset before doing the batching. Hopefully it will bake the lightmap scale and offset in the batched geometry as it does when there is a lighting data asset.

— Reply to this email directly, view it on GitHub https://github.com/laurenth-personal/lightmap-switching-tool/issues/39#issuecomment-2329880691, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQQZMIPYOQQEF5FU3S7VH7LZU5SG3AVCNFSM6AAAAABLOU7MDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRZHA4DANRZGE . You are receiving this because you authored the thread.Message ID: @.*** com>

[laurenth-personal]

Hello, I'm sorry to read that you're missing the store button. I've always seen it as a useless step but needed workaround because in much older versions of unity i think the callback after the asynchronous bake was not reliable. I can add an option to restore it but I can't make a new version this weekend. The method for storing is public though so you can use a unity event or another script to call it and pass it the lighting scenario index. If you're using unity event make sure you switch to the mode that also runs in the editor.