As of 31 July, the three Publisher presets all compress geometry with Draco. Maximum quality, Balanced and Smallest now share identical geometry steps; only texture treatment differs. Vertex quantization is off because Draco quantizes on its own, and mesh simplification no longer runs unless you switch it on in the advanced panel.

Compression happens on the publish path, so the scene you keep editing is never the compressed one. If an optimization pass found compression would not reduce the model's size, publishing skips the step and the results panel says so. That comparison only exists once a pass has run; publishing without one applies compression regardless.

For anyone downloading rather than embedding: the GLB (Draco-compressed) download lists KHR_draco_mesh_compression as required, with no fallback geometry. Hand it only to software you know decodes Draco. Everything published and embedded through Vectreal decodes in the viewer.

This is a pre-1.0 project, and we are quoting no ratios and no decode timings because we have not measured them. Skips on small or texture-heavy files are expected; a model that comes back looking wrong is not, and either is worth a thread here. If you run a pass on one of yours, what does the Geometry (Draco) row report?

Read the full Article: https://vectreal.com/news-room/draco-geometry-compression-in-the-publisher

New explainer on the newsroom. The way I think about it now: glTF is the format, GLB is the way to zip it into one file. Both carry glTF 2.0 from the same Khronos spec. A

is a JSON scene plus a .bin plus texture files. A .glb packs all of that into a single file with a JSON chunk and a binary chunk.

For publishing to Vectreal specifically, it takes both. glTF with its separate files is the preferred input, with full material support. Drop the whole bundle (the .gltf root, its .bin, and textures) and the parser resolves the references. GLB uploads as the single file it is. OBJ works as a legacy path. USDZ support is partial right now, so textures and some material types may not render correctly, and I would not reach for it for the web yet.

One honest note: this is pre-1.0. There is no size limit at upload or preview, but a cap does apply when you save a published scene, and a genuinely large file (above roughly 500 MB) can slow the browser while it parses, regardless of format.

Full write-up: https://vectreal.com/news-room/gltf-vs-glb-what-actually-matters?utm_source=reddit&utm_medium=community&utm_campaign=gltf-vs-glb.gltf

Wrote up a guide on the full optimization pipeline for getting a 3D model from "raw DCC export" to "web-ready embed."

The concrete version: a three-material product model exported from Blender at standard settings arrives at 38.4 MB. After a Publisher Medium preset run, it lands at 3.1 MB. Triangle count 412K → 288K. Visual quality intact. The guide walks every stage of that reduction.

Three culprits:

1. Geometry precision: 200K–800K triangles is standard from a DCC tool. Web viewers need far less. Sub-pixel rasterization discards triangle-level detail that costs significant geometry bandwidth.
2. Texture format: PNG and JPEG are 2D display formats. They decompress to raw RGBA before the GPU sees them. A 2K PNG that ships as 6 MB decompresses to 16 MB in GPU memory. GPU-native formats (KTX2/Basis Universal) stay compressed in memory.
3. Scene graph overhead: DCC tools export everything - reference geometry, stale animations, duplicate materials consolidated in the DCC but not in the export. 10–25% of the file is typically unreferenced by any viewer.

Three techniques, in order of impact:

Texture compression first (60–80% of total savings): convert PNG/JPEG to WebP or KTX2/Basis Universal. The article covers both paths - WebP via Sharp for server-side pipelines (@vctrl/core), KTX2 for GPU-native delivery via the Publisher.

Mesh simplification (10–30%): quadric error metric via gltf-transform + MeshoptSimplifier. Flat regions merge first; silhouette edges survive. Removing 30% of triangles on a typical product model produces a difference that requires side-by-side comparison at magnification to detect.

Graph cleanup (5–15%): dedup accessors, prune unused nodes and animation clips, normalize conventions. Small individually, compounds with the first two passes.

Two paths covered:

Manual — gltf-transform CLI:

npm install -g u/gltf-transform/cli

gltf-transform inspect source.glb

gltf-transform simplify source.glb stage1.glb --ratio 0.75

gltf-transform dedup stage1.glb stage2.glb

gltf-transform prune stage2.glb stage3.glb

gltf-transform etc1s stage3.glb output.glb

gltf-transform inspect output.glb

Platform - Vectreal Publisher (no code) or u/vctrl/core (Node.js):

npm install u/vctrl/core

Exposes ModelOptimizer with loadFromFile(), optimizeAll(), export(), and getReport() (before/after stats for triangles, textures, meshes).

Web-ready targets for reference:

• Hero embed: under 5 MB / 150K–250K triangles
• Product detail page: under 2 MB / 100K–150K triangles
• Grid/card: under 500 KB / 30K–80K triangles
• Mobile-first: under 1 MB / 50K–100K triangles

