MammyJammy

The process is likely different for various aircraft, but if you know what you're doing to configure the ISG gauges, the following may be helpful. I've spent significant time getting the JustFlight DC-10 working in the x64 versions of P3D and have published a lengthy guide for others. A section of this guide includes converting the DC-10 to an pseudo MD-10 using the ISG gauges, including the Smiths FMS. The following links may be helpful to get things set up in P3D v5: Post in the DC-10 thread with some helpful advice actually installing the ISG gauges into P3D v5: And another link to the DC-10 upgrade guide. The ISG info starts on page 38 (linked from the table of contents): https://www.dropbox.com/s/huvhow2w1q4ypv4/JF_DC10_Install_Guide.pdf?dl=1

Both are needed for any and all texture conversions. The only thing that will change between sims is the source folder you point it at when you run the Texture Optimizer.

I made a purpose-built texture optimizing tool for P3D many years ago and have adapted it for the 64-bit versions of P3D and also MSFS. I originally built it to handle the massive amount of AI liveries I have, but have broadened it to be far more general purpose. You can use it for almost all the texture formats that are used by either P3D or MSFS, including scenery. Just set the source folder to the "texture" directory in the scenery you want to optimize. This way you can leave your P3D setting alone if it's just one or two sceneries that cause issues. It's not for the faint of heart, but if you know your way around your flight sim install, it can be a helpful way to lower your VRAM footprint and CPU cycles for large textures. It's non-destructive and creates new textures in an optimized folder that you can rename. NOTE: You can NOT redistribute textures generated by this tool without the express written consent of the original texture author(s). For personal install use only. You can see the directions for install and use, and download it here: https://izn-flightsim.s3.amazonaws.com/textureoptimizer.html And the longer post on the MSFS forums here at Avsim is here that has more detail about how it works:

Hi All, I've just published a new version (1.4) of my Texture Optimizer tool. This version fixes the processor architecture issue that was causing smaller images to be incorrectly processed. Requires uninstall/reinstall of the Texture Optimizer. The directions are available at: https://izn-flightsim.s3.amazonaws.com/textureoptimizer.html. NOTE: If you have Compressonator and TexConv already installed, you do not need to reinstall them. Change Log: New Features: New optional parameters for resizesmaller and reformatsmaller that allows for custom control of how smaller images are handled. Continued performance enhancements Bug Fixes: Architecture fixes to support proper handling of images smaller than the target resolution that is specified. Please read the linked guide for information on how the tool works, including the new optional parameters. By default, images smaller than the target resolution specified will not be resized, however they will be reformatted according to the processing specified when it is run. If -dxt is set to "auto" (or left to default...It's a purely optional parameter), smaller images will be reformatted and mipmaps added as determined by the algorithm. Said another way, -resizesmaller defaults to false, -reformatsmaller defaults to true. I would highly recommend leaving these as they are. I haven't tested this heavily...I don't have time. I ran it against an FSLTL package and it seemed to work fine. YMMV.

It appears there's a small bug in how image metadata is being captured prior to processing - Likely emerged when I changed the processor architecture to speed it up a few revisions ago. It's not a terribly difficult fix and I'll get to it when I have some time over the next few weeks. I'll add a new switch to the config to allow for forcing all vs. skipping smaller as well. What were the errors captured in the error log? They would be helpful in identifying any improvements to the compression algorithms being used.

Having logged many, many, hours in the A330, I've had a similar issue with long haul flights as well. After digging around on this for some time, it appears (at least on my system) to be an issue with the weather radar. The challenge is that even if you turn off the weather radar on the panel, it will still run in the background. I found this solution buried in the Aerosoft forums, which has been helpful to me. I've posted it as an optimization on my affinity calculator - Click on "Beyond Affinity Masks" -> "Prepar3d Addons" at the bottom. https://izn-flightsim.s3.amazonaws.com/affinity.html The weather radar in the Airbus series can also cause frame rate drops, particularly during long-haul flights. By default the Aerosoft Airbus will run the weather radar in the background, regardless if it is on, which on some systems can cause a memory/loop processing leak. Navigate to the directory into which you installed the Aerosoft Airbus. From there, go into the "Data" directory and open the file named "AB_ND_GDI.ini" Add this section to the bottom of the file and save: You can change the WXBackgroundScan to 1 if you prefer a limited scan and see no degradation in frame rates.

Right-click on the drive itself from Windows Explorer and choose Properties. Check the bottom two boxes from the dialog screen. It should look something like this: On a fresh Windows install using NTFS, I'm pretty sure (but not 100% certain) that it will default both compression and file indexing to on (checked).

