So I'm working on a space exploration / sim. Here is the puzzle, some of you may already have experience with this and I thought I'd pick your brain. If you don't have experience... that's fine... let's hash over some development ideas.

I am currently looking at a "level" or a "stage" as an entire solar system. What I do not want are "rooms" in a system (meaning the earth system, the mars system, the jupiter system, etc... where each system is its own scene).

My idea is that as space is fairly large but empty... modern renderers should have little issue rendering what is really constant in a system:

1) the sun

2) the planets

3) some large moons

The rest (asteroids, comets, minor moons, minor planets) can be instantiated as i need them to be. Perhaps trigger zones on a system that when crossed let the system know to create them.

This would mean that if I am orbiting earth and I point at the sun and accelerate, that I should eventually be able to get to the sun and that I shouldn't need a loading screen to load me into the proper zone to do so. If I'm orbiting the earth, then the other planets should be present on the screen as tiny dots, much as they are in our sky in real life, and that if you point at one and accelerate towards it that you'd eventually reach it... that the earth would shrink to a dot... and the target planet grow until you were actually there.

We can go a step farther and incorporate an orbital formula and have the planets orbit the star and also be in motion as well as add a rotational formula to let the planets rotate as well as with their moons.

While this would be hard to perceive... if you stayed put for 24 hrs and took screen shots you'd see changes.

Do you feel that this is a realistic model or do you feel that rendering these large objects (the sun for example would be a massive sphere and light emitter) constantly would cause performance issues?

You can use a Level of Detail (LoD) system to keep the amount of polygons down.

The stars being light emitters shouldnt be a problem, just take the closest ones into account when shading.

However, a problem kind of unique to space renderers is dealing with the extreme distances involved. You will need to use special approaches to do a few things since using floats wont really do for positioning, and when rendering, the depth buffer wont be of much use for the more distant objects (i think some space renderers use multiple passes to render different distance ranges of objects).

Computationally it wont be too expensive, its just that you need more complexity to make it work right.

Do you feel that this is a realistic model or do you feel that rendering these large objects (the sun for example would be a massive sphere and light emitter) constantly would cause performance issues?

been there. done that. its not an issue.

just page targets into and out of the active targets list as the player approaches them / leaves them behind.

SIMTrek 1.0, wriiten in Pascal in 1988, did eveything you describe and more with no problems.

Aye, this really isn't a problem to accomplish. You will have some fun with handling distances and depth-buffer precision at this scale, but nothing insoluble.

The really difficult part is figuring out how to make all that empty space interesting ;)

for distances, use a world coordinate system and a camera relative local coordinate system. do everything in world coordinates, then convert to camera relative local coordinates just before drawing.

far clip panes will be large, 10000 or more.

use star skydome, distant 3d billboards of galaxies and nebulae, a particle system streaming star field flying by for faster than light speed, and a particle system of space rocks for sub-light speeds. Draw any nearby star, planet(s), and moon(s). generally there will only be perhaps one to six of these visible at any time. a simple textured sphere will suffice here. draw starports and friendly and enemy vessels, and projectiles in flight. once you get all that going, it should look sufficiently busy.

note that lighting will have a dramatic effect on the scene. do a search here on gamedev.net for relevant info on that topic. its been covered here on gamedev.net in the past.

the basic idea is you want to use natural lighting. a point light at your nearby light sources, lots of diffuse, as little ambient as possible, for dramatic shadows.

The render to texture is an awesome idea, but as I'm using Unity... that is a part of the $1500 license. So I have to be more creative. I may try the billboarding idea... billboarding the sun, planets, etc... while they are at a certain distance until they get into the appropriate distance of my player.

Use raycasts to determine location or an object manager that just compares coordinates of ship to coordinates of each planet and do the math without requiring a raycast.

I suppose that in a space exploration game the main task the player performs is flying a spacecraft to arbitrary interesting places in the star system (most commonly asteroids or other spacecraft). This poses a number of user interface problems if the display shows only a realistic rendering of celestial bodies:

