I have not seen this implemented:
I find it quite useful to analyze how volume profile came together.
2 Likes
What you show is possible as a replay workflow, but I have not seen a separate NinjaTrader control that animates an already completed historical profile.
Use the Playback Connection, set its clock before the session you want to study, then add Order Flow Volume Profile with Tick resolution and a Session or Composite period. As Playback advances, the profile processes the replayed tick stream, so you can watch the POC, value area and distribution develop.
A few details matter:
- Market Replay data is the best source because it contains recorded Level I and Level II events. Historical playback can work, but bid and ask data may be simulated.
- Playback and Tick Replay are different. Tick Replay rebuilds historical indicator state. It is not an interactive timeline control.
- Start before the study range. NinjaTrader redraws the UI about once per second during Playback, although indicators and strategies still calculate from the replay stream normally.
- Order Flow Volume Profile requires the Order Flow+ entitlement.
So the workflow exists, but the one-click animation of any finished past profile shown in your GIF does not appear to be a separate native feature.
NIce going Bill, i do have a question are candles coloring reacting it also ?
I do not get why it would be useful? One thig useful I can think of could be masking everything to the right of the cursor but that would preferable be a separate indicator.
I programmed something similar for NinjaTrader 7 more than 15 years ago. As you moved the mouse, it displayed the Market Profile that had formed up to the bar under the mouse cursor. It was basically a replay controlled by the mouse cursor. You could merge and split sessions, etc. In the end, I never ported it to NT8, partly because I was too lazy and partly because I didn’t see much practical use for it.
2 Likes
Looks good!
I would argue that there’s a bit less need for reply within Market Profile VS Volume Profile because bar’s volume is not visible where as Market Profile is built from bars on the chart.
1 Like
Fixed scaling of the VP reply. The profile is scaled by max value of the full profile…as it should have been since beginning. Can also filter by trade size, not sure how useful that is.
Not sure how I feel about this one this takes it back the the original version, I think u kind took a few steps backwards, u were doing great with the previous ones, it probably just me, it does look great
One scaling detail matters if this is meant as replay: scaling each historical frame by the maximum of the completed full profile uses future volume to size earlier frames. It makes the animation stable, but it leaks the end-of-session state.
I would expose two modes:
- Replay-normalized: use the maximum bin only up to the current cursor or replay time.
- Session-normalized: use the final full-profile maximum, but label it as a comparison view rather than replay.
A useful acceptance case is to stop at the same timestamp once through forward playback and once through a mouse jump. Bin widths, POC and value area should match.
The trade-size filter is useful only when the input retains tick-level volume per trade. With minute bars or reconstructed historical data, the filter can look precise while the source cannot support it. I would display the source granularity and the rejected-volume count next to the filter. That makes the result testable.
I do have fixed volume per pixel option, however, that often overflows at 9:30AM and 4PM, otherwise scale is normalized to visible VPs or per each separately
I build profile from secondary tick data so it’s not an issue.
In my mind, this way is superior as volume profile ONLY changes at price levels where volume changed. In the example scaling is normalized to all visible VPs and is the reason why it does not span larger area.
1 Like
That clears up the data side. If the profile is rebuilt from secondary tick data, the aggregation itself is not using future bars.
The remaining difference is visual:
- Fixed volume per pixel preserves magnitude, but can overflow around 9:30 and 4:00.
- Per-profile normalization preserves each shape, but hides absolute growth.
- Normalizing across visible profiles preserves comparisons inside the current viewport, but the scale changes when the visible set changes.
I would show the active scale mode and its current denominator in the replay overlay or debug output. Then one straight playback and one cursor jump to the same timestamp should produce the same bins and denominator. If they do, updating only the price levels whose volume changed is a clean approach and avoids repainting the full matrix.
One thing I would separate here is the profile construction from the replay visualization.
If the profile itself is being rebuilt from a secondary tick series, then the important test is whether two different navigation paths produce exactly the same profile state at the same timestamp.
For example:
- Start at the beginning of the session and replay forward to 10:30.
- Record the bins, POC, VAH/VAL and total accumulated volume.
- Reset the state.
- Move directly to the same 10:30 point using the cursor/replay control.
- Compare the resulting profile.
If both paths produce the same underlying profile, then any remaining difference is primarily a visualization/scaling issue.
I also think having both scaling modes is useful:
- progressive scaling based only on volume accumulated up to the replay point;
- fixed/session scaling based on the final or selected reference profile.
They answer slightly different questions. The first shows how the profile actually evolved, while the second makes visual comparison between stages easier.
For the trade-size filter, using the actual secondary tick stream is important. Otherwise a filter can appear very precise even though the source data does not retain individual trade size.
I feel I have a pretty good underlying design. It’s nonblocking with time gated processing in OnRender() to keep the UI thread smooth. Underlying data structure (primary bar indexed buys and sells from secondary tick data) is the same so all VP are exactly the same (cached profile matches reply VP to a pixel). Reply VP is built like any other VP, just with different anchors. It actually came out of infinitely adjustable VP region idea: Best UI for range selection?
I like the way it works right now and no one can convince me otherwise 
It’s just clearer how much volume is at every level and by how much it has changed.
(I just realized that I am describing above my newer version, which foregoes fixed zone rangereplies. It does ‘reply’ VP to from any location on the chart:user presses a key combination to start the VP and moves mouse to the end)
2 Likes
This look nice I do like 
That makes sense. If the cached profile and the replay profile are coming from the same underlying buy/sell data structure and are matching pixel-for-pixel, then you have already eliminated the part I would have been most concerned about — the replay path producing a different profile state from the normal calculation.
And I can see why you prefer the progressive scaling in that case. If the goal is to visually follow how participation is developing at each price level, keeping the profile normalized to the volume available at that point in the replay probably communicates the change more clearly than a fixed final-session scale.
The newer mouse-defined range also sounds much more flexible than fixed replay zones.
One thing I’d be curious about: when the user moves the endpoint of the profile range, are you rebuilding the entire selected profile each time, or are you incrementally updating the existing bins as the range expands/contracts?
With the primary-bar indexed buy/sell structure you described, I could see the incremental approach becoming very efficient for larger ranges.