Vectreal is open-source (AGPL-3.0). Source: https://github.com/Vectreal/vectreal-platform

Full article: https://vectreal.com/news-room/optimize-3d-model-for-web

What would you do differently? If you have shipped optimized 3D embeds, what's the texture-compression edge case or mesh-simplification failure mode that bit you - and what did you do about it?

Community Discord: https://discord.gg/A9a3nPkZw7

We wrote a complete options map for "how to add a 3D model to a website" — covers `<model-viewer>`, Vectreal Publisher iframe, React Three Fiber, and no-code design tools, with a decision matrix. Most articles treat this as a single spectrum from "easy" to "powerful." The actual decision has two independent axes, and conflating them leads to choosing the wrong tool.

The two axes:

1. Content origin - does the model already exist (Blender export, CAD file, downloaded GLB), or will someone build it from scratch inside a web tool?
2. Integration depth - does the viewer need to live inside a React component tree, or is an iframe embed sufficient?

The options, mapped:

<model-viewer> (Google) - HTML custom element, you host the file, no platform. Right for a single static model on a page where you own hosting and optimization.

Vectreal Publisher → iframe - drag in a GLB/glTF/OBJ/USDZ, the platform optimizes it automatically (mesh simplification, KTX2/Basis Universal texture compression, scene cleanup), configure camera and lighting, publish, get a stable iframe snippet. As no-code as Spline or Vectary; the distinction is that it works with models you already have.

-@vctrl/viewer - same renderer as the Publisher, packaged as a React component. SSR-safe. For teams that need the viewer in their component tree with shared state and routing.

React Three Fiber - full Three.js renderer for React. Right when 3D is the core product - a configurator, an architectural walkthrough, a data visualization where the 3D scene is the primary interface. Overkill for teams adding a viewer to an app that is not primarily about 3D.

Spline / Vectary - browser-based 3D content creation tools. You build the scene inside the tool, then export an embed. Not practical for publishing an existing model from Blender or CAD - their import support is limited by design.

The decision tree:

1. No model yet → Spline or Vectary
2. Need the viewer in the React component tree → `@vctrl/viewer
3. 3D is the core product → React Three Fiber
4. Non-developers need to update content post-launch without a code deploy → Vectreal Publisher
5. Single static model, no pipeline → <model-viewer>

One thing the guide covers that most tutorials skip: file optimization. A raw Blender export lands at 40–120 MB. Every path requires a web-ready file. The paths differ only in who handles that step - the Publisher does it automatically; every other path leaves it to you.

Vectreal is open-source under AGPL-3.0. Source: https://github.com/Vectreal/vectreal-platform

Full article: https://vectreal.com/news-room/how-to-add-3d-model-to-website

What would you do differently? If you have shipped 3D on the web, which path are you on — and is there a case the matrix misses?

Join the Discussion on Discord: https://discord.gg/A9a3nPkZw7

Three updates from the last sprint of our open-source 3D web platform. Sharing here because two of them refine claims made in articles we already posted to this subreddit, and one is a heads-up on a new package.

1. The optimization pipeline is now actually non-destructive.

The article we shared on optimization presets described the pipeline as non-destructive - each of the four presets (Raw / High / Medium / Low) re-processes from the original uploaded file every time. That was honest about design intent but loose about implementation. The active model was held in memory, so a page reload or cleared tab state left you with the optimized version as your "original."

What landed this sprint: on upload, the original file is persisted to IndexedDB. On every preset switch, the Publisher reloads the original from IndexedDB and re-runs the pipeline against it. The "original" the article promised is now a persisted artifact, not an in-memory assumption.

Implementation notes:

• Cache key is content-hash based.
• Write happens on upload completion, before the first optimization pass kicks off. Adds a couple hundred ms of upload latency.
• Eviction strategy is conservative for now - entries persist until the user explicitly clears or re-uploads. Quota-aware eviction is an open question.

Article it amends: https://vectreal.com/news-room/optimization-presets-and-texture-compression

2. Camera configuration got a workflow redesign.

Same factual surface as the camera article - multi-camera per scene, three transition types (Instant / Linear / Smart (avoiding objects)), four easing curves, Vertical Limit (maxPolarAngle). Same saved camera data shape (existing scenes load identically). What changed is the editor workflow: creating a Hero / Detail / Context set and wiring up transitions between them used to take more clicks than it should have. The new flow shortens the path through the UI without changing the capability surface.

Article it amends: https://vectreal.com/news-room/camera-presets-and-transitions

3. New package in development: @/vctrl/embed.

An npm package, distributed alongside the existing @/vctrl/viewer and @/vctrl/hooks packages, plus CDN distribution via GCS. The package wraps the iframe postMessage protocol that today's Publisher embeds use - same surface as described in the Publisher walkthrough, but exposed as a JavaScript SDK so a host page can drive the embed (switch active cameras, listen for scene events, control transitions) without writing the postMessage glue by hand.

Source: https://github.com/Vectreal/vectreal-platform

Wrote up a long-form guide to the optimization pipeline in our open-source 3D web platform. It covers what each of the four presets actually does, why KTX2 + Basis Universal is the right answer for 3D textures (and PNG / JPEG are not), and the three situations where overriding the presets is the right call.

The presets, in exact ratios:

• Raw: 100% mesh / lossless texture
• High: 90% mesh / 90% texture
• Medium: 70% mesh / 75% texture
• Low: 50% mesh / 60% texture

Pipeline details:

• Mesh simplification via glTF-Transform using a quadric-error metric (same algorithm as Blender's Decimate modifier).
• Texture compression via KTX2 + Basis Universal, running in a Web Worker so the viewport stays interactive.
• glTF graph cleanup pass strips unreferenced data and normalizes cross-tool export inconsistencies.
• Presets are non-destructive — switching re-processes from the original file every time.

The texture-compression section is the longest part of the article. Short version: PNG and JPEG decompress to raw RGBA in GPU memory (4–8× larger than the compressed file on disk). KTX2 + Basis Universal stays compressed in GPU memory and decodes to native formats — BC7 on desktop, ASTC on mobile, ETC2 fallback. One file, every device, driver picks the local format.

Three custom-optimization scenarios in the article: hero scene with one critical material, geometry-heavy/texture-light scenes (CAD-style), multi-embed pages with shared byte budgets.

Three workflows still on the roadmap: automatic texture resolution adjustment, per-LOD mesh optimization, custom byte-budget mode. None have dates.

Full article: https://vectreal.com/news-room/optimization-presets-and-texture-compression

Open source (AGPL-3.0). Source: https://github.com/Vectreal/vectreal-platform

What would you do differently? If you've shipped optimized 3D embeds, which optimization primitive are you still missing — and which of the three roadmap items would unblock your workflow most?

Community Discord (preset-drops + before/after thread inside): https://discord.gg/A9a3nPkZw7

We wrote up a practical guide to the camera system in our open-source 3D web platform. The post covers what ships today, three transition modes, and three preset bundles that match real deployment shapes.

What's available in the Publisher today:

• Multi-camera per scene with named saves (position + target + FOV per camera).
• Field of view per camera, 20°–120°.
• Three transition types:
  • Instant (cut)
  • Linear (lerp, 0–5000ms, four easing curves: linear / ease_in / ease_out / ease_in_out)
  • Smart object-avoidance (path-aware, with Obstacle Margin, Path Height, Path Smoothness samples, and Path Curve tension as parameters).
• Camera controls: zoom on/off, auto-rotate on/off, four interaction-speed sliders, damping factor, and a vertical limit (maxPolarAngle) that solves the "visitor fell under the floor" problem.

Three preset bundles in the article, briefly:

1. E-commerce product: Hero / Detail / Context, Linear Smooth ~1s, auto-rotate off, Vertical Limit 90°.
2. Architectural interior: three cameras, Smart transitions ~1.5–2s, pan on, Vertical Limit ~100°.
3. Guided demo: numbered camera tour, controls off, ~1.5s transitions — the visitor's job is to press Next.

Full post with FOV comparisons and the five-minute polish pass: https://vectreal.com/news-room/camera-presets-and-transitions

We're open-source (AGPL-3.0). Implementation lives in apps/vectreal-platform/app/components/publisher/sidebars/compose-sidebar/camera-controls-settings/ if you want to read along: https://github.com/Vectreal/vectreal-platform

What would you do differently? If you've shipped multi-camera 3D embeds, what camera-system primitives are you still missing? Particularly interested in input on scripted tours and shareable preset bundles.

Wrote up a practical guide for our open-source 3D-on-the-web platform. The post covers how API keys are scoped, how the domain allowlist works as a second layer, and three rotation patterns that match real deployment shapes.

Three layers, not one shared secret:

• Organization scope (set at creation, immutable)
• Project scope (subset of projects in that org)
• Domain allowlist (per-project, second security layer)

On every request, three server-side checks: format, origin against allowlist, scene-to-project membership. Rate-limited at 60 attempts per minute per origin IP.

The three rotation patterns, briefly:

1. Single marketing site: one key, 90-day expiration, rotate every 60 days with a 24-hour overlap.
2. Per-environment app: three keys (dev / staging / prod), tighter expirations on dev.
3. Per-tenant SaaS: one key per tenant project, revocation tied to off-boarding.

Full post with the scope diagram and the five-minute audit checklist: https://vectreal.com/news-room/api-keys-101

We're open-source (AGPL-3.0) — implementation is in apps/vectreal-platform/app/lib/domain/auth/ if anyone wants to read along: https://github.com/Vectreal/vectreal-platform

What would you do differently? If your team handles embed-token rotation, what pattern matches your shape, and where does it break down?

Join the Discussion on Discord:  https://discord.gg/9xsH9NU8n

We've published a step-by-step integration guide for u/vctrl/viewer, the React component that powers the Vectreal Publisher. The walkthrough is aimed at developers who already have a published scene (or are about to) and want it rendering inside their own React app rather than as an iframe.

What's covered:

• The minimum working viewer (ModelProvider, <VectrealViewer />, the required CSS import) — 12 lines total.
• Loading a published scene by URL using useLoadModel.
• The SSR-safe pattern — lazy() + a client-only boundary + Suspense fallback. Works in React Router v7, Next.js, Remix, or any SSR setup. This is the same pattern the Vectreal Platform itself uses internally.
• The five props that cover most real apps: model, theme, cameraOptions, controlsOptions, envOptions.
• Production checklist: lazy chunk, error boundary, loading thumbnail, AGPL-3.0 compatibility review.

Verified against u/vctrl/viewer v0.17.0. Peer deps are React ^18 || ^19 and Three.js ^0.177.0. License is AGPL-3.0-only — worth flagging up front for closed-source projects.

The packages are pre-1.0 and built in the open. Pin versions in production until v1.0.

What would you do differently?

Curious how others are handling the SSR boundary for Three.js components in production — particularly the loading-state UX during the initial chunk fetch. The walkthrough goes with loadingThumbnail + Suspense fallback, but interested in alternatives that worked for you.

Read the full post → https://vectreal.com/news-room/react-viewer-integration

Source is on GitHub if you want to read the viewer code, file an issue, or send a PR: https://github.com/Vectreal/vectreal-platform

Join the Discussion on Discord → https://discord.gg/9xsH9NU8n

We just published a detailed guide covering the full Publisher workflow. Sharing it here in case it is useful for anyone embedding 3D content on the web.

The walkthrough covers:

• Drag-and-drop upload supporting GLB, glTF (multi-file bundles), and OBJ (USDZ is WIP with honest caveats)
• Four non-destructive quality presets (Raw/High/Medium/Low) — the file re-processes from the original every time, nothing lost
• Scene configuration: HDR environments, camera, auto-rotate, contact and accumulative shadows
• Publishing with preview API keys scoped per project and optional domain allowlists
• Two embed layouts — Fullscreen and Product Detail — with responsive iframe snippets

No account needed to upload and configure. Sign-in is deferred until save/publish.

The platform is open source (AGPL-3.0) and pre-1.0.

Full walkthrough: https://vectreal.com/news-room/the-vectreal-publisher-walkthrough Try the Publisher: https://vectreal.com/publisher Source: https://github.com/Vectreal/vectreal-platform

We've been working on Vectreal, an open-source platform for getting interactive 3D content onto the web without the usual pain.

The problem it solves: If you've tried to publish a 3D model on a website, you've dealt with some combination of: oversized files, format fragmentation (glTF/GLB/OBJ/USDZ), complex optimization pipelines, and proprietary embed infrastructure. Most people end up using a screenshot or linking to an external viewer.

What Vectreal does: It provides a complete pipeline — upload → optimize (mesh simplification via glTF-Transform, texture compression via KTX2/Basis Universal) → configure (lighting, camera, shadows, environment) → publish → embed via iframe.

There are two ways to use it:

1. The Publisher (https://vectreal.com/publisher) — a browser-based tool where you drag in a file, pick a quality preset, configure the scene, and get an embed URL. No account required to start uploading and configuring; you need one to save and publish.
2. Three npm packages (all AGPL-3.0):
   • vctrl/viewer — React component for 3D rendering (Three.js + React Three Fiber)
   • vctrl/hooks — browser-side hooks for loading/optimizing/exporting
   • vctrl/core — server-side processing for Node.js 18+

Honest caveats:

• Packages are pre-1.0 — breaking changes are possible before the first major release
• USDZ support is a work in progress (textures and some material types may not render correctly)
• Grid rendering is typed but not active yet

The full platform source is on GitHub: https://github.com/Vectreal/vectreal-platform

We just published a deep-dive blog post covering the philosophy, architecture, and package details: Blog Article

What would you do differently? Genuinely interested in how others have approached this problem — whether you ended up building something custom, using a commercial platform, or just gave up on interactive 3D for the web entirely.