DEV Community: 有点质量

25 Million Gaussians: Loading Detail While You Explore

有点质量 — Sun, 25 Oct 2026 11:55:04 +0000

The model we were integrating came as a PLY file of about 1.76 GB, containing 25,842,067 Gaussians. We previously wrote about the stalls and blur we investigated once it was rendering. This time, I want to take a step back: what does the browser receive first, and how does it fill in more detail as the view changes?

For the close-up test, we set a selection budget of 2.5 million Gaussians. The source contained more than 25 million, while the current selection contained only a few million. We had not simply deleted the rest. Making that work required preparation before the browser ever opened the model.

Figure 1. The images in this article show the Gemmingen quarry example from our public demo, published by diddlkiller and rendered through the SuperSplat viewer. Original scene. The 25.84 million source Gaussians and loading measurements discussed below belong to a different project model. These images illustrate the appearance of a scene.

Prepare data that can be used in parts

We did not simply split the original PLY into small files and tell the browser to read them in order. The order of records in a file does not tell a viewer what matters from a particular position, or which details can wait.

We first used Spark's conversion tools on the server to generate levels of detail, or LOD, and organize them into paged RAD assets for our native WebGPU viewer. Coarse nodes summarize an area, while nodes below them retain finer detail. The viewer can start with a coarse representation and refine the regions that matter for the current view.

The converted main model contained 581 pages, totaling about 722 MB. That is the size of the complete main asset, not the amount that must be downloaded to open one camera view. The original PLY still had to be downloaded and converted in full as part of this workflow.

Another number is easy to misread: the resulting tree contained about 38.04 million nodes, more than the source model's 25.84 million Gaussians. The extra nodes represent different levels of detail; they are not all Gaussians that need to be drawn at the same time. Source count, total tree-node count, and current selection count describe three different things.

Figure 2. The data flow used in this integration. The upper half happens before the viewer opens; the lower half continues as the view changes. Source count, tree-node count, and selection budget refer to different stages.

Show a coarse view, then prepare more detail

When opening the asset, the viewer first reads the page directory to find the data, then fetches the page containing the root nodes. It can display the coarse data already available without waiting for all 581 pages.

The directory records each page's location and length. Pages can live in a single file, with HTTP Range requests retrieving specific byte ranges, or in separate RADC files. We used separate chunks in this case. The viewer fetches the required file and checks the response length, so a request intended to read one page cannot silently consume an entire large file.

Camera position, orientation, canvas size, and the count budget then guide selection. A distant region that occupies few pixels can use a coarser representation. As the camera moves closer, finer nodes become useful, and selection identifies the pages that are still missing.

We request those pages, decode them, and select again. New data may unlock another level of refinement, so this proceeds in rounds. Once the current selection has the data it needs, we pack it for the GPU, upload it, and update rendering. A completed network request does not, by itself, put more detail on screen.

While the next set of data is being prepared, the current resources remain available for drawing. The replacement takes over only when it is fully ready. Camera interaction and preparation can therefore continue without clearing the scene and rebuilding it from an empty frame.

In this test, 2.5 million was the limit for the current selection. That selection can contain nodes from several detail levels; it is not the first 2.5 million records from the original file. A different camera position changes which details are worth keeping. Pages no longer involved in the selection can be released and fetched again later if needed.

Figure 3. A view of the same public quarry example, showing rock faces, ramps, and haul roads. When viewed up close, these features occupy more screen space, which is why the viewer needs to choose detail according to the view.

A short piece of pseudocode shows the steps between data arriving and the rendered image changing:

let selected = null, ready = false;
for (let round = 0; round <= pageCount; round++) {
  const cut = await select(view, budget);
  selected = cut.data ?? selected;
  const missing = cut.wantedPages.filter(id => !resident.has(id));
  if (!missing.length) { ready = true; break; }
  for (const id of missing) {
    await fetchAndDecodePage(id);
    resident.add(id);
  }
}
if (!ready) throw new Error("LOD selection did not converge");
if (!selected) return;
const next = await buildPass(selected);
if (signal.aborted) { next.dispose(); return; }
const old = pass;
pass = next;
old?.dispose();

