Page 56 of 95

General suggestions for SpaceEngine

Posted: 19 Dec 2017 09:16
by Nantes
When using the System Chart, why are planets' distance not in scale?

Screenshot_7.jpg


Jupiter's semimajor axis is 5.2 AU. It should be over 5 times further away from the Sun than Earth is, but that's not what's observed. Similarly, Mercury (with the arrows in the picture above) at 0.4 AU should be really close to the Sun, but instead it's bundled with the other planets.

If it's for easier display purposes, there should be an easily-visible option to switch between scale and non-scale modes. The game's system chart doesn't have the usual limitations of a paper-based chart due to the possibility of zooming out. A system chart that's in scale would be much more didactic.

General suggestions for SpaceEngine

Posted: 19 Dec 2017 16:22
by EldronBladefur
Here's an idea that I think would be pretty cool for larger moons. How about moons for other moons? I mean, it CAN happen, can't it? I would love to see some moons have tiny moons orbiting them! Imagine a giant gas giant with a smaller gas giant moon, with another Selena-like moon, with a tiny asteroid moon!

General suggestions for SpaceEngine

Posted: 20 Dec 2017 14:18
by XBrain130
Nantes wrote:
Source of the post When using the System Chart, why are planets' distance not in scale?

This had me make me facepalm so hard - because distances are to scale when you're not using System Chart! What kind of question is that??
EldronBladefur wrote:
Source of the post How about moons for other moons?

It has been brought up before, and we think that recursive moons are theorically possible, but highly unlikely due to huge instability.

General suggestions for SpaceEngine

Posted: 21 Dec 2017 07:31
by ettore_bilbo
Nantes wrote:
Source of the post The game's system chart doesn't have the usual limitations of a paper-based chart due to the possibility of zooming out. A system chart that's in scale would be much more didactic.

But you have an entire simulator for real distances... a chart is a chart, it serves to visualize a complex system with a single glance.

General suggestions for SpaceEngine

Posted: 22 Dec 2017 13:12
by John Wain
Well, it's been three days and my post got no attention (maybe since it was the last on the previous page and no one got a chance to see it), but I'm not giving it up yet.

I was proposing some 'didactic' tools to let you explore the universe in a more controlled way and I was also bringing up some of the current limitations of the 'random factor', with massive stars always being 300 solar masses and large galaxies always 100 parsecs.

Anyhow, here is the original post:

viewtopic.php?f=4&t=29&start=810#p17019

I was really hoping to get some feedback from developers or testers of the upcoming version, but any and all brainstorming is welcome.

General suggestions for SpaceEngine

Posted: 22 Dec 2017 14:36
by Mosfet
SpaceEngineer said in this same thread that the value you notice for galaxies or star masses, are limitations due to current engine implementation. These values will change, eventually, with the introduction of new rendering methods.

The cube shape of the universe, as well, I think is due to practical coding reasons regarding procedural generation.

General suggestions for SpaceEngine

Posted: 22 Dec 2017 14:49
by XBrain130
John Wain wrote:
Source of the post massive stars always being 300 solar masses

The problem is that 300 solar masses is already double the currently theorized limit for newborn stars in real life, and roughly the same as the (very-uncertainly estimated) record holder (R136a1 at 315, but it could be as much as 50 units lower), so there's really no reason to increase it.

General suggestions for SpaceEngine

Posted: 22 Dec 2017 23:36
by John Wain
[quote="Mosfet"][ref]SpaceEngineer[/ref] said in this same thread that the value you notice for galaxies or star masses, are limitations due to current engine implementation. These values will change, eventually, with the introduction of new rendering methods.[/quote]

