When Both Real-Time Interaction and Promotional Videos Are Needed, Is It Necessary to Build Two Sets of Unity Models?

In Unity 3D animation production projects, when one model set needs to handle both real-time interaction and high-quality promotional videos, it is usually not urgent to rebuild a separate model set. But directly sharing the same final file is also not appropriate. A more stable approach is to first create a unified base model, then derive a low-poly version for real-time use and a rendering version for offline use. According to delivery habits in 2026, deciding output scenarios first and then splitting precision can avoid rework later.

Why Real-Time Interaction and Promotional Videos Have Such Different Modeling Requirements

Real-time interaction is constrained by frame budget and video memory, requiring control over triangle count, texture size, and Draw Call. Offline rendering, on the other hand, prioritizes subdivision surfaces, chamfers, and lighting layers, without making concessions for frame rate. Since these two evaluation dimensions differ, expecting one final model to satisfy both ends often results in frame drops in the engine and loss of detail in the renderer.

The differences can be summarized as:

• Real-time version: The typical range for a single object's triangle count is compressed according to the target platform's frame rate; textures commonly use 2K, high-end PCs can use 4K, and mobile ends drop to 1K.
• Offline rendering version: Can use 8K textures and higher subdivision geometry, with priority on chamfers and silhouettes.
• Real-time version relies on normal maps and LOD groups; offline rendering version relies on actual geometry and displacement details.

First Compare Against Four Criteria, Then Decide Whether to Split

Whether to split or not is not a subjective decision by the production team; it depends on four hard indicators: target platform, camera distance, modification frequency, and renderer specifications. If any of these conflict, sharing one model set will leave pitfalls for later stages.

• Target platform: When fixed for WebGL, mini-programs, or low-end mobile devices, the real-time version requires additional LOD generation and total triangle count control; if only running on high-end PCs, it may not need splitting.
• Camera distance: With many close-up shots, the real-time version needs normal maps to compensate for geometry; the offline version must still retain sufficient silhouette, so sharing a model often satisfies neither side.
• Modification frequency: During the concept phase with frequent changes, it is recommended to maintain one base model and derive both versions, rather than editing two finished models separately.
• Renderer and Unity pipeline: Built-in, URP, HDRP, or even different color spaces mean material parameters cannot be directly copied; offline rendering also requires separate verification of Gamma and Linear.

Deriving Dual Versions from One Base Model: The Two-Level Precision Splitting Method

Two-level precision splitting separates the "editable base model" from the "final exported models." Regular changes only occur on the base model, and you should not casually deliver the real-time version as an offline version after editing.

1. Unified base model: Apply scale, set units to centimeters, zero origin, and check for mirror and isolated vertices.
2. Shared UV: Open separate UV channels for important textures so the offline rendering version can share the real-time version's normal map coordinates.
3. Derive offline rendering version: Copy the base model, add subdivisions, preserve displacement map channels, and avoid overlaying so many steps that you cannot undo.
4. Derive real-time version: Copy the base model, reduce polygons, generate LOD groups, compress textures, and verify Shader compatibility.
5. Return to base model loop: Each modification only touches the base model, then record update points with notes to prevent the two finished models from diverging progressively.

With this arrangement, interaction debugging and promotional video production can proceed in parallel, and acceptance is based on the delivery unit of "base model + two derived files."

How Much Does Modeling Workload Differ: Cost Comparison Between Direct Sharing and Dual Versions

"Dual versions" here does not mean starting from scratch; they are derived from the unified base model and do not equal "double the modeling." The direct experience difference is: directly sharing one high-poly model may seem time-saving early on, but it defers risk to later stages. Based on project experience, the typical range is:

• Directly sharing one high-medium poly model: It saves initial split planning time, but after importing into the engine, performance or texture problems may appear. Adding low poly and fixing UV takes about 2–4 working days; for highly complex models, this may increase.
• Deriving two versions from a base model: About half a day to 1 day is spent at the beginning on splitting and LOD strategy; afterwards, modifications only touch the base model, and both versions are exported in parallel, significantly reducing rework frequency.

A Real Rework Case Explanation: Where Direct Model Sharing Gets Stuck

In a Unity 3D animation project, the client simultaneously required interactive displays and promotional videos. The modeling team initially provided the same high-precision model, with about a million triangles in the typical range. High-end PCs could run it, but after publishing to WebGL, frame drops were noticeable, and entering the scene required waiting over ten seconds. Later, when trying to add low poly, it was discovered that the original UVs were laid out for offline rendering. After polygon reduction, texture seams were amplified, necessitating re-unwrapping. The rework cost an experience range of about 2–4 working days (varies with model complexity). After switching to the two-version derivation from a base model, the real-time and offline versions were maintained separately, and regression testing only confirmed frame rate and rendered frames, with no further issues.

Halfway Acceptance Checklist: What to Check for Each Version

For the real-time version, after importing into Unity, check whether materials turn magenta, polygon counts and LOD switching behave as expected, and animation playback has no frame drops. For the offline rendering version, check whether texture paths are relative, whether black faces or inverted normals exist, and whether materials can be batch-replaced. It is recommended to include the version and asset list in the acceptance form: base model source files, triangle count range for each version, texture resolution, and material scheme. If doing multi-platform releases, also test on real devices or browser previews, as testing only on PC does not cover everything.

Applicability Boundaries: When One Model Set Is Sufficient

Scope of application: When publishing to WebGL, mini-programs, or mobile devices, while also needing to deliver high-definition videos to editors, following 2026 delivery habits it is more recommended to use dual versions. Not applicable: If Unity is only used for screen recording or outputting animation sequences, without real-time interaction or deployment to low-end devices, a medium-precision model set is sufficient; no need to split into two. If the schedule is only a few days, skipping LOD temporarily is acceptable, but you should note in the requirements document that "smooth performance on low-end devices is not guaranteed" to avoid later being considered a defect.

There is also a compromise: use automatic LOD for the real-time version. But it is not recommended as a primary solution, as automatic polygon reduction often causes mesh breakage on complex structures and should only be used for emergencies.

FAQ

When both real-time interaction and promotional video recording are needed, must the model be built twice?

Not necessarily. You can first build a base model, then export a real-time version and an offline rendering version. Only when the difference in visual precision and target platforms is very large would you need to build a second set from scratch.

When reusing one model set directly in both scenarios, what is the most common sticking point?

It tends to get stuck on triangle count and UVs. Offline models have high subdivision and cause frame drops after import; after polygon reduction, texture seams and detail loss appear, usually requiring 2–4 working days of rework.

How detailed should the base model be in the two-level precision splitting method?

The base model should clearly show structure, split lines, and key hole positions, without needing final render subdivision. A common approach is to allow upward subdividing for the offline version and downward polygon reduction for the real-time version.

If it was not split initially, can it still be remedied mid-project?

Usually yes, but at a higher cost. Returning to the base model and re-deriving is more stable than piecemeal fixes on the high-poly model. It is recommended to reserve at least 2–4 working days as a buffer period.

Action guide: When receiving a Unity 3D animation production requirement, first confirm with the client the target platform and output medium. If it is only for internal previews or standalone playback, one fairly complete model set is enough; when needing to launch on WebGL, mini-programs, or batch distribution, manage it by the approach of one base model with two derived versions. It is recommended to break modeling into three parts during quoting: base model, real-time optimization, and offline rendering preprocessing, to facilitate future additions and settlement.