Meadville Space Center
Welcome,
Guest
. Please
login
or
register
.
May 19, 2013, 12:36:09 AM
1 Hour
1 Day
1 Week
1 Month
Forever
Login with username, password and session length
Search:
Advanced search
Gemini 060615 released!
20010
Posts in
1929
Topics by
2250
Members
Latest Member:
mikegk
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
Author
Topic: Collision detection and all that come with it (Read 7628 times)
Artlav
Full Member
Posts: 36
Collision detection and all that come with it
«
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: 3687
nassp.sf.net
Re: Collision detection and all that come with it
«
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!
Cheers
Tschachim
Logged
Artlav
Full Member
Posts: 36
Re: Collision detection and all that come with it
«
Reply #2 on:
January 26, 2009, 01:04:23 PM »
Quote from: Tschachim on January 26, 2009, 09:11:11 AM
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...
Quote from: Tschachim on January 26, 2009, 09:11:11 AM
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.
Quote from: Tschachim on January 26, 2009, 09:11:11 AM
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.
Quote from: Tschachim on January 26, 2009, 09:11:11 AM
Save/load state compatibility would be cool
Works for Shukra, so it's potentially doable, not sure how it will work out large-scale.
Quote from: Tschachim on January 26, 2009, 09:11:11 AM
...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.
Quote from: Tschachim on January 26, 2009, 09:11:11 AM
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.
Quote from: Tschachim on January 26, 2009, 09:11:11 AM
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: 3687
nassp.sf.net
Re: Collision detection and all that come with it
«
Reply #3 on:
February 02, 2009, 02:13:35 PM »
Hi Artlav,
sorry for the delay...
Quote from: Artlav on January 26, 2009, 01:04:23 PM
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.
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.
Quote from: Artlav on January 26, 2009, 01:04:23 PM
(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...
Quote from: Artlav on January 26, 2009, 01:04:23 PM
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?
Quote from: Artlav on January 26, 2009, 01:04:23 PM
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
Re: Collision detection and all that come with it
«
Reply #4 on:
February 03, 2009, 03:19:24 AM »
Quote from: Tschachim on February 02, 2009, 02:13:35 PM
...but I needed to try your docking solution and it's really nice, thanks a lot.
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.
Quote from: Tschachim on February 02, 2009, 02:13:35 PM
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.
Quote from: Tschachim on February 02, 2009, 02:13:35 PM
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: 3687
nassp.sf.net
Re: Collision detection and all that come with it
«
Reply #5 on:
February 04, 2009, 01:24:15 PM »
Quote from: Artlav on February 03, 2009, 03:19:24 AM
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...
Quote from: Artlav on February 03, 2009, 03:19:24 AM
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!
Do you want me to fix the other 2 scenarios, too, so you can test better?
Quote from: Artlav on February 03, 2009, 03:19:24 AM
But i guess the ground stuff is not your immediate priority - there were like 3 years since the last NASSP release?
4 years!
Quote from: Artlav on February 03, 2009, 03:19:24 AM
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: 3687
nassp.sf.net
Re: Collision detection and all that come with it
«
Reply #6 on:
February 04, 2009, 03:16:38 PM »
Quote from: Artlav on February 03, 2009, 03:19:24 AM
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: 3687
nassp.sf.net
Re: Collision detection and all that come with it
«
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: 3687
nassp.sf.net
Re: Collision detection and all that come with it
«
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?
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
Re: Collision detection and all that come with it
«
Reply #9 on:
June 13, 2009, 01:02:47 PM »
Hello again.
Quote from: Tschachim on June 11, 2009, 12:33:31 PM
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?
Quote from: Tschachim on June 11, 2009, 12:33:31 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?
Not at all, only better use the newer (
http://orbides.1gb.ru/collision_ml_090613.zip
) version...
Quote from: Tschachim on June 11, 2009, 12:33:31 PM
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: 3687
nassp.sf.net
Re: Collision detection and all that come with it
«
Reply #10 on:
June 14, 2009, 02:54:20 PM »
Quote from: Artlav on June 13, 2009, 01:02:47 PM
Quote from: Tschachim on June 11, 2009, 12:33:31 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?
Not at all, only better use the newer (
http://orbides.1gb.ru/collision_ml_090613.zip
) version...
Thanks a lot!
Quote from: Artlav on June 13, 2009, 01:02:47 PM
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
Re: Collision detection and all that come with it
«
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: 3687
nassp.sf.net
Re: Collision detection and all that come with it
«
Reply #12 on:
June 14, 2009, 04:59:51 PM »
Quote from: Artlav on June 14, 2009, 04:11:03 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.
Quote from: Artlav on June 14, 2009, 04:11:03 PM
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
Re: Collision detection and all that come with it
«
Reply #13 on:
June 14, 2009, 05:09:46 PM »
Quote from: Tschachim on June 14, 2009, 04:59:51 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: 3687
nassp.sf.net
Re: Collision detection and all that come with it
«
Reply #14 on:
June 14, 2009, 05:16:05 PM »
Quote from: Artlav on June 14, 2009, 05:09:46 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
« previous
next »
Jump to:
Please select a destination:
-----------------------------
Meadville Space Center
-----------------------------
=> NEW MEMBER REGISTRATION
=> Site News
=> Project News
=> Orbiter
=> Off Topic
=> Rob Conley's Blog
-----------------------------
Project Apollo - NASSP
-----------------------------
=> Project Apollo - NASSP News & Discussion
===> News & Announcements
===> Support & Bugs
=> Project Apollo - NASSP Development
===> Planning
===> Programming
===> Modeling
===> Sounds
-----------------------------
Project Mercury
-----------------------------
=> Discussion & Help
=> Development
===> Planning
===> Programming
=> Mecury Mission Control
-----------------------------
Project Gemini
-----------------------------
=> Discussion & Help
=> Development
===> Programming
===> Modelling
===> Sounds
===> Planning
-----------------------------
Orbiter Mars Direct
-----------------------------
=> Planning
===> General News
=> Development
===> Programming
===> Modelling
===> Sounds
-----------------------------
General Projects
-----------------------------
=> The After Columbia Project
===> Sprint
===> Greenstar
===> Cyanstar
===> Bluestar
===> Mars Challenger
-----------------------------
Sol 2018
-----------------------------
=> Planning
Loading...