koobas.hobune.stream
Can I create lightmaps at runtime?
I'm working on a geo-mod style system, destructible buildings etc. If I change the meshes included in a building, what's the best way I can update the lighting to be realistic and fast? I find the realtime lights a bit jagged for my taste and maybe they're too computationally expensive. I'm guessing I will have to make my own functions for calculating lightmap data and create my own lightmap shaders... I can calculate a bit each frame (I'm doing that for the mesh destruction anyway), then swap out the textures once calculated.
My question is this: am I making life too complicated? Is there an easier/better way? I am thinking of getting Unity 3 Pro - is the realtime lighting of a good enough quality and fast enough to handle this? I do however want to publish to iPhone so I guess I need lightmaps anyway...
So that's about five questions in one!
Any reason this is downvoted/close-voted? Is it a duplicate? The content seems reasonable anyway.
The close dialog shows it's a dupe of this: http://answers.unity3d.com/questions/15311/how-can-i-bake-a-lightmap-at-runtime-using-new-unity-3
Ah - I saw the word bake in Related, thought it was a different process. Shows what I know about lightmaps. :) (also it was about Unity 3).
I did see that question. I don't believe $$anonymous$$e duplicates it - it's related, maybe. I wasn't asking if it is possible to bake at runtime with Unity's own baking tools. I was enquiring about the relative complexity of using pixel lights vs creating/updating lightmaps with my own custom runtime functions.
You are making life too complicated, yes. Unity 3's Deferred Rendering should make using pixel lights much faster, and the quality will be improved from Unity 2
On the other hand, you want to build on iPhone - I'm not sure if deferred lighting will work, but forward rendering should still be faster than unity 2, and look better.
There shouldn't really be any need to bake lightmaps at runtime, which would be excessively slow anyway (Especially on an iPhone if it were even possible, you'd be waiting an hour to get similar results to a few point lights)
Good news about the deferred rendering... however won't I still need to change the lightmaps? I understood that in Unity 3, lightmaps take over at a certain distance.
And on iPhone - when you say forward rendering will still look better, what about the core problem that I need to change the lighting arbitrarily at runtime? I can't just use normal system lights as they go through walls, so I still need lightmaps (don't I?) And they have to change arbitrarily as I blow chunks out of walls.
lightmaps only take over at a distance if you use lightmaps. as for iphone, it's still a problem i guess, but i can't imagine lightmaps helping at all - you'd need to make a different lightmap for each permutation of chunks blown out of a wall. my guess would be to not worry about the light bleeding through, any attempts to fix it would most likely make the game unplayably slow
Ok, didn't realise that first bit. As for permutations, I was thinking more of calculating new lightmaps on the fly. The important point is that I would do it not all in one frame, but with my own custom functions for doing a certain number of lumels per frame, thus calculating the new lightmap over a period of a few seconds. That's what I'm doing for the meshes.
In that case it could work, but it's not going to be possible using the built in lightmapper (Which you've probably figured out by now)
Clicking on your "lightmap" tag, I got this answer as the first. So, with the included methods in Unity, it isn't possible to bake the lightmap at runtime.
What you could do is baking several lightmaps in the editor - one for the normal building, one for the destructed one, and then only swap these textures.
The intention is to make my own procedures for generating lightmaps on the fly - especially as the destruction is not pre-generated...
