TalosXT

I see but instead of going for the RED in the first place they could have considered other options.

Hello everyone, I recently watched the RED camera video and it was nice since i stopped wondering what camera LTT uses. However a question answered and two takes its place. 1. From my understanding, LTT always likes to take it to the extremes so why not go for an ARRI ALEXA XT, ARRI ALEXA MINI, or even ARRI AMIRA? Correct me if I'm wrong but XT as I have heard is around $70,000 USD or ARRI AMIRA is which is around the same price of a RED. Plus you don't have to deal with RED charging all those insane prices for cables and what not. I'm only saying this because I think ARRI would have been a better choice for LTT because they are always featuring people (Linus himself) which on ARRI would have the skin looking softer which is one of ARRI's winning points. I always thought RED was used for more action oriented or open environment shooting but maybe that's just me being affected by RED's marketing direction, design and naming choice. 2. Why did LTT continue using RED despite all its problems? I know they made a follow up video with one of their camera operator explaining some things, but to me it just didn't make sense. The guest shooter in the video said its better for post because you can reframe and downsample (which you still could do with an ARRI) and don't get me wrong, but that just doesn't make sense. As far as I can see, LTT is not doing action sequences with characters shooting each other up while the camera man is playing fidget spinner with the camera. Also Linus, if you ever read this thread, it would be amazing to see YOUR opinion about RED after all these videos. Did you change your opinion or do you still think it wasn't the best choice?

While you guys been testing games and making videos and forcibly proving/denying the problem to each other, Me and @SpeedUp10 were actually investigating the issue. Please stop testing games and making videos and start researching. For once we actually know what the problem is however the solution or what causing it is unknown. First of all, Please Please and Please stop making general names for this problem. "Texture Flickering" or "Jagged Edges" will only attract people whose problem can be fixed by reinstalling driver or windows or people who wanna prove to us nothing is wrong. So here is the investigation: We did a bit of research here and there and found out that this problem is something that is happening once there is a camera motion. meaning that a fixed frame is rendering perfectly. therefore we concluded that this is because of some sort of calculation being run in GPU and is being messed with and it takes a few seconds to re-adjust. After a bit of more researching and cross-solving, we drew some connection to LoD Bias. Now LoD bias is a series of calculations that aid the GPU in rendering each object/texture specific to their location in relation to player. The values being yielded by theses calculation also aids the GPU in draw distance and shadow quality (Depending on Shader being used by the engine). Now the APIs (DirectX, OpenGL, VulkanRT) are responsible for this. So I went after articles written by shader programmers wo use these APIs to specifically find the problem since blaming LoD Bias is again too general (LoD bias has alot of more calculations). So we came to this conclusion that this is actually a really common problem in shader programming and thats why simply searching "Texture Flickering" on google wont get you to this. We tried alot of things, even went for RF Noise or radio interference or testing game enigine based LoD bias. Also a clue that helped was that this is all about shadows. this may also come as bit of shock but shadows are what we should blame the whole thing on, and you maybe say that im crazy why should I blame shadows on jagged edges or popping but bare with me im going to prove why. So guys, to shorten this up, the problem is not one but 3: 1. Shadow Acne (Main one) Another common artifact found in shadow mapping is shadow acne, or erroneous self-shadowing. This generally occurs when the texel depth in light space and the texel depth in view space are so close that floating point errors incorrectly cause the depth test to fail. There are a few ways to address this issue. It’s so prevalent, that most graphics APIs provide a means to instantiate a rasterizer state that includes both a depth bias and a slope-scaled depth bias. Essentially, during shadow map creation, these values are used in combination to offset the current value by a certain amount and push it out of the range where floating point inaccuracies would cause inaccurate comparisons. One must be careful when setting these bias values. Too high of a value can cause the next issue to be discussed, peter panning, while too low of a value will still let acne artifacts creep back. 2. Peter Panning It’s frustrating when introducing a fix for one thing breaks something else. That’s exactly what we can potentially end up with when we use depth biases for shadow maps. Peter Panning is caused by offsetting the depth values in light space too much. The result is that the shadow becomes detached from the object casting it. Sometimes the depth bias is so large that it pushes the shadow away from the caster, causing them to appear as though they could be floating. 3. Perspective Aliasing These types of artifacts are perhaps the simplest to alleviate. Stair-like artifacts outlining the projected shadows are generally caused by the resolution of the shadow map being too low. Unfortunately, increasing the resolution will only get us so far. Even at high resolutions, if the viewer is close enough to the receiving surface, tiny stair-like artifacts will still be noticeable along the edges of projected shadows. The solution to this is to use a technique called percentage closer filtering (PCF). Instead of sampling at one location, this algorithm samples several points around the initial location, weighs the results that are shadowed versus non-shadowed, and creates soft edges for the result. TL;DR Stop looking for proofs and videos and game problems and start looking for a fix for Shadow Acne. Trust me when I say this. You fix Shadow Acne your problems will be solved forever. How to fix it? that's the million dollar question.

I have an i7 6700k. hey try this (for testing purposes): Set "Antialiasing - Transparency Supersampling" to any of the Sparse Grid Supersampling settings. Set "Texture Filtering - Driver Controlled LoD Bias" to Off Set "Texture Filtering - Negative LoD Bias" to Clamp Set "Anisotroping Filtering Mode" to "User-Defined / off" Set "Anisotroping Filtering Setting" to x8 or x16 Then try a game like witcher 3 or something AAA. then come back and tell us the results.

how did you check it? Im trying to figure out how to activate it. Is it just a switch in the bios or is there something else to do other than that?

I was just wondering... have any of you guys tested a game on iGPU?

It doesn't hurt to check.

