-
Notifications
You must be signed in to change notification settings - Fork 10
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
base: main
Are you sure you want to change the base?
Conversation
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 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: This video seems to be attaching thrusters to the seat directly, very funny |
@yankscally glTF has one coordinate system mandated by the spec: Right-handed, +Y up, +X left side, +Z front, meters.
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).
Absolutely, we need more examples, and help would be very welcome!
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" |
6456a13
to
5557261
Compare
5557261
to
b108ce2
Compare
b108ce2
to
53b0590
Compare
53b0590
to
cdab278
Compare
cdab278
to
fbe4675
Compare
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.