DEV Community: Mugen3D Dev

3D Gaussian Splatting vs. Meshes: Choosing a Representation for Real-Time Content

Mugen3D Dev — Fri, 30 Oct 2026 02:18:39 +0000

As real-time rendering and generative AI evolve, developers have more ways to represent visual content than traditional polygon meshes. One format attracting attention is 3D Gaussian Splatting (3DGS).

The interesting question is not whether 3DGS will replace meshes. It is where each representation fits in a production pipeline—and what trade-offs developers should consider.

Meshes and 3DGS represent scenes differently

A mesh describes a surface using vertices, edges, and polygons. This gives developers explicit geometry to work with. Meshes fit established workflows for UV mapping, material editing, collision, deformation, and skeletal animation.

3DGS represents a scene using many Gaussian primitives. Each splat has attributes such as position, color, opacity, and shape. Together, they can reproduce detailed appearance from different viewpoints, including visual features that are difficult to model as clean geometry.

That difference matters. A visually convincing representation is not automatically a production-ready game asset. A mesh provides explicit surfaces and topology; a 3DGS scene prioritizes appearance through a different representation.

Where 3DGS may be useful

3DGS is especially interesting for content with complex visual detail, such as hair, fur, foliage, and textured real-world environments. In reconstruction workflows, it can preserve the appearance of a captured scene without requiring every detail to be rebuilt as conventional geometry.

This could make it useful for certain environment elements, visual references, or scenes where appearance matters more than extensive deformation. But the right choice depends on the requirements of the project.

For example, a character that needs skeletal animation, precise collision, and frequent material changes may fit more naturally into a mesh-based pipeline. A captured environment that is mostly viewed from a limited range of angles may be a candidate for a splat-based representation. These are possibilities to evaluate, not universal rules.

Questions to ask before choosing a representation

When evaluating 3DGS or meshes for a real-time project, consider:

Does the asset need to deform? Characters and gameplay objects may need rigging, skinning, and predictable geometry.

Does it need collision or physics? Visual representation and collision representation may need to be handled separately.

How will the camera move? Viewpoint range can affect how a reconstructed asset looks.

How editable does it need to be? Consider whether artists need to change topology, materials, or individual scene elements.

What are the runtime constraints? Performance depends on the implementation, hardware, scene size, and rendering pipeline—not just the representation format.

Can the asset be reused elsewhere? A production pipeline may need exports for multiple engines, tools, or output formats.

A hybrid pipeline may be worth exploring

Meshes and 3DGS do not have to be treated as competing formats. A project could use meshes for characters, collision, and gameplay-driven objects, while using splats for selected environments or captured visual detail.

The challenge is integration. Teams need to consider import and export, runtime performance, lighting, interaction, level of detail, and how artists will inspect and edit the result. Those requirements will vary between engines and projects, so practical tests matter more than broad claims about one format being universally better.

3DGS makes a different point in the design space: it offers another way to represent detailed visual content. The useful question for game developers is where that representation solves a real production problem—and where the existing mesh workflow remains the better fit.

How are you evaluating 3DGS, meshes, or hybrid approaches in your own real-time projects? Which constraint has mattered most so far: editability, animation, collision, visual fidelity, or runtime performance?

References

Kerbl et al., “3D Gaussian Splatting for Real-Time Radiance Field Rendering,” SIGGRAPH 2023.

Mildenhall et al., “NeRF: Representing Scenes as Neural Radiance Fields for View Synthesis,” ECCV 2020.

This article was prepared with AI assistance and should be reviewed by the author for technical accuracy before publication.

From a Portrait to an Interactive TalkingHead: Persona, Knowledge, and Voice

Mugen3D Dev — Wed, 28 Oct 2026 06:15:22 +0000

I work on Mugen3D at SumeruAI. We have been exploring a workflow that turns a portrait into a character people can talk with through text or voice. This post walks through the creator flow and the pieces a developer needs to think about when building a product around it.

The character workflow

In TalkingHead Studio, the flow starts with a portrait and then adds the interaction layer:

Upload a portrait to define the character's appearance.
Write a persona with the character's background, tone, and conversational goal.
Add a knowledge document for topic-specific reference material.
Choose a voice.
Start a text or microphone conversation and review how the character responds.

