Orbiter Screenshot Thread

Saw some other water pictures in another thread, it sure looks good but big performance hit.

Big performance hit ? Compared to what ? I am detecting something like -15% in a frame rate with my desktop and laptop computers from a water rendering compared to Beta 10 without water. Of course, the new water will double the complexity of the terrain shader and how much that will contribute to overall performance will depend graphics options and settings.

I suppose I can add on/off toggle switch in the setup panel for an advanced water.
 
The game used to be smooth, now it is jerky but it comes in spurts, sometimes it is smooth. Not sure if it due the graphical glitches or the water.

I should not have said the water degrades performance, it could be something else. When I am in Orbit of Earth, Moon & Mars, there is slowdown too especially if there are lots of the graphical glitches.
 
picture.php

View image in gallery

---------- Post added at 01:36 PM ---------- Previous post was at 01:31 AM ----------

I know, I'm an Orion Geek
 
The game used to be smooth, now it is jerky but it comes in spurts, sometimes it is smooth. Not sure if it due the graphical glitches or the water.

Used to be smooth ? When ? And when it stopped to be smooth ? Is this D3D9 specific or does it also occur with the Orbiter's internal engine ?
 
Ok the difference is between night and day. I just tried version 10 & 11.

Loading up the dg scenario Cape Canaveral, on version 10 I get an average of 300 fps, on 11 I get about 15. (no typo, and that is just sitting on the launch pad just moving the mouse around).

Like to add thou that Mars and Moon now work, they don't on version 10. Also with version 11 I have not been able to play longer than 5 minutes without a crash.
 
Last edited:
Loading up the dg scenario Cape Canaveral, on version 10 I get an average of 300 fps, on 11 I get about 15. (no typo, and that is just sitting on the launch pad just moving the mouse around).

Somethings gone horribly wrong.

A few more questions. If you keep the camera still (you don't rotate it), does the framerate increase to normal ratings 270-300fps ? If not, then, are there any errors printed in D3D9ClientLog.html located in /Modules/D3D9Client/

If there are a large amount of errors, then could you copy a few lines in your replay. Also, could you replay in a D3D9Client thread, since this discussion doesn't really belong in here.
 
Well, for me, D3D9 client beta 11 works just fine, no performance degradation from beta 10. No performance degradation because of the better water.
 
rZ7fUdE.jpg


"I would say, Murphy, that you done made a rendezvous..." - Donn Eisele, Apollo 7
 
Alas, the harpoons failed to fire on contact,

picture.php


and so the commander of the Philae had to explain to his disappointed passengers why the Phobos excursion would have to be scrapped ...

picture.php


PS: before you get too excited, there are still plenty of visual artefacts to be fixed before this will be beta-worthy. It turns out that small, very irregular bodies have their distinct set of graphics problems (not least of which is that Phobos currently plops back into a sphere at moderate camera distances ...)
 
Where did you get that texture? I searched everywhere and couldn't find anything! I have the 3D Model of 67P thanks to la Cité de l'Espace but not the textures.

Anyway, I think that your attempt at putting Choury into Orbiter will give more rock solid results. (See what I did there? :lol: )
 
Will it be possible in next Orbiter to land anywhere on surface of irregular bodies? Anyways, amazing photos :)
 
Just to avoid misunderstandings: the planetary body pictured above is Phobos, not 67P. The reference to Philae may have been a bit unfortunate there. So, irregularly shaped bodies - yes, rubber ducks ... not quite.

And to answer the question: it will be possible to land on irregularly shaped bodies, as long as they are implemented with the new planetary surface definition, and have an elevation map provided for them.

In particular, that means that elevations must be representable as r = r(phi,theta). In other words, the surfaces have to be star-shaped (in the topological, not the astronomical sense ;) ). More specifically, star-shaped from the centre of gravity. This is true for most solar system objects, but not all of them. And 67P is probably not. So no recreation of the Philae bounce for now.

Although it might be interesting to figure out how close one can get to 67P's surface with a star-shape. If you put the origin into the neck, close to the surface opposite the most concave part, you'd probably catch most of the shape (even though the origin would then be some distance from the centre of gravity, which would cause other problems). Homework for today: find the optimal point of origin, resulting in the smallest shape error, as a least squares minimisation problem.
 
Perhaps the problem can be solved by setting up two (or more bodies) with the same orbital parameters.
So for 67P, just use 2 bodies and make them touch by the "neck". That way, all of the surface can have a valid representable elevation.
 
Last edited:
Interesting idea. Have you tried if this works? I can see potential problems there: If you define each of the partial bodies with respect to their individual centre of gravity, then they can't really have the same orbital elements, or they just overlap. So they would probably have to orbit their common barycentre with unperturbed circular orbits, but then how do you enforce the orbital period to be the same as the revolution period of the body?

If on the other hand you define both partial bodies with respect to their common centre of gravity, then the star-shape condition will probably not be satisfied, so you wouldn't gain anything.
 
With the explosive growth of the cubesat market over the past few years a market for a dedicated launcher has opened up again. The winner fell to the good old cheap to operate Negi-1, seen here during a cubesat group launch from Negishima Space Center:

15.02.23%2002-04-27%20Negi-1.jpg
 
Is that rocket an addon that you are working on and dous it launch a cubesat?
 
It a launcher by one of our members, found here [ame="http://www.orbithangar.com/searchid.php?ID=5996"]Negi-1 satellite launch vehicle v0.1[/ame]

As far as launching a cubesat, it'll do. It's multistage based, so it'd be a matter of writing an .cfg file for it.
 
Back
Top