Search results

Over Night Test I made over night test with the latest fixes in 15x15km lunar orbit with two docked DGs (v-synced 60fps) 10x acc. Memory consumption remained constant about 500MB, data caches remained constant. However, the frame rate had dropped down to 5fps and the vessels were in nan-space...

The Forum still appears to down scale attached images. The original was 99kb forums scaled it and raised it to 360kb. It ain't working.

The extreme drop in a frame rate in the end (in your screen shot) is likely due to lot of errors printed in Orbiter Log due to out of memory condition. 1.7GB huh. Where does it all go... Is the terrain resolution bias at default ? No, it's at max. Hmm.

Here's my test session.

If that helps then the issue is as Gondos suggested a memory fragmentation. I'll try to pinpoint more places of constant memory allocation/release. I used the frame-rate limiter to drop down to 20fps. In a few minutes application size climbed from 300M up to 600M held there during 10 minute test...

I wrote a small memory manager and moved all terrain elevation and vertex based allocation under it. There is a PR for testing. No leaks detected. If it looks good then might be good idea to move some other things under it too. Those surface tile issues in a screen shots are a result of out of...

Visual studio gives a list of unreleased memory allocations but it's difficult to pinpoint the source (i.e. memory allocator). What I have looked they appear to be rather small.

Looks like it makes random crashes after running out of memory. Is this a new problem or has it existed for some time ? Terrain vertex buffers are already recycled, the same space is re-used over and over again. However, that doesn't apply to the tile loading. I suppose those system memory...

Existing functions still operate the same was as before. Compatibility isn't effected. Compatibility breaks down only if virtual functions are added/removed.

Yes, exactly that. Especially with short examples. Can't be avoided with long ones. I'll start working on conversion of Atlantis Manual and I'll make a PR to your documentationrework_part1_conversion There is already one waiting.

I tried to build the "Orbiter Developer Manual" you have been working on and there was a problem with font "NotoSansMono" I found it from the internet but refused to work. I changed it to "Tahoma" and the document build worked. Would it be possible to tell LaTeX to avoid page breaks inside text...

Orbiter core uses data types such as Vector, Matrix, Matrix4 and the OrbiterAPI uses VECTOR3, VECTOR4, MATRIX3, MATRIX4. Should we keep them separated or standardize them (i.e. make the core use same data types as the API uses) ?

What about the documentation ? Right now the GitHub doesn't build Doxygen nor LaTeX sources. Of course, we can build the documentation manually/locally and then commit the pre-build docs to a repository.

What about the Debug Libs ? Should we have: Orbiterd.lib OrbiterSDKd.lib Lua/Luad.lib ... Or would it be better: Debug/Orbiter.lib Debug/OrbiterSDK.lib Debug/Lua/Lua.lib ... The later wouldn't require renaming the libs and build tools might handle the sub directory easier.

The soft-dock code is very much Martin's code that's modified. Yeah, that tile problem is a real mystery. I kinda bugs me that the reason for the failure is yet unknown. Physics and graphics elevations are very much separate systems and the problem effects them both in a same way. Have to move on.

Here's a new patch for testing. It looks like there was nothing wrong in the tile cache. If a planet had no elevation data available then elevation manager was disabled due to resent optimizations. Having a planet with disabled elevation manager somewhere in a solar system caused issues in many...

It might be good idea to change the linear interpolation to hermite interpolation since it gives more natural feeling for a movement since we are dealing with heavy objects. With "herp" movement starts and ends slowly. With "lerp" movement is instant. VECTOR3 herp(VECTOR3& A, VECTOR3& B, double...

Here's a modified ODS code for better docking. Only works with PR #445

Thanks for the report. I can actually see it on Mars now, the cache is obvious thing to blame but this could be something else. Have to check the planet rendering code. There were some changes on there as well.

I managed to compile SSV and reproduce the very fast spin shortly after docking. OS4 works but OS5 has some issues.