Appreciate the links. I have used riemer's site a bit. He has some good starting points though his code is outdated and doesn't compile so you have to fix it a little as it was designed to run in older versions of xna.

His xwing example is one of the camera angles i'm going for (the other being the cockpit view which is basically a first person camera)

A lot to read a lot to take in but that's the fun of it!

I will look into mesh instancing first. My prototype right now just uses a skybox with a starfield texture painted over it but as the game is more sandbox, I'd like to actually have stars that are stars on the screen as opposed to just particles i randomly throw out there.

This is really just a side comment but a few things comes into mind.

* If the stars surrounding appears to be moving like a passing-by effect, that would mean your ship is moving really2x fast! Will your ship be moving in light-speed or warp speed all the time?

* If you're moving towards a start, what happens to that star when you get too close to it? Will it still be just a dot in your screen even though you're just a few meters away from that star?

What if you'll have a dynamic skybox. For each frame, you render your skybox cubemap in a separate scene that just contains the star field. Let's use a 2D star field for example. You can separate the starfield in 2 sections. The front and back which can only move horizontally and the left and right side that can only move vertically. That way i think you'll solve your problem having a dynamic starfield moving while you travel and also preventing the second problem of "tiny" stars staring in front of your face.

The stars should not appear to get closer to the ship at all. Most of the game will take place in "realspace" which will have the ship moving at roughly 500 m/s. The sun in the system will be the origin and it will be possible to fly into the sun, but at 500 m/s that would take an awfully long time to get to the sun. (It may just be that I render the sun as a static object in the game depending on location in the system)

Based on that, a textured starfield I think would be pretty workable and realistic since the stars should just move right left and up and down, not coming at the player.

During translation to the warp the cock pit closes down and the warp is done without visuals (i'm probably going to add some hellish glows ala warhammer 40k but that's still pending)

I like the idea of textured starfield map simply because it requires the least amount of code... you paste it to the skybox.

Possible issues with this: i want each system to appear different, and not just arbitrarily different.

I like how EVE does it where each point of light is actually a system. I think that's more or less rendering a star on the backdrop in the same absolute location to the world though which I also think is very doable.

if the vehicles are basically sub-light speed only, use a skybox/skysphere, instanced meshes for rock/debris flying by (gives good sense of speed and motion), and simply draw nearby systems (textured spheres, or 3d billboards at low LOD) . perhaps change up the skybox texture depending on the general area of space they're in, if the "game world" is that big. SIMTrek drew nearby stars, planets, moons, star bases, etc. the "world map" had 10,000 star systems in it.

As i recall, in wing commander, they usually had at most one big planet nearby, which would make sense for that type of vehicle simulator. Space is BIG! <g>.

Very big :D

Definitely pursuing the skybox right now. Researching how to work with instanced meshes. I have used VertexBuffers before and it seems that those may be similar... still haven't made the connection yet though.

Was going to billboard nebulae and gas clouds and then particle the systems they can travel to (so that they can have a label attached to them by the nav HUD)

Researching how to work with instanced meshes. I have used VertexBuffers before and it seems that those may be similar... still haven't made the connection yet though.

basically you'll have a VB,and possibly an IB to go with it, then you have an "instance buffer", with a whole bunch of world transform matrices in it. the shader applies the transform to the original mesh (the VB) then draws it. then applies the next transform in the instance buffer to the original mesh and draws another copy. and so on for all your instances.

Was going to billboard nebulae and gas clouds and then particle the systems they can travel to (so that they can have a label attached to them by the nav HUD)

if the "world" (galaxy?) is large, you'll want a "world map" with star systems etc, and an "active targets list" that you page star systems into and out of as they come into and go out of range. then just draw your active targets. planets and such aren't really particle systems, they're more like world objects, like a big ship or starport.

now for the REAL challenge:

how on earth are you going to draw what it looks like when they get shot down and fly through the atmosphere and crash land on an alien planet? if you draw a planet, they're going to want to land on it. you know how player's are, they want to be able to do everything. <g>.

drawing atmospheric reentry is one of the big challenges in space flight sims.

And yes, i'm just kidding. Almost no space sim does this due to the difficulty.

That my friend is on my list of things to do lol. There is a game I found on STEAM called Evochron Mercenary which lets you do just that, though I am not a fan of how the overall look is landing on the planet.

For right now you will not be able to land on the planet. But it is something I want (atmospheric dogfights) and the ability to land.