This pseudocode omits scheduling and error handling. buildPass includes packing and preparing GPU resources. After each round of fetching, selection runs again until no pages are missing. Exceeding a round limit based on the page count raises an error rather than waiting indefinitely. The old resources keep drawing during selection, requests, and uploads; they are replaced only when the new resources are complete. If preparation fails, the old resources remain, and the unfinished update is kept for a retry.

The count budget is not a memory cap. Downloaded pages, decoded data, resources being prepared, and resources currently in use all occupy memory. Limiting the drawn count does not remove the need to manage their residency and release.

Loading ended, but refinement had not

Early in the integration, a state flag misled us. Loading had become false, so the test assumed refinement was complete, checked the image, and failed.

The root nodes were ready, but the next camera-driven refinement was still queued. An idle downloader did not mean all the work for the current view had finished.

We added queued LOD updates, selection in progress, and resource rebuilding to the busy state. Our checks also followed the work further: had the selected data actually reached rendering, and had the image changed accordingly?

Figure 4. A coarse view may already be visible while refinement is still queued. Loading state needs to include that follow-up work. Completing selection also does not mean the new resources have reached rendering.

We therefore distinguish between having an initial image and finishing refinement for the current view. Moving the camera creates another round of demand. In a streaming viewer, a statement that loading is complete needs to say which view it applies to.

After a failure, state must not get ahead of the image

Breaking loading into stages also creates several places where it can fail. A page may have arrived and selection may have changed when a later request fails. Or the CPU may have prepared new data, but building the GPU resources fails.

We encountered a case where the decoder remembered a new selection while rendering still used the old data. On retry, asking only whether the selection had changed could return no change. The selected data would then never be sent back to the rendering side.

A retry after failure must therefore be able to retrieve the current selection again, and unfinished updates must remain pending. The displayed count must describe data successfully handed over for rendering, not data still being prepared.

The following pseudocode puts the decoder and rendering states together. refine represents the selection-and-fetch loop above. forceOutput tells it to return data even if the selection has not changed:

try {
  let selected;
  try {
    selected = await refine(view, budget, { forceOutput });
    forceOutput = false;
  } catch (error) {
    forceOutput = true;
    throw error;
  }
  if (selected) { data = selected; dirty = true; }
  if (!dirty) return;
  const next = await buildPass(data);
  if (signal.aborted) { next.dispose(); return; }
  const old = pass;
  pass = next;
  old?.dispose();
  committedCount = data.count;
  dirty = false;
} catch {
  if (!signal.aborted) scheduleRetry(view);
}

data retains the selected data, and dirty records that it has not yet been committed. Even if the next selection is unchanged, that rebuild still needs to finish. committedCount changes only after the new pass replaces the old one. Forcing output restores the data; scheduling a retry makes another attempt happen. Both are necessary.

If the user leaves the scene during this work, any late result must also be released when the task is cancelled.

These measures may not make the first load faster. They determine whether the viewer can still function after repeated scene changes and failed attempts.

After a two-minute stall, check whether the bytes arrived

When we switched to the complete model, the first remote test stalled again. The scene was ready, but waiting for refinement timed out after 120 seconds. There were no GPU or page errors, and only a small number of page requests had been issued.

Further investigation showed that the private tunnel used by the test was very slow. An independent copy measured about 34.5 KB per second. A response header reporting a file's size tells us how many bytes to expect, not how many the browser has received.

To see whether data is still arriving, we can count the bytes read from the response body. This standalone observation snippet uses browser APIs:

const response = await fetch(pageUrl, { signal });
if (!response.ok) throw new Error(`HTTP ${response.status}`);
if (!response.body) throw new Error("Missing response body");
const reader = response.body.getReader();
let receivedBytes = 0;
try {
  while (true) {
    const { done, value } = await reader.read();
    if (done) break;
    receivedBytes += value.byteLength;
    console.log({ receivedBytes });
  }
} finally {
  await reader.cancel().catch(() => {});
  reader.releaseLock();
}

receivedBytes measures only the response body read so far. A chunk returned by read() is not a RAD page, and receiving it does not mean it has been decoded or displayed. Selection and upload still need to be checked separately.

We did not relax the refinement timeout or reduce the point count. Instead, we transferred the complete derived assets to the local machine, verified that the bytes matched, and reran the test with the same parameters. Overview, close-up, visibility, and resource-release checks passed in a real browser, giving us evidence to distinguish the earlier wait from a rendering failure.

That changed how we thought about loading while viewing. Paging lets the browser use a subset of the data first. LOD lets the current view represent a scene with fewer nodes. Neither delivers missing pages on behalf of the network or does the GPU's rendering work. The complete model could be viewed up close in that run, but interaction performance still needed further work.

When a large model takes too long to become detailed, we now follow the actual sequence: have the required pages arrived, has selection finished, and has the new rendering data taken over? Those questions give us a more concrete next step than repeatedly changing the point budget.

Combining Gaussian Splats and BIM in One Scene: What We Ran Into

有点质量 — Sun, 25 Oct 2026 11:51:27 +0000

Our BIM viewer originally dealt with walls, beams, equipment, and pipes. These objects had geometry, but also element IDs, properties, and a hierarchy. Adding Gaussian splatting introduced a very different kind of data: it could show what a site looked like, without automatically becoming a collection of engineering components whose properties we could query.

Putting the two together was appealing. A reconstruction from photographs could provide the surroundings and a sense of the space, while BIM retained the component information in the design model. Once we started integrating them, though, the work quickly went beyond loading another file format.

An earlier article covered stalls and blur in Gaussian rendering. This one looks back at the initial integration into our native WebGPU viewer: how we aligned coordinates, established occlusion, framed the whole scene, and decided which existing component operations still applied.

Figure 1. The kind of data we were adding: the public Knock Community Hall sample rendered in our viewer, retaining 1,935,275 Gaussians. The model was published by scbenoit (SteveB) under CC BY 4.0. We decoded SOG to PLY before rendering it. This image shows only the Gaussian input; the later images use a separate synthetic scene to test occlusion between Gaussians and BIM.

Align the coordinate conventions first

A BIM file and a Gaussian file can each display correctly on their own and still fail to line up when placed in the same scene.

Gaussian data often uses local coordinates established during reconstruction. An engineering model has its own origin, orientation, and units. Sharing a camera cannot remove those differences. We first need to establish which direction each axis represents and how much physical distance one unit corresponds to.

Our integration path first converts the source Gaussian coordinates to the viewer's Z-up convention, then applies the scene member's placement matrix. Translation, rotation, and scale are expressed at this layer, so the original Gaussian file can remain unchanged.

The integration layer therefore places the data using a supplied transform. The registration between the two models still has to be determined beforehand. Where the same wall corner lies in each dataset, and whether their physical scales match, are questions that do not disappear just because both files have loaded.

For engineering scenes with large world coordinates, we also subtract the same local origin in both rendering paths, letting GPU calculations operate on smaller relative coordinates. If each path chooses its own origin without carrying that difference through the pipeline, the two datasets still will not occupy the same space.

Figure 2. The main relationships in a mixed frame. Opaque depth produced by BIM participates in Gaussian rendering, and the colors from the two paths are composited.

Sharing a camera also means sharing depth

The next task was to make the front-to-back relationships work.

Suppose a group of Gaussians sits behind an opaque wall. The wall should hide it. When the camera moves to the other side and the Gaussians are in front, they should become visible again. Simply stacking two rendered images in a fixed order cannot guarantee that relationship.

We let BIM write the depth of opaque objects first. Gaussian rendering then uses that depth to determine whether a fragment lies behind geometry already drawn. Both paths need the same camera, canvas dimensions, and depth convention for those comparisons to mean the same thing.

We checked this with a deliberately simple synthetic scene: a gray wall as the BIM occluder, with red Gaussians on one side. Simple shapes made it harder for complex textures to hide an error.

Figure 3. A screenshot from the running test. The red region consists of Gaussians; the gray region is opaque BIM test geometry. From this side, the Gaussians are visible.

Figure 4. Looking from the other side hides the Gaussians. Hiding the gray occluder in the test makes the red Gaussians reappear. Figures 3 and 4 both show the synthetic validation scene.

The Gaussians also have their own rendering requirements. 3D Gaussian Splatting represents a scene using Gaussians with opacity, whose projected contributions must be blended in order. We put the visible Gaussian members into one sorting process and draw them from back to front, so the result does not depend on the order in which models were loaded.

The Gaussians participate in depth testing, but do not write to that opaque depth buffer. If a translucent Gaussian with a soft edge claimed depth as though it were a solid wall, it could incorrectly hide later contributions.

The key steps of a frame can be reduced to this pseudocode:

