Problem Problem with DGIV inside and outside views

[Fred45]

I'm having altitude problems with the DGIV. I recently installed a clean orbiter install on a new hard drive and anytime I switch views from outside to inside the DGIV begins a vertical descent at around 2 m/s. I have a clean install with no Hi-res addons and actually no addons at all except orbiter sound 3.5 and the DGIV. I have tested this while undocking from the ISS and MIR at first everything is doing what it usually does, backing away from the ISS slowly still lined up with the dock. If I switch from inside view to outside and back then it starts descending toward the earth.
I have tested the default Delta Glider and the space shuttle and neither of these display this behavior. I tried posting this on Dan's forum since it only happens on the DGIV but I haven't got a password from them in three days waiting.
I have reinstalled this about three times still getting the same result.
I know this sounds weird but I have been flying Orbiter for at least two years and have never seen this before.
Thanks for any help.

Fred

 

[Fred45]

Short replay video attached

Here is a short replay video, just drop inside your playback file and replay it. It starts from inside view docked to ISS. I have switched from outside to inside view then undocked.

 

[RisingFury]

Ha... this is odd...

You're not the first person to report it and it's not DGIV specific. The first thread that I've seen was of someone reporting the problem with the XR2 vessel... which means it might be a problem with Orbiter, not the ship.

 

[dbeachy1]

This is simply a symptom of the initial frame taking longer than a normal frame to render when you switch to a new interior panel: each interactive area and dynamic (displayable) area must be registered with the Orbiter core and each area must be rendered. (An analogy would be Windows sending a WM_PAINT message to each application on your desktop asking it to render itself.) With vessels that have complex panels, such as the DGIV and XR series, creating and painting all of those controls takes significantly more CPU time than normal frames do. After the panel is created, subsequent frames only need to re-render any changed areas on the panel. Since the accuracy of the simulation depends on the framerate, when you have a framerate "blip" like that, accuracy will suffer for that frame. You can easily demonstrate this by switching panels (or between interior/exterior views) when time acceleration is active.

Also, when you switch to an exterior view the vessel's mesh must be rendered from scratch, and, like 2D panels, the initial frame takes longer than subsequent frames to render. Depending on the complexity of the vessel's mesh and/or textures, switching to an external view from an internal view can also cause a framerate "blip". So to summarize, what you are seeing is not a "bug"; rather, it is a normal and unavoidable side-effect of complex vessels.

As for how much of an effect the framerate blip incurrs, that depends on how fast the system is: the slower the system, the more effect the framerate blip will have.

 

[RisingFury]

So the fix would be to have a fixed time step of ~1 ms for that frame, instead of timing how long it took to render it.

 

[T.Neo]

So the fix would be to have a fixed time step of ~1 ms for that frame, instead of timing how long it took to render it.

Why don't you get ultra high speed processors instead .

P.S. What happened to the old smilies? These are differant.

 

[dbeachy1]

So the fix would be to have a fixed time step of ~1 ms for that frame, instead of timing how long it took to render it.

Not to put too fine a point on it, but it is not as simple as that. Martin has implemented timestep sub-sampling to minimize the accuracy hit from lengthy timesteps (take a look at Extra -> Time Propagation settings in the Orbiter launchpad), but there is no way to make it perfect.

 

[Fred45]

I thank all for the quick responses, just don't understand why it never has happened before on my system until I reloaded a clean install. I have uploaded another video clip from an external view and ask if someone would look at it and see if it's what everybody is talking about. In the video I loaded the DGIV docked to ISS. Switched to outside view, waited about a minute then undocked using the CTRL D key. As the Delta Glider undocked it began falling toward earth as you can see in the video.
Once again thanks for all the input.

 

[-Pv-]

I just tried the scenario in question using the DGIV on a new clean install with OrbiterSound 3.5. No problems. My guess is you might have a controller issue sensitive to the DGIV or a Module which might be slowing your orbit. Have you tried setting the main HUD RCS controls to OFF, all the engine and auto switches in the DG to OFF, then undocking? Are you watching the Orbit MFD display? Have you tried disabling every Module except sound? I even tried it at warp 100 switching back and forth between external and internal with no glitches. I have an AMD 2.8 DC and X1950 Vid card.
-Pv-

 

[2552]

This is simply a symptom of the initial frame taking longer than a normal frame to render when you switch to a new interior panel: each interactive area and dynamic (displayable) area must be registered with the Orbiter core and each area must be rendered. (An analogy would be Windows sending a WM_PAINT message to each application on your desktop asking it to render itself.) With vessels that have complex panels, such as the DGIV and XR series, creating and painting all of those controls takes significantly more CPU time than normal frames do. After the panel is created, subsequent frames only need to re-render any changed areas on the panel. Since the accuracy of the simulation depends on the framerate, when you have a framerate "blip" like that, accuracy will suffer for that frame. You can easily demonstrate this by switching panels (or between interior/exterior views) when time acceleration is active.

Also, when you switch to an exterior view the vessel's mesh must be rendered from scratch, and, like 2D panels, the initial frame takes longer than subsequent frames to render. Depending on the complexity of the vessel's mesh and/or textures, switching to an external view from an internal view can also cause a framerate "blip". So to summarize, what you are seeing is not a "bug"; rather, it is a normal and unavoidable side-effect of complex vessels.

As for how much of an effect the framerate blip incurrs, that depends on how fast the system is: the slower the system, the more effect the framerate blip will have.

Would it help the accuracy at all to hit Ctrl+P to pause while it freezes for a second or two? I haven't noticed the accuracy problem, but I have a habit now of pausing when Orbiter freezes like that, then unpausing afterwards.