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

Login with username, password and session length
Search:     Advanced search
Gemini 060615 released!
25068 Posts in 2094 Topics by 2266 Members
Latest Member: twa517
* Home Help Search Login Register
  Show Posts
Pages: 1 [2] 3
16  Project Apollo - NASSP / Programming / Re: IMPORTANT! - Project source code rearranging proposal on: February 13, 2009, 12:41:50 PM
everything is looking good so far, I hope I'm ready soon, just one question: It looks like you already disabled the interface to the old meshland version, so I need to deinstall or deactivate the old Meshland/visosad stuff in order to avoid that the Saturn and the CSM are laying on the side?
Yes. I think i've updated all MeshLand definitions to Collision ones, so it should work with the new module, but won't work with the old one anymore.
17  Project Apollo - NASSP / Programming / Re: Project source code rearranging proposal on: February 04, 2009, 01:24:04 PM
I checked your lastest zip and assuming you didn't forgot a file I'd propose the following changes/moves:
Incorporated, sorted, rebuilded:
VC2005 and VC6 tested, VC2008 processed, but untested.
It all builds and flies (A7 non-VAGC launch to splashdown), so i assume i didn't miss anything.

How do we want to do the "move"? Do you want CVS access and just commit that?
It's all in the zip, so i guess you can do it in whatever way you want.
As for CVS access - better not. It's a kind of a thing i usually and unexpectedly screw up.
18  Project Apollo - NASSP / Programming / Re: Project source code rearranging proposal on: February 04, 2009, 11:23:18 AM
As long as you change these files because of the new file structure (include paths etc.) I've no problems with merging on my side, anything else we should coordinate (not only because of changed files but also to discuss requirements).
Well, i'm familiarizing myself with the code (that triggered the rearrangement of the mess in the first place) by doing some small-scale cleanups and compression, like for example, merging the main and drogue chutes nearly identical code into one dll: (62Kb)
Is that acceptable, btw?

Also, i've updated all of the CollisionSDK definitions, as present in the rearranged package.
Do you have some kind of bug tracker or to-do list?
19  Project Apollo - NASSP / Programming / Re: Project source code rearranging proposal on: February 04, 2009, 10:20:48 AM
Good, i've rearranged the stages and systems as was noticed, and VC6 was processed and tested.
Do anyone use VC2008? It should work if VC2005 works, but surprises are not ruled out. (2 Mb, sans bitmaps)

There also is a question - who is working on what?
What parts of the code can be harmlessly changed, and what better be left alone to avoid repeats and unmergeability?

20  Project Apollo - NASSP / Programming / IMPORTANT! - Project source code rearranging proposal on: February 03, 2009, 12:54:31 PM
As i looked at the structure of the sources in the CVS, the first and continuous thought i had was like "What A Mess...".

So, i rearranged the files, cleaned up repeats and trash, wrote a resequencer program to update VC2005 & '08 project files for new paths, etc.
The result is here: (2 Mb, sans bitmaps)

The idea is - build environment files and object files generated during the build go in one place and sources are sorted into 7 categories by their purpose or vehicle.

Status -
The VC2005 environment was tested and works fully, the VC2008 was processed, but not tested - some tweaks might be needed, VC6 was not processed yet for being a different file format, and doxygen files are not updated.
Also, i might have misplaced a file or two, being not very familiar with what abbreviation means what in Apollo.

So, the questions are - does it make sense, would you use it and if yes, what does not look good?

21  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Collision detection and all that come with it 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:
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?
22  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Collision detection and all that come with it 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: 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:
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:
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. 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?
23  Project Apollo - NASSP / Project Apollo - NASSP Development / 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?

Artyom "Artlav" Litvinovich
24  Project Apollo - NASSP / Planning / New Meshland version. on: June 04, 2006, 11:02:54 AM
Have you seen the beta?
It's the same engine - physically accurate solution, with all the tiltings and frictions.

ASAP will likely to take some time - there is no backwards compatibility, and model diffirence from 1.1 is like between ground and sky.
Look in the main forum for details on how to port older thing to new SDK.

I haven't followed this forum for a while, who crashed the LM Happy ?
25  Project Apollo - NASSP / Planning / New Meshland version. on: June 04, 2006, 04:45:07 AM

