Horizons Space Realism Issues

I don't really remember whether the ring rocks are of randomly generated shapes or do they start repeating after you've seen enough of them. If they are, then the surface problem is already solved, just make a bigger one.
That could work, but only up to certain size (I’d guess about the size of space stations, i.e. a few km across); above that, you need dynamic terrain generation to avoid excessively high CPU or GPU load.

Rings around asteroids would introduce additional realism problems. For one there would be too many. As I understand asteroid moons and rings are quite rare. I think we only have just one known example of both for now but correct me if i'm wrong.
Asteroid rings seem to be rare in real life indeed, and I also am aware of one example only. Asteroid moons, on the other hand, seem to be fairly common (although many of those would be classified as binary asteroids in ED).

As the linked article notes, the data are still patchy, but one would expect them to be more common (by percentage) in the farther reaches of our Solar System, where gravitational disturbances from planets are smaller. Which brings additional problem – most of the asteroid belts in ED are very close to the parent object, so any realistic asteroids there would have very small Roche lobes (or Hill spheres if you prefer ;)) and thus would be unlikely to have any moons.

The second problem would be that player interaction should destroy those orbits in reality. An asteroid's moon would be so weakly bound that just colliding with it should change it's orbit by a lot.
True, but that applies to ring rocks, too – colliding with them (esp. multiple times from the same angle) ought to cause them to drift slowly relative to other rocks, possibly even collide with other rocks and break apart (now that would be cool, wouldn’t it :cool:). Not modelling such interactions is an Acceptable Break from Reality™, IMHO. Definitely more acceptable than having mined fragments inexplicably slow down and stop in the void of space, as they do ;)

I agree about all those other problems, but how do you know about ring rotation? Did you make time-lapse videos? The only way I can imagine I would notice is if I was mining on the inner part of the ring and noted the time it takes for me to move a certain angular distance in relation to the planet and then do the same experiment on the outer edge of the ring and if the times were the same then the orbital speeds are wrong.
I’ll repeat: it was not me. I read about ring rotation on these forums, more than half a year ago, AFAIR. I no longer remember who said that, or if they did any videos. I admit I did not try to verify the claim properly, but it agreed with some not-very-scientific observations I made.

You see, the game sets your frame of reference (FOR) relative to a ring only if you are within a certain distance from the rings’ plane (1000 km, I think, although it may vary with the distance from the centre); if you are farther out, your FOR is relative to the central body, which often means you can see the ring’s rotation. If each ringlet rotated independently according to the (generalized) Kepler’s third law, the rotation should be discernibly slower at the outer edge. (For reference, the orbital velocity of Saturn’s rings – which are modelled as a single ring in ED – ranges from ca. 22.5 km/s at the outer edge of the D ring (which, oddly enough, is the inner edge in ED) to ca. 16.5 km/s at the F ring (which is the outer edge in ED).) OTOH, if the angular velocity of all ringlets is the same in ED, they will seem to rotate faster at the outer edge – which is what I seemed to observe. Granted, it is difficult to get accurate measurements that way, especially since it is difficult to measure the actual distance from a ring.

If someone feels like verifying that, the fastest method is to determine the time it takes the edge of the central planet’s disc (assuming the ship does not co-rotate with the ring while inside it – come to think of that, I haven’t checked if that is the case indeed) to move a certain number of pixels on the screen, both at the inner and at the outer edge. (The edge to be observed should be as close to the centre of the screen as possible, so that perspective distortion does not skew the results.) If the central planet’s angular velocity is the same at both edges, then the ring rotates as a single object.

I would want that myself. Because even though I would never notice certain things, it helps to build immersion by just knowing that the universe is accurately modeled. But I would not like them to spend resources on such things until the obvious ones are taken care of first and until game-play problems are fixed.
Ditto. It’s a game, after all; game-play bugs are more important than realism bugs. :)
 
True, but that applies to ring rocks, too – colliding with them (esp. multiple times from the same angle) ought to cause them to drift slowly relative to other rocks, possibly even collide with other rocks and break apart (now that would be cool, wouldn’t it :cool:). Not modelling such interactions is an Acceptable Break from Reality™, IMHO. Definitely more acceptable than having mined fragments inexplicably slow down and stop in the void of space, as they do ;)

Agreed, but unlike with the asteroid's moons and rings, you could not achieve the ejection of rocks from orbit or make them fall into the planet. That would require enormous amounts of fuel. And by nudging them just a little bit, they would eventually dissipate the excess energy throughout the rest of the giant planetary ring by interacting with other pieces. Even If you were to nudge it out of the plain away from the ring, its orbit would still pierce the ring's plane in two points (the ascending and descending node) and thus spreading the energy again and making the effects negligible. With things in orbit around asteroids however, just a few cm/s additional velocity goes a long way and you could achieve escape velocity by just jumping off the asteroid.

Ditto. It’s a game, after all; game-play bugs are more important than realism bugs. :)

Yes, that's why I'm only bothered by really obvious things. I don't even bother making a thread like this on Star Citizen forums as realism is clearly not their goal (not that it has to be).

That could work, but only up to certain size (I’d guess about the size of space stations, i.e. a few km across); above that, you need dynamic terrain generation to avoid excessively high CPU or GPU load.

Unless you were to flatten the surface somewhat, thus making the number of polygons smaller. But that would make the asteroids look too flat. So come to think of it again, we probably do need terrain generation for this. But as I understand, all the software required for that was also downloaded by players that have season one only. There is just a line of code preventing them to descend to planets (I think). So if they kept the planets locked off for them but use terrain generation on asteroids anyway, they could probably make it work somehow, unless it's a dx11 only thing.

Which brings me to a devastating thought; I don't think they can do any significant graphics changes on asteroids, star shapes, black hole accretion disks etc, as that would increase the minimum system requirements for people who bought season one and have no intention of getting expansions. If they were to add this stuff say with season three, they either had to drop support for past seasons after so little time, or make it work on old hardware, or put players of past seasons on separate servers (which we know won't happen). So even though they said stars with teardrop shaped Roche lobes during the kickstarter campaign (I was told) it doesn't seem possible any more given their current marketing strategy. It seems that we are stuck with season one graphics all the way through season 10 if it ever gets that far (except for places that are locked off for older seasons). I wish FD would respond or make a statement about this. Even if the response is that it's true, that they can't or aren't allowed to make these changes and/or upgrades, I just need to know.
 
Agreed, but unlike with the asteroid's moons and rings, you could not achieve the ejection of rocks from orbit or make them fall into the planet. That would require enormous amounts of fuel. And by nudging them just a little bit, they would eventually dissipate the excess energy throughout the rest of the giant planetary ring by interacting with other pieces.
The said interaction, if we’re to talk about real life rings, would mostly consist of collisions with other pieces :)
(As you probably know, real planetary rings consist mostly of an enormous numbers of small rocks several millimetres to centimetres across.)

With things in orbit around asteroids however, just a few cm/s additional velocity goes a long way and you could achieve escape velocity by just jumping off the asteroid.
Hmm. The escape velocity at the surface of Deimos, which is at the small end of asteroidal bodies (its dimensions are roughly 15×12×11 km), is about 5.5 m/s on the average. So I don’t think you could achieve escape velocity by jumping with just your feet. Perhaps with a pogo stick :D

So come to think of it again, we probably do need terrain generation for this. But as I understand, all the software required for that was also downloaded by players that have season one only. There is just a line of code preventing them to descend to planets (I think). So if they kept the planets locked off for them but use terrain generation on asteroids anyway, they could probably make it work somehow, unless it's a dx11 only thing.
It is a “DX11 only” thing – or, more accurately, dynamic terrain generation requires compute shaders.

Which brings me to a devastating thought; I don't think they can do any significant graphics changes on asteroids, star shapes, black hole accretion disks etc, as that would increase the minimum system requirements for people who bought season one and have no intention of getting expansions.
Asteroids, the way you suggested, probably yes, as discussed above. Star shapes, most probably no; putting polygon vertices on an approximated Roche lobe instead of a sphere surely would not increase CPU or GPU load that much. Accretion disks, no idea.
 
