Two pass planet slice

[kanthoney]

Fix for #151, the imtermediate clear depth should be 50,000.

The way this is supposed to work is by:

1. 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.

2. 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.

3. 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.

[cim--]

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.

[cim--]

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 S.addShips("asteroid",50,PS.position,10E3);. Then I flew out and looked at them from a different angle:

and then I flew towards the cluster for a few km

Note what happens as I get closer to the highlighted asteroid: it goes from being drawn in front of the planet's edge to being correctly behind it.

[kanthoney]

I've replaced the timestamp with a simple counter which has fixed the first problem. The second problem is going to be tricky!

[kanthoney]

Next attempt - this one scans through the list of entites and tries to find a workable boundary between first and second pass.

[cim--]

This seems to be working okay now - I couldn't see any oddities with the earlier asteroid set up. Time to merge it?

[AnotherCommander]

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?

[kanthoney]

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.

[AnotherCommander]

Comment from forum user Frame, who has been experimenting with the contents of this PR at extreme distances:
-------- Begin quote ----------
When processed [with this PR's contents] the video of it will be available here

https://youtu.be/Dk5UDIKhFr4

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.
Instead the the size of the planet should be considered for when it is smaller than a pixel. In this respect 1.84 is supirior.

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]
---------- End quote -------------

[cim--]

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.