Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OMI_vehicle_* extensions #231

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

aaronfranke
Copy link
Member

@aaronfranke aaronfranke commented Aug 29, 2024

This PR is the start of my plans to add a general-purpose vehicle standard into OMI's glTF extensions.

Preview: https://github.com/aaronfranke/gltf-extensions/tree/OMI_vehicle/extensions/2.0/OMI_vehicle_body (and see also the OMI_vehicle_wheel and OMI_vehicle_thruster folders).

Proof of concept Godot implementation: omigroup/omi-godot#11

OMI_vehicle_body is the base type, the properties here are vehicle-wide and highly generalized. For example, while a car would have steering left and right for its only angular control, OMI_vehicle_body defines a Vector3 for angular activation, where a car's steering would be represented as rotation around the Y axis (ZX plane). The other angular directions may be used for other types of vehicles, such as aircraft and spacecraft pitch/roll. Similarly, the linear activation is defined as a Vector3, whereas a car would just use the Z direction for forward/backward.

OMI_vehicle_body also defines gyroscope torque, maximum speed, and several properties for how vehicles should be controlled, such as dampeners, throttle, and most importantly the pilot seat. The pilot seat refers to a glTF node with the OMI_seat extension, and the player sitting in this seat should control the vehicle.

OMI_vehicle_wheel is designed for things like cars and aircraft landing gear. It defines the maximum force, steering angle, and variables to control the current activation ratios of those. Note that many driving games define engine force and steering vehicle-wide, while OMI_vehicle_wheel defines these on the wheel. This is to allow for asset authors to have full freedom in designing vehicles, and compatibility with games like Space Engineers which only define per-wheel properties. Also, many driving games use properties like wheel count and axle width, but this would prevent custom configurations such as the Reliant Robin, so OMI_vehicle_wheel allows any amount of wheels in any position using glTF node positions.

OMI_vehicle_wheel also defines a radius, width, physics material, and 4 different suspension properties including damping, stiffness, and travel. For the physics material, this depends on #226, because physics materials still need to be added to the OMI_physics_body extension.

OMI_vehicle_thruster can be used for vehicles such as aircraft, spacecraft, rockets, and more. It defines force and gimbal, including the maximum, and variables for the current activation ratio. For both wheels and thrusters, the current activation ratio is exposed, allowing wheels and thrusters to optionally be used independently of OMI_vehicle_body, making all three extensions technically independent. For example, someone may choose to attach an OMI_vehicle_thruster to a non-vehicle dynamic rigid body node, and script custom input with a KHR_interactivity script, for a result such as this https://www.youtube.com/watch?v=qsdhFXUD8nA&t=150s

The OMI_vehicle_body folder also has a Markdown file called mappings.md that defines how these properties correspond to properties in various games, game engines, and platforms. This document needs to be expanded as we do more research into vehicle systems, and discoveries made as part of that research will help refine the standard.

@yankscally
Copy link

Looks really good!

"The pilot seat is expected to face +Z" - which coordinate system is that? there are 4 being used. You also mention coordinate refrences elsewhere. Does gltf assume a coordinate system?

in simple_car.gltf, there are 4 seats but they each refrence the same trigger area, is this intended? from my understanding each seat would need its own trigger area.

vehicle, wheel, and thruster basically covers all the vehicles, it would be nice to try and get a .gltf example file of a spaceship, sub, boat, plane... motorcycle? It's really versatile and would be good to show that off. I can give you a hand with some of them.

and also, is there a way to use thrusters and wheels outside of a vehicle object? For example there could be wheel objects that are yet to be attached to a vehicle body (in a game implementation) and thrusters can be attached onto other objects in games like gmod. A small mention of this would be nice maybe.

example in gmod:
https://www.youtube.com/watch?v=NsWJpI9iqJM

This video seems to be attaching thrusters to the seat directly, very funny

@aaronfranke
Copy link
Member Author

@yankscally glTF has one coordinate system mandated by the spec: Right-handed, +Y up, +X left side, +Z front, meters.

in simple_car.gltf, there are 4 seats but they each refrence the same trigger area

Specifically, they reference the same shape resource. And to clarify terminology, "resource" is a word I am borrowing from Godot to describe pieces of data used by nodes that may be shared between nodes. It's the same as a glTF mesh (Godot "Mesh") resource being used on multiple glTF nodes (Godot "MeshInstance3D" nodes). In this case it's a OMI_physics_shape shape (Godot "Shape3D") resource being used on multiple glTF triggers (Godot "CollisionShape3D" nodes as children of "Area3D" nodes).

vehicle, wheel, and thruster basically covers all the vehicles, it would be nice to try and get a .gltf example file of a spaceship, sub, boat, plane... motorcycle? It's really versatile and would be good to show that off. I can give you a hand with some of them.

Absolutely, we need more examples, and help would be very welcome!

and also, is there a way to use thrusters and wheels outside of a vehicle object?

Yes, the spec does not forbid that, and my implementation allows for it. In fact I mentioned this above: "For example, someone may choose to attach an OMI_vehicle_thruster to a non-vehicle dynamic rigid body node, and script custom input with a KHR_interactivity script, for a result such as this"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants