---
title: "Fish-Net Remote Entity Presentation: Snapshot Interpolation, Extrapolation Caps, and URP Draw Poses in IO Games"
description: "Present remote Fish-Net entities with snapshot interpolation, capped extrapolation, and URP draw poses that never write back to simulation ticks in IO games."
url: "https://news.bigfatgames.com/fish-net-remote-entity-presentation-snapshot-interpolation-urp-io-games"
category: "Fish-Net Multiplayer"
date_published: 2026-09-14
reading_time_minutes: 9
word_count: 2153
---

# Fish-Net Remote Entity Presentation: Snapshot Interpolation, Extrapolation Caps, and URP Draw Poses in IO Games

*Delay the pixels, not the tick—keep the other ninety-nine players honest on screen.*

![Fish-Net Remote Entity Presentation: Snapshot Interpolation, Extrapolation Caps, and URP Draw Poses in IO Games](https://pub-07fb5e4955ba485b822d6b388be96d9a.r2.dev/627e11da-a23a-494d-9964-843e8f31c507/fish-net-remote-entity-presentation-snapshot-interpolation-urp-io-games/hero-ef3fb948-7cce-41a9-b9da-2becdcc1bc62.jpg)

**TL;DR:**

- Keep remote presentation on a delayed render clock; never write interpolated or extrapolated poses back into Fish-Net ticks.
- Interpolate between consecutive snapshots; only extrapolate when the buffer is empty, and cap that motion.
- Drive URP draw poses from the presentation sample so shaders and cameras never touch simulation state.
- Local player prediction and remote interpolation are different jobs—do not mix their time bases.
- Honest remotes in IO games come from buffer discipline, not from guessing farther into the future.

## Remotes Are Snapshots, Not a Second Predicted Avatar

## One consumer of time: snapshot rings vs NetworkTickSmoother

## Render delay: how far behind the newest snapshot you dare sit

## Interpolate into a draw pose the renderer owns

## Cap extrapolation so remotes never invent motion

## Feed URP cameras and instanced draws from presentation poses

## Conclusion

- Snapshots only — remotes are dated Fish-Net samples, not a second predicted avatar, so NetworkTransform and TickSmoother never define IO crowd motion.
- One time consumer — TimeManager ticks address a presentation-owned snapshot ring; stacking a smoother on that ring produces mush, late, oscillating neighbors.
- Render delay is a product choice — sit far enough behind the newest snapshot for two samples to lerp, with tighter windows on nearby threats and cheaper, longer ones on the far crowd.
- Draw pose, not sim pose — blend into a renderer-owned child, matrix, or buffer so URP never writes colliders or NetworkObject transforms, and cameras share that same presentation clock.
- Capped extrapolation — when the window is empty, guess only briefly by time, speed, and path, then freeze or fade; never invent motion across despawn, teleport, or ownership change.
- URP consumes presentation — cameras and instanced draws read the pose buffer, LOD the work, and keep hits and lag compensation on simulation time.

Ship your next IO crowd with a snapshot ring, capped extrapolation, and URP draw poses that never write back into Fish-Net ticks — then tune the delay per interest tier on bigfatgames.com tools.

## Frequently Asked Questions

### Should remote interpolation write into NetworkTransform or the tick?

No. Sample a presentation pose for rendering only. Simulation, collision, and Fish-Net state stay on tick time so reconciles remain honest.

### How large should the snapshot interpolation buffer be?

Large enough to absorb typical jitter plus one extra snapshot, small enough that remote motion still feels current. Size it from measured RTT variance, not a fixed frame count.

### Why cap extrapolation instead of predicting freely?

Uncapped prediction invents motion the server never sent. A hard distance or time cap stops rubber-banding and score-theft when packets stall.

### What is a URP draw pose in this pipeline?

A transform (and optional animation sample) taken from the interpolator at render time and applied only to the visual root or renderer, never to the networked rigidbody or tick object.

### Can the local player use the same interpolator as remotes?

Usually not. Local movement is predicted and reconciled; remotes are delayed interpolators. Sharing one time base mixes those jobs and causes hitching.

### Does this apply only to Fish-Net IO games?

The split—tick vs delayed draw pose—is general. Fish-Net’s snapshots make the buffer and time math straightforward; URP just consumes the pose.