Problem with my light mapping… check the screenshot… anyone know what i can do to fix this? ive tried so much arleady… dont know where to go with the settings.
good uv and large size lightmap would help you.
I’m guessing it’s an issue with not having enough margin between the UV charts.
If you’re using automatic unwrapping for that mesh, go to it’s mesh importer, choose Advanced next to the “Generate Lightmap UVs” option and increase the Pack Margin.
If you unwrapped those meshes yourself for lightmapping, make sure the margin is bigger.
Thanks for the reply. I tried what you said, putting the pack margin to 10 and i even put the resolutions from 15 - 50… i dont think resolution is the issue, but later i may make unity generate 4096 maps instead of 1024 to see what happens.
Anyway here are the screenshots… with some blotchy issues. Any idea what i could do about these… ive tried putting contrast ratio to .05, .03, .01, .001
Nothing seems to get rid of them.
Oh, at first it looked as if the artifacts were of a size of a single texel - then it would be a margin problem. But they’re not, they’re much bigger than that.
In that case it’s probably a similar issue as in your other thread: http://forum.unity3d.com/threads/70637-Blotchy-Lightmap - try my suggestions from that thread (and yea, you can go higher with the contrast threshold than 0.05).
Kurylo3d, I feel your pain 
I’m currently getting the exact same results… increasing the number of FG rays seems to improve it, as does increasing res on the lightmaps (but exponentially increasing the bake time).
It seems to be a discrepancy between the amount of pixels being sampled in beast and the amount of pixels being used as the lightmap in unity… they should be the same but they’re not… some kind of adaptive sampling is going on within beast that is a multiple of pixels (2,4,8,16) of the actual lightmap pixels. Adjusting contrast threshold doesn’t get rid of this. It might be as simple as changing the XML file or settings passed to beast, but the problem definitely seems to be with that.
eg: Make a plane, put a light or emitter next to the plane… set the plane to have a lightmap and set the res fairly low and bake it… you’ll notice that near to the light you get light value changing per lightmap pixel (as you’d expect)… but moving further away towards the darker areas, you can see that the lightmap is res’d down to 1/2 then 1/4 then 1/8 of the original res… this must be some kind of adaptive sampling going on in beast, ie: if difference between 2 lightmap pixels is less than some threshold, don’t subdivide but mark the whole block as the same colour… makes sense. Also makes sense that there must be some way to override this.
Still looking into this but will post again when I find any answers. I’ve got the original beast SDK manuals here so for sure I will get to the bottom of it! 
ok, not a problem with passing params from Unity to Beast. I’ve narrowed it down to this:
Beast outputs EXR (HDR) format files. Unity takes these HDR format images and converts them to low dynamic range lightmaps… so far so good… but when converting from HDR->LDR, unity doesn’t do any dithering, instead just flattening the pixels, per pixel, into the low dynamic range, hence darker areas get less possible brightnesses to be allocated->blotching.
Thats the problem… and it’s a well-documented problem…the solution is to have unity dither the pixels when converting from HDR to LDR. Still looking into that (or you could write your shader to use HDR lightmaps)
A suggestion to UT: You could use something like Wards algorithm for converting the lightmaps from HDR->LDR. That would take a global view of the dynamic range per lightmap, whereas the current implementation seems to be per-pixel, ie: 100% local… quick, but as this is an offline process it should be better. Maybe someone will write an editor plugin to solve this now we know the problem
I should put here for any future searchers, that there are TWO types of blotching when using Unity / Beast lightmapping: one is having the quality set to ‘low’ (and so final gather rays set too low)… that is blotching because there are not enough samples being taken in beast)… this problem is referring to dark areas being blotchy because of low dynamic range - not the same thing).
Ah well, hope this helps
Thanks Chris. I hope they do fix that.
In either case I am done with beast lightmapping in unity. Im going back to turtle and mental ray. Better quality with less hassle. And I could share the lightmaps between scenes instead of having 1 lightmap per scene which is dumb. Not to mention that if you try to lightmap the same prefab in different scenes you totally destory your unity project.Not to mention u can spend a week trying to get a good looking result and never get it.
Beast for unity is plain and simply trash. Good luck to them on trying to make it better. Its a good concept, but its nothing right now for real developers. Too many problems… too many bugs. It shouldn’t have been released yet.
I don’t know … I don’t have Unity Pro but I can’t imagine that the tech behind Beast is another one than in another Engine as it’s 3rd Party.
Still: I don’t think (yet) that the tech itself is trash or unusable. An external renderer shouldn’t produce different results for different programs, should it?
What I wondered was why we didn’t have a more convenient access to more of the settings. Especially with a renderer it’s something to tewak endlessly untill you know what the renderer does.
For example the texture size alone: I don’t understand why somethings as vital as the texture size is hidden via programming from the User. As a producer/programmer/artist I’d expect to know what I am doing. As such I think that access to these feature(s ?) should be vital. I wonder what other settings are inaccessible via the interface inside Unity.
The conversion from HDR to, let’s call it, Clamped Dynamic Range is indeed done locally for a pixel, without dithering. We are using RGBM encoding (which stores the multiplier max(r,g,b) / maxRange in the alpha channel and scales the rgb values accordingly, and the decoding is simply maxRange * rgb * a). The range is hardcoded to 8, but thanks to that the lightmaps can be directly decoded even on fixed function hardware.
Due to the way the lightmaps are encoded the precision in darker areas is actually very high and this is not the problem Kurylo3d is facing.
The walls in that scene seem to be white, so a range of 0-1 with 8-bits per channel would be enough to lightmap that scene - the result will be clamped like that on output anyways. A texture with a gradient from 0 to 1 with steps of 1/255 after encoding to RGBM, storing in an RGBA texture and then decoding still shows the same gradient.
In the screenshot where camera is facing the dark part of the room you can clearly see a checker pattern on the far wall. This is caused by the way Beast’s sampling works and I am convinced that smooth results can be obtained with some tweaking, we saw examples of that in users’ scenes, as well as internally. Please check out Robert’s suggestions in the other thread and let us know how did it go.
The encoding of HDR values is clearly not the problem in Kurylo3d’s scene. If you have a scene where this indeed is a problem, please submit it and I will be glad to have a look.
Unfortunately dithering doesn’t seem like a good idea in general case - where lightmap texels can be relatively big compared to screen pixels.
Note: RGBM encoding is not used on mobile platforms, doubleLDR encoding is used there instead.
You’re right motionblur, we are using the fully-blown Beast.
We are aware of the fact that the settings currently exposed in the UI do not allow for full control, but they should cover most of the use cases.
The lightmapper UI will get some love from us soon and you guys can be sure we heard you, we will ask you for more feedback and give you the flexibility you need.
Currently all global bake settings can be changed via XML file though.
Settings that you do not have access to are the ones changing the bake target to RNM, vertex baking, etc.
Kuba , if you feel like it, please do me a favor and check out the other post located here… my latest results still have problems i attached all the settings i used at that post.
http://forum.unity3d.com/threads/70637-Blotchy-Lightmap/page2
At this point, I dont beleive its possible to get a “correct” lighting result with beast. Just seems like photoshop is required . Please correct me if I am wrong.
Hey Thomas,
Your scene is in fact pretty tricky. The room on the side of the building which is lit only by the light coming through the window is basically what FinalGather (the primary integrator) does not like. To light the darkest corners of the room you need a lot of bounces, which in turn leads to weird brighter and darker spots in the areas reached only by subsequent rays.
There are two solutions that work in your case:
-
Tweak the settings for FinalGather to death. That gives pretty good results.
-
Use PathTracer as the secondary integrator, since it handles cases like that better. This is the preferred solution.
I have attached the XML files with fixed Beast settings. I made the tests at a 3x lower resolution (30), try that resolution as well, no need to waste VRAM
477155–16755–$BeastSettings_1_Kurylo.xml.txt (1.94 KB) - holds the settings you have used via UI. Changes relative to defaults:
- giEnvironmentIntensity - 0 → 1 (turned skylight on)
- fgContrastThreshold - 0.05 → 0.09
- fgInterpolationPoints - 15 → 30
- fgDepth - 1 → 4
477155–16756–$BeastSettings_2_FinalGather.xml.txt (1.99 KB). Changes relative to the previous file:
- fgContrastThreshold - 0.05 → 0.2
- fgCheckVisibilityDepth - 1 → 3 (needed because of the way the geometry in that corner is set up, which is prone to light leaks; you could try a slightly different topology and then switch that parameter back to value 1)
477155–16757–$BeastSettings_3_PathTracer.xml.txt (2.12 KB). Changes relative to the previous file:
- fgInterpolationPoints - 30 → 15 (back to default)
- fgDepth - 4 → 2 (we don’t need that many bounces anymore, the secondary integrator will handle light propagation from here)
- secondaryIntegrator - None → PathTracer
- ptCheckVisibility - false → true
Please use the last two files as your starting point, look at the docs again and tweak it as you please.
Docs: Custom Beast Settings
Again Kuba, thank you for all your hard work and effort! Im sure it wasn’t easy. I am learning a great deal from how you are doing things. I will definently give this stuff a try when I get some free time.
Oh deary deary deary.
Looks like I’m not the only one who has this problem. I’m having major issues with lightmaps using plain base maps. Get that ugly blotchy effect. Funny enough, the same lightmap appears beautiful and smooth in Photoshop elements but blotchy (as in Unity) in Photoshop 4. After reading all the above entries I’m beginning to understand that the problem lies in the internal gradient of the software in use.
And yes, it would be great to be able to access the file that allows me to manipulate the quality of the gradient in Unity. At the moment I cannot get realistic looking walls.