A basic editing workflow resulting in a published asset

[OldManMeta]

Hey Don,

Apologies if this has already been covered - I'm going blind from doc overload on a ton of stuff at the moment and getting confused by picking bits from here and there ;-)

I was hoping to get a very clear understanding of how best to use the packages to achieve a simple workflow to begin with.

The scenario is - the app is an electron app; the user loads a model from disk, performs editing tasks on the model and then we save that model to a cloud blob storage, with the intention of compressing and cleaning up the model during that process.

A few questions that I have:

1. I'm confused about using draco vs meshopt - is this just a preference type deal, or is Draco seen to be a newer replacement? I would expect that our users models will have animations and blendshapes includes, so assuming that may impact my choice to only being able to use meshopt?
2. Related to that - I get that an importer of gltf needs a draco decoder, but does the same apply to meshopt that is available in something like Three.js? or is meshopt just cleaning everything up and leaving the original file contents intact?
3. The transform flow shown in your example (on the Home page) appears to be an excellent process of really cleaning up the model - are there any gotcha's there?
4. Texture compression appears to be an awesome improvement for the overall size of the package (models + textures etc) - but it did strike me that resizing the texture could mess with UV co-ordinates in someway - or is that already taken care of in the process?

File management is a really important thing for us here, especially allowing the user to manage the placement of their files for a model. So, if we performed a textureCompress-resize, does that replace the original files or create new ones and if so, where are those files placed. Is there a way to specify a filepath?

And lastly with writing the file - I see the conversion of the document to a binary file. I did see a method for including a fetch to work with URLs but I was not sure if that applied to just getting the source model file, or also applied to writing a file? Either way, understanding how to correctly write a file to both disk and to a remote location like an S3 bucket would be really helpful.

Thanks for any direction here.

[donmccurdy]

I'm confused about using draco vs meshopt - is this just a preference type deal, or is Draco seen to be a newer replacement?

Draco is more widely supported by tools. If you only need these models to be edited and displayed by your own tools and viewer, that may not matter. Both Meshopt and Draco compress mesh geometry. Meshopt can also compress point clouds, animation, and morph targets, whereas Draco leaves these uncompressed. Meshopt tends to decompress more quickly. Compression ratios on geometry are usually pretty similar, if you gzip the entire file after applying Meshopt – Meshopt is designed with that additional compression in mind. Note that both Meshopt and Draco are "lossy" compression methods, with tunable parameters. The defaults usually work pretty well, though.

Related to that - I get that an importer of gltf needs a draco decoder, but does the same apply to meshopt that is available in something like Three.js? or is meshopt just cleaning everything up and leaving the original file contents intact?

Meshopt also requires a decoder, although the Meshopt decoder is much smaller than the Draco decoder. See this three.js example for how to use it.

There is an option that requires no decoder — quantization. This won't do as much compression as draco or meshopt, however. Applying meshopt implicitly also applies quantization.

The transform flow shown in your example (on the Home page) appears to be an excellent process of really cleaning up the model - are there any gotcha's there?

Nothing to flag, except that the textureCompress step currently works only in Node.js environments, and not in a browser. There's a more advanced version of this transform flow in the CLI:

glTF-Transform/packages/cli/src/cli.ts

Lines 268 to 316 in aa9861f

	// Baseline transforms.
	const transforms: Transform[] = [dedup()];
	if (opts.instance) transforms.push(instance({ min: opts.instanceMin }));
	if (opts.flatten) transforms.push(flatten());
	if (opts.join) transforms.push(dequantize(), join());
	// Simplification and welding.
	if (opts.simplify) {
	transforms.push(
	weld({ tolerance: opts.simplifyError / 2 }),
	simplify({ simplifier: MeshoptSimplifier, error: opts.simplifyError })
	);
	} else {
	transforms.push(weld());
	}
	transforms.push(resample(), prune({ keepAttributes: false, keepLeaves: false }), sparse());
	// Texture compression.
	if (opts.textureCompress === 'ktx2') {
	const slotsUASTC = '{normalTexture,occlusionTexture,metallicRoughnessTexture}';
	transforms.push(
	toktx({ mode: Mode.UASTC, slots: slotsUASTC, level: 4, rdo: 4, zstd: 18 }),
	toktx({ mode: Mode.ETC1S, quality: 255 })
	);
	} else if (opts.textureCompress !== false) {
	transforms.push(
	textureCompress({
	encoder: sharp,
	targetFormat: opts.textureCompress === 'auto' ? undefined : opts.textureCompress,
	resize: [opts.textureSize, opts.textureSize],
	})
	);
	}
	// Mesh compression last. Doesn't matter here, but in one-off CLI
	// commands we want to avoid recompressing mesh data.
	if (opts.compress === 'draco') {
	transforms.push(draco());
	} else if (opts.compress === 'meshopt') {
	transforms.push(meshopt({ encoder: MeshoptEncoder }));
	} else if (opts.compress === 'quantize') {
	transforms.push(quantize());
	}
	return Session.create(io, logger, args.input, args.output)
	.setDisplay(true)
	.transform(...transforms);

You can quickly test how that does on your assets with:

npm install --global @gltf-transform/cli

gltf-transform optimize input.glb output.glb --compress draco --texture-compress webp

...it did strike me that resizing the texture could mess with UV co-ordinates in someway - or is that already taken care of in the process?

UVs are defined in the [0-1] space, as fractions of the texture's width and height, so resizing the textures does not require updating UVs. Most texture compression (MozJPEG, OxiPNG, WebP, AVIF) doesn't resize the texture unless requested, and preserves aspect ratio even then. Block-based compression (KTX2) will require power-of-two or multiple-of-four sizes, depending on your target environment, and can handle that resizing.

I haven't seen issues related to resizing, but block-based compression is fairly sensitive. You'll need a bit of padding around UV islands, and probably some tuning of the parameters. I'd be hesitant to use KTX2 on users' textures without human visual review.

So, if we performed a textureCompress-resize, does that replace the original files or create new ones and if so, where are those files placed. Is there a way to specify a filepath?

If you're writing scripts, then you can specify that with Texture#setURI, a path relative to wherever the .gltf is written. Your you may find it easier to have glTF Transform write a JSONDocument with NodeIO#writeJSON(document), and then deal with putting things on disk yourself. If using the CLI, it will preserve relative paths. So:

# will overwrite textures
gltf-transform cp in.gltf out.gltf

# will not overwrite textures
gltf-transform cp a/in.gltf b/out.gltf

I did see a method for including a fetch to work with URLs but I was not sure if that applied to just getting the source model file, or also applied to writing a file? Either way, understanding how to correctly write a file to both disk and to a remote location like an S3 bucket would be really helpful.

The library can read from HTTP endpoints (on by default with WebIO, opt-in with NodeIO), but it cannot write to them. Per the earlier comment, if you need to pass this data into some other JS library for storage, I would suggest having the library 'write' to an in-memory JSONDocument. The resource entries will be Uint8Arrays (equivalent to Node.js Buffers), and the json entry can be serialized as a string and written to a .gltf.

If it's easier to upload to S3 once the files are already on disk, you could use the usual I/O methods to do that first, and then upload the files. I've worked with Google Cloud Storage more than S3, but I assume the APIs are fairly similar.

[OldManMeta]

@donmccurdy - thank you so much for that detailed response to my questions. I really appreciate the effort you've put into all of this.

I'll make some POCs over the next few weeks and see how I get on, particularly with the View package.

Thanks again Don.