I see, and I suspected that the rendering method was the culprit. But regardless of the method, there will be a hard upper limit (maybe a low one as well, but I haven't seen patterns of that). However what I was proposing was that objects hitting the upper limit be randomized once more with a 10% variation. So for instance a star which was to have 300 solar masses could now be anything between 270-330. That would ensure a less standardized universe.

[quote="Mosfet"]The cube shape of the universe, as well, I think is due to practical coding reasons regarding procedural generation.[/quote]

Could be, but then again, the number seems very specific (a cube 10 gigaparsecs on a side). It is not a multiple of a binary number, so maybe it has less to do with programming...?

[quote="XBrain130"]The problem is that 300 solar masses is already double the currently theorized limit for newborn stars in real life, and roughly the same as the (very-uncertainly estimated) record holder (R136a1 at 315, but it could be as much as 50 units lower), so there's really no reason to increase it.[/quote]

As per our current understanding of R136a1, it was born with 315 solar masses and has lost 50 since then. But as I said above, I did not talk about increasing the limit, only about adding a small random factor for those stars which have hit the limit. One solution would be to decrease the hard stop from 300 to e.g. 280 and factor in a +/-10% variation, so that the maximum value could be 110% x 280 = 308 solar masses (but this value will only be visible for a small percentage of those stars that the program rendered at 280 masses).

General suggestions for SpaceEngine

Posted: 27 Dec 2017 19:57
by Anthony96
A app for android and iPad

General suggestions for SpaceEngine

Posted: 27 Dec 2017 20:27
by PlutonianEmpire
Anthony96 wrote:
A app for android and iPad

Not quite possible. It would require a total rewrite of the entire thing, AND, mobile devices have nowhere near the graphics power of a proper PC.

The next best thing would be a 3rd party app or utility that could let you access your computer remotely from your device and play SE that way. There, the only limitations would be network speeds and data capping, afaik. :)

General suggestions for SpaceEngine

Posted: 28 Dec 2017 01:31
by John Wain
PlutonianEmpire, I like the idea of playing remotely. But I think it would be quite difficult to control the movement, you'd still need controls adapted for touchscreen use.

General suggestions for SpaceEngine

Posted: 28 Dec 2017 02:29
by SpaceEngineer
John Wain wrote:
Source of the post For starters, would it be feasible to input absolute magnitude cutoffs for stars/galaxies? For instance only stars between Mag 4 and Mag 10 would rendered, with the user being able (like it is now) to increase apparent magnitude limits in order to see those further away.

Good idea, worth to try. Some sort of auto limiting of the dim stars rendering if the magnitude is raised too high?
John Wain wrote:
Source of the post In the same vein and in conjunction with the above, distance cutoffs would be great. It would allow users to only render stars/galaxies up to a certain distance, so that they could simply explore a region of space with no regard for the rest. Rendering could be done continuously as you move through space (a sort of comoving distance), or only once from the point of the camera, and then stay fixed for you to fly around it and explore.

The Map Mode already doing this, although camera position is fixed. Some combination could be implemented. How do you imagine the interface for this mode?
John Wain wrote:
Source of the post As such, there should also be an option to limit the number of stars/galaxies rendered, so that the user could prevent an overload and a crash of the program, with certain rules determining what's shown in case the number of objects meeting the selection criteria is larger than the number of objects that the user allows to be shown at the same time.

This is hard to implements, because engine does not know how much objects it will render until it renders them actually. Currently there are some limits on a number of simultaneously rendered nodes of a star octree, galaxies models etc, but they are high enough to let engine render a realistic universe. This limit is hit only then visual magnitude is raised too high, then engine just skip to render extra objects (star nodes etc), and you can see stars appearing as a blocks.
Recently I implemented some sort of auto-adaptation for the Map mode. It uses information about number of objects rendered in the previous frame, and adjust a magnitude cut-off to keep this number in a certain limits. Probably this could be extended to a normal rendering mode. There is a problems with oscillatory instability though (raise cutoff too much -> too less objects will be rendered in the next frame -> reduce cutoff back too much -> too many objects will be rendered and so on).
John Wain wrote:
Source of the post And finally, in the same 'didactic' category, SpaceEngineer explained that galaxies are rendered in filaments. Does the program know which galaxy belongs to which filament? If so, would it be possible to have only the certain filament rendered at once? As it stands, the macro structure of the universe is lost on us.

No, it don't know. This is a common problem with procedural fractal noise: you can only have a statistical parameters. On a planet, there is no way to say if the given point is in a mountain range, other than by using some general info (like elevation). For a galaxy, you may just say that it is in the filament (because there are no galaxies in voids, obviously). But in which one is impossible to say, also because filaments are not a discrete entities in the engine, they are a result of a procedural noise output (just volumes where function computes higher density value).

General suggestions for SpaceEngine

