DEV Community: Selin Vidal

Meshy AI 3D Review 2026: 15.26 MB Buys Only 254,336 Triangles

Selin Vidal — Fri, 09 Oct 2026 16:03:34 +0000

This is an independent test. Nothing here came from vendor access: both tools were used on my own free and paid accounts.

I needed a director's chair.

Not a real one. A 3D one — a film-set prop I could drop into a virtual set and spin around on a detail page. I had one illustration of it and no time to model anything by hand.

So I asked around. Every time the question "what do you use to turn an image into a 3D model?" came up, two names came back: Meshy and SupaVoxel. Nobody could tell me which one to pick.

Fine. I ran the same illustration through Meshy, then through SupaVoxel, downloaded both files, and pulled them apart offline.

My verdict in 60 seconds — Meshy 62/100, SupaVoxel 90/100. Those are my subjective scores for this one job, not a lab result. Everything else on this page is a number I read out of the two files.

Download size — Meshy 15.26 MB vs SupaVoxel 10.25 MB · Meshy 6/10 · SupaVoxel 9/10 — Meshy makes every visitor pull 5 MB more down the wire; SupaVoxel's file is the lighter one to serve, cache and store.
Triangles in the file — Meshy 254,336 vs SupaVoxel 1,500,000 · Meshy 6/10 · SupaVoxel 9/10 — triangles are the little flat plates a shape is built from, and Meshy is working with about a sixth of them; SupaVoxel has the plates to bend a piece of canvas around.
Vertices — Meshy 146,472 vs SupaVoxel 854,468 · Meshy 6/10 · SupaVoxel 9/10 — Meshy runs short of corners exactly where the fabric creases; SupaVoxel has corners to pin a fold to.
Bytes per triangle — Meshy 60.0 vs SupaVoxel 6.8 · Meshy 4/10 · SupaVoxel 9/10 — Meshy charges the most download per unit of shape in this test; SupaVoxel delivers shape for roughly a ninth of the bytes.
Edges across the fabric span — Meshy sparse vs SupaVoxel dense, same wireframe camera · Meshy 5/10 · SupaVoxel 9/10 — Meshy puts long slivers along straight frame pieces and starves the canvas; SupaVoxel puts its edges where the surface actually curves.
Wait on a 12 Mbps phone line — Meshy 10.2 s vs SupaVoxel 6.8 s · Meshy 6/10 · SupaVoxel 9/10 — Meshy spends three and a half extra seconds of blank viewer per visitor; SupaVoxel gets the prop on screen sooner.
Export options from one run — Meshy one GLB vs SupaVoxel compressed GLB plus an original-size GLB · Meshy 7/10 · SupaVoxel 9/10 — Meshy gives you one file and that's your lot; SupaVoxel's menu hands you a light one for the web and a plain one for a fussy importer without regenerating anything.
Textures baked inside — Meshy 3 vs SupaVoxel 3 · Meshy 7/10 · SupaVoxel 7/10 — a genuine tie: identical count out of both files, so nothing separates them here and neither side gets credit for it.

This is one image and one run on each side — not a lab study. Here's what I found.

The SupaVoxel chair. That's the tool I ended up keeping for this job — supavoxel.com — and I'll show you why below.

Why the smaller file was the one with more detail

I expected this to be a trade. Smaller file, less stuff in it. That's how it usually works.

It wasn't. Not the way Meshy did it.

Meshy handed me 15,262,068 bytes. The other file was 10,245,480 bytes. Meshy's is about 49% heavier.

And then I counted what was inside. Meshy: 254,336 triangles. The other one: 1,500,000.

Meshy asked me to download half again as much file, and gave me roughly one sixth of the shape.

And with Meshy you paid those extra bytes for less model. The download section below puts real numbers on what that costs your visitors.

The Meshy chair, same camera angle, same lights, same viewer. 15.26 MB. Each file carries its own idea of which way is forward, so don't read this as a pixel-perfect overlay.

What 1,500,000 triangles actually buys you

A director's chair is a specific problem. You have an X-frame made of straight sticks, and you have two panels of canvas that sag.

Straight sticks are cheap. Sagging canvas is not. A curve needs edges to sit on, and if there aren't enough, the curve turns into a set of flat facets.

