Oolite Bulletins

Decouple rarity of ships from rarity of equipment on them.
I made a ship 1.0 rarity, and I saw it for sale carrying LOTS of Passenger Berths.
Filled up completely in fact.

Switeck wrote:

I made a ship 1.0 rarity, and I saw it for sale carrying LOTS of Passenger Berths.
Filled up completely in fact.

That sounds like a bug. How many passenger berths was the ship allowed to carry?

i'd far prefer good/better collision detection that 3d suns. i don't see the point of the sun thing, i like them the way they are, they should be too bright to see much/any detail anyway. w/ better collision tho, far better and more interesting models like the hacker asteroids etc could be made that wouldn't be ruined by the "flying through walls" thing.
but, whatever. it's not like this is up for vote.

Probably the best way to get better collision detection is if we were to switch the internal coordinate system so that internal coordinates become relative to the player's ship. (NB: we could still use a witchpoint based coord system when we interact with it via js, so the actual coord settings for oxp object placement won't have to be touched!)

That way we could - relatively easily - have a bubble of space around the player where everything is calculated extremely well, and only do approximate collision detection in the distance to save on processing time - hapless NPCs in the far, far away distance will still have some collision detection problems & the occasional jitterness, but hey - out of sight, out of mind, I s'pose...

Edit: if we downgrade collision detection in the distance for 2.0 (there's a few possible shortcuts that could then be used to still produce realistic-like scooping & battle results) we could get many more in-system objects for a given frame rate! Something to think about...

Kaks wrote:

Probably the best way to get better collision detection is if we were to switch the internal coordinate system so that internal coordinates become relative to the player's ship. (NB: we could still use a witchpoint based coord system when we interact with it via js, so the actual coord settings for oxp object placement won't have to be touched!)

That way we could - relatively easily - have a bubble of space around the player where everything is calculated extremely well, and only do approximate collision detection in the distance to save on processing time - hapless NPCs in the far, far away distance will still have some collision detection problems & the occasional jitterness, but hey - out of sight, out of mind, I s'pose...

Edit: if we downgrade collision detection in the distance for 2.0 (there's a few possible shortcuts that could then be used to still produce realistic-like scooping & battle results) we could get many more in-system objects for a given frame rate! Something to think about...

I think I can see the outlines of a possible insider joke here:

- "Hey, what is this Oolite they're all talking about?"
- "It's like Elite, only that it isn't player-centered."
- "Cool, and what about this Oolite 2.0?"
- "That's like Oolite, only more player-centered."

Kaks wrote:

Probably the best way to get better collision detection is if we were to switch the internal coordinate system so that internal coordinates become relative to the player's ship. (NB: we could still use a witchpoint based coord system when we interact with it via js, so the actual coord settings for oxp object placement won't have to be touched!)

This isn’t really the issue. The problem with Oolite collision detection is the approach, and the cost is in octree setup and memory consumption rather than actual collision detection. Each raise in octree resolution raises those costs by up to a factor of eight, and we’d need much higher resolution for nice results with big ships.

I’d like to use proper polytope collision detection, and preferably better collision response (imparting angular as well as linear momentum), but I don’t want to implement it myself. Hence my mention of evaluating physics engines above.

We could do with better space partitioning (probably using an “infinite octree” approach – quite unrelated to the current collision octrees). This would benefit range-limited entity searches relative to entities other than the player, too.

Using coarser collision detection away from the player is a much smaller problem.

Weird, I thought we had a few posts already about problems with accurate ship's (& ship's subentites) positioning - jittery movements / noticeable wobbliness in supposedly fixed subentites - once we were sufficiently away from the coordinates' origin...

Anyway, even assuming that positioning is more accurate in 2.0, (solving the positioning issue, which is conceptually different from, but still related to collision detecting: 'that tree just jumped into the middle of the road, officer') moving 0,0,0 to the middle of the player ship would make it fairly easy to have octree resolution degrade smoothly - and take considerably less memory and processing time - the further away from the player we are, even before talking about other possible programming shortcuts (at a sufficient distance from the player - say 10x scanner range - we could just use an rng & a lookup table to determine collision results, laser hits, successful scooping, etc, etc)...

