Oolite Bulletins

Ok.. thanks.. that makes sense..

Commander McLane wrote:

How is the collision radius defined? The largest extension of the entity along any one axis? Then I could keep ships out of that radius until the player gets into scanner range.

It is a value based on the shortest and longest axis:
collision radius = (length_longest_axis + length_shortest_axis)/2;

When looking at the genship mod file I see:
// model size: 5625.000 x 5625.000 x 6500.000
So there is not so much difference between shortest and longest axis. I did notice that the model is very incorrect centred. The origin is defined in its nose. This will probably look bad when it makes a turn.

Commander McLane wrote:

Diziet Sma wrote:

why would improved collision detection at close range to the player be "not entirely in the spirit of Oolite’s design"?

Because Oolite (unlike Elite) isn't player centred. In principle everything in the system should work all by itself, regardless how close or far the player currently is.

Unlike this, in original Elite the player was always in the centre of the action. Everything else was only added around him. I guess the 8-bit computers just couldn't run an entire system when effectively nobody was looking. Modern computers, however, can.

i.e. those flashes in the distance as a pirate blows a hole in the side of an undefended Anaconda - have the same collision detection algorithms and precision working for them as they do for what's going on around us when we're flying. So, what would the consequences of fiddling with collision precision near the player ship have? Distant epic battles never happen because the ships spontaneously blow up because collision detection for them never happens properly?

In the original 8-bit Elites the player ship was at 0,0,0 and stuff was added just off scanner range along your current vector - when you used the Torus Drive - the sun/planet rushed towards you - not the other way round - for those with large egos in 8-bit Elite you really were at the centre of the Universe!

Eric Walch wrote:

Commander McLane wrote:

How is the collision radius defined? The largest extension of the entity along any one axis? Then I could keep ships out of that radius until the player gets into scanner range.

It is a value based on the shortest and longest axis:
collision radius = (length_longest_axis + length_shortest_axis)/2;

When looking at the genship mod file I see:
// model size: 5625.000 x 5625.000 x 6500.000
So there is not so much difference between shortest and longest axis. I did notice that the model is very incorrect centred. The origin is defined in its nose. This will probably look bad when it makes a turn.

Thanks for the formula! I have already centred the Generation Ship, so the model size is now 6412.5 x 6412.5 x ~30400. (And the main entity is the head, not the barrels!)

If the collision radius is based on the average, this also explains why NPCs can fly through the Generation Ship's nose and tail unharmed, but not along its side.

DaddyHoggy wrote:

i.e. those flashes in the distance as a pirate blows a hole in the side of an undefended Anaconda - have the same collision detection algorithms and precision working for them as they do for what's going on around us when we're flying. So, what would the consequences of fiddling with collision precision near the player ship have? Distant epic battles never happen because the ships spontaneously blow up because collision detection for them never happens properly?

As Eric explained already on the previous page, that is exactly how it is working right now. You still see battles in the distance, because for normally sized, not hugely aspherical ships Oolite's routine works just fine. We only get into trouble with "big cigars", like the Generation Ship.

DaddyHoggy wrote:

Distant epic battles never happen because the ships spontaneously blow up because collision detection for them never happens properly?

Seems to be that way. I wonder why they were set to blow up instead of disabling the collision detection for them (or modify it to a very strict collision requirement)...I would guess that makes more sense than having them to collide more easily and even reduce the CPU load.

Screet

Screet wrote:

I wonder why they were set to blow up instead of disabling the collision detection for them (or modify it to a very strict collision requirement)...

I assume both ways are tested in the past and this came out as best. e.g. scooping pods is triggered by collision. For most instances when a ship is approaching to the collision radius it will hit the real texture a fraction of a second later anyhow.
Only when actually seeing it, it must be correct. And as McLane writes: for normal ships this is no problem at all. Only when creating ships in dimensions Oolite was not designed for, you can expect strange things.

Eric Walch wrote:

e.g. scooping pods is triggered by collision.

Really? I recently had about 20 splinters as a big bundle being scooped...they were INSIDE my Caduceus, but the scoops could not bring them aboard. I had to use the injectors to abort scooping and then scoop them one by one again.

Was a funny screenshot with that immense bundle inside my ship

Screet

Screet wrote:

Eric Walch wrote:

e.g. scooping pods is triggered by collision.

Really? I recently had about 20 splinters as a big bundle being scooped...they were INSIDE my Caduceus,

I only wrote triggered, not scooped. Once triggered it starts pulling in towards the scoop position. For that occasion collision detection is set of totally.
That it is pulled inside the ship is because of a missing or wrong scoop position. When defining that position on a hull location, the splinters should be pile up at that position. And a bundle dangling at the bottom of the ship looks better than inside the ship.
It is most likely a missing scoop position. I never have seen a ship that had it defined except the boa in my personal oolite. Not even Oolites own ships use it. I have no idea why.

Screet wrote:

Was a funny screenshot with that immense bundle inside my ship

Sounds entertaining.. can we see it?

Diziet Sma wrote:

Sounds entertaining.. can we see it?

I really could not scoop them in and had to abort

Screet

Eric Walch wrote:

Commander McLane wrote:

How is the collision radius defined? The largest extension of the entity along any one axis? Then I could keep ships out of that radius until the player gets into scanner range.

It is a value based on the shortest and longest axis:
collision radius = (length_longest_axis + length_shortest_axis)/2;

Um, really? Are you sure that’s not no_draw_distance you’re looking at? (Even then, in trunk that uses a calculation similar to the collision radius except flashers are included.)

The collision radius is supposed to enclose the entire entity. For ships, this means the union of the collision spheres for the main ship and all its subentities. The collision sphere for an individual entity is calculated as the distance from the origin to the vertex furthest from the origin. Subentity spheres are added to the master sphere as the greater of the original sphere radius and the distance to the subentity’s origin plus its collision radius.

For code spelunkers, the root radius is set implicitly in -setMesh: (which gets it from the OOMesh), and subentities are added in in -addSubentityToCollisionRadius: (in 1.74) or addSolidSubentityToCollisionRadius: (in 1.73).

It’s important to note that the collision radius is only used for initial collision testing. If the collision radius test passes (i.e., the collision spheres intercept), octree tests are used for actual hit testing.