Thanks for posting this. Unfortunately you are experiencing a severe case of filter malfunction. As you can see in the first pic the filter is not being applied at all (You should see a tinted rings of green and red) and in your second pic you are having severe jagged edges. Don't get me wrong, it should look jagged when you lower the bias however yours in more jagged than usual. Technically the first ring should be smoother than that. Can you post a screenshot of your nVidia Profile Inspector settings?

So guys, here's an update after a week of researching: First of all thanks for those who submitted the D3D AF Tester results. I also grabbed some off of internet to see it running on different cards. Second of all, It appears all of us are facing different issues here. Similar symptoms but different kind of problem. But the funny part is that all the problems are affecting LoD Bias and ultimately messing with draw distance. I fixed Witcher 3 a few days ago by forcing nvidia inspector to turn off LoD bias Driver Control, meaning I gave all the LoD calculation responsibility to the Witcher 3's engine. IT FIXED IT (except the CSMs). This means that the game engine is doing it's job correctly however the GPU was interfering with it, and instead of aiding the game in the LoD calculations, it messed it up resulting in shimmering, flickering, Alaising and ultimately CSMs. Now in order to prove the theory, I installed Stonghold Crusader 2 (2014) which uses a cheap engine that rests on Hardware based post processing. The problems were back again. Now why do I think it's different for everybody? This is where D3D AF tester comes in play. let's look at @Zemzemma's. As you can see, the hardware based Anisotropic Filter is smoothing the beginning of the tunnel but as it progresses through it appears as it is warped horizontally. even though the LoD bias is set to -8, the filter is clamping it to 0 (transition from smooth to jagged) but beyond that it can not process. That should not be happening. for me it's a different case. the filter is allowing the the negative bias to pass through even though I've forced it to to clamp to 0. *** NOW this can be because of many different reasons. These LoD problems have DIFFERENT sources and are yielding DIFFERENT RESULTS. But ONE THING COMMON between the results is that it's messing with the draw distance calculations. I'm willing to bet my money that this is the root to all of our problems. I will try to continue researching even though I may not have enough time since I'm a student but ONE thing i'm damned sure of is that there is NO MAGICAL SOLUTION for everyone. Some people can fix it with driver's install, Some with UPS Stabilizer, Some with building a new PC, or some with neither. This is why we can't get to a solid solution for years. @iiNNeX The problem that you're facing is similar to CSM. It's hard to tell since it's a top down camera but that's because the LoD bias cannot tell how accurately to draw the pixels so the computer is making a safe assumption that the shadow is very far and renders it in low quality (AKA realtime low rez Lightmap bakes). It make's it better when the game is dynamically lit (games with a day night system). Have you tried forcing the driver to stop calculating the LoD bias and let the engine do it? (If the engine has that option built in).

I know. I've tried it too. it's wont fix that way. but here's the weird thing. The clamping is not being applied. Doesn't matter what you put in inspector, It just wont do it's job. Here's an explanation on all of this: https://www.reddit.com/r/pcmasterrace/comments/433c5x/can_someone_explain_lod_bias_texture_filtering/

Srsly bro thats totally normal. I've seen that on more than 10 devices (my friends) the only reason your friends is better it's because the blur effect on the picture that gets applied when being transferred thru text or imessage. but thats totally normal.

I may be wrong but LOD Bias is telling the GPU how much AA or AF apply to objects and textures depending on their distance from the screen. All you have to do to help my research is to download D3D AF Tester (http://www.3dcenter.org/dateien/dateien/d3d-af-tester.zip) Open it and set The settings like mine (in the screenshot) also try playing with LOD Bias slider and see how it works for you but at the end put it on -8 and click "Start". A windows will open and try to render the tunnel. After it's done click "Stop" and a bmp picture called "mipband" will be generated. open it up and take a screenshot

Guys, I've been doing a research the past days. The only thing I found that was close to my kind of problem was the LOD Bias stuff. I know this is an old theory and it doesn't make sense why would system mess with the LOD Bias given the fact that changing parts and nuking partitions wont fix it. But for me it's definitely LOD Bias. I suggest you guys try this as well. It wont hurt. just remember to post screen shots of your test. Im gonna start with mine: Download "D3D AF Tester" and play with LOD Bias (Take it to -8) and post a screenshot. also post your generated mipband. Please help me research this. Heres Mine:

I never said throw it away. Rather contrary. This problem is beyond logical but I'm just saying that If it was power, you would see something more like artifacts like giant traingles in the background (Not Z-fighting) or bars on the screen. But then again I might be wrong. Also correct me If I'm wrong, UPS would not serve a purpose but a stabilizer would. UPS is just a battery trying keep everything stable if power goes out.

I don't wanna make double posts but It's worth mentioning. The only piece of software that Is working correctly is Unreal Engine 4 (4.12). I'm a game artist and I work with this software like everyday and I haven't noticed a thing. UE4 has a more performance heavy anti aliasing (Temporal) as well as AO that is generated by swarm agents. I have worked with the post process sliders and there are no signs of flickering or jagged edges, etc. Which is really weird. Since most of my scenes are pure art and not a single blueprint or script running. No AI and all shadows dynamic. While you guys wait for UPS arrive or anything. Can you please check this in UE4? I believe I'm onto something here and I can't figure it out without you guys. Here's the link: https://www.unrealengine.com/what-is-unreal-engine-4 Also I wish that there was a game Technical artist around here. They seem to be more experienced with these stuff as they work with it like everyday in the office EDIT: I just realized that UE4 generated the LODs for everything in my scenes since I never created LODs for my models or textures. Witcher 3 for example uses Simplygon as their LOD backend. So there might be a connection we're missing?