U3 lightmapping question

when i create my lightmap while in defered rendering path (so that i can set shadows property on spot and point lights) all the shadows created from either spot or point lights are gone, unlike the direction light. Question is that a bug or it can not be baked since i am in defered rendering?

 

Up!

 

In deferred rendering point and spot shadows should be present. Make sure that you are in deferred mode and that your shadow distance is set far enough in the Quality Settings. Also make sure that your lights are set to "Auto" (which is the default).

 

potentially related to the cookie problem? see cookie thread

 

Cookies should show up regardless for the realtime lights (when close enough) if everything is set up correctly.

 

hmm. Do you mean the baked shadows are gone ? The baked shadows are meant to disapear if you are inside "shadow range" because the lights have become real time, and would use their real time shadows instead.

Try turning shadow range down to 0 (in the quality settings) and see if the long distance version of the lightmap has the shadows baked onto it.

If you want both the long distance and close up lightmaps to have baked shadows then you can set the lights to "bake only".

 

Exactly, Unity 3 uses a dual lightmap system where in the foreground we use dynamic shadows/lighting combined with indirect lighting in the lightmaps. In the distance we blend to lightmaps that include direct and indirect lighting with no dynamic lights/shadows. If tweaked correctly it's very nice.

 

Okay, seems i am getting the idea behind the shadow distance now. I was setting it as defauled 300, played a little with the value and i am seeing the effects now. Thanks guys.

 

Now each light can have its own shadow distance i suppose?

 

No, it's global.

 

GOD! i am loving this beast!

 

Yeah me too =D

I just put the ambient occlusion right up and it just looks awesome.

 

hi... i am trying to combine lightmapped objects with a dynamic light.

the lightmaps don't have a direct shadow... just gi and ao (from vray). i want the direct shadow be created from a directional light in unity (and i want to be able to change the position of that light in realtime). so thats why i didnt bake direct shadows into the lightmaps.

so in the unity 3 beta... when i create a lightmapped material on an object the shadow dissapears, what do i have to do in that case? I guess this has something to do with the deferred rendering, or am i completly wrong?

thanks for any hint.

sinnlos

 

Try adjusting the shadow distance to a lower value. I think the default one is a bit too high at the moment.

 

i already tried fiddling with the shadow distance, with no luck. no shadows at all! i can see the changes on a diffuse material, but when i change to lightmapped it dissapears
you mean the shadow distance in the quality settings, right?

 

Let's do one thing at a time. You want a nice render with gi and ao that works nicely with realtime lights? Ok, forget vray for now, just do everything in Unity, in the Lightmap Editor:

- make sure the light's lightmapping mode is set to Auto
- make sure lightmap mode is set to Dual Lightmaps
- Bake

If your shadow distance (the one in quality settings or the one in the Lightmap Display window in Scene View) is big and you're in deferred rendering path (player settings), you'll be seeing all direct illumination and direct shadows still rendered in realtime, so if you move the light the shadow will update.

At the same time your indirect light part of gi will be taken from the lightmap, so you'll see nice color bleeding (which of course won't be updating if you just move the light).

This looks like something you want, right?

You 'create a lightmapped material'? That's wrong. If you're not working with some old project that requires Unity's old lightmapped materials (they can be recognised by having 'lightmapped' in the name), then there's no need to use them. All built-in Unity 3 shaders support lightmaps out of the box, so make sure all your objects just have the plain Diffuse shader on them (or any other from the built-ins).

 

screenshots!!!!!

 

Hi robert, thanks alot for your reply.

Yeah it does look like something i want, but the bakes i got from beast don't satisfy me (yet).

what would i do, when i still want to use my vray-baked maps?

I know you guys really put hard work into the integration of beast and now there is me, who still wants to use the "old" vray-stuff, but for my purpose (an interior architecture viz) i really need those maps in order to get the "same" result as my static renderings out of vray.

i will certainly use the beast lightmapping in my future game-projects. it is a lot easier in workflow, and i can't wait until we will be able to bake point-clouds aswell.
In fact the integration of beast is for me the main reason why i preordered.

thanks for any hint, and please don't be angry on me when i don't want to use beast for this project :?

cheers sinnlos

 

Well, lightmap rendering doesn't really care what texture it is getting as long as the texture is imported with the 'lightmap' checkbox on and of course HDR textures (.exr) offer the range that's often very useful in lightmaps.

So if you have your vray-baked textures you can just exchange the Beast baked lightmaps via the Maps pane in the Lightmap Editor window and all will work just fine (just keep in mind that your vray render has to use the same UVs and the same atlasing as Unity does).

