View Issue Details

IDProjectCategoryView StatusLast Update
0001151FSSCPgraphicspublic2012-04-03 13:47
ReporterTolwyn Assigned To 
PrioritynormalSeverityblockReproducibilityalways
Status closedResolutionfixed 
Product Version3.6.9 
Summary0001151: Asteroids are not rendered correctly after entering autopilot/time compression set to 64x
DescriptionAfter some excessive testing I am pretty sure it is related to the time compression. There are varios effects, which I will describe here:

Asteroids will pop up in a certain distance (Geforce 6800), cause severe slow downs (and usually vanish i.e. they are not invisible, they are no longer in the mission's area)(Geforce 6200), same applies to Intel 845 shared memory (it worked perfectly before).

Example: In our third mission there is an asteroid field at nav1 (SCP asteroids, maps by Dabrain). You may get a glimpse of it, but then... it is gone. Asteroids are not invisible or anything, they are simply gone.

As a workaround i never activated autopilot to nav1. Instead I set the time compression to 16x or 32x. Framerate remained stable at above 25fps and the asteroid field was at the nav point.

At nav1 I turned around, flew at the asteroids and set time compression manually to 64x max value. Asteroids disappeared and framerate dropped. Doh!
TagsNo tags attached.

Activities

Tolwyn

2006-11-23 09:15

reporter   ~0007150

here are my command line parameters: fs2_open_3_6_9.exe -spec -glow -2d_poof -cache_bitmaps -ship_choice_3d -wcsaga -snd_preload -ambient_factor 100

Tolwyn

2006-11-23 09:52

reporter   ~0007151

I took a closer look today (must have been 4 hours I spent trying to figure out what was wrong ;) ). I get a glimpse of asteroids at nav1, then they start to make erratic movements ("buzzing like flies") and then they are gone.

This seems to be related to the global speed of the asteroid field (I am not sure what it is for). At any rate, replacing 4 with a zero did the trick.

Here is the bit of the FRED code:

#original entry

$Density: 256
+Field Type: 0
+Debris Genre: 0
+Field Debris Type: 0
+Field Debris Type: 1
$Average Speed: 4.000000
$Minimum: 22000.000000, 6500.000000, -50000.000000
$Maximum: 39000.000000, 10500.000000, -46500.000000

#replaced with...

$Density: 256
+Field Type: 0
+Debris Genre: 0
+Field Debris Type: 0
+Field Debris Type: 1
$Average Speed: 0.000000
$Minimum: 22000.000000, 6500.000000, -50000.000000
$Maximum: 39000.000000, 10500.000000, -46500.000000

P.S. I did not try, but this might as well fix the "popping up" (I wonder for a better term.) effect I have with asteroids.

taylor

2006-11-25 21:30

administrator   ~0007169

Try: http://icculus.org/~taylor/fso/testing/rc7dot9x.rar

It shouldn't make a difference in the speed problem, but it restores the lighting falloff that non-HTL had. This makes asteroids more difficult to see the further away that they are since it lowers the light applied to them. It should lessen the effect of them popping in and out of view until I can finish coding up a proper fix for post-3.6.9 builds.

Tolwyn

2006-11-26 17:58

reporter   ~0007179

I'll try it asap.

What can we do, apart from waiting for a fix? Revert to FS2 asteroids? Reduce texture resolution?

taylor

2006-11-26 18:03

administrator   ~0007180

Well, I think that the MediaVP asteroids had non-power-of-2 textures (ie, like 800x600 or something like that), which makes then slower to use. You can just resize them to a power-of-2 size and see if that helps. I had done this for my own MediaVPs (even though I don't need to, my video card supports non-power-of-2 textures natively) and thought that it possibly could be the cause of the some of the slowdown. The problem is that the game should handle the non-power-of-2 textures just fine, but perhaps it's hitting a bug or something and only some cards/drivers are able to trigger it.

I've been through the code and can't find a reason for the slowdown at all. If it's linked to "$Average Speed" in any way then I sure can't figure out how.

Tolwyn

2006-11-26 18:08

reporter   ~0007181

hmm... you couldn't upload your texture maps, could you? And I am not sure if our asteroids are up-to-date. My Media VPs date back to May 2006, although I am not sure where I get them in the first place.

As I mentioned this before, only slower GPUs are affected by this (and only at 64x time compression). I'll check the POFs and texture maps next.

Tolwyn

2006-11-26 18:13

reporter   ~0007183

I just checked: texture maps are power of two (1024*512). Asteroid models have around 7k polys in lod1, 120 in lod4.

Tolwyn

2006-11-26 19:11

reporter   ~0007186

I can't run the executable on my subnotebook. Upon launch it will switch into pause mode (you can see the briefing screen in the background). I can do nothing else but start the task manager and kill fs_open.exe.

Tolwyn

2006-11-28 09:24

reporter   ~0007206

Last edited: 2006-11-28 09:26

Okay, I just replaced MediaPack VP asteroids with the low detailed asteroids from FS2 VPs. Voila. Everything works.

Then again, if I use VP asteroids and fly manually (32x time compression) to the asteroid field, everything will work just as fine. If I set time compression to 64x asteroids will start to make very erratic movements after a few seconds. Then they seem to fill my screen and vanish. If I wait a couple of minutes they will respawn.

Somehow it reminds me of Star Trek and the warp drive :)