const camera = scene.camera;
const { color: bimColor, depth } = drawOpaqueBim(camera);
const ordered = sortBackToFront(visibleSplats, camera);
const splatColor = drawSplats(ordered, {
  camera,
  depthAttachment: depth,
  depthLoadOp: "load",
  depthCompare: "less-equal",
  depthWriteEnabled: false,
  blend: "premultiplied-alpha",
});
compositeOver(bimColor, splatColor);

This leaves out GPU resource creation and antialiasing configuration. It keeps the three relationships that matter here: a shared camera, existing depth, and alpha blending.

At this point, opaque BIM could correctly occlude the Gaussians. Transparent components such as glass needed separate handling. They also participate in alpha blending, and sharing opaque depth alone cannot resolve their ordering with Gaussians. That integration did not yet implement a global transparent sort covering both glass and Gaussians.

Framing the whole scene must include the Gaussians

Once the images could be combined, some previously routine features became worth checking again.

One example was the command to frame the entire scene. With BIM alone, computing the camera position from the BIM bounds was sufficient. After adding Gaussian members, the scene bounds needed to include them as well. Otherwise, both datasets could be loaded while the camera continued to frame only one of them.

We built a test that placed the Gaussians far from the BIM geometry and then checked the full scene bounds. This forced us to include Gaussian bounds in camera framing and near/far clipping calculations, rather than merely checking that they displayed correctly near the origin.

Figure 5. A diagram of the combined bounds, not a rendering screenshot. The green dashed rectangle encloses both types of data. Framing only the BIM on the left could leave the Gaussians on the right outside the view.

The combined bounds also have a specific purpose. The camera needs to know the size of the whole scene, while BIM culling and shadow calculations retain their own bounds. Adding distant Gaussian data does not mean that every BIM calculation should expand to cover it.

Rendering together does not make the interaction capabilities identical

At the interaction layer, it was easy to make another assumption: if everything on screen is 3D, should clicking it open properties, allow hiding by floor, or support distance measurements?

In our integration path, the answer depends on the data type.

A BIM element ID can connect geometry to properties and a hierarchy. Ordinary Gaussian data contains rendering information such as position, shape, color, and opacity. It does not inherently carry a business identity such as "this is a beam" or "this belongs to the third floor." A wall that looks continuous in the image is not necessarily a geometric surface available for calculations.

We therefore manage Gaussians as independent scene members. They can have an initial placement, be shown or hidden as a whole, and participate in scene framing. Element picking, property queries, and hierarchy operations continue to come from BIM data. Measurement and sectioning of Gaussian surfaces did not automatically arrive with the ability to display them.

The API needs to express that difference too. The application configures its actions from the capabilities returned by each member, rather than enabling every button whenever it sees 3D content:

function actionsFor(member) {
  const caps = member.capabilities;
  return {
    toggleVisible: caps.visibility.supported,
    pickElement: caps.picking.supported,
    showProperties: caps.properties.supported,
    browseHierarchy: caps.hierarchy.supported,
  };
}

For the Gaussian members described here, whole-member visibility is supported, while the other three component operations are not. A capability flag says that the interface supports an operation; it does not guarantee that a particular BIM file contains complete properties or hierarchy data.

This gives the two data types a clear division of work: Gaussians help people understand the site's appearance, while BIM anchors operations to identifiable components. Connecting a region in the captured site to a specific piece of equipment will require a data correspondence, beyond further changes to rendering code.

Scene switching is part of a complete integration

The final part of the work often stays outside the screenshot.

Loading and refining Gaussians creates asynchronous tasks. A user may enter a scene and immediately leave it, or destroy the entire viewer while new data is being uploaded. Requests already in flight, decoded results, and GPU resources all need a clear owner.

We tie loading, decoding, and rendering resources to the scene session's lifecycle. Disposing the scene cancels its tasks. Late results must be released even if they have already created GPU resources, and must not re-enter a scene the user has left. If initialization fails partway through, buffers allocated earlier also need to be reclaimed. Member visibility is handled separately: hiding is not disposal.

During refinement, we keep the current drawable resources until the next set is fully ready, then replace them. The content already on screen can keep rendering while preparation continues. If building the new resources fails, the current image and statistics should still correspond to the batch that was successfully committed.

The following example expands one replacement. Each scene session builds new resources serially, while the old resources continue rendering:

async function replacePass(data, session) {
  let candidate = null;
  try {
    candidate = await buildPass(data, session.signal);
    if (session.disposed || session.signal.aborted) return;
    candidate.setVisibility(session.memberVisibility);
    const previous = session.pass;
    session.pass = candidate;
    session.committedCount = data.count;
    candidate = null;
    previous?.dispose();
  } finally {
    candidate?.dispose();
  }
}

If buildPass fails internally, it must release the resources it has already allocated. If the build succeeds after the scene has been left, finally releases the unused candidate. Ownership of that candidate passes to the scene only when it successfully replaces the old resources.

To check the integration, we moved the camera to the other side of the test wall, hid the wall, and then switched the entire scene. Those ordinary operations checked spatial relationships, occlusion, and resource management together. Once Gaussians enter a BIM viewer, they need to withstand those operations alongside the original models.

Why We Rebuilt Our BIM Rendering Core with WebGPU

有点质量 — Thu, 08 Oct 2026 09:37:45 +0000

We started with Three.js and WebGL. Once we had models rendering in the browser, we worked through the usual optimizations: loading in chunks, reducing detail at a distance, batching draws, and skipping occluded geometry.

As that work progressed, changes began to affect one another. Drawing less required more checks. Keeping the display stable meant dealing with visibility decisions that changed from frame to frame. A fix in one part meant another round of checks elsewhere.

Eventually, we decided to rebuild our BIM rendering core with WebGPU. Looking back, several attempts that didn't work out as expected help explain why.

If it's marked invisible, why are we still drawing it?

One investigation in the old viewer stands out. The diagnostics showed that many elements had been marked invisible, but the amount of drawing hadn't gone down.

We traced the problem to a mismatch in granularity. The visibility logic could decide that an individual element didn't need to be drawn. The data being used to display it, however, didn't always let us remove that element independently. A more precise decision wasn't necessarily something the renderer could act on.

We tried adding checks for some of those elements. It saved no drawing work and caused more changes in their visibility state. We removed that change.

This was a limitation of how our old implementation organized data and applied its decisions. Blaming WebGL alone would have missed the problems in our own implementation. But adding more conditions to the visibility logic wasn't going to fix the layer underneath it.

Investigations like this led us to break down the work in each frame again. The CPU had to traverse the scene, update state, and prepare drawing commands. The main thread also had to handle mouse input and the application UI. Drawing only one room didn't mean the work needed to decide what to draw was cheap.

We can group that work into a few broad categories. Some of it overlaps, so the timings can't simply be added together:

After that, we started asking one more question when reviewing an optimization: did the work we claimed to have saved actually disappear from the steps that followed?

WebGPU gave us more room to divide the work

WebGL already let us use the GPU for drawing. What made WebGPU worth considering was the flexibility of its compute and drawing interfaces.

Compute shaders can process batches of work that lend themselves to parallel execution. Storage buffers can hold the data those tasks need. Indirect draws can read their drawing parameters directly from a buffer.

In a typical GPU-driven design, some filtering and draw preparation can happen on the GPU. That creates opportunities to reduce CPU work per object and avoid certain round trips between the CPU and GPU. Chrome's introduction to WebGPU discusses these capabilities as well.

Moving work has a cost, though. Data has to be prepared and transferred, and tasks may have to wait for one another. Small, scattered tasks may not be worth moving. Large batches of independent, similar decisions are more promising candidates.

We also considered replacing only the renderer while keeping our existing data preparation. We set that option aside during evaluation. If the data organization and repeated processing stayed the same, a new graphics API would inherit those costs.

The rebuild therefore included how we prepared data before it reached the renderer. We needed to reconsider what belonged on the GPU, what should stay on the CPU, and what work could be avoided earlier.

Shared geometry still needs to be drawn

Imagine a scene with a thousand identical chairs. They share the same geometry and material, but sit in different positions.

Storing a complete copy of the geometry for every chair would duplicate a lot of data. Instancing lets the chairs share geometry while retaining their own positions. Three.js's InstancedMesh supports this kind of use.

But all the chairs visible on screen still need to be drawn. A smaller file doesn't remove the pixels they cover or the occlusion between them.

Batching involves a similar tradeoff. Combining many objects into one draw batch can reduce submission work. If that batch spans several rooms, viewing one room may also cause geometry from the others to be submitted.

