Meadville Space Center
Welcome, Guest. Please login or register.
January 25, 2020, 01:37:10 AM

Login with username, password and session length
Search:     Advanced search
Welcome to the new Meadville Space Center forums!
25068 Posts in 2094 Topics by 2266 Members
Latest Member: twa517
* Home Help Search Login Register
  Show Posts
Pages: [1] 2 3
1  Meadville Space Center / NEW MEMBER REGISTRATION / Re: NEW MEMBER REGISTRATION on: January 26, 2011, 02:12:03 AM
That's unexpected, as i never seen a single bot or spam post here.
Looks like the team's been busy with more than development. Duh!
2  Project Apollo - NASSP / Support & Bugs / Re: Testing collision detection on: June 18, 2009, 10:54:58 AM
I forgot to answer that: No technical reason, it was already this way when I joined the team a couple of years ago, probably because the Deltaglider does it this way. Are bitmaps as resources within dll's bigger then separate files?
Not quite, it's just that you need to download same 30Mb of bitmaps every time someone rebuilds the modules for you.
Same weird case is why the sources are in the orbitersdk\samples directory?
Makes more sense to put them into a special folder.

Both are nothing critical, just some WTF kind of structures in the project.
3  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Collision detection and all that come with it on: June 17, 2009, 10:56:39 AM
Got it. It jumps nicely here at 0.1x.
Investigating already...
4  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Collision detection and all that come with it on: June 16, 2009, 04:09:18 PM
Thank you, that is a significantly better description of a problem - the jumping is between an elevated area and the sphere - part makes it a different domain to look into.

Will there be any difference (jumping-wise) if you set tilting=0 in collision.cfg?

Is there any FPS dependency? Like, recording on 25 FPS and non-recording 60 FPS?

Does it happen with LEVA?

Is there anything special about the terrain jumping happens on, in Fra Mauro case?

Do the two meshes lay in separate files? You can remove one from the collision cfg then.
Shouldn't do any problems, but the performance will be reduced with two.

5  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Collision detection and all that come with it on: June 16, 2009, 08:45:43 AM
Quote from: Tschachim
Yes, you're right, the problem occurs only if FraMauro.cfg is read-only, good catch!
Ok, here is the update:
http://orbides.1gb.ru/collision_ml_090616.zip
Modules are compatible.
-Fixed the read-only files problem
-Fixed VSC_SPHERELOCK flag
-Turned sphere lock on by default

Theoretically, it should fix the jumping on LRV, but only FordPrefect can confirm that, it seems.

Quote from: Tschachim
No. I need to do more testing later, it looks like the touchdown points need some improvement
Three-point model makes it look weird, same for LM. I think i can get more than 3 points support working soon.
6  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Collision detection and all that come with it on: June 16, 2009, 08:09:36 AM
It looks like there's a new bug: Currently we support only 2 moon bases, FraMauro and Tranquillity. So in "Config\Collision\ProjectApollo\Moon" there's only FraMauro.cfg and Tranquillity.cfg. This way the CollisionSDK isn't doing anything at all when loading a FraMauro scenario. I need at least a 3rd file in "Config\Collision\ProjectApollo\Moon", for example xyz.cfg, which seems to need to contain the same content as FraMauro.cfg, then it's working fine again.

I hope this doesn't sound too weird
Unfortunately, it does.
The weird thing is, why do all your files - sources, configs, everything - go in read-only mode?
Maybe it's something CVS adds?

Anyway, most likely the problem is that the cfg file is being opened in rw mode (for historical reasons), and you have it in read-only mode, causing a error.
Could you check that?

Also, do you get the tilting jumping bug FordPrefect described anywhere?
7  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Collision detection and all that come with it on: June 15, 2009, 04:08:59 PM
One more question - how close is that terrain to the sphere level?
If it's slightly below it, i can sort of see why it jumps.

Try setting spherelock=1 in the config/collision/collision.cfg, does it change anything?
8  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Collision detection and all that come with it on: June 15, 2009, 02:44:49 PM
Hm.
What about that jumping?
Is it happening on any terrain, or some specific places?
Can't reproduce that, it runs nicely around Fra Mauro for me.

