Gaming Terrain performance testing request

Artlav

Aperiodic traveller
Addon Developer
Beta Tester
Joined
Jan 7, 2008
Messages
5,814
Reaction score
869
Points
203
Location
Earth
Website
orbides.org
Preferred Pronouns
she/her
Good evening.
I've been working on improving and speeding up the OGLA/Spaceway terrain engine, and would like to get some feedback.

If you are interested, here it is:
http://spaceway.1gb.ru/files/sway-terrain-test-130803-1.zip (0.7Mb)
Unpack into it's own directory, run the exe.
(Connection problems? See post #6 - http://www.orbiter-forum.com/showthread.php?p=432465#post432465 )

There are 4 scenarios:
pt_big_air - Flying over a "complex" world
pt_big_orbit - In orbit over a "complex" world
pt_small_air - Flying over a "simple" world
pt_big_free - Free flight over a "complex" world

"complex" and "simple" refer to the texture generation complexity of a planet.
"Simple" one would take a while to load the first time.

What to do:
Include your system specs (CPU, GPU, OS) in your reply, without them everything else is meaningless.

-Pick first three scenarios one by one.
On the start the game would be paused, and terrain would start to generate.
On the left is the debug menu, it shows time elapsed, and generation stats.
-Note the time it takes to generate terrain ("total" stops increasing), and generate textures ("tex" stops increasing)
-Once it finishes, note the FPS (upper-right, or window caption) and unpause (Ctrl-P).

From here it becomes subjective.
You will be flying along the terrain (or orbiting).
Observe how well the terrain stays updated, and what kind of performance degradation there is in motion. It might jerk, or it might slow down - i'm not sure.
In orbital scenario, before unpausing try to look around (right mouse button), and observe whether terrain updates with the view in a reasonable manner.
Note the average FPS in motion.
If you want to take control, controls are similar to Orbiter, Q toggles off the fly-straight mode.

Try to get the best quality and performance combination by changing the settings, and note the settings if successful.

Settings:
On the right there is options menu.
Two sliders are of interest - Uniformness and Quality.

Uniformness controls the spread of the terrain - if low, the high-resolution terrain will creep around the player, and in the distance everything will blur out.
If high, the terrain would be uniformly distributed (whether high-res or blurred depends on sufficient Quality being allocated).

Quality controls how much polygons are allocated for the terrain, and primarily responsible for FPS.

F11 key toggles the graphic settings menu.
Only thing of interest there is the "Advanced graphics" (AG) option, U key.
If everything is unreasonably slow, toggle it off.
Rule of thumb: If in paused orbital scenario you get high FPS looking at space, and low looking at terrain, then toggle AG off.

If everything works so smooth it's boring, try increasing texture resolution to 128 (Won't let you change in game, press Esc in scenario select, change, press L). EDIT: After the change, exit and delete the content of dynpl directory in cache if you do this, otherwise you'll get stripes instead of terrain.

Changing any other settings leaves you on your own with voided warranty.

Potential issues to look for:
-Colours are off, probably on Intel cards
-Weird shadows or black spots
-Total lack of anything (on lower-end systems)

If any of these present, post shaders.log
If it crashes, post run.log
If it looks weird, post screenshots (Ctrl+V)

References for appearance, high is uniformness/quality at maximum and AG on, low is uniformness/quality at minimum and AG off.

Flight, high and low:
swt-130803-ah.jpg

swt-130803-al.jpg


Orbit:
swt-130803-oh.jpg

swt-130803-ol.jpg


Simple:
swt-130803-mh.jpg

swt-130803-ml.jpg
 
Last edited:
How many parallel connections can the server handle? My download stopped at 0 B of 718 KB and the images you posted haven't fully loaded yet.
 
Yea i'm having issues connecting to your site as well. It was working fine the past few days. :shrug:
 
Same here. Anyways, it's awesome to see that you're still at it. I saw something along the lines of "spaceway is no more" in another thread and got a bit worried. Will definitely give the benchmark a go as soon as I get to download it...
 
It was working fine when i posted... :shrug:
I'm some 2000 km away from the place, so no idea what is wrong - try trying again in an hour, i guess.

EDIT: The whole 1gb.ru network is down. I think the technical term for this is "bad luck".
They are a big company, so i hope there are people fixing whatever is wrong.
 
Last edited:
The first two scenarios start loading quick but after about 5-10 seconds i get a windows timeout error. (Error code: 7) The third works nicely terrain loads pretty quickly albeit fuzzy at the far side of the planet with an average of 25-30 FPS. The last scenario loads in about 5 seconds and i get an average of 32-38 FPS terrain updates quickly on the fly.

Graphics card:NVIDIA GT 240 and i have i think 4 gigs of ram.

Edit: In the third scenario if i look directly at the planet i get a windows timeout error as well.
 