BIM adds another requirement: individual elements must remain usable. Two identical valves still need to be selected, hidden, and inspected separately. Large batches can reduce draw calls while making those operations harder to support.

Culling has a cost too

Inside a building, many elements are hidden behind walls. Not drawing them sounds like a straightforward optimization.

First, the engine has to establish that they really are hidden.

The view frustum, spatial hierarchies, and occlusion information can all help narrow down what needs processing. Each approach has different costs and works best in different situations. The most detailed check isn't necessary for every object.

Consider a CPU that issues an occlusion query and immediately waits for the GPU to return the result. It may save some drawing, but it also gives up an opportunity for CPU and GPU work to overlap. A long enough wait can make the whole frame slower. NVIDIA's discussion of occlusion culling covers this problem.

Correctness matters just as much. When the camera turns a corner, newly exposed equipment needs to appear promptly. A coarse decision mustn't hide pipes behind glass. When visibility is uncertain, drawing a little extra is usually preferable to leaving out an element.

Move the camera above the building and the tradeoff changes again. Much more of the scene is visible, so there is less drawing to eliminate, while the checks still cost something. An approach that works well indoors may offer little benefit from above.

Fewer draw calls, more GPU time

A draw call is a request to draw geometry. Counting draw calls is useful when looking at submission work, but that count doesn't describe the full rendering cost.

We ran into this again shortly after moving to WebGPU.

Once the minimal viewer could display a model, we tried merging more draw batches. The reasoning was straightforward: fewer calls should be faster. The call count did fall. GPU time increased, though, and the model took longer to appear.

We didn't adopt that experiment for the main rendering path, but kept it as a reference. We hadn't established exactly why it was slower. What we could tell was that further merging hadn't helped that version.

A single draw call can still contain a great deal of geometry. Overlapping transparent objects, shadows, and post-processing can also keep the GPU busy.

Resolution provides a simple example. Double both the width and height of an image, and the pixel count quadruples. Rendering time won't necessarily quadruple, but the GPU has more pixels to process.

WebGPU render bundles let us reuse previously recorded drawing commands, avoiding repeated encoding. Indirect draws let the GPU obtain drawing parameters from a buffer. Both are useful, and neither addresses every cost.

To validate a change like this, we still need to repeat the same interaction: does dragging feel smoother, does the UI pause, and has the image quality changed?

How much space does a 4K texture take?

The number of bytes downloaded often differs substantially from the memory a resource occupies at runtime, including GPU memory.

Take a hypothetical 4096 × 4096 texture. With uncompressed RGBA8 at 4 bytes per pixel, the pixel data for that resolution level alone occupies:

4096 × 4096 × 4 = 67,108,864 bytes, or 64 MiB.

That excludes other resolution levels and additional resources. GPU texture compression changes the footprint again. The download size can't be used directly as an estimate of runtime texture memory.

These costs are worth keeping separate:

A model loading successfully once doesn't settle the question. We also need to check repeated model switches. Long sessions, canceled loads, and closed views all put resource management to the test. A graphics API upgrade doesn't handle that work for the application.

A black screen in another browser

After integrating the new core into the viewer page, we encountered a black screen. The page worked in our development environment, but failed to render in an embedded browser.

We eventually found that our resource usage exceeded what that environment allowed. Our development machine exposed more generous limits, so it hadn't revealed the problem. After adjusting resource usage and testing again, rendering worked in that environment.

“Supports WebGPU” isn't the whole story. The browser, operating system, GPU, and driver all affect the capabilities available. Once something works on the development machine, the target environments still need to be tested.

Framework maintenance belongs in this calculation too. Three.js already provides WebGPURenderer, so choosing WebGPU still leaves room to use a framework. Taking direct responsibility for more of the rendering also means taking on its debugging, compatibility, and resource management.

We kept both viewers available during the transition. We compared the same models from the same camera positions and gradually brought the interactions across. Only after the new viewer became the default did we archive the old one.

We kept the batching experiment that had made rendering slower, too. If we revisit that direction, we can first look at what we changed and why we didn't carry it forward.

Rebuilding with WebGPU gave us more control over where computation happens and how drawing is organized. Whether a particular change helps still comes down to opening that model and moving the camera back to the spot where it used to stutter.