Collision mesh changes for ships, pads, and some tag_landing inclusion #3912

Merged
merged 1 commit into from Jan 31, 2017

Projects

None yet

6 participants

@nozmajner
Contributor
nozmajner commented Jan 18, 2017 edited

Adding tag_landing to Deneb, Venturestar and AC33.
Modifying some collision meshes to have some geometry sticking down to tag_lading height to aid landing collision detection. Some just needed a little adjustment.
Also modifying the pad collision of the ground stations to have a flat planar pad collision mesh, and some additional planes under it to catch stray ships flying high on time accel.
The pad collisions became quite large, to allow for lousier landings, as @jaj22 said: "Ideally if you land on the big flat bit between 6 and 7, it would land, fine you, and then slide you to the correct pad :P" Or to avoid novice players hitting the station floor, and allow their ships to be towed to the pad properly.
For #3901
Sorry for putting them into one commit, stupid git/text editor gave me some problems I noticed too late.

@jaj22
Contributor
jaj22 commented Jan 19, 2017

Ok, gone through all these. The only issue I spotted is that lunarshuttle should have some static collision geometry at the landing tag level, because if the collision model animation code is fixed then it won't dock anymore. Arguably lunarshuttle shouldn't have dynamic collision geometry anyway, but it'll be useful for debugging.

Otherwise this should be fine together with the supporting code (basically remove all usage of Aabb).

@mike-f1
Contributor
mike-f1 commented Jan 19, 2017

@jaj22: I found this (after @nozmajner give me clue) #2493, and I tested it: it works even if you cant't see them. It's more tricky because you must place dynamic collision mesh on the same *dae file in which you have standard mesh.
But this, at least, could help :-) : you could trigger a collision more easily even with lunarshuttle.

Now I think the problem could be to test this, even in combination with #3911 alone.

I will test it now, so we could "un-freeze" these PR.

@mike-f1
Contributor
mike-f1 commented Jan 19, 2017

@nozmajner : I tested with you PR and mine (#3911), but I think this is valid also for actual code on master...
Seems not working, because with current code you neeed collision but if docking surface
is too near to collision, then when ship try landing they hit both. So I modify "starport_docking"
moving surfaces up, and I tried with some ship.

moving up docking surface 0.57:
Sinonatrix => docking (no damage)
Deneb => docking (only at 100x small damage)
AC 33 DropStar => docking (no damage)
Varada => docking (no damage)
Bowfin fighter => docking (no damage)
Xylophis => docking (no damage)
Mola Mola => docking (no damage)
Lunar Shuttle => docking (no damage)
Varada => docking (no damage)
Kanara => docking (no damage)

...when I see all these ships docking I modify the file and tested again:

moving up docking surface 0.25 (<= I doubt here: I don't know how to measure distance in Blender :-/ ):
Sinonatrix => docking (no damage)
Venture Star => docking (no damage)
Pumpkinseed => docking (no damage)
Nerodia => docking (no damage)
Deneb => docking (some damage at 1000x)
Bowfin fighter => docking (no damage)
Wave => not docking if 1000x or more (may tag_landing be too low?)

Last thing I did was (staying docked) put time accel to 10000x and seeing
what happened to AI ship... Well: they seems docking :-)
Here the modified file (then you can check changes):

starport_docking.dae.zip

...So, there's a problem with Wave and small issue with Deneb.
And thank you for your effort :-)

@mike-f1
Contributor
mike-f1 commented Jan 19, 2017

Anphiesma => little damage if 1000x and 10000x
Kanara => docking
Varada => damage if 100x or more
Malabar => docking and no damage
Lunar Shuttle => docking and no damage (!)
Vatakara => docking no problem

...Varada seems take some damage...

@jaj22
Contributor
jaj22 commented Jan 19, 2017

Yeah ok, there's something odd going on here. With the Sinonatrix at LA I can go right up to a 0.3 offset (gear clearly submerged in the pad) with no collision detected.

Are the visible and docking surfaces actually co-planar on ground_station? If so, the collision detection routines may be much less accurate than I expected. Maybe converting positions to floats too early.

@walterar
Contributor

Remember that NPC ships must safely docking at maximum acceleration of time.

@nozmajner
Contributor

@jaj22 Yes, they are co-planar. Are you sure that an actual collision volume isn't needed?

@jaj22
Contributor
jaj22 commented Jan 20, 2017

@nozmajner Yeah, it doesn't know about volumes. It's pure edge vs tri collision. An initial read of the collision code doesn't show any potential issues so I'll need to step through it.

@jaj22
Contributor
jaj22 commented Jan 20, 2017

I'm making false assumptions about how the collision code works. Flagged surfaces have no priority, and only the "first" contact is reported for each edge, so if the collision geometry is arranged in a particular way then only un-flagged contacts will be reported even though the flagged surfaces are intersecting.

This means that co-planar or near co-planar surfaces are generally a bad idea. Instead, on the ground stations, the pad surfaces should be replaced by flagged surfaces, rather than adding flagged surfaces on top.

