Realtime Renko

I've been working on real-time renko for a while as a coding challenge. The interesting problem here is building renko bricks that form based on incoming tick data rather than waiting for bar closes. Every tick that comes through gets processed immediately, and when price moves enough to complete a brick, that brick closes and a new one opens right then. It's just neat because you can run it and it updates as you'd expect with renko, forming bricks based purely on price movement happening in real time rather than waiting for arbitrary time intervals to pass.

The three brick sizing methods give you flexibility in how you define "enough movement" to form a new brick. Traditional renko uses a fixed price range, so if you set it to 10 ticks, every brick represents exactly 10 ticks of movement. This works well for instruments with stable tick sizes and predictable volatility. ATR-based sizing calculates the average true range once at startup using a weighted average across all historical bars, then divides that by your brick value input. If you want bricks that are one full ATR in size, you'd use a brick value of 1. If you want half-ATR bricks, use 2. This inverted relationship exists because the calculation is ATR divided by your input, which lets you work with multiples and fractions intuitively. Percentage-based sizing makes each brick a fixed percentage move from the previous brick's close, which automatically scales with price level and works well for instruments that move proportionally rather than in absolute tick increments.

The best part about this implementation is how it uses varip for state management. When you first load the indicator, there's no history at all. Everything starts fresh from the moment you add it to your chart because varip variables only exist in real-time. This means you're watching actual renko bricks form from real tick data as it arrives. The indicator builds its own internal history as it runs, storing up to 250 completed bricks in memory, but that history only exists for the current session. Refresh the page or reload the indicator and it starts over from scratch.

The visual implementation uses boxes for brick bodies and lines for wicks, drawn at offset bar indices to create the appearance of a continuous renko chart in the indicator pane. Each brick occupies two bar index positions horizontally, which spaces them out and makes the chart readable. The current brick updates in real time as new ticks arrive, with its high, low, and close values adjusting continuously until it reaches the threshold to close and become finalized. Once a brick closes, it gets pushed into the history array and a new brick opens at the closing level of the previous one.

What makes this especially useful for debugging and analysis are the hover tooltips on each brick. Clicking on any brick brings up information showing when it opened with millisecond precision, how long it took to form from open to close, its internal bar index within the renko sequence, and the brick size being used. That time delta measurement is particularly valuable because it reveals the pace of price movement. A brick that forms in five seconds indicates very different market conditions than one that takes three minutes, even though both bricks represent the same amount of price movement. You can spot acceleration and deceleration in trend development by watching how quickly consecutive bricks form.

The pine logs that generate when bricks close serve as breadcrumbs back to the main chart. Every time a brick finalizes, the indicator writes a log entry with the same information shown in the tooltip. You can click that log entry and TradingView jumps your main chart to the exact timestamp when that brick closed. This lets you correlate renko brick formation with what was happening on the time-based chart, which is critical for understanding context. A brick that closed during a major news announcement or at a key support level tells a different story than one that closed during quiet drift, and the logs make it trivial to investigate those situations.

The internal bar indexing system maintains a separate count from the chart's bar_index, giving each renko brick its own sequential number starting from when the indicator begins running. This makes it easy to reference specific bricks in your analysis or when discussing patterns with others. The internal index increments only when a brick closes, so it's a pure measure of how many bricks have formed regardless of how much chart time has passed. You can match these indices between the visual bricks and the log entries, which helps when you're trying to track down the details of a specific brick that caught your attention.

Brick overshoot handling ensures that when price blows through the threshold level instead of just barely touching it, the brick closes at the threshold and the excess movement carries over to the next brick. This prevents gaps in the renko sequence and maintains the integrity of the brick sizing. If price shoots up through your bullish threshold and keeps going, the current brick closes at exactly the threshold level and the new brick opens there with the overshoot already baked into its initial high. Without this logic, you'd get renko bricks with irregular sizes whenever price moved aggressively, which would undermine the whole point of using fixed-range bricks.

The timezone setting lets you adjust timestamps to your local time or whatever reference you prefer, which matters when you're analyzing logs or comparing brick formation times across different sessions. The time delta formatter converts raw milliseconds into human-readable strings showing days, hours, minutes, and seconds with fractional precision. This makes it immediately clear whether a brick took 12.3 seconds or 2 minutes and 15 seconds to form, without having to parse millisecond values mentally.

This is the script version that will eventually be integrated into my real-time candles library. The library version had an issue with tooltips not displaying correctly, which this implementation fixes by using a different approach to label creation and positioning. Running it as a standalone indicator also gives you more control over the visual settings and makes it easier to experiment with different brick sizing methods without affecting other tools that might be using the library version.

What this really demonstrates is that real-time indicators in Pine Script require thinking about state management and tick processing differently than historical indicators. Most indicator code assumes bars are immutable once closed, so you can reference `close[1]` and know that value will never change. Real-time renko throws that assumption out because the current brick is constantly mutating with every tick until it closes. Using varip for state variables and carefully tracking what belongs to finalized bricks versus the developing brick makes it possible to maintain consistency while still updating smoothly in real-time. The fact that there's no historical reconstruction and everything starts fresh when you load it is actually a feature, not a limitation, because you're seeing genuine real-time brick formation rather than some approximation of what might have happened in the past.