Platform Comparison

Foundry vs Roll20 Animated Asset Workflow

Compare how the same transparent animated character moves through Folosa delivery, Foundry VTT packaging and Bridge import, or direct Roll20 WebM upload.

Updated 2026-08-26Platform Comparison
Shadow knight artwork used to compare Foundry and Roll20 token workflows
The character can remain consistent across platforms while packaging and import steps change.

Practical answer

Foundry VTT and Roll20 can both use animated WebM characters, but they organize and import those assets differently. Folosa asks for one target per task so the delivery can match the platform instead of presenting a confusing universal bundle.

What stays the same

Both workflows begin with one Folosa account and one active input mode: Build, Prompt, or Upload. The character still needs a readable source or brief, one coherent motion idea, clean transparency, controlled framing, and a matching static fallback.

The generation quality choices also have the same intent. Standard VTT is the normal live-play option, while HD Pro and 4K Master serve larger display, detailed review, archive, or creator delivery. Choosing a platform does not change the need to test the final token in a real scene.

Where Foundry adds structure

Foundry users can download a system-agnostic module ZIP containing module.json, transparent token assets, static fallbacks, README, notices, and import guidance. Manual users place the files under Foundry Data and assign the WebM to a Prototype Token.

Folosa Bridge adds an account-connected path inside Foundry. A GM approves a short-lived device code, creates a task or selects compatible completed history, and lets Bridge verify the files before creating an Actor with a static portrait and animated Prototype Token. Actor data is created against the active system rather than hardcoded into a generic media archive.

Where Roll20 stays direct

Roll20 does not use the Foundry module manifest or module folder structure. Download the Roll20-targeted WebM, upload it through the supported asset workflow, place it on a test page, assign the intended grid size, and verify playback in the players' browsers.

The static file remains useful for portraits, previews, lower-power scenes, and backup. Keep the original Folosa download outside the campaign so the asset can be restored or used elsewhere without another generation.

Compare the delivery paths

DecisionFoundry VTTRoll20
Animated play fileTransparent WebMTransparent WebM
Static companionWebP/PNG portrait and fallbackWebP/PNG preview and fallback
PackagingModule ZIP with manifest and notesDirect platform-friendly files
AutomationBridge can verify and create an ActorManual asset upload and placement
System dataCreated in the active system by BridgeManaged in the Roll20 game

Choose one target without losing reuse

Select Foundry when you want package structure, manual Foundry installation, or Bridge-based creation and Actor import. Select Roll20 when the immediate destination is a Roll20 game and direct WebM upload is the useful handoff.

You can preserve the same character identity across both platforms by keeping the completed source assets and using target-specific packaging. There is no “All” platform option in the Forge, and ProRes is not a platform target. Creator ProRes 4444 is an optional editing export from eligible completed HD or 4K tasks.

FAQ

Do Foundry and Roll20 need different character art?

No. The same source concept can be used, but the selected task target controls packaging and import guidance.

Can Roll20 use the Foundry module ZIP?

The useful asset inside it may be a WebM, but Roll20 does not use Foundry's module.json or module installation structure. Use the Roll20 delivery for a direct workflow.

Is Folosa Bridge required for Foundry?

No. Bridge automates account connection, task tracking, verification, and Actor creation. The Foundry ZIP also supports a deliberate manual workflow.