SkyServer

A system to render a user-defined sky. This server can be shared across multiple sims (ie: operates at [multi]grid level) such that different sims can share the same sky viewed from different places (eg, each sim might be on a different planet in a shared star-system).

NOTES:

• This is distinct from WindLight which actually renders the atmospheric effects through which the sky is seen rather than the sky itself - they are complimentary systems.
• These sky-objects are visual-only - they are not intended to be approachable (ie, this is not a 3D space-sim; it is a planetarium). If you want to go there, you teleport to a sim located there, and the sky will be rendered as you would see from there (none of that tedious traveling for weeks through space!).
• Keeping with the above, we are using fixed and unchanging orbits - we really don't care about how the gravity of that gas giant will perturb the motion of the small rocky planet next orbit out! - if you want that, you need to rethink why you are using a human-scale VR simulation that stores its sky-object parameters in 32bit variables! ;-P
• What we do want is to see that little red dot in the sky one evening and know that the planet Gelderfink has entered the constellation of The-Man-Falling-Off-a-Bicycle. And the third moon is rotating so that crater-field that looks like Marylin Monroe's famous air-vent scene is visible again for the next few weeks. :-D - Basically adding interest and culture (or not!) to our skies!

Overview:

• Up to - 4 levels of orbit, ie: objects orbiting objects orbiting objects. This allows a level of complexity up to, for example, a barycenter orbited by multiple stars, each in turn orbited by planets, each in turn by moons, each in turn by satellites. Which is probably enough! Soft limit, though, no intrinsic reason the regression can't go as far as the user will put up with!
• NearSky objects follow orbital paths and can be in the forms:
• Null - an invisible point - used for an empty barycenter around which objects may mutually orbit (eg, multi-star systems, a planetoid with a large moon - eg: Pluto+Charon).
• Star - using the sphere render path initially, but differentiated in data for possible later addition of things like coronas, sunspots, etc.
• Sphere - for planets, moons and other spherical bodies (even spherical space-stations if you like).
• Belt - for asteroid belts and rings - individual components won't be visible, just the overall form.
• Mesh - for non-spherical bodies (natural or otherwise).
• Spheres, meshes and belts can have an optional texture. Objects at significant distance, will only be rendered as points, so only very-near-sky objects will need to download any provided texture (which objects are very-near-sky may depend on the location of the particular sim and also the relative orbital positions of things).
• Orbits are fixed and user-defined - we are not calculating gravity or anything, but assuming the user has either set things up sensibly or they want things to be non-Newtonian! A separate utility for graphically setting things up is a possibility, but editing a text file is easy enough if you don't get too fancy with your orbits!
• A FarSky sphere is provided for rendering items outside the local star system. It is assumed that the relative velocities of far-sky objects is imperceptibly low in real time, so everything is position-fixed.:
  • StarField - density and seed values for procedurally generating a background-star-field of low-to-mid-apparent-brightness stars. A few other very general parameters to effect the positioning even-ness of generated stars - clump them more densely along a plane (if you are inside a spiral galaxy) or more densely towards one side of the sky (off to the edge of a galaxy). The clumping is relative to the root XY plane - if you want it at a different angle relative to the system's orbital plane, you move the orbital plane of the planets (of course, systems don't have to have an orbital plane at all, it is just a convention from the real universe - the sim-owner can spew orbits all over the place if they want!.
  • Named Star - a coloured point representing a manually-positioned star. Can be any brightness, but would generally be high-apparent-brightness for making feature constellations, etc.
  • Texture - an image object (for placing nebula, external galaxies, etc. in the starfield).
