View more

View more

View more

### Image of the Day Submit

IOTD | Top Screenshots

### The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

# Space Exploration - going about populating a system

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

23 replies to this topic

### #1IcedCrow  Members

Posted 26 July 2013 - 07:20 AM

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?

For more on my wargaming title check out my dev blog at http://baelsoubliette.wordpress.com/

### #2Waterlimon  Members

Posted 26 July 2013 - 09:20 AM

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.

o3o

### #3Norman Barrows  Members

Posted 26 July 2013 - 09:41 AM

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.

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

### #4swiftcoder  Senior Moderators

Posted 26 July 2013 - 03:26 PM

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 ;)

Tristam MacDonald - Software Engineer @ Amazon - [swiftcoding] [GitHub]

### #5Norman Barrows  Members

Posted 26 July 2013 - 04:29 PM

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.

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

### #6IcedCrow  Members

Posted 30 July 2013 - 08:18 AM

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. For more on my wargaming title check out my dev blog at http://baelsoubliette.wordpress.com/ ### #7Hawkblood Members Posted 31 July 2013 - 08:10 PM I am making a game that has all those objectives in mind. There have been others on the forum looking to do similar games. There are several things to overcome when making a game like this. The first one you will run across is the coordinate system. Floating points will NOT work because when you are far out in the solar system, you will start seeing objects "jitter" about because the float has uncertainty around 10 digits or greater. This is discussed in another post: http://www.gamedev.net/topic/645976-good-far-plane-distance-for-space-game/ 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. This could actually be a problem because the player will constantly need to adjust their position to keep up with the solar objects. For instance, the Earth travels ~100,000k/h in its orbit around the Sun. I actually set up my solar system to do the orbits, and that's when I discovered the annoyance. I think it can be corrected with some trickery. I have a few vids displaying some of the aspects of the game: http://youtu.be/fukDH9jzD1U http://youtu.be/9t2HPn-77bo http://youtu.be/-Dyb_VNPtTM If you want my coordinate system, just ask. It uses __int64 and float so the available "space" before it "wraps around" is HUGE-- about 15x the distance from the Sun to Pluto. ### #8LorenzoGatti Members Posted 01 August 2013 - 02:15 AM 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. Omae Wa Mou Shindeiru ### #9IcedCrow Members Posted 01 August 2013 - 06:32 AM 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. Edited by IcedCrow, 01 August 2013 - 06:34 AM. For more on my wargaming title check out my dev blog at http://baelsoubliette.wordpress.com/ ### #10Khaiy Members Posted 01 August 2013 - 03:38 PM 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. -------R.I.P.------- Selective Quote ~Too Late - Too Soon~ ### #11swiftcoder Senior Moderators Posted 01 August 2013 - 03:53 PM 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. I'm not clear that there is any real difference between your "rooms" approach, and my approach of lazily refining the detail of objects based on distance. In either model, when you are far from the Earth, it is rendered as a dot, and when you are close, it is rendered as a spherical terrain... Tristam MacDonald - Software Engineer @ Amazon - [swiftcoding] [GitHub] ### #12Khaiy Members Posted 02 August 2013 - 01:03 PM 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. I'm not clear that there is any real difference between your "rooms" approach, and my approach of lazily refining the detail of objects based on distance. In either model, when you are far from the Earth, it is rendered as a dot, and when you are close, it is rendered as a spherical terrain... For rendering, it isn't. What I wanted to convey was that there isn't much difference between a "room" approach and a continuous, traversable volume of space unless a good portion of space is full of stuff. The rendering is, as others have said, a very minor side-issue. By explicitly rejecting "rooms", I get the impression that the OP recognizes that such an approach has advantages design-wise but that concern about seamless transitions has outweighed those advantages. I just wanted to point out that that tradeoff doesn't necessarily exist and so abandoning "rooms" conceptually, if they are otherwise attractive to the OP, puts unneeded constraints on the project. -------R.I.P.------- Selective Quote ~Too Late - Too Soon~ ### #13IcedCrow Members Posted 03 August 2013 - 10:00 AM For my sun I'm rendering it like a billboard now. I'm dealing with some lens flare issues trying to make it look right... but we'll see how that goes. For more on my wargaming title check out my dev blog at http://baelsoubliette.wordpress.com/ ### #14Norman Barrows Members Posted 04 August 2013 - 07:41 AM 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.

probably overkill.

try just drawing a low poly sphere with a nice texture when they get close enough. you may be surprised.

IcedCrow, on 26 Jul 2013 - 09:20 AM, said:

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.
This could actually be a problem because the player will constantly need to adjust their position to keep up with the solar objects. For instance, the Earth travels ~100,000k/h in its orbit around the Sun. I actually set up my solar system to do the orbits, and that's when I discovered the annoyance. I think it can be corrected with some trickery.

that's what the "make/break orbit" button is for! <g>.   it activates AI that maintains orbit while the planet or moon moves through the solar system.   look at me, i'm giving away all my secrets! <g>.

If you want my coordinate system, just ask. It uses __int64 and float so the available "space" before it "wraps around" is HUGE-- about 15x the distance from the Sun to Pluto.

that should work within a single system, but probably won't work with a star cloud of 10,000 solar systems, each no closer than 4 light years from the next. that's the size of the "world map" in a typical large interstellar flight game.

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).

the traditional way to handle this in a vehicle simulator is with time acceleration.

re: "rooms" approach:

it appears that each solar system will be a "level", and continuous simulation of flight from one system to another will not be possible. it'll be more like "go here", show canned animation of ship in FTL flight, start player in new system.

For my sun I'm rendering it like a billboard now.  I'm dealing with some lens flare issues trying to make it look right... but we'll see how that goes.

note that lens flares looks cool but will be unrealistic unless the view screen is supposed to be displaying an image fed from a remote camera mounted on the ship. if its an actual window or windshield looking out into space, there would be no lens flare. in that case you would get points off for using unrealistic graphics chrome (IE special effects where there shouldn't be any). that's why it call lens flare, it a flare (reflection/refraction artifact) that occurs only when looking through a camera lens. no lens, no flare.

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

### #15Hawkblood  Members

Posted 04 August 2013 - 08:17 AM

Hawkblood, on 31 Jul 2013 - 10:10 PM, said:

If you want my coordinate system, just ask. It uses __int64 and float so the available "space" before it "wraps around" is HUGE-- about 15x the distance from the Sun to Pluto.

that should work within a single system, but probably won't work with a star cloud of 10,000 solar systems, each no closer than 4 light years from the next. that's the size of the "world map" in a typical large interstellar flight game.

Traveling from star to star would not be something a game would likely do at speeds where light can be seen normally. There are some cool looking FTL effects you can use to make the player go "ooooh that looks cool" for a few seconds and then realize he doesn't care. At this point in my game, the player will be encouraged to interact with his crew. BTW, this is also the time I use to generate the approaching system-- so no transition/cut-scene.

### #16IcedCrow  Members

Posted 04 August 2013 - 08:34 AM

When I remove the lens flare I don't like how the scene looks, so for now I'm keeping it in.  My ability with shaders etc is extremely limited (one of the things that has kept me out of 3D programming all this time) and I can't find any good tutorials written in english for it, so I'm having to use what I know and build up from there.  If I can figure out how to render a sun better, I'll be sure to try it.  I'm going for what looks cool right now vs what is more realistic.

Added a bearing compass last night in relative postiion to the compass.  Last step is making the sun stay in the same relative position as the ship which I am hoping to knock out today.

Edited by IcedCrow, 04 August 2013 - 08:34 AM.

For more on my wargaming title check out my dev blog at http://baelsoubliette.wordpress.com/

### #17Hawkblood  Members

Posted 04 August 2013 - 09:30 AM

This has a few FX files you can download with example code. Some are a little hard to navigate (for me) because of the way it's written, but even a dummy like me finally understood.

### #18Norman Barrows  Members

Posted 04 August 2013 - 12:14 PM

Traveling from star to star would not be something a game would likely do at speeds where light can be seen normally.

ah, ok. in SIMTrek/SIMSpace (which i'm about to start another version of) you could fly and fight at FTL speeds, as well as sub-light, and it was one giant continuous galaxy. and you could accelerate time to get places quickly. if you had a random encounter or something en-route, the simulation automatically dropped out of accelerated time.

if you can't really do anything while at light speed but wait to arrive, then there's no real need to simulate the entire flight, just "fast travel" them there.

BTW, this is also the time I use to generate the approaching system-- so no transition/cut-scene.

depending on how you do things, the time required to add a star system to the list of active targets should be near zero. offhand i can't think of circumstances where lead time would be required, unless you're doing mega textures or something like that.

When I remove the lens flare I don't like how the scene looks, so for now I'm keeping it in.  My ability with shaders etc is extremely limited (one of the things that has kept me out of 3D programming all this time) and I can't find any good tutorials written in english for it, so I'm having to use what I know and build up from there.  If I can figure out how to render a sun better, I'll be sure to try it.  I'm going for what looks cool right now vs what is more realistic.

funny, i was going to mention that...

"note: by lens flare, i DON'T mean the corona around the sun"    <g>

the corona effect is correct and looks quite good. if you're using lens flare drawing techniques to achieve it, that's perfectly fine.

typically for a sun, you'll want to alpha blend your sun into the background after you draw everything else. that way objects partly obscured by the sun will be blended with the corona correctly. and if you have a binary system and 2 stars to draw, you'll blend from back to front. this will give excellent lighting effects with coronas.

Last step is making the sun stay in the same relative position as the ship which I am hoping to knock out today.

have you defined a distance scale for the simulation yet? with a data structure such that as mentioned elsewhere in this thread that is suitable for the size of a solar system, and a suitable choice of scale, you should be able to simply place everything where its supposed to be, and its should all automatically draw and work correctly.

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

### #19IcedCrow  Members

Posted 04 August 2013 - 04:43 PM

I haven't yet.  That'll be for an upcoming blog post

typically for a sun, you'll want to alpha blend your sun into the background after you draw everything else. that way objects partly obscured by the sun will be blended with the corona correctly. and if you have a binary system and 2 stars to draw, you'll blend from back to front. this will give excellent lighting effects with coronas.

That's the part I'm having difficulty with.  When we say to alpha blend the sun into the background, I kind of understand that to a point but not fully.  Also I am using the Unity engine so not sure how much control over alpha blending I have (I'm sure there is a degree that it lets me work with but I also don't have the \$1500 full version so my rendering tools are limited)

Edited by IcedCrow, 04 August 2013 - 04:47 PM.

For more on my wargaming title check out my dev blog at http://baelsoubliette.wordpress.com/

### #20IcedCrow  Members

Posted 04 August 2013 - 04:59 PM

This has a few FX files you can download with example code. Some are a little hard to navigate (for me) because of the way it's written, but even a dummy like me finally understood.