duzenko

Make sure you have r_useFBO 0 Otherwise use r_fboresolution for VSR effect

To all people complaining about low fps. Your SS and AA settings are too high. Example: nVidia 980 Ti is rated at 180 GTexels/sec. 2M pixels (full HD) x 60 fps x 16 AA x 96 SS quality x 2 texels per shadow sample = 368 GTexels/sec required. This is for one light. Multiple by number of visible lights in your test scene. Please lower your AA and/or SS until the math above works for your GPU. If you absolutely want to comment on why max SS quality is 96 please PM @stgatilov. It does NOT make sense to have both AA and SS maxed out. They MULTIPLY. Max SS should ONLY be used with AA off. @stgatilov should we include fragment position in its pixel in the SS tex coord formula? Are normals and view angles same for every fragment on a given pixel? In other words, does the SS formula have the same result for every fragment in a pixel when AA is used? If so, it's kinda a waste to do the same computation for each fragment.

Try SS off or lower quality - does that help with fps? What is antialiasing set to? Is it better with AA off? About sky in the mirror - could it be blend add on the mirror surface? Try making it blend overwrite (not sure what is the correct name)

Fps-wise do you have soft shadows on? How many fps is very sluggish? What are your CPU/GPU?

Revision: 7348 r_gamma in GLSL skipped for lightgem

You say ambient lights contribute to lightgem. The ambient/simple ambient affects brightness of ambient lights on different surfaces - were you aware of this?

If you're talking about lightgem here, I would still like to hear about enhanced vs simple ambient.

Do you mean that simple and advanced ambient (that produce different output color on the screen) also affects lightmap output value?

Not sure what you mean my light brightness. The change I did is about pixels on the screen. Unless AI somehow reads pixels...

Good question. Do ambient lights contribute to lightgem? I think not. @nbohre1more? If so, no change, otherwise lightgem calc output will have to be adjusted accordingly OR gamma shader skipped during lightgem stage.

I don't think so Probably it won't Thinking about that - does it make any sense to have a gamma room in Training mission at all considering new players will have gamma setting on its default value? Do we actually expect different visibility on different monitors in digital LCD era? I think that's what people did on CRT's 10+ years ago.

I'm sure most of you have a custom r_gamma > 1.0. It has an unfortunate side effect that all windows are overbrightened and bleached when you alt-tab from TDM. For that reason I myself have for a long time stopped using r_gamma. However sometimes a map is so dark that I wonder if the author was designating it to be played with high gamma value (e.g. Old Habits 1). I'm going to put a new uniform to the ambient interaction shader that would brighten up ambient lights using r_gamma cvar value. At the same time I will disable device gamma ramp in regards of gamma. "Normal" point lights will ignore r_gamma from now on, as well as GUI's, etc. This will affect the svn version, not 2.06. Another problem this should reduce is color banding. Gamma ramp makes banding more visible due to relatively higher steps between dim color shades. Please comment.

About 4665 (framerate and mouse sensitivity) Does the unlocked fps option make any difference to you? I am asking whoever can notice this problem because I can't.

Maybe leave this for now and return later with a fresh head

The FBO textures might be getting reset with reloadimages. Looks like a bug. r_showShadows always make shadows disappear, but with soft shadows on they also don't produce the shadow volume geometry because soft shadows are rendered off screen. Looks like a bug too.

Intel test (github repo) Map loads - whew! Fps is lower than trunk - 36 vs 46. Second load aborts with error: Not all interactions removed. This was with the last commit before TBB addition. Ignore gl errors shows no impact on fps to me. Console quit hangs in idSessionLocal::WaitForFrontendCompletion

Don't worry about shadow maps, I will look into that myself after trunk merge ... Trunk shows no change in fps with glgeterror skipped on AMD. Will clone your git and give it a try. ... First impressions: buttons in the main menu flickering when hovering mouse over them? ... Rightful Property won't load - stuck somewhere in image load.

The one added in the last commit r_useInteractionTriCulling The two culling functions take a lot of time for me in RP. One is shadow volume calc. Another is interaction tri culling. Both are toggleable now.

Try shadow maps on and interaction tri culling off. Where are you testing this BTW?

We have r_ignoreglerrors, should convert it from bool to int. It kinda makes sense and goes along with the "one-way flow" concept the opengl drivers seem to follow recently. Send commands one way, and don't try to ask driver for any results unless absolutely necessary... From my experience out of the three vendors AMD does the worst job when it comes to caching commands and background execution. Intel is better but it's usually limited by hardware. nVidia has better (faster) opengl drivers than AMD and better hardware than Intel. I may have time tomorrow evening to test on Intel. I also have an AMD 460 at work but it's paired with a 4.5GHz CPU and is usually limited by fillrate (in 1440p)

What do you have in r_fbosharedcolor ?

No, I mean is original warp glitch issue appearing fixed with both of them?

I don't see difference between r_testarbprogram 0 and 1 when r_useGLSL = 1.

Yeah, r_showsmp prints only dots but afterburner shows gpu usage around 80%. Could be driver overhead. One thing we could do with backend, is since we now have this big single vertex buffer, we might want to longer call the five vertex attribs per surface like we do now. Instead pass the calculated surface data offset in the big buffer to glDrawElements? Also, maybe cache uniforms on client, but driver might already be doing that...