Ultimate space simulation software

 
User avatar
Nantes
Space Tourist
Space Tourist
Posts: 22
Joined: 23 May 2017 09:08

General suggestions for SpaceEngine

19 Dec 2017 11:16

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.
 
EldronBladefur
Observer
Observer
Posts: 1
Joined: 19 Dec 2017 18:18

General suggestions for SpaceEngine

19 Dec 2017 18:22

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!
 
User avatar
XBrain130
Explorer
Explorer
Posts: 286
Joined: 26 Nov 2016 13:19
Location: Italy
Contact:

General suggestions for SpaceEngine

20 Dec 2017 16:18

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??
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.
SpaceEngine's Italian Discord server: https://discord.gg/NhQbEbC
 
User avatar
ettore_bilbo
Explorer
Explorer
Posts: 204
Joined: 11 Nov 2016 05:33
Location: Italy

General suggestions for SpaceEngine

21 Dec 2017 09:31

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.
 
User avatar
John Wain
Space Tourist
Space Tourist
Posts: 21
Joined: 19 Dec 2017 07:35
Location: Somewhere in RG 0-0-0-893

General suggestions for SpaceEngine

22 Dec 2017 15:12

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:

http://forum.spaceengine.org/viewtopic. ... 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.
 
User avatar
Mosfet
Star Engineer
Star Engineer
Posts: 1770
Joined: 24 Oct 2016 11:34
Location: Italy
Contact:

General suggestions for SpaceEngine

22 Dec 2017 16:36

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.
"Time is illusion. Lunchtime doubly so". Douglas N. Adams
| My mods: http://forum.spaceengine.org/viewtopic.php?f=3&t=80 | My specs: Asus x555ub - cpu i5-6200u, ram 12gb, gpu nvidia geforce 940m 2gb vram |
 
User avatar
XBrain130
Explorer
Explorer
Posts: 286
Joined: 26 Nov 2016 13:19
Location: Italy
Contact:

General suggestions for SpaceEngine

22 Dec 2017 16:49

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.
SpaceEngine's Italian Discord server: https://discord.gg/NhQbEbC
 
User avatar
John Wain
Space Tourist
Space Tourist
Posts: 21
Joined: 19 Dec 2017 07:35
Location: Somewhere in RG 0-0-0-893

General suggestions for SpaceEngine

23 Dec 2017 01:36

[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).
Last edited by John Wain on 29 Dec 2017 09:15, edited 1 time in total.
 
Anthony96
Observer
Observer
Posts: 4
Joined: 27 Dec 2017 21:53
Location: Wisconsin

General suggestions for SpaceEngine

27 Dec 2017 21:57

A app for android and iPad
Anthony
 
User avatar
PlutonianEmpire
Pioneer
Pioneer
Posts: 535
Joined: 02 Nov 2016 18:13
Location: Planet Meabh
Contact:

General suggestions for SpaceEngine

27 Dec 2017 22:27

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. :)
Specs: STGAubron desktop PC; NVIDIA GeForce RTX 3060/PCIe/SSE2 12 GB Vram, Intel Core i7-8700 3.2 GHz, 12 cpus; 32 GB RAM; Windows 11 x64
 
User avatar
John Wain
Space Tourist
Space Tourist
Posts: 21
Joined: 19 Dec 2017 07:35
Location: Somewhere in RG 0-0-0-893

General suggestions for SpaceEngine

28 Dec 2017 03:31

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.
 
User avatar
SpaceEngineer
Author of SpaceEngine
Author of SpaceEngine
Topic Author
Posts: 1125
Joined: 17 May 2016 22:16
Location: Saint-Petersburg
Contact:

General suggestions for SpaceEngine

28 Dec 2017 04:29

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?
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?
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).
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).
 
User avatar
SpaceEngineer
Author of SpaceEngine
Author of SpaceEngine
Topic Author
Posts: 1125
Joined: 17 May 2016 22:16
Location: Saint-Petersburg
Contact:

General suggestions for SpaceEngine

28 Dec 2017 04:45

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.
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).
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".
 
User avatar
SpaceEngineer
Author of SpaceEngine
Author of SpaceEngine
Topic Author
Posts: 1125
Joined: 17 May 2016 22:16
Location: Saint-Petersburg
Contact:

General suggestions for SpaceEngine

28 Dec 2017 04:52

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.
 
User avatar
John Wain
Space Tourist
Space Tourist
Posts: 21
Joined: 19 Dec 2017 07:35
Location: Somewhere in RG 0-0-0-893

General suggestions for SpaceEngine

28 Dec 2017 05:03

John Wain: 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...

Who is online

Users browsing this forum: No registered users and 5 guests