Create an active ID system for tagging objects, layout for grand data design for solar system modeling

[iontom]

We will try to produce an object id schema system to keep track of objects and bodies. Some will be generated from within this libarary, others will be populated from MetaSim either directly or proxy from other reference engines. Top level positions/coordinates take precedent. Other parameters are meta, and might be equally synonmous with other reference engines. This is just a sketch of data that would be important.

• Identifiers
  sim_id: [simulation id] from MetaSim/WebHex
  guid: [global id] local
  ss_id: [Solar system id] local, for getting absolute coordinates
• Position Cartesian (center of mass, maybe integration later for moon volcanism)
  x [barycentric ss position] local to send to renderer
  y [barycentric ss position] local to send to renderer
  z [barycentric ss position] local to send to renderer
  vx [barycentric ss velocity] local to send to renderer
  vy [barycentric ss velocity] local to send to renderer
  vz [barycentric ss velocity] local to send to renderer
• Revolution
  per [period time to do one revolution if in stable orbit] = native year
  phase [phase of the year,]
  ses [seasonality of the planet based on rotation angles]
• Rotation
  http://en.wikipedia.org/wiki/File:Earth_precession.svg
  w_p [rotation angle 'pitch'] = axial tilt
  w_r [rotation angle 'roll'] = precesion
  w_y [rotation angle 'yaw'] = time of day
  f_p [rotation freq 'pitch']
  f_r [rotation freq 'roll']
  f_y [rotation freq 'yaw']
• Optional position equations to send to renderer
  Eq(x, y, z) = Equation[ If Parabolic, If Hyperbolic, If Ellipse, Else NONE]
  Parse from python to JavaScript to describe orbit of planet in case network lag slows
  positioning. Each equation would include orbital params seen below:
• Store radial/cyl coordinates as well for easier calculation internal
  pos.r [radial position]
  pos.w [theta angle ]
  pos.p [phi angle]
  pos.h [height = z]
• Primary Descriptors
  mass [mass of the object] local for modeling
  mass_units [kg/tons, fractional Earth mass, etc]
  objtype [object type: asteroid, comet, planetoid, rocky, terra, gas] local to send to M.S., terrainRE
  subtype [ex. rocky->mercurial, etc] local to send to M.S., terrainRE
• Secondary Descriptors
  objage [how old it is]
  tmp-avg [average "surface" temperature]
  atmo [array for renderer, color, opacity, reflictivity, will feed renderer parameters]
  density [average density calculated from size and mass]
  metl [Metalicity]
  ele [primary elements]
  bom [bombardment level, to determine crater count for terrain] to terrainRE
• Object descriptors if spheroid
  sa-a [Semi-axis on x axis]
  sa-b [Semi-axis on y axis]
  sa-z [Semi-axis on z axis]
• If non-spheroid / IE asteroid
• For large scale modeling, no data pull needed. For modeling Binary asteroids or rotations, there will be a dedicated script for converting asteroid into a density point cloud. Will work closely with terrain.
• Internal Modeling -[might talk to geologyRE later, but some elements need to be in this reference engine for tidal force modeling]
  density[x,y,z]/[r,w,p]~~~
  material[x,y,z]/[r,w,p]
• Interplanetary Medium
  dust[x, y, z, ion] clumped dust volumes into spatial model.
  radCart[x,y,z, a, b, g, em] radiation map of the solar system
  radObj[r, obj_id] [radiation level as a function of radius from an object]
• alpha, beta, gamma, EM
  Flairs TBD
  Comet trails TBD
  Accretion/Protoplanetary discs TBD
  Planetary Nebulae (PNe) TBD

[kelsey-sorrels]

Will there be types and subtypes for star bodies?

Also, I like making coordinate's (0,0,0) the barycenter of the system. It makes sense.

[iontom]

Yep, we might even need three or four tiers of "types." Thanks to the way Mongo's collections work, this should be less data intensive too! So take Betelgeuse for example:

Type: "Star"
Sub-Type: "Red supergiant"
Classification: "M2Iab"
Variable type: "SR c"

And of course stars have tons of other luminosity properties, but with the way Mongo stores stuff you wouldn't record any of that for non-star objects.

What will be really awesome is getting a really decent schema, getting our engine part another few paradigms ahead, and then ETL some realworld data into the system! There is so much data right now, the Minor Planet Center, SDSS, Simbad, plenty of stuff to pluck and render on the fly. And then your Clojureterrain can run procedural generation for unmappable exoplanets! It will be awesome!

[iontom]

NOTE:

Treat small bodies as volumetric units. Break up solar system into quadrants and have asteroid probability density as an object instead of tracking all small bodies themselves

[rexwhitten]

Let me ask you this, in the above list of Attributes, which ones are "metrics" ? that is to say, which of these attributes are purely calculated, and not static? For example, in the generator, which ones would need to be generated?