Under the hood...

For all topics that don't fit into another category. Note that we cannot promise that any of these posts will be responded to by our development team.
bojote
Posts: 6
Joined: Tue Dec 07, 2010 3:46 pm

Postby bojote » Tue Dec 07, 2010 11:07 am

Hello... ;) newby here.



I was wondering if the Prepar3D developers take an active role in the forums, I just had some questions regarding FSX / Prepar3D differences.



Particularly, I want to know if Prepar3D changed the way Index/Vertex buffers are used. FSX uses dynamic buffers but does not 'cap' the ammount sent by frame unless you set a RejectThreshold value. This is (was) a performance killer in FSX, has this changed in any way for Prepar3D? (yes, I know it can be tweaked, just asking what it defaults to)



How about the HIGHMEMFIX? is it truly enabled by default now? in FSX, all the D3DXCreateEffect* functions will NOT pass the D3DXFX_LARGEADDRESSAWARE Flag unless HIGHMEMFIX is set!



A user tried to install my Shader 3 Mod into Prepar3D and got a black screen, so I can only assume that the shaders were changed to SM3, is this correct? he also noticed that Prepar3D by default had better performance when flying into clouds (using ATI cards), I solved this performance problem changing filters from linear to aniso (for clouds only) and ATI users got a nice performance boost.



The reason I want to confirm all this, is because of this:

http://www.venetubo.com/fsx.html



Want to make sure I provide accurate info ;)



Thanks,

Jesus 'Bojote' Altuve

User avatar
Beau Hollis
Lockheed Martin
Posts: 2167
Joined: Wed Oct 06, 2010 3:25 pm

Postby Beau Hollis » Tue Dec 07, 2010 1:18 pm

Jesus,



First off, thanks for all your research into FSX performance and rendering. I've personally read through a few of your threads on the SM3 mod and FSX.cfg tweaks, and found them useful when investigating performance issues with Prepar3D. In fact, one of our guys compile performance tweaks from the community and documented them in the learning center, and you were properly credited for your research.



Quote:

Special thanks to Avsim member, Jesus “Bojote” Altuve for the BP=0 research. Much of this information is taken from an Avsim forum thread and the link to the original thread can be found below in the sources.




The team has definitely been active on the forum and will continue to be - as long it doesn't interfere with our core tasks.



To address your questions:

- Prepar3D did not change the way Index\Vertex buffers are handled.

- HIGHMEMFIX is not in Prepar3D.cfg by default but is documented in the learning center

- We updated the terrain, water, and general shaders to SM3 to accommodate an increase in instructions introduced by the addition of IR Sensors and Refraction (for bathymetry).

- We haven't tweaked the clouds.



Post launch, we discovered some issues with rain/snow either performing badly or not showing up at all because of newer hardware choking on the old SM1.1 shader. We have fixed that and are currently looking into upgrading other legacy shaders.



Also, just a few bits of info for you in case you are asked to compare performance between FSX and Prepar3D.



Global textures settings have a new range:

FSX/ESP: 64 128 256 512 1024

Prepar3D: 256 512 1024 2048 4096



In this next update the range will be expanded and re-labled to avoid confusion:

64 128 256 512 1024 2048 4096



Our starting area is now Norfolk, which has a high-res pictometry inset that uses 4096 textures.



Water settings are all 3x now and the top 3 settings include refraction. There is also a known bug where scenery objects are rendered in the refraction pass for all three of these settings even when bathymetry is disabled. A fix for this will be part of our next update and will improve performance.



So for the best apples-to-apples comparison, you would need to:

- Be far away from Norfolk

- Have bathymetry Disabled

- Have Global texture settings two notches lower than FSX/ESP



Thanks,

Beau



Beau Hollis
Prepar3D Software Architect

bojote
Posts: 6
Joined: Tue Dec 07, 2010 3:46 pm

Postby bojote » Tue Dec 07, 2010 3:19 pm



Quote:

Quote from bhollis on December 7, 2010, 13:18

and you were properly credited for your research.




Thats great to hear! keeps the motivation up ;)



Quote:

Quote from bhollis on December 7, 2010, 13:18

The team has definitely been active on the forum and will continue to be - as long it doesn't interfere with our core tasks.




it says a lot about the Prepar3D team and their involvement with the community, I'm strongly considering protecting my investment (time and money) into a supported version of FSX and Prepar3D might be just what I need, specially now that I'm planning some new stuff.



I developed a d3d9.dll proxy/wrapper to intercept D3D calls and modify some parameters (such as BehaviorFlags) for IDirect3D9::CreateDevice to experiment with performance. Currently FSX passes some weird BehaviorFlags that do not correspond with Vertex/Index buffer usage parameters (they should match) Also, I want to experiment with allowing Direct3D control (instead of device driver control) at device creation time to see if it allow fsx to use undocumented parameters such as:



Code:

[GRAPHICS]
MultiSamplesPerPixel=
MultiSampleQuality=




With the wrapper I also want to add some Bloom/HDR post processing effects (like ENBSeries does) but is taking me forever to figure out how to read a back buffer surface as a texture. I'm trying to do this HDR effects because I believe the current Bloom.fx in FSX is flawed or at least, not efficient... I tried modifying it but I believe the samplers (texture registers s0, s1, s2...) are passing the wrong data or I'm doing something wrong.



