Just to sate my curiosity, how does the built in light-mapper interact with static batching? Does it obey the materials assigned to the objects?
In other words, if I carefully construct a scene where static batching is optimal, will the light-mapping inevitably interfere with said optimization to some degree? Is there a way to predict where the lightmaps will be an issue for batching?
Thanks all!
-Steve
EDIT: The reason I’m asking, rather than simply investigating this myself, is that I’m about to take the plunge into Pro ownership. I’m merely curious as it’s not going to make a difference either way in my upgrading, but until then I figured it couldn’t hurt to talk about it. I searched the forums and the manual to no avail, so this was my last resort.
Yes, Beast lightmapping respects the materials. You can also bake in the free Unity version, you just don’t get bounce lighting. The performance is the same.
So to be clear, if I have a scene where 100 static objects all share 2 materials, I would have 2 draw calls. If Beast then decided it needed 3 lightmaps to light my scene, I would have 3 draw calls, correct? I’m assuming one of the shared materials would have to be duplicated for those objects that fall into the third lightmap?
well, it works slightly differently. Imagine that due to the phase of the moon you have objects of both materials on all 3 lightmaps - then you will get 6 draw calls at best. But anyway - lightmapping is interfering with static batching only as 2nd texture that can be changed (if i’m not forgetting anything)
Hmmm now I’m confused. If I had my 100 objects sharing 2 materials, I can assign Diffuse and Lightmap textures to each material and still only be 2 draw calls. In my above example if I ended up requiring that third lightmap to say, increase fidelity, I then would simply have 3 draw calls…again assuming I did this all myself in my 3D software.
it will not be 2 drawcalls with 2 materials + 2 lightmaps it will be 4 (2 materials * 2 lightmaps) normally.
the more lightmaps the lightmap generation generates the larget it becomes.
Your level needs to be extremely small or the lightmap very undetailed to end on just 1 and not a plentitude of them.
the tab most right lists you all the generated lightmaps after the baking.
if you use pixel lights that exist at runtime the whole topic becomes even more complex as that causes redraws of affected geometry
With the iPhone/LightmapOnlyShader I get 1 draw call for a single mesh and two texture maps (Diffuse and Lightmap), unless the Statistics display is incorrect?
Otherwise I agree with everything else you said; my specifying the 1 or 2 lightmaps was purely for example. My question is with iPhone development in mind, to be more specific.
Okay haha that’s my confusion Alexey; just to stick with my first example, if I have 2 materials shared over 100 objects (for optimal static batching) I can light this scene with two lightmaps and assign then myself in 3DSMax and have 2 draw calls. If I realized that the lighting wasn’t very good and I needed a 3rd lightmap, I’d create a 3rd material and then simply have 3 draw calls.
You’re saying I’d have 6 draw calls (200% increase) if I used Beast…thats pretty significant. Despite ease of use, and dont get me wrong thats a big deal to me too, it seems inefficient if its unable to utilize the iPhone/LightmapOnlyShader to supply the lightmap texture to the lightmap slot. Beast is taking away what can easily be achieved in your 3D software, and where draw calls are precious (iOS).
I’ll do what testing I can do today to investigate, though be forewarned I have Unity iPhone Basic so I do not have Static Batching.
Not exhaustive of course, but I did a quick lightmapping of a single object with a single material (assume for a moment I did all the batching myself…otherwise it would be made of dozens of objects)…
…anyway with OR without the lightmap, it was only 1 drawcall.
Can I get some real technical information about how lightmapping works in Unity? This material isn’t assigned in the Inspector and at least in this one test isn’t increasing my drawcalls. Cool, but still too auto-magical; I love that it “just works” but I’d also love to know what’s going on.
Lightmapping is taken care of when the real shader is being built by adding the lightmap related entry to the shaders of the materials
as such it won’t impact drawcalls if only 1 lightmap texture is used but it can raise it if more than 1 is being used and if 2+ different lightmap textures end on objects that otherwise would have 1 drawcall as they then no longer use 1 material but 1 per different lightmap texture
On weak hardware lightmapping at worst could fallback to render in a second pass where it would definitely double drawcalls (doubt it though as even iphone 2g has a 2 texture unit graphics chip)
^This. Okay perfect, that’s exactly what I was looking for.
Yea then I’m not so concerned anymore with its impact; obviously I’d expect the draw calls to increase, but as long as it’s not exponential then we’re good.
compatibility and performance especially. Cards that only support 2048 in max are normally very limited in their bandwidth so switching around textures all the time for rendering can result in the much larger performance hit than a few more drawcalls. (performance is a result of the whole mix, not a single thing thats low. I can offer you a 1-10 drawcall mesh thats gonna kill nearly every pc performance wise and mobiles anyway without even blinking)
you have objects of both materials on all 3 lightmaps - then you will get 6 draw calls at best. But anyway - lightmapping is interfering with static batching only as 2nd texture that can be changed (if i’m not forgetting anything)