Forums » Bugs
Some asteroid fields, such as Helios P6, stretch on for 60 kilometers (or more?). The result is that as you reach the end of the belt, you can look back over it, and some of the distant rocks seem to disappear. At precisely the right distance, they can even magically disappear and reappear with a slight turning of the ships nose. It looks especially weird at the rocky end of Helios P6, because there is a massive icefield at the other end, which is easily seen to disappear/reappear with its sharp white contrast against the inky blackness of space.
(PS. I know its roughly 60km because there was a storm there and storm exit points show distance)
(PS. I know its roughly 60km because there was a storm there and storm exit points show distance)
I believe the problem is that the asteroids become farther away than the skybox.
There is no skybox. The problem is that there's no "fog" so rather than gradually vanish when roids go out of visibility, they just abruptly vanish. Most games either take place in a confined area or have a "fog" to make things vanish gradually. Maybe the devs could put in a nebula effect.
I think they should just draw the stuff. There would be no fps problem. On my computer the 2 kilometer-across superdense silica/carbonic asteroid cluster sectors give me the fps problem, and sometimes the stations give me a slight problem, but not the 60 kilometer long strings of asteroids, they always run smooth, and are very pretty by the way.
Funny, I always thought that there was indeed a skybox, centered around the player going out to 20km on either side. Might be 40km though.
Rogues explanation, however, makes absolutley no sense.
Rogues explanation, however, makes absolutley no sense.
There is no skybox. The "sky" is drawn on your display, not as a box. There's a whole thread about it. We used to have contests to find out what the game looked like outside the skybox, until two things happened. Firstly, SiliconX crashed a sector by going more than 2^32m from the center, and failed to find a skybox. Secondly, a dev explained to us that there was no skybox.
Err, there may have been some misunderstanding. There IS a skybox, and it IS always centered around your ship. It's true, you can't go outside your skybox, because it's always centered around you.
http://www.vendetta-online.com/x/msgboard/1/4900#64683
http://www.vendetta-online.com/x/msgboard/1/4900#64683
> I think they should just draw the stuff. There would be no fps problem.
The reason things more distant than ~60km are not drawn is not one of framerate. I will try to explain why.
The most commonly accepted way to avoid object "popthrough" (an object is drawn in front of another object despite being behind it) is to have, associated with each pixel on the screen, a "depth value." This depth value, like a color value, has a certain fixed range. If the range is small, popthrough is not avoided (lack of precision, I could demonstrate the consequences graphically if needed), but if it's large, performance suffers. The best way to reduce the needed range is to scale the Z coordinate. (e.g. 0m = 0.0 in the depth buffer, 60,000m = 1.0)
Unfortunately, if you draw outside this new range (in this case, 0-60,000m) some very interesting overflow glitches occur, so most graphics APIs/applications perform a "Z clip" which simply skips all parts of objects that lie outside this range. As a consequence, any pixel which would have been outside the range is simply not drawn, resulting in the "disappearing object" problem, which (most will agree) is a small one compared to object popthrough or overflow-through.
As for avoiding this problem--for those who don't mind near imprecision errors, which can be pretty ugly--adding the far Z-clip plane as a configurable option would probably not be a bad idea.
-:sigma.SB
The reason things more distant than ~60km are not drawn is not one of framerate. I will try to explain why.
The most commonly accepted way to avoid object "popthrough" (an object is drawn in front of another object despite being behind it) is to have, associated with each pixel on the screen, a "depth value." This depth value, like a color value, has a certain fixed range. If the range is small, popthrough is not avoided (lack of precision, I could demonstrate the consequences graphically if needed), but if it's large, performance suffers. The best way to reduce the needed range is to scale the Z coordinate. (e.g. 0m = 0.0 in the depth buffer, 60,000m = 1.0)
Unfortunately, if you draw outside this new range (in this case, 0-60,000m) some very interesting overflow glitches occur, so most graphics APIs/applications perform a "Z clip" which simply skips all parts of objects that lie outside this range. As a consequence, any pixel which would have been outside the range is simply not drawn, resulting in the "disappearing object" problem, which (most will agree) is a small one compared to object popthrough or overflow-through.
As for avoiding this problem--for those who don't mind near imprecision errors, which can be pretty ugly--adding the far Z-clip plane as a configurable option would probably not be a bad idea.
-:sigma.SB
My head hurts from being upside-down and that explaination.
Andy: want to tell Solra why it is as it is?
Andy: want to tell Solra why it is as it is?
"I think they should just draw the stuff. There would be no fps problem" -oops. heh, sorry.
Yeah, our far z-clipping plane is set to 60,000.
Making it larger causes z-clipping artifacts on 16bit z-buffers (running the game in 16-bit color mode) for things like the station when it is far away.
I suppose we could just force 32bit color mode and then extend the far clipping plane but then lower-end video cards will suffer.
We don't fade away objects when they get that far away. That's what we should do to avoid the sudden disappearance of the asteroids at extreme distances.
Making it larger causes z-clipping artifacts on 16bit z-buffers (running the game in 16-bit color mode) for things like the station when it is far away.
I suppose we could just force 32bit color mode and then extend the far clipping plane but then lower-end video cards will suffer.
We don't fade away objects when they get that far away. That's what we should do to avoid the sudden disappearance of the asteroids at extreme distances.
Couldn't you extend it to 65,536m? :D
In actuality, fading would be nice. Like a nebula-ish fog effect.
In actuality, fading would be nice. Like a nebula-ish fog effect.
Well I think I can survive with this bug, until 16bit color becomes obsolete. I doubt it bothers many people. Thanks for the info.
Other thread about this, and snapshots showing an example of this:
http://www.vendetta-online.com/x/msgboard/2/9052
http://www.vendetta-online.com/x/msgboard/2/9052
I want fog....It sounds cool. Please?
Space is supposed to be a void. I think the unrealism of fog would be a far greater annoyance than the disappearing rocks at 60km.
Space isn't a void. It's just not dense.
Nebulas are "dust particles" clouds spread over billions of kilometers. If you'd be _in_ a nebula, you wouldn't notice it as you do when you're in fog and that's because it really isn't dense.
So, it does makes sense, to some degree, to have a faint fog-like effect to mask faraway objects. It wouldn't be "fog", but ratter "nebula" particles, just as we see in most backdrops.
Cool thing is that these fog effects could be tinted to reflect the background images.
I'm just not confident in my OpenGL API knowlege to figure out how background images would show through, though.
perhaps objects should dissapear as they do, but their dissapearance somewhatpartly covered by a transparent fog so that backdrop shows through.
Nebulas are "dust particles" clouds spread over billions of kilometers. If you'd be _in_ a nebula, you wouldn't notice it as you do when you're in fog and that's because it really isn't dense.
So, it does makes sense, to some degree, to have a faint fog-like effect to mask faraway objects. It wouldn't be "fog", but ratter "nebula" particles, just as we see in most backdrops.
Cool thing is that these fog effects could be tinted to reflect the background images.
I'm just not confident in my OpenGL API knowlege to figure out how background images would show through, though.
perhaps objects should dissapear as they do, but their dissapearance somewhatpartly covered by a transparent fog so that backdrop shows through.
Alpha fog (like Bugdom) anyone?
-:sigma.SB
-:sigma.SB
/me hooks up his smoke machine with a barrel of theatrical fog juice and begins the tedious task of fogging out the universe.
this could take a while kids, don't hold your breath. :D
this could take a while kids, don't hold your breath. :D
What's the performance hit caused by alpha fog? I suppose there could be a toggle to turn it off, though...
Solra, just wondering... are you a programmer? You sound like one... :P
Solra, just wondering... are you a programmer? You sound like one... :P