Collision detection seems like one of those technical details that shouldn't need a vote.

Any way they're implemented, from the users perspective everything should detect collisions normally - even if the engine is cheating in the background, the user should ideally never be aware of it.

So long as everything appears to "just work", the number of NPCs is only limited by Josh's ability to keep LT performant (something that may as well be programming-sorcery as far as most of us are concerned).

agreed, for detailed purposes, let super accurate collisions happen around the player, and more simple ones happen elsewhere. I do not think that they should be totally disabled though, I don't want npcs to be able to move through planets because I am far away, nor do I want them to collide with the jumpgate and get stuck for the same reason...

Yup, that's pretty much what I was hoping for. As to getting stuck in objects as the player approaches - that's horribly easy to deal with.

Out of visual range (100% and up): No collisions except for large objects like planets and stars
Distant visual range (50% to 100%): Spherical collisions only (i.e. pretend each ship and object is a sphere when you check for collisions)
Close-by visual range (0% to 50%): Use collision models for detailed collision detection

And there you go.

With Distant visual range, it'll be too far away for you to really tell that the ship isn't using a high level of collision detection - you'll just be able to tell it's avoiding collisions.

As to when you get closer to an object, that's easy. If an object switches from OutOfVisualRange to DistantVisualRange and is inside an asteroid, you give it a quick grace period of one frame, move the ship to just outside the object they'd be colliding with, and move on. As it's just entering very distant visual range, the player won't have a clue that the ship was ever inside an asteroid at all. You can do the same thing with Close-By visual range to Distant visual range, too. It gives you the advantage of not having to really check much for collisions, and if done right, you'll be able to fly through as many space stations as you wish... Although Josh's space stations don't appear to look like anything you can fly through. The sector thing I mentioned earlier will cut down on a huge portion of distance checking, too, and keep framerate high.

This does mean, however, that the NPC collision avoidance AI will have to alter itself depending on how far away you are, but that's fine, and can be easily taken care of.


At Just_Ice_au: I think the OP was more asking which people put a higher priority over: NPC count or collision detection. I agree with you, though. It isn't a question of giving one up for the other - it's just a question of how Josh is going to do it.

Talvieno wrote:Out of visual range (100% and up): No collisions except for large objects like planets and stars
Distant visual range (50% to 100%): Spherical collisions only (i.e. pretend each ship and object is a sphere when you check for collisions)
Close-by visual range (0% to 50%): Use collision models for detailed collision detection

I wrote a reply in this thread yesterday that said basically this...

...and then I deleted it because I kept coming up with too many special-case scenarios.

What are the objects that will exist in large-scale form (relative to an imaginary avatar) in LT? In rough order of increasing size:

• ships
• stations
• asteroids
• planets
• stars

Because all non-ship objects are fixed in space (with the possible exception of stations), the only meaningful collision condition needing to be handled will be ships bumping into the items in this list. Asteroids, planets, and stars will never collide with each other.

So, questions:

1. How would targeting work for NPCs who can be inside each other's ship (if both are a long way away from the player)? Do I take damage if I shoot a missile at another ship that I'm "inside" that then impacts almost instantly? If NPC fighters can go inside an enemy cap ship, wouldn't they all wind up in a ball at the approximate center of such ships?

2. If NPCs can be allowed inside asteroids beyond a particular distance from the player's character, how do scanning and mining work? What about stealth -- would hiding become a lot easier?

3. Should it be a gameplay mechanic that all ships burn up if they get too close to (or go inside) a star?

All of these things, and probably more that I haven't thought of, seem to get in the way of a simple "beyond this distance, turn off complex or spherical collision detection for ships" algorithm.

I should add that the only thing I'm trying to poke holes in is my own understanding of how to optimize collision detection. I won't be surprised if there's an elegant way to handle all this and I'm just not seeing it.

I'd assumed that only ships need to be checked for collisions against other objects. This makes things considerably simpler, and faster, than it would be otherwise - a little advantage to having immobile asteroids and debris.

