Skip to content

How We Use Shale Ourselves

Seismiq built Shale to solve problems we were already facing in our own production work. We use it daily — not as a demo, but as the actual tool our team relies on to move creative work forward. Here are a few ways it fits into how we operate.


Before anything goes to a client, it goes through an internal review on Shale. Our artists push captures directly from Blender mid-production — not polished finals, just far enough along to get eyes on — and the rest of the team leaves notes spatially within the scene.

This catches problems early, in context. The note is on the geometry. There’s no ambiguity about what it refers to, and no back-and-forth trying to describe where something is.

When we’re ready to share with a client, they get the same navigable capture through a browser link — no software, no guided tour. They explore the space at their own pace, and their feedback comes back pinned to exactly where they meant it.


We produce our own marketing assets — renders, social imagery, promotional visuals — and we review them on Shale the same way we’d review any other deliverable. Upload the image, share a link internally, and anyone on the team can annotate directly on it: crop suggestions, copy placement, colour notes, whatever needs addressing.

It keeps feedback off Slack and out of email, and makes it easy to see at a glance what’s been resolved and what’s still open before anything goes out.


Before a project ships, we do a final QA pass on Shale. One person captures the scene, another reviews it as a fresh set of eyes — not in Blender, but through the browser viewer the way a client would actually experience it. This surfaces things you miss when you’re deep in the tool: lighting that reads fine in the viewport but looks flat in the capture, materials that tile awkwardly at certain node angles, navigation dead-ends.

Reviewing through Shale instead of the DCC mimics how the deliverable will be experienced, which makes the QA pass meaningfully more useful.


Once a project is signed off, the Shale capture becomes a record of what was approved and when. If a scope question comes up later — “wasn’t that wall supposed to be lighter?” — the approved version is there, navigable and annotated, not buried in someone’s Dropbox or lost in a Slack thread.

We use versioning to keep a clear history: draft, revised, approved. Each version is its own capture, so nothing gets overwritten and the approval trail is always intact.


Not everything needs a 3D capture. A lot of day-to-day content — reference images, screenshots, diagrams, rough layouts, work-in-progress visuals — just needs to get in front of someone with a clear way to respond. We use Shale for that too.

Upload the image, share the link, get annotated feedback back. It’s faster than assembling a presentation, cleaner than a Slack thread, and keeps everything in one place with the rest of the project’s review history rather than scattered across inboxes.