The persona and knowledge document serve different purposes. The persona shapes how the character communicates; the document supplies reference material for what it can discuss. A history guide might use curated sources, while a product guide might use FAQs. In either case, the material should be organized and the answers should be tested. A document upload does not guarantee factual responses.

Voice and interaction design

Text is useful for quick prompts and review. Voice can make the character feel more conversational, but it adds practical questions: how long does a response take, how does the UI show that it is listening or speaking, and what happens when speech recognition or playback fails?

Voice, persona, and knowledge content should be tested together. The same answer can feel quite different depending on the voice and speaking animation. For a useful prototype, I would start with one clear role and a small set of reference material, then test whether people can understand what the character can and cannot do.

What the developer integration covers

There are two related parts: creating a TalkingHead asset from a photo, and embedding a rendered character in your own product. The Mugen3D API page describes photo-to-TalkingHead generation as an asynchronous job with a result callback. The public API docs are the source for the current request fields and job details.

For the browser runtime, the TalkingHead Web SDK repository includes a demo, a minimal integration example, avatar rendering helpers, local workers, and audio-driven facial animation. Its example flow is to get an access token, load a hosted avatar model, and pass a WAV file to the audio-driven facial animation helper. The SDK covers avatar rendering and facial drive; your application still needs its own conversation interface and any retrieval or product logic unless you choose a service that provides those pieces.

Keep API credentials on your server. For a longer-running generation task, keep the task ID, show processing, completed, and failed states, and preserve useful error details so the user can recover after refreshing the page. The repository's minimal example and developer guide show the current SDK calls.

Use cases and limits

A small team could prototype a language-practice partner, a history explainer, an interview coach, or an interactive story character. The useful product work is often in the surrounding flow: how users choose a character, what they can ask, how the app handles uncertainty, and when it hands off to a human or a static answer.

For fan experiences or memorial projects, use portraits, recordings, and other source material only when you have permission. Make the synthetic nature of the character clear, and respect the wishes and privacy of the people involved. Voice cloning needs particular care.

Try it and share feedback

I would be interested in feedback from developers building conversational characters: which part is hardest to get right in a first prototype—consistent persona, useful knowledge references, voice interaction, or integration?

More prototype screenshots

The Boundary Between Video and 3D Is Blurring: Atlas, Genie 3 and Reusable Assets

Mugen3D Dev — Wed, 21 Oct 2026 08:51:35 +0000

Disclosure: I am part of the Mugen3D team at Sumeru AI. This article compares product approaches, not benchmark results. AI assisted with adaptation and editing. Product specifications and availability below reflect the cited documentation as of September 2026.

On September 1, 2026, World Labs introduced Atlas. Earlier, Google DeepMind’s Genie 3 had already allowed users to enter worlds generated in real time by a model.

Taken together, these two developments suggest that the industry is beginning to ask a different question.

The focus is shifting from:

Can the video look more realistic?

to:

Can visual content become a world that users can enter, change, and reuse?

This also explains why video and 3D are increasingly being discussed together.

Video is good at presentation. 3D is good at preserving spatial structure and interaction.

Atlas starts from spatial intelligence. Genie 3 starts from real-time world generation. Mugen3D at Sumeru AI starts with reusable 3D assets.

The three approaches are related, but they operate at different product layers and solve different problems.

Genie 3: The model generates what comes next as the camera moves forward. Its focus is real-time exploration and world simulation.

Atlas: The model understands images, videos, camera positions, and spatial relationships before generating new views, videos, or 3D outputs. Its focus is spatial control and reconstruction.

Mugen3D: The system first turns people, objects, and environments into reusable 3D assets, then enables animation, dialogue, and interaction in real-time applications. Its focus is asset production and application deployment.

Video Is About More Than Image Quality

Before generative AI, video and 3D followed two very different production paths

3D meant high cost and a high technical barrier. Its strengths were free camera movement, real-time interaction, and asset reuse. It was mainly used in games, visual effects, film production, and industrial design.

Video was treated as the default format for realistic content. It was easier to create and distribute, but largely “one-time” content. Once rendered, it was difficult to change the camera, edit individual objects, or reuse the scene as an interactive environment.

Generative AI first disrupted the video industry.

Video-generation models can now produce highly realistic footage. However, several limitations remain:

long-term consistency is still difficult;
commercial generation length is often limited;
users have limited control over camera movement;
training and inference remain computationally expensive;
video content still cannot be interacted with in the same way as a real-time 3D environment.

The core problem is this:

Video models generate fixed visual sequences. They do not automatically generate living, editable, and reusable spaces.

If video itself becomes three-dimensional

If the long-term goal is to generate high-quality visual content that is:

not limited by video duration;
freely navigable;
highly detailed;
interactive in real time;

then there are two broad paths.

Starting from video generation

A video-first system needs to solve several difficult problems at the same time:

maintaining consistency under diffusion or transformer-based generation;
achieving high-quality, low-latency interaction;
allowing users to control the camera;
generating long-duration content;
compressing and transmitting the result under real-world network conditions.

Starting from 3D generation

A 3D-first system can avoid some of these problems because a 3D asset is a reusable representation.

It naturally provides:

better spatial consistency;
longer-duration content;
user-controlled camera movement;
asset reuse;
easier integration with real-time interaction.

It also introduces a different set of challenges:

the quality of generated 3D assets must approach the visual quality of video;
animation generation is more difficult;
AI-driven 3D motion and behavior are still evolving;
deployment requires careful handling of memory, compression, rendering, and interaction.

The key difference is that the 3D path may exchange some generation complexity for greater engineering predictability.

The video path must solve several independent problems at once. The 3D path concentrates more of its difficulty in asset quality, animation, and runtime deployment.

At present, three technical approaches are helping validate this direction.

Atlas: Bringing 3D spatial understanding into video generation

World Labs introduced Atlas as an omni world model for spatial intelligence.

According to the official description, Atlas operates natively on text, images, videos, and 3D data. It combines these inputs into a shared spatial context and uses that context to generate new views, videos, reconstructions, and simulations.

Atlas supports several important capabilities:

Taking one to six input images and generating video with manually designed camera paths, up to one minute at 1440p.
Reconstructing real-world scenes from one to dozens of input images and producing novel views as well as explicit 3D outputs.
Modeling space and time from input videos for applications such as visual effects and real-to-sim workflows.

Atlas also supports image generation and 360-degree panoramas.

Its main value is that it attempts to understand spatial relationships before generating the next image or video frame. It is not simply predicting pixels independently. The model uses information about camera position, geometry, depth, and the surrounding scene.

However, there is still an important distinction between spatially aware video generation and a fully interactive 3D runtime environment.

A camera-controlled video and an explicit 3D reconstruction are different output modes. In a video workflow, the timeline remains the primary structure. In a 3D application, the scene can be rendered repeatedly from different viewpoints while individual assets remain available for further editing or interaction.

Atlas significantly improves spatial control and reconstruction, but its product workflow should not automatically be treated as the same thing as a reusable 3D asset pipeline.

Genie 3: A generated world that responds to movement

Google DeepMind introduced Genie 3 as a general-purpose world model that can generate interactive environments.

According to Google DeepMind, Genie 3 can generate dynamic worlds from text prompts and allow users to navigate them in real time at 24 frames per second and 720p, with consistency maintained for a few minutes.

The breakthrough comes from the generation loop.

In a traditional video:

the video is generated first;
the user can only watch it afterward.

In Genie 3:

the user moves or changes direction;
the model predicts what should appear next;
the system generates the next part of the world;
the environment remains broadly consistent with the previous trajectory.

Genie 3 also supports promptable world events. Users can change weather conditions or introduce new objects and characters.

This means that the user’s movement becomes part of the generation process.

For robotics and embodied-agent research, this creates a new type of simulated environment. An agent can move through a generated world, test actions, and observe how the environment evolves.

However, the current limitations are also clear. Google DeepMind lists the following constraints:

the direct action space is still limited;
complex interactions between multiple independent agents remain difficult;
real-world locations cannot yet be reproduced with perfect geographic accuracy;
text rendering is not always reliable;
continuous interaction currently lasts only a few minutes.

From a product perspective, Genie 3 is best understood as a real-time generative world model.

It allows users to enter a generated environment, but it does not automatically provide a library of independent meshes, 3D Gaussian Splatting assets, animation rigs, or objects that can be exported directly into Unity or Unreal Engine.

That is a different problem from world generation.

Project Genie