As to question #1:
It's simple. That'll practically never come up. The reason for this is that AI would automatically swerve to avoid coming within a certain distance of any object, including other ships - if they smash into something, they're more or less screwed, and they wouldn't want that, would they? Even if, by some bizarre circumstance, they ended up inside each other, they would simply turn and move away, like putting two reversed magnets next to each other.

#2. You saw in the last update that mining and scanning works just fine - keep in mind there weren't any collisions going on, and while there was a single bizarre incident where a large mining ship got "stuck" in an asteroid as a "monument" (as Josh called it), that was it. Everything else functioned normally, and apart from that, the lack of collisions was practically unnoticeable.

And for #3:
Yeah. But, that won't come up, unless it's you. Stars and planets should always be avoided by NPCs, no matter what. In fact, NPCs would probably avoid asteroids, too. Instances where they would actually collide are likely to be few and far between. Instances where they go through a star? That's pretty much zero.



Collision handling is part detection, and part active avoidance. If you can get AI to recognize where an enemy ship is, it's much less likely that they'll collide. This would likely go on throughout the entire system all at once, unless Josh turns it off to save on frame rate.

Basically... if the ship collides in the first place, you're doing something wrong, or the ship was forced into it. Collision detection should be primarily for players, and weaponry. (weaponry is a bit harder to deal with, but not really - they're basically tiny spheres themselves.) (which reminds me, you forgot weapon fire. )

Maybe base collision not around absolute distance but around apparent size of the object.
For smaller sizes you can lower collision LOD pretty fast, but larger ships should use full collision checks for a longer time.
(May replace apparent size with size factor of the ship, amounts to the same and needs no additional calculations)

Cornflakes_91 wrote:Maybe base collision not around absolute distance but around apparent size of the object.
For smaller sizes you can lower collision LOD pretty fast, but larger ships should use full collision checks for a longer time.
(May replace apparent size with size factor of the ship, amounts to the same and needs no additional calculations)

It's not really so much the size of the ship as its X to Y to Z ratio. If it's 100 meters by 1 meter by 1 meter, that'll throw off targeting unless you say "aim for this specific part of the ship". (You'll notice in the last update video that NPCs are absurdly inaccurate.) If it's a Borg-like cube at 100 meters by 100 meters by 100 meters, then you only have the edges to worry about. For ships, it would be best to fit their base collision boxes into a rectangular prism, probably, and use that instead of a sphere.

Talvieno wrote: It's not really so much the size of the ship as its X to Y to Z ratio. If it's 100 meters by 1 meter by 1 meter, that'll throw off targeting unless you say "aim for this specific part of the ship". (You'll notice in the last update video that NPCs are absurdly inaccurate.) If it's a Borg-like cube at 100 meters by 100 meters by 100 meters, then you only have the edges to worry about. For ships, it would be best to fit their base collision boxes into a rectangular prism, probably, and use that instead of a sphere.

If we just use mass (or thr size factor as i called it earlier) we'd become aspect ratio agnostic.
So you can say that "everything inside the weight class of an battleship must use full collision up to an distance of 30km"
or everything along those lines.
The exact lenghts of the ship do not really matter.

Cornflakes_91 wrote:

Talvieno wrote: It's not really so much the size of the ship as its X to Y to Z ratio. If it's 100 meters by 1 meter by 1 meter, that'll throw off targeting unless you say "aim for this specific part of the ship". (You'll notice in the last update video that NPCs are absurdly inaccurate.) If it's a Borg-like cube at 100 meters by 100 meters by 100 meters, then you only have the edges to worry about. For ships, it would be best to fit their base collision boxes into a rectangular prism, probably, and use that instead of a sphere.

If we just use mass (or thr size factor as i called it earlier) we'd become aspect ratio agnostic.
So you can say that "everything inside the weight class of an battleship must use full collision up to an distance of 30km"
or everything along those lines.
The exact lenghts of the ship do not really matter.