Posted: 28 Dec 2017 02:45
by SpaceEngineer
John Wain wrote:
Source of the post Well, it's been three days and my post got no attention (maybe since it was the last on the previous page and no one got a chance to see it), but I'm not giving it up yet.

Sorry that I don't answer immediately, and sorry if I don't answer at all. It take a lot of time to read through the forum (hours!), so I am forced to skip questions which are obvious, nonsensical or has been answer previously. I rely on experienced community members - they sometimes give exhaustive answers.

John Wain wrote:
Source of the post However what I was proposing was that objects hitting the upper limit be randomized once more with a 10% variation. So for instance a star which was to have 300 solar masses could now be anything between 270-330. That would ensure a less standardized universe.

This is impossible in the current code. It has some places where random must not be used, otherwise it will result in s random universe. In some old versions there was a bug with stars in a star clusters - they was completely different in each new session of SE. This limit for upper limit for a star or galaxy has similar nature. All that I can do is modifying the initial magnitude distribution function so it will have a stronger falloff at the giants edge (star generation in SE is based on absolute magnitude or luminosity).

John Wain wrote:
Source of the post Could be, but then again, the number seems very specific (a cube 10 gigaparsecs on a side). It is not a multiple of a binary number, so maybe it has less to do with programming...?

This is a two power maximum depth of the octree traverse multiply on the smallest ocree node size. Raising this is only possible by increasing the octree depth, or introducing a virtual upper nodes with no galaxies in them (like this done for stars in a galaxies). This require some work, which is not have a large priority now. Simple scaling up of the smallest node size will result in reducing density of galaxies, or enormous increasing of their generation and render count, if you want to keep density intact. Programming is always a sort of tradeoff "memory <-> speed".

General suggestions for SpaceEngine

Posted: 28 Dec 2017 02:52
by SpaceEngineer
Nantes wrote:
Source of the post Jupiter's semimajor axis is 5.2 AU. It should be over 5 times further away from the Sun than Earth is, but that's not what's observed. Similarly, Mercury (with the arrows in the picture above) at 0.4 AU should be really close to the Sun, but instead it's bundled with the other planets.

If it's for easier display purposes, there should be an easily-visible option to switch between scale and non-scale modes. The game's system chart doesn't have the usual limitations of a paper-based chart due to the possibility of zooming out. A system chart that's in scale would be much more didactic.

Do you mean showing relative distance to scale, independently of scale of the planets? I tried that and ended up with overlapping Jupiter and Saturn's rings, and moons rendered inside gas giants. This simply cannot be controlled by a single scaling factor. Also, think about other star systems, especially with a binary/multiple stars. How would you render relative distance between them, also in the same scale, applied vertically? This simply will not work in all cases. The only way to display the chart with no overlapping, is introducing some empty intervals between planets, accumulate widths and heights, and the re-position them.

General suggestions for SpaceEngine

Posted: 28 Dec 2017 03:03
by John Wain
John Wain:Source of the post In the same vein and in conjunction with the above, distance cutoffs would be great. It would allow users to only render stars/galaxies up to a certain distance, so that they could simply explore a region of space with no regard for the rest. Rendering could be done continuously as you move through space (a sort of comoving distance), or only once from the point of the camera, and then stay fixed for you to fly around it and explore.

The Map Mode already doing this, although camera position is fixed. Some combination could be implemented. How do you imagine the interface for this mode?

The map does this pretty well, but I'm thinking of being able to do so in normal rendering mode. So for example you can go to the desired location and switch from continuous rendering mode to this specific mode, where you first set your parameters: absolute magnitude cutoffs and distance over which to render. This would effectively create a sphere around your position and only render the objects meeting the magnitude criteria, and you'd still be able to increase/decrease apparent magnitude in order not to overload your system with too many stars/galaxies visible at once.
You'd then have the chance to navigate or fly around this sphere and study it. You'd practically be studying your desired volume of space without anything else rendering anymore around you. When you're done, switching to the classic rendering mode would then allow the software to render according to its original rules.
Also, I believe that absolute magnitude cutoffs could be implemented as a standalone feature in normal rendering mode, even if I don't really see the point of doing that. It makes sense for you to want to know how many stars between magnitude X-Y are in a specific volume (the situation I was describing above), but when you render the entire galaxy/universe, it kind of defies the purpose. But still...