Search results

@jarmonik Good news: Memory usage seems to be very stable now. Bad news: I think this one should be pretty easy to replicate though, on your end. Load any scenario (DG at Brighton Beach, is usually my go-to). Select the camera dialog and target a different planet than the one your...

What's your time epoch. Orbiter uses TDB Modified Julian Date + 29999.5 Where did you run into trouble with this? Extremely long-term effects (Milankovitch cycles, etc) are (as far as I can recall) definitely not simulated by the default Earth module, but not in-practice, impossible.

This might be a helpful thread https://www.orbiter-forum.com/threads/orbiter-and-earth-rotation.40260/ Also, this. Post in thread 'SPICE module' https://www.orbiter-forum.com/threads/spice-module.1108/post-609388

Awesome. I'll pull and build this when I get home tonight. I did leave a long-term test running overnight (with the previous commit) and this morning it was still going strong with a process memory of just over 1GB (obviously the camera isn't focusing on anything different though). Hopefully...

I will test this too. It seems strange that the crash is occurring at 1.7GB, and not closer to the 2GB limit. Or am I thinking of that wrong.

This is a significant improvement to the memory usage over time. I've been trying pretty hard for the last two hours. Eventually, (by switching between 4 vessels in orbit around Vesta, Moon, Mars and Earth) I was able to get the memory to run out. From Orbiter.log 007297.875: Failed to create...

I'm running at 2560x1080. so not a super high resolution, but definitely a different aspect ratio. @CaptainSwag101 was able to replicate (partially) this memory problem. check the orbiter development channel on the O-F discord.

Collected a bit more data: I am using your latest commit: This is heap profiling from as soon as I opened the launchpad. Frame-rate was pretty low, and I wasn't getting a crash, so I went back to the launchpad. That snapshot below shows quite a bit of memory still allocated after returning to...

For some strange reason NASSP has two different versions of the vector and matrix types: one which is the normal OAPI kind, and another that looks suspiciously like the internal Orbiter types (circa 2003 code, that we haven't updated yet...). is it perhaps a historical reason, like were these...

I'll run the test again tonight to gather data. I saw it as high as 1.8GB when it was running out of memory. DX9 is running natively. Maybe there's some other hardware weirdness going on? I have ecc memory, but this is on a dual-cpu (2x x5690) system.

If you had nonspherical gravity on, I'd say that's definitely a possibility, but with it off I wouldn't expect that. even at 5fps the propagators, substeps, and orbit stabilization should be able to keep up with that, I'd think.

if you want to exactly replicate my test case: Nonspherical gravity on Moon.cfg gravity coeff cutoff, change from 10 to 165 Dynamic state propagation: set RK8 to be the only one at all timeatep lengths. two vessels in 15x15km lunar orbit. 10x-100x time acceleration

This appears to have made the issue significantly better...but it's still present. It's much more resistant to crashing, and even seems to be able to recover (sometimes). upon scenario close: Observation: I noticed this originally because I was testing the gravity models (again) in a...

I don't think this is new I've seen this type of elevation issue before (since 2022, but I have a vague memory of seeing this in the Beta/2016 versions of the client too (unconfirmed)): I should capture a video next time. It usually starts out with some distant z-fighting, then the surface...

It probably would be good to test this against some Orbiter 2016 vessels. I believe there have been several other small VESSEL class changes (including one I'm responsible for); and if I'm not mistaken, at least one or two core/API/base class changes occurred prior to Orbiter becoming open...

This is what the moon looks like as the frame-rates start to get really bad: Closing Orbiter during this, results in an access violation here: EDIT: Crash during an Orbiter session. This took about an hour (realtime) at 10x in lunar orbit. Exception thrown: read access violation...

I think there may be an issue with memory. I was testing the gravity models in a low lunar orbit (15x15km). With LP165 set to a 165x165 cutoff I'm normally able to get frame-rates in the 120s-180s depending on number of vessels. That's what I got when I added the gravity models, and that's...

which ceres addon are you using?

What is everyone using for a \LaTeX package manager? I would think we'd want to pick packages that can just auto download.

Well the elevation issue definitely seems to be fixed. I wouldn't have guessed that was the problem in a hundred years. The soft-dock code looks very cool. Haven't had a chance to play around with that yet, but it sounds like GLS tested it. Correct. OpenOrbiter Only.