Actually, they rather do matter, but not so much the length as the ratios between length/width/height. Even a 1m by 0.1m by 0.1m ship is taking up less than 1% of its cubic (or spherical) boundaries.

Like I said above, encasing the ship in a rectangular prism will solve the collision issues at a distance, as it's unlikely we'll have any ships that look incredibly bizarre, or even anything that looks like the Enterprise... Although I'd like to point out that it's a safe bet that if anything came within a rectangular collision box for the Enterprise, it would still be incredibly likely to hit whatever that object was.

Large ships, if you have exceedingly accurate collisions for them, will be many, many times more processor-intensive ratio-wise than their smaller counterparts. It's best to just use a collision box for them when they're off in the distance.

I do think, though, that if they're large enough, they should always have collisions enabled, if that's what you're saying, but I don't think we should assign an arbitrary value to said ship.

Also, the larger they get, the larger their AI collision avoidance margin would be, making it so that if they were too wide to enter an asteroid field, even with collisions turned off, they should never attempt to enter that asteroid field in the first place.

If an NPC hits something, the AI is broken. NPC collisions should almost never happen unless the NPC is forced into it by avoiding something else. Collision avoidance shouldn't be needed at all outside of line-of-sight, unless we want ships smashing into stuff all the time during gameplay, which looks... well, broken, frankly. Collision avoidance is done using spheres, and is pretty easy to calculate. You just turn the ship away from the object when it gets too close, and that's that. You could even do it at any distance you wish without it having too much of a negative impact on performance.

im not talking about which form those low-lod detections should have but at which distance we switch to lower LOD.
For a small ship we can lower LOD pretty fast.
But on a big ship you probably need to maintain high-lod for quite a while.

Not discussing if we should use cubes, spheres or whatever for LOD, but at which distance we star to use simpler models

If we're going to do that, I personally think it would be better to lower it dynamically... for example:

distanceLowerLOD = shipMass * 10;

so that a ship with a mass of 100 has its LOD lowered at 1000 units, while a ship with a mass of 10,000 has its LOD lowered at 100,000 units. That way there won't be a sharp cutoff point for everything, and we don't need to say:

if (shipMass > 500) {
if (shipDistance > 100000) {
lowerDetail(ship);
}
} else {
if (shipDistance > 1000) {
lowerDetail(ship);
}
}

That said, I don't really see the point, honestly. If it's too far away to see, it's too far away to see. Likewise, if it's too far away to see clearly, then it's too far away to see clearly. At such great distances, it won't really matter if the ship is colliding with an object just because it has a slightly protruding point somewhere along the hull - you won't be able to tell. At point-blank distance, maybe - or if you make a ship that looks like a giant cross (which I would strongly advise be impossible simply for the sake of AI navigation).

A clearer determinate for LoD is the screen-space a model takes up.
There's nothing wrong with, or particularity difficult to navigate about, a cross shaped ship. It's still made of convex shapes.

For low lod, would it make sense for weapons collisions to take the volume of the ship/module divided by the volume of the collision box to get a hit chance?

Katawa wrote:A clearer determinate for LoD is the screen-space a model takes up.
There's nothing wrong with, or particularity difficult to navigate about, a cross shaped ship. It's still made of convex shapes.

I was thinking for ships that were significantly larger than asteroids. It would be next to impossible to write the AI so it could navigate an asteroid field with that kind of ship (expecting to avoid the asteroids by flying past them in the gaps in the + shape) - at least without killing the CPU.

Talvieno wrote:I was thinking for ships that were significantly larger than asteroids. It would be next to impossible to write the AI so it could navigate an asteroid field with that kind of ship (expecting to avoid the asteroids by flying past them in the gaps in the + shape) - at least without killing the CPU.

That sort of thing is fairly simple with field-based pathfinding, flow field being one of the more popular ones currently, the areas between rocks contain a certain amount of 'flow' based in the space available, the ship just checks its flow requirement against what's available.
Because asteroids are static this is very cheap pathfinding.