Lightmaps on func_brush end up on wrong sides of the brush
I'm having this trouble where I have a func_brush, and somehow each side of the brush shows the lightmap that should (probably) actually belong to the opposite side of that brush, given the lighting environment on that side.
Exhibit 1 (both sides):
Exhibit 2 (both sides):
What can I possibly be doing wrong? More importantly, how to fix it?
All of these images show the brush before it has moved in any manner.
Here's how I have defined these brushes (they are parented to a func_door_rotating, but this is beside the point):
(And door 2 similarly)
(To get full-size pictures, remove "_thu" from the picture url.)
I tried various combinations of those three "shadows" flags, but none seemed to help this problem. I also tried removing the parent func_door_rotating brush (invisible textures) that was the same size and in the same location as the func_brush itself, but this did not affect either. I also tried rotating the whole brush 90 degrees so as to bring the back to the front and vice versa (and then mirroring the texture by changing the scale of 0.25 into -0.25 to keep the door-knob on the correct side), but no, that did not help either.
I also cleared the name of the brush, cleared the parent property, and toggled the "solid bsp" setting, but none of these individual tests brought a change to the lightmaps.
I also moved the brush's core (origin?) to the outside of the brush (so that there will be no entity inside the brush), but the only difference it made was that the surface closest to the core became dark; the other side was still colored (wrongly) as before.
The brushes are quite normal rectangles, with 3-unit thickness along the narrowest direction.
Here's also a picture showing that it's not a case of wrong side of the texture being rendered.
Why have a func_brush parented to a func_door_rotating ? ... why not just texture the func_door_rotating to look like a door, move the origin to be on the side of the hinge and set the correct flags... see here for more info
Also this looks like the brush is set to spin 180degrees (on the z-axis from the centre of the brush) on map start, somehow getting the light map on "the wrong side"..
What direction/how does the door function when opened/closed? Is there something in your map that is making it turn 180degrees.
That was indeed what I first tried, but it resulted in the door being completely black at least from one side. I was only able to bring light to it by setting the "minimum light level" to a nonzero value (but it won't be of correct color). Using func_brush at least brings _some_ light to it... but on wrong sides. (In retrospect, it was quite much the same observation as I did when I tried to move the func_brush's origin outside the box as part of the number of unsuccessful attempts to fix this problem that I iterated in the bottom of my previous post).
That's what I thought as well. But how could this happen? Note that the texture is asymmetric. Any rotations to the surface would be noticeable. Yet when I look at it in the game, it is properly oriented, exactly as in Hammer. Additionally, when I remove the parenting and the door feature, leaving only the func_brush standing there with no dynamic functionality whatsoever, it is still rendered wrong, with no differences to when it was parented to the hinged door.
Hence, the problem is not in the func_door_rotating part.
EDIT: My brush was on the boundary between two floor sections. I now tried moving the door into the middle of a room, thinking that maybe it can't decide which one of the two sectors it should draw light from. Nope, it didn't change a thing. Still getting light on the opposide side.
The only other thing I can think is to check the "inputs" tab to see if the brush is being effected by something that is making it spin.. you might have an "obs_door2* " output from something ...
Or maybe that brush has somehow got corrupted.. have you tried making a new one from scratch?
Does it change if the brush is not a func_brush but just a standard world brush (you can noclip around/through it during testing, to check the texture)
Or try using a different door texture ? Maybe use a func_door_rotating with a parented prop_dynamic set to a door model ?
There are no inputs or outputs to that brush.
When I move it to world (i.e. delete the entity within that brush), it is rendered just fine. When I move it back to entity (func_brush), it is rendered wrong. When I set it to a func_detail entity, it is also rendered just fine. func_detail entities however cannot be parented or moved, so it has to be a func_brush.
I tried changing the texture; the problem occurs regardless of the texture.
There are no door models in Portal 2 that can be used with func_door_rotating or prop_door_rotating.
There is a prop_dynamic of an underground door, but to use it I would need to create func_button stuff to activate it, and it's a nasty way that I don't want to use. (And the door looks different, as well.)
There is a prop_door_rotating model in The Stanley Parable that works really well and which I could import, but appearance-wise it is too glossy for this particular scene.
EDIT: Recreated the brush from scratch, still the same problem.
EDIT 2: It may be worth noting - I just thought of it - that this brush is inside a .vmf file that is included with "func_instance" into the actual map. The func_instance rotates the vmf by angles of "0 180 0". This is done by the puzzlemaker.)
EDIT 3: Yeah... Rotating the entire contents of that vmf by 180 degrees, and then by similarly rotating the object in puzzlemaker, solved the problem.
However, now I have 30 info_overlays that need to be reoriented and reanchored... Because somehow, rotating everything in the map broke every single info_overlay.
Ah! Now it makes a bit more sense... I'm not sure where I read about it but sometimes a "door's" movement direction and/or angles keyvalues doesn't get set correctly when inside a rotated instance. The door faces the direction in the main map that was the angles in the instance vmf. I'm not sure why it happens, but I've seen it in my own maps too. For you this would cause the doors to spin 180 degrees on map start as they default to their "open/closed" positioned (and 180degrees to where Hammer made the lightmap for it).
There is a simple solution though I'm not sure it would work for you. Give the angles and move direction keyvalues a $xxx value. Set a func_instance_params inside the instance vmf and set them up with default orientation values. Then when you use your instance in any orientation other than "normal" in your main map, adjust the corresponding parameters in the func_instance to set the door straight and correct....
Hope that made sense...
I'm not sure whether you are properly registering that I mentioned several times that the problem had nothing to do with doors or anything that moves in general. It was an issue with lightmaps not being properly rendered on func_brush, even if that func_brush has no movements associated with it at all.
@Bisqwit: In my opinion, it's clear that in the moment the map is compiled the brush is at the right position, and therefore the lightmaps stored on your brush's surfaces are the correct ones. But it seems that the first thing that the door does right when you load the map is to turn 180 degrees. Surely the reason is what you both were discussing above about the func_instance's origin relative to the map's origin.
Try to fix that by adding a logic_auto that OnMapSpawn turns the door 180 degrees. Or maybe by turning it 180 degrees inside the instance. You can also try to add a func_instance_origin to your func_instance in the case you aren't doing it yet.
useful tools and stuff here on TWP 
[spoiler]
[/spoiler]