Last edited:
More of a ship realism question than a space realism question per se, but is there any reason that the nuclear powerplant on my Python that could power a small city can't also power headlights that illuminate more than a few hundreds meters ahead of me?
 
The said interaction, if we’re to talk about real life rings, would mostly consist of collisions with other pieces :)
(As you probably know, real planetary rings consist mostly of an enormous numbers of small rocks several millimetres to centimetres across.)

Yes. They should look more like this as opposed to this. But the number of objects and polygons would be astronomical and if on top of that you also added the interactions between rocks, you would need nothing short of a supercomputer. Not to mention that the rocks cast no shadows.

Hmm. The escape velocity at the surface of Deimos, which is at the small end of asteroidal bodies (its dimensions are roughly 15×12×11 km), is about 5.5 m/s on the average. So I don’t think you could achieve escape velocity by jumping with just your feet. Perhaps with a pogo stick :D

hh ok

It is a “DX11 only” thing – or, more accurately, dynamic terrain generation requires compute shaders.

So this pretty much means that we will never have asteroids in ED. That's just great.

- - - - - Additional Content Posted / Auto Merge - - - - -


Yes I know. It's not the issue. A realistic one would look just as beautiful as that.
 
Last edited:
Meet Sol. A little star in our very on solar system. We've been studying it for almost as long as we have been around... Now we have probes that watch it 24 hours a day and guess what - It's round, is this proof enough?

Basing everything on just theory will lead to it needing to be changed when the math is proven wrong as so much of it is... Did/can you watch the Horizon that was mentioned earlier? It has been discovered that we are not the normal system we thought we were. There are systems that defy all current models on how a solar system works - scientists are having to re-write the rules they had created with just maths as actual data proves them wrong.

So again, less of the artists impressions based on unproven/untested math and more observed scientific facts would be my preference. More actual stars we know about would be nice too.

Sorry I must have overlooked this comment of yours.

No that doesn't prove that B2 type stars aren't cube-shaped or that planets around other stars are not fluorescent pink. And we do have ray-tracing methods to determine what the black hole should look like if assuming the current theories are correct. So we do not need artist's impressions at least not in this case. Also our solar system not being typical is irrelevant to the matter here. Even if other solar systems don't look the way science currently predicts, the way science predicts is still the best bet as compared to non-scientific guesses. (best bet, even though not necessarily a good bet). But FD, I propose, should make things at least in accordance with best bets since they can't deliver the real deal.
 
Last edited:
http://spiro.fisica.unipd.it/~antonell/schwarzschild/

[video]//commons.wikimedia.org/wiki/File:NASA-led_Study_Explains_How_Black_Holes_Shine_in_Hard_X-rays.ogg?embedplayer=yes" width="854" height="480" frameborder="0" webkitAllowFullScreen mozallowfullscreen allowFullScreen[/video]

There's no black, featureless disc in ED:
ZSEYZ1I.png

Nothing absorbing light in that screenshot. Rather, creating reflexions in the middle.
That's not what science predicts.
 
Last edited:
For those posting about the dark side of planets/moons being overly bright first thing to do is check your contrast and brightness settings, not just in ED but both on a OS level and a monitor level. ED isn't going to compensate for you if you have your monitor or default display settings set to make darker regions obsolete on your display.

Secondly, if you're using anything like SweetFX, ReShade/EDFX etc re-examine those settings and make sure you properly understand what each is doing (just reading 1 line tooltips isn't going to help you here) and then change ones that go out of their way to counter the significance of unlit surfaces by increasing the contrast of dark regions not in direct lighting, sharpen details artificially and what ever else... just whacking such things on without understanding what each additional process are fully doing from a display perspective is not the way to go about things. :)
 
Last edited:
Sorry I must have overlooked this comment of yours.

No that doesn't prove that B2 type stars aren't cube-shaped or that planets around other stars are not fluorescent pink. And we do have ray-tracing methods to determine what the black hole should look like if assuming the current theories are correct. So we do not need artist's impressions at least not in this case. Also our solar system not being typical is irrelevant to the matter here. Even if other solar systems don't look the way science currently predicts, the way science predicts is still the best bet as compared to non-scientific guesses. (best bet, even though not necessarily a good bet). But FD, I propose, should make things at least in accordance with best bets since they can't deliver the real deal.