In other words: I couldn't agree more, using coarser collision detection away from the player is indeed a much smaller problem (hence a lot easier to implement & debug), than going for an 'infinite octree' approach!

Kaks wrote:

Weird, I thought we had a few posts already about problems with accurate ship's (& ship's subentites) positioning - jittery movements / noticeable wobbliness in supposedly fixed subentites - once we were sufficiently away from the coordinates' origin...

There are precision issues when you go hundreds of times further from the original than usual, but that’s unrelated to collision detection.

There are two things we can do about the precision issue:

1. Switch to double-precision vectors throughout. This won’t fix everything, since we’ll have to boil them down to single-precision transformation matrices, but it will avoid intermediate precision loss and cumulative error, giving us at least a few orders of magnitude more space.
2. Implement a hierarchical coordinate scheme, which could permit arbitrarily large space, even to the point of allowing direct flight between systems over many years of gameplay, and would require huge changes.

I’m prepared to evaluate option 1. I’m not touching option 2 with a bargepole.

Kaks wrote:

moving 0,0,0 to the middle of the player ship would make it fairly easy to have octree resolution degrade smoothly - and take considerably less memory and processing time

No, it really wouldn’t make it any easier to do that, and it would use more memory and processing time because octree data is currently generated once, shared between all instances of a ship, and cached.

Important context detail: octrees aren’t used for space partitioning in Oolite 1.x. They’re used to store a voxel representation of each ship.

Kaks wrote:

In other words: I couldn't agree more, using coarser collision detection away from the player is indeed a much smaller problem (hence a lot easier to implement & debug), than going for an 'infinite octree' approach! :)

The point of the infinite octree (a spacial partitioning scheme with no fixed boundary, once again unrelated to the current voxel octrees) is to reduce the number of candidate collisions (and also the number of candidates for scan/search operations, which are a non-trivial cost).

I actually implemented an infinite octree last year, for something completely different It doesn’t have all the necessary cleanup functions, but the infinite bit is easy. (“Infinite” in this case means “really big”, namely up to 2⁶⁴ buckets. If each bucket was 50 × 50 × 50 km for Oolite – a reasonable size for collision partitioning purposes – that would conveniently match the size of the observable universe. See precision option 2 above, but the problem of integrating a bunch of things in different local coordinate systems is much bigger than the octree. On a further digression, with a 64-bit fixed-point coordinate scheme within each bucket we’d be able to position anything in the universe to ten-picometre precision, which would be kinda neat. Hmm, I wonder what sort of coordinate representation Infinity uses…)

Commander McLane wrote:

Switeck wrote:

I made a ship 1.0 rarity, and I saw it for sale carrying LOTS of Passenger Berths.
Filled up completely in fact.

That sounds like a bug. How many passenger berths was the ship allowed to carry?

I was creating a hack of the Constrictor with all its stats set "beyond ridiculous" for quick testing of almost everything I could think of. I wanted it to be an extremely fast "set of eyeballs" so I could watch whatever was happening in a system without using a debugger. And not have to worry about a full cargo bay. So I set its cargo max to 32,767 TC.

But for whatever reason the ship wasn't for sale where I expected it at TL 14-15 worlds. So I set the rarity to 1.0 ...even then I screwed up because I didn't realize that "techlevel = 14;" in its shipyard.plist file actually means TL = 15 in terms of where it will constantly appear and only rarely/occasionally appear at TL 14.

I set its cost to 2,000,000 credits as I had ~2.5 million credits in my savegame that I was going to use to buy it. So when one finally appeared, I expected it to cost about 2.0-2.1 million credits. Instead, it cost ~7.5 million credits ...because it came with 6,553 Passenger Berths.

I had something similar when designing the Boa Clipper, I recall. I set the 'chance' to 1.0 so I could easily buy one for testing, and spent ages wondering why they never had the 150TC capacity they should, until I noticed they all came with loads of Passenger Berths

Masochistic mode? I'm not sure we really want to encourage that type of play!

About the collision detection stuff, I was thinking that having the coordinate system actually centered on the player would certainly help when positioning the player, and make possible collisions easier to compute & the player's ride smoother overall.

But given the 2 choices available,

Point 1: sure, I like the sound of 10 picometre granularity!