Last edited:
i get a windows timeout error. (Error code: 7)
Which Windows and what CPU do you have?
Is there anything in run.log?
What does the error look like? Pop-up window? "Driver was restarted"?
Any other details (i can't identify this "windows timeout error", and Google does not help)?
 
OS: Windows 7 and it was a pop-up window. I would get a screenshot but i don't know how. CPU: Intel Dual Core 2

It happened as soon as the terrain stopped loading. Unpausing in the beginning seemed to help.
 

Attachments

I recorded the test with Open BroadCaster, specs included.

 
It happened as soon as the terrain stopped loading. Unpausing in the beginning seemed to help.
Ok, please try this one:
http://spaceway.1gb.ru/files/sway-terrain-test-130803-2.zip

Try to reproduce the crash a few times.
According to the log, both cases happened when you started one scenario, then quit to main menu and started another without closing the game.

This version is not expected to fix the problem, only localize it.
If by chance it does fix it, please post the log of the runs anyway - some errors are quietly ignored.

I recorded the test with Open BroadCaster, specs included.
Nice, thank you.
You should not have enabled "Sharp clouds" - it's broken and gobbles up performance, invalidating the comparison somewhat.

Does it work as well without the capture software?
Specifically, the jerkiness.
30 FPS in space also seems too low.

Does it fell playable?

---------- Post added at 04:05 ---------- Previous post was at 04:01 ----------

Also, about texture resolution 128 - please try deleting all in cache/dynpl, then trying it again.
 
Happens almost everytime for me and heres the log from the first go in scenario 1. The session lasted about 3 seconds before crashing.
 

Attachments

Last edited:
Happens almost everytime for me and heres the log from the first go in scenario 1.
Are you sure it's the log with the crash? It's pretty much empty.

Try making a screenshot of the error window - i.e. press Alt+Printscreen on it, then paste into mspaint.

If there is a details button on the error window, what is under it?
 
Here i attached a new log with all scenarios tested along with shader log. The shader log is showing the error.

Edit: Is this indicating my driver to be out of date?
 

Attachments

Last edited:
CPU: 4 Core 2.4 GHz
GPU: GeForce GTX 650
RAM: 4 GB
OS: Win 7 32bit Pro
On the default settings, with this hardware, it stays at 60FPS most of the time, even when flying. Will try turning things up tomorrow.
 
Here i attached a new log with all scenarios tested along with shader log. The shader log is showing the error.
shader.log cannot show any error of crash magnitude, it only shows graphics-related compatibility issues.

I'm looking for things like "Error in galvis, i=0 Access violation at address 0049EE95 in module 'terrain_test.exe'. Read of address 00000000" in run.log, of which there are none...

Could you get a screenshot of that error window?

Edit: Is this indicating my driver to be out of date?
Nope, just a bunch of typical warnings related to overdiligent shader compiler in your drivers.

---------- Post added at 04:32 ---------- Previous post was at 04:30 ----------

On the default settings, with this hardware, it stays at 60FPS most of the time, even when flying. Will try turning things up tomorrow.
Nice. If you'll get stripes in the terrain instead of textures, don't forget to delete cache\dynpl directory content.
 
Yep here is a pic.
 

Attachments

  • 0803132035.jpg
    0803132035.jpg
    105 KB · Views: 17
  • 0803132035a.jpg
    0803132035a.jpg
    250.7 KB · Views: 16
Yep here is a pic.
Ah, so it's a driver error window, not game error window!

This is in fact a known issue with Nvidia drivers.

Try this:
Go to NVIDIA Control Panel --> Manage 3D Settings --> Global Settings, and switch "Power Management Mode" to "Prefer Maximum Performance".

If that does not help, then try Googling "nvidia opengl driver lost connection" or something similar - AFAIF, it's a common issue with many possible solutions.
 
Yea there was no effect. This is baffling as previous versions worked very well. ( I could almost max out the settings without major consequences.)
 
Last edited:
Q6700 @ 3200 MHz, 6 GiB RAM, GeForce GTX 285 1 GiB RAM (PCIe 1.1 on the motherboard); Gentoo Linux x86_64, kernel 3.9.1, nvidia-drivers 325.08, screen at 1920x1440@86Hz, WINE 1.6.

Default settings:

[table=head]scenario|
"total" time​
|
"tex" time​
|
paused FPS

pt_small_air|||

pt_big_air|||

pt_big_free|||

pt_big_orbit|||[/table]


High settings (all sliders moved to the right):

[table=head]scenario|
"total" time​
|
"tex" time​
|
paused FPS

pt_small_air|||

pt_big_air|||

pt_big_free|||

pt_big_orbit|||[/table]

The missing images mean the "tex" generation process didn't finish and it was locking the render window ("tex" around 100 / ~220), and I preferred to close it while I still could, instead of restarting the X server (which did automatically a couple of times during testing).

The "pt_small_air" scenario required clearing cache every time it was launched, because there was this error (which didn't crash the SpaceWay, but stopped calculations and rendering until I closed the error window):
Code:
wine: Unhandled page fault on write access to 0x0000xxxx at address 0x12deb48:0x0047af22 (thread 002d)

The delay between the counter not increasing and me taking the screenshot may be around 500-1500 ms in normal cases. However, for very short times I tried to catch the exact moment a couple of times, as can bee seen for "pt_small_air" in standard settings ("total" is 174 at 0.38 seconds instead of the final 178, but I couldn't catch the screen for example at 0.42 seconds no matter how hard I tried :P).

I'll do some dynamic testing and check different settings tomorrow, and I'll test it on Windows 7 (x86_64) and Windows XP (x86) on the same computer tomorrow evening.

The FPS on the screenshots shows that the v-sync is in use (eg. 86, 43, 28, 17, etc.). While I'll be testing it on Windows, this shouldn't be the case and there might be higher results than 86 FPS.
 
Back
Top