![]() So as soon as something like that comes up, please poke early. I'm sad to hear that it's been frustrating for you. We might miss it sometimes, we might have other priorities some other times, but we'll hear you out and try to help as much as we can. In the long term we can add APIs that will help with creating everything from scratch:īut that will likely come after we've done some changes when it comes to storing inputs to lightmapping (to separate them from scenes) and changes wrt to multi-scene and light probes. occlusion probes (attenuation for up to 4 lights affecting the probe).light index for occlusion probes - an occlusion probe points to a light.shadowmask index - a light points to a shadowmask layer.In the mid term we can add APIs also to the lighting data asset that will help with lighting modes: In the short term we can add an API that will allow you to modify: Something that other users are already doing to keep lightmap data together with prefabs. The other is to store the data in your own asset (or possibly as references in the scene itself, as otherwise referencing renderers would be tricky) and patching it at scene load and after entering play mode. One approach is the one that you took, so trying to modify the lighting data asset. We could take a step back and look at what you want to achieve: apply lightmaps and light probes in the scene. That said, I can see how its black-box nature can be limiting, especially in your case. Reflection probes do belong in the lighting data asset as they are as much "baked GI" as lightmaps and light probes are. The other reason was that realtime GI and then lighting modes were in a lot of flux until last year, so exposing APIs would make it much harder to shift things around. Initially the asset wasn't really meant to be modified by the user as it contains a lot of realtime GI specific mappings that you really don't want to deal with. ![]() This separation is crucial for a decent end-user workflow. LightingDataAsset was introduced so that the scene (source data) doesn't need to be touched when we bake/precompute lighting (generated data). Possibly separate Reflection probes and even Light probes into different files Add complete read/write API to LightingDataAsset It was mentioned by devs somewhere that the reason for LightingDataAsset was to make project merging easier (when working with a team), but to me this solution created much more problems than it solved. Asking Unity to bake a cubemap can instead force lightmap rendering for the whole scene with the purpose of just initializing a new LightingDataAsset. Reflection probes get in the way by being saved in the same asset, even though they have literally nothing to do with baked lighting. Lightmap-renderer mapping can't be saved. Light Probes can't be created without calling Bake(). light probe colors seem to be saved) or not at all. LightingDataAsset is a black box with no API. Before LightingDataAssets were introduced things were nice and easy - there was a lightmap array, lightmapIndex, lightmapScaleOffset, they could be altered by a script and saved with the scene. This is not the way it should be, and it's not the way it was before. I even had to spend a few days reversing LightingDataAssets in a hex editor to get the job done. Sometimes it's tougher than writing the actual lightmapping code itself. To my regret, every time I have to deal with patching Unity lighting data, I have to fight it. I have a faint hope that some of the developers will read this post. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |