Support for public assets

[leoncvlt]

Great plugin! In most of my projects, however, I tend to store the 3D models in the public folder, which of course results in the plugin not picking up the files for optimization.

I quickly created a proof of concept which works on those public assets - it consists of hookin up the closeBundle plugin function to recursively iterate through all files inside the viteConfig.build.outDir folder, then filtering gltfs/glbs out and running the same transform functions, overwriting the files.

It should be pretty easy to generalize the asset processing function in the plugin and have a flag in the plugins config to run that on load (for bundled assets) or on closeBundle (for public assets).

@donmccurdy would such functionality be in the plugin's scope? If so, I'll start working towards a pull request.

[donmccurdy]

Hi @leoncvlt! Not out of scope at all, but I think we'd need to decide whether using the public folder in that way is a good fit for Vite (or perhaps other bundlers). Without this plugin I would put 3D models into the public/ folder as well, which matches Vite's static asset handling guidelines, emphasis mine:

If you have assets that are:

• Never referenced in source code (e.g. robots.txt)
• Must retain the exact same file name (without hashing)
• ...or you simply don't want to have to import an asset first just to get its URL

Then you can place the asset in a special public directory under your project root. Assets in this directory will be served at root path / during dev, and copied to the root of the dist directory as-is.

I am a bit worried that (1) not supporting hashing might create cache invalidation problems for users, and (2) leaving files in public as-is might be a general expectation of Vite users that we don't want to break. If that's the case — and I'd love to get feedback on that from you and others in the Vite community! — then it might be better for us to encourage people to move toward src instead of public for these resources so we aren't working "across the grain" of Vite.

[leoncvlt]

Ha I gotta confess that I'm definitely in the third point category, I just find it less verbose to write

loadAssets("models/model.glb");

rather than

import model from "models/model.glb";
loadAsset(model);

especially when it comes down to projects with a lot of models which need to be loaded programatically, as in the former case I'd have to start messing with glob / dynamic imports. I don't really care about cache invalidation or the public files changing in filesize from development to the processed production version (I assume that's something users would be conscious of as they're installing the plugin), but I can see why it would be a concern for other users...

[ixxie]

Where should I place my models? I'm trying out the plugin in a SvelteKit project; I put the models in a subdirectory of the static folder but the plugin doesn't seem to catch anything. At least, I don't think it does, because I don't see any output in logs, nor any reduction in .glb asset size.

...

const config: UserConfig = {
	plugins: [
		gltf({
			verbose: true,
			transforms: [
				// remove unused resources
				prune(),
				// try to reduce poly count
				weld({ tolerance: 0.001 }),
				simplify({ simplifier: MeshoptSimplifier, ratio: 0.75, error: 0.001 }),
				// combine duplicated resources
				dedup(),
				// effectively remove textures
				textureResize({ size: [1, 1] }),
				// center the models in the origin
				center({ pivot: 'above' }),
				// compress mesh geometry
				draco()
			]
		}),
		sveltekit()
	],
	...
};

...

Note: I also tried reversing the order of the plugins, to no avail.

[donmccurdy]

The idea of static assets is that they're served as-is, without changes at build time. This plugin allows glTF files to be optimized at build time, so I think the result is that .glb/.gltf files will need to go somewhere under the src/ directory instead. In a typical SvelteKit project structure, and based on the asset handling guidelines, I think that location would be something like src/lib/assets/ —

<script>
  import sceneURL from '$lib/assets/scene.glb';
</script>

Other frameworks may have different conventions though, I'm not familiar with Next.js for example. In any case, we should add some of this information in README.md. :)

[ixxie]

Thanks for the tip @donmccurdy...

I'm trying to follow your suggestion but run into a mysterious error:

ReferenceError: location is not defined
    at /src/lib/assets/model.glb:1:69
    at instantiateModule (file:///home/ixxie/repos/myapp/node_modules/vite/dist/node/chunks/dep-5e7f419b.js:52224:15)

It's quite hard to google this sort of thing (I tried) and it point inside the glb file for the source of the problem. I am stomped.

If necessary I am happy to provide a minimal reproduction, but I thought I would first wait to see if you can see an obvious issue.

[ixxie]

It seems SSR was the issue. Here is a minimal reproduction, including the fix: https://github.com/seedling-life/sveltekit-gltf

[juniorxsound]

@ixxie Thanks for the added information - to echo @donmccurdy I wonder if this is worth a README section with framework specific caveats? and if so, would you be open to contributing a short blurb about Sveltekit?

[ixxie]

@juniorxsound something like this - #17?