Expose glTF 2.0 exporting from scripting for run-time usage

[goatchurchprime]

Describe the project you are working on

Cave mapping program from within VR https://github.com/goatchurchprime/tunnelvr

Describe the problem or limitation you are having in your project

My problem is due to building CAD capabilities in Godot. I use VR to define textured geometry (the GDscript code generates the shapes which the player interacts with using a SurfaceTool object). I would like to be able to export these creations as assets so they can be used and rendered elsewhere.

This feature could also prove useful to move gamestates and assets between networked players.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

This uses the binary format data created on the fly rather than only what is stored on the disk.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

The announcement says this feature is only supported in editor builds (tools=yes) https://godotengine.org/article/introducing-the-godot-gltf-2-0-scene-exporter My proposal is to generalize this feature so it is available in the standard GDscript like a save_var() function.

If this enhancement will not be used often, can it be worked around with a few lines of script?

My current hack is to output my triangles as an STL file.
https://github.com/goatchurchprime/tunnelvr/blob/master/GUIPanel3D.gd#L143 This loses all the UV mapping and the materials/colours. One option is to make up my own file format and then use some Python scripts and libraries to generate the gltf file from it. (I have considered, but rejected, implementing a limited gltf exporter in GDscript.)

Is there a reason why this should be core and not an add-on in the asset library?

It's an upgrade of something that is already in the core.

[Calinou]

Compiling the glTF exporter in export templates would increase binary size noticeably, so I'm not sure if it's worth the effort. Also, I think it's likely that @fire wrote it in a way that makes it rely on editor functionality.

This feature could also prove useful to move gamestates and assets between networked players.

This is likely a bad way to achieve it for various reasons (even security). I wouldn't trust arbitrary glTF files for this.

My current hack is to output my triangles as an STL file.
https://github.com/goatchurchprime/tunnelvr/blob/master/GUIPanel3D.gd#L143 This loses all the UV mapping and the materials/colours.

You can implement your own OBJ + MTL exporter and loader. The format supports UV mapping and non-PBR materials in the MTL file. For PBR, you'll need to design your own extension to the MTL format, but it can likely be done.

[fire]

I wanted the gltf2 export to work at runtime, so the only dependency is the EditorSceneImporterMesh / EditorSceneImporterNode3d for tools=no usage. You can easily copy those classes to a module with the names renamed.

You can also ship tools=yes as your game.

The apis are well defined for runtime usage.

class PackedSceneGLTF : public PackedScene {
	GDCLASS(PackedSceneGLTF, PackedScene);

protected:
	static void _bind_methods();

public:
	virtual void save_scene(Node *p_node, const String &p_path, const String &p_src_path,
			uint32_t p_flags, int p_bake_fps,
			List<String> *r_missing_deps, Error *r_err = NULL);
	virtual void _build_parent_hierachy(Ref<GLTFState> state);
	virtual Error export_gltf(Node *p_root, String p_path, int32_t p_flags = 0,
			real_t p_bake_fps = 1000.0f);
	virtual Node *import_scene(const String &p_path, uint32_t p_flags,
			int p_bake_fps,
			List<String> *r_missing_deps,
			Error *r_err,
			Ref<GLTFState> r_state);
	virtual Node *import_gltf_scene(const String &p_path, uint32_t p_flags, float p_bake_fps, Ref<GLTFState> r_state = Ref<GLTFState>());
	virtual void pack_gltf(String p_path, int32_t p_flags = 0,
			real_t p_bake_fps = 1000.0f, Ref<GLTFState> r_state = Ref<GLTFState>());
};

Arguing for tools=no gltf2 export was very difficult so I decided to use these two fallback options.

Edited:

For the gdscript / visual script, I would define a spec for the gltf2 extension and write the code for embedding it! If you do do this, please delight me by notifying me!

[goatchurchprime]

I'm afraid I don't exactly know what this "tools=yes/no" thing means. All I know about is putting the word "tool" at the start of a GDScript file. Is it a project setting in the v4.0 projects settings or something that includes it or not? If that sorts it out then that's good enough to move forward and close this ticket -- if the method for enabling the feature is documented.

Just making this feature possible in some alpha state would be good enough to prove whether it has wide use (or not). If this does eventually develop into the one true convenient 3D interchange format, then the loader will obviously have filter/sanitation options, just as we do with JSON to avoid any nasties. (Remember when that format was invented we could only load it by calling "exec()"!)

@Calinou Thanks for the tip on OBJ. I'm showing my CAM background in only knowing about STL. It looks like I could use Blender to convert to GLB, which is what is required to import an asset into hubs.link. I've been looking at pygltflib and it's doing my head in. That library requires you to do your own bytes and buffer packing.

[Calinou]

I'm afraid I don't exactly know what this "tools=yes/no" thing means.

tools=yes refers to editor builds, tools=no refers to non-editor builds (export template).

Is it a project setting in the v4.0 projects settings or something that includes it or not?

No, as it's a compile-time option 🙂

[goatchurchprime]

Making an OBJ exporter worked and is enough to satisfy my workflow needs today, so I'll close this for now. Someone can re-open it if they need it.

[Calinou]

For reference, this is now implemented in 4.0alpha: #3273