Strange lighting when walking on DIF

#1 You can have a look at the option receiveMLlighting which uses the lighting defined for terrains or DIFS to apply to other objects, it can produce some strange effects so try and turn it off/on for the player and see if it helps.

#2 I've searched everywhere in both scripts, source, and GG.com, but there's no receiveMLlighting option anywhere in TGE ^^'

#3 Alright... it was "receiveLMLighting" not "receiveMLlighting", I tried disabling it (in source SceneObject::SceneObject()), but it turns the player completely black :o

#4 Bump... anyone else is aware of the issue? It appears on almost every interiors, I supposed it should be well known...

I tried to put the same difs inside the TGEA barricade demo, and the player is correctly lighted, so it is a TGE only issue, which GG already corrected for TGEA :/

It is really a show-stopper problem, please... TGEA is too expensive, especially if I only need to buy it to fix a lighting issue.

#5 I don't know if its related but I've had weird lighting issues in TGEA when the DIF has been scaled. If your dif is scaled then set it to 100% - relight and see if the issue is still there.

#6 Another thing to consider is to try and use a couple of the DIFs included in the demo. Does the same thing happen? If not, then it might be something about the DIF or the way it is modeled/exported. If so, then perhaps it has something to do with your lighting settings.

#7 I get this bug a lot too, so you are not alone. No idea how to fix it though.

It's actually really discouraging, when you spent a few solid hours on a shape and you get this kind of bug. If I find anything out I'll be sure to let you know ASAP.

P.S.

I've noticed that it seems to happen more with larger sized DIFs. Try breaking your structure up into smaller parts, then putting them together in the editor. It's a bit of a hassle, but it might solve some of your problems.

#8 I'll echo Chris's comment, see if the interior is scaled.

#9 The interior is not scaled, it's default size and all. *sigh*... This bug puts on hold my project until the day I can afford the TGEA upgrade (which I planned to do someday anyway... but still :/ ).

#10 It's doubtful that an upgrade to TGEA will solve your problem, we've got lighting issues with TGEA and DIFs too that didn't exist in TGE so your problems may persist.

#11 I might be completely off with this, but I think the problem is that the DTS receives outside lighting based on the lighting the terrain gets just below it. (You've seen that.) It could be possible, that the terrain is lit differently just below the DTS model, and the DIF is not taken into account at all.

Try moving the dif and see if the DTS becomes dark at the same position compared to the DIF and to the terrain.

Edit:
If that's the case, the fix would be to flatten your terrain beneath the DIF.

#12 I actually encountered this same problem in my recent TGEA port of the FPS Environment Pack.

The player get a different lighting value when stepping on a dts object. Not sure what the solution is for this, but would be very interested to know if some one finds a solution.

#13 I've found this that might shed some light (and confusion):

John Kabus explained DTS lighting in this thread:

Quote:
The directional light source applied to dts objects in TLS is frequently called "environmental lighting", because it doesn't come directly from the sun. The value it extracted from the terrain or interior directly below the dts object and also based on zoning info.

This allows dts objects to receive relatively accurate lighting and shading on the terrain even when standing in another object's shadow. This also allows objects to receive relatively good lighting from static lights that do not directly illuminate dts objects.

I did some testing, and indeed, it does get lighting from a DTS right below it. I made a huge DTS that got lighting from one point of the terrain - probably below the box center, because moving it was shading the huge DTS according to the small light fluctuations on the terrain. Once I jumped off the huge DTS object, my orc was again getting lighting from the terrain even already in mid air. So there must be a ray check in the source for this somewhere.

From what Benjamin wrote, I am thinking that this is not the case with interiors, and the terrain is taken into account instead of the interior below the player dts.

I did my tests in TGEA 1.7.1. I will see if I can find the part where that ray is cast.

#14 Yup, I have done the same test, but what I am seeing does not seem to match the lighting values that would be expected for the particular situation.

My player is getting much brighter than it should, and never gets darker by stepping on a dts that is dark (shadowed).

#15 Unfortunately it is not the case, the terrain does not play any role in the issue I encounter.

Here's an example DIF (with CSX) on which the issue will happen for sure on TGE:
dragon.six.free.fr/cube.zip

#16 Something else popped into my mind. Did you reight the scene? I was thinking that maybe the DIF was moved and was not relit, and maybe relighting is not automatically done when you launch your mission. Just a guess.

Anyway, I've dug into TGEA source, and found the following:

The method getColorFromRayInfo is responsible for getting shadow color from a colliding object for terrains and interiors. This information is then used in the light manager in the method getLightingAmbientColor. It casts a ray from the player's bounding box top center down (100 units long) when the object moves, and checks if there's a lighting interface available for the collided object. If it finds one, it calls its getColorFromRayInfo, and takes the resulting color.

Now, this is really cool, since it is relatively easy to add or modify new interfaces. sceneGraph/lightingInterfaces.cpp has functions for that. Anyway, I've found the following systems registered:

Basic Lignting Interior, Basic Lighting Terrain, Synapse Gaming Atlas, Synapse Gaming Interior and Synapse Gaming Terrain.

This leads me to the conclusion, that DTS objects are not given a separate lighting system, and if the first object collided under the player object is a dts, then no appropriate lighting interface is found, and the object goes with some kind of a default / maybe even random value. I haven't checked that yet. This could be tweaked further to have the ray go through everything except for what there's a lighting interface. But that would not necessarily provide a better results (probably the very opposite).

Benjamin, I've tested with your cube object, and everything worked according to what I just explained. When standing right above the shadow that was projected on the top of the cube, the player model received the color from that shadow, otherwise, it received a lighter color.

So I can only think that it's a glitch in TGE, and that's why I was unable to reproduce it in TGEA. I haven't tested with basic lighting though, so it is possible that the color sampling there does the funny stuff. If you can, you should give your DIF a try under TGEA, and see if the problem you mean can be reproduced there.

#17

Quote:I can only think that it's a glitch in TGE

Indeed, and I'm interested to know if there's a fix for TGE. I use only TGE, and it's a pain to see such a glitch on such an old and "battle tested" engine.

But, if there's also different glitches in TGEA, it's also an interesting matter.

#18 Whether they are glitches or just problems with the models we've created I'm not sure to be honest - unfortunately we've not managed to resolve the issue and the one suggestion we have had to look at the map2dif source - which unfortuantely is missing from the latest TGEA releases so little support there.

#19 I build my DIF geometry in QUARK, then load it into Constructor for texture alignment and light placement. My DIF work great when exported from QUARK(map2dif+ from 2005), but once exported from Constructor(version 1.0.51; Export As Dif option) the DIF was riddled with all types of odd lighting problems and missing face, including the problem Benjamin L. Grauer noted. I found all my problems went away after switching ever DETAIL brush back to STRUCTURAL, and cleaning up some sharp angled 'wedge' brushes, (much like the window boxes seen in the far left background of the 'not good' example picture above).

#20 The issue with the Player stepping on a DTS and receiving the incorrect lightning is, at least in TGEA, because they added another mask bit to the castRay () call in sgLightManager.cpp @ 418 - probably due to the new polysoup code which lets you use DTS as buildings, in which case you'll need the proper mask bit. In our case, we didn't so we removed it and the issues are gone.