Possible Performance Gain

[Tels]

I don't think lg_split is on by default.

 

Ah. Would that mean by using "lg_split" "1" the performance would be even greater? (and does it influence your flicker/stutter? could you please try that?)

[Springheel]

Performance would go up, yes, but IIRC the flickering would be worse.

[chilli]

I have been testing this running Knighton Manor. I tried values of 1, 5, 10, 15, 20, and 30 and saw no difference in fps or light gem operation.

 

Next I tried values of 1, 5 and 30 at the beginning of RTTC and still saw no differences at all.

 

I am running a fairly outdated rig (dual core, 2 gig RAM, Nvidia 8500GT) with most graphic options toned down. My average fps swings from 15 to 63

depending on the mission and screen activity. Most missions play fine (with slight choppiness when too many guards are about).

 

I will end my first post with a heartfelt thanks to all the team members who made the Dark Mod possible. It is an amazing piece of work.

[Fidcal]

What happens if we turn off the light gem completely in the menu gameplay settings? Does that only make the lg invisible (like total transparency) but still effectively working - or does it fully disable it with performance gain? Surely that should be some kind of benchmark if so.

[New Horizon]

What happens if we turn off the light gem completely in the menu gameplay settings? Does that only make the lg invisible (like total transparency) but still effectively working - or does it fully disable it with performance gain? Surely that should be some kind of benchmark if so.

 

That only disables of the 'gui' lightgem, which is completely separate from the gem model used to calculate how visible the player is. The model we use for the players visibility is shaped like a diamond and has a bottom and top rendershot taken of it, which is then averaged to determine visibility. To see it, type pm_thirdperson 1 and tdm_lg_player 1

[Baddcog]

I never really though about NOT using the light gem, it was always such a large part of the game. But all of a sudden it sounds very interesting, after all this time I don't think I really even use it, just used to it being there.

 

Would be cool if that also disabled the calculating, if you're not using it why take the performance hit for it?

[Tels]

I never really though about NOT using the light gem, it was always such a large part of the game. But all of a sudden it sounds very interesting, after all this time I don't think I really even use it, just used to it being there.

 

Would be cool if that also disabled the calculating, if you're not using it why take the performance hit for it?

 

If the LG is not calculated, the AI can't use it, so they don't know whether you are lit or not.

[New Horizon]

Would be cool if that also disabled the calculating, if you're not using it why take the performance hit for it?

 

The gui is there to tell 'you' how visible you are to the 'AI' and, in turn, tell the 'AI' how visible 'you' are to them. If the calculation isn't made, the AI won't work.

[i30817]

Is there going to be a option to turn the "visible" lightgem off?

[STiFU]

There already is. Check out the tdm settings in the "gameplay" part.

[i30817]

doh!

[rebb]

After testing this a bit, it seems like only particles with a Depth-Hack setting other than 0 are affected by the flicker-problems.

 

Particles with Depth-Hack 0 work fine no matter which interleave value is used.

 

However it seems like the default value of interleave 1 also affects depth-hacked particles.

They don't flicker, but the Depth-Hack seems to be applied differently than it probably should, at least thats what i saw when placing a smoke particle system on the ground and switching interleave between 0 and 1.

[OrbWeaver]

Interesting find. So presumably the flickering has something to do with the way depth-buffer values are used during and/or after the light gem rendershots.

 

It might also explain why certain effects such as glare are affected, since these could be using the depth buffer to ensure they draw over everything else.

[rebb]

Yeah it looks like the Depth-Hack is actually inverted when the LightGem is being calculated in the current frame.

DeptHack -20 with interleave 1 looks like DepthHack 20 with interleave 0.

 

That must be the reason for the flickering, while the FPS jumps are probably simply the game running faster between calculations, until it hits a LightGem calculating frame.

[Fidcal]

Does this explain why I am sometimes seeing what I thought were texture chugs? (like hitting a wall for half a second then it frees up again.) No flickering. I've set this at 30. I've not had time to experiment turning down the values or off because I am doing so many things at the moment.

[Tels]

Yeah it looks like the Depth-Hack is actually inverted when the LightGem is being calculated in the current frame.

DeptHack -20 with interleave 1 looks like DepthHack 20 with interleave 0.

 

That must be the reason for the flickering, while the FPS jumps are probably simply the game running faster between calculations, until it hits a LightGem calculating frame.

 

Interesting find, we probably can't do anything for the stutter (unless we find clever tricks how to turn things on/off reliable and fast where they don't matter (e.g. particles?) but maybe we can fix the depthhack feature?

