Oolite Bulletins

In the Looking Ahead thread, I mentioned the idea of using a particle dynamics system to remap Oolite’s galaxies into 3D while maintaining something close to the current jump distances. I’ve been playing around with it and, while it isn’t perfect, I’m now confident that the idea will hold up. Here’s what I have so far for galaxy 1:



Graphics style aside, this looks a lot like the current galaxy 1, although it doesn’t line up exactly.

Here’s a view from the southern edge:



The fact that the big southern cluster is below the plane is an artefact of the anti-gravity term in the model, which needs to be tweaked, but most of the other variations are useful to help maintain the correct distances between systems. (There is one pair of systems that are too far apart, and one pair that are too close together; this also needs tool refinements.)

Screenshots can only tell you so much, though, so those of you with a fancy-schmancy WebGL-capable browser can take it for a spin here. Tested in Webkit nightlies, FireFox 4.0 and Chrome 10.

Very, very cool!

That is really neat. Is it possible to bubble it out more, and give it some more volume without messing up distances too much. Are you using the original seeds to get the similarities to current galaxies, and if so I'm curious about the orphaned systems in Galaxy 7 and 8. Possible to do the same test with one of them.

Gimi wrote:

That is really neat. Is it possible to bubble it out more, and give it some more volume without messing up distances too much.

There are various ways that could be done, but right now I’m most interested in seeing how little change I can get away with while “fixing” the system topography.

Gimi wrote:

Are you using the original seeds to get the similarities to current galaxies

A temporary method in the 2.0 branch generates the system data and writes it as a JSON file, which is then read by the galaxy-jiggling tool (a Mac-only application). I have data for all the galaxies, but generating a 3D map involves a lot of manual fiddling with parameters.

Gimi wrote:

and if so I'm curious about the orphaned systems in Galaxy 7 and 8. Possible to do the same test with one of them.

Isolated systems and small groups are pushed away from the galactic plane by the “anti-gravity” term, but pulled back by the “plane attraction” term added specifically to avoid unnecessary “bubbling”. (Without the “plane attraction” term, they’d accelerate forever.) The tool currently doesn’t model planets being reachable by misjumping; perhaps it should, but misjump rules might change in 2.0 anyway.

Bravo Ahruman. Really very cool.

(having got FF 3.6.x to behave itself with my choice of add-ons I haven't yet taken the plunge into FF4 territory so WebGL for me - yet)

A bunch of my friends have been telling me to try out FF4 for ages. I've finally been tempted to have a proper look at it and weigh up using it over Chromium.

Ahruman wrote:

A temporary method in the 2.0 branch generates the system data and writes it as a JSON file, which is then read by the galaxy-jiggling tool (a Mac-only application). I have data for all the galaxies, but generating a 3D map involves a lot of manual fiddling with parameters.

Intriguing! Can you combine galaxies in layers with that. (I know that would mean a dramatic change to the galaxy model, but I'm curious). As I have said earlier, in my view, the Galaxy model in Oolite is probably the "weakest" part of the game as it stands right now, and it would be interesting to see what a layered model looks like (if you, against all odds, should find yourself board and with some spare time on your hands that is).

Mauiby de Fug wrote:

A bunch of my friends have been telling me to try out FF4 for ages. I've finally been tempted to have a proper look at it and weigh up using it over Chromium.

The WebGL thing should work in Chrome/Chromium, but I haven’t tested it.

A bit of internet searching and I got it working in Firefox 4, but still no luck figuring out how to enable it in Chromium. No big deal, though, as I tried some other things with WebGL in and Firefox crashed, so I suppose my computer's not really up to it...

I have attempt this myself over a year ago and then I decided to allow the distances to increase as long as they remain <=7 lyr. I kept the same x,y positions and just varied the z. I could get a significant thickness to the systems this way. Like you I had to hand tweak the last two/three systems as the algorithm I came up with got itself into a loop.

I will rummage around and see if I can find the results.

This is truly a big step forward!

I'm honestly a little bit puzzled nobody is screaming sacrilege, heehee!

So.... How does it feel to singlehandedly create a new universe?

Considering the difference between - say - the tube map & the real underground railway layout, we could certainly try to make the 3D version less flat than it is at the moment, as long as it keeps - broadly - the same relative distances between star systems...

It would also be great, IMO, if overlapping systems could finally become less - err... - overlappy!

It seems that the term that’s supposed to “pin” systems to their original location in x,y only is also affecting their z position, making the galaxy flatter than it should be. I’ll post new data when I’ve fixed it. No, wait, false alarm. It seems the initial distances just aren’t bad enough. :-)

Incidentally, the fact that you can’t zoom in the WebGL viewer is a limitation of the web bit, not the GL bit. If anyone familiar with webby stuff would like to improve it, you can zoom (technically, dolly) by manipulating ooGalaxyRenderer.viewDistance. (Works in web consoles too, of course; default is 150.)

Kaks wrote:

It would also be great, IMO, if overlapping systems could finally become less - err... - overlappy! :)

The distance between overlapping systems is set to 0.1 to match 1.x jump behaviour, and their initial position is correspondingly moved in z so they have different initial forces applied to them.

It displayed fine in Chrome for me with Ubuntu. Very nice bit of work. The "Z" being the difference with the systems that appear to overlap on the F6 map is a sensible and logical way of working that overlap out without actually changing the logic of the maps that have been in use.

It's not unimaginable that there could be eight "sheets" or layers somewhere out in the universe, where each layer was close enough to travel in and be thought of as a "galaxy" but for enough apart that it would take a bigger jump to get from one layer to the next.

So, would the eventual game use of this map version involve the in-game navigational map being a 3D item that could be moved/rotated to get a clear view of a destination for setting a course to it?

Ganelon wrote:

So, would the eventual game use of this map version involve the in-game navigational map being a 3D item that could be moved/rotated to get a clear view of a destination for setting a course to it?

It’s a tad early to answer questions like that.