Just to point out the obvious but 'Ray-tracing' is just a technique (or rather combination of techniques) that can be utilised in any number of ways set to a user defined set of rules.

There's no "Fixed 100% scientifically accurate depiction of real science theory Ray-tracing".... as such any number of people can come up with their own variations of rules for their ray-tracing behaviour set off of the same scientific principle foundations and get significantly different end results so even the implementation of the technique to generate a possible appearance of something is extremely theoretical and highly questionable in terms of accuracy. At best it's probably safe to say they're 'Valid interpretations of possible representations'.

Taking such things as hard law and parading as "How things definitely look like if current scientific theories are accurate" is a significant fallacy... it's really just one speculative stab in the dark representation of the creators simplification of rules and behaviours used to drive their computations in an attempt to reflect much more complex concepts, amongst a field of dozens of other possible representations and variations that could come about using the same fundamental techniques but with differences in personal interpretations of how to simplify rules to still deliver accurate results.

All it would really take is for one creator to go "Well I don't think xxxx part of interactions would not really relate to the predictions of the framework I'm working with, so to save computational load I'll not bother with factoring in such possible interactions".

Whilst another creator decides the opposite and includes such interactions and in doing so has to have commonly shared rules between the two efforts behave differently to accommodate the additional interactions, and.....

Ta-da! Same techniques and fundamentally accurate depictions of a scientific theory, different visual representation outputs of what should be expected. Even in the example you linked the same person has come up with significantly different visual representations by varying the complexity/simplicity of the behaviour rules.
 
Last edited:
For those posting about the dark side of planets/moons being overly bright first thing to do is check your contrast and brightness settings, not just in ED but both on a OS level and a monitor level. ED isn't going to compensate for you if you have your monitor or default display settings set to make darker regions obsolete on your display.

Secondly, if you're using anything like SweetFX, ReShade/EDFX etc re-examine those settings and make sure you properly understand what each is doing (just reading 1 line tooltips isn't going to help you here) and then change ones that go out of their way to counter the significance of unlit surfaces by increasing the contrast of dark regions not in direct lighting, sharpen details artificially and what ever else... just whacking such things on without understanding what each additional process are fully doing from a display perspective is not the way to go about things. :)

Yes, they should also check if their color range is set to full range. I have to set that every time I update the drivers with the tool available from here. However, the issue is not that I don't have dark areas in game at all, I have them, but the back side of planets goes from full dark to lit up as I descend. Obvious game-play mechanics.
 
Last edited:
Just to point out the obvious but 'Ray-tracing' is just a technique (or rather combination of techniques) that can be utilised in any number of ways set to a user defined set of rules.

Yes, just like you can program any simulation with any king of physical laws that you want. But you can also program it with the actual scientific laws.
There's no "Fixed 100% scientifically accurate depiction of real science theory Ray-tracing".... as such any number of people can come up with their own variations of rules for their ray-tracing behaviour set off of the same scientific principle foundations and get significantly different end results so even the implementation of the technique to generate a possible appearance of something is extremely theoretical and highly questionable in terms of accuracy. At best it's probably safe to say they're 'Valid interpretations of possible representations'.

Taking such things as hard law and parading as "How things definitely look like if current scientific theories are accurate" is a significant fallacy... it's really just one speculative stab in the dark representation of the creators simplification of rules and behaviours used to drive their computations in an attempt to reflect much more complex concepts, amongst a field of dozens of other possible representations and variations that could come about using the same fundamental techniques but with differences in personal interpretations of how to simplify rules to still deliver accurate results.

All it would really take is for one creator to go "Well I don't think xxxx part of interactions would not really relate to the predictions of the framework I'm working with, so to save computational load I'll not bother with factoring in such possible interactions".

Whilst another creator decides the opposite and includes such interactions and in doing so has to have commonly shared rules between the two efforts behave differently to accommodate the additional interactions, and.....

Ta-da! Same techniques and fundamentally accurate depictions of a scientific theory, different visual representation outputs of what should be expected. Even in the example you linked the same person has come up with significantly different visual representations by varying the complexity/simplicity of the behaviour rules.

