because in the DirectX 11 developer blog they said that instancing would be in 2.0.

 

And it probably was, there are many implementations of instancing and how one deals with the buffer (instance, constant, instance data in shaders, etc.).  There are also some tricks you can do to increase performance which are code/implementation specific.  I'm not privy to exactly what LM did to improve the instancing process, maybe they used just a single vertex buffer (rather than many) and constant buffer for the instance data ... who knows, many ways to skin this programming task.

 

But I'm not saying additional work on building Autogen is impossible, but I am saying they would need to "group" building batches into same geometry in order to really use instancing.  It maybe that the overhead to do this out weighs it's benefits ... or maybe LM just don't want to add "high risk" code (meaning high potential to break compatibility and/or cause other issues) right now.  I don't really know other than nothing has been mentioned about working on Autogen buildings.  I'll try to get more details from Wes, but no expectations.

 

Cheers, Rob.

And it probably was, there are many implementations of instancing and how one deals with the buffer (instance, constant, instance data in shaders, etc.).  There are also some tricks you can do to increase performance which are code/implementation specific.  I'm not privy to exactly what LM did to improve the instancing process, maybe they used just a single vertex buffer (rather than many) and constant buffer for the instance data ... who knows, many ways to skin this programming task.

 

But I'm not saying additional work on building Autogen is impossible, but I am saying they would need to "group" building batches into same geometry in order to really use instancing.  It maybe that the overhead to do this out weighs it's benefits ... or maybe LM just don't want to add "high risk" code (meaning high potential to break compatibility and/or cause other issues) right now.  I don't really know other than nothing has been mentioned about working on Autogen buildings.  I'll try to get more details from Wes, but no expectations.

 

Thanks for the information. I hope Wes will give you some details in that matter.

If it's instancing, then you're right that it cannot be applied to the buildings. However this confuses me further, because in the DirectX 11 developer blog they said that instancing would be in 2.0.

Obviously not all building autogen could be instanced the same, but surely some elements could be?

Obviously not all building autogen could be instanced the same, but surely some elements could be?

 

I'm pretty sure that each autogen building consists of just one model, so I don't think elements of buildings can be instanced. Here's Zach's response on the matter:

 

Unfortunately, the buildings have much more unique data than the autogen trees. We will continue to optimize systems as we find opportunities and time, but the large optimizations for the memory footprint and bandwidth of the trees are largely inapplicable to the buildings.

 

Zach Heylmun

Software Engineer - Prepar3D® Team

We may have to wait for a DirectX 12 version of Prepar3D before there is a significant improvement in multicore threading.

 

From techradar article (top half of graph is with current DX; bottom half is with DX12):

 

 

We may have to wait for a DirectX 12 version of Prepar3D before there is a significant improvement in multicore threading.

 

From what I've seen/read DX12 will also add some flexibility to instancing where geometry can be adjusted slightly so the objects don't look so repetitive.

 

And yes, DX12 should open up the threading door and give developers more control.

 

However, I'm not aware LM have committed to DX12 or mentioned anything about it?

 

Cheers, Rob.

I've been following DirectX 12 since its announcement, it looks like that it will be quite hard to implement because it's really low-level, and it's probably going to break even more compatibility of add-ons. I'd expect DirectX 12 support with the 64-bit version.

 

Considering that things like physics, aircraft systems and AI are running on the main thread, I'm sure that there's still plenty of multi-threading potential with the DirectX 11 version. But you're right that DirectX 12 is definitely needed so we can fully take advantage of our multi-core CPUs.

From what I've seen/read DX12 will also add some flexibility to instancing where geometry can be adjusted slightly so the objects don't look so repetitive.

 

And yes, DX12 should open up the threading door and give developers more control.

 

However, I'm not aware LM have committed to DX12 or mentioned anything about it?

 

Cheers, Rob.

 

I'm not surprised that LM hasn't committed about DX12 yet, as it will still be a while before DX12 will be actually be implemented.  Estimates are that the first DX12 games won't appear until late 2015.  

 

I've been following DirectX 12 since its announcement, it looks like that it will be quite hard to implement because it's really low-level, and it's probably going to break even more compatibility of add-ons. I'd expect DirectX 12 support with the 64-bit version.

 

Considering that things like physics, aircraft systems and AI are running on the main thread, I'm sure that there's still plenty of multi-threading potential with the DirectX 11 version. But you're right that DirectX 12 is definitely needed so we can fully take advantage of our multi-core CPUs.

 