I would encourage you to read the section at the bottom of the calculator that explains what each of these things are, particularly the Thread Schedulers. Each of those can be assigned to a single core only, and depending on your CPU, cooling, and overclocking, you can go deep down the rabbit hole to find the fastest single core you have. Unless you have a crazy single-core overclock, the gains in doing so will be minimal. The better thing is to spread them out a bit so you don't have a "hotspot" on your CPU (this depends heavily on the CPU die layout, but that's a whole 'nother level of nerd). Using the calculator is pretty easy: Click the radio button next to those options, then simply click on the cell you want to assign to that affinity mask/core assignment. For your CPU, I'd encourage you to try giving it as many cores as you can and mask off the HT cores for the Thread Schedulers. Try this: https://izn-flightsim.s3.amazonaws.com/affinity.html?cores=8&threads=16&affinity=63447&coreAffinity=63444&mainThread=0&renderThread=6&frameThread=1#presetAnchor Of course, if turning HT off works fine, then do that. But this may give you the same FPS results with slightly improved scenery loading. Not exactly. P3D 5.3 will consume as many cores as you give it for all its supplemental threads within the P3DCoreAffinityMask. There's another long thread here (link escapes me) where many of us tested this repeatedly. On P3D 5.3, give it as many cores as you can and leverage the far more granular affinity mask to keep the virtual cores adjacent to the Thread Schedulers off. This will most visibly improve scenery loading versus HT off with similar-if-not-identical FPS results. Earlier versions of P3D that did not have this granular affinity masking ran great with HT off, but the experience of I and others is that 5.3 makes effective improvements in multi core performance. Your mileage may vary though and every system is different....Test and use what works for you! With the most recent 500.x+ Nvidia drivers and P3D 5.3, you don't need RTSS to lock the frame rates externally. Again, see the optimization guide at the bottom of the affinity tool for multiple ways to externally lock to 30 FPS from the Nvidia Control Panel with Vsync on in P3D and frame rate set to unlimited. 100%. Over multiple systems I have built and tested running P3D, the single most important factor I have found in disk speed is random read/write IOPS. P3D reads thousands of files, most of which are pretty small. on random read/write performance, M.2 PCIE (!important) drives are an order of magnitude faster than SATA SSDs, which themselves are an order of magnitude faster than any mechanical drive. Careful looking at sustained read/write speeds (typically Gbps) as they don't have much meaning in P3D...That's more applicable to reading and writing very large files. This however, is with a caveat: If you still run your system with file compression, file indexing, and virus scanning on (all Windows defaults BTW...), your performance will still suffer. That's a lot of software layers on every single file read into P3D. Turn that stuff off selectively and you'll see better scenery loading, as well as a shortened wait for the P3D scenario screen to fire up. Again, all in the guide at the bottom of the affinity calculator.

As part of the Affinity Calculator I put together, I wrote up a PC/system/P3D tuning guide based on a myriad of threads here at Avsim (echoed in this one) and other places, as well as my own testing over the years. It contains info on setting up your CPU and GPU power, frame rate limiting, disk configurations and optimizations, antivirus exclusions, some P3D settings, and some specifics on FPS troublesome add-ons. https://izn-flightsim.s3.amazonaws.com/affinity.html Click on "Beyond Affinity Masks - Optimizing Prepar3D Performance (Prepar3D System Tuning Guide)" at the bottom.

No need to ask - Yes, the calculator accounts for performance and efficiency cores. Here's a link as an example: https://izn-flightsim.s3.amazonaws.com/affinity.html?cores=12&threads=20&affinity=1048575&coreAffinity=939348&mainThread=0&renderThread=1&frameThread=2#presetAnchor BTW, 12700K only is an 8P/4E CPU. The 12900K has the 8P/8E config. My experience with a 12900K and 13900K is to give P3D as many of the cores as you can, regardless of whether they are P or E cores. Keep the MainThreadScheduler, RenderThreadScheduler, and FrameWorkerThreadScheduler on P cores. And yes, copy/paste the [JobScheduler] entry into your prepar3d.cfg. If it doesn't work or work well, just delete that section of your config and P3D will re-create it with defaults for your system on next launch.

P3D 5.3 changes how affinity masks work. Prior versions simply had an affinity mask for all of P3D and any other processes that run with it (SimConnect, DLLs, etc.) With P3D 5.3, you can now specific separate affinity masks for the CORE processes of P3D and any of the other processes that need access to the P3D process space. You can dig through this thread and many others here on Avsim, but in a lot of research by Rob A, myself, and others, there really isn't a benefit in 5.3 to fully turning off a core from the entire P3D process space. The First Core Free preset will simply move the CORE processes of P3D off the first core, but other stuff can still consume it. As an example, FSUIPC, ActiveSky, etc. The CORE P3D processes are the ones you will see consume significant CPU time, especially the MainThreadScheduler, which will run at or near 100% most of the time. At the bottom of the affinity calculator is a broad series of help sections. Under the "Additional Info and and Configuration Suggestions" you'll find more detail. There's also the setting descriptions straight from Lockheed Martin linked in the help too.

It's a simple page that runs on Amazon Web Services. Appears to be running fine for me. https://izn-flightsim.s3.amazonaws.com/affinity.html If AWS is down, we'll all have bigger problems. 🙂

There's a link to an article on Unreal's site with some deeper details and some quotes from Adam Breed at Lockheed Martin: https://www.unrealengine.com/en-US/spotlights/lockheed-martin-engages-unreal-engine-for-aerospace-simulation-r-d

"fix FPS"? Maybe, but it depends what you mean by fix. What the Texture Optimizer does is allow you to reduce the size of the textures and convert them into a format that allows easier and more direct processing by the GPU. Both of those distinct pieces are important in reducing system utilization for AI. This should lower VRAM usage and some GPU cycles, but it is very dependent on how many AI you have, what the original packages contained, your own system, etc. You may or may not see an FPS increase. Mathematically, each divide-by-two step down of a texture reduces the texture size by a factor of FOUR. How much VRAM is used is a little trickier as it has to do with how the GPU applies, caches, and garbage collects textures. Far more complicated, however it should be reasonable to expect less VRAM usage. At the bottom of the user guide for the Texture Optimizer, there's an entire section on how to re-run it depending on what you are trying to do...Including how to re-run updated packages without needing to regenerate all the textures. Link in the other thread.

Yup. I added those warnings simply to provide more info as to what images had some extra manipulation beyond resizing (and some other fiddly adjustments to make sure alpha channels, texture flipping, and compression are done correctly).