You are apparently mixing scientific accuracy with actual realism. If you red the thread, you will understand that I'm calling here for accuracy as according to the current theories and not as according to how thing really are as that would be impossible to know. Scientific predictions are a best bet, not necessarily a good bet, but there is no better one. The black hole that that site shows looks the same as on any other independent site that did ray-tracing I found (example, example, example), so I don't know how valid you statement that there are difference principles available. General relativity predicts only one possible path of light ray in a given situation. If you are using theories other than general relativity for ray-tracing, then you are not using the best bet. But feel free to post any sources for you claim that there are more competing principles that guide paths of rays. There are definitely different methods that vary in resolution of correcting paths of rays, but that there are completely different physics that the rays should follow? I would need a source.
 
Some questions I would like to ask those who question the realism, are these:

  • Could you do any better, given the constrictions of DXD, OGL, etc, with support for all the platforms and with an acceptable FPS that catered for the minimum requirements of ED ?
  • What algorithms would you use ?
  • How would you program the shaders to get the desired effects ?
  • How much effort/cost would you justify realism with respect to the cost to the business and time constraints?

Perhaps the last question is the important one ;)

Kitty
 
I liked the beta galaxy more. It wasn't quite as "realistic", but it had more sights. The low orbiting stations were nice too and would have been even better in Horizons.
 
Last edited:
Some questions I would like to ask those who question the realism, are these:

  • Could you do any better, given the constrictions of DXD, OGL, etc, with support for all the platforms and with an acceptable FPS that catered for the minimum requirements of ED ?
  • What algorithms would you use ?
  • How would you program the shaders to get the desired effects ?
  • How much effort/cost would you justify realism with respect to the cost to the business and time constraints?

Perhaps the last question is the important one ;)



Kitty

I don't know but in Space Engine way more realistic black holes were done by an unpaid one man army so at least that part should be super easy for FD. Also removing or giving an option to remove the brightening effect shouldn't be too difficult since removing things is way easier than adding them and could probably be just done by adding a simple if clause into the code in like under 5 minutes. Other things would be more difficult but the eye candy of tear-drop shaped stars and the potential new game-play mechanics around kilometers wide asteroids would probably boost sales somewhat anyway.
 
Last edited:
Planets and moons jumping through their orbit really really annoys me, because I know it wasn't always like that, motion use to be smooth, talk about immersion breaking when you see a moon jump 1000kms at a time.
 
My main issue is the Roche limit with moons and binary orbits. I want collapsed or fractured planets when this happens. Of course, what I want is not what it will happens, but if I am to be asked about, this is my take.

Everything else, yep, would be great to have, specially the accretion disk on Black holes and proper asteroid fields.

And last but not least, red giant star aren't spherical, their body structure is irregular and it looks like the star is being dissolved, as it looks in most space telescope´s pictures.

But that being said, I love the game and I am quite happy with what I got, so this is just me being demanding.
 
And last but not least, red giant star aren't spherical, their body structure is irregular and it looks like the star is being dissolved, as it looks in most space telescope´s pictures.

Yup, that's why they look like that in Space Engine. I'm not sure about the fact that we can see that through telescopes? But there were simulations that showed such shapes.

[video=youtube;hJn-jmL_hyo]https://www.youtube.com/watch?v=hJn-jmL_hyo[/video]

But that being said, I love the game and I am quite happy with what I got, so this is just me being demanding.

Same here.
 
Last edited:
I don't know but in Space Engine way more realistic black holes were done by an unpaid one man army so at least that part should be super easy for FD. Also removing or giving an option to remove the brightening effect shouldn't be too difficult since removing things is way easier than adding them and could probably be just done by adding a simple if clause into the code in like under 5 minutes. Other things would be more difficult but the eye candy of tear-drop shaped stars and the potential new game-play mechanics around kilometers wide asteroids would probably boost sales somewhat anyway.

Yeah; all your points are based on a pure simulation (not a multiplayer game), which is due to the extra resources involved, the big difference...
 
Last edited:
Back
Top Bottom