Anyway, thank you very much for the quick answer.. will definitely monitor the forums here and get a developer license for Prepar3D.



One more thing... would you be so kind in providing the 'correct' ranges for the 'ObjectsToBatchPerFrame' setting from the [SCENERY] section? (should be in the g3d.cpp file) it affect the batching of autogen objects per frame, it does not have a significant performance impact because this happens in the texture manager threads but it is the only setting in the fsx.cfg I've not been able to figure out yet ;) I would like to experiment a bit with it.



Cheers,


User avatar
Beau Hollis
Lockheed Martin
Posts: 2167
Joined: Wed Oct 06, 2010 3:25 pm

Postby Beau Hollis » Wed Dec 08, 2010 8:36 am

The default value 50. It's an unsigned int, so there really isn't a bounding range. It's an early out for the batch building function. Setting it to 0 will turn off batching, setting to an arbitrarily high number would cause the runtime to batch all batch-able scenery objects that haven't already been batched.
Beau Hollis
Prepar3D Software Architect

bojote
Posts: 6
Joined: Tue Dec 07, 2010 3:46 pm

Postby bojote » Wed Dec 08, 2010 10:46 am



Quote:

Quote from bhollis on December 8, 2010, 08:36

The default value 50.




Great! thanks Beau... no more questions :)




Lu53
Posts: 4
Joined: Thu Dec 02, 2010 3:12 am

Postby Lu53 » Sun Dec 12, 2010 8:01 pm

Hello Jesus,



good to have you here after our initial email conversation. Keep up the good work for P3D as well!



Greetings, Lu



(Walter Weyers)

bojote
Posts: 6
Joined: Tue Dec 07, 2010 3:46 pm

Postby bojote » Mon Dec 13, 2010 10:41 am

I will Walter! but, trust me... you are in good hands with the Lockheed Martin guys ;) they are all probably as obsessed as I am in making the sim experience the best possible!

bojote
Posts: 6
Joined: Tue Dec 07, 2010 3:46 pm

Postby bojote » Sun Jan 02, 2011 5:35 am

Hi Beau,



Hope you had a great New Year celebration!



While doing some cleaning today I found old notes I had on some settings I investigated a while back. They are still a mistery to me and I would appreciate any clarification to understand them a bit more.



[TERRAIN]

TEXTURE_FORMAT



[MAIN]

MIN_FIBER_TIME_SEC

MAX_FIBER_TIME_SEC



[GRAPHICS]

DPUPBUFFERSIZE

STALE_BUFFER_THRESHOLD=60 // Valid values are 5-1024 default is 60





I know that STALE_BUFFER_THRESHOLD is for clearing unused vertex data after x amount of frames, yet I have never seen *ANY* impact on GPU memory usage, so I'm not sure its being used or if the data I have is correct for the default values and valid ranges.



TEXTURE_FORMAT under [TERRAIN] not sure if this refers to direct3d format (D3DFMT_) enum types. if this is the case, it would be nice to test different values under nVidia/ATI cards and see how they perform. I remember the default value for this was '7' no idea what the '7' refers to.



What about DPUPBUFFERSIZE? is it used at all? and finally the MIN and MAX FIBER_TIME_SEC settings above.



I would appreciate any input on the above, default values and/or valid ranges so I can play with them and report back.



Thanks!

User avatar
Beau Hollis
Lockheed Martin
Posts: 2167
Joined: Wed Oct 06, 2010 3:25 pm

Postby Beau Hollis » Thu Jan 06, 2011 7:30 am

Min/Max Fiber Time default to 0.001(seconds) and 0.1(seconds), but it doesn't look like the variables are actually used, so you'll probably want to stick with FIBER_FRAME_TIME_FRACTION.



Texture formats values are as follows:

0 - 8 Bit Monochrome

1 - 8 bit indexed

2 - 16 bit with binary alpha (1555)

3 - 16 bit (565)

4 - 16 bit with alpha (4444)

5 - 24 bit 888

6 - 32 bit 8888

7 - DirectX Texture Compression DXT1 ** Default Value **

8 - DirectX Texture Compression DXT3

9 - DirectX Texture Compression DXT5

10 - Perturbation data

11 - PTC compressed

12 - 1-bit per pixel grayscale

13 - 8-bit per pixel grayscale

14 - 16-bit per pixel grayscale

15 - 32-bit floating point grayscale

16 - 16-bit floating point grayscale



I don't know how changing this would effect the terrain system, so play with it at your own risk.



DPUBUFFERSIZE is the DrawPrim buffer size in MB. Accepted range is 4-64. Default is 4. This only applies to the dx10 renderer, though, which we disabled in Prepar3D.



STALE_BUFFER_THRESHOLD is used to delete the D3D9VertexBuffer objects at the directx level. When a buffer is released, the stale counter starts, and if it's not requested again before the threshold, it gets deleted. I'm guessing that either the driver is waiting until space is needed to delete the buffers, or the delayed D3D9VertexBuffer deletion only applies to the system memory copy.



Beau
Beau Hollis
Prepar3D Software Architect


Return to “Miscellaneous”

Who is online

Users browsing this forum: No registered users and 29 guests