taylor

2006-11-28 09:37

administrator   ~0007207

Try this and see if it also remedies the problem: http://icculus.org/~taylor/fso/misc/ast-test.rar

This is the hi-poly asteroids, textures, and IBX files from my own VP set. If it fixes the problem then we'll just assume that there is some issue with the MediaVP asteroids/data and leave it at that.

Tolwyn

2006-11-28 09:53

reporter   ~0007209

nope. 32x - fine, 64x - bad :)

2006-11-28 09:59

 

screen0022.jpg (52,009 bytes)   
screen0022.jpg (52,009 bytes)   

2006-11-28 10:00

 

screen0023.jpg (51,733 bytes)   
screen0023.jpg (51,733 bytes)   

2006-11-28 10:00

 

screen0024.jpg (42,322 bytes)   
screen0024.jpg (42,322 bytes)   

Tolwyn

2006-11-28 10:01

reporter   ~0007210

I doubt I can record a video clip to show how it really looks like. I wish I could. Here are a couple of screenshots.

ARSPR

2006-11-28 16:01

reporter   ~0007211

Last edited: 2006-11-28 16:03

I don't know if this can be related to it.

I can assure that general game accuracy is lost when you start increasing time compresion. Till 16x it 'always' works fine. But if you make it higher, specially at 64x, you get quite strange behaviours. For example while testing my loved Derelict's 'The Stars are Right' (0000962), I always use time compresion till the Moloch arrives. If I left a high factor enabled I can see at least the following issues:

+ When the Argo with the engineers undocks from the Ganimede Ring, it follows its waypath quite erratically.

+ When the Moloch arrives from subspace, it stops at a different position than with 1x.

+ Beams accuracy is lost. As an example, the SD Lucifer usually misses the facing Sobek.

(I have always thought that this effect was unsolvable and fully known).

Tolwyn

2006-11-28 18:58

reporter   ~0007213

it seems to happen only on low end systems.

ARSPR

2006-11-28 19:30

reporter   ~0007214

Well, my PC is not a Mega-Ultra-High-Tech Core 2 Quad with two overclocked SLI 8800GTX GPUs, but it isn't VERY bad:

P4 HT 2.8 GHz + RAM 1.5 GB DDR400 + nVidia AGP 7800GS

So if the time compresion issues are related to PC specs, it shouldn't appear here.

Tolwyn

2006-11-28 19:38

reporter   ~0007215

I should have made myself more clearly :)

I was refering solely to the asteroid vanishing while using time compression 64x (which we do in autopilot mode).

@taylor: regarding the asteroid appearing in certain distance on a Geforce6800. I am not sure if I had it before. It might be just an effect of time compression (asteroid respawn), because not all asteroids are affected by this.

taylor

2006-11-28 20:23

administrator   ~0007216

The asteroid (dis)appearing thing is just old code which needs to be replaced. It has nothing to do with the persons computer, or even time compression, but old code which is fixed at saying that beyond 3000 meters any asteroid can appear or disappear. As we keep upgrading the engine and the graphics involved, it becomes far easier to actually see asteroids that far way in perfect detail. That's why I restored the asteroid lighting fall-off in newer builds, it does a little to help hide the problem. I'll get it fixed to work more appropriately after 3.6.9 ships, but it's just too big of a change to do before then.

As far as time compression goes, I'm pretty sure that there is an inaccuracy there somewhere which is attributing to the problem. Since many calculations are based on the framerate, with time compression factored in, when you get to the higher time compression levels the accuracy of the math becomes a big issue. I don't know that we can do much of anything about this though, except maybe disable anything above 16x, but I don't think that would work out very well for mods. This is just too big of a problem to come up with a remotely sensible solution for by the time 3.6.9 ships (ie, any day now).