Meshy had 254,336 triangles and 146,472 corners to spend across the whole chair. That budget is fine for the frame and thin for the fabric — and the fabric is the thing everybody looks at.

Meshy's chair head-on. Everything reads at this distance. That's the honest starting point — at arm's length, both files look like a chair.

The SupaVoxel chair from exactly the same camera as the Meshy shot above. Still a chair. The difference doesn't show up until you get closer.

What 146,472 corners means when the fabric has to bend

Triangles get the headlines; vertices are what actually limits you. A vertex is a corner — a point that triangles hang off. Meshy's file has 146,472 of them. The other file has 854,468.

Here's where it bites. You drop the Meshy chair into your set, it looks great at working distance, then the shot calls for a slow push-in. Now the seat edge is forty percent of frame and Meshy hasn't got the corners to describe a curve. You can't fix that in a shader — you'd be remodelling the seat by hand, which is the job you paid a tool to avoid.

Zoom into the wireframe and you can see where the budget went

A wireframe render draws only the edges, so you can see how the model is built underneath the picture. Here's Meshy's, pulled in tight on the frame and the fabric.

Meshy's wireframe up close. Watch the long slivers running along the straight frame pieces, and how few edges cross the fabric.

The SupaVoxel wireframe from the same camera as Meshy's. More edges where the surface actually curves.

Don't count Meshy's lines. Look at where they are.

Meshy spent a lot of its triangle budget on straight pieces that didn't need them, and ran short across the canvas that did. That's a distribution problem, not a count problem, and it's the kind of thing you only find out after you've already built the shot around the model.

Does the mesh hold up with the texture switched off?

Texture hides a lot. Strip it off Meshy's chair and you're looking at raw shape.

Meshy's chair with the texture removed. This is what 254,336 triangles look like carrying a whole prop by themselves.

The same view of the SupaVoxel chair. Denser than Meshy's — and yes, that density has a cost, which I get to in a minute.

If you're going to relight this thing, or push in on it, or put it anywhere near a camera move, the untextured shape is what you're really buying from Meshy. Texture is makeup. Geometry is bone structure.

So what does 60 bytes per triangle actually mean for you?

Divide Meshy's file size by its triangle count and you get a rough price per unit of shape. Meshy: 60.0 bytes per triangle. The other file: 6.8.

Fair warning — both files bake in 3 textures, so neither number is pure geometry. More on that next.

Every megabyte Meshy adds is a megabyte you serve, cache, store and pay for — and in this run those megabytes weren't buying shape.

Three textures each, so the weight isn't coming from the paint

Before you assume Meshy's file is fat because it's carrying more image data: it isn't. I counted what's baked inside each GLB. Meshy: 3 textures. The other file: 3 textures — the count, straight out of the files, not resolutions.

That kills the kindest explanation for Meshy's extra 5 MB. Meshy is heavier while carrying the same number of maps and one sixth of the geometry. There's nowhere left for those bytes to hide.

What the wait actually looks like: phone first, then desktop

These are division, not a stopwatch. On a clean, steady 12 Mbps phone connection, Meshy's 15.26 MB is about 10.2 seconds of pure transfer against 6.8. On a clean 100 Mbps desktop line, Meshy is about 1.22 seconds against 0.82. Both assume perfect effective bandwidth — Meshy's and the other one's alike, no handshake, no decode, no cache.

So does 0.4 of a second on desktop matter? On its own, no. But the phone number is the one that decides whether somebody sees your prop at all. Ten seconds on a mobile connection is past the point where people swipe away, and every extra second there is a visitor Meshy's file cost you.

A hundred props: what your drive and your meter look like

Nobody dresses a whole production with one chair — not with Meshy, not with anything. So multiply this single run by a hundred, holding every measured number exactly where it is and assuming nothing fails.

Storage: Meshy's side lands at about 1.53 GB. The other side at about 1.02 GB. Half a gigabyte of difference for one project's worth of set dressing — and you give up no detail to get it back, because the smaller file is the denser one.

Credits: Meshy's side scales to 3,500 Meshy credits, the other to 300 SupaVoxel credits. Meshy credits and SupaVoxel credits are two different plans in two different units — that's not a price ratio and I'm not going to turn it into one.

Both are straight multiplication, not a second hundred Meshy runs — a planning estimate, nothing more.

How many clicks until you actually have the file?

