Questions so good they needed their own home

At times I'm asked tough questions that end up with involved answers about lighting theory, work-flow philosophy, and the meaning of life (well at least lighting and work-flow). I'm making an effort to preserve the questions and answers here, so everyone can benefit from them.

Do you still recommend using map light entities? Or are we to the point where the TLS static lights look better and perform well enough? -Eric Forhan

(Just a note before I get started; everything that follows is in regard to static lighting - entity lights are static, so I'll keep the comparison apples-to-apples. For dynamic lights you need to use mission lights.)

The big win entity lights see over mission lights is in relight performance - entity lights (which are created and saved in the map file) are calculated when map2dif compiles the dif and are not recalculated during relight (the lighting is baked into the dif).

Mission lights on the other hand do get recalculated during relight, so adding mission lights slowly increases the relight times. However mission lights also take advantage of the Torque Lighting System's lighting models, and any additional models you create - entity lights look very flat in comparison. Also mission lights can directly illuminate DTS objects, have lens flares, and are easier to edit - because you can edit them in-game WYSIWYG-style.

Also with the newer relight tools like the quality options, filtered relight, and the ability to disable shadows, the relight times are not as much of an issue as in the past. Though if you're using one massive or several large difs even filtered relighting won't help much as it only filters on the object level, so large difs mean coarse-grain filtering (the quality and shadow controls still help in this case).

Regarding memory usage; both entity and mission lights use the same light maps, so neither one increases or decreases the light map memory usage - that's determined by the map WorldSpawn property light_geometry_scale.

Another issue that can occur when using mission lights is increased mission load time due to a large number of datablocks. Torque streams all datablocks to the client, not just those used in the mission - and each takes up network bandwidth and time. A large number of light datablocks will increase mission load time. I've seen a few projects with literally a hundred+ light datablocks defined, which definitely impacts load time.

I try to make my light type decision on a case-by-case basis. If I'm going to reuse an interior several times it's often easier to rig the secondary and background lighting using entity lights and then setup the key lights in the mission. If the interior is unique I'll often go for all mission lights as they provide the best control over the scene.

I always rig the key lights, and any fill lights (in this case fill lights meaning indirect lights used for a radiosity feel) using mission lights. The entity lighting model just doesn't cut-it for key lights, and fill lights require too much adjustment, which requires constant jumping in and out of Torque.

With Constructor I think you'll see the trend toward mission lights swing the other direction - it's easy to rig most of the lighting in Constructor as you get constant visual feedback, the lighting looks nearly identical in-editor as it does in-game, you can add static meshes, so more of the 'mission' is contained in the dif, and it's all done using a more traditional modeling interface, which can be much easier to use.

But keep in mind this is based on my experiences, definitely try out the entity and mission lights yourself to see which you feel more comfortable and efficient using.