In January 2026, Google introduced Project Genie, an experimental web prototype powered by Genie 3, Nano Banana Pro, and Gemini.

Project Genie allows users to create, explore, and remix interactive worlds using text, images, and other inputs.

However, Project Genie is not identical to the full Genie 3 research model.

Google’s current documentation lists several limitations:

each generation is limited to 60 seconds;
generated worlds may not always follow prompts, images, or real-world physics closely;
characters can be difficult to control;
some Genie 3 capabilities, including promptable world events, are not yet included in the prototype.

Genie 3 represents the research capability.

Project Genie represents the product experience currently available to a limited audience.

Mugen3D: Turning the world into reusable 3D assets

Product and public demos: Mugen3D.

Mugen3D follows a different path.

Instead of generating every frame during interaction, Mugen3D starts by creating a reusable 3D representation. Animation, dialogue, and interaction are then built around that representation.

The overall workflow can be summarized in three steps:

Generate 3D Gaussian Splatting assets from a single image.
Generate 3D environments from sparse images or videos.
Use AI-driven animation and real-time rendering to create interactive experiences.

The generated content is no longer limited by the duration of a video file. Once the 3D asset exists, it can be rendered repeatedly from different viewpoints and used in different application contexts.

Mugen3D’s current product direction includes 3DGS scenes, realistic characters and animals, stylized assets, and interactive AI avatars.

Our development work also covers AI-driven animation for 3D virtual humans, including facial expressions, micro-expressions, motion, dialogue, and real-time interaction.

At the same time, generated 3D assets should not be treated as automatically production-ready in every scenario.

Single-view reconstruction still has clear limitations:

unseen surfaces must be inferred;
small text and logos may be inconsistent;
reflective and transparent materials are difficult;
complex geometry may require manual review;
output quality depends heavily on the input image and the intended use case.

For this reason, Mugen3D should currently be evaluated as a fast 3D asset-production and visualization workflow. It is not a universal replacement for CAD or manual modeling.

The differences are mainly about cost, interaction, and application

Dimension	Atlas	Genie 3	Mugen3D
Main workflow	Spatial generation, camera-controlled video and reconstruction	Real-time interactive world generation	Reusable 3D asset generation and application integration
Outputs and reuse	Depends on the selected mode; includes explicit 3D reconstruction	Navigable generated experience; do not assume independent asset export	3D representations intended for repeated rendering and integration
Main engineering questions	Input coverage, camera control and output-mode requirements	Temporal consistency, action limits, latency and inference	Unseen surfaces, asset quality, animation, memory, compression and rendering
Cost comparison	Depends on workload and output mode	Depends on duration, resolution and interaction	Generation plus runtime rendering and animation; no standardized cross-system benchmark claimed

This workflow comparison replaces the original infographic. It does not establish relative training cost, image quality or throughput.

The fundamental difference in cost structure

Atlas and Genie 3 both rely heavily on generative inference.

For video or world-model generation, computation increases with output duration, resolution, and interaction time. The system must continue producing new visual content as the user moves or as the timeline progresses.

Mugen3D shifts more of the work into the asset-generation stage.

Once the asset has been generated, the runtime application can render it repeatedly without regenerating every frame. The remaining costs are related to rendering, animation, memory, compression, and deployment.

The difference in interaction

Genie 3 allows users to navigate through a generated environment. The world responds to movement, but the underlying content is still produced as part of the model’s generation loop.

Atlas provides camera-controlled generation, novel views, and spatial reconstruction. Its output depends on the selected workflow and output mode.

Mugen3D is designed around reusable 3D assets. In an application, these assets can be positioned, rendered, animated, and combined with other systems.

This is the difference between:

watching generated content;
navigating generated content;
building an application around reusable 3D content.

The difference in commercialization

Genie 3 remains a limited research preview.

Project Genie is an experimental prototype available to a limited group of Google AI Ultra subscribers in the United States.

Atlas is entering early access with selected partners.

Mugen3D is following a public product and demo path, with ongoing development and product releases.

This does not mean that one approach is automatically better. It means the three technologies are currently at different stages of productization and are designed for different deployment scenarios.

The difference in application scope

Genie 3 and Atlas are particularly relevant to:

interactive world generation;
robotics and embodied-agent research;
simulation;
camera-controlled visual content;
spatial reconstruction.

