asdf
#Lightmapping Problems
brazen yew
@vague jacinth
aside, why can i see it even when its not realtime?
this is the test light i'm using to establish baseline either way
the walls should be green too i think. working on just getting this one dock platform (flat plane) working
GI: Baked Lightmap view
the mesh import
vague jacinth
aside, why can i see it even when its not realtime?
Before generating, baked lights are rendered as realtime for preview purposes
vague jacinth
Looks more or less as expected
brazen yew
so yeah just a directional light, but heres my light settings for previewing
it wants 20 min to bake that one light
and doesn't appear to have any impact
vague jacinth
not scaling on import
Best to check from the mesh itself at the end of the transform hierarchy to any transforms above it there are no big scales, as the mesh lightmap resolution is calculated before any scalings that exist in the scene
Mesh Renderer's Scale in Lightmap is applied then on top of that
brazen yew
theres nothing scaled in the heirarchy
the scale in lightmap setting i have now is the very edge of what it wont complain about running out of space or whatever
and i had to massively lower the minimum lightmap resolution on the mesh importer
wonder if this is interesting
vague jacinth
So the thing that remains is that you have relatively much lightmapped surface area, and a lot of texels among them so it's not surprising that it takes a long time to bake
Every checker square is a point that's shooting out the rays during light baking
vague jacinth
Direct samples towards light sources and other samples towards the environment, if I understand the system correctly
brazen yew
removing GI from that fog might go a long way
vague jacinth
Indeed, it is a huge area that doesn't benefit from it
brazen yew
fog removed
vague jacinth
You can gauge by eye how many of those checkers would be necessary to represent the illumination in that area, varying by the kind of lighting you have for each spot
Then tweak the Resolution globally, or Scale in Lightmap for local adjustments
brazen yew
when you say "checkers" what specificcally are you referring to?
vague jacinth
Each is a lightmap texture pixel or texel, as defined by Resolution
brazen yew
ohhhh ok this is enlightening
to fix the fog, just make it unlit i guess?
its only using these
oh wait that breaks the normal block
vague jacinth
That's up to your artistic intent
Simpler to have it as unlit so it doesn't receive ambient lighting
But also can be interesting to let lighting interact with it
But I would not let it contribute to GI
brazen yew
i was using a normal map to give it some volume
is there a way to keep that but turn it off as a GI participant?
vague jacinth
Yes, in Mesh Renderer properties
brazen yew
ahh yeah
vague jacinth
You can set objects to contribute to GI but receive GI to probes rather than lightmaps, which makes them blue in the contributor view
brazen yew
now its showing as receive GI only (orange)
vague jacinth
Meaning they reflect light and cast shadows during baking, but don't consume lightmap space
brazen yew
thats probably what i want right
vague jacinth
For the fog you'd keep it not contributing
brazen yew
vague jacinth
But in case of some objects like the barrels and machines, using lightmaps for them could be wasteful, but allowing them to cast shadows onto the floor's lightmap below would be useful
brazen yew
yeah i need to work my way around everything again. for now i just want to test that baked lights work
vague jacinth
Mind you you do need light probe groups and reflection probes around for a "full" lighting setup
brazen yew
that part i did get to watch a long video on
vague jacinth
And as far as I know in case of "contributing but probe receiving" renderers, their lightmap resolution will be irrelevant, even if the debug view shows the checkers for them
brazen yew
the lightmap on the dock is really high rez
definitely dont need that level of detail
vague jacinth
That looks a lot more than 10 per unit, if that's what the others had
So it might be scaled or have a unique Scale in Lightmap
brazen yew
ok yeah lowering scale in lightmap brings it back up
what about this "min lightmap resolution" on the mesh's import settings
vague jacinth
The texel density on the railing is also very high (depending on how close the railing will be observed, anyhow) and its texels are somewhat stretched
brazen yew
yeah i have done zero work on this untli just now. so starting with just the dock
then i need to review everything else
the dock platforms are just an intentionally shaped plane with normal details baked on
oh right. so i was wondering about that "minimum lightmap resolution"
it defaults to 40, but it says its too large until i scale it down to 10
vague jacinth
what about this "min lightmap resolution" on the mesh's import settings
The lightmap atlas must ensure enough padding between UVs so baked light won't bleed from one object to another
But the lightmapper can only arrange mesh UVs, it can't modify them per-mesh, which is why lightmap UV generation must be enabled separately to begin with
As a consequence while it can calculate how to arrange the atlas based on required padding, it can't do that for UV islands within a mesh, instead that's determined by the Minimum Lightmap Resolution
brazen yew
so i scaled back a lot of settings (on my draft light settings) and set the scale in lightmap down to 0.25. the checkers look like this now. is that the right direction?
had to lower min res to 5 tho
just for the sake of getting a draft level look at baked lighting for now
imma just disable everything in the room except this dock and try it again
vague jacinth
it defaults to 40, but it says its too large until i scale it down to 10
The warning about being too large is probably a result of your Max Lightmap Resolution being too low
It doesn't actually directly reduce any resolution, determines whether you get many smaller textures or fewer big ones in the atlasing process
Smaller limit might lead to more efficient atlasing (maybe unintentionally) but it may scale down your object lightmap scales automatically
brazen yew
i was under the impression you do that just to do quick bakes to spot check things and then ramp up for the final cut
vague jacinth
Max Lightmap Size setting probably exists only for hardware specific reasons, it doesn't practically change how much baked lightmap you end up with
vague jacinth
Lowering Resolution is the simplest way to reduce bake times for a draft, but on the other hand if you don't also ensure meshes min lightmap UV size doesn't exceed resolution you'll easily get light leaking
brazen yew
oh. yeah that went instant
vague jacinth
Which may or may not hinder your testing
brazen yew
oh hey!
there we go
now the spotlight doesn't seem to have a preview anymore
is there some internal flag on the light saying not to preview now?
because it got baked?
yeah thats what i was looking for
ok ok now everything is making sense
vague jacinth
wonder if this is interesting
This one is texel invalidity
https://forum.unity.com/threads/lightmapping-troubleshooting-guide.1340936/ c. 15
Basically when a lightmapped surface is in view of backfaces of a mesh that contributes to GI, so the rays from the texel terminate on an invalid surface
Its purpose is to "stretch out" light in areas where objects intersect to avoid unnecessary shadowing, but if you have open meshes in plain view it can appear anywhere
vague jacinth
because it got baked?
Yes
If it did have a realtime preview you'd see twice the light which wouldn't be correct
brazen yew
yeah thats sound
vague jacinth
If it had both with some kind of masking or layering to not overlap with itself, it'd behave like a Mixed light which would be confusing if it were not one
brazen yew
ok... i think i broke out of the brain jail on this. thanks. i can see the preview working now too
i take it having massively cranked up intensity on lights for a scene this size is normal
vague jacinth
If you want baked lights back to realtime preview, you can clear the baked lightmaps from the dropdown next to Generate button
vague jacinth
i take it having massively cranked up intensity on lights for a scene this size ...
Depending on size and depending on definition of massively but kinda yes, with "realistic" logarithmic falloff light intensity must also increase logarithmically as distance increases
brazen yew
Depending on size and depending on definition of massively but kinda yes, with "...
oh... now i see something i wasn't thinking about when i made this shader graph
it seems like the scaling is being taken into account for this material's lightmap. its a plane with an "auto tile" feature
is there something i can do to have it apply to the lightmap as well in the shader graph?
its set up in a way i can scale a single plane and it will auto change the tiling size to accomodate the scale of the mesh
but it looks like the lightmap doesn't follow suit
vague jacinth
but it looks like the lightmap doesn't follow suit
You wouldn't want it to, not that it's possible
brazen yew
so the stretched checkerboard is fine?
vague jacinth
It's not ideal, but point is the shader doesn't have anything to do with it
brazen yew
ah.
vague jacinth
You can use texture tiling for the surface itself, but for practical and technical reasons lightmapping has to use the mesh UV coordinates stored in vertices
brazen yew
ok
vague jacinth
So while this kind of mesh is fine for drafting the level, ideally you'd make a custom mesh in the right proportions
Though it can work in a pinch if the stretching isn't too bad and you aren't casting any sharp baked shadows on it
brazen yew
ah, really?
this is scenery the player doesn't really interact with at all besides seeing it
vague jacinth
You can also use two planes, technically, but mesh seams over a surface introduces a new problem, as the two meshes lose lightmap continuity
brazen yew
guess i'll see if the baked lighting looks like shit
vague jacinth
That resolution is still relatively high in my opinion
If the lighting and shadowing are anything close to as soft as we saw before, you can get by with a third of that resolution
But again, also depends on how close the surface will be seen by the player
brazen yew
i'm dropping their scale to 0.25 s o far
not close
most of this
the tunnel is where the player takes off into with a brief camera pan around the hangar
so i imagine i focus most of the work there
vague jacinth
not close
So in anticipation for dropping every object's scale in lightmap, could consider dropping Resolution globally again
brazen yew
theres a global resolution option? in the lighting settings?
vague jacinth
so i imagine i focus most of the work there
Whether it's a third person, first person or uncontrollable bird's eye view makes the most difference
brazen yew
shmup style game. this is more or less a cutscene scene
the actual gameplay happens in the tunnel
vague jacinth
theres a global resolution option? in the lighting settings?
Yes, Lightmap Resolution
which the Minimum Lightmap Resolution of lightmap UV generation refers to
brazen yew
yep now i got it working
brazen yew
Cont'd from General:
what else could possibly be making this texture so dirty looking? i tried messing with various lighting settings including ambient occlusion, compression, resolution settings and others. tried changing the lightmap filter to use something besides optix (no idea what i'm doing but just following suggestions). Tried removing all the lights and rebaking, adding double sided GI to get rid of texel errors. the texture wont go back to the way it originally looked
2nd image: This is what the texture looked like before i started doing lighting. I started a new scene and created a wall plane with scaling of x28 (the walls have auto tiling scale based on the model scale).
Other notes: made no changes to my directional light in the scene. just added some baked lighting around the map. its relatively low rez for now just for drafting but even trying to up the resolution a bit didn't make it cleaner looking. but i didn't try upping it too much
UPDATE: Reducing the metallic scale to 0.8 in my material (one of the features in the custom lit graph) seems to reduce this dirty effect. For now it looks decent but wondering why that would suddenly pop up with lighting baked in
20% metallic reduction ^
vague jacinth
20% metallic reduction ^
It looks like you have relatively noisy roughness maps, metallic maps and occlusion maps, so it doesn't seem like a mystery
Metallic materials are affected very differently by lighting compared to non-metallic
Namely metallics only receive specular lighting
brazen yew
i see
vague jacinth
So it's important specular reflections and ambient diffuse lighting do not diverge more than they should realistically
And occlusion map multiplies out all indirect diffuse lighting which is usually a lot of the incoming light, and causes further discrepancy between metallic and nonmetallic spots
Furthermore metallics react to higher smoothness by sharply increased visual contrast, whether darker or brighter
vague jacinth
And normals can do it too
Removing all the maps and trying them alone and in different combinations can give you a good idea of what they do
brazen yew
yea tried normal too, its too subtle to be teh cause. you're right it was the metallics
scaling it back restored it to less noisiness
vague jacinth
And what I prefer as a benchmark is to have some primitive spheres or capsules with fully metallic, nonmetallic, rough and smooth varieties of materials
So you can see how different a smooth metal object would be compared to a rough nonmetal, for example
brazen yew
And what I prefer as a benchmark is to have some primitive spheres or capsules w...
i just added reflection probes about the level and i noticed it makes the wall look way different, is that because of the metallic property also? like everything with metallic material properties seems more alive now
like brighter
oh hey it even kinda fixes the dirty thing
metallic restored to 100%
vague jacinth
i just added reflection probes about the level and i noticed it makes the wall l...
Metallics are almost entirely lit by specular, which comes from reflection probes (and from realtime lights)
Nonmetallics only partially, depending on smoothness
Which is why it's important that in an area where there are lightmapped surfaces and light probes there are also reflection probes, so specular lighting and diffuse lighting match
brazen yew
yup! that part i did get a good read on about
took this long to get to the reflection probes. sick!
looks much better now. with a little color adjustment
uh... do i need light probes for reflection probes to work on static stuff? or thats just for moving entities
vague jacinth
Again why it helps to have those primitive meshes with very basic materials, so you can move them around to confirm there are no drastic changes in types of lighting locally
brazen yew
cuz i only put them on the center platform and into the tunnel where the players takes off into
yeah i oughtta add that to my workflow
vague jacinth
uh... do i need light probes for reflection probes to work on static stuff? or ...
They are for dynamic objects as well as for static objects that contribute to GI but do not receive GI to lightmaps
Required to be placed where lighting changes noticeably, but no more than that
brazen yew
aite
vague jacinth
APVs are also an option
They are placed automatically, usually so densely that they can replace lightmaps altogether
Especially since one object can sample multiple probes from an APV, but not from a light probe group
It's a very different workflow though, and not supported by all platforms
brazen yew
yeah i'm using an APV
for the tunnel anyway
this look right?
i'm under the impression i dont need to do more than that with the APV version
settings jic
vague jacinth
You don't, assuming you have set up the subdivision and other settings correctly
And assuming you don't get artefacts which may require tweaking of settings or manual tweaking of probes using adjustment volumes
brazen yew
i haven't gotten to anything actually using them yet
vague jacinth
Light probe groups are simpler in that way, you can just move the probes where they're needed
brazen yew
soon. this is getting to the late stage of this scene i've been working on for like
jeez. 2.5 months now
vague jacinth
And because APVs can replace lightmaps, their complexity is offset by the fact that you can skip doing anything with lightmaps
Workflow complexity I mean
And offset by the fact they don't need manual placing which can be really great in labyrinthian scenes
brazen yew
think APVs would be the way to go for the gameplay scenery then? this is one of the only real cutscene scenes in the game
with tons of static stuff in it
the main loop involves mostly scenery that moves past the player
infinite scrolling background terrain type deal. i'm assuming i want APVs for that
instead of lightmaps
even this map ultimately transitions into a roofless version of the tunnel so you can view top down but it scrolls past the player
vague jacinth
infinite scrolling background terrain type deal. i'm assuming i want APVs for t...
Not sure what that means practically, all baked lighting is a bit problematic with dynamic or moving environments
To put it lightly
brazen yew
like, there's gonna just be 3-4 panels that loop endlessly in a train that moves continuously to simulate flight motion
like a shoot em' up style game. ikaruga etc
with some intermittent cutscenes that do play through some static environmental backgrounds but few and far between
the prototype i used a pool of base meshes that could rotate or offset some of the terrain decorations to make a much broader range of random permutations of the scenery, but ultimately it would pool about 6-8 variations and randomly drop one at the end of the chain as it crosses a certain threshold
usually there'll be 3 tiles active at any given time that need drawcall overhead
so for lighting i was asking, would that be a job for APVs? can they move with the scenery?
vague jacinth
I don't think they can
vague jacinth
Scenery can move relative to them, which might give acceptable results if the environment changes little along the direction of movement
brazen yew
actually wouldn't it just make sense to bake the lighting and still just move the terrain anyway?
like the player's action has no impact on the background
the sun isn't changing positions or anything
you're usually high over the terrain anyway
in some rare biomes, indoors like this tunnel zone
vague jacinth
actually wouldn't it just make sense to bake the lighting and still just move th...
You mean bake lightmaps for the moving terrain or something else?
brazen yew
but i think for the enclosed zones realtime lights wouldn't be a problem since there'd be few of them altogether
yeah
bake the light into the textures and then just move 'em
vague jacinth
It could work, never tried that or seen it tried
brazen yew
puzzle to solve later. appreciate the insight, this has been very enlightening