[Release] System Features: Rings

[RockDoctor]

as far as Oolite is concerned the rings are actually a single solid 3D object in the form of a square plane (think of it as a transparent canvas upon which rings are painted by the shader)

(head explodes, in slo-mo) I admit to not having done any graphics programming since implementing a Mandlebrot set in Assembler on a DOS system with a 64-colour card ... but I'd got the impression from the blurb that modern graphics cards had physics models that would do massive numbers of calculations in parallel to do things like "A in front of B" calculations.
Shrug. I'll go back to picking up the mouse-shaped microphone and instructing the computer through that. In CanaScots.

[spara]

So... here's how things are worked out at system creation time
- the planet is placed at its location
- the sun is placed in the sun_vector direction
- the planet is rotated so that its axis points along a vector described by the cross product of the sun vector and the vector [1,0,0]. This ensures the axis has a consistent direction perpendicular to the sun (All Oolite main planets have an axial tilt of 0)
- the station is placed in the direction of the station_vector

Can't get this right, cim . I'm probably not understanding something here.

Known problematic system is Ribior (6, 35). From planetinfo.plist I can extract the following:

Code: Select all

station_vector = "-0.807 0.141 0.573";
sun_vector = "-0.204 -0.494 0.846";

The axis of the planet would then be parallel to:

Code: Select all

> Vector3D(-0.204, -0.494, 0.846).cross([1,0,0]);
(-0, 0.846, 0.494)

And to see if the station is near the equatorial orbit I check the dot product:

Code: Select all

> Vector3D(-0.204, -0.494, 0.846).cross([1,0,0]).dot([-0.807, 0.141, 0.573]);
0.402348

Not even close to zero, so something is obviously wrong somewhere. But where?

[cim]

Ah, okay - not the cross product - must have looked at the wrong line. It sets the planet orientiation to
quaternion_rotation_betweenHP(sun_dir,make_HPvector(1.0,0.0,0.0))
which in JS is either sun_vector.rotationTo([1,0,0]) or [1,0,0].rotationTo(sun_vector)

That gives you a quaternion but you can convert it back to a direction vector for the axis using .vectorForward

[spara]

Ah, okay - not the cross product - must have looked at the wrong line. It sets the planet orientiation to
quaternion_rotation_betweenHP(sun_dir,make_HPvector(1.0,0.0,0.0))
which in JS is either sun_vector.rotationTo([1,0,0]) or [1,0,0].rotationTo(sun_vector)

That gives you a quaternion but you can convert it back to a direction vector for the axis using .vectorForward

Thanks, that's close enough. With a bit of trial and error, I got it now.

Code: Select all

> Vector3D([-0.204, -0.494, 0.846]).rotationTo([1,0,0]).vectorUp().dot([-0.807, 0.141, 0.573]);
-0.00004321709275256769

[gsagostinho]

@spara @cim Thank you so much for all the help, I really appreciate it.

@RockDoctor There would be other ways of doing rings, but there are many nice advantages of using shaders. For instance, instead of having a single type of ring with a single look, we can use code to generate rings in a procedural fashion, so that each one is unique. If you notice, it's not only the size and radial thickness of rings that change from planet to planet, but also the number of gaps, where those gaps are, the colour gradients are always a unique pattern, etc. so that no two rings are identical. So instead of hand crafting 500 individual rings as 3D objects, the shader code takes care of that for us. But that's just one point, and there are many other reasons why the shader solution is particularly interesting (e.g. the shadow problem that cim mentioned and which the shader code easily takes care of).

[gsagostinho]

So the bug has been solved thanks to spara (many, many, many thanks!!). He tested all 2048 planets and it turns out only Ribior had a collision issue (at least we now know it for sure). I will be releasing a new version with the fix in the next days. Thanks you all for all the help!

[Cody]

Fame at last for Ribior - the only system in the Eight where you can ring-surf right into the slot!

[gsagostinho]

Fame at last for Ribior

[gsagostinho]

Hi all, version 2.7 is now available in the manager. Here is the changelog:

- added "use strict"; to scripts which removes some warnings in the log.
- rings are now a little bit more common (1/8 of planets will have them).
- the description of a system will now tell whether it has rings or not (thanks phkb for the help implementing this!).
- close-up grain density now proportional to the colour intensity of the ring lane.
- fixed bug in which Ribior's main station would spawn inside rings (thanks to spara, cim and all others for the suggestions and spara for doing the all hard work for the fix).

[Cody]

Say I want to disable rings in one particular system - can that be done?

[gsagostinho]

Say I want to disable rings in one particular system - can that be done?

Well, it can be done but probably not as easily as you might want. You would have to change the JavaScript code and come up with a different way of selecting which planets get rings, as currently all planets with radius above a certain threshold get a ring (so systems are not specified individually). See the function this.systemWillPopulate in Scripts/systemfeatures-rings.js.

But if you don't mind me asking, are you seeing some problem, bug or ugly rings in some system out there which you'd like to disable?

[Coyote]

Ain't no rings around Aquti, amigo!

[Cody]

No problem - the rings look fine. I'll tweak the numbers, as I did with cim's original. Arrr!

[gsagostinho]

@Cody Ok, let me know if you need any help.

@Coyote But was it supposed to be any rings around Aquti, amigo?

[Smivs]

<Chuckles>

G'kar said "No one here is exactly what he appears"