Inventory and ability icon sets
Generate a named manifest of weapons, potions, skills, status effects, and rewards while keeping perspective, border treatment, and palette consistent.
Coming soon
Bulk 2D game asset generation — in development
We're scoping a way to batch-generate icons, sprites, and tileset pieces from one style prompt, so a two-person team doesn't have to hand-draw two hundred inventory icons. It isn't shipped yet — here's the plan, and what you can already do in 3D.
the problem
Why 2D asset volume breaks small teams
One icon takes ten minutes, a UI needs two hundred
Inventory icons, ability icons, achievement badges, tile variants — the volume of 2D assets a real game needs rarely matches the time a small team has to draw them one by one.
Style consistency breaks down at scale
Commissioning or generating dozens of individual assets from different sources almost always drifts in palette, line weight, or perspective by the twentieth item.
Sprite sheets and tilesets need structure, not just images
A usable game asset isn't a single picture — it's a sheet with consistent frame sizes, padding, and naming, ready to slice in an engine.
what we're building
The plan for bulk 2D generation
One style prompt, many outputs
Describe the visual style once — "hand-painted fantasy icon set, muted palette" — and generate a batch of items (a sword, a potion, a shield) that hold that style together.
Sheet-aware output
Planned output includes packed sprite sheets and tileset grids with consistent dimensions, not just a folder of loose PNGs you have to arrange by hand.
Built for the same audience as our 3D tools
Indie teams and game jammers who need coverage fast — the same problem bunpav already solves for 3D props, applied to 2D.
None of this is shipped software yet — treat it as a roadmap, not a feature list. If you'd rather generate assets bunpav already supports, its text-to-3D and image-to-3D tools handle bulk 3D prop and character generation today, including auto-rigged characters and low-poly output for mobile and VR.
planned use cases
The first production jobs this workflow is being scoped around
Tilesets and environment kits
Create connected floor, wall, edge, corner, prop, and terrain variants as an engine-ready grid instead of unrelated single images.
Game-jam sprite coverage
Build the minimum coherent art set for enemies, pickups, UI, and objectives before the jam clock forces placeholder art into the final submission.
These are roadmap use cases, not screenshots of shipped 2D software. The page intentionally avoids fabricated product imagery until the batch workflow exists.
pricing
Same credit model, once it ships
bunpav runs on credit packs with no subscription — today that's 9 to 89 dollars for 3D generation. Bulk 2D generation would use the same balance rather than a separate plan.
faq
Questions, answered
Is bulk 2D asset generation available now?
No — AI bulk 2D generation is in development, not a shipped feature. bunpav already ships free Sprite Sheet Lab and Sprite Animator for packing frames and previewing loops. The live AI product today generates 3D models from text or an image. This page describes the planned AI batch-2D direction and collects interest.
What would bulk 2D generation actually produce?
The plan is style-consistent batches of 2D game assets — icons, sprites, and tileset pieces — generated from one style description, output as organized sheets rather than one-off images.
Can I generate multiple 3D assets in bulk today?
Yes — bunpav's credit system already supports generating many 3D props or characters back to back for a prop library or a game jam batch; only the dedicated 2D sprite/tileset workflow is unbuilt.
How do I find out when 2D generation ships?
Join the waitlist below. bunpav is in private beta for the 3D tools now, and 2D asset generation would follow as a separate release once it's ready.
Why build 2D generation after 3D?
bunpav started with the harder reconstruction problem — text and photos into textured, riggable 3D meshes. Structured, style-consistent 2D batch generation is a related but distinct problem we're scoping next.
go deeper