You would measure distances between planets in AUs, distances between station and planet in kilometres. That could avoid foating point overflows and could also speed up rendering.
Whatever you are displaying for the player, the internal unit is meters and wouldn't change from that. So I don't see how merely displaying the meters as kilometers, AUs, or even ParSec's has anything to do with floating point precision, or the lack of it.
the unit has no impact at all. The precision is only important and using AU just means a lot of decimal places.
The only way to fix it is to use more bytes for the floating points used in coordinates or maybe carve space into sectors and have each point qualified by a sector id or something and that isnt simple.
The bottom line is that the way oolite is means no 'big' systems any time soon
If we cut space into sectors then we would have to convert all position vectors from being a set of three single precision floating point numbers (S.P.F.P.) to being the same set three S.P.F.P. numbers plus 3 Long Integers for the sector numbers. A sensible value for the grid size for the sectors would need to be chosen. After this a considerable amount of rewriting of functions would be needed to make use of these expanded vector objects instead of normal vectors. Such as changes to the expanded vector components when an entity moves from one sector to another. Also some decision would need to be made in how to handle the now legacy position vectors that are set by setPosition in Javascript by existing OXPs plus anything that's done with legacy position vectors via the AIs.
When rendering you would have to select only entities in the appropriate sectors close to the player and map the expanded vector positions back into normal vectors centred on the nearest sector's origin to the player. On top of which you would need to do something to still render the sun if it is outside the rendered sectors. And if that isn't enough there would likely be the need to decide whether to continue to process all the entities in the system (as with these bigger systems you probably want more entities) or only process those within a range of sectors around the player and then what to do about those outside that range.
And there are probably plenty more things I haven't even thought of.
This is not going to be done anytime soon I would have thought.
Last edited by PhantorGorth on Sat Feb 27, 2010 12:16 am, edited 1 time in total.
There is no need to render a space station if it is in the subsystem of a planet which is 0.1 AU away. You don't need to render a planet which is 2 AUs away or a solar system in a distance of 2 Parsecs. Once you have culled those objects you can concentrate to your vicinity. Here you use another scale, kilometres or even meters.
You increase the precision, an object has the distance: 0.4 Parsec + 3.1 AU + 15000 kilometers ... (your coefficients have nice floating point precision). But why should I render that? I render only relevant things, e.g. a sun 2 AU or a station 10 km away.
That's just a suggestion, I don't care if/when you can/will implement it!
There are no AU's, and there are no systems. At any given moment only one single system exists in Oolite. Therefore a remark like "you don't need to render distant suns" makes no sense at all. There are no distant suns. There is only the sun of the current system.
And not rendering distant planets utterly defeats the whole purpose of the idea. After all it is all about displaying multiple planets in a system. What sense would it make to not display them?
Lastly it is not only about rendering. Oolite is not player-centred. Even if you as player don't look, the NPCs everywhere in the system continue to act, to fly, to fight each other, to dock with stations, to launch from stations, etc., etc. Which basically means that the game engine has to know and re-calculate the position of every object in the system all the time. Whether the object is actually rendered is irrelevant. The engine has to keep track of its position and movements. And with decreasing precision in the distance this becomes increasingly impossible to do with the necessary accuracy.
Commander McLane is, as always exactly correct. Rendering is not the problem. The main problem I think is collision detection. Even with current sized oolite, it is quite easy to fly far enough from the station that precision problems cause a bloodbath of docking ships, the explosions of which are still visible. We could possibly do something clever like dock any colliding objects (if one is a station) if they are more than a given distance from the player, but I dont think the general problem is fixable.
My (well, this is a quite common) idea is to build a hierarchy of objects. If you know a planet would be displayed as a point you do not even need to try to render objects in the subsystem represented by that planet. Note, when talking about system and subsystem I do not refer to the Oolite term but to a data structure, the nodes of a tree. A planet could be such a node and define its own coordinate system. You express the positions of its objects (station, ships, moons etc) in the units of the planet's coordinate system. Move the coordinate system and you move all its objects at once. The sun may have a coordinate system measured in a different unit, for instance AU. Using different coordinate systems helps to avoid floating point overflow.
I also know that there is only one active Oolite system. I wanted to point out the potential of the approach. If you were able to cull objects easly and have different coordinate system you *could* render all stars and even galaxies. Of course they were in a frozen state since they are too far away. They could be displayed as a point.
My (well, this is a quite common) idea is to build a hierarchy of objects. If you know a planet would be displayed as a point you do not even need to try to render objects in the subsystem represented by that planet. Note, when talking about system and subsystem I do not refer to the Oolite term but to a data structure, the nodes of a tree. A planet could be such a node and define its own coordinate system. You express the positions of its objects (station, ships, moons etc) in the units of the planet's coordinate system. Move the coordinate system and you move all its objects at once. The sun may have a coordinate system measured in a different unit, for instance AU. Using different coordinate systems helps to avoid floating point overflow.
And if strawberries grew on trees, we’d all have jam on Sunday. (Wait, what? That’s not right…) A complete rewrite of the way Oolite manages objects, to support situations entirely unlike Elite, is out of the question.