And as far as 2 goes: I've got the feeling if we had a way to 'walk' between stars in Oolite, way too many of the board members would take the challenge and do just that

Just a thought: if we make the ooniverse coarser than 10 picometres - say .001 metres instead of 1 E-11 metres - then the volume of space we can move about without witchjumping - or changing buckets! - grows from a cube about 50 km across to a cube about 30 light minutes across, which with Oolite scales is probably already halfway to another solar system...
Anyway, I do find the many buckets theory a fascinating concept. Move over multiverse!

No, it really wouldn’t make it any easier to do that, and it would use more memory and processing time because octree data is currently generated once, shared between all instances of a ship, and cached.

Hmm, I don't follow. Ok, we don't move the origin to the middle of the player's ship - it would simplify drawing objects in the player's vicinity, but complicate other calculations, which I assume we don't want to do - but I'm not too sure about the whole of your assessment!

Assuming that a hypothetical low-res voxel representation of the ship is half as accurate of present day's Oolite, and also assuming that the hi-res one is twice as accurate as what we have now, a ship that would need 8KiB worth of voxels would then take 64KiB for the high res, and 1KiB for the low res.

Every time you jump to a new system, all ships would load the low-res one, and the hi-res octree would only be loaded in memory for ships within let's say a cube 5x scanner range centered on the player's ship, giving us a nice 2.5x scanner range minimum distance between the coarser collision detection and the fine grained one.


Most octree generating code, including the one Oolite uses - correct me if I'm wrong - give you the lo-res representation 'for free' on the way of getting to the hi-res one. There is an overhead, true: writing the intermediate data to the cache takes some time, and the cache data for all octrees would be bigger than otherwise. However the low res octree/voxel data is 1/64th - aka less than 1.6% - of the high res one.
In the very 'worse' situation i.e. when all ships & ship models are within the given proximity volume we'd get 101.6% memory usage, and 100% processing time, not really that much worse off!

However, if - in a busy system - the player gets near enough to only 80% of all types of ships in systems, and let's say the most crowded it gets we're only near enough to 40% of all ships.
The resulting memory & processor consumption looks pretty nice to me:
Octrees memory usage - on average 81.6% of the fully high res one.
Per-frame processing time - less than 40.1% of the high res octree version, right? Dealing with 64 times smaller octrees/voxel data takes so much less time!


Anyway, just a few of the possible choices to keep us busy between now and 2.0, I suspect!

Kaks wrote:

Most octree generating code, including the one Oolite uses - correct me if I'm wrong - give you the lo-res representation 'for free' on the way of getting to the hi-res one.

Well, yes, but once we have the high-res octree there’s little point in using a low-res one. Most collisions will be rejected in a collision-sphere test or at a low level of the octree intersection test. Full-resolution octree tests aren’t a problem, but the O(n²) candidate collisions are an important limitation on population count even with quick rejections. Using space partitioning is the standard way of reducing this to O(log n)ish.

Getting decent resolution for the octree for a Coriolis-sized object would require at least three more octree levels. For really big objects, there would be two or three more (an increase of up to 262 144x) – and it would still be inferior to direct mesh collision handling – so I still want to evaluate (not commit to) some of the OSS physics engines.

This is still unrelated to the drawing/simulation precision problem. :-)

Ahruman wrote:

Getting decent resolution for the octree for a Coriolis-sized object would require at least three more octree levels. For really big objects, there would be two or three more (an increase of up to 262 144x) – and it would still be inferior to direct mesh collision handling – so I still want to evaluate (not commit to) some of the OSS physics engines.

All the more reason to switch to higher res octrees only in close proximity to the player!

And yes, I did like the cut of Ogre's gib, many moons ago. Someone had started writing a space / planetary system extension for it too, but didn't get too far, though...

edit: it might be interesting to contact these guys directly:
http://www.titaniumarts.com.au/index.php

Kaks wrote:

And yes, I did like the cut of Ogre's gib, many moons ago. Someone had started writing a space / planetary system extension for it too, but didn't get too far, though...

I doubt it would be of interest. I don’t intend to swap to realistic system-scale physics, just mesh-mesh collisions and ray casting.

I’ve split a big chunk of discussion to Oolite 2: ship balance, starting conditions and death knells.