As you can see in thet image, I have a wall and a door that fits in it, with the same materials applied to both of them. In spite of this, they look different - the wall is a static mesh and the door a movable one, for interactivity purposes. I´d like to have them look the same, since they are supposed to be be same, but I haven´t been able to achieve this yet. Is there anything I´m doing wrong or I should be doing different?
All the lights in the scene are by the way static, except the ones on top of the door, which are stationary.
You’re not going to be able to get dynamic objects to match the lighting of static objects, since the dynamic object can’t use the same lighting it uses a probe of the area to try and get the GI effect. This works fine for things like characters, but for something like a door you have lighting on one side that is very different from lighting on the other side and that will blend the light together in the probe. You can try to make a unique material for the door and adjust the coloring to try and match, but the only way to make it match exactly is to make the wall dynamic as well.
Thanks for your answer Darthviper! I was really keen to know if that was at all possible, but since it´s not the case I´ll try what you just mentioned. Thanks once again!
Old games didn’t use advanced lighting, a lot used vertex shading which would be the same on all meshes. Doors are an especially difficult problem for all games these days since the lighting is so different on either side of the door.
Eeh, no, Quake used lightmaps. Quake 3 used more advanced lightmaps with static GI and still could have matching lighting on static geometry and dynamic geometry.
I guess the trick was to make sure doors/plats are in the position player will see the most (e.g. if the door should remain closed most of the time, that’s the position it should be in when lighting is baking). So when lighting was baked, doors/plats received lightmaps just like any other geometry on the map. So in default position, you couldn’t tell which one is movable geometry and which is static.
Of course when door would be triggered open, lighting on wouldn’t change. At that point you wouldn’t care as it wouldn’t be seen much or would be only seen momentarily.
Dynamic objects would still be affected by 3D lightgrid, so it would help a bit when pre-lit dynamic geometry moved.
The lighting system in Quake 3 is far less advanced compared to lightmass. It’s impossible to match lighting on a dynamic object without doing the same calculations that you do for the static object.
That’s a million dollars question - how could ancient lightmaps baker generate better static lighting than 2016 engine?! (perhaps not better, but more suited for static + dynamic environments)
I’ve worked plenty with Quake 3 lighting system (my game on Steam uses q3bsp maps and q3map2 lightmaps baker app for Quake 3) and I wouldn’t be posting about this if I didn’t know what I was talking about.
I don´t know about Quake, but it´s a shame that something as ordinary as the example I showed above for the door and wall doesn´t have a simpler solution than manually tweaking the door´s material to fit the surroundings. I know Unreal isn´t aimed towards ArchViz, and I´m still fairly new at it, but not having an option to easily match a door to its surrounding static meshes is a little bit of a pain…
Isn’t there an option on the actor called “Light as static” ? I recall the tool tip said it’s specifically made for movable actors. Should do exactly the same thing as what I described in older games.
I did some Jedi Outcast/Academy modding which uses Quake 3 as well and I don’t remember it having all that great of lighting. I’d be surprised to see an actual case where Quake 3 is able to do a dynamic mesh surrounded by static lighting that has the same coloring.
Dynamic mesh (e.g. player) and door/plat aren’t the same things. Doors/plats are BSP (in Q3) and can receive lightmaps. Dynamic meshes (characters, weapons, etc.) can not. So lighting on those won’t look like on the level, ever.
That can work but the issue is that there will be a shadow on the door where it was blocked and it will leave a shadow where it was, and I’m not sure whether it can cast shadows.
It can. Lightmap is not recalculated every frame. So if you have shadow being cast on the door, that shadow will move with the door (or rather, piece of the shadow that is on the door)
It’s a compromise. If you want your scene to look consistent before you disrupt it (open the door, call lift, call platform, etc.), you opt in for Quake 3-like static lighting approach, where it all looks good until you start interacting with doors/plats/etc.
Another way (and that can’t be done in Quake 3, but in FOSS engine that support Quake 3 maps) is to bake ambient and GI, but use real-time shadows. This way even when doors/etc. move, lighting on them still pretty much looks like static geometry and since shadows are all dynamic, you don’t even notice the difference in ambient/GI lighting.
Right, if doors cast shadows, these shadows will stay on the floor once the door opens. You can choose for doors to receive shadows, but not cast them (static shadows that is). I think it works in UE4 the same way.
Have you tried changing the indirect lighting mode to “Volume” instead of “Point” for the door? That should be down under the advanced lighting tab and it should have a name like “ILCQ_Point” with another option called “ILCQ_Volume”.
This should let either side of the door get a unique indirect sample whereas with Point, it will take one average value for the whole object which means both sides see both sides.
(or rather, piece of the shadow that is on the door)