Is it possible to move a lightmapped object at run time, if the object is only set to lightmap static?
I’ve tries this and my object seems to lose connection to lightmap. i.e. comes out bright and without affect from the lightmap. before running the game with the object animated it had a clear influence from the lightmap texture.
Hi Alcolepone,
it’s not possible. The lightmap is created offline, while the project is being built. If a static object that is a part of light precalculation is moved, the lighting becomes incorrect.
That… is not true. (or that’s not what he asked, depending on what you mean). I think Unity is confused on this matter.
You can move items that are static lightmapped and nothing else just fine. Assuming you are using fully baked lightmaps. Obviously the lighting will look “wrong”, because it will look how it was in the position it was baked, but you can move it.
Not sure why it seems to lose connection to the lightmap. What are you doing exactly? Which lightmap mode are you using?
That’s correct, I meant that the lighting information will be incorrect if you move an object that was baked into a static lightmap.
I think the OP means something different. He says it loses connection to lightmap (and presumably, becomes unlit).
And while I have your attention, since we agree that moving lightmapped static objects should be totally doable (although it will look wrong), why are you restricting movement in scene view while in play mode for lightmapped static only objects? (I have filed a bug report on the issue, 876174 )
I wouldn’t agree that it should be doable. This is a behavior that breaks something (lighting, in this case), so I’d say it shouldn’t be allowed.
It’s allowed through scripting and it’s allowed through animation, it’s allowed by entering different values in inspector, it’s just not allowed by the handles in scene view, where it would reset when I stop play mode anyway, so there’s really no harm. The only thing it does, is annoy me when I want to experiment with the position of a certain object for a bit and it forces me to use the inspector, instead of just grabbing it and moving it.
Doesn’t make much sense to me.
This is rather a question of behavior consistency. It either should be allowed everywhere or disallowed everywhere.
And as stated in the bug report discussion, someone is going to take a look on that.
Final thoughts on this, because I think I derailed the thread from what the OP was intending a bit too much:
Disallowing movement everywhere would break everyone’s projects. Doing things like shaking a lightmapped mesh, is a perfectly valid use case and it doesn’t really break lighting (all that much). And I can mention you a ton of released games that move around lightmapped objects (including mine). So in my mind, it should just be allowed everywhere.
Artificially limiting what we can do is contrary to the spirit of game development, where we have to employ all sorts of trickery to get what we want.
I guess I can’t let this go yet. Someone is supposed to look at the bug report I made 6 months ago for this pretty silly issue, but at this rate even if someone takes a look at it, I doubt they are going to fix it, since it’s supposedly by design.
Oh thank you Unity for not allowing me the convenience of moving that cup normally. The lighting looks soooo wrong when I move the cup through the inspector, it’s unbearable.
[/sarcasm]
As long as this is not a stability or security issue, this should not be blocked. I understand some people would break the lightmap but Unity is a professional tool for people who know what they should do or not do in this instance.
Right now I’m stuck with a project because of this. :-/
Edit: turn out it was a hierarchy issue. Lighmapped objects were movable in game. 
If you move the lights with the objects, nothing should look broken. Possible use case: moving all the level geometry and lights as one in a floating origin system.
And someone did, and he shrugged as no one has shrugged before and it’s more than 2 years later and Unity still thinks that “is lightmapped” means “it should not move”.
It’s ok, I use ue4 now.
And some did, and decided that you won’t change it back because of “users that rely upon the affected versions”.
Funny that users that relied on this in the first place wasn’t really an issue though. Because that time someone probably did the change by mistake and now no one wants to bother.
I’m going to respectfully disagree here. I regularly have switches, sliders, and dials in every one of my projects that need to be “moved” to change states. As these items only move by ~60°, or ~2-5cm it’s perfectly fine to have their indirect lighting, soft shadowing / AO, and GI baked as they will never (short of an app breaking bug) leave their general illumination area’s.
That said, I still have them cast their primary direct hard shadow via mixed lighting to maintain visual consistency when interacted with for scenes with harsher lighting
With regards to gaming in general, I agree with you though. That baked crate in the corner of the warehouse would look just plain wrong if it were dragged to the courtyard by the player. But for simulation and training ala “real games”, that doesn’t apply as much as one would think because the scenarios and their specific interactions are tightly controlled.
===
On a side note I’d love to just have everything real-time illuminated with hand crafted AO maps applied, however our budgets are a pittance compared to you AAA devs & designers, and not many of your artists make the jump to the training and simulation scene. Seriously we could use talented artists and devs who know how to build optimized 3D.
Granted the pay isn’t as high as say ubisoft (it’s still good), but the hours are generally fixed at 40 per week with very little “crunch”. (1-2ish weeks of 50hrs a year)
So once you get your fill of AAA gaming and never being able to spend time with your family’s, make the jump it’s great.