I think that the best fix for the time being is to help reduce the inaccuracy of the math. As you already noticed, changing the average speed of the asteroid field to 0 fixes the slowdown. That is a float value, so a setting of 0.7 (for instance) is valid, and should still give the asteroids some movement. The point though, is that the smaller the number the lower the chances of floating point error in the velocity and position calculations for the asteroids.

See if just reducing the average speed variable does the trick, instead of setting it to 0, and hopefully that can hold everyone over until we can figure out how to deal with this issue better in the code.

Tolwyn

2006-11-28 21:16

reporter   ~0007217

I'll try. All I can tell for now is that 2.0 did not work. Of course, we could limit time compression to 32x as it works perfectly. Then again, it will have some impact on the game play seeing, that it will double travel time between navpoints.

We could, of course, offer old asteroid models for those, who experience the problem. Or we could remove lod1 on the asteroids and see what happens.

At any rate, I'll try 0.7 for the average speed. Tolwyn out.

Tolwyn

2006-11-29 10:13

reporter   ~0007219

no change is visible :(

Tolwyn

2006-11-30 12:45

reporter   ~0007225

would it be possible to either limit time compression to 32x globaly or on a mission basis?

Tolwyn

2006-12-05 10:29

reporter   ~0007231

Last edited: 2006-12-05 10:31

uhuh, bad news.

I believe, that there are two effects, which concern autopilot now.

1. disappearing asteroids
2. performance drop

They can occur at the same time or separately although there seems to be some sort of connection. Then again, using old asteroids fixed number 1 for me, but I never experienced number 2.

ScoobyDoo from our team reported slow downs for some time now. I believe, that it is related to the asteroid field. He conducted some testing today and was able to confirm my suspicions. I believe he has a Geforce2 card.

So, what should we do? Set average speed of the asteroid field to zero? This solves disappearing asteroids AND performance drop, but the overall impression of the field sucks. It becomes static. Offer a fix for those who have the problem? (Altered core.vp available on setup).

Of course, another possibility would be to limit time compression to 32x, but that will virtaully double travelling time between nav points.

taylor

2006-12-05 19:09

administrator   ~0007236

We aren't going to put code hacks in to deal with this (ie, making 32x the max autopilot speed). And since the speed drop only affects certain people apparently, there will be no code changes to deal with that until the exact cause of the slowdown is known.

Anything else code related (to properly deal with the disappearing problem) will deffinitely wait until after 3.6.9, and probably won't happen until after Kazan has time to do that asteroid field redo that he was talking about. Unfortunately this just isn't a big enough of a deal to get any real coder time until after 3.6.9 goes out.

In the meantime I guess the only option is for you to do whatever you need to do to address your user group. Whether that is mission changes, or using different asteroid models, is up to you.

Altough I don't actually anticipate that this will have any sort of affect (at least not positive), try out this VP and see if it does anything: http://icculus.org/~taylor/fso/misc/asttest.rar

Tolwyn

2006-12-05 19:37

reporter   ~0007237

is it the same vp you gave me a week ago?

And yes, this seems to affect a very low number of people, although I can't tell this for certain. In FS2 you usually do not use time compression and asteroid fiels are also very rarely used.

taylor

2006-12-05 20:20

administrator   ~0007240

It's nearly the same filename (didn't do that on purpose), but it does have a few minor changes. It has a new asteroid.tbl which changes the detail level bumps, the same texture maps that you tried before, and slightly modified asteroid POFs which fix the radius values (just in case). But as I said, I don't really expect this to make much, if any, difference.

But since we don't know exactly what the problem is, any change is worth a test to see if it makes any sort of a difference. It will either do nothing, make the problem worse, or make the problem better. In any of those cases it at least provies a clue as to what the actual problem might be. If the radius change helps then it could be physics related, in which case the fixed data might be all that's needed. If it doesn't help then we've just ruled one more thing out.

Tolwyn

2006-12-05 21:43

reporter   ~0007241

Last edited: 2006-12-05 21:49

okay, I inserted it into the beta folder. Since it starts with a it will be used instead of prologue_core/ships.

Result: same as before.

I'll ask someone, who experienced slow downs, to test the VP file.

taylor

2008-02-22 19:42

administrator   ~0008900

Give this build a try: http://icculus.org/~taylor/fso/willrobinson/Xt0222-win32.rar

