TSE Lighting System Q&A

#21 Hi John,

Me again learning about the lighting system. Is the following a bug? If I select a light in the inspector window and then open the lighting GUI, the GUI does not pick up the settings for the selected light. I can find no way to get at the settings I made in the GUI when I first created the light. There are a few settings (such as the datablock) visible in the inspector panel on the right, but most are not available.

Thanks,

Dave.

#22 The Light Editor edits light datablocks, not light objects (see the TDN section for details). It could be setup to pick up the light's datablock when selected, however selection in the mission editor can be difficult in heavy scenes, making auto-switching a bit frustrating.

#23 That makes sense. I was trying to get the light selected and expected the datablock to pop up in the listbox after the light was selected. But of course as it's the datablock that controls the light(s) then it's the datablock that gets selected first. OK, slow brain catches up with real world for a while. Thanks John.

#24 Having a "get selected light" button on the gui would help. Would be much easier to use.

#25 I have a question about the self-shadowing rendering: is it done by masking the lighting, or by darkening the shadowed areas?

#26 The shadows are rendered in a separate pass, darkening the objects they cover.

#27 I'm having some difficulty tracking down sgShadowTexture to what it does during runtime.
I get what's going on in its class, just having difficulty tracking down where it fits into the rendering process.

#28 sgShadowTexture is the shadow buffer used by sgShadowProjector (the shadow class). It's wrapped in a container class, so sgShadowProjector can easily reference a single object and some basic lod info without acquiring an entire lod chain of textures (this saves considerable texture memory especially when distant objects come into view, as the highest lod levels are not needed).

The acquire/release calls are pulling shadow buffers from or putting them into the texture cache, this minimizes the overhead when creating/deleting texture objects ('cold' textures are eventually deleted from the cache, 'warm' textures continue to get reused).

sgShadowTexture is directly referenced when set as the render target and shadow texture.

I'm not sure if this was what you were asking, let me know if it helps.

#29 Perfect. Thanks.

#30 Updated.

#31 John, do you still recommend using map light entities? Or are we to the point where the TSE's static lights look better and perform well enough?

#32 I am wondering the same as Eric. I saw those light entities being used in the TSE demo and I have no clue what they do VS TSE's normal lights.

Also, is it intended that dynamic lights do not cash shadows and that they go trough interior walls? I'm not sure about the former, but the latter is definatly the case.

#33 Stefan, I think if you mark them as zone lights they won't go through the walls. Mine don't anyway.

#34 Hi guys,

Great question.

(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 tryout the entity and mission lights yourself to see which you feel more comfortable and efficient using.

#35 Stefan, check out Zone Lighting it limits lights to the contained zone. Dynamic lights only cast shadows from DTS objects right now, but those shadows do cast onto all object types (including other DTS objects and themselves).

#36 Question: is there a safe way to make the shadows darker, without hacking the shaders? They look too subtle in our game.

#37 No, but that is actually the second request for darker shadows I've had, so I'll definitely look into it. There is already a shadowIntensity in the ShapeBase datablock, but it only lightens. I can try and extend the property to darken also.

#38 Ishbuu, I've added a slight delay to the DRL exposure, which gives a more natural and gradual change. It should go out in the next code drop, let me know if it seems to help.

#39 John, thanks for the response. Maybe consider adding that to TDN?

#40 Very cool! Thanks a bundle John, would help to know when the next code drop is. I also would like a variable shadow level type thing, would be a godsend.

[Ishbuu]