Skip to main content
Getly

Command menu

Jump to a page or search the catalog

Requires Blender 4.2 or newer · Free

Getly Publisher for Blender

A Blender extension. It reads your file the way a buyer's Blender will, tells you what will break, and fixes what can be fixed in one press. Every check runs offline with no account; logging in is a separate, optional step.

View the listing About the tool

The problem, measured

A .blend stores paths, not files. It opens perfectly for the author because their textures are still on their own disk; the buyer opens it and every surface is flat magenta. Today Getly carries 93 live Blender products across 17 stores, and 10 .blend files in the entire catalog, because sellers ship archives.

Every decision, and what it cost

01

The gate opens the archive instead of reading the file extension

Why

92 of the 93 live Blender products ship as a .zip. A gate keyed on the extension - the way the Unity one is - would have fired on almost none of them. Opening the archive is also what makes the headline check correct rather than merely strict: a texture that is not packed into the .blend is not a defect when it is sitting right beside it in the same download.

What it cost

A zip reader, on bytes a stranger uploaded, with every bound that implies. It claims an archive only when a .blend or an add-on manifest is genuinely inside, so the hundreds of ordinary zips in the catalog are read once and then left alone.

02

It fixes, because a reporter loses to a menu item

Why

Blender has shipped Report Missing Files, Make Paths Relative and Pack Resources for years. A tool that only repeats what they say competes with something already installed, and loses on every axis including the cost of installing it. This runs those steps in the right order in one press - paths made relative before packing, so a later unpack leaves a working path rather than the absolute one you started with - and then says exactly what it changed.

What it cost

Writing into somebody's project is a serious thing to do. So it lists what it will change before changing anything, and it never saves the file: you look at the result and save it yourself.

03

Every check runs offline, with no account

Why

The tool has to be worth installing for somebody who will never sell anything on Getly. A validator with a shop attached is an advertisement, and Blender's own extension repository - a free, official channel inside the application - would read it as one.

What it cost

We learn nothing about who installs it or what it finds unless they log in, so the check list is calibrated against files we author rather than against what sellers actually hit.

04

A file we cannot read is "not checked", not a refusal

Why

A hand-written reader of a self-describing format will eventually meet a Blender release it does not understand. On that day the failure has to be "we could not check this", not "every Blender seller is refused". The one exception is a file that is not a .blend at all - Blender will not open that either, and that is the buyer's problem to be spared.

What it cost

A deliberately corrupt file passes. We would rather refund that than take the platform down for everyone selling Blender work the week a new release lands.

05

It is GPL, so the checks are forkable - which is why the server decides

Why

The Blender Foundation treats the Python API as part of Blender, so anything built on it ships GPL-compatible. That means our check list and our sign-in flow are readable and forkable by anyone. We did not work around it; it is precisely why Getly re-reads the uploaded bytes rather than trusting a report from a program the seller controls.

What it cost

Nothing in the client is a moat. What is left is the server side and whatever judgement is in the check list, and the license touches neither.

What we got wrong first

These were caught before a buyer saw them, which is the only reason we can write them down. They are here because the decisions above teach less than the mistakes do.

We wrote

A path scanner that would have refused every well-made file.

The truth

The plan was to scan the decompressed bytes for machine-rooted paths, the way the Unity checker scans text files. Measuring real files killed it in a minute: every .blend Blender writes contains a /Users/… path of its own, and a correctly PACKED image records the author's absolute source path inside the file. The scan would have fired hardest on flawless work. The reader now parses the file's own type description and reads named fields out of named structures.

For your listing

Test your idea against a good example before you build it. If it complains about something you know is right, the idea is wrong - not the example.

We wrote

A reader that crashed on any archive built with Finder.

The truth

macOS writes a companion file for every real one when you use Compress, tucked into a parallel __MACOSX folder and named ._yourfile.blend. Its name ends in .blend and it is not one. The reader picked it up and threw, which would have broken the check for every Mac seller on the platform. A synthetic test archive would never have shown it; the one built by the actual tool did, immediately.

For your listing

Build your test files with the tool your buyer uses, not the one that is convenient. Ours only worked because we stopped hand-assembling archives.

We wrote

A 407 KB file that read back as 1 236 bytes and looked fine.

The truth

Blender compresses with Zstandard in several frames back to back. The standard decompressor returns the first frame and stops - no error, no warning, just a valid-looking header and almost none of the file. We only caught it because a test compared the compressed copy against its uncompressed twin.

For your listing

The failures that cost the most are the ones that look like success. Compare against a known-good result, not against "did it throw".

We wrote

A "check passed" badge that could vouch for a file nobody opened.

The truth

Two paths record a report for a file we deliberately did not read - over the size limit, and one our reader could not parse. Both store an empty findings list, and "no findings" was being read downstream as "nothing wrong". Nobody was mislabelled yet, but the next seller to press Check on a large package would have been. The report now records whether we actually opened it.

For your listing

"We found nothing" and "we did not look" are the same shape and opposite meanings. Anywhere your listing implies a check, make sure it can tell those two apart.

What it does not do

  • It is not a virus scanner. A .blend can carry Python, and the check tells you when a script is flagged to run on open - a fact about the file, not a judgement about you.
  • It does not judge whether your asset is good. Only whether it arrives working.
  • It cannot tell whether a render matches your listing images. It can tell you the file has no lighting to reproduce them with.
  • It is Blender only. There is a Unity version; there is nothing for Unreal, Photoshop or Cinema 4D.

How we convinced ourselves

Blender wrote every test file

Not one fixture was assembled by hand. The whole risk in a format reader is that the format is not what you assumed, and a hand-built fixture encodes the assumption twice instead of testing it once. That discipline caught three separate mistakes before any of them shipped.

More tests assert what must NOT be refused than what must

A packed file, a .blend beside its texture folder, an archive built by Finder, a procedural material, a material library with no objects at all. Proving a checker catches defects is the easy half; proving it stays quiet on good work is the half that decides whether anyone keeps reading it.

The harness itself lied once, and that was worth finding

It printed PASSED while an assertion was failing, because a Python script exiting with an error code inside Blender does not reach the shell. A test that cannot fail is worse than no test, so the verdict is now a marker line the shell greps for - a missing line counts as a failure too - and the harness is checked against a deliberately broken build.

The listing itself

The description leads with the buyer's experience, not ours

It opens with the magenta surface, because that is the thing a Blender author recognizes instantly and has probably already shipped once. Then what blocks publishing, then the honest answer to "Blender already has Pack Resources" - which is the objection any experienced seller will raise first.

The cover draws the failure, not the tool

A magnifying glass could belong to any marketplace. This one draws a texture escaping a file with the mascot reaching to catch it, which is legible at thumbnail size and is literally what the product prevents. The word is hand-lettered rather than a logo copied.

Free, and GPL on top

Anything built on Blender's Python API ships GPL-compatible, so the source is readable and forkable. Charging for it would have been charging for our own quality bar.

One archive, built by Blender's own builder

The download is produced by the extension builder Blender ships, not zipped by hand - which is also how we know the manifest is valid, because the builder refuses an invalid one.

Our own checker found a real problem in our own package

Publishing it runs the same gate every seller passes. It came back with one finding: the archive had no readme, which is one of our own twelve advisory checks. We fixed the package rather than the check, and the readme it produced is now what the listing and the extension repository both show.

View the listingStandards