It should reduce the popping problem. I tweaked the routine there to base its distance checks on the radius of the asteroid field box rather than the fixed 3,000 it used previously. Also, it will now bounce asteroids that are less than 30% past the radius boundary and still in your view. The "bounce" is where it simply reverses the asteroid direction rather than warping it to a different location.

So now it is still going to "pop", but it should be far less noticeable. Let me know if this new behavior is acceptable, or even whether makes any difference in this case.

taylor

2008-07-17 16:32

administrator   ~0009465

My work on this is in the Xt tree, but one of the other devs will need to go through it and figure out if what I was doing was right and/or finish/replace it.

Tolwyn

2008-07-17 16:50

reporter   ~0009482

This issue can be closed, because time compression is no longer used.

phreak

2008-07-18 20:10

developer   ~0009488

that still doesn't mean we should ignore it happened in the first place

chief1983

2008-10-09 16:31

administrator   ~0009891

Tolwyn, any chance you can verify, just for S&G's, that this doesn't still happen with a newer build and an older copy of your project that uses the time compression?

portej05

2009-06-06 06:16

reporter   ~0010945

Is there any further update on this issue?
Last comment was on 09/10/2008 (DD/MM/YYYY)

Tolwyn

2009-06-09 07:09

reporter   ~0010970

As I said, no longer relevant for Saga. As far as I am concerned, this can be closed.

Issue History

Date Modified Username Field Change
2006-11-20 08:12 Tolwyn New Issue
2006-11-23 09:15 Tolwyn Note Added: 0007150
2006-11-23 09:52 Tolwyn Note Added: 0007151
2006-11-25 21:30 taylor Note Added: 0007169
2006-11-25 21:30 taylor Status new => assigned
2006-11-25 21:30 taylor Assigned To => taylor
2006-11-26 17:58 Tolwyn Note Added: 0007179
2006-11-26 18:03 taylor Note Added: 0007180
2006-11-26 18:08 Tolwyn Note Added: 0007181
2006-11-26 18:13 Tolwyn Note Added: 0007183
2006-11-26 19:11 Tolwyn Note Added: 0007186
2006-11-28 09:24 Tolwyn Note Added: 0007206
2006-11-28 09:26 Tolwyn Note Edited: 0007206
2006-11-28 09:37 taylor Note Added: 0007207
2006-11-28 09:53 Tolwyn Note Added: 0007209
2006-11-28 09:59 Tolwyn File Added: screen0022.jpg
2006-11-28 10:00 Tolwyn File Added: screen0023.jpg
2006-11-28 10:00 Tolwyn File Added: screen0024.jpg
2006-11-28 10:01 Tolwyn Note Added: 0007210
2006-11-28 16:01 ARSPR Note Added: 0007211
2006-11-28 16:01 ARSPR Note Edited: 0007211
2006-11-28 16:03 ARSPR Note Edited: 0007211
2006-11-28 18:58 Tolwyn Note Added: 0007213
2006-11-28 19:30 ARSPR Note Added: 0007214
2006-11-28 19:38 Tolwyn Note Added: 0007215
2006-11-28 20:23 taylor Note Added: 0007216
2006-11-28 21:16 Tolwyn Note Added: 0007217
2006-11-29 10:13 Tolwyn Note Added: 0007219
2006-11-30 12:45 Tolwyn Note Added: 0007225
2006-12-05 10:29 Tolwyn Note Added: 0007231
2006-12-05 10:31 Tolwyn Note Edited: 0007231
2006-12-05 19:09 taylor Note Added: 0007236
2006-12-05 19:37 Tolwyn Note Added: 0007237
2006-12-05 20:20 taylor Note Added: 0007240
2006-12-05 21:43 Tolwyn Note Added: 0007241
2006-12-05 21:49 Tolwyn Note Edited: 0007241
2008-02-22 19:42 taylor Note Added: 0008900
2008-07-17 16:32 taylor Note Added: 0009465
2008-07-17 16:32 taylor Assigned To taylor =>
2008-07-17 16:32 taylor Status assigned => new
2008-07-17 16:50 Tolwyn Note Added: 0009482
2008-07-18 20:10 phreak Note Added: 0009488
2008-10-09 16:31 chief1983 Note Added: 0009891
2009-06-06 06:16 portej05 Note Added: 0010945
2009-06-06 06:16 portej05 Status new => feedback
2009-06-09 07:09 Tolwyn Note Added: 0010970
2012-04-03 13:47 Echelon9 Status feedback => closed
2012-04-03 13:47 Echelon9 Resolution open => fixed