• FarSky objects are all rendered 'fullbrite' and are not effected by light sources (though NamedStars and TextureObjects can be light sources themselves, effecting near-sky objects as well as the viewer).
• NearSky-objects (emissive or reflective) are light sources. Reflective light sources calculate their output colour and intensity based on lit-surface colour (basically the average colour of the body as seen from the viewer, accounting for shadowed regions).
• The viewer will choose the most significant light sources to use in a scene (config. setting to define how many, suggested default 4).
• For the actual render, the region is aware of which named orbital body it is located on as well as its declination and right-ascension on the body surface (or bounding sphere for a mesh object), using this and the time/date to calculate the position from which it will render the rest of the sky from the server-provided data (the server doesn't need to know this as all the calculations are done client-side based on the static data).
• The sky only needs to be recalculated when the viewer moves sim or NearSky objects have moved noticably, so the current sim sun/moon-position-update frequency should be fine, and the processing load hence kept well down. A system-designer would generally try to keep the number of sky-objects fairly low - for example, there is no point putting a moon around a distant planet no sim will ever be on - the planet itself will render as a pixel in the sky, but the moon would be too close to be visually separate (I suggest against supporting telescopes!). At the extreme end of reasonable, I am thinking as visible from a particular sim: Two suns, three texture-visible moons, a glowing nebula on the far-sky, a hundred far-sky constellation stars (non-emissive), and a half-dozen neighbor planets far enough to be only single-pixel entities.

Data Structures:

• Sky[array of Objects] - any number of the following objects:
• NearSkyObject (these follow orbital paths)
• Name:[string255] - used to reference the object - can be empty if the object has no children and is never to be referenced from LSL.
• Parent:[string255] - empty parent string means 'system barycenter' which is (0,0,0)
• Size:[float32(km)] - the radius of the sphere, or bounding cube of the mesh, or width of the ring/belt (ring/belt objects are effectively planar, so have no thickness).
• Orbit:[float32s of: e,a,i,Ω,ω,M] - Keplerian elements.
• Eccentricity[Uint32(portion of 1 unit)]
• SemimajorAxis[float32(Mm?)]
• Inclination[Sint32(portion of ±1 Radian)]
• LongitudeOfAscendingNode[Sint32(portion of ±1 Radian)]
• ArgumentOfPeriapsis[Sint32(portion of ±1 Radian)]
• MeanAnomalyAtEpoch[Sint32(portion of ±1 Radian)]
• Type:[Uint8 (void/star/sphere/ring/mesh)]
• BaseColour:[Uint32(ARGB)]
• GroundTexture:[uuid(ref to ARGB or g256 texture)] - null ref means flat texture of BaseColour (if an object is never going to be more than a point, no need for a texture)
• GroundBumpmap:[uuid(ref to g256 texture)] - null ref means flat ground
• CloudTexture:[uuid(ref to ARGB or g256 texture)] - null ref means no texture
• CloudBumpmap:[uuid(ref to g256 texture)] - null ref means 2d cloud layer (no side-lighting on tufts of cloud)
• Density [Uint32(portion of 1 unit)] - how dense is the asteroid belt/ring - full-scale is effectively a solid object!
• Mesh:[uuid(ref to mesh data)]
• EmissiveIntensity:[int8(portion of 1 unit)] - 0 means (reflective-only).
• StarField - fixed to the skydome. You can have more than one (to allow multiple star density planes), however 1 is recommended. Far-stars are all white from 0-50% apparent brightness.
• Density [Uint32(absolute)] - how many background stars to render (recommend 1024)
• Seed [Uint32(absolute)] - the seed for the psudo-random generator (so the starfield always comes out the same per grid but different between them!)
• Flatness [Sint16(portion of 1 unit)] - clump stars towards the XY-plane
• Offset [Sint16(Mm?)] - move the clump plane up or down on the Z-axis
• FarSkyObject - These are pinned to the skydome. All FarSkyObjects are emissive as in 'full-bright' and are not effected by NearSky lighting, of course. FarSky objects with EmissiveIntensity status CAN, however, effect NearSky object lighting.
• Name:[string256]
• Size:[Uint32,Uint32(parts of 1 Radian)] - the XY apparent size of the object
• Position:[Sint16,Sint16(parts of 1 Radian)] - declination, right-ascension
• Type:[Uint8(void/star/texture)] - void is there in case you need an invisible scenelight source from the farSky (don't ask me, I just live here!)
• BaseColour:[Uint32(ARGB)] - intended for named stars, though it gets added to the texture of objects too.
• Texture:[uuid(ref to ARGB texture)] - ignored if type is not 'texture'
• EmissiveIntensity:[int8(portion of 1 unit)] - 0 means 'never use as a light source' - a FarSky object would have to be galaxy-sized to be a realistic light source, but reality is up to the grid-owner.

Supporting LSL:

Function to return the rotation of a Named NearSkyObject relative to the location of either another Named Near- or FarSkyObject. Useful for calculating the time-of-day using an emissive SkyObject source rather than the absolute rotation of the local planet. (Day-length can potentially be somewhat variable if you are on a moon orbiting a planet orbiting a star, all rotating/orbiting at different rates!)

Function to return a list of Named SkyObjects with pertinent data such as CurrentDistance (FarSky objects always return a value meaning 'overflow'), ApparentBrightness (which may change as orbits progresses), CurrentDirection (relative to sim coordinates), AbsolutePosition (in the system, in XYZ coords). Good for making machines (and creatures) that point at or react to particular positions of various SkyObjects or which show relative positions of various things. (egs: plants that always reach for the brightest SkyObject in view; a real-time Orrery; an event that only happens when a particular named star is lined up against certain landmarks).

---

[ Back to main WishList ]