Upload the picture, set the options, wait, open the download menu, pick a format, save. That's the whole Meshy loop, and the other tool's too. Both let me leave with a GLB — the single-file 3D format that packs geometry and textures into one blob, which most web viewers and engines read with no conversion step. Same format both sides, so every size comparison here is like for like.

Meshy's download options. A screenshot proves what the screen said — I still checked the real file size on disk rather than trusting the menu.

The SupaVoxel export menu at the same point in the run as Meshy's.

And the GLB options underneath it — a compressed build for the web and an original-size build for anything fussy, both off the same generation.

No drama on either side. If you were expecting Meshy to make you fight for your model, it doesn't — and neither does the other one.

Meshy showing the finished, textured result before download. This is the screen where the job flips from "generating" to "yours" — and the point where Meshy's 245.8-second clock stopped.

What happens when your importer has never heard of meshopt

This scenario decides the whole comparison for some of you, so here it is on its own.

Every GLB can declare extensions it requires — features a reader must support or it can't open the file at all. Meshy's file: empty. No required extensions.

The compressed SupaVoxel file: EXT_meshopt_compression and KHR_mesh_quantization. Meshopt compresses geometry; quantization stores coordinates in smaller number formats. Both need a decoder on the reading end.

Picture the moment. An older importer, a locked-down studio pipeline, a client's viewer you can't touch. Meshy's single file at least tries.

And this is exactly what SupaVoxel's second export is for. The same menu that produced the compressed GLB also offers an original-size GLB — no meshopt, no decoder, nothing to install. You take the light one to the web and the plain one to the fussy importer, off one generation, without hunting for a converter. Honest limit: the extension flags are measured from the files, the import outcome is inference. I loaded neither into a real importer.

The two numbers nobody captured — and why I'm telling you anyway

I can tell you what the files contain. I can't tell you how often Meshy or the other tool falls over.

Failure counts: not captured. Retry counts: not captured. For Meshy and the other side alike. I didn't record them, so I don't have them, and I won't gesture at them with "seemed reliable". I also didn't capture what either product claims on its own pages.

Because an article that quietly skips the metric it didn't measure is the one to trust least. If Meshy drops one run in five, everything above changes, and neither of us knows.

Where Meshy actually wins

I'm not going to bury this. Meshy took real points here, and in these situations Meshy is your answer.

Meshy's main file requires no extensions at all. That is a measured fact and a real point: one file, no decoder, no conditions. On the SupaVoxel side you get there by taking the original-size export from the same menu, which needs no decoder either.

The exchange rate: Meshy's single no-conditions file costs you roughly 5 MB of extra download and about five sixths of the shape. If you never want to think about which export to grab, that's a fair price.

Meshy's model is lighter once it's in memory. Estimating geometry memory from the vertex and triangle counts gives Meshy about 7.7 MB against about 45.3 MB. That is exactly what a lean triangle budget is for, and Meshy earns it.

The exchange rate: six times less memory pressure, paid for with canvas that runs out of edges. Deep background, take Meshy's. A prop the camera pushes into, don't.

And Meshy was faster. 245.8 seconds of recorded generation against 274.9. Meshy got there about 29 seconds sooner. One run each, and each tool times its own clock, so treat that as an observation rather than a speed rating.

How to pick, for a job like this

You're putting the prop on a page and bytes matter — take the SupaVoxel file. 10.25 MB against 15.26 MB, measured.
Your importer can't handle meshopt — Meshy's single file, or SupaVoxel's original-size export. Both are decoder-free; only one of them also gives you a light copy for the web.
You want to know which one is cheaper — I can't tell you. One tool's ledger said 35 credits, the other said 3, and those are two different plans with two different units. I'm not turning that into a dollar comparison, and neither should you.
You need something production-signed-off — neither, yet. One generation from one image tells you nothing about rigging, thickness or whether it survives your engine.
You need to know whether the chair's arms would actually detach, or whether it would really fold — not answered here by either tool. A screenshot, a triangle count and a file format are not a manufacturing test, and I won't let any of the three stand in for one.

Final verdict: Meshy scores 62/100 for this job

Meshy did the job. Meshy gave me a clean GLB that opens anywhere, in under four minutes, and Meshy did it about 29 seconds faster than the alternative.

