Blender 5.2 turns any folder of .blend files into a library your customers subscribe to from inside Blender. One terminal command, a static web server, no marketplace in the middle. I wanted remote asset libraries to be the answer, so I ran the arithmetic against a pack I actually sell, and the first number back was 643 megabytes to get one wood plank.
That number is not Blender's fault. It is mine, and it is probably yours as well.
What a remote asset library actually is
A directory of .blend files with a set of JSON listing files next to them, served over ordinary HTTP. Blender reads the listing, shows every asset in the library, and downloads a .blend only when somebody asks for one. It arrived in 5.2, an LTS release, which is the only reason I bothered testing it rather than waiting. The Blender developers' blog post on remote asset libraries, from July, is the honest account of what it does and does not do, and the manual page called Remote Asset Libraries carries the hosting instructions.
You generate the listing from inside the library folder, by running Blender in the background with the asset_listing generate command and a dot for the current directory. That is the whole publishing step. It writes the JSON, exports the previews, and leaves a meta file where you set the library name and your contact details once. Re-run it whenever anything changes; the manual is explicit that merely re-saving a file counts as a change. Then copy the folder to nginx.
The generator is not the hard part. What is inside the .blend files is the hard part.
Packing is a byte copy, and that is the whole problem
Every asset has to be self-contained. No linking to other .blend files, no external images, everything packed. That is stated in the manual and again in the developers' post, and it is the constraint that decides whether any of this works for you.
So I took the texture set behind my 51 Wood Planks and Beams pack: eight material sets covering fifty-one pieces, twenty-four maps, every one of them 4096 by 4096. Colour and ORM ship as JPEG, 2.0 to 5.1 MB each. The normals ship as 16-bit PNG, 62.9 to 81.8 MB each. On disk the whole set is 642.73 MB.
I built one material from one of those sets, marked it as an asset, packed the images and saved it three ways.
- The three source files on disk: 83.50 MB
- The packed .blend: 84.01 MB
- The packed .blend with Compress File enabled: 83.58 MB
Packing does not compress anything. It copies your image files into the .blend byte for byte, and that half-megabyte difference is the material, the node tree and the file header. Compress File bought me half a per cent, because PNG and JPEG are already compressed and there is nothing left in them for zstd to find.
Whatever your texture folder weighs is what your customer downloads. There is no step in between where it quietly gets smaller.
One asset costs one entire file
Here is the part that catches people. A single .blend can hold many assets, and the listing handles that perfectly well. Downloading, however, is per file. The developer documentation says it plainly: storing multiple assets in one file is possible, but users have to download that entire file to import one of its assets.
So I put all eight materials into one .blend and packed it. 643.54 MB. With Compress File on, 642.46 MB.
Somebody who wanted one weathered joist for a barn would pull 643 megabytes and receive seven materials they never asked for. On a marketplace they would have bought the pack and downloaded it once, deliberately, knowing the size. Here they clicked a thumbnail.
One asset per .blend, then. That is not a tidiness preference, it is the only lever you have over download weight, because nothing downstream in the listing gives you a smaller one. Where two materials genuinely share a texture set, put those two together and nothing else.
The 16-bit normal map is what kills it
Even split one asset per file, 84 MB per material is not a library anyone browses. So I went at the largest file in the set: a single 4K normal map, shipped as 16-bit PNG at 75.94 MB.
- 16-bit PNG at maximum PNG compression: 76.63 MB. It got bigger.
- 8-bit PNG: 28.05 MB.
- WebP at quality 90: 5.33 MB.
Fourteen times smaller than what I ship. I re-encoded all twenty-four maps to WebP at 90 and rebuilt both files. One material, packed: 12.01 MB, down from 84.01. All eight in one file: 102.12 MB, down from 643.54.
Twelve megabytes is a library. Eighty-four is a download.
Two warnings before anyone points a batch converter at their archive. First, this is the remote copy, not the product. The 16-bit file stays in the archive the buyer pays for, because 16 bits is what survives being driven into a displacement or tessellated at render time. Second, WebP at 90 is lossy, and a lossy normal map shows its blocking at grazing angles, which is precisely where normals are weakest already. Test your worst case, a large flat panel under raking light, before you commit to it. On wood grain at 4K I could not see the difference. On smooth painted metal I would not take the risk.
There is no login, so this is not your shop
This is the part I would have wanted somebody to tell me before I spent a weekend on it.
There is no authentication. The listing is static JSON on a static server, and the developer documentation files authorisation hooks under potential improvements, as something that could be added rather than something with a date on it. Until it exists, whoever has the URL has the library.
There is no concept of asset versions either. Blender can only tell whether the remote file is the same as the one already downloaded, or different. Not newer, not older. Fix one roughness value, re-save, and every subscriber sees a changed file with no way to know what changed or whether they want it.
So this is not a route around the marketplace. It is an excellent delivery mechanism for the part of a catalogue you already give away — the free tier, the sampler, the set you hand students on day one — and a genuinely good one for a small team sharing a house library across four machines. Both of those are worth doing, and I am doing them. Neither is the thing the headline implies.
What to put on a server this week
- Pick a folder where every .blend is already independent. If anything links out, or points at an image on your drive, it is not ready.
- One asset per file. Name the files so a stranger can guess the contents, because the filename is what ends up in the listing.
- Re-encode the remote copy. WebP where it survives inspection, 8-bit where it does not, 16-bit only where the map is doing displacement work.
- Check that your web server sends Content-Length and ignores query strings. The manual requires both, because Blender appends a hash parameter to every URL to stop proxies serving a stale file. Switch on ETag or Last-Modified too. The listing re-syncs once a day, so a 304 is the difference between polite and expensive.
- Run the generator, edit the meta file once, copy the folder up.
Then open the library on a machine that is not yours, over a connection that is not yours, and click the heaviest thing you own. Whatever number appears is your actual product.