For now (with version 2.x), it is probably best for P3D to remain mostly FSX compatible, as that will certainly help expand the user base. Perhaps P3D v.3.0 will be BOTH 64-bit and DX12. At some point, I would hope that P3D will move beyond all the old constraints attached to remaining FSX compatible.

 

For now (with version 2.x), it is probably best for P3D to remain mostly FSX compatible, as that will certainly help expand the user base. Perhaps P3D v.3.0 will be BOTH 64-bit and DX12. At some point, I would hope that P3D will move beyond all the old constraints attached to remaining FSX compatible.

 

+1

And it would be a smart move to do both "compatibility-braking-things" (DX12 and 64bit) in one step.

If they even manage to communicate this to the third party developers early enough addons will follow.

Always enjoy your insights Rob.... doing a great job with testing and providing insight. Thanks... much appreciated.

Back to the stutter debate since I know it's important to many (on my own personal level I'm very tolerant to stutters, they don't bother me that much).  Here is FRAPS time frame analysis showing what a "stutter" looks like in P3D (very small snapshot):

 

 

This IS NOT a vsync stutter.  FRAPS simply logs the time data (in milliseconds) from one frame displayed to the next frame displayed ... the graph above shows the difference in ms between each displayed frame.  It should be rather obvious where the stutter is.  Again this is hard evidence of what I was indicating earlier in this thread about the 1/60 to 60/60 frame example.

 

I have reported the same findings to LM.  How LM will be able to equate such data to "cause" is of course the key to working a solution or at least an understanding of the issue (because it is very possible there maybe no solution that can be implemented within the constructs of ESP code ... meaning if stutters bother you, then you better be able to hit 60 fps - brute force approach).

 

The basic goal for sub 60 fps is to keep that graph looking as smooth as possible, no spikes.

 

Cheers, Rob.

That is a very interesting graph, Rob. Thanks for that. Perhaps L-M could take a page from electronics and design the equivalent of a "hi-pass" filter to smooth out the results...

...in simpler terms, set a hard limit of upper ms tolerance, such that it is essentially saying "send me whatever you've got at xx ms, and I'll do the best I can with it..." :He He:

 

 

.in simpler terms, set a hard limit of upper ms tolerance, such that it is essentially saying "send me whatever you've got at xx ms, and I'll do the best I can with it..."

 

I'm certainly not going to under play the complexity of ESP ... when I started to look at every aspect of what ESP has to do it boggles my mind ... the threading complexity alone would be enough to send me to the nutter house -- and then add-on support with SDK ... I just no way, run away run away. 

 

I've looked at the Pre-rendered frames settings thinking this might help smooth things out, but no luck.  But I agree, if there are indeed pre-rendered frames, that could provide some measure of "spikes ahead" but how does one smooth with that known information?  Well beyond my humbled knowledge and I don't envy LM.

 

Cheers, Rob.

Funny that the late frame was immediately followed by 2 early frames?

And with the exception of a couple of instances the time taken

to render is more, less, more, less, more, less etc.

How many noticeable stutters are here? Just one or

perhaps 3? If its 3 then the intervals between seem

about the same. Based on 30FPS that makes it about

a second between stutters. I've seen that exact phenomenon.

At 30FPS the Sim runs smoothly with a stutter every second.

But I see that you are getting an average of about 17.5 or 18 fps

in that segment? maybe LM can at least figure out who is to blame

the CPU or the GPU. Or maybe its a conspiracy

Funny that the late frame was immediately followed by 2 early frames?

 

Yes, and that long delay followed by two shorter times will emphasize the "stutter".  This sample represents a relatively "small" stutter (this was just level flight around default Langley, default F22, default scenery, default textures, clean install) and it's a just a small snapshot in time.  If I moved to more dense areas such as KSEA the frequency of stutters is much higher (time between frames).

 

Part of time frame analysis is to ignore fps (frames per second) as that doesn't really expose the issue ... time between frames does show clearly that some frames are taking much longer to display.  IMHO, times between frames if far far more important to "my experience" than fps ... time between frames is what presents a sense of "fluidity".  I can have the same sense of "fluidity" at 20 fps as I can at 60 fps (even at higher GS at lower AGL).  

 

Look at frames 2133 to 2190 that'll present a relatively fluid experience (stutter free) ... time between frames is not identical but it's all about the consistency (smaller variance).  Something is causing the delay around frame 2128 ... I hope LM can at least identify that something.

 

Cheers, Rob.