For the running around the rock - i guess it's LRV's code side problem, no idea what could cause it on my side.
9  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Collision detection and all that come with it on: June 15, 2009, 01:05:01 PM
Quote from: Tschachim
I already changed the touchdown points of the LEVA in CVS to
which seems to work fine, sorry I forgot to mention that. The LRV touchdown points are changed, too.
Well, i missed that.

In any case, the features should be useful:
http://orbides.1gb.ru/collision_ml_090615.zip
Compiled LEVA and LRV modules: http://orbides.1gb.ru/orbf/projectapollo_modules_090615_wtw_eva.zip

I've added a DWORD VSSetCollisionFlags(OBJHANDLE VesselHandle,DWORD flags) call, that controls vessel's collision features.

The flags are:
VSC_ONEPOINT - Do collision detection using only center point. (I advice to put EVA touchdown points the way they were before - it gives it better leverage, which helps avoiding bugs possible on high ground, and the flag should take care of the offset problem).

VSC_TILTING - Enable tilting. Yes, it's already implemented.

VSC_SPHERELOCK - Do not allow vessels to go below sphere level.

VSC_READ_FLAGS - Change nothing, return currently set.

So, it should look like that now:


Bug reports are welcome!
10  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Collision detection and all that come with it on: June 15, 2009, 12:22:23 PM
Quote from: Tschachim
VSGetAbsMaxElvLoc did it, thanks a lot!  Happy
Don't overuse it, it should be slower than the normal one.
Not quite sure by how much though.

Quote from: Tschachim
leva.cpp arrived somewhat "distorted" here, lots of spaces and carriage returns are missing, making the code un-diffable (and for me unreadable), so I didn't use that file, the rest is fine. As of now there seem to be no bugs.
I'll keep it in mind that our coding styles are mutually incompatible. Sad
I just can't stand empty spaces in the source codes.

Quote from: Tschachim
If you do a CVS Update of everything, you can test the LM landing with the "Project Apollo - NASSP\Broken Scenarios\Quickstart Missions\Apollo 14\Apollo 14 - LM final approach" scenario I just fixed, some instructions are here: http://nassp.sourceforge.net/wiki/LM_landing_checklist_(Quickstart)
Works nicely.
One suggestion - a flag is planted by pressing F key, which incidentally is the key you use to toggle FPS meter.

Another - the LEVA touchdown points are quite weird in terms of walking over rocks - it's a big triangle.
Will you do something about that, or should i change something on my side (Like, an option to use one below-COG point instead of touchdown tripod)?

Quote from: Tschachim
I nice feature would be vessel tilting for the rover.  Happy
Hopefully, it's on the way.
I just landed the LM one leg on a boulder, and nothing looks strange.
11  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Collision detection and all that come with it on: June 15, 2009, 12:07:22 AM
So, what the problem is?
What's the limit and where to set? The LM is about 50m above the terrain, about 150m above Orbiter's sphere.
There is no specific limit - the algorithm is designed to exclude meshes that are not in the immediate vicinity of a vessel, for performance reasons. The values are determined by the mesh - if there are no mountains higher than your altitude nearby, it should return sphere level.
VSGetAbsMaxElvLoc will return a precise elevation, if it is necessary.

I can alter this behavior if asked for, but i'm not sure how much it will affect performance.
12  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Collision detection and all that come with it 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.
13  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Collision detection and all that come with it 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.
14  Project Apollo - NASSP / Support & Bugs / Re: Testing collision detection on: June 14, 2009, 12:31:10 PM
If by latest you mean 090613, then it's perfectly normal, since the interface was changed.
In that case, here is the compiled current state, that should work fine:
http://orbides.1gb.ru/orbf/projectapollo_modules_090614_wtw.zip (29Mb)

The texture error in the log appears wholly unrelated to the crash.

Also, question to developers:
Why pack panels and other bitmaps into dll's?
It makes for a lot of download of a lot of dead weight on the bad side, with nothing obvious on good side.
15  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Collision detection and all that come with it 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.
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!