Boiling it down to simple terms: “I want a flashlight!”
I am just now experimenting with Unity’s lightmapping for an iOS project, and so far it’s working well. As this is targeting the iOS, I’m only using a single light map.
I don’t have much additional lighting, but I do have a few VFX interactive lights, the main one being the equivalent of a flashlight. I was expecting this to work alongside the lightmapped objects, but I can’t seem to find the proper set-up for this. The built-in lightmapping seems to just ignore any lights on objects that are lightmapped.
Am I missing a set up?
Can I take these generated lightmaps and use them with a different shader?
On the other hand, this setting seems to be global and shared. If the developer decides to use forward rendering on the iOS, do they need to set this in one of the other build target windows?
I also can’t seem to crack what the Lightmapper is actually doing or where it’s saving the uvmapping. Is this exportable? Can I bake my levels in Unity and then utilize the maps and coordinates with a different shader that will be effected by dynamic lights?
Will I have to look into lightmapping externally? This seems a shame…
On mobiles there is no renderpath setting cause there is none to set, its always forward given you are on OES 2.0 (mobiles don’t support dynamic shadows at all and alike, so there is little reason to use deferred. Also it would be worlds to taxing). With ARMV6 targeting its vertex lit only as there is no shader support then and thus also no forward rendering or pixel lights.
The UV mapping done on mesh import (depending on if you allow it or not in the mesh import settings) and then stored in the engine mesh representation generated from the mesh you import.
The lightmap shader code itself is added as part of surface shader compilation, so all surface shaders that don’t disable it basically support lightmaps, no extra work required and any surface shader you do yourself will go that path.
If you write an own non surface shader or glsl you could potentially add it, there are a few threads on the matter of how / how not to try doing this from what I recall, unsure on the state of that knowledge and possibility though, as I didn’t need it so far.
I’ll be the first one to admit that shaders are not my strong point.
I understand now that the lightmap shader code is added by Unity during shader compilation (this makes sense, and I suspected something like this…), but…
I don’t understand one point, which could be from my lack of technical experience:
Does this mean that: “No surface shader with the Unity Lightmapping code will accept additional dynamic lights on the iOS”? That’s what I’m reading. Did I misunderstand? (Sometimes I need to be hit with the information wrapped around a brick to get it into my skull…)
Can you imagine anyway I can use single-pass lightmapping and a dynamic light as well? I don’t seem to be getting this in any case I can come up with in the editor.
Can some one comment on whether there is any value at all in experimenting with a pipeline that includes external lightmapping in a 3D package, importing this lightmapped model/texture pair into Unity and using a texture/shader combination that would accept dynamic lights on top?
I’m struggling a bit as game play and level design have been (so far) based on the concept that I could have dynamic lights in the scene. Lightmapping is so effective on very simple geometry that I’d loathe to give up the beauty pass for a technical reason.
Incidentally I’m researching the very same thing. I want a flashlight in my iOS game too!
Today I also experimented with a blob light projector, which seems to produce acceptable results in combination with Unity-lightmapping. However, the contrast is a bit poor since the multiply of the lightmap will usually drown the additive blob. There’s a lot of black and a little grey this way, but no white.
Simply duplicating the light projector does increase the effect, but it also affects performance of course.
Will keep an eye on this topic, and if I find anything, report back!
After finally getting your real intend and problem from the last posting I did some tests:
I didn’t have any problems to make it show up and brighten up an otherwise dark area.
so here a short summary of what I have:
Requirement for it was, as mentioned previously: ARMV7 targeting, Light marked as realtime (don’t think it has an impact but I own U3 iOS Pro). If you want to see it in editor, don’t forget to change graphics emulation to OpenGL ES 2.0 (2nd from top) the rest won’t show it cause they have no pixel lights
Shaders were simple default diffuse. Ensure to not have vertex lit shaders cause vertex lit ignores pixel light by definition and design
lightmap was a simple beast lightmap, 50 texels, single directional light generating it
It was the original shaders. They are set to vertex lit. I made the assumption that once they were lightmapped that it was the lightmap shader that took over… but as you pointed out above, if it’s tacked on at compile-time, then yes, it wouldn’t show.
I’ll hop back on and give that a tweak and check. (Testing is slow going with tweak, render, wait…)
Which is good! (Means older phone owners are screwed in one fashion or another, but …)
And the light mapping is looking good. Test geom and a simple brick texture, map it, and it shows promise! Still working out the subtleties of the pipeline.
Thanks dreamora, I guess I was trying too hard. Went back to basics, and indeed it works perfectly out of the box! Really cool stuff, can’t believe it’s so good on iOS! =)
One warning though: keep in mind that each object thats touched by light is redrawn a second time for this purpose. So you will want to limit the light range correspondingly or only make it affect rather simple objects with no transparent / transparent cutout material.
As for older devices being screwed: actually not, cause there it will run on vertex lit which you discovered to work, within its limits naturally (vertex density).
The main prob with older devices can become the lightmap itself as on pre 3GS, you have 22-23MB at max cause the VRAM is limited to 24MB and the rest goes into backbuffer, frontbuffer and depth buffer.
With newer ones its not limited to a fixed amount, it could use the whole RAM.
I guess what I meant about older devices being screwed is that, as my game currently expects (really requires) this lighting effect, otherwise it’s really unplayable. On older devices, I’ll have to somehow detect what device is running and disable lightmapping. Even though the device will run in vertex mode, it seems that is runs in vertex mode with lightmapping on which leads us full circle back to the flashlight not working.
