Where Tds Went Wrong

[sparhawk]

All I know is that its checking every light in the level, that is a big problem IMO because as the level size increases, so does the load on the lightgem code.

 

Do you even read what is answered to your postings or do you simply answere to what you think was written??? I already said it a hundred times that there is no code that checks every light anymore because THIS CODE IS NO LONGER IN USE!!!

 

I'm sure Spar will find a way around that.

 

That's the proof. You are apparently an automatic answering machine, that went wild, while it's owner went out for a prolonged vacation (or he was driven nuts by you).

 

I ALREADY FOUND A WAY AROUND THAT WHICH IS THE CURRENT IMPLEMENTATION!!!

[sparhawk]

@Ishtvan - Are you saying the render snapshot method doesn't check every light in the level?

 

I see light at the end of the tunnel.

[bob_arctor]

Can someone explain in really simple terms what the system is now and whether that's good or bad?

Does that mean you can't have animated lights in TDM or something?

 

:S

[Ishtvan]

The new lightgem method is based on a snapshot image (actually two) of a testmodel in place of the player, so we can see how light falls on the model and set the lightgem accordingly. It's very accurate, but the tradeoff is that it has some impact on performance. Until Id releases the renderer source though, it seems to be the best we can do. You can use whatever animated textures you want and this lightgem method will pick it up.

[sparhawk]

Can someone explain in really simple terms what the system is now and whether that's good or bad?

Does that mean you can't have animated lights in TDM or something?

 

The current lightgem works flawless and will recognize ANY kind of light, regardless where it comes from. Animated light, particle effects, ambient, etc..

[OrbWeaver]

The new lightgem method is based on a snapshot image (actually two) of a testmodel in place of the player, so we can see how light falls on the model and set the lightgem accordingly. It's very accurate, but the tradeoff is that it has some impact on performance. Until Id releases the renderer source though, it seems to be the best we can do. You can use whatever animated textures you want and this lightgem method will pick it up.

 

It is actually a very good design - using the game's own render code to process animated textures rather than having to re-implement everything and attempt to match what the game is doing.

 

The drawback is in the implementation, due to an underlying limitation of the game code which only allows the rendered image to be passed back over a local socket (which is not a high-performance way of doing things). It doesn't seem to present any problems so far though, in fact for me the lightgem feels a lot more responsive in TDM than in any of the Thief games.

[sparhawk]

The drawback is in the implementation, due to an underlying limitation of the game code which only allows the rendered image to be passed back over a local socket (which is not a high-performance way of doing things).

 

Performancewise this is not really a big problem, because the socket is pretty fast. The major problem is that the image has to be retrieved from the gfx card memory, which is awfully slow, and has the biggest performance impact. In the first version I was writing the image to the disk and the speed was the same as before. But if you don't get the image from teh gfx card, the framerate will jump up drastically. I'm not 100% sure if teh rendercode will really help that much, because it depends on how much calculation is done on the CPU and how much on the GPU. If the access to the rendercode shows that the required information is calculated inside the GPU it can not be improved much.

[OrbWeaver]

What resolution are you using for the captured image? Presumably it can be quite small if all it is doing is calculating a light level.

 

Perhaps a tweakable option could be provided to adjust the resolution for lower-performance users?

[sparhawk]

I'm using 16x16. But the resolution doesn't help that much. Of course ther is a difference wether I use 16x16 or 1024x1024, but when I developed it I played aorund with it a lot, and for example it doesn't matter wether you use 16x16 or 128x128. I don't know if you know about VGA programming, but frmo my days when I looked into this I knew that retreiving data from the card always was slow, because of the interface design. There is a huge bottleneck there, and the AGP port improved this, but only in one direction. GFX cards a re designed to push data into it fast, not getting it out of it.

[Domarius]

Lol, if you had have told me that the current implementation was not checking all lights in the first place, we could have saved a lot of time. As far as I knew, the current implementation was still checking all lights, and I kept saying this from the start. So all you had to do was update me

 

After a re-read, it seems you were talking to me about the old light gem code the entire time. No wonder you had me thinking this was still the case.

[sparhawk]

After a re-read, it seems you were talking to me about the old light gem code the entire time. No wonder you had me thinking this was still the case.

 

I mentioned that this is about the OLD lightgem code, and you asked me how it worked. So I answered it, but it seems you were thinking that this code is still in place, despite me saying several times that this is not the case anymore.