@Nozmajner Don't bother doing all of them unless it's quick. ground_station with just the small pads replaced is sufficient for initial testing.

@mike-f1
Contributor
mike-f1 commented Jan 20, 2017

@jaj22 : I uploaded a file: with this file I had the reported results (even at high time accel), and docking surface is only 0.25 over the spaceport collision mesh.

@jaj22
Contributor
jaj22 commented Jan 21, 2017

@mike-f1 Well, that (mostly) works for the same reasons: You adjust the station so that ships aren't hitting flagged and unflagged collision geometry at the same time, which works around the problem. However, it won't consistently avoid the unflagged geometry for manual landing, or the first-frame autopilot impact at high time accel, which is probably why you're getting some minor damaging hits. Extra collision geometry also has a performance impact.

@jaj22
Contributor
jaj22 commented Jan 22, 2017

Ok, I managed to test the theory by removing the geometry from ground_station/startport_col.dae (apparently the flagged geometry is in starport_docking.dae). Appears to work correctly with a tiny offset.

@fluffyfreak
Contributor

I don't know if this would work but you might be able to mark the landing pad geometry for collision.
It's been so long since I rewrote all this that it's a bit fuzzy.

This is why the collision geometry extended far above the pad by the way, and that it animated into position.

@fluffyfreak
Contributor

@jaj22 the geometry actually gets the flag added too it in src\scenegraph\Loader.cpp in the Loader::GetGeomFlagForNodeName method.

@jaj22
Contributor
jaj22 commented Jan 26, 2017

Currently the stations essentially have two separate collision meshes: A plain (unflagged) one loaded using Loader::LoadCollision, with flagged geometry loaded separately using node names. It looks like you could instead have a single collision mesh with both flagged and unflagged surfaces, which may or may not simplify the creation process but certainly seems more intuitive.

For reference, a node should be loaded as unflagged collision geometry if it starts with collision_ but not collision_pad.

It's down to @nozmajner whether he wants to stick with two meshes that cover different sections of the stations or switch to a single mesh.

@nozmajner
Contributor

I'm impartial now that I think about it. The thing for having them separately is that they are more easier update/change later. But if there's a performance or other gain in having them together, then I'm with that.

@mike-f1
Contributor
mike-f1 commented Jan 26, 2017

@jaj22: so if ships aren't docking, the collision between ship and landing (==flagged) surfaces happens?

@nozmajner Err: before merge, there's need to check why Wave still not docking...

@impaktor
Member

Some rebasing would be useful on this. Either I'll help @nozmajner on IRC (not today though), or I'll do it at merge time.

Yep, it seems "rebase" is the onlything I care about these days, :).

@jaj22
Contributor
jaj22 commented Jan 28, 2017

Problem with new_ground in the latest commit: The docking bay tags are somewhat higher than the docking geometry, so ships won't dock. The tags need to be in the same plane as the geometry.

Could also shorten the depth geometry so that people can fly underneath the pads if they want to. ~5m depth should be plenty for poorly-controlled manual docking.

New_ground does also have a lot more plain collision geometry now. Hopefully that's not a significant cost once docking is reliable.

@nozmajner
Contributor

@jaj22 Fixed them both (I hope).
I'm really hoping that the new_ground collisions wouldn't be too much performance burden, because it would be nice to allow flying under the pads for those who want to try (or hide from the police). The orbital stations have way more detailed collision meshes, and I haven't saw any complaint about their performance, so I'm hopeful.

Let me reference #2951, an issue with the position of landing tags as a whole is rotated -90° on X, so they export correctly if I rotate them 90° in the source file. This makes them a bit hard to predict. (A nuisance only really).

@impaktor May I ask you to do that rebasing? Mind too slow right now.

@nozmajner nozmajner Changing ship collision meshes to include a little extrusion to the b…
…ottom, for landing detection.

Adding tag_landing to the ships that don't have it (Deneb, AC33/Venturestar).
Updating station collision meshes: xxx_col has the actualy collision mesh, except the pad surfaces. xxx_docking has the pad tags and pad collision meshes, named accordingly.
e15bc11
@impaktor
Member

Yay, rebased! 👍

@jaj22
Contributor
jaj22 commented Jan 29, 2017

Ok, tested this a fair bit together with #3915, including 2 hours @ 1000x on Earth start with debug spam. Everything seems fine, docking reliable and optimal on all station types & ships.

A couple of non-blocking issues I ran into along the way. Will just note them here briefly:

  1. AICmdDock currently runs fully in DOCKING flight state, which it probably shouldn't, although it may not have any negative effects aside from messing up my debug spam. Return false as with UNDOCKING seems reasonable (if you don't want it to report completed) and appears to work fine.

  2. Ships spawned in stations (at least the player - didn't check others) are not removed from the dynamic collision list, unlike ships that dock, which puts an unnecessarily heavy load on the collision engine. It seems to handle it surprisingly well, considering.

@impaktor impaktor merged commit e15bc11 into pioneerspacesim:master Jan 31, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment