Solarex GL, a 3D space flight module for Solarex

[Vandar]

Over many years, every now and then I have been working on a space exploration and trading game. The latest incarnation is called Solarex, written in Java, and available from Sourceforge (GPL v2):

http://sourceforge.net/projects/solarex/

A long time I had been hesitant to add a first person space flight view, because I felt intimidated by the technology like OpenGL. Also, I didn't like to bundle libraries of 5 times the size of the actual game, just for a 3D view. But times change, OpenGL is everywhere nowadays, and 5MB are no longer a big bundle.

So I'm now working on a first person space flight display module for Solarex. For the next while it'll be a separate project, focusing on space display and movement. Later it will be integrated in Solarex and become visible through a new "depart" action from a space station or space port. Internally the stellar systems in Solarex are full 3D already, so there is not much to do in terms of adapting the stellar system data to the new display module.

http://sourceforge.net/projects/solarex ... olarex_GL/

Open questions are, how to handle the planets. Use bitmaps? Use models? Procedurally generated models? Almost all content in Solarex is procedurally generated.

At the moment I have a star background, a nebula and a ship model rotating around two axes for demonstration. I'm going for a definite retro look with this, very simple, untextured geometry. At least for the time being. The pyramid thing there is a space ship. Really

[smcameron]

Nice. r/proceduralgeneration occasionally has some nice discussions. r/creativecoding is also interesting but may be less likely to be actually useful.

[Vandar]

Let me present: The pock-marked planet!

It's procedurally generated, so I can create any number of variants of this planet type easily. It looks boring though. I must convince OpenGL to use more contrast, the shadow side of the planet should be close to black. Also, the planet mesh has 900.000 vertices, that looks insane to me. But with less, the isles and continents don't look good anymore. My laptop can still render this planet at 60 FPS. In theory I can create the planet in several detail levels, and eventually I guess I'll have to, if player are allowed to get much closer to the planet than on the screenshot.

The polar caps need some more work, too.

Edit: Got a better version of the planet, in terms of light and colors. Stillneed to fix the polar caps, and then continue with the other planet types.

[Vandar]

Finally I got the planet generator right, and wrote parameter sets for the most common planet types: rocky, cloudy, earth-type, mars-type, big gas giant, small gas giant, ice type.

Next will be to link the 3D view with the stellar system data, and fly around in a real stellar system for testing.

[zahni]

Also, the planet mesh has 900.000 vertices, that looks insane to me. But with less, the isles and continents don't look good anymore.

It might make sense to use a smaller number of vertices, and to use texture mapping rather than depending on setting colors for each and every vertex. A texture map could give you much higher resolution and reduce the amount of work your GPU needs to do. And, that would also let you do nifty tricks like giving the oceans more of a specular reflection than the land, or adding subtle shadows via bump-mapping. (Googling for "OpenGL planet" will show you a lot of ways others have done this.)

[andrewj]

Yep create some textures.

Easiest way to wrap textures onto a sphere is to use cube-mapping, i.e. generate 6 sides of a cube.

P.S. those planets look very nice.

[smcameron]

Seconding the idea of cubemapping textures. You could possibly keep your current procedural generation and generate the cubemap textures from your current system and thus not be impacted by the high number of vertices except when generating the textures. I dunno... procedurally generating acceptable planet textures in real time seems pretty difficult. Offline generation is always going to produce better results (having more time to spend) and sort of ends up moving the Overton window of what's "acceptable," or at least that seems to be how it worked for me. But, if you need the infinite variety, generating everything offline ahead of time isn't really an option either.

[Vandar]

Indeed, creating a texture and mapping it onto a sphere might be the better approach. Creating the texture on the fly shouldn't take much longer than creating all those triangles. The planets are produced when the player arrives at the system, so there will be a "hyperjump effect" playing for a while, and the planets can be done in parallel, so the player won't notice a delay. Otherwise it happens after loading a game or starting the game, in each case it won't disrupt the game's flow either.

Thanks for the hint, I'll try that

There are mixed news about the UI though. I couldn't get LWJGL and Swing based UI integrate smoothly. Either LWJGL had no keyboard input, or the Swing event queue locked up. So eventually I decided to recreate all UI panels based on OpenGL, since OpenGL allows more nifty graphical effects. The good thing is, writing it newly I can avoid some pitfalls which the old code had, and I can also rework the panel and component design, but it will take some time.

[Vandar]

Besides some improvements in the font area, I have started to work on a cockpit control area panel. Still very basic, but it should do the job to provide controls to access the panels like system overview, system map, galactic map etc ... next panel I'm going to port wil be the system overview panel.

[Vandar]

The space flight view looks good now.

The tabular system view doesn't. Many small layout glitches, and still missing, the planet info display. But getting there.

[Vandar]

The navigation panel is now almost complete. The cockpit area is shown in perspective projektion now, instead of parallel projection as before. Which version do you consider better?

[charlie]

Good progress! Keep it coming.

[Vandar]

Thanks I wish I was faster at this, but OpenGl provides a lot of pitfalls for newbies. Often there are moments when I have just no idea why something doesn't show on screen, or doesn't show correctly and I need man hours to learn all the details. But I could finish some tasks.

Planets are textures now. Less triangles, and more details in the textures. It allows nifty tricks too, but at the moment I'm happy that I have converted the planet creation routine, and that I can recreate the former planet styles. Still some planets beg for a cloud layer. Generating the textures takes some time, but creating an equally detailed planet mesh would take as long. At the moment creating a system with 15 bodies takes a few minutes, and this deems me too long.

The system info panel got a more eye-friendly font size and some bug fixes.

And I ported the galactic map to OpenGL. I've attached two view, one fully zoomed in, and one fully zoomed out. This galaxy is a spiral type galaxy like our own.

[Vandar]

I researched the stellar converter! (quote for those MOO fans )

Actually I have 90% of the work done on the conversion of the stellar system representation from Solarex into a structure that I can render directly with OpenGL. Missing are black holes and ringed planets, those have no suitable representation for OpenGL yet.

The Werteizin system is strange anyways ... a dual star system with a white dwarf and a neutron star. Still it has planets who seem to have survived the nova explosion, when at least one or probably both of the suns ran out of suitable fusion fuel. I guess I must tune the stellar system generator, such systems should only occasionally have planets, and they can only be bare rock bodies.

All system bodies now got labels, which are visible even if the body is too far away to be seen itself. That ought to help with navigation, but at times the labels clump up, if you look at a planet with several moons and stations orbiting from afar.

-> in this version you actually can fly around and watch the planets! Still missing are real drive mechanics ...

[Vandar]

I've diced for newton laws based flight mechanics. That means acceleration + inertia effects. For testing help, there is also an emergency break which can stop a ship in a moment. But the autopilot code drives me nuts. It works for planets, but not for space stations - if I set a space station as destination, the ship ends up in nowhereland. I have no diea why, since the station position seems to be correct, at least it is displayed at the correct position and the display position is the same as the flight coordinates, following smcameron's advice there is only one coordinate system for everything.

The space station is missing textures, and some normals seem to be wrong, but at least I've got a usable station model in the game now. Docking will be automatic once you are close enough to the station.

[Vandar]

Fasten seat belts, we are approaching the planet!

Maybe I can make it come true to land on planets. The transitions between the detail levels stall the game for a minute each time, though, that is far from "good enough" ...

[Vandar]

After the space related work, I went back and ported another UI panel from Swing to OpenGL - the goods exchange panel. It's been easier than expected because I took a different layout, particularly I tried to create a layout that doesn't need any scrolling. Before I didn't really notice how many goods there are already in the game. I always thought there are too few ...

[Vandar]

Writing a new planet detail panel turned out to be a very time consuming undertaking, but I have the basics done now. Planet attributes and planetary resources info (gathered by ship sensors) are available now.

Also, I 've added clouds to some planets.

[Vandar]

I couldimprove the fonts some more, and I think the texts are now better readable than before. The planet info panel now seems to be fully functional with all data, and the solar system converter can use all CPU cores to create planet textures and vertices, which speeds up system building quite a bit, depending on the computer.

I think I'll name the project "Solarex GL", since it is the same as the old Solarex in large parts. It just uses OpenGL for all drawing operations and comes with a 3D space view - maybe some day also with landing operations on planets. Solarex had the concept that the ship stays in orbit, and surface operations are handled by drones, except for planets which have spaceports where a ship can also land (or maybe send a shuttle to, and the main ship still stays in orbit ...) At the moment I'm heading towards a first release, but docking at a station is missing, which I consider a must have even for an early testing release. Most of the other things like shipyard, ship equipment shops etc. are not that essential.

[Vandar]

I've compiled a first release of Solarex GL. It is tested with Windows 7, but a start script for Linux is included as well, and with some luck it might even work. There is a lot missing, and there a myriads of bugs, but basically you can click around the UI panels and finally launch into flight mode to explore the system. You can even dock at another space station, just fly into it, the collision is handled as docking attempt. Bad news is, that launching from a space station places the ship somewhere far away from the station, a bug which I couldn't fix yet.

http://sourceforge.net/projects/solarex ... x_GL/r001/

There is an autopilot function. In space view you can click a body or body label and press A. This activated the autopilot which will steer the ship near the selected space body. Manual flight controls are the mouse and W,S or Cursor Up/Down to speed up and slow down again. Space works as emergency break and brings the ship to halt in the fraction of a second.

Particularly interesting is the space around Werteizin 5, with 4 moons and 2 space stations. Space ports are not present in the space display yet, although listed in the system info panel.

Hyperjumps to other systems are not available yet, but the galactic map is enabled.

[smcameron]

You can even dock at another space station, just fly into it, the collision is handled as docking attempt

Heh, not really very different from my docking code in SNIS. One of those things that fell into the "what's the simplest quickest thing I can make to sorta kinda work" category. If you get around to making it better, I'm interested to see what you come up with. I think Elite kind of hit it out of the park doing that 3D synchronized rotating thing back in the '80s -- for the time, and considering the hardware it ran on, anyway.

[Vandar]

Yes, both Elite and Elite II were very advanced for their time. I've been a big fan of the series. Actually I'm trying to recreate a bit of the feeling, but noticing how hard it is to reimplement the features even with current technology and hardware shows even more how much effort had been put into those games.

Today I've improved the system info panel so that selecting a space body works better now. The galactic map now has an "Engage Jumpdrive" button which will trigger a hyperjump to the selected system. Very crude, but it will get you there. So in this version you can actually explore other systems:

http://sourceforge.net/projects/solarex ... x_GL/r002/

Edit: If I model landing in more detail, it which just be an automated descend on the landing platform of the station. I'll not copy Elite's model of shpis landing inside the station.

[Vandar]

I decided to give the different races in the game home systems, which will be hardcoded, unlike the other system which are procedurally generated. So I started with our own home system ... but I cn tell, this is tedious work to type in all the planet and moon details. And I haven't even finished all bodies of our system. I want to make the cut at about 500km radius, smaller bodies I'll not add.

[Vandar]

R003 is mostly a bugfix and cleanup release. Important changes include the support for inspecting distant systems by clicking them twice in the galactic map, and support for hardcoded systems to be mixed under the procedurally generated ones.

http://sourceforge.net/projects/solarex ... x_GL/r003/

[Vandar]

R004 can save and load game states via the new options panel. You can open the options panel by clicking the small red cloud thingy all on the right on the cockpit UI. (Had no time for a better icon yet ...)

http://sourceforge.net/projects/solarex ... x_GL/r004/