him225

Aside from the slow loading black textures and patchy populating autogen at higher altitude and speeds, with the OOMs gone, large LOD radius and dynamic lights at their early stage I am sort of satisfied. I would be happy if the primary thread was mutlicored and AI/ATC/Afcad behavior improved/increased in depth, but I reckon that would require a full fledged dev team rather than the current part time development to deal with.

p3d has reached v4 but the time function in startup screen continues to be quirky/broken. Make a change to the location like a different runway or parking spot before changing time. Also use local time as GMT does not work properly.

How much resolution mesh be sufficient for airliner flying beyond which would be considered overkill?

Since it seems like a regular procedure on longer flights that inner tanks feed all engines until quantity on all four wing tanks become equal, why does it lack some kind of auto mode that might be armed to switch off override tanks at the required condition with a ping/notification on ecas? The pilots are always there to do this but since there are many other things that are handled by automation why leave this to be done only manually?

If LM can enable shadows/opacity and adjustable intensity to their dynamic lights in a next update we wouldn't require the above additional modules.

Imagine vectoring of all pilotless planes at heathrow?

No flight is same and not every flight face ordinary situations - combination of economics, weather, traffic, failures, emergencies. Hard to imagine automation to reach a point to robustly cover all those conditions.

Can p3d support realistic flights to and from space in space shuttles at the same level as for eg AS A320? Are there any addons available or in development that can make it possible in future?

would like to know as well how it improves/affects the terrain appearance as the textures appear to have been 1024 resolution since fsx as can be seen in the scenery\world\textures folder and remain the same in v4. Checking the high resolution terrain checkbox which has been found by others to be same as EXP=9 does make the terrain textures sharper even at 3km distance and EXP=10 with little visual difference if any vastly increases loading time and causes stutters on my system. It has been explained it increases the terrain tile resolution from 256 to 512 and 1024, but what exactly is that as looking at texture files the terrain textures have been 1024 in the earlier sim versions as well. Did the previous sim versions not use/display the available texture resolutions fully?

I also prefer default atc and have had it malfunction on several occasions in v4 where it immediately cancels a flight plan or locks out user with no options in the atc menu on loading a saved flight after exiting p3d. Perhaps it happens when sim is interrupted or flight saved while atc is transmitting message or user reaponse is pending. Also I usually carry out vnav decent not adhering to atc instructions which has worked fine but in v4 several times never got assigned approach and runway. Didn't have these glitches before v4.

Ok, was looking to fix it in v4. Its strange though why p3d doesn't yet natively simulate the correct unpaved ground characteristics.

Will fsuipc add this soon or remain unsupported in v4?

Is there an addon or tweak that can give realistic off pavement behavior of friction and gear pressure handling? In MSFS and p3d it is hardly noticeable when the wheels of an airliner stray off the taxiway on to ground/dirt and come back on like nothing happened.  This takes away from the necessity and challenge to keep the plane like 77W on taxiway.

42 minutes ago, B777ER said:

So DD did it right then. I've stayed at the Renaissance Marriott hotel literally right next to the airfield in Atlanta where you have a unobstructed view of the whole airport. At night the airport is unbelievably dark. The only lights really are the sodium lights at the gates. The rest is very dark. That's been a fault of many developers, making their night textures very unrealistically bright. So a dark airport is good.

The airfield should be dark agreed but the parking areas and terminals would be well illuminated which are as much dark with DD when HDR is off. There are couple of posts on their forums of dark airport at night where users were asked to turn on HDR to make the lighting appear correctly.

It seems night lighting is tuned for use with HDR as found airports completely dark at night until tried turning HDR on, which is bit of a problem as I prefer HDR off. Expected to see some use of dynamic lights too.

On ‎04‎-‎06‎-‎2017 at 8:25 AM, LRW said:

 

Beau Hollis of LM wrote this in their P3D forum:

http://www.prepar3d.com/forum/viewtopic.php?f=6315&t=124753&p=158168&hilit=Use+High+Resolution+Terrain+Textures#p158168

GPU heavy features:
- Shadows
- Dynamic Reflections
- SSAA
- Dynamic Lighting
- 3D Water (water set to ultra)
- New 3D rain/snow effects (set weather to storm theme to test)

In terms of GPU memory, checking the high resolution terrain textures box will up the terrain tile resolutionfrom 256 to 512. This uses 4x the texture memory for terrain. With a cfg tweak, you can get the resolution up to 1024. We don't support this via the UI because so few video cards have enough memory to function on that setting. Note that in addition to using more GPU memory, this will put more stress on the threaded CPU jobs used to generate those textures. So, it will impact loading times and paging performance which can lead to blurry textures, models popping in, etc.