But Meshy charged me 15,262,068 bytes for 254,336 triangles — 60 bytes of download per triangle against 6.8 — and Meshy's wireframe shows exactly where that ran out: across the canvas, which is the one surface on a director's chair that anybody looks at.

62/100 is my call on this one chair, from this one run. It's not a ranking of Meshy's output in general, and I'd be lying if I claimed otherwise off a single image.

Try it on your own image before you trust either one

If your job looks like mine — a prop that has to be small on the wire and dense enough to survive a close shot — supavoxel.com is where I'd start — take the compressed GLB for the page and keep the original-size one for whatever refuses it.

But run your own picture through both before you commit. One image proves one image. Yours might have a hard edge where mine had fabric, and that changes everything.

How I tested this

One illustration of a director's chair, generated for this project with GPT Image 2. Same picture into Meshy and into SupaVoxel. No text prompt on either side. One run each.

Meshy ran its Image to 3D workflow at High Detail, Ultra 2K, texture on, multi-view off. The other side ran a full generation at 5 steps, guidance 5.5, background removal on, octree resolution 256. Matching option names don't make two tools equivalent — that's just what was set.

Every measured number above was read straight out of the two downloaded GLB files after checking their hashes. Nothing came off a marketing page.

Here is every number on this page that is arithmetic rather than measurement, with the assumption written next to it, because a derived figure without its assumption is just a rumour:

Download seconds — file bytes × 8 ÷ bandwidth, at a clean, steady 12 Mbps and 100 Mbps. No handshake, no decode, no cache, no retries. Gives 10.17 seconds for Meshy and 6.83 for the other on mobile, 1.22 and 0.82 on desktop.
Hundred-prop storage — this one file × 100, decimal bytes. Gives about 1.53 GB for Meshy and 1.02 GB for the other. It is a capacity estimate, not a hundred real generations.
Hundred-prop credits — this one run's credit line × 100, assuming every run costs the same and nothing fails or retries. Gives 3,500 on one plan and 300 on the other, in two different units that do not convert.
Geometry memory — (vertices × 32 bytes) + (triangles × 3 × 4 bytes), an illustrative layout of position, normal and UV with 32-bit indices. Gives about 7.7 MB for Meshy and 45.3 MB for the other. Not real VRAM: it excludes textures, mipmaps and load peaks.
Bytes per triangle — file size ÷ triangle count. Gives 60.0 for Meshy and 6.8 for the other. Both files embed 3 textures, so this is not pure geometry.

The required-extension comparison is measured — it's read from each file's declared list. The consequence of that comparison, the importer scenario above, is inference. No importer was tested.

Failure counts and retry counts were not captured in this test, and neither were either product's published claims. I don't know those numbers, and I'm not going to imply that I do.

The elapsed times — Meshy's 245.796 seconds and the other's 274.886 — come from each tool's own job record, start to finish, download excluded. Each tool clocks its own window with its own stages inside it, so that pair is an observation from one run, not a same-conditions stopwatch.

All renders used the same offline viewer, resolution, lighting and camera numbers on both sides: front at yaw 0, three-quarters at 35, side at 90, back at 180, plus a top view and mesh and wireframe close-ups. Each file has its own built-in orientation, so matched numbers don't guarantee matched angles.

Free Landing Page Templates in 2026: 9 Sources I Checked

Selin Vidal — Wed, 07 Oct 2026 03:32:33 +0000

Most lists of free landing page templates were written years ago, and the problem is not only that the screenshots look old. Half the repos have gone quiet, some pin a CSS framework two major versions behind, and a few have licence terms that people skip right past. I build landing pages for small product teams, and I start almost every job from a template. So this week (6 October 2026) I went back through the sources I actually use. For each one I checked the repo, the licence and the date of the last push before writing it down.

When none of them fits the brief, which happens on roughly one project in five, I describe the page to Begin and it writes it as an ordinary Next.js/React/Tailwind project. More on that at the end. Templates first.

How I judged each template

I only had four questions:

Is anyone still committing? I looked at the last push date on GitHub. Anything quiet for more than about two years gets a warning, not a ban. A static HTML page doesn't rot the way a Next.js app does.
What does the licence actually allow? "Free" covers everything from MIT to "free, but credit me in the footer" to "free, but don't redistribute".
What stack is it on, and which version? A template on Tailwind 2 or Next 14 is still usable, but you're inheriting an upgrade.
How fast can I delete what I don't need? A landing page template usually ships a blog, five page variants and a pricing table nobody asked for.