There's no problem with making Dual Lightmaps yourself either. Just make sure the near lightmap doesn't contain direct light from any lights marked as Auto and that the far lightmap contains the full illumination from all the lights.

 

Will there be other options, such as baking only to Vertex Color? You can still have beautiful lighting only in the vertices and it creates very soft results due to the interpolation between vertices.

I know some people "cringe" at the idea of vertex baked lights in 2010... but we pulled off some nice lighting on our last project mostly per-vertex! (the sun light was realtime, that's it) http://xbox360media.ign.com/xbox360...sia-the-forgotten-sands-20100218043336447.jpg

On the other end of quality - what about directional lightmaps? Will Unity utilise this feature of Beast? I've used this in a couple of projects at work (the technique, not UE3) and it's one of the best ways to get radiosity correct ambient normalmapping.

It's all there!
http://www.illuminatelabs.com/products/beast/features

 

I doubt it.
Beast does not create low quality renders as those resulting from vertex lighting.

Also vertices don't bake HDRI, AO, ...

 

Does anyone have any information on how light intensity work compared to emmissive materials intensity? I'm experimenting with a simple conell box scene but havent come to grips with the Beast settings yet.

Also, the manuals info dont say what settings are "good" values to use.
Maybe a comparison with images showing settings, render quality and render time?

 

Well it does, among many other things
Beast Features.

...anyway, having the option is pretty important as often the quality of a baked solution is only just one small part of why a company/project will choose to light with vertex or texels, baked or dynamic.

But!
UT will determine the benefits of exposing certain parts of Beast themselves - and this is where my question is - what has UT determined is going to be exposed for users in Unity3 with Beast?

 

We plan on exposing vertex baking in a 3.x release as it would be beneficial for a lot of things.

 

I agree - there are meshes and scenes that would be better off with lighting baked into the vertex colors. Especially if there are some extra thin features in the geometry that are narrower than a reasonably sized lightmap texel or the tesselation in general is detailed enough to sufficiently show lighting gradients.

So there's a good chance we'll add this feature some time in 3.x - we just wanted to focus on polishing all the current lightmapper features for 3.0. And we'll have to put some thought into how exactly vertex baking will be organised, as you want your renderers to still reference the same mesh data if it's shared with other renderers, but you want to have a unique set of vertex colors per renderer - and all this needs to be presented in some understandable manner :wink:

So you worked on Forgotten Sands? Nice! Which parts did you work on?

When we were starting the lightmapper integration, we considered a bunch of lightmap storage techniques and EU3-style Directional Lightmaps were definitely among them. Then we came up with the Dual Lightmaps approach which looked very promising, so we decided to go for something new.

Now I can say we're very happy with Dual Lightmaps and in many scenarios they will give much better effect than Directional Lightmaps would and that's for two main reasons:

Firstly, with dual lightmaps you only bake indirect illumination into the the near lightmap; since indirect illumination is usually low frequency, you don't need high resolution here; direct light is rendered in realtime, so you're getting very crisp shadows, normal mapping, etc.; far lightmap contains full illumination, so also high-frequency lighting changes at the edges of shadows and so on, but hey - since this lightmap is only used at a larger distance, you don't need high lightmap resolution here either This way we solve the typical problem that lightmaps usually don't have enough resolution to nicely show the lighting.

Secondly, even if your light is baked - you can still animate it! Picture a hanging lantern that is swaying in the wind and flickering. Up close it will be rendered in realtime, it will be animated, with shadows flickering on the walls and so on. At the same time it's indirect light will be taken from the lightmap which will make the lighting look so much better. Far away everything will fade into the far lightmap, but at this point you don't care about the animation anymore, you just want the player to see something similar to what he saw when standing by the light.

So I can't wait to see what kind of stuff you guys will be able to pull off with Unity's lightmapping

 

Yeh, well I was in a tech art role, so my work was mostly behind the scenes - lots of memory/peformance profiling and trouble shooting, but I did help with some of the lighting, and it's one of my interests in game dev, which is why I'm eagerly following Unity3 Beast!

The case for duel lightmaps is good - I think it's found a good balance between realtime and baked.

But where I find DLMap's to shine is when most of your lighting in indirect.

Below is a very quick test scene inside 3dsMax - the angle I took the screenshot from shows only baked indirect lighting, nothing dynamic and you can see how the normalmaps all show up correctly. This is also per-vertex, but you're able to get per-pixel quality due to the technique used.

But either way, I'm just showing one of many, many ways you can get your scene lit - I'll be very keen to jump into some fun lighting when U3 is released! Good work with chosing Beast!

 

I am trying to figure out where the light mapped data is stored in the project? I poked around the library and assets folder but can't seem to turn anything up.

Will it be possible to change light maps? If the capability exists to load a new lightmap from file then we could potentially do some nice blending between different times of day.

 

The lightmaps are stored in a folder right next to the scene file in the project.

 

As aNTeNNa trEE said, in a folder next to your scene, with the same name as the scene. You can also just select the 'Maps' pane of the Lightmap Editor (the window you bake the lightmaps from) and click on any lightmap (in the recent betas actually on the Select button there) and the lightmap will get highlighted in the project view.

Of course. Just drag different textures into the slots in the 'Maps' pane. I recommend using .exr, as it gives you bigger dynamic range for the lighting.

 

in the current build (3.0.0b3) are lights and emissive materials mutually exclusive in Beast? I can't seem to get them to both turn up in the same render.
If this is the case, it would save me a lot of time. I won't have to bother trying to get both to work.

Also, is there a way to re-use a baked lightMap at a later date? My current scene is pretty big, and letting the whole thing render will take a VERY long time at the moment. I'm thinking days. Obviously I can make it more efficient, but beyond that being able to use my tests and partial renders later would be great.

 

Just a quick question. I've been following the details in this thread to get my lightmaps working using point lights in my scene (had to change to deferred rendering etc).

What I really want though is to create the lightmaps, and then remove the lights from the scene completely and just use lightmaps.

In that case, what should I be doing in terms of "Shadow Distance"? It could be that the beta still has bugs in this area, but I'm finding that if I set the shadow distance to 0 or 1, then my lightmaps disappear as soon as I run the game. While running, if I adjust the shadow distance (say from 0 to 1 and then back to 0) then the lightmaps appear, but I have to do this everytime I run the game.

Something definitely doesn't seem to be working right.

 

what you want to do is set the lights to be baking lights only. in that case they won't have a realtime light representation at runtime

 

Ahhh awesome! I saw that setting and wasn't sure that that was what it meant. That's definitely a lot better than removing the lights and having to place them again if I decide I need to re-bake the lightmaps

 

Hi,

Just an other question about lightmap in unity 3 b3.
I have see that is possible to change the resolution of the maps with the command LightmapEditorSettings.maxAtlasWidth|Height but is it just for terrain lightmap ?
I have try to write a script and place it in the editor folder but it doesn t work.
Can someone give me a little script example to show me how it works.
Thanks a lot and excuse me for my bad english.

 

You can use both emissive materials and lights (both auto and baked only) at the same time with any limitations. You can even add a sky light or image-based lighting on top of that and everything should bake just fine. In fact, the apartment scene from the lightmapper preview video and the Dark Unity city scene use both lights and emissive materials.

If your still having problems, please post a question on unity answers describing your setup exactly and post the link here - I'll answer the question there so it's hopefully easier to find by the next person bumping into a similar issue.

Sure. The lightmap itself is just a texture. After baking, make sure to move your lightmaps to a differently named folder (they won't loose connection to the scene), because lightmaps in the default folder get deleted for you the next time you hit bake to avoid clutter in your project. What you will also care about is to keep lightmap 'atlas' information (lightmap index, tiling and offset) on every renderer intact, so every renderer still knows which part of which lightmap belongs to him. You can do that by clicking 'Lock Atlas' or by writing a script that will store all this data from the renderers for you somewhere, to be used later.

 

As dreamora said, you should just use Baked Only lights :wink: Or, if you never ever want to have your baked lights to illuminate lightmapped materials, that means you don't really want dual lightmaps. Just switch to single lightmaps in the Lightmap Editor.

No - shadow distance is for tweaking where the realtime shadows begin and where the transition between near lightmaps (and realtime lighting of auto lights) and far lightmaps is.

The shadow distance control that you see popping up in the scene view is only for preview purposes and it only has an effect as long as that small window is visible. The _real_ shadow distance settings live in quality settings and you should adjust them according to how you feel different quality levels should look like.

 

Robert - fantastic! Thanks for all the great answers!

 

Just to confirm I'm reading the scripting documentation correctly it seems that a scene can only have 254 lightmaps loaded at any given time correct?

I'm referring to the bit on Renderer.lightmapIndex

Also...

I have figured out how to access the renderer on each game object and play around with the offset settings. I understand your post about needing to back them up in order to save all of this info after playing around with this =).

The problem I am having though is accessing the terrain light map? It compiles fine but when I run my scene it says that terrain doesn't have a renderer. I can add one but this still does not give me access to the lightmap data. Is the lightmap data accessed on the terrain in a different way than standard objects?

Thanks for the quick replies by the way! One of the things that makes Unity so great is the wonderful support you guys provide.

 

Yes.

Terrain doesn't need a Mesh Renderer. It actually doesn't need lightmap tiling and offset, since it always occupies one full lightmap. So the only interesting terrain property is the lightmap index and you can just get it via terrain.lightmapIndex.

:wink:

 

Oh ok...

I guess to explain what I was trying was to see if I could stretch or shrink the x y paramaters on the offsets based on a directional light's angle up to 90 degrees then change the lightmap to one rendered at 45 degrees the other direction. In this way one might be able to simulate the rising of the sun mid day would be straight down then switch to evening light map for the other 90 degrees and shadows stretching out the opposite direction. Thought it might save on the memory storage of using many various light maps vs just 2 and the overhead in real time.

On a side note..

I tried GameObject.Find("MyTerrain").lightmapIndex and I get a 'lightmapIndex' is not a member of 'UnityEngine.GameObject'.

 

I don't think this would really work... and you can't do it on a terrain.

Well, that's because GameObject doesn't have a property called lightmapIndex. Terrain does. You first have to get the Terrain component and then access it's property.

 

robert, while you're around -

What's the new way to switch lightmaps via script? Especially for terrain. The old terrain.terrainData.lightmap API doesn't exist anymore.

 

Hey Tom,

If you go up to the menu on top of the screen and select the light mapping tool you will see a button that is called Maps. This is a list of the light maps currently being used in your scene. If you click on one (they all look black to me) it will highlight the lightmap file in your resource browser window. I would suggest looking through these files to find which one is your terrain light map. Probably the one that isn't so dark.

Code (csharp):

1.  
2.     // This grabs the # of the lightmap file your terrain is currently using in the lightmap array
3.  
4.     var myInt = GameObject.Find("Name of my terrain object in my case MyTerrain").GetComponent(Terrain).lightmapIndex;
5.  
6. // Here I assign a different light map to the terrain.. In my case my terrain is #12.. So #3 here prob belongs to a rock or something..  
7.  
8. GameObject.Find("MyTerrain").GetComponent(Terrain).lightmapIndex = 3;
9.     yield WaitForSeconds (5);
10.  
11. // Hopefully sets it back to the original file.. Actually didn't work for me as it reset to the #3 when I stopped the scene but.. I just changed the #3 to a #12 since I found it first before testing this and ran it again to fix it..
12.  
13. GameObject.Find("MyTerrain").GetComponent(Terrain).lightmapIndex = myInt;
14.  

I'm sure there is a really beautiful way to do this but this should at least get you on the right track as far as the concept goes..

So basically you can load an array of lightmap files into your lightmap array then when you want to change the terrain or other objects you just reassign the index # of the object's lightmapIndex or just change one of the files in the lightmap array itself. Make sense?

I should mention if anyone wants to chime in here regarding setting up a day cycle script using the new lightmapping system please give it a shot.

How it looks like it is going to work is to build 3 sets of lightmaps for your scene. Then switch these files in the lightmap array based on the position of the directional light as it rotates around your scene. The only other part I need to figure out is how to blend one lightmap file with the next in the cycle with the blend % based on the angel of the sun then put the blended texture in the lightmap array instead of one of the basic 3. This would then at least give a realtime changing shadow effect vs the shadows suddenly changing with a jolt.

 

Hi. I also have dificulties using realtime shadows. I have created a scene, added one directional light (sun) and two spotlights (table lamps). I've baked lightmaps within Unity and the scene really looks great. Now I wanted to add some dynamic light to this scene - for example a flashlight. I've added a spotlight to the scene. It shined normally but when I've made it cast shadows all the lighting from this spotlight dissappeared.
This flashlight is marked as realtime only. I don't want it to be baked into lightmaps because it must be dynamic - like flashlight. I've changed the shadows distance - when it is set to 0 flashlight shines normally but without shadows which is normal behaviour (no realtime shadows behind this distance). But as soon as I change shadow distance just a little above zero - flashlight stops working. No light and no shadows. Setting shadow distance to higher values also doesn't help. No matter what I do, I can't have dynamic shadows from this light (from earlier set light sources shadows work normally). What should I do? I'm using defered rendering and Unity 3 beta 4.

 

Your lighting setup should just work as you expect.

You don't have any object just in front of your flashlight light, do you? A model for the flashlight?

It sounds like a bug, so please use the bug reporter (help->report a problem), attach your scene (or maybe you can reproduce the problem in a simple scene with just a plane, cube and two lights?) and describe exactly what's wrong (just like you did here).

Thanks!

 

I've reproduced problem I had described earlier. It is posted as bug number 367626.
I've also encountered another problem. I've created simple scene, exported it to package and then imported it in another project. Now when I change shadow distance property editor window isn't updating the view according to new shadow distance value - whole scene looks like the value is set to zero (everything still works properly in game view).

 

Thanks for the bug report. Your scene is set up correctly (but since you just exported an asset package, I don't have the full project state) and everything works fine on my machine, but we'll still try to reproduce the issue on an iMac.

About your other issue with shadow distance: this should be working just fine as well. Remember that shadow distance can be changed in two different places: in Quality Settings (make sure you change it for your current quality, otherwise you won't see any effect) and in the Lightmap Display window visible in the Scene View when the Lightmap Editor window is open. The latter is not a 'real' setting - it's just an override for the shadow distance from Quality Settings and it's used when the Lightmap Display window is visible.

 

I can send whole project if it would be easier for You to reproduce the problem - but on my iMac it occured also in new project after importing the package.
And I know that shadow distance in lightmap window is just for preview purposes. But (after importing the package I've created) changing this value didn't have any impact on the scene view window but everything worked fine in game preview window. In scene view shadows didn't change at all, no dynamic shadows or bumpmapping appeared in the places where everything had been all right earlier (in game view changes were easily visible).
I've also spotted another two things which I think are bugs.
First is that in one of our scenes lightmapping ignored some objects. All objects were marked as static and there was only one directional light with cast shadows option set to soft shadows. When I baked lightmaps (not for selected objects but for whole scene) some objects were ignored - lightmap number 255 was assigned to them despite the fact only 5 or 6 lightmaps were generated. These objects were dark, they didn't receive any shadows and they didn't cast any shadows on other object. They were marked as static (I've checked). Also cast shadows and receive shadows was set for them to true. When I've calculated lightmaps only for them they were normaly assigned and properly calculated. So this isn't i.e. texture coordinates proble. I've checked it several times - on other scenes it worked fine. And it also worked properly for fast, preview lightmap calculations. It appeared only when high quality lightmaps were supposed to be generated.
On another scene after baking lightmaps both far and near lightmaps looked exactly the same. And when I set shadow distance to higher value - places that were near the camera (from zero to shadow distance value) were too bright, almost white. It looked like normal, dynamic light was just added to lightmap in which this same light was also stored (in near lightmap direct light should not be stored, right?). Shadows were ok, dark places also looked ok. Only places with dynamic light and where direct light was shinning on were too bright. And it occured also only for high quality lightmaps. Fast, low quality (but with the same resolution) lightmaps worked properly.
I will try to post another bug report but these two bugs occured in our commercial project and it can be problematical ;-). That's all for now ;-).

 

Thanks for all the feedback!

As usual, it would be best if you would submit a bug report, attach your project and then explain exactly what's wrong, because otherwise we can only guess :wink: Especially that everything you describe is a very typical workflow and has been tested by me and our QA many times - so there's a good chance the issue can only be reproduced if we have your project, your hardware specs, etc.

But if I would guess, I'd say that in the first case I'd check what's the rendering path after importing the package - if it's forward, then dual lightmaps and realtime shadows from point and spot lights won't work.

In the second case - didn't you have Lock Atlas enabled by any chance?

And in the third case - well, I'm not sure. I'd have to see your scene. :wink: The rule is that auto lights shouldn't contribute their direct light to the near lightmap. Near lightmaps should contain direct light, but only emitted from 'baked only' lights, emissive materials and sky lights.

If you still think something doesn't work as it should - then it's a bug and needs a bug report

 

1. I've set deferred rendering in Player Settings and - to be sure - I've also forced it in camera (there was info that in forward rendering shadows works only with directional lights).
2. I didn't change Lock Atlas setting - it was unchecked.
3. On the scene I was describing there was only one directional light with rendering set to auto - I wanted dual lightmaps method to work but despite this fact dynamic lighting added brightness to lightmap - not replaced it. It looked like dual lightmaps method didn't work or (as I had described earlier) that near lightmap also contained direct light from directional light source.