Could someone clarify on the high resolution terrain texture check box as I thought fsx/p3d already used 1024 resolution textures which is the size of them in the default scenery. Do the previous versions load/display terrain textures at lower resolution despite textures being 1024 size or does this new setting in v4 allow 1024 farther away?

1. An additional 100w for of the order of +20% single core throughput would indeed be not that interesting an increase in performance.

This might be a cheesy thought but since we already have so many cores being put on a die, can there be a design where a single thread is run alternatively on two or more cores where the cores run at nominal clock speed but in alternating sync while only the combining data bus run at higher speed with windows seeing them as a single core at the combined speed, could that give 2x, 3x.. single thread performance?

2. Being able to do it gradually in parts unlike x64 would be a convenience, but will it be of significantly more complexity than 64 bit conversion that they might hesitate in taking it up?

3. I think the well known explanation for this is p3d loads the whole world and its varying features on the run while games cover a small area optimized and build to be viewed from limited viewpoints and distances. Would be interesting to know how much further it is possible for more tasks to be efficiently shifted to the gpu which is better at parallel processing while cpu at sequential one. From my use I find AI quantity and scenery complexity quantity to be the primary hitters on the performance aside from complex aircraft.

1. Just to have an idea, if they were to go with larger design, beefier air coolers and power supply what would it be like and how high the cost would be of processor and associated components to build such a pc? As they could keep it as a product range for interested industry customers and enthusiasts even if of little use or demand to the mainstream. Would it be cheaper for them to work at larger nm scale when much finer scale technology is readily established?

2. Thought that might be the case. Would it be more substantial of a work than x64 conversion which they recently did?

3. A tantalizing prospect but each of the other options have to go a significant way until they become a more complete package like fsx/p3d is. But given the pace they all have similar uncertainty if it will happen.

1. It has been apparent since several years intel has not shown any interest in boosting single core performance. Can AMD be expected to cover this area or bets are still on Intel if ever it happens?

2. Will we have to wait for above to happen for a remarkable increase in performance or LM is going to multithread the rendering before that?

3. None of above will happen and things will continue at a crawling pace as they have for past few years?

I have found the culprit setting on my system to be terrain texture resolution slider. Anything above 5m is inducing intermittent stutter in cruise while I had it set 60cm in v3 without any problems where it didn't cause stutter even with slider to full right while in v4 at the max setting stutters profusely. Any suggestions on what might be causing this? I have already tried adding texturemaxload, and changing affinitymask to no effect.

Edit: I was keeping p3d process priority high to keep other programs from interfering but turns out it had reverse effect and caused this stutter. Returning it to normal priority made the sim back smooth again. Didn't see it happen in v3 so didn't strike immediately.

Although the maximum range for ILS in p3d is fixed at 25NM I have seen planes intercepting as far back as 35-40nm from the airport in flightradar24, which made me curious how much DME distance is generally considered fine for ILS interception in real life? Does it vary from airport to airport or between old and new transmitters or perhaps aircraft even?

I have stutters at cruise as well, seems to be related to high fps. There are intermittent stutters if fps touches or exceeds 60, even with vsync+triple buffering on. Applying AM=170 (which is similar to 85) appears to have helped a lot with it but not completely eliminated them.

1. In above diagram could you clarify the result with AM=85 as I think it would give two loading cores similar to 245 and make rendering free from loading?

2. If I change p3d to high priority in task manager which should not hold up the process for other things as addons and some OS work, but with HT on and sharing one LP with p3d and other LP of the same core with addon or other app having a cpu demand, will it choke the p3d process despite the high set priority as from what I read windows sees them as separate physical cores and that should instead assign the addon process on the same LP as p3d thread to let windows priority work normally?

27 minutes ago, SteveW said:

 

250=11,11,10,10 same as 245=11,11,01,01 = joy-o-meter leaning towards rendering performance

Simplified, gives a pair of cores dualed for loading '11,11' and a pair of cores rendering '01,01'

Keep addons to 10,10,00,00

 

254=11,11,11,10 same as 253 11,11,11,01 = joy-o-meter leaning towards background performance

extra LP may add loading performance but robbing some smoothness from the first two jobs even if not.

 

See if your scenario loads up quicker with 254, if not then your hardware can give up no more than it can with 250 (250=245).

 

 

Thanks for the explanation. Theoretically will 254 still rob rendering performance over 250 if both LPs of core1 average below 50% and never max out? As I am tempted to keep 254 to give additional core to loading tasks since with 250 I feel core1 remains underused during flight.

could you suggest between AM=250 and 254 on quadcore with HT on. The light second rendering task is shared with a fifth loading task on a core with its two LPs in the latter. Can that improve the throughput or better to stick with 250?

As for p3d itself - better multicoring. Better AI behavior in general, perhaps an addon would do it.

In addons - something for detailed global landclass coverage enhancement and update. LM has already improved the vector data.