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. |
|
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
17 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. |
…t the corner of the screen with a high FOV setting
oocube
force-pushed
the
two_pass_planet_slice
branch
from
be4a497 to
efb43e2
Compare
|
Looks like the branch builds. I downloaded an AppImage and looks like I can play. So the obvious failure did not happen. :-) Now we can ask more people to download and test the artifacts. |
|
@oocube I suggest you ask for testers on the bb if you haven't already. |
|
I tried an appimage, flew around various objects and all looked ok to me. Others who have played a lot more than I are better qualified to give feedback on it. I didn't notice any speed difference, but then with a gaming laptop it's hard to notice much difference in performance. |
|
If you want to check performance, you must check with fps uncapped, otherwise you are always getting v-sync fps, which is usually a low number like 60 for a 60Hz monitor, 144 for a 144Hz one etc. Add the Edit to add: When comparing builds performance check always with more or less the same amount of entities in the system. If in one case you get 250 entities and in the other you get 70 results may be biased. Try to compare instances where the two system entity numbers are as close as possible. Shift+F shows you this info in test release builds. Edit further to add: Forgot to mention an obviously important detail: you must also disable v-sync to have uncapped fps. You do this by setting the OoliteDefaults.plist key |
|
That is important to know. |
|
@phkb do you know the answer to oocube's question? |
|
Sure. The most complete way of ensuring the system spawns the same way is to override the system population and repopulation functions. When you do that, the only things that are created by the core game are the main station, the sun and the main planet. Everything else is then up to you. You can negate any random factors and spawn in however many ships/stations as you deem necessary. I walked through the process in the Assassins Guild thread on the BB recently. But I'm guessing we don't need information right now - we need an OXP that can be used for system testing. Give me your requirements and I'll put something together. |
|
@phkb Brilliant! AnotherCommander said "When comparing builds performance check always with more or less the same amount of entities in the system. If in one case you get 250 entities and in the other you get 70 results may be biased. Try to compare instances where the two system entity numbers are as close as possible." (as well as some OoliteDefaults.plist changes @oocube what do you think is needed? 100 of the same ship eg. Mamba? |
|
One thing that might already work is to set Oolite's rand seed so we get the same random number sequences. If Oolite works that way. Another one, more powerful though might be to have an OXP that overrides system population possibly by a script or config file we provide. This way different scenarios could be tested - different ships, different number of ships, ... I am not yet sure what is possible or important to test. Maybe the second item is too big to start with. Let's have something that allows us to have 250 ships to be rendered. And we take it from there. |
6 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.