Skip to content
This repository has been archived by the owner on Jul 1, 2021. It is now read-only.

Creating Parts

Neal_Nicdao edited this page Dec 28, 2019 · 9 revisions

This is a guide on how to create parts for a severely incomplete game. Although there might be some tips, this is not a modelling tutorial.

You will require:

  • A working urho-osp build
  • Blender 2.8

In case Blender 2.8 is not usable, use the glTF exporter with a stable version: https://github.com/KhronosGroup/glTF-Blender-Exporter

The .sturdy.gltf format

A convenient feature of urho-osp is that part data is stored in glTF files. The files have the extension sturdy.gltf. Parts can be created, edited, and viewed without the use of specialized software. The sturdy parts in bin/OSPData/Default/Parts/* can be dragged into online glTF viewers like this. The "extras" categories of the glTF nodes are used for OSP specific data.

The GLTFFile importer in this repository is not entirely complete.

Modelling

The only modelling guidelines for now, is to use metallic-roughness PBR materials, and try to keep the triangle count low.

This model was slightly inspired by the XLR-11. It is made of multiple objects, and will feature multiple engine plumes to demonstrate flexibility.

Make it recognisable by OSP

Note: This might change soon, as part information may be moved into a separate config file

Parts are recognized as any node in the root of the scene with a name prefixed with part_.

  1. Add an empty object, prefer the Arrows display type.
  2. Position the empty to the center of mass of the model.
  3. Rotate the empty so that -Y points forward, and Z points up (Y arrow going out of the nozzle).
  4. Set the empty as the parent of all the objects in the model.
  5. Rename the empty to a technical name with the prefix part_. This is the name it will be referred to in code.

Correction: The direction of the cone empty here is incorrect as the cone actually points backwards.

Add the following custom properties to the root empty. They should be self-explanatory:

Property name DataType Example
country String United States
description String Elon's RP-1 powered Linear Beef
manufacturer String SpaceX
massdry Number (kg) 22200
name String Falcon 9 Block 4

As simple as that, this can now exported into a .sturdy.gltf file.

Adding Colliders

When brought to life as an OSP::Entity, the object just falls through the ground.

Colliders are defined by any node (usually an empty) named with a prefix col_. Their transform is used, and shape specified by the shape custom property.

Supported shapes:

  • cube
  • cylinder
  • TODO
  1. Create a cube empty and name it something like "col_somethingCollider"
  2. Add the right shape custom property
  3. Rotate, translate, and scale the cube empty into place. For cylinders, make sure that Z points along the axis of the desired cylinder.
  4. Parented it to the root empty

Note: Unfortunately, there is no cylinder empty for blender. It may help to parent a cylinder mesh to the empty to help visualize.

Using 4 identical cylinders, and 1 large cylinder.

In-game with CollisionShapes drawn

Attachments

These indicate where other parts can be attached to. This includes structural points only usable in the editor, as well as different kinds of docking ports, areas to attach a tether to, refueling booms, and whatever else might be implemented.

Attachments are recognized as any node (usually an empty) named with a prefix attach_. Their behaviour is mainly determined by the "method" custom property.

Note: The current urho-osp just ignores custom properties of attachments, the info below is just planned

TODO: Need some custom properties to describe what resources an attachment can conduct such as fuel flow or whether crew can walk through it

Point coupling method

When you want some point of a part to join with another point on a different part, this is the way. Point attachments are made by setting "method" to "POINT". Their Z axis should point outwards from the surface like a normal, and their scale determines the radial size.

TODO: Need some custom properties to describe what kind of point attachment the node is, such as flat surface or docking port.

Bar coupling method (TODO)

This may sound like a temporary name for anything in programming, but there's some meaning in it this time. Bar attachments are made by setting "method" to "BAR". The bar is a line between the empty's position, and the tip of its Z axis determined by scale. It describes beams, handles, or poles. Clasp attachments can be connected along it. Two bar attachments cannot be connected together, how would that even work?

When you're doing EVA, you may need something to hold, or attach a hook to.

Clasp coupling method (TODO)

Clasp attachments attach to the sides of Bar attachments. When you look at space probes, such as the Voyager, it's common to see scientific instruments attached along some sort of bar. Also, antennas are often mounted on the sides of poles, just search "antenna pole mount" on google. This needs some work.

Making it apply thrust

[link to a page on machines goes here]

Note: This might change soon, as part information may be moved into a separate config file

Use a Machine class to add functionality to parts. They are defined under the the "machines" custom property.

The Blender interface has troubles interfacing with custom properties that are arrays or directories. Use the scripting console to set it.

TODO

bpy.data.objects["part_hexelr"]["machines"] =
[
  {
    "type": "Rocket", # Use the MachineRocket class

    # Maximum used for Thrust and Efficiency factors defined later
    "maxPressure": 200000,
    "maxSignificantProximity": 1,
    "maxHeat": 1770,

    # Thrust or efficiency can vary 2 seconds after launch (not used)
    "timePeriod": 2,
    "loopTimePeriod": false,

    "baseThrust": 1000,
    "baseEfficiency": 300,

    # Factors that affect thrust
    "thrust": {
      "throttle": [0, 4, 80, 100], # thrust = thrust * 100% at max throttle
      "pressure": [100, 0], # thrust = thrust * 0% at max throttle
      "proximity": [140, 100], # Increased thrust when close to the ground (this isn't that important, ignore it)

      # The following are not entirely important
      "dotAcceleration": [100],
      "acceleration": [100],
      "time": [100],
      "mach": [100]
    },
    # Factors that affect efficiency
    "efficiency": {
      "pressure": [100, 50] # Reduced efficiency at higher pressures
    }
  }
]

Exporting

  • Triangulate all meshes to properly export tangents for normal maps
  • Tick Export Extras
  • Use glTF Separate
  • File extension must be .sturdy.gltf
  • Must be in a bin/OSPData/*/Parts folder