The comparison table

Data checked on 2026-10-06, taken from each repo's GitHub metadata, README and package.json.

Template	Stack (from package.json / source)	Licence	Last push
AstroWind (`arthelokyo/astrowind`)	Astro 7, Tailwind CSS v4	MIT	2026-09-12
Launch UI (`launch-ui/launch-ui`)	Next.js 16, shadcn/ui, Tailwind 4.3	MIT (some sections are Pro-only)	2026-09-04
Bigspring Light (`themefisher/bigspring-light-astro`)	Astro 7, Tailwind 4	MIT	2026-06-27
Next JS Landing Page Starter (`ixartz/...`)	Next.js 14, Tailwind 3	MIT	2026-01-18
Cruip Open (`cruip/open-react-template`)	Next.js 15, Tailwind 4	GPL + "don't redistribute" terms	2025-12-12
Cruip Simple Light (`cruip/tailwind-landing-page-template`)	Next.js 15, Tailwind 4	GPL + "don't redistribute" terms	2025-12-12
shadcn Landing Page (`leoMirandaa/shadcn-landing-page`)	Vite 5, React 18, Tailwind 3	MIT	2024-10-09
Start Bootstrap Landing Page	Bootstrap 5.2.3, Pug + SCSS build	MIT	2024-07-08
Tailwind Toolbox Landing Page	One `index.html`, Tailwind 2.2.19 via CDN	MIT	2024-04-25
HTML5 UP (site, not a repo)	Plain HTML + CSS	CC BY 3.0 (attribution required)	no public dates

The landing page templates, one by one

AstroWind: my default for content-heavy launches

AstroWind is the one I reach for when the "landing page" is going to grow a blog, a changelog and docs within a month. Its README lists 30+ typed page-section widgets (heroes, features, bento, pricing with a comparison table, FAQ accordion, testimonials, newsletter), and the whole site is configured from src/config.yaml. It's the most actively maintained repo here, with the last push in September 2026. The code example below uses it. The source is on GitHub.

