GI support for spotlights and pointlights

The tittle is wrong. I mean the spot and point lights shadowing for GI, not just the light support.

Is there any ETA for this feature? Any chance that it will be available for testing in the beta?

Do you want it to be included in the first 5.0 release?

 

Hi,

any idea on which .x version will bring it on? I'm not trying to nail you to a specific one, but I just want to get an idea about "how far away in time" this might be...

 

Hey Metron,
Even if we pinned it to a specific dot release we would not be able to predict when would that be released. As Jesper said, it's high on our list of things to do after 5.0 ships.

 

What is bounce light shadowing exactly? I'm mostly playing around with point and spot lights and I do see light bounce "properly". What does Directional Light bounced light do that point and spot, doesn't?

 

Great to hear! Looking forward to this feature, too! Because you know, dynamic GI is awesome, but with only directional light and static objects support its pretty limited.

 

Okay. Now I'm horribly confused.



That's a spotlight. It's set to dynamic. There is no other light and/or ambient.

Again, what is supposed to not be working with spots/points?

 

As always with unity, there are more things doesn't working than working Xd

 

But... It's working.

 

@AcidArrow as I understand it, if you put another block behind the block on the right, light will be bounced onto the back of the block in the middle (previously the right most block). As though the light had traveled straight through the first block, bounced off the second block and landed on the back of the first.

Try it, put another block back there.

 

@Zomby138 Ah, yes, you are right. Thank you for clearing that up. I haven't felt this confused in a long time.



Guess enlighten and Unity's Shadowing system don't play that well together (yet?)

 

@AcidArrow yeah. Luckily the GI is real time, so we should be able to work around it by just switching the light off when you're not in the room or something.

 

Yeah, it would be nice if it "just worked", but I think it can be fairly easily worked around.

At this point in time, I'm a bit more worried on how long enlighten takes to precompute things. I wouldn't say it's slow because what it's doing is far more complex than what Beast did, but I'm kind of afraid of opening one of my bigger scenes and try to apply some sort of high density lighting (static or dynamic) to it.

 

That's indeed the case that doesn't work yet. It will though...

But as you can see, it's already fine to use it if e.g. you're limited to one room or generally don't see past the wall on which the local light is shining.

 

As for the precompute times: they heavily depend on the amount of output texels (so realtime GI resolution) and charts (UV islands) in the realtime UVs.

The first step should always be to check the "GI - Charts" view as it shows you the resolution and the different colors refer to different charts. Generally texels 1 world unit big are a good start, but the resolution can be increased for indoor scenes and decreased for outdoor ones. That can be done globally or per system via lightmap params.

The renderer has some properties (Lighting/Lightmapping window > Object tab) that control auto UVs -- a UV simplification algorithm that can help you lower the amount of charts and reduce the amount of unwated seams while preserving the wanted ones. Changes to those parameters have an immediate effect in the "GI - Charts" view, but they take time to trickle down through the entire pipeline.

We will have general guidelines on how to tweak those parameters to get the best results in the smallest amount of time and some examples from the Viking Village should serve the purpose well.

 

@Kuba , I understand, I'll definitely look into this (and I've already played a bit with the auto-uv options and lightmap parameters).

My main issue right now, is that static lightmap quality is tied to the precomputed quality (that if I understand correctly, it just upscales the data from precomputed, and it adds direct light at high res). For Arch-viz style graphics, really dense lightmaps, where every lightmap pixel counts are pretty much a must. So if I want a static lightmap with res of say 50 (which I often do, for small scenes) where every pixel counts, I have to also precompute at resolution 50, which, at the very least in the beta and with my kinda old current computer is close to impossible. (and it wasn't with Beast)

With that said, I'll definitely play with the variety of settings more. I actually like learning a new system and find how to play to its strengths. I'm just a little bit uncomfortable that it seems that my previous workflow has become much harder to achieve. (at least, as I said, with the current beta and my current rig, both which are probably subject to major change).

 

The resolution for the precompute and the static light map are totally separate. You can do a precompute with one texel per unit and a static lightmap with fifty. Note that you'll want to set your lights to static GI.

 

If the precompute misses indirect contact shadows (by say having a really low resolution), then, no matter what res the static GI is, it won't be there.

 

Example.

It's only lit by Sky Light, which is set to static.

 

Hmm. I'll try it out when I get home.

 

Ok I've had a bit of a play around. Seems to me that if I'm on non-directional mode then I get identical results for my baked lightmap no matter what I set the precompute res to, even if I take it all the way to zero. But if I use the directional modes, it does make a difference. Perhaps some of the directional data is stored in the precompute somehow?

Which mode are you using?

 

Non directional.

I also have ambient occlusion at 0. Try turning AO off, because AO is indeed calculated at baked res, but that's not the same as GI data.

I also made a more obvious example.

 

I just tried turning off AO and it seems that you are right after all! I consider that to be a bug.

Now it's gonna be really annoying me. >_<

 

Right now indirect lighting is indeed upscaled from the lightmap done at precompute resolution. It does take visibility at bake resolution into account, so the results should be better than from realtime lightmaps. So no need to increase precompute resolution to the same value as bake resolution.

We're working with Geomerics on making indirect lighting be calculated at baked res by using final gather, which will remove the need to increase the precompute resolution. This will allow for really nice contact shadows and penumbras just from bounced light. No exact timeline for that yet, but you can be sure that we want it in as soon as possible.

 

Well they are better (and combined with a bit of AO, which I believe is done at the baked res) and does end up looking better, but it's still clearly not as good as what it should look like if the GI was calculated at the baked res as well.

That's good enough for me (for now ).