Strange lighting when walking on DIF
by DragonSix · in Torque Game Engine · 10/08/2008 (11:55 pm) · 30 replies
When I move the player on terrains, lighting is acting right, it fits with the sunlight brightness.
But when I walk on open outdoor DIFs, the player become almost black at some bright places without any logic.
Like that :
The players lighting becomes suddenly dark when it shouldn't (this picture is on the same DIF, same mission, same sun exposition, but in too different positions).
How can I fix this issue?
But when I walk on open outdoor DIFs, the player become almost black at some bright places without any logic.
Like that :
The players lighting becomes suddenly dark when it shouldn't (this picture is on the same DIF, same mission, same sun exposition, but in too different positions).How can I fix this issue?
About the author
#22
Can you please show where the new maskbit for polysoup dts is added? I've been searching for it to no avail.
I've seen that mAvailableObjectTypes bits are only set through a scene lighting interface's addObjectType method, and calls to these are only made when these interfaces are initialized, and they are: interior, terrain and atlas.
I could not find any reference to this in the polysoup code and even the entire source. What am I missing?
10/24/2008 (1:40 am)
@Stefan:Can you please show where the new maskbit for polysoup dts is added? I've been searching for it to no avail.
I've seen that mAvailableObjectTypes bits are only set through a scene lighting interface's addObjectType method, and calls to these are only made when these interfaces are initialized, and they are: interior, terrain and atlas.
I could not find any reference to this in the polysoup code and even the entire source. What am I missing?
#23
Before the raycheck, I check if the actual object is a large object. For large objects, I do not take the color from the terrain or interrior, instead, I check if the sun is occluded within a reasonable distance by another large object, and apply ambient color on the dts accordingly. This results in a much more realistic ambient lighting for large dts objects.
10/25/2008 (12:58 pm)
@Todd: I've came up with a simple solution for the DTS shading problem. Before the raycheck, I check if the actual object is a large object. For large objects, I do not take the color from the terrain or interrior, instead, I check if the sun is occluded within a reasonable distance by another large object, and apply ambient color on the dts accordingly. This results in a much more realistic ambient lighting for large dts objects.
#24
10/25/2008 (1:27 pm)
I didn't bother with that, just checked our old 1.03 based version and made sure it worked by setting it directly. Like TerrainObjectType | InteriorObjectType - whatever. Just used the bits we needed.
#25
10/25/2008 (1:32 pm)
@Stefan: I see. There's no DTS sampler for the ray cast color picking, so I did what I just wrote, and it works even better as it would with the original raycast, so I guess I'll stick with this for now. Thanks anyway! 
#26
Good job guys. I only understood about a one third of that, but I get the idea.
I will definitely keep this in mind for future releases.
10/25/2008 (2:01 pm)
@ Konrad and Stefan,Good job guys. I only understood about a one third of that, but I get the idea.
I will definitely keep this in mind for future releases.
#27
11/01/2008 (12:39 pm)
Still no one has anything about the TGE lighting issue? It is a show stopper and yet nobody seems to want to acknowledge it's existence... Especially NOT GG :/
#28
As you've seen, I've tried to reproduce it, but it's not present in TGEA. However, all hope is not lost. I think there are many hints in this thread - where to look, what to look for - that you could trace the problem back to its roots - and maybe even present other TGE users with a fix. Granted, the lighting of TGE and TGEA is a bit different, but I don't think it's that different, because I believe that both use lighting interfaces.
Try narrowing the problem down to a directory in the source. Lighting, interior are the keywords you are looking for. I am not familiar with TGE's directory structure. Find the functions getLightingAmbientColor and getColorFromRayInfo (or something similar - though I doubt their names were changed). Don't forget that you only need to check interior light sampling, so don't bother with other interfaces (the only other being "terrain" probably).
You need to go over each line in those functions, see how they relate to each other, and make sure you understand what they do. Then you're gonna have one of those heureka moments, and from there, it's a straight way to fixing your problem.
Edit: It is possible that your exporter is acting up, so maybe try using another version before diving into the source.
11/01/2008 (1:43 pm)
@Benjamin: I don't think it's about not wanting to acknowledge the lighting issue. It's that you could either find info about it somewhere, or that it's not something you couldn't fix yourself.As you've seen, I've tried to reproduce it, but it's not present in TGEA. However, all hope is not lost. I think there are many hints in this thread - where to look, what to look for - that you could trace the problem back to its roots - and maybe even present other TGE users with a fix. Granted, the lighting of TGE and TGEA is a bit different, but I don't think it's that different, because I believe that both use lighting interfaces.
Try narrowing the problem down to a directory in the source. Lighting, interior are the keywords you are looking for. I am not familiar with TGE's directory structure. Find the functions getLightingAmbientColor and getColorFromRayInfo (or something similar - though I doubt their names were changed). Don't forget that you only need to check interior light sampling, so don't bother with other interfaces (the only other being "terrain" probably).
You need to go over each line in those functions, see how they relate to each other, and make sure you understand what they do. Then you're gonna have one of those heureka moments, and from there, it's a straight way to fixing your problem.
Edit: It is possible that your exporter is acting up, so maybe try using another version before diving into the source.
#29
11/02/2008 (3:11 pm)
I fixed the problem with my DIF's. Any/all brush that exhibit odd light problems in a runtime test, i select in constructor, copy, past back in same place, edit new past brush and old brush in an effort to create TWO brush in place of the one brush surface that generated the problem. Basically try to manually control where brush seams are created. I have found this simple fix work for every oddity i have found, even the occasional missing face. After a few days fixing my old DIF's i see a pattern, and most often the errors spawn from my not understanding how to build most effective Torque DIF geometry.
#30
I'm no good in C++ for now, but I will surely try to do what you suggest anyway, because I can't do anything else now... and this was supposed to be a stock feature... :|
@Caylo
Yep, it does sort out the issues, but your solution is only realistically doable for relatively simple structures. Dividing and testing more complex grounds is waaay too much time consuming for what it's worth. I will try to find a more radical solution.
Thanks to you both for your suggestions ^^
I was assuming that TGE 1.5.2 was the most robust, but it seems I was deadly wrong.
11/11/2008 (11:11 am)
@KonradI'm no good in C++ for now, but I will surely try to do what you suggest anyway, because I can't do anything else now... and this was supposed to be a stock feature... :|
@Caylo
Yep, it does sort out the issues, but your solution is only realistically doable for relatively simple structures. Dividing and testing more complex grounds is waaay too much time consuming for what it's worth. I will try to find a more radical solution.
Thanks to you both for your suggestions ^^
I was assuming that TGE 1.5.2 was the most robust, but it seems I was deadly wrong.
Torque Owner DragonSix