Meadville Space Center
Welcome, Guest. Please login or register.
September 24, 2020, 12:29:22 AM

Login with username, password and session length
Search:     Advanced search
Project Apollo Beta 7.0 released!
http://nassp.sf.net/wiki/Installation
25068 Posts in 2094 Topics by 2266 Members
Latest Member: twa517
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development (Moderators: movieman, Tschachim, Swatch, lassombra)
| | |-+  Collision detection and all that come with it
« previous next »
Pages: [1] 2 3 Print
Author Topic: Collision detection and all that come with it  (Read 17745 times)
Artlav
Full Member
***
Posts: 36


746021
View Profile WWW
« on: January 23, 2009, 04:24:45 PM »

Greetings everyone.

It's been a while since i last visited this place.
Sure looks like a lot of activity since 2006, i'd appreciate if someone tell me how the project is going, what problems it faces now, or where it is written around here.

It may also be relevant, since i'm going to work on the MeshLand around now, and the Project Apollo is the only add-on that seriously uses it.
Is your Moon landing part up to any walking on the mesh tests?

The status on my part is like that - the Visosad engine 2.x that i developed from january 2006 proved to be fundamentally flawed when used in add-on space, so it's back to engine 1.1 that is used in in NASSP. It is not exactly buried, and if merged with some special-case alternative systems that was made for Shukra Venus station, it can provide both the stability of the old meshland and walking-rolling-tilting features of Shukra engine.

Before i get seriously into that, what exactly NASSP expects from collision detection module?
Vessel-vessel collisions are out (except for carrier-like ones), vessel-terrain collisions are possible with with restitive dynamics, meaning that if you hit the Moon hard, you'll just stop dead, no bumping, no spinning.
Walkable landscape for UMMU-like astronaut.
Potentially save-load state compatibility without up-bubbling effects.
Same SDK as now, Orulex support, most of what i can remember now.

Pretty much a special-purpose collision detection system - a potentially doable library to use by add-ons, instead of a nearly-impossible generic Orbiter-wide hack.

Feature lists, suggestions, comments?

Regards,
Artyom "Artlav" Litvinovich
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #1 on: January 26, 2009, 09:11:11 AM »

Hi Artlav,

thanks for your post and your interest in our stuff. I'd say our biggest problem currently is the lack of time of the developers. But we're still working towards an "Apollo 7 only" release slowly but steadily, a list of the features still needed is here: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=1456.0

An "Apollo 7 only" release doesn't mean that all of our lunar stuff is broken beyond repair, you can still do lunar EVAs and use the rover together with the Meshland version you kindly did for us. If you want to try that, install the latest NASSP 7 beta as explained here: http://nassp.sf.net/wiki/Installation and start the "Scenarios\Project Apollo - NASSP\Broken Scenarios\Quickstart Missions\Apollo 14\Apollo 14 - LM after touchdown" scenario, some instructions about how to use the astronaut and the rover are here: http://nassp.sf.net/wiki/LM_landing_checklist_(Quickstart)

But for the Apollo 7 release we won't need Meshland probably, except perhaps if we add some recovery scenery like an aircraft carrier with a helicopter, which can be landed on the flight deck, but that's probably the same case as landing the LM on a lunar landing site mesh.

So what do we expect from collision detection module?

