Conversation
|
The only case I can see that going wrong in theory is if there were a series of irregular large objects, at particular positions, the largest of which was considerably over 5km long, positioned with its near edge close to or just inside the rendering boundary, and some other objects with their near edge at just over 55km were large enough to visible at that range, and were occluding the back edge of the massive object. Then the small object would be drawn in the first pass, and overdrawn in the second pass by the back edge which is actually in front of it. I don't think there are any in-game objects even in OXPs which are >>5km in size but not basically convex, though, so I doubt there's anything to worry about here. I'll give it a try in-game soon. |
…t the corner of the screen with a high FOV setting
|
One issue: pausing the game in flight temporarily blanks everything but the HUD elements, because all frames have the same game time after that. Another issue: there are some slightly odd effects with large objects like planets, around the edges of them. I flew close to the planet surface and then did |
|
I've replaced the timestamp with a simple counter which has fixed the first problem. The second problem is going to be tricky! |
|
Next attempt - this one scans through the list of entites and tries to find a workable boundary between first and second pass. |
May help with issue #134 or may be entirely unrelated.
|
This seems to be working okay now - I couldn't see any oddities with the earlier asteroid set up. Time to merge it? |
|
I've noticed that the branch was recently updated to not conflict with master. Is it considered ready for a merge? Playing devil's advocate here, I have been going through the early posts that generated the pull request that this branch refers to and I couldn't find the exact reason why a 50Km intermediate clear depth distance is a better option than what we have now. Chris did mention that he originally intended to have the boundary at 50km, but not the exact reason why. Is it because of expected performance improvements, resolving a problem that used to exist (but maybe not anymore), or something else that I may be completely missing? |
|
I've just flown out to an absurd distance in master to see if I could spot any issues. I didn't see any, despite flying out to a point where the sun was just a couple of pixels across, so I guess there isn't an obvious problem currently. If we expanded the game to include much more distant objects then we might run into problems (maybe something shows up in the rescaling branch at large distances?) but otherwise I think we're fine. |
|
Comment from forum user Frame, who has been experimenting with the contents of this PR at extreme distances: Im not to impressed by the hard limit of 10 million km, since this causes the planet to just vanish while it is still rather large. the source (1.85) without the diff file applied did the sam ething [as this video: https://www.youtube.com/watch?v=e03qmsNYbkM shows], but however created more "blotches"..[Note: ;blotches' refers to noise on the planet texture that looks like TV static and which seems to appear at huge planet distances] |
|
While the game engine uses 64-bit positioning, the Open GL library still
only uses 32-bit - so objects at extreme ranges get a lot of graphical
artifacts.
For suns I dealt with this by displaying them at a maximum distance of
(I think) 10^9 and scaling them down for display if they were really
further away than that.
No other standard-ish game object was practically visible at that range,
but something similar (plus some faked depth buffering so that the overlap
is the right way round) is probably needed for large planets if ones still
practically visible at 10^10 are being checked.
|
HiranChaudhuri
force-pushed
the
master
branch
12 times, most recently
from
32b2c88 to
f985059
Compare
HiranChaudhuri
force-pushed
the
master
branch
5 times, most recently
from
4d65277 to
be540a2
Compare
|
@oocube I'm not clear from the discussion above if the issue this PR is meant to fix is still an issue (or was still an issue back then) |
|
@mcarans I cannot tell. But it is from 2015, so conflicts are visible and to be expected. What's the likelyhood we get this fixed? |
|
@oocube I'm not sure if this change fixes anything. We need someone involved in the original discussion. @kanthoney, @cim-- calling out to you both for comment on this. |
|
It's a long time ago, but I think the problem was that cim wanted to
increase the MAX_CLEAR_DEPTH constant in MyOpenGLView.h from 10000000 to
10000000000, possibly to stop planets from disappearing if anyone flew more
than 10,000km away from them. Unfortunately, you can't simply increase this
number because, if it gets too big, the depth buffer loses resolution and
OpenGL can't always tell which of two objects is closer so you get weird
effects where a closer object is overlapped by one slightly further away.
Cim's solution was to introduce a two-pass render. The first pass rendered
distant objects, with the second pass rendering near ones. Originally the
boundary between the two passes was set at 50km, but this introduced a
visual effect particularly noticeable with planets - if the planet
straddled the boundary, there was an obvious slice taken out of it. So the
boundary between the two passes was set to 100m instead. This introduced a
few visual effects at 100m, such as exhaust plumes being truncated, which I
believe we fixed somehow. But I think we still wanted the boundary to be at
50km, so this was an attempt to find a way of doing that without the planet
slice effect. Essentially, it scans through the list of entities and if one
of them straddles the 50km boundary we use a different boundary. I guess
everyone lost interest in the discussion without merging this
…On Sat, 11 Apr 2026 at 00:23, Mike ***@***.***> wrote:
*mcarans* left a comment (OoliteProject/oolite#153)
<#153 (comment)>
@oocube <https://github.com/oocube> I'm not sure if this change fixes
anything. We need someone involved in the original discussion. @kanthoney
<https://github.com/kanthoney>, @cim-- <https://github.com/cim--> calling
out to you both for comment on this.
—
Reply to this email directly, view it on GitHub
<#153 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABM6GMU7KENSBP3UIY5BGXT4VF67HAVCNFSM6AAAAACXTKRSC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMRXGMYDGMBWGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Kevin Anthoney
***@***.***
|
|
@kanthoney Thanks so much for your detailed reply. What do I need to do to see the exhaust plume issue? Go to an external view of my ship and zoom out to 100m? |
|
Either that or tailing a ship by 100m should show the effect if it's still
there, although I think it was fixed (see
#150). If it was fixed and
nobody's spotted any similar problems in the ten years this pull request
has been kicking around then you probably don't need to worry about this fix
…On Sat, 11 Apr 2026 at 23:35, Mike ***@***.***> wrote:
*mcarans* left a comment (OoliteProject/oolite#153)
<#153 (comment)>
@kanthoney <https://github.com/kanthoney> Thanks so much for your
detailed reply. What do I need to do to see the exhaust plume issue? Go to
an external view of my ship and zoom out to 100m?
—
Reply to this email directly, view it on GitHub
<#153 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABM6GMS3ZZJHQ7UMKDVYODT4VLCCDAVCNFSM6AAAAACXTKRSC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMZQGI4TSNBUGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Kevin Anthoney
***@***.***
|
|
I did not see the issue when using an external view. I posted here: https://bb.oolite.space/viewtopic.php?t=22088. If no one gets back to confirm the issue still occurs in the next couple of days or so, I'll close this PR. |
|
I had a look at the actual file changes. Basically the visibility range is increased, some property including getter/setter are added and then the draw method is patched. If that one failed the problem should be visible all over - maybe easy to verify we are still good (even if not in every corner of Ooniverse) Should we go for a merge and see what happens? I can revert the merge similarly as I did for PR378. |
|
@oocube You're welcome to look into this if you like. I don't know what to look for or expect when making this change. How will you confirm if it works or not or has unwanted side effects? |
|
I have no scientific test plan. More something like a heuristic: Failure would be visible very clearly, and in that case we just take advantage of version control to go back in time and live without it. Does that make sense? |
|
@oocube Aside from visual failure, you would need to check FPS to ensure it doesn't adversely affect the performance of the game. Also visual artifacts may only occur in certain circumstances like at certain distances from objects. |
|
I just noticed this PR does not come from some foreign repo. It is already a separate branch here. |
5 participants
Fix for #151, the imtermediate clear depth should be 50,000.
The way this is supposed to work is by:
Making sure that every object is rendered either in pass 1 or pass 2, not having half an object rendered in both passes. To facilitate this, at the beginning of the render a timestamp is generated, and as each object is drawn it is tagged with this timestamp. On the second pass, if the object already has the correct timestamp it's passed over.
On the first pass (the one for more distant objects), the distance of the near side of the object is checked. If it's within or close to the intermediate depth the object is punted to the second "near object" pass. "Close" in this case means within 10% of the intermediate depth - using the exact figure led to odd effects (atmospheric disturbance, missing asteroids) if the near edge of the object is very close to the intermediate horizon.
If an object is left until the second pass, the far edge is checked and, if necessary, the far plane of the frustum for the second pass is extended so that the whole object is encompassed (the far plane is set to far edge + 10%). This might cause problems if there's an extremely long object in the game, with one end close by and another end an extremely long way off. I don't think there's anything close to that currently in the game, but if one turned up we could probably add a third pass for those.
I haven't noticed any issues in the testing that I've done.