[Darkman]

I noticed the same as someone above: every interleave-setting beyond 1 leads to stuttering (visually just looks like lowered fps, even if fps - in fact - rise).

 

However, i messed around a little bit with the interleaved setttings... most changes had no or a bad influence - except a certain one:

I rose the interleaved_renderpasses from 1 (=min) to 2 (=max). Is far as i know, i experienced a constant and noticable fps-boost. I haven't testet this anymore (til now) and i don't know what this exactly does and/or if there any possible disadvantages.

But feel free to test this on your own, maybe (i guarantee nothing ) we can gain some fps without the whole problems at THIS point...

 

By the way, i would be glad if anyone could explain with few words, what the mentioned command exactly does?!

[New Horizon]

I rose the interleaved_renderpasses from 1 (=min) to 2 (=max). Is far as i know, i experienced a constant and noticable fps-boost. I haven't testet this anymore (til now) and i don't know what this exactly does and/or if there any possible disadvantages.

 

Like I said earlier, the interleaved setting of 2 caused massive stuttering on my system. It all depends on the strength of your system. If you're already getting decent framerates, then you're not going to get stutter...but if a system with low framerates tries to use it, there will be stutter because of the free CPU cycles causing the fps to spike up and suddenly fall again.

 

The interleaved setting does the following:

 

The lightgem system has to render a snapshot of the player lightgem model, not the one on your gui, but an invisible one you don't see. At interleave 1, the system takes a snapshot of this gem every frame. At 2, every second frame...and so on. The stutter is a side effect of the gained fps during the free cpu cycles.

 

So far, there doesn't seem to be anything we can do to smooth this out.

[MoroseTroll]

Just a thought (sorry, if someone have already spoke about this): can you, guys, set the affinity of the Light Gem calculation function to another thread? Almost all CPUs of TDM-fans' PCs are multicore, and the Doom 3 itself is a mostly one-threaded application, so maybe such a trick is feasible?

[New Horizon]

Some kind of check to see if the system was multicore would be great if possible. I'm not sure if we can though.

[MoroseTroll]

Some kind of check to see if the system was multicore would be great if possible. I'm not sure if we can though.

Windows has an environment variable, NUMBER_OF_PROCESSORS, which is equal to the total CPU threads (not CPU cores) available for OS. I'm sure that Linux and MacOS have something similar. In Windows, all you need is to check that variable and voila - you may bind the Light Gem function to any CPU thread you want. Of course, there some simple (?) multitask manager will be required in order to implement this feature.

 

So, TDM programmers, what do you think?

[greebo]

The game needs to wait for the result of the light gem rendershot anyway, so pushing this into a separate thread is not gaining anything. Multithreading is only helping if you have tasks that can be performed in parallel in the first place, which is not the case here.

 

Also, I'm pretty certain that the renderer in D3 is not designed to be used by multiple clients at the same time, this surely would mess up the renderer's state / GL state.

[MoroseTroll]

I'm definitely not a graphics programmer, but what if the main (game) thread won't wait for the result of the light gem function, but use the last known one? I mean that the main (game) and the light gem threads would work asynchronously, i.e. the light gem thread synchronously would receieve the rendershot from the main (game) thread, but would return the result asynchronously?

Edited January 27, 2011 by MoroseTroll

[stgatilov]

I'm definitely not a graphics programmer, but what if the main (game) thread won't wait for the result of the light gem function, but use the last known one? I mean that the main (game) and the light gem threads would work asynchronously, i.e. the light gem thread synchronously would receieve the rendershot from the main (game) thread, but would return the result asynchronously?

 

Most of the time is consumed inside Doom3 renderer and OpenGL driver. They are designed only for single-threaded work. It is a crazy idea to make them multi-threaded because they lack any synchronization. (Well, some OS-specific hacks can be used, but they are VERY buggy - I don't want to play TDM with them ).

 

Perhaps AI calculation can be separated from rendering. But it requires redesign of the whole TDM code, I think... So unlikely it'll happen.

 

All in all, multi-threading produces more pain than benefit.

 

 

[Tels]

I'm definitely not a graphics programmer, but what if the main (game) thread won't wait for the result of the light gem function, but use the last known one? I mean that the main (game) and the light gem threads would work asynchronously, i.e. the light gem thread synchronously would receieve the rendershot from the main (game) thread, but would return the result asynchronously?

 

That would not work, because during rendering of the lightgem, the rest of the engine (or most of it, anyway) has to wait, because there is only one GPU and it can do only one thing at a time - rendering the scene, or rendering the lightgem shot.