In my opinion the Meshland version we're using is quite fine, in fact I only have a few points in mind:

  • Vessel tilting. It would be cool if the LM is able to land on the mesh tilted, but for the rover it would be even more important as the current "always horizontally" way is looking bad if you drive uphill or downhill.

  • About vessel to vessel collisions: Not really necessary, only application would be the docking of the CSM with the LM. Orbiter's docking mechanism is ugly because of this "jumping to position", Swatch was thinking about to do some special case stuff here. If it's too hard to do that with Meshland, we'll accept that.

  • Save/load state compatibility would be cool

  • Not really a feature request, but currently perhaps the biggest problem: We had some problems with Meshland because once installed it affects every vessel, not only our stuff, so what we really need would be a Meshland version that is completely separated from other add-ons/vessels both at runtime and from an installation point of view:

    - To avoid conflicts with other Meshland versions or other add-ons the "Modules\Plugin\MeshLand.dll" should be renamed to "Modules\Plugin\ProjectApolloMeshLand.dll" and the "Visosad" directory should be moved to "Modules\ProjectApollo\visosad" or "Config\ProjectApollo\visosad" (which isn't possible with the current version).

    - Additionally the meshland features should be turned off until a vessel enables them via the API.

    - Lastly we're using our own Earth and Moon, i.e. our "System" in the scenarios is "ProjectApollo\Sol" and our ProjectApollo\Sol.cfg contains a ProjectApollo\Earth and a ProjectApollo\Moon. It should be possible to configure Meshland for this Earth/Moon without affecting any other celbody called "Earth" or "Moon", which isn't possible at the moment.


So I hope we don't have any impossible or too hard requests here, thanks again for your interest and we would be very happy about an improved Meshland version! Happy

Cheers
Tschachim
Logged

Artlav
Full Member
***
Posts: 36


746021
View Profile WWW
« Reply #2 on: January 26, 2009, 01:04:23 PM »

An "Apollo 7 only" release doesn't mean that all of our lunar stuff is broken beyond repair, you can still do lunar EVAs and use the rover together with the Meshland version you kindly did for us. If you want to try that, install the latest NASSP 7 beta as explained here: http://nassp.sf.net/wiki/Installation and start the "Scenarios\Project Apollo - NASSP\Broken Scenarios\Quickstart Missions\Apollo 14\Apollo 14 - LM after touchdown" scenario, some instructions about how to use the astronaut and the rover are here: http://nassp.sf.net/wiki/LM_landing_checklist_(Quickstart)
Thank you for the links, i'll see how it is going or working...

Vessel tilting. It would be cool if the LM is able to land on the mesh tilted, but for the rover it would be even more important as the current "always horizontally" way is looking bad if you drive uphill or downhill.
Should be doable, unless extreme angles are involved. Sliding down would be hard to do, as well as handling upside-down crash cases.

About vessel to vessel collisions: Not really necessary, only application would be the docking of the CSM with the LM. Orbiter's docking mechanism is ugly because of this "jumping to position", Swatch was thinking about to do some special case stuff here. If it's too hard to do that with Meshland, we'll accept that.
Jumping to position?
Not sure how it is related to collision detection, but if you want a solution to that problem, here is one way to do it:
http://orbides.1gb.ru/orbf/dcktstves.zip
No guarantee that it's complete or bugless, but it does the job.

Save/load state compatibility would be cool
Works for Shukra, so it's potentially doable, not sure how it will work out large-scale.

...so what we really need would be a Meshland version that is completely separated from other add-ons/vessels both at runtime and from an installation point of view:

To avoid conflicts with other Meshland versions or other add-ons the "Modules\Plugin\MeshLand.dll" should be renamed to "Modules\Plugin\ProjectApolloMeshLand.dll" and the "Visosad" directory should be moved to "Modules\ProjectApollo\visosad" or "Config\ProjectApollo\visosad" (which isn't possible with the current version).
Already thought about it, the MoonLand.dll plugin, lunosid.dll module and config\lunosid for cfg's was my choice of names.

Additionally the meshland features should be turned off until a vessel enables them via the API.
As a special-case system it will be off by default and completely vessel-configurable.

Lastly we're using our own Earth and Moon, i.e. our "System" in the scenarios is "ProjectApollo\Sol" and our ProjectApollo\Sol.cfg contains a ProjectApollo\Earth and a ProjectApollo\Moon. It should be possible to configure Meshland for this Earth/Moon without affecting any other celbody called "Earth" or "Moon", which isn't possible at the moment.
Hm. With above one default off's, it should work for NASSP vessels on any body called Moon or Earth or any other configured (Apollo to Mars remix?).
Is that fine?
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #3 on: February 02, 2009, 02:13:35 PM »

Hi Artlav,

sorry for the delay...

Jumping to position? Not sure how it is related to collision detection, but if you want a solution to that problem, here is one way to do it: http://orbides.1gb.ru/orbf/dcktstves.zip No guarantee that it's complete or bugless, but it does the job.

...but I needed to try your docking solution and it's really nice, thanks a lot.  Thumbs Up

I integrated your code into the docking probe, change is committed to CVS. It could be improved regarding the attitude of the docked vessel, but most important we now can really distinguish between capture and hard dock and retract the LM (or whatever) after capture.

(Vessel tilting) Should be doable, unless extreme angles are involved. Sliding down would be hard to do, as well as handling upside-down crash cases.

No problem, that's fine, people shouldn't crash their rovers in the first place... Wink

Already thought about it, the MoonLand.dll plugin, lunosid.dll module and config\lunosid for cfg's was my choice of names.

Hm, I'm not sure if I understand you correctly, do you plan to have one "global" Meshland installation, used by various add-ons simultaneously (like OrbiterSound) or do you plan to provide a kind of "library", which can be used and distributed by add-ons, while each add-on is using its own version installed in add-on specific subdirectories?

Hm. With above one default off's, it should work for NASSP vessels on any body called Moon or Earth or any other configured (Apollo to Mars remix?). Is that fine?

That depends on the answer to the former question. All these "Moons" have the same name, but different bases, so they'd need different Meshland config files.

Cheers
Tschachim
Logged

Artlav
Full Member
***
Posts: 36


746021
View Profile WWW
« Reply #4 on: February 03, 2009, 03:19:24 AM »

...but I needed to try your docking solution and it's really nice, thanks a lot.  Thumbs Up

I integrated your code into the docking probe, change is committed to CVS. It could be improved regarding the attitude of the docked vessel, but most important we now can really distinguish between capture and hard dock and retract the LM (or whatever) after capture.
I'm glad it's been of use.

Hm, I'm not sure if I understand you correctly, do you plan to have one "global" Meshland installation, used by various add-ons simultaneously (like OrbiterSound) or do you plan to provide a kind of "library", which can be used and distributed by add-ons, while each add-on is using its own version installed in add-on specific subdirectories?
I think UMMU-like system will be a way to go. There will be a dll for collision system and module to enable/disable it all. The vessels compiled with an SDK will have collision detection on, others will be ignored. One splitted centralized system is better than a bunch of add-on specific modules while having the same advantages over the old all-fits-all approach.

That depends on the answer to the former question. All these "Moons" have the same name, but different bases, so they'd need different Meshland config files.
Valid point. But is there a way to distinguish between which cfg file was used? I don't know one, so it's a no-feature till one is proposed.

---------------------------------------------------

Now, to the actual system.
A current version can be found here:
http://orbides.1gb.ru/orbf/collision_ml_090203.zip
Including a new-SDK tuned LEM code.

Your lunar stuff is in worse shape than you say - the PD from orbit smacks the LEM into the ground way off from the landing site it was aimed at. Might be a targeting or set-up issue (Broken Scenarios\Quickstart Missions\Apollo 14\Apollo 14 - LM before powered descent.scn). Other than that, the LEM sits well on both types of mesh (base and orulex) if the altitude is not too high.

There is still a question of excess restitution if the altitude of the mesh is high.
The LM is moved up to the mesh in one stroke at scenario launch, another still buggy point for cases of high elevation, but no problems on lowlands.
I'm yet to try the rover.

The system and SDK changes:
-The config files are in config\collision directory.
-There are no more .manifest files - the bottleneck of loading the meshes for collisions was solved a while ago, so just loading all there is in the planet directory is quite harmless - 2 seconds and 18Mb of RAM for all your bases. (confirm?)
-The SDK is cleaned up of all the noise - every function now returns an actual real value for what it is supposed to return, regardless of activation or presence of the collision system.
Consequently, there are no more VS_NO_ATL things and all the add-on side case-code that comes with it.
-The vessels are started with collisions off, there is no longer a need to "register" a vessel in the system, simply calling VSEnableCollisions(GetHandle()); is all it takes to enable the system from compatible add-on side.
-The VSSetTouchdownPoints no longer needs COG elevation.
-Tilting support is planned to be enableable/disableable from the SDK. Is it needed?

But i guess the ground stuff is not your immediate priority - there were like 3 years since the last NASSP release?
Any plans on when a new one will come around, A7 or full?
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #5 on: February 04, 2009, 01:24:15 PM »

But is there a way to distinguish between which cfg file was used? I don't know one, so it's a no-feature till one is proposed.

With the API I don't know. There's the "System" entry in the scenario and one could trace it from there by parsing the config files directly, but I don't know if this works. Perhaps it's time for a new Orbiter feature request...  Happy

Your lunar stuff is in worse shape than you say - the PD from orbit smacks the LEM into the ground way off from the landing site it was aimed at. Might be a targeting or set-up issue (Broken Scenarios\Quickstart Missions\Apollo 14\Apollo 14 - LM before powered descent.scn).

Yes, both "Apollo 14 - LM before powered descent.scn" and "Apollo 14 - LM final approach.scn" are broken because of the recent change of Moon's rotation model, "Apollo 14 - LM after touchdown.scn" should be fine, I fixed that last week - especially for you!  Happy
Do you want me to fix the other 2 scenarios, too, so you can test better?

But i guess the ground stuff is not your immediate priority - there were like 3 years since the last NASSP release?

4 years!  Happy

Any plans on when a new one will come around, A7 or full?

Full? No clue, probably years as there's a LOT of work to to in the LM. An Apollo 7 release this year would be nice...

Cheers
Tschachim
Logged

Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #6 on: February 04, 2009, 03:16:38 PM »

But is there a way to distinguish between which cfg file was used? I don't know one, so it's a no-feature till one is proposed.

Another idea as this seems to be a really critical problem, there are just too many different Moons (NASSP, AMSO, 2001 etc.): Perhaps it would be possible to set the configuration file/folder via the Meshland API?

Cheers
Tschachim
Logged

Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #7 on: March 22, 2009, 11:33:15 AM »

Hi Artlav,

looks like you're busy with OGLA, but any news about the new collision module?

Cheers
Tschachim
Logged

Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #8 on: June 11, 2009, 12:33:31 PM »

Hi Artlav,

I just tested collision_ml_090203.zip you linked above and it looks like it's working fine. Now I have 2 questions:

  • Would you mind if we bundle collision_ml_090203.zip with our beta modules zip / CVS snapshot, so that testers don't need to download and install an additional zip file?  Happy

  • The only "issue" is the config file problem discussed above. Would it be possible that a vessel sets a different config path, for example by an optional argument of "InitCollisionSDK"? This way we could move the (NASSP specific) files from "Config\Collision" to "Config\ProjectApollo\Collision" and "Config\Collision" can be used for the stock Orbiter planets and bases?

Thanks in advance
Tschachim
Logged

Artlav
Full Member
***
Posts: 36


746021
View Profile WWW
« Reply #9 on: June 13, 2009, 01:02:47 PM »

Hello again.

I just tested collision_ml_090203.zip you linked above and it looks like it's working fine. Now I have 2 questions:
Fine is a vague definition, you don't want to say that there are no bugs at all?

Would you mind if we bundle collision_ml_090203.zip with our beta modules zip / CVS snapshot, so that testers don't need to download and install an additional zip file?  Happy
Not at all, only better use the newer ( http://orbides.1gb.ru/collision_ml_090613.zip ) version...

The only "issue" is the config file problem discussed above. Would it be possible that a vessel sets a different config path, for example by an optional argument of "InitCollisionSDK"? This way we could move the (NASSP specific) files from "Config\Collision" to "Config\ProjectApollo\Collision" and "Config\Collision" can be used for the stock Orbiter planets and bases?[/li][/list]
...Because that is the problem i took a stab at in it.
The configuration directory is specified in VSEnableCollision call, relative to config/collision.
Once set, in whatever vessel comes first, it will use the given path for all collision-specific definition reading.
Theoretically, it should go into InitCollisionSDK call, but that will need some tricky cutting and welding i don't really want to do yet.

Except that, it's pretty much the same module with updated configs (matched new Fra Mauro, etc).

I've also included the fixed versions of all the PA files using CollisionSDK, and did some shameless tinkering on the EVA code - i have to say, rover and EVA looks really nice in the current CVS version, makes me want to do some better ground handling.
Looks like LEM, rover and LEVA works fine with the module, as was said, but my testing is quite biased, and i didn't figured out how to test LEM landing autopilot.


Some general description of the system - CollisionSDK is a whole separate add-on, consisting of the module, enable/disable plug-in, SDK for add-ons, and configurations for planets. Every add-on that want to have ground collision support should link with CollisionSDK, and enable collisions. All planet data goes into config/collision, with common settings in the root of that folder, and add-on specific in subfolders, defined by the add-ons. Add-on specified subfolder is checked first, if the planet below the add-on is not in the folder, then the common is checked.

Long-term plans include Shukra-like system SDK for vessels, niceties for terrain (like tilting, sliding, and no bugs), and, hopefully, documentation.

Well, since yours are the only users for the system so far, feature requests and bug reports are welcome.
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #10 on: June 14, 2009, 02:54:20 PM »

Would you mind if we bundle collision_ml_090203.zip with our beta modules zip / CVS snapshot, so that testers don't need to download and install an additional zip file?  Happy
Not at all, only better use the newer ( http://orbides.1gb.ru/collision_ml_090613.zip ) version...

Thanks a lot!  Happy

Fine is a vague definition, you don't want to say that there are no bugs at all?

Looks like I found one, VSGetATL seems to return Orbiter's altitude when the vessel is not landed. I don't know if this is enough as description, if you like I can provide a demo scenario/code.

Cheers
Tschachim
Logged

Artlav
Full Member
***
Posts: 36


746021
View Profile WWW
« Reply #11 on: June 14, 2009, 04:11:03 PM »

Quote from: Tschachim
Looks like I found one, VSGetATL seems to return Orbiter's altitude when the vessel is not landed. I don't know if this is enough as description, if you like I can provide a demo scenario/code.
Not quite enough. It is designed to return Orbiter's altitude if the collision is inactive, or disabled. Also, if the vessel is too high up above the terrain.
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #12 on: June 14, 2009, 04:59:51 PM »

Not quite enough. It is designed to return Orbiter's altitude if the collision is inactive, or disabled.

Yes, but pVSGetATL is called actually, I already debugged CollisionSDK.

Also, if the vessel is too high up above the terrain.

What's the limit and where to set? The LM is about 50m above the terrain, about 150m above Orbiter's sphere.

Cheers
Tschachim
Logged

Artlav
Full Member
***
Posts: 36


746021
View Profile WWW
« Reply #13 on: June 14, 2009, 05:09:46 PM »

Yes, but pVSGetATL is called actually, I already debugged CollisionSDK.
Debugged in what way? Orbiter's altitude is returned from inside the DLL's call.
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #14 on: June 14, 2009, 05:16:05 PM »

Debugged in what way? Orbiter's altitude is returned from inside the DLL's call.

Ahh sorry. No, just this part in CollisionSDK.cpp:

Code:
double VSGetATL (OBJHANDLE VesselHandle) {
if(SetErr)return oapiGetVesselInterface(VesselHandle)->GetAltitude();
return pVSGetATL(VesselHandle);
}

Landing on the mesh is working fine though.
Logged

Pages: [1] 2 3 Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!