New Meshland version is out. It's not a 2.0 yet, but worth a try.

Main change is that CollisionSDK is up-to-date again, and ProjectApollo is the only one which use it.

This version uses a collision engine from the beta, so physical accuracy should be good.
26  Project Apollo - NASSP / Modeling / Taurus-Littrow Valley Project at full throttle again... on: April 10, 2006, 01:52:41 PM
This photos are fake - there are stars in the background Happy

Looks great! <Put some lot of "great" equivalents here>!
Any info on when?
27  Project Apollo - NASSP / Planning / Landing the LM on meshes on: January 23, 2006, 08:22:17 AM
Quote from: Redburne

BTW, if someone else wants to modify the parameter: Meshland is a bit touchy concerning the exact format of the numbers. Cutting off a trailing zero (in my case "5.000" instead of "5.0000") crashes Orbiter as soon as you start the EVA.

That's quite strange, and i cant reproduce it. What about other numbers?

Quote from: Tschachim

That's good to know. One question: It looks like this setting is global, so it affects all vessels in a Orbiter installation. Since the astronaut/rover is a quite special vessel moving much slower and nearer to the surface than normal vessels it would be perhaps useful to have an API call to set that speed vessel dependend to avoid negative effects to all other ships when increasing it? I don't know if this is possible?

Perfectly possible and already done.

Quote from: Tschachim

No, the LM doesn't change it's touchdown points during landing, only it's mesh. I have the same problem with the astronaut if I do an EVA after landing using LazyD's scenario and the astronaut also doesn't change his touchdown points, perhaps a small bug?

Actually, yes. When the tilt approaches some critical level current equtions become discret, with all the consequences. Will be fixed soon enough...

Quote from: Tschachim

Artlav, I hope you are not annoyed because of all these requests, you did a really great job, please keep up the good work! Happy

Not a bit. Iam on a vacantion now, and mostly sitting home (-30C outside), so there's nothing else to do...
28  Project Apollo - NASSP / Planning / Landing the LM on meshes on: January 22, 2006, 11:33:24 AM
Redburne: That's good...

"drifting up while below the surface" is already configurable by the "Uprun coefficient [v=(m/ugvspd)/s]*(1/timewrap)" in the meshland.cfg file (or mlconfig). But there is no instant up option, since it confuses Orbiter core someway.

Yes, tilting is not always correct, since LM and rover is 4-whelled, and collision is 3-pointed + some bugs.
Tilting disabling may be implemented, but it will be a hack for current engine - like disabling all orbits except equatorial in Orbiter.

Thank you for help offer, but there is no need yet - PTP engine is still a work in progress, and it will eventually converge to a general-case bugless solution.

LazyD: No idea, what is wrong in the first one, feels like something setting the points simulteniousely with visosad.

Some tilting errors is because 4-wheeler(legger?) by 3-points model, others because of inperfection of the equations. Will be fixed eventually.
29  Project Apollo - NASSP / Planning / Landing the LM on meshes on: January 22, 2006, 04:20:21 AM
Here is the update:

Main points is performance and tilt.

Visosad now recognizes the landed vessel state and uses the saved data instead of calculating new one.
If the landed vessel's position is changed, then the data is recalculated.
GetATL is also redundancy-proof.
*ElvLoc's uses data cache to prevent recalculations.
This way ALOT of redundant calculations was eliminated.
Calcs count in MFD now shows <LTP collisions>/<bounding collisions>.

Special-case points-to-polys collision detection mode is supported.
In general case you will be able to define a set of points, that will collide with the mesh to calculate tilt, sliding and bouncing.
Currently points is preset to touchdown points, giving a "triangular" tilt.
General case will be done as soon as i'll compose the equations (not soon enough, i think).

Main FPS-eaters are not the algorithms, but thous 1000-poly per unit rocks in the middle of the landing site.
30  Project Apollo - NASSP / Planning / Landing the LM on meshes on: January 22, 2006, 03:07:56 AM
Redburne picture looks promising, but it's acually reinventing of a bicycle.
I've already solved the tilt<->performance issue, and will post an update as soon it's debugged and ready.
Pages: 1 [2] 3
Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!