Mugen3D is designed for an asset-oriented workflow, including:

interactive 3D assets;
digital humans;
virtual characters;
real-time applications;
virtual showrooms;
simulation;
interactive media.

The central question is whether the user only needs to experience the generated world, or whether the user needs to reuse and integrate the underlying assets.

Video may eventually become content that users can enter

Atlas and Genie 3 have pushed the industry’s imagination forward.

Atlas makes generative systems more spatially aware. It can control camera movement, reconstruct scenes, and produce 3D-related outputs.

Genie 3 connects movement, time, and generation. Users can enter a generated environment and influence what appears next.

Mugen3D follows an asset-oriented application path.

It first turns key objects and environments into reusable 3D assets, then uses animation, dialogue, and real-time rendering to make them move and interact inside a 3D space.

Its potential advantage comes from changing the unit of generation.

Instead of generating only a sequence of frames, the system attempts to generate a reusable representation that can support multiple viewpoints, interactions, and application workflows.

The future of screen-based content may not be limited to video or games.

People may continue to watch stories as videos, enter generated environments as interactive worlds, and communicate with digital characters in real time.

Robots may also train in simulated 3D environments, while the same underlying content is reused for education, entertainment, commerce, and social interaction.

The user may be looking at the same three-dimensional content, but choose to:

observe it;
explore it;
edit it;
or participate in it.

The companies and technologies that can turn research into usable products, bring those products to real users, and make people return to the experience may be closer to the next generation of visual computing.

The boundary between video and 3D is not disappearing because every video will become a 3D model.

It is disappearing because users increasingly expect visual content to be:

explorable;
editable;
interactive;
and reusable.

Sources and notes

The dates, specifications, and product statuses of Atlas, Genie 3, and Project Genie are based on information publicly available on their respective official pages as of September 2026.

Official sources:

Atlas: https://www.worldlabs.ai/blog/atlas
Genie 3: https://deepmind.google/blog/genie-3-a-new-frontier-for-world-models/
Project Genie: https://blog.google/innovation-and-ai/models-and-research/google-deepmind/project-genie/
Mugen3D: https://mugen3d.ai/

Discussion question:

In your workflow, what matters most: visual fidelity, camera control, asset reuse, real-time interaction, or predictable runtime cost?

Testing Single-Image 3DGS for E-commerce: From One Product Photo to an Interactive Web Asset

Mugen3D Dev — Fri, 16 Oct 2026 02:53:09 +0000

Traditional product photos and turntable videos show only predefined views. Interactive 3D lets shoppers rotate a product and inspect its sides, back, and overall volume.

Creating a 3D scan or manual model for every SKU is costly. This article tests a lighter approach: reusing an existing product photo to generate a free-viewpoint 3DGS asset.

Using SumeruAI's Mugen3D, we focus on the actual workflow, differences between product categories, and the quality checks required before batch deployment.

Note: API capabilities reflect current SumeruAI website and console information. The e-commerce integration architecture below is a suggested pattern; actual fields and outputs should be verified against current documentation and API responses.

1. The Gap Between Fixed Product Photos and Interactive 3D

Product photos and turntable videos help show appearance, but shoppers still cannot rotate the product or inspect any angle on demand.

For a product detail page, the core interaction is simple:

Rotate the product freely;
Inspect its sides, back, and overall volume;
Embed it in product pages, digital catalogs, or virtual showrooms;
Reuse existing product images and reduce additional 3D capture work.

Here, “interactive 3D for e-commerce” means orbiting, previewing, and embedding—not CAD data, manufacturing files, or physical simulation.

2. What Does Single-Image Generation Produce?

Mugen3D's Image to 3DGS feature accepts one product image and generates a previewable, exportable 3DGS asset as an asynchronous task. The website offers SQ and HQ quality modes; current output formats and download methods should be confirmed in the console documentation.

3DGS, meshes, and CAD serve different purposes. This article evaluates the output as a product-visualization asset.

A single image shows only one viewpoint, so the system must infer the back, bottom, and occluded structures. A rotatable result does not mean every unseen surface was measured accurately.

The output is best used for visualization, not assumed to be an engineering-accurate model.

Test Products and Selection Criteria

The test covers six categories representing common challenges: hard surfaces, soft materials, mixed materials, functional structures, transparency and reflections, and fine details.

3.1 Robot or Hard-Surface Toy

Robots and hard-surface toys have clear silhouettes and distinct components. The main checks are proportions, component connections, and perceived volume.

3.2 Plush Toy

Plush toys have soft surfaces and irregular silhouettes. The main checks are overall shape, fur appearance, and whether the inferred back looks natural.

3.3 Designer Toy or Collectible Figure

Designer toys combine exaggerated proportions, decorative details, and sometimes mixed materials. The main checks are character identity, material transitions, and consistency of the back view.

3.4 Shoe

Shoes combine curved surfaces, soles, openings, and hidden side structures. The main checks are functional structure, left-right relationships, and inferred geometry.

3.5 Cosmetic Bottle

Cosmetic bottles often include transparent or semi-transparent materials, reflections, labels, logos, and small text. The main checks are silhouette, label stability, and material appearance.

3.6 Watch

Watches combine glass, metallic reflections, dial markings, logos, and small text. The main checks are dial structure, strap connections, and detail stability.

Based on this test, robots or hard-surface toys, plush toys, and designer toys produced more stable silhouettes and materials, making them good candidates for initial batch generation. Shoes may be used at scale with sample-based human review. Cosmetic bottles and watches are more sensitive to transparency, reflections, small text, and complex details; for now, they are better suited to individual tests and manual review rather than automatic batch publication. For batch input, use consistent images with a complete product, clear silhouette, simple background, even lighting, and no severe occlusion.

4. From a Product Image to a 3DGS Asset

The Studio workflow is simple:

Upload a product image and confirm the subject;
Select a quality mode and click Generate;
Let the task run in the background for about 30 minutes while you continue other work;
Return to preview, rotate the result, and export the asset.

For batch testing, record the quality mode, actual generation time, file size, and review result to identify categories suitable for scale.

5. Generation Flow Based on Public API Information

Mugen3D's public API uses asynchronous jobs: the server uploads an image with a Bearer token, receives a task ID, then uses that ID to query status and retrieve the result.

The developer workflow has four steps:

Submit image → Receive task ID → Query task status → Retrieve the 3DGS asset

SQ submission example:

import requests


def submit_mugen_sq(access_token: str, image_path: str):
    url = "https://api.sumeruai.us/v1/mugen-3d/sq"
    headers = {"Authorization": f"Bearer {access_token}"}

    with open(image_path, "rb") as image_file:
        files = {"file": image_file}
        response = requests.post(
            url,
            headers=headers,
            files=files,
            timeout=120,
        )

    response.raise_for_status()
    return response.json()


result = submit_mugen_sq(
    "YOUR_ACCESS_TOKEN",
    "product.jpg",
)

task_id = result["data"]["id"]
print("Task ID:", task_id)

Before publishing an integration guide, verify authentication, task-status, download, and HQ request details against current console documentation and actual API responses.

6. A Proposed E-commerce Integration Architecture

Mugen3D generates the 3DGS asset; object storage, CMS, SKU binding, and the web viewer remain part of the merchant's existing system. After generation and review, the delivery path can be simplified to:

Approved 3DGS asset → Object storage or CDN → CMS SKU binding → Web viewer → Product detail page

Display the 3D viewer only when the asset has passed review and loads correctly; otherwise, fall back to the existing product images.

The CMS could store:

Product SKU;
Generation task ID;
Current task status;
3D asset location;
Generation version;
Review status;
Failure reason or internal notes.

This is a suggested architecture. Mugen3D does not provide a complete CMS or product detail page system.

7. How to Evaluate Results Across Product Categories

To avoid presenting only the most successful angle, every product should be reviewed using the same criteria:

At minimum, review the following:

Does the front remain consistent with the input image?
Are the left and right sides structurally plausible?
Do the back and bottom contain obvious artifacts?
Have the product proportions changed?
Are logos, labels, and small text legible and stable?
Are any components missing or duplicated?
Do transparent, reflective, or soft materials look natural?
Do floating elements, breakage, or visible noise appear during rotation?

The results can then be grouped into three levels:

Ready for the presentation workflow: Major viewpoints are stable, with no obvious silhouette or structural errors;
Manual review required: The overall result is usable, but text, logos, the inferred back, or materials present a risk;
Not currently recommended: The product is incomplete, structurally inaccurate, or substantially different from the real item.

