Well, one thing's for sure, I'll be on the edge of my seat waiting to hear back. As you put it, the ongoing issues stutters - regardless of hardware - and the cloud popping are IMO the defining immersion breakers. (Personally, I'd prefer to see volumetric clouds, but that's not likely to ever happen and is best left to another discussion...if you can get rid of the popping, well enough).

Also, as an incentive/appreciation (and this is open to whomever can claim it first), if you provide proof of a way to eliminate stutters and cloud popping entirely, I'll PayPal you $50 with my compliments. Certainly worth it, no question. (Of course, the proof is subject to confirmation...most notably it must be something that can be replicated elsewhere using a proven methodology).

Here's my concern: I believe that the testing method(s) being used often mislead the tester, by making it seem as if the stutters are gone. Let me explain.

Long ago, I recall reading (on a well-respected forum concerned with CFS3, mind you) about the different tweaks which (at that time) could improve CFS3 graphics. Plenty of interested parties, and those tweaks were proven. But the key to confirming whether these things actually worked was to make sure the same test was done every time. This wasn't new to me; as a trained and experienced troubleshooter, I already long since knew the importance of 'apples-to-apples' comparisons when testing different approaches to technical problems. At any rate, the significance of the CFS thread from way back is that it mentions specifically about making sure you're using a test flight that you can repeat at will identically, and that also will replicate the issue(s) you're working on, Obviously, not much point in testing a boat for leaks unless it's in the water; by the same token, you can't properly test for stutters and cloud popping unless you're using a methodology (test flight) that actually has the issue in the first place. You absolutely have to use a flight that, no matter how many times you fly, the same stutters appear - ideally, at the same moment. Otherwise, you have no way of knowing whether they would (or would not have) occurred during follow-up tests.

No one here can accurately say what causes stutters, so logically, the only way to make sure a test will show stutters is if you can see them in the first place - before any changes are made. Then, make the changes you want, re-do the same test and observe for stutters.

Finally - and this is a crucial part: Un-do the changes, and re-do the test. If your test and theory are valid, the stutters will return. If not, then (as I believe has often happened), something else besides your changes is likely causing the stutters to come and go, but it's not being controlled by your changes.

Most anyone learns how to 'swap parts' to isolate technical problems: If you suspect a graphics card problem, swap the card with another card and see if the problem goes away. The mistake that is sometimes made involves (what I call) the 'second swap test'. Put the first card back, and verify the problem does follow the suspect unit. This step is often overlooked, commonly because (if the first swap fixed the issue) then why bother? Well, a lot of things can happen, most notably that the physical act of unplugging/plugging a part ("re-seating") can clean corrosion off contact pins or correct a small alignment issue...plus, if you're following best practices, then the power supply has been removed/reapplied as well...lots of things happen when that swap is made. I can assure you, in 35+ years of electronics maintenance, I've solved far more problems re-seating hardware than replacing it, by probably a factor of 2:1 at least (especially in industrial conditions like dirt, grease, moisture, vibration, temp extremes, etc).

Anyway, I believe that a lack of a repeatable test has resulted in any number of claims to have 'fixed the stutters', where all that happened was testing that - for whatever reason - wasn't likely to show the stutters in the first place. I'd welcome seeing a solution that can be repeated universally - in other words, an actual solution. A solution that will 'follow the swap'.

One other aside: Many here have insisted that the very process of using your machine to create the video is what causes stuttering. I'd be interested in seeing your outcome and thus whether it's possible to record video on a PC without causing stutters. (I am quite sure this wasn't the problem I've seen, as it occurs both when recording and when not, and also the sounds aren't affected in videos that show stuttering most often; though I understand they are different data, it still indicates to me that the stuttering is within the video display from WOFF only).

Edit: It also doesn't make sense that someone can post 100's of videos without stutter, then suggest that recording causes stutter in 1 video created by the same individual, using the same recording process on the same machine, likely under the same conditions...seems rather obvious the stuttering would've been far more prevalent in at least some of the other videos, if the stuttering were actually being caused by the recording process.

I look forward to your result, and wish you the very best of luck.