• Huge distances. Going from Earth to Mars with plausible technology and flight plans requires many months; even a trip to the Moon requires several days. Treating planets, satellites, asteroids, clusters of various stuff at Lagrange points, etc. as "rooms" would allow you to say "you went from A to B in C days" and skip the boring parts of space adventure. The other way to avoid boring long and uneventful flights is magical enormous speed (some kind of inertialess, presumably faster than light drive, and/or unnatural means to survive great accelerations).
• Navigation. Both the appropriate thrusts for rocketry and the accurate targeting needed for fantasy engines need computer assistance: not including a HUD that marks possible destinations and offers "travel to place X" commands means torturing the player for no good reason. There has been some technological progress since the time when Babylonian astronomers watched the sky with their naked eye.
• Getting lost. Planets seen as bright dots can be confused with stars; the field of view is limited, and there are very few landmarks of any kind unless your star system is quite strange. There must be flight instruments telling position, distance and ETA to one's destination, suggested course changes, etc. and displaying anything of importance that cannot be seen directly. Consider the presumably common scenario of regaining one's bearings in the middle of nowhere to resume long-range travel after a dogfight, a landing/docking/boarding attempt, or other cases of flying by sight in random directions for a while: how annoying, difficult and error-prone is it going to be?
• Databases. The player learns that he should go to asteroid LK418. It's effectively invisible at any distance above "already braking to land on it" and, even if visible, identical to thousands of other asteroids; and the player has no idea of the general type of orbit it might have. Clearly, the spaceship computer should step in, displaying an appropriate marker on the maps and offering to drive there

To sum it up, there are good reasons for the user interface conventions you reject, and you should be aware of the price of rejecting them; as already discussed, rendering space scenes is the last and least of your problems.

Well most of the objects in the system that you would want to visit should be selectable via the interface and bracketed. If you are looking for a ship or an asteroid, once you are in the area of that object, you should be able to select it from a targeting array and bracket the object to help identify it. Space flight games from the 90s did this and that's also how EVE works.

Loading screens and rooms are not how I want to design the game, because it creates a suspension between the game immersion. I conducted a couple polls on this very thing and the vast majority preferred seamless movement. This is not always possible, and I plan on having a warp screen for moving between systems but between planets its very doable simply because the engine speed is not moving as it would today. No one would want to play a game if they had to go to the moon base to collect ore and it took three days of actual time to get there.

When having to travel to a location, there will be beacon objects that the user selects from the nav computer and then the engine drives can be engaged to travel to that beacon. I haven't figured out a good system time of travel yet but I would like it comparable to eve. So zipping from the earth to mars should take no longer than say 10 seconds. I *could* use a room which would mean I have some kind of transition screen and then mars appears based on the scene I create but me personally would find this implementation chincy after getting used to games like EVE that move you around the system visibly. As I write games mainly to entertain myself, I don't want rooms.

I'm not seeing the user interface conventions I am rejecting so I am a little confused to the comment. I would not in a million years dream up a system where the player has to rely on computer dots to navigate or find an asteroid in a field of thousands to land on without the aid of the system to identify the asteroid and go into an "orbit". I'm not interested in making a 100% realistic simulator of space, that would probably frustrate most people than it would be entertaining.

Even within a solar system most objects are too far from any given observer to be more than a point of light, if even that much. so. Rendering at any given moment shouldn't be very difficult because most of the objects you want to render will be relatively small and featureless.

Because of this I'm not clear on why you are so opposed to a room-esque approach. Regardless of how fast the player is moving most travel time will be lacking in scenery and you could load the destination's local details during the trip. The only thing you would need for it to feel seamless is to expand the objects the player is approaching, which shouldn't require any special tricks.

To me, rejecting "rooms" when you have downtime to load new data and can easily avoid a loading screen implies that I can freely travel to any arbitrary volume of space and find something to do there, which in turn implies that space will be chock full of activity and seem almost crowded. If this is not the case I feel like you can get the effect you want with a room-centric design without giving anything up.