8. Production Considerations

Before moving to batch use, add the following safeguards:

Keep credentials on the server

Store access tokens only on the server. The front end should receive only approved asset URLs.

Validate images before submission

Validate file type, size, resolution, and subject quality before submission. Send images with complex backgrounds, severe occlusion, or blur for manual preparation.

Add timeout, polling, retry, and error handling

Store the task ID and use a polling interval, timeout, limited retries, and error logging.

Generation success does not mean publication approval

Use category-specific rules for automatic approval, manual review, or unsupported products instead of publishing every completed result automatically.

Test mobile performance separately

Test asset size, first load, viewer compatibility, memory use, and failure fallback on real mobile devices and representative networks.

9. Suitable and Unsuitable Use Cases

Single-image 3DGS may be useful as a visual supplement for:

360-degree product exploration;
E-commerce product detail pages;
Digital product catalogs;
Virtual showrooms;
Marketing and social media content;
Visual previews in games or applications;
Concept demonstrations and rapid prototypes.

Without additional validation, it should not be treated as a direct replacement for:

CAD design or precise measurement;
Industrial manufacturing and tooling;
Use cases that require exact small text or logo reproduction;
Products that demand highly accurate transparent, glass, or mirror-like materials;
Workflows that require rigging, collision geometry, or editable topology;
AR try-on experiences with strict dimensional and occlusion requirements.

10. Conclusion

The value of single-image 3DGS is not to replace product photography or 3D modeling, but to turn existing product images into free-viewpoint visualization assets more efficiently.

Based on this round of results, robots or hard-surface toys, plush toys, and designer toys or collectible figures are suitable for initial batch generation. Shoes may be used at scale with sample-based human review. Cosmetic bottles and watches are not currently recommended. Any decision to publish these assets should also consider file size, mobile performance, and the business’s tolerance for visual errors.

Next, we will continue testing web-based 3DGS viewers for compatibility, compression, mobile loading, and catalog-scale SKU management.

Has anyone tested Gaussian Splatting viewers on production e-commerce pages? I’d be interested to hear how others handle viewer performance, file compression, and mobile loading optimization.

Same model, same audio: comparing 3 Audio-to-Face approaches in Unity

Mugen3D Dev — Thu, 20 Aug 2026 12:16:51 +0000

We’ve been testing different Audio-to-Face approaches for real-time characters, and one thing became obvious very quickly:

Even with the same character and the same source audio, different systems can produce noticeably different facial animation.

So for this test, we compared three approaches under the closest conditions we could reproduce:

Mugen3D Audio To Face
NVIDIA Audio2Face
Convai

For this comparison, we mainly looked at three things:

Timing— how closely the mouth movement follows the speech
Mouth movement — how restrained or exaggerated the articulation feels
Overall naturalness — whether the face feels believable while speaking

What we observed

NVIDIA Audio2Face

NVIDIA provides a flexible and technically mature solution, especially for developers who want more control over the overall pipeline.

In our test, the facial movement felt relatively clear and structured, although bringing the workflow into Unity requires more integration work.

Convai

Convai produced noticeably larger mouth and facial movements in our test.

The result feels more expressive and performance-oriented, which can work well when combined with full-body character animation.

Mugen3D

Our current approach is more restrained.

We’re focusing on keeping the mouth movement closely aligned with the source audio without making every syllable feel overly exaggerated, while keeping the Unity integration lightweight.

A separate reference: Georgy Dev

We also looked at Georgy Dev’s Audio-to-Face result.

However, we did not have access to the same character setup, so we don’t think it would be fair to include it in the direct comparison above.

Visually, the result looked very polished in the material we reviewed, so we’re including it here only as an additional reference rather than treating it as an apples-to-apples benchmark.

That distinction is important to us: different character rigs, rendering setups and production pipelines can significantly affect how facial animation looks.

What matters most to you?

When evaluating Audio-to-Face for a real project, which matters more?

tighter timing with the source audio
more expressive facial movement
overall visual naturalness
easier Unity integration

We’d be interested to hear how other Unity developers judge these results.

If you want to try our current Unity version yourself, the demo is available on GitHub:

[GitHub link]：https://github.com/sumeurai/AudioToFace-For-Unity