One thing to know: the README says it needs Node.js 22.22.3 or newer (there's an .nvmrc), so check that before you blame the template for a broken install.

Launch UI: if the client is already on shadcn/ui

Launch UI is less a single template and more a kit of landing sections (navbar, hero, items, logos, FAQ, stats, CTA, footer) built on Next.js 16, shadcn/ui and Tailwind 4. It's handy when the product app already uses shadcn, because the marketing page then shares the same design tokens. Bento grids, testimonials, carousels and tabs are in the paid Pro version, so plan your sections around what's in the free repo. If you're still on Tailwind 3, the README says a separate tailwind-3 branch is maintained.

Bigspring Light: Astro, marketing-shaped

Themefisher's Bigspring is an Astro 7 + Tailwind 4 theme pitched at SaaS and marketing sites. It has fewer stars than AstroWind, but it got a push in June 2026, and its package.json already includes a Cloudflare Workers deploy script (deploy:cf-workers). Pick it if you want Astro without AstroWind's look. AstroWind's README calls it the most-starred Astro theme four years running, so visitors may have seen its default layout before.

ixartz Next JS Landing Page Starter

This one is a clean, single-page Next.js + TypeScript starter with ESLint, Prettier and Husky already set up. The repo was pushed in January 2026, but the dependencies are still Next 14 and Tailwind 3. That's fine for a page that won't change much. For a long-lived site I'd budget an afternoon for the upgrade before the client sees it.

Cruip Open and Simple Light

The 2020 dev.to list that still ranks for this keyword was written by one of Cruip's founders, and Cruip has kept these two free templates current. Both moved to Next.js 15 and Tailwind v4 in 2025. They look polished, and Open has a dark look that works well for developer tools.

Read the licence before you fork them, though. GitHub's licence detector shows nothing for either repo. The README says GPL and then adds: use it for personal and commercial projects, but don't republish, redistribute or resell the template. Building a client's site is fine. Turning it into your own template pack is not.

shadcn Landing Page (Vite)

This is a nice single-page React + shadcn layout. It's a plain Vite SPA, though, not Next.js, so it renders client-side by default. For a landing page that needs to rank, I either prerender it or move the sections into an SSR framework. The last push was October 2024, so treat it as a parts bin.

Start Bootstrap Landing Page

It's old-school and still useful. If the client's team knows Bootstrap and not Tailwind, this is the least friction. Per the README, you can just edit the files in dist/ and open index.html. The full build (npm start) compiles Pug and SCSS from src/. Bootstrap is pinned at 5.2.3, and the repo hasn't been pushed since mid-2024.

Tailwind Toolbox Landing Page

The entire template is one index.html that pulls Tailwind 2.2.19 from a CDN. I use it for throwaway "is anyone interested?" pages where a build step is overkill. Don't use it for anything you'll maintain. The CDN build of Tailwind 2 ships the whole framework, and moving to v4 means rewriting classes.

HTML5 UP

These are plain HTML/CSS templates with nothing to install, and the site is still up and serving downloads. The licence is Creative Commons Attribution 3.0. You can use them commercially and change them however you like, but you have to credit HTML5 UP. The author sells attribution-free versions separately. There are no dates on the site, so I can't tell you how recently any one template was touched.

Stripping a template down and shipping it

Every time I start from a template I do the same three things. I delete the routes I don't need, set the metadata, and ship the static output. Here's that for AstroWind. The commands and config keys come straight from its README.

# 1. Scaffold from the template (name the folder my-landing when prompted)
npm create astro@latest -- --template arthelokyo/astrowind
cd my-landing
npm install

# 2. Turn off the blog if this is a single landing page
#    (edit src/config.yaml, see the YAML below)

# 3. List the widgets the homepage imports, then remove the sections you
#    don't need from src/pages/index.astro (BlogHighlightedPosts goes
#    first if the blog is off)
grep -ho "widgets/[A-Za-z]*" src/pages/index.astro | sort -u

# 4. Build and check locally
npm run check
npm run build      # static output goes to ./dist/
npm run preview

# 5. Ship ./dist to any static host, e.g. your own server
rsync -avz --delete dist/ deploy@your-server:/var/www/my-landing/

The relevant part of src/config.yaml:

site:
  name: 'Acme'
  site: 'https://acme.example'
  base: '/'

metadata:
  title:
    default: 'Acme'
    template: '%s — Acme'
  description: 'One sentence that says what Acme does and for whom.'

apps:
  blog:
    isEnabled: false   # single landing page, no blog routes

ui:
  theme: 'light:only'

The same approach works for the Next.js templates. Delete unused routes under app/, and if there's no server code, add output: 'export' to the Next config so next build writes a static out/ folder you can host anywhere.

Which one I'd pick

Developer tool or OSS project, dark look: Cruip Open, as long as you're fine with its redistribution terms.
SaaS that will grow a blog and docs: AstroWind.
Product app already on shadcn/ui: Launch UI.
Team that only knows Bootstrap: Start Bootstrap Landing Page.
A validation page you'll delete in two weeks: Tailwind Toolbox or HTML5 UP.

FAQ

Are free landing page templates OK for commercial use?
Usually, but check each licence. MIT ones (AstroWind, Launch UI's free tier, Start Bootstrap) let you do almost anything. HTML5 UP requires attribution. Cruip allows commercial client work but forbids redistributing the template itself.

What's the best free landing page template for SEO?
Pick one that renders HTML on the server or at build time: Astro-based templates or Next.js with static export. A client-only Vite SPA like the shadcn landing page needs prerendering before search engines see your content reliably.

Is there a good HTML landing page template without a build step?
Yes. HTML5 UP and the Tailwind Toolbox page are both a folder you open in a browser. Start Bootstrap's dist/ folder works the same way if you skip its build.

How do I know if a template is still maintained?
Look at the repo's last push date, not its star count, and open package.json to see which framework major versions it pins. A recent push with old dependencies is a warning too.

When no template fits

Templates are about 80% of my landing page work. The other 20% is when the client has a very specific layout in mind and adapting a template means rewriting most of it. In those cases I describe the page to Begin, which builds it as a Next.js, React and Tailwind project I can keep editing in code, with hosting on my own domain. Then I strip and tune it the same way as everything above. Know a maintained free template I missed? Leave it in the comments and I'll check it.