Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

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

Open
iontom opened this Issue · 4 comments

3 participants

@iontom
Owner

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
@aaron-santos

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
Owner

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
Owner

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
Owner

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.