Reactive Trail System [WillyAlgoTrader]📊 Reactive Trail System (RTS) is an overlay trend-following indicator that combines a momentum-adaptive trailing stop, a dual volatility engine, a 0–100 signal quality score, and a complete trade-management layer (Entry / SL / TP1–TP3 / break-even) — all tracked live on a sectioned dashboard with win-rate statistics.
The core insight: a trailing stop should not have a fixed width. When momentum is strong, price moves cleanly and the trail can hug price to lock in profit. When momentum fades, price gets noisy and the trail must widen to survive the chop. RTS measures momentum every bar and reshapes the trail width automatically — up to 40% tighter in strong moves — so one setting adapts to changing conditions instead of being permanently too tight or too loose.
If you are new to trailing stops: think of the trail as a colored line that follows price from below in an uptrend (green) and from above in a downtrend (red). As long as price stays on the right side of the line, the trend is alive. When price closes through the line, the trend flips — and RTS turns that flip into a fully managed trade idea with a stop-loss and three targets drawn on the chart for you.
Works on all markets (crypto, forex, stocks, indices, commodities) and all timeframes.
🧩 WHY THESE COMPONENTS WORK TOGETHER
A classic supertrend-style trail has three chronic problems. First, its width is fixed — the same multiplier that protects you in chop gives back too much profit in a strong trend. Second, a raw trail flip says nothing about signal quality — a flip in dead, low-volume conditions looks identical to a flip with real participation. Third, a flip is not a trade — you still have to decide where the stop goes, where the targets go, and when to move to break-even.
RTS solves all three with one integrated pipeline:
Baseline MA (6 engines) → Dual volatility measure (ATR + StDev) → RSI momentum engine → Adaptive trail width → Ratcheting trail state machine → HTF bias + volume filters → 0–100 signal score → Wick-anchored SL + TP1/TP2/TP3 → Break-even automation → Trade outcome statistics
The baseline MA defines the anchor the trail hangs from. The volatility engine defines the raw distance. The RSI momentum engine then compresses that distance when momentum is strong — this is what makes the trail "reactive" rather than static. The ratcheting state machine guarantees the trail only ever tightens in the trade's favor (it never backs away from price). The HTF and volume filters decide whether a flip is allowed to become a trade. The scoring engine grades every entry so you can tell an A-setup from a C-setup at a glance. The risk engine converts the signal into concrete levels anchored to real market structure (the signal bar's wick), and the trade engine tracks every touch, break-even move, stop-out and reversal — feeding honest statistics back to the dashboard.
Remove any link and the chain breaks: without momentum adaptation the trail is just another supertrend; without filters every flip fires; without the wick-anchored stop the levels ignore structure; without outcome tracking you never learn how the system actually behaves on your market.
🔍 WHAT MAKES IT ORIGINAL
1️⃣ Momentum-adaptive trail width — the trail breathes with the market.
Instead of a fixed multiplier, RTS computes a momentum distance from the smoothed RSI and uses it to compress the trail:
— momDist = min(|RSI_smoothed − 50| / 50, 1.0) — 0 means dead-center momentum, 1 means extreme
— effectiveMultiplier = TrailMultiplier × (1 − Adaptivity × momDist × 0.4)
— trailOffset = volatility × effectiveMultiplier
With default Trail Multiplier 2.0 and Adaptivity 1.0, the trail runs at full width in neutral conditions and tightens by up to 40% when RSI pushes toward extremes. Set Adaptivity to 0 and you get a classic fixed-width trail; the default 1.0 gives maximum adaptation. RSI length 13 with EMA smoothing 3 keeps the width changes calm instead of jittery.
Why this matters: strong momentum = clean price movement = you can afford a tight trail that protects open profit. Weak momentum = noise = the trail widens automatically so you don't get shaken out.
2️⃣ Dual volatility engine — ATR, StDev, or a stabilized Hybrid.
Trail distance can be measured three ways (Volatility Length default 13):
— ATR: classic bar-range volatility
— StDev: close-to-close dispersion
— Hybrid (default): (ATR + StDev) / 2
ATR reacts to wicks and gaps; StDev reacts to closing dispersion. Averaging them dampens the weakness of each — a single wild wick inflates ATR but barely moves StDev, so the Hybrid stays stable where a pure-ATR trail would suddenly balloon.
3️⃣ Six baseline engines including KAMA and T3 — with a volume-safety fallback.
The trail anchors to a baseline MA selectable from HMA, ALMA (default, length 21), KAMA, T3, VWMA and EMA. KAMA and T3 are computed from their full formulas internally (Kaufman efficiency-ratio smoothing constant sc = (ER × (fast − slow) + slow)², and Tillson's six-stage EMA cascade with a = 0.7). If you pick VWMA on an instrument whose data feed reports no volume (common on some forex feeds), RTS silently falls back to EMA instead of plotting garbage.
4️⃣ Ratcheting trail state machine — the stop never retreats.
In a bull regime the trail is trail = max(previous trail, baseline − offset): it can only rise. In a bear regime it can only fall. A flip requires a full bar close beyond the trail — intrabar wicks through the line do not flip the trend. This one-way ratchet is what makes the line usable as an actual trailing stop rather than a wavy band.
5️⃣ Non-repainting HTF bias filter.
Optional filter: longs only when the higher timeframe (default 240 = 4H) closes above its 50 EMA, shorts only below. The HTF request uses the last closed HTF bar (index with lookahead), so the bias never changes retroactively — what you see in a live chart is what a backtest would have seen.
6️⃣ Signal quality score 0–100 — every entry is graded, not just fired.
Each entry gets a transparent confluence score:
— Momentum component (0–40): min(momDist / 0.6, 1) × 40
— Volume component (0–30): participation vs the 20-bar volume SMA, clamped; fixed 15 when the feed has no volume
— HTF alignment (10 or 30): 30 when the higher timeframe agrees with the trade direction, 10 when it doesn't
The score is shown in the BUY/SELL label tooltip, in the dashboard "Last signal" row, and in every entry alert. A 90-score long (strong momentum, heavy volume, HTF agrees) and a 45-score long are both valid flips — but you instantly know which one deserves full size.
7️⃣ Wick-anchored stop-loss — structure-aware risk, not a blind ATR offset.
Default SL mode anchors the stop to the signal bar's actual wick:
— Long SL = min(low − 0.25 × ATR, close − 0.5 × ATR)
— Short SL = max(high + 0.25 × ATR, close + 0.5 × ATR)
The 0.25 × ATR buffer sits the stop just beyond the wick (where stop-hunts reach), and the 0.5 × ATR minimum distance prevents absurdly tight stops on small-bodied signal bars. A classic fixed ATR mode (SL = entry ± multiplier × ATR, ATR length 14) is available too. Targets are pure R-multiples of the actual risk: TP = entry ± risk × multiplier.
Four one-click risk presets: Conservative (SL 2.5×ATR, TP 1R/2R/4R), Balanced (default: 1.5×ATR, 1R/2R/3R), Aggressive (1.0×ATR, 1.5R/2.5R/4R), Scalping (0.8×ATR, 0.8R/1.5R/2R), plus a fully manual Custom preset with input validation (TP1 < TP2 < TP3 enforced).
8️⃣ Full trade lifecycle engine with honest intrabar rules.
RTS doesn't just draw levels — it tracks the trade like a journal:
— Hits are checked only on confirmed bars, and never on the entry bar itself (entry-bar guard)
— TP-priority model: if a bar touches both a TP and the SL, the TP touch registers first (this optimistic assumption is disclosed right in the dashboard tooltip)
— Break-even automation: once TP1 is touched, the stop moves to entry; a BE moved this bar cannot stop you out on the same bar
— Opposite confirmed signal reverses the position (closes the old trade, opens the new one)
— Win definition is fixed and transparent: a trade counts as a WIN once TP1 has been touched (TP3 close, BE stop-out after TP1, or reversal after TP1); closed before TP1 = loss
9️⃣ Persistent trade visualization.
Entry (subtle dotted), SL (solid, prominent) and TP1/TP2/TP3 (dashed) lines extend with the live trade. When a TP is touched, its line turns solid teal with a ✓ on the label. When break-even activates, the original SL line dims to a record and the entry label is annotated "→ SL (BE)". After the trade closes, the drawing persists as a record until the next entry replaces it — you can scroll back and see exactly how each trade resolved.
🔟 Dashboard 2.0 with period-filtered statistics.
A sectioned panel (Market / Trade / Stats — each toggleable, position and font size configurable):
— Market: trend direction, trend age in bars, HTF bias, smoothed RSI, last signal with score and bars-ago
— Trade: entry, SL (with "BE @" marker), TP1–TP3 with ✓ checkmarks, R:R at TP1, SL distance in % — collapses to one row when flat
— Stats: closed trades, wins, losses, win rate with a ▰▱ gauge, and a "Form" strip of the last 10 results
The win-rate window is selectable: last 24 Hours, last 30 Days, or All-Time — computed from timestamped trade closures kept in a rolling 31-day buffer. Statistics reset on chart reload, and this is disclosed directly in the dashboard tooltips.
📖 HOW IT WORKS — CALCULATION FLOW
Step 1 — Baseline: the selected MA engine (ALMA 21 by default) is computed as the trail anchor.
Step 2 — Volatility: ATR and StDev over 13 bars are combined per the selected engine into one volatility measure.
Step 3 — Momentum: RSI(13) is EMA-smoothed(3); its distance from 50 (normalized 0–1) compresses the trail multiplier by up to 40%.
Step 4 — Trail update: the ratcheting state machine raises the trail in bull regimes / lowers it in bear regimes; a confirmed close through the trail flips the regime.
Step 5 — Filtering: the flip becomes an entry signal only if it passes the optional HTF bias and volume-confirmation filters, on a confirmed bar, after the warm-up period.
Step 6 — Scoring: the entry is graded 0–100 from momentum, volume participation and HTF alignment.
Step 7 — Risk placement: SL is anchored to the signal bar's wick (or fixed ATR), TP1–TP3 are projected as R-multiples of the actual risk per the active preset.
Step 8 — Trade tracking: every confirmed bar is checked for TP touches, break-even activation, stop-out or reversal; outcomes update the win/loss statistics and the Form strip.
📖 HOW TO USE
🎯 Quick start:
1. Add the indicator to your chart. Defaults (ALMA 21, Hybrid volatility, Balanced preset) are ready to use.
2. Wait for a ▲ BUY or ▼ SELL label — hover it to see the score, RSI, SL and TP1.
3. Check the dashboard: score of the last signal, HTF bias, and current R:R.
4. Prefer high-score signals (70+) where the HTF bias agrees with the trade direction.
5. Manage by the drawn levels: partial at TP1 (stop moves to break-even automatically), remainder toward TP2/TP3 or until the trail flips.
👁️ Reading the chart:
— 🟢 Green trail line below price = bull regime; it can only rise
— 🔴 Red trail line above price = bear regime; it can only fall
— ▲ BUY / ▼ SELL labels = filtered, confirmed entries (tooltip shows score and levels)
— Dotted line = entry reference · solid red = stop-loss · dashed green = TP1/TP2/TP3
— Teal solid TP line with ✓ = target reached · dimmed SL + "→ SL (BE)" = stop moved to entry
— Optional: soft trend fill between trail and baseline, and regime-colored candles
📊 Dashboard fields:
— Trend / Age: current regime and bars since the last flip
— HTF Bias: higher-timeframe direction (Off when the filter is disabled)
— RSI: the smoothed momentum value driving trail width
— Last signal: direction · score (bars ago)
— Entry / SL / TP1–TP3 / R:R / SL Dist: full live trade card
— Trades / Wins / Losses / Win rate: statistics for the selected period (24H / 30D / All-Time)
— Form: last 10 results, ▰ = win, ▱ = loss, newest on the right
🔧 Tuning guide:
— Too many flips / whipsaws: raise Trail Multiplier toward 2.5–3.0, raise Baseline Length toward 34–55, or enable the HTF Bias Filter
— Exits feel too late: lower Trail Multiplier toward 1.8, or keep Adaptivity at 1.0 so strong momentum tightens the trail
— Trail width feels jumpy: lower Momentum Adaptivity to 0.4–0.6 or raise Momentum Smoothing to 5–8
— Too few signals: disable the volume filter, or shorten Baseline Length toward 13–21
— Stops too tight on your market: switch the preset to Conservative, or use ATR mode with a higher SL multiplier
— Scalping lower timeframes: Scalping preset + Volatility Length 10 + consider HMA baseline
⚙️ KEY SETTINGS
⚙️ Main:
— Baseline MA Type (default ALMA): trail anchor engine — HMA / ALMA / KAMA / T3 / VWMA / EMA
— Baseline Length (default 21): higher = smoother, fewer flips
— Momentum (RSI) Length (default 13) and Smoothing (default 3): the adaptive-width driver
— Volatility Engine (default Hybrid) and Length (default 13)
— Trail Multiplier (default 2.0): base trail distance in volatility units
— Momentum Adaptivity (default 1.0): 0 = fixed width, 1 = up to 40% tightening
🔍 Filters:
— HTF Bias Filter (default off) + Higher Timeframe (default 240): trade only with the bigger trend
— Volume Confirmation (default off) + Threshold (default 1.2 × SMA20): require real participation; auto-bypassed on no-volume feeds
🛡️ Risk Management:
— Risk Preset (default Balanced): Conservative / Balanced / Aggressive / Scalping / Custom
— SL Mode (default Wick-Anchored): structure-based stop or fixed ATR
— ATR Length (default 14), SL / TP1 / TP2 / TP3 multipliers (Custom preset)
— Break-Even After TP1 (default on)
— SL/TP lines, labels, % distance and per-line styles are all configurable
🎨 Visual:
— Theme Auto / Dark / Light (auto-detects chart background), trail / baseline / fill / labels / candle-coloring toggles, font sizes, bull & bear colors
📊 Dashboard:
— Show/hide the panel and each section, position (4 corners), font size, Win Rate Period (24 Hours / 30 Days / All-Time)
🔔 ALERTS
— 🟢 LONG / 🔴 SHORT — entry with price, SL, TP1–TP3, R:R and score; plain text or JSON webhook payload for bot integration
— 🎯 TP1 HIT / 🎯🎯 TP2 HIT — target touches
— 🏆 TP3 HIT — final target, trade closed
— 🛑 SL HIT / 🛡️ BE STOP-OUT — stop-outs with entry and stop price
— 🛡️ BREAK-EVEN — stop moved to entry after TP1
— 🔄 REVERSAL — opposite signal closed the trade and opened the other direction
— ▲ / ▼ FLIP (optional, informational) — trail flipped but the entry was blocked by filters
All alerts fire once per confirmed bar close. Set up a single alert with "Any alert() function call" and toggle the categories you want in the settings.
⚠️ IMPORTANT NOTES
— 🚫 No repainting. Signals require barstate.isconfirmed; a flip needs a full bar close through the trail; the HTF filter reads only the last closed higher-timeframe bar; all alerts use bar-close frequency. What you see on historical bars is what the live chart produced.
— 📐 Intrabar assumption disclosed. When a single bar touches both a TP and the SL, the TP registers first (optimistic model). This is stated in the dashboard tooltip so the statistics are interpreted correctly.
— 📐 Statistics are session-based. Win/loss counts and the Form strip are computed from the loaded chart history and reset on chart reload. Past performance does not guarantee future results.
— ⚖️ Scope. RTS is a trend-following system — like any trail-based approach it performs best in trending conditions and will flip more often in tight ranges. Use the HTF and volume filters and the score to skip low-quality environments.
— 🛠️ This is an analysis tool, not an automated trading bot. It identifies trend regimes, grades entries, and draws structured risk levels — trade decisions remain yours.
— 🌐 Works on all markets and timeframes. Instruments without volume data are handled automatically (VWMA falls back to EMA, the volume filter bypasses, scoring uses a neutral volume component).
The indicator is completely free. Indicator
Mean Deviation Trail | Lyro RSIntroduction:
The Mean Deviation Trail (MDT) is an adaptive trend-following overlay that pairs Mean Absolute Deviation (MAD) volatility normalization with a signed, smoothed deviation signal to produce a dynamic, self-adjusting trail. Instead of relying on a fixed-width channel, MDT continuously measures how far — and in which direction — price departs from its mean, then modulates the trail width in real time. The outcome is a trail that tightens during strong directional regimes and widens during low-momentum or choppy phases.
How It Works
Deviation Engine — All calculations are anchored to an EMA of the source. From this anchor, the signed normalized deviation is computed:
Deviation Raw = (Price − EMA) / MAD
This captures both the direction and the relative magnitude of price displacement. A user-selectable smoothing MA (16 types) is then applied to filter noise from the raw signal.
MAD Volatility Normalizer — Mean Absolute Deviation is calculated across a rolling lookback:
MAD = Σ |Price − EMA| / Length
Unlike standard deviation, MAD is not inflated by squared error terms, making it more resistant to outlier spikes and producing a smoother volatility anchor.
Adaptive Trail Width — The smoothed deviation signal is scaled against its 80-bar peak to produce sigNorm (a value between 0 and 1). This drives the multiplier between two user-defined extremes:
Strong deviation → multiplier approaches the Tight value → trail hugs price.
Weak deviation → multiplier approaches the Wide value → trail drifts away.
Multiplier = Wide − sigNorm × (Wide − Tight)
Bandwidth = MAD × Multiplier
Trail & Outer Band — The trail sits below price in uptrends and above price in downtrends, offset from the EMA by the adaptive bandwidth. An optional outer band plots at half-bandwidth on the opposite side, useful as a soft confirmation level.
Trend State — Trend flips when the smoothed deviation crosses zero. Each flip prints a Long or Short label and resets the trail on the opposite side of price.
Key Features
16 Smoothing MA Types — SMA, EMA, WMA, VWMA, DEMA, TEMA, RMA, HMA, LSMA, SMMA, ALMA, ZLSMA, FRAMA, KAMA, JMA, T3.
Adaptive Trail Width — Tight in high-deviation regimes, wide when momentum decays.
Optional Outer Band — A half-width band on the opposite side for additional context.
Gradient & Trend Color Modes — Gradient scales color intensity with deviation strength; Trend applies flat directional coloring.
Colored Candles & Bar Color — Full chart integration with signal-aware candle coloring.
Long / Short Signal Labels — Printed at trend crossovers with 𝓛𝓸𝓷𝓰 / 𝓢𝓱𝓸𝓻𝓽 labels.
Color Palettes — Classic, Mystic, Accented, Royal, or fully custom.
Status Table — Displays live Trend direction and Strength (Weak / Moderate / Strong).
Alerts — Confirmed Bullish and Bearish alert conditions included.
Signal Interpretation
A Long signal (𝓛𝓸𝓷𝓰 label, below bar) fires when the smoothed deviation crosses above zero — price is pulling away from the mean to the upside and the trail flips below price.
A Short signal (𝓢𝓱𝓸𝓻𝓽 label, above bar) fires when the smoothed deviation crosses below zero — price is pulling away from the mean to the downside and the trail flips above price.
Strength = Strong indicates the deviation signal is near its recent peak — trend is mature and the trail is tight. Weak indicates a fading or compressing regime — the trail loosens, and continuation should be treated with more caution.
Recommended Settings
Long-Term Investing: 1D, MA Length 40, Smoothing 20, MAD 14
Swing Trading: 4h, default settings
Intraday Trading: 15m, MA Length 20, Smoothing 9, MAD 7, Tight 0.4, Wide 1.8
⚠️ Disclaimer
This indicator is for educational and informational purposes only. It does not constitute financial, investment, or trading advice. Past performance is not indicative of future results. Always combine with price action, proper risk management, and additional analysis. Indicator
Trailing Stop Quality [AGPro Series]Trailing Stop Quality
🧠 Core Idea
Is the current trailing reference defending the move cleanly, or is it creating noise that deserves a risk review?
📌 Overview / What it does
Trailing Stop Quality is a trade-management planner built for traders who want more context around active trailing stops, defense rails, and risk-shift conditions.
The script compares a swing defense rail with a volatility defense rail, evaluates trend-defense quality, measures pullback depth, checks volatility expansion, and converts the result into a 0-100 trailing stop quality score.
It produces trail rails, a centered risk-shift zone, a target-room guide, compact state labels, alerts, and a clean AGPro panel. It does not predict price direction, automate trading, or tell users what to buy or sell.
🎯 Purpose & Design Philosophy
Many trailing stop tools show a stop line, but they do not explain whether the current trail is structurally clean, too close to noise, too loose, or in conflict with another management reference.
This script was built to fill that gap.
It helps traders who already have a move in progress and want to evaluate whether the active trail is still defending the move with enough quality to keep monitoring.
The design philosophy is simple: manage context before reacting to the line.
⚡ Why This Script Is Different
Most tools focus on plotting a trailing stop line, flipping side, or marking stop transitions.
This script does NOT clone a Chandelier Exit flip-zone tool, does not act as a stop-loss optimizer, and does not print direct trade commands.
Instead, it scores the quality of the current trail using swing defense, volatility defense, trend slope, pullback depth, volatility expansion, and rail conflict. The result is a management-readiness layer, not another raw stop signal.
⚙️ Methodology
1. Context Detection
The script reads the active management side automatically or lets the user force long-side or short-side evaluation.
2. Reference Mapping
It maps two trail references: a swing defense rail and a volatility defense rail. The tighter reference becomes the active defense rail.
3. Reaction Evaluation
It scores whether the active trail is balanced, too near, too loose, conflicted, or already broken.
4. Visual Output
It displays the active defense rail, swing rail, volatility rail, risk-shift zone, target guide, compact labels, alerts, and AGPro panel state.
🗺️ How to Read the Chart
Zones = the risk-shift zone shows the gap between the swing defense rail and volatility defense rail. Its centered label summarizes the active conflict or quiet state.
Labels = labels mark TRAIL HOLDS, RISK SHIFT, MONITOR, NOISE, ROOM LIMITED, or DEFENSE LOST contexts.
Colors = green highlights clean defense, pink highlights lost defense, amber highlights risk review, and indigo highlights monitor context.
Panel = the panel summarizes Trail Quality, Stop Distance, Trend Defense, Risk Shift, and Action.
🚦 Signals & States
• TRAIL HOLDS → the active trail is defending cleanly with enough score and no major risk-shift conflict.
• RISK SHIFT → price is close to the active rail or swing and volatility rails disagree enough to deserve review.
• MONITOR → trail quality is acceptable but not strong enough for a clean defense state.
• NOISE → the current trail reference is low quality or too unstable.
• ROOM LIMITED → forward room is limited relative to the active trail risk.
• DEFENSE LOST → price crossed the active defense rail and the current trail context should be reviewed.
🔔 Alerts Logic
Alerts trigger when the script detects a clean trail-hold state, risk-shift state, monitor state, noisy trail state, defense-loss event, or limited target-room condition.
Alerts are attention markers only.
They are not trade instructions and should be interpreted within broader market context.
🧩 Confluence Logic
The strongest context appears when swing defense and volatility defense are aligned, the active trail distance is balanced, trend slope supports the management side, pullback depth is controlled, and volatility is expanding without becoming chaotic.
When those conditions align, the 0-100 trail quality score improves.
📊 When to Use
• During active trend-following management
• After a move has already started and trailing references matter
• When comparing swing-based trail behavior with volatility-based defense
• During pullbacks where the trail may be too close to price
• When evaluating whether a move still has reasonable room before the next structure edge
⚠️ When NOT to Use
• Very low-liquidity symbols with erratic wick behavior
• Extremely noisy chop where no stable management side exists
• Event-driven spikes where volatility changes too quickly
• Charts where the user wants entry signals instead of trail-quality context
🎛️ Key Inputs
• Management Side → controls Auto, Long Management, or Short Management mode.
• Swing Trail Lookback → controls the structural defense rail.
• Volatility Rail Multiple → controls the ATR-based volatility defense rail.
• Sensitivity → adjusts how strict the trail-quality scoring model is.
• Minimum Clean Score → defines when the trail can qualify as a clean defense state.
• Target Guide R Multiple → sets the forward planning reference used for target-room context.
• Visual settings → control rails, risk-shift zone, target guide, labels, panel location, panel theme, and font sizes.
🖥️ Interface & Visual Design
The interface is intentionally chart-first.
The rails show the actual management references, the zone shows swing-versus-volatility conflict, and the panel gives a fast decision read without turning the script into a crowded dashboard.
The AGPro panel uses a single merged blue header row and keeps the key state visible at a glance.
🧪 Practical Usage Workflow
1. Read the panel Trail Quality state.
2. Check whether the active defense rail is still below price in long management or above price in short management.
3. Review the risk-shift zone to see whether swing and volatility references agree.
4. Check whether the target guide still has reasonable forward room.
5. Use the label state as an attention marker, then confirm with broader structure and market context.
🔍 Interpretation Guidelines
Think of the output as trail-quality context, not a trade signal.
A high score means the active trail is better aligned with structure, volatility, trend defense, and pullback depth.
A low score means the current trailing reference may be too noisy, too close, too loose, or already losing defensive value.
🚫 What This Script Is NOT
• Not a prediction engine
• Not financial advice
• Not auto trading
• Not guaranteed signals
• Not a Chandelier Exit clone
• Not a stop-loss optimizer
• Not a buy or sell signal tool
⚠️ Limitations & Transparency
Trailing stop quality can change quickly when volatility expands, contracts, or when price moves into noisy pullback conditions.
Different timeframes may produce different trail rails and score behavior.
Fast markets, low liquidity, and abnormal wick behavior can reduce the usefulness of any rule-based trail-quality model.
🧠 Market Context Notes
Trail quality is not only about distance from price.
It also depends on whether structure is still defending the move, whether volatility is stable enough to support the rail, and whether the next target area leaves enough room relative to current trail risk.
🧾 Use Case Examples
When price trends higher and both swing defense and volatility defense remain below price with a strong score, the script may mark TRAIL HOLDS.
When price compresses toward the active trail or swing and volatility rails separate too much, the script may mark RISK SHIFT.
When price crosses the active defense rail, the script may mark DEFENSE LOST so the user can review the management context.
🧱 System Philosophy
Trailing Stop Quality belongs to the AGPro planner-style family: tools designed to help traders evaluate context before decisions, rather than simply adding another signal to the chart.
🔐 Non-Promise Statement
No output from this script guarantees a result.
No score represents certainty.
📉 Risk Disclosure
Trading involves risk.
Users are responsible for their own decisions, position sizing, and risk management.
This script is for educational and analytical purposes only and does not provide financial advice.
📚 Educational Note
The goal is to make trailing stop context easier to inspect by separating clean defense, risk shift, noisy trails, limited room, and lost defense states.
Indicator
Pine3D: A Native 3D Graphical Rendering EnginePine3D is a full 3D rendering engine for PulseWire, powered by Pine Script™ v6.
Pine3D pushes forward the frontier of PulseWire 3D rendering capabilities, providing a fully fledged graphical engine under an intuitive, chainable, object oriented API. Build meshes, transform them in world space, light them, cast shadows, project them through a perspective camera, and render the result directly on your chart, all without ever bothering about trigonometry synchronization or optimization.
The library brings forth a streamlined process for anyone that wishes to visualize data in 3D, without needing to know anything about the complex math that has previously gatekept such indicators. Pine3D does all the heavy lifting, including extreme optimization techniques designed for production ready indicators.
The entire API is chainable and tag addressable, so spawning a mesh, registering it, pointing the camera at it, and rendering the frame is a four line affair:
Mesh mybox = cube(40.0, color.orange).setTag("hero").rotateBy(0.0, 45.0, 0.0)
scene.add(mybox)
scene.lookAt("hero")
render(scene)
🔷 SURFACES: CONTOUR BAND RENDERING
Pine Script imposes a hard ceiling of 100 polylines and 500 lines per indicator . On the surface this looks fatal for dense 3D meshes: every triangle drawn naively burns one of those 100 slots, or two of the 500, and the budget evaporates within a few hundred faces.
The conventional escape hatch is strip stitching , tracing a polyline forward along one row of a grid and back along the next, packing a ribbon of quads into a single drawing slot. It buys a meaningful multiplier, but it pays for that multiplier with two structural constraints baked into the geometry itself:
One color per strip. A polyline carries a single stroke and fill color, so every cell along the ribbon must share the same shade. The moment you want per cell lighting, contour banding, or value driven gradients, every color change forces a new polyline and the budget collapses.
One contiguous ribbon per slot. Strips can only describe topologically connected runs of cells. Disjoint regions, holes, islands, and value clustered fragments scattered across the surface each demand their own polyline.
Pine3D breaks both constraints at once.
At the core of the engine sits an innovation that redefines the limits for visual fidelity: contour band rendering using degenerate bridge stitching . The technique quantizes a surface's elevation into colored bands, then collapses every cell that falls inside the same band, no matter where it sits on the screen , into one continuous, hole aware polyline path per band, threading invisible zero width bridges between disjoint islands so that a single polyline can carry thousands of polygon equivalent fragments scattered across the geometry.
The result:
A single polyline can render up to 2,000 disconnected triangle equivalents , spread across arbitrarily separated regions of the surface.
Theoretical ceiling of around 200,000 disconnected faces inside the 100 polyline budget, a regime that strip based stitching cannot enter at any color count above one.
A 40 x 40 heightmap (around 3,000 triangles) renders inside the budget with full per band contour coloring and room to spare. Stress harnesses have run 40 x 80 grids .
Each band's path is depth sorted and near plane culled, and cached between bars , so once geometry is built only the screen space projection runs per frame.
This algorithm enables scenes with extreme detail relative to the 100 polyline limit, and shifts the optimization focus from "drawing limits" to "CPU limits", which Pine3D natively handles with aggressive caching at every layer of the pipeline. The contour technique is currently integrated into the surface() function, with the same compression strategy generalizable to any mesh class and ultimately full scene rendering in future versions.
Non-uniform grids out of the box. surface() accepts optional axisX and axisZ arrays that override the default uniform spacing with custom column and row positions. This means logarithmic strike spacing on an option volatility surface, irregular timestamp spacing on a market depth heatmap, or any other non-evenly-sampled grid renders correctly without resampling the data first. The contour band engine, axis ticks, and gridBox cage all snap to the custom positions automatically.
A full contour surface is just a handful of lines; the damped ripple below builds once and never needs updating:
//@version=6
indicator("Pine3D - Contour Surface", overlay = false, max_polylines_count = 100, max_lines_count = 500, max_labels_count = 500)
import Alien_Algorithms/Pine3D/1 as p3d
var p3d.Scene scene = p3d.newScene()
var p3d.Mesh heatmap = na
if barstate.isfirst
// Damped cosine ripple
int N = 20
matrix data = matrix.new(N, N, 0.0)
for r = 0 to N - 1
for c = 0 to N - 1
float dx = c - (N - 1) / 2.0
float dz = r - (N - 1) / 2.0
float d = math.sqrt(dx * dx + dz * dz) * 0.7
data.set(r, c, math.cos(d) * math.exp(-d * 0.12) * 50.0)
heatmap := p3d.surface(data, 200.0, color.blue, color.red, 24)
.gridBox()
.gridLabels(color.white, "X", "Amplitude", "Z")
scene.add(heatmap)
scene.camera.orbit(35.0, 25.0, 380.0)
if barstate.islast
p3d.render(scene, lighting = true)
🔷 TRAIL3D: STREAMED OSCILLATOR PATHS
Trail3D is a first class streaming primitive built for visualizing two correlated time series as a 3D ribbon evolving through time. You give it a rolling buffer capacity and push (u, v) samples bar by bar; the primitive maintains the buffer, builds the ribbon geometry, and renders it inside a normalized bounding cube so the path always fits cleanly in view regardless of the underlying data range.
Under the hood, Trail3D is a coordinated bundle of polylines: one for the main ribbon, two for optional shadow projections onto the back wall and floor, and one for the wireframe cage. All four are depth sorted and occlusion clipped against the rest of the scene, and the primitive auto normalizes incoming samples against the rolling window's min/max so streaming data always fills the cube without manual scaling.
This enables a class of visualizations that would otherwise require dozens of polylines and manual buffer management: phase space portraits, Lissajous figures, oscillator pair correlations, attractor trajectories, and any "two indicators evolving together over time" study. The demo above shows a sine and cosine pair pushing samples each bar to trace a clean spiral inside the cage, the same pattern you would use to plot RSI vs MFI, momentum vs volatility, or any custom (u, v) signal pair.
A full streamed scene is a handful of lines:
//@version=6
indicator("Pine3D - Trail3D", overlay = false, max_polylines_count = 100, max_lines_count = 500, max_labels_count = 500)
import Alien_Algorithms/Pine3D/1 as p3d
var p3d.Scene scene = p3d.newScene()
var p3d.Trail3D trail = na
if barstate.isfirst
trail := p3d.trail3D(220.0, 200, color.yellow)
.cage(true)
.axisLabels("sin", "cos", color.white)
trail._uProj.col := #00ffff69
trail._vProj.col := #ff00ff71
scene.add(trail)
scene.camera.orbit(215.0, 20.0, 360.0)
float phase = bar_index * 0.15
float sinX = math.sin(phase) * 100.0
float cosY = math.cos(phase) * 100.0
if barstate.isconfirmed
trail.pushSample(sinX, cosY)
p3d.render(scene)
🔷 BARS3D: CATEGORICAL 3D BAR CHARTS
bars3D() turns any series of values into a fully lit, depth sorted 3D bar chart in a single call. Each bar is height mapped to its value, color graded between a low and high color, and packed into one combined mesh with per bar depth grouping so individual bars sort correctly even inside the merged geometry. The companion updateBars() mutator refreshes heights, colors, and labels in place every bar without rebuilding geometry, making it suitable for live rankings, rolling windows, and animated comparisons.
The chainable barLabels(catNames, valNames) helper attaches category labels at the base of each bar and value labels at the top, both depth sorted with the rest of the scene. Category labels are set once at build time, while value labels can be passed to updateBars(values, valLabels = ...) each frame to reflect live data. Combined with wireGrid() for the floor and a contour surface() in the background, bars3D() becomes the centerpiece of dashboards comparing assets, sectors, timeframes, or any categorical metric.
Negative values are handled automatically: bars below zero extrude downward from the base plane with reversed face winding, so signed series like PnL, delta, or momentum histograms render correctly without any extra setup.
A complete labeled bar chart is just a few lines:
//@version=6
indicator("Pine3D - Bars3D", overlay = false, max_polylines_count = 100, max_lines_count = 500, max_labels_count = 500)
import Alien_Algorithms/Pine3D/1 as p3d
var p3d.Scene scene = p3d.newScene()
var p3d.Mesh bars = na
array values = array.from(volume - volume , volume - volume , volume - volume , volume - volume , volume - volume , volume - volume )
array names = array.from("ΔV0", "ΔV-1", "ΔV-2", "ΔV-3", "ΔV-4", "ΔV-5")
if barstate.isfirst
bars := p3d.bars3D(values, 30.0, 30.0, 10.0, color.blue, color.red, 200.0)
.barLabels(names)
scene.add(bars)
p3d.wireGrid(scene, 300.0, 300.0, 6, 6, color.new(color.gray, 80))
scene.camera.orbit(215.0, 25.0, 360.0)
if barstate.islast
bars.updateBars(values)
p3d.render(scene, lighting = true)
Omitting valLabels in updateBars() tells the engine to auto format each numeric value via str.tostring() . Pass valLabels only when you need custom strings.
🔷 SCATTER CLOUDS: POINTS IN 3D SPACE
Pine3D treats scatter clouds as a first class use case without needing a dedicated scatter API. Because Label3D is the primitive and scene.add(array) is a single batch operation, you can scatter up to 500 points anywhere in 3D space, each with independent color, symbol, size, and tooltip , and have them depth sorted and occlusion clipped against the rest of the scene automatically.
Each point is a fully addressable Label3D with mutable fields. You can change position , textColor , bgColor , labelStyle (any label.style_* glyph including circles, squares, diamonds, triangles, crosses, arrows, flags), labelSize (any size.* preset), and text per point per bar. The renderer reads these mutations every frame, so animation is just direct field assignment.
This unlocks a wide class of visualizations: clustered data scatter, K means visualizations, particle systems, parametric surfaces sampled as point clouds, gradient colored attractors, multi class classification overlays, and structured curves like the demo above. The double helix demo plots two intertwined parametric strands as ~500 points with alternating colors and per point sizing, all inside the standard scene.add(array) pipeline.
The pattern is straightforward: build the array once in barstate.isfirst , add it to the scene, then mutate point fields per bar to animate.
//@version=6
indicator("Pine3D - Scatter Cloud", overlay = false, max_polylines_count = 100, max_lines_count = 500, max_labels_count = 500)
import Alien_Algorithms/Pine3D/1 as p3d
var p3d.Scene scene = p3d.newScene()
var array points = array.new()
if barstate.isfirst
for i = 0 to 499
p3d.Vec3 pos = p3d.vec3(0.0, 0.0, 0.0)
points.push(p3d.Label3D.new(position = pos, txt = "•"))
scene.add(points)
scene.camera.orbit(35.0, 20.0, 400.0)
if barstate.islast
for i = 0 to points.size() - 1
float t = i * 0.05 + bar_index * 0.01
p3d.Label3D pt = points.get(i)
pt.position := p3d.vec3(80.0 * math.cos(t), i * 0.4 - 100.0, 80.0 * math.sin(t))
pt.textColor := i % 2 == 0 ? color.aqua : color.fuchsia
p3d.render(scene)
----------------------------------------------------------------------------------------------------------------
🔷 TWO LAYER ARCHITECTURE
Pine3D ships as a clean, two layer library:
🔸 Layer 1 - DIY API. First principle building blocks ( Vec3 , Mesh , Camera , Light , Scene , plus world space overlay primitives) for total creative control. Author your own geometry, camera behavior, lighting setup, and scene graph from scratch.
🔸 Layer 2 - High Level Helpers. Production ready wrappers like surface() , bars3D() , trail3D() , updateBars() , updateSurface() , sphere() , torus() , cylinder() , and wireGrid() , plus chainable contour helpers gridBox() and gridLabels() that wrap the primitives into a few lines of code. Scatter clouds use the standard Label3D primitive directly.
The object model is chainable and scene oriented, so complex setups still read cleanly.
🔷 FEATURE LIST
Contour Surface Rendering - The most powerful 3D surface engine ever released for Pine Script. Render tens of thousands of polygon equivalent faces using a single polyline per contour band, delivering smooth, continuous terrain with natural ridges and valleys.
Adaptive Rail Sharing - Solid meshes drawn with the default linefill backend reuse one edge line between adjacent coplanar faces, averaging roughly 1.6 lines per face instead of the naive two, pushing practical mesh capacity up to ~360 faces depending on topology.
Interior Face Culling on Merge - mergeMeshes(meshes, removeInterior = true) detects coincident faces with opposing normals and strips them, so voxel style scenes (stacked cubes, block walls, lattice geometry) ship only their exterior shell and spend no budget on hidden interior faces.
True Perspective Camera System - Full 3D camera with position, target, fov, and orbit() controls. Supports cinematic camera movement, lookAt by mesh tag, and realistic depth.
Real Time Lighting and Shadows - Directional and point lights with configurable ambient, shadow strength, self shadowing, and a spatial grid acceleration structure for fast shadow queries.
High Performance Update System - updateSurface() and updateBars() let you animate massive datasets bar by bar without rebuilding geometry, keeping CPU usage minimal.
Rich Primitive Library - Cubes, cuboids, spheres, cylinders, tori, pyramids, planes, discs, circles, custom meshes, and the groundbreaking bars3D() with automatic labels.
Streamed Trail Primitive - trail3D() maintains a rolling buffer of (u, v) samples and renders them as a 3D ribbon inside a bounding cube, with optional projections onto the back wall and floor and a wireframe cage.
Depth Sorted Overlays - 3D labels, lines, polylines, wire grids, and trails, all correctly occluded and painter sorted against the rest of the scene.
Professional Contour Helpers - gridBox() and gridLabels() automatically add clean bounding boxes and axis titles, ticks, and series names that refresh on every updateSurface() call.
Tag Based Scene Graph - Every Mesh , Label3D , Line3D , and Polyline3D can carry a string tag. Scene exposes getMesh() , getLabel() , getLine() , getPolyline() , lookAt() , and remove() by tag, turning your scene into a lookup by name graph instead of an index juggling exercise.
Chainable, Intuitive API - Everything is designed for maximum readability and speed of development. Build complex scenes in just a few lines.
Production Ready Optimizations - World vertex caching, view projection caching, face preprocessing cache, shadow grid cache, and contour geometry cache, all managed automatically.
----------------------------------------------------------------------------------------------------------------
🔷 THE RENDERER
Every frame is produced by a single call to render(scene, ...) . The renderer runs the full pipeline: world transform, camera transform, back face culling, occlusion culling, depth sort, directional or point lighting with shadows, and perspective projection.
⚠ render() clears the entire chart drawing pool at the start of every call - every polyline , line , label , and linefill on the chart is deleted before Pine3D redraws, not just the ones it created. If you mix Pine3D with manual label.new() , line.new() , or similar calls, those drawings must be emitted after render() or they will be wiped every frame.
🔸 Setup Requirements. Pine3D consumes polylines, lines, and labels simultaneously, so your indicator() declaration must raise all three budgets, and the library must be imported under an alias:
indicator("My 3D Scene", overlay = false,
max_polylines_count = 100,
max_lines_count = 500,
max_labels_count = 500)
import Alien_Algorithms/Pine3D/1 as p3d
🔸 render() parameters.
maxFaces (int, default 100). Hard cap on solid faces drawn per frame. Contour bands, wireframe edges, labels, lines, and overlay polylines are not counted against this cap, and are bounded only by PulseWire's global 100 polyline / 500 line / 500 label budgets.
culling (bool, default true). Enable back face culling.
lighting (bool, default false). Enable diffuse shading. Reads scene.light if set; otherwise falls back to the render() args.
lightDir (Vec3). Overrides scene.light.direction when provided. Points toward the light.
ambient (float, default 0.3). Minimum brightness for shadowed faces (0.0-1.0).
wireframe (bool, default false). Force outline only output for the entire scene.
occlusion (bool, default true). Sparse raster pass that drops hidden faces before drawing. Major perf win on dense scenes.
occlusionRaster (int, default 768). Raster resolution of the occlusion buffer. Lower = faster but coarser; higher = stricter hidden face rejection.
Explicit render() args always win over scene.light , which makes render() the right place for ad hoc, per frame lighting tweaks.
----------------------------------------------------------------------------------------------------------------
🔷 MESH DRAWING MODES
Two independent axes control how a mesh appears on the chart:
🔸 Style (via mesh.setStyle(...) ) - what gets drawn:
"solid" . Filled faces. Default.
"wireframe" . All edges, no fill. Shows interior geometry.
"wireframe_front" . Only front facing edges. Cleaner silhouette for convex meshes.
🔸 Draw Mode (via mesh.drawMode ) - which PulseWire primitive carries the solid faces:
"linefill" (default). Uses the line and linefill budgets. An adaptive rail sharing optimization reuses one edge line between adjacent coplanar faces, pushing practical capacity up to ~360 faces per mesh depending on topology. Supports in place updates via updateSurface() and updateBars() . Rails are drawn transparent, so solid faces in this mode have no visible outline - use a wireframe style or "poly" drawMode if you need stroked edges. Recommended for all new code.
"poly" . Legacy polyline backend. Capacity ~100 faces, no in place updates, but renders the face outline using mesh.lineStyle and mesh.lineWidth . Use only when you need styled solid face outlines.
Wireframe styles always render with line primitives regardless of drawMode. Stroke width and style on edges (and on poly mode face outlines) come from mesh.lineWidth and mesh.lineStyle , which you mutate by direct field assignment.
----------------------------------------------------------------------------------------------------------------
🔷 QUICK START
The best practice lifecycle is simple:
Create one persistent Scene with newScene() .
Build meshes and helper overlays once in barstate.isfirst .
On later bars, mutate objects in place with transforms or helper mutators like updateBars() and updateSurface() .
Call render(scene, ...) once per frame. It automatically clears the previous chart drawings.
A complete, lit, animated 3D scene is still a handful of lines:
//@version=6
indicator("My First 3D Scene", overlay = false, max_polylines_count = 100, max_lines_count = 500, max_labels_count = 500)
import Alien_Algorithms/Pine3D/1 as p3d
var p3d.Scene scene = p3d.newScene()
var p3d.Mesh sun = na
if barstate.isfirst
scene.setLightDir(1.0, -1.0, 0.5).setAmbient(0.3)
sun := p3d.sphere(50.0, 16, 12, color.orange).setTag("sun")
scene.add(sun)
p3d.wireGrid(scene, 300.0, 300.0, 6, 6, color.new(color.gray, 80))
scene.camera.orbit(35.0, 25.0, 220.0)
if barstate.islast
sun.rotateBy(0.0, 1.5, 0.0)
p3d.render(scene, lighting = true)
----------------------------------------------------------------------------------------------------------------
🔷 RECOMMENDED USAGE PATTERN
Use your Scene and major meshes in var .
Build geometry once in barstate.isfirst .
Use updateSurface() and updateBars() on later bars instead of rebuilding meshes.
Use scene level helpers like wireGrid() when you want overlays added immediately.
Use trail3D() when you want a streamed oscillator style path with built in wall projections and cage geometry.
For scatter clouds, build an array once, hand it to scene.add(pts) , then mutate pt.position , pt.textColor , etc. each bar to animate.
Use mesh level gridBox() and gridLabels() (contour) and barLabels() (bars) to attach overlays to the mesh setup chain. They are drained into the scene by scene.add(mesh) .
🔷 CONSIDERATIONS
scene.clear() vs render(). scene.clear() removes objects from the scene graph (meshes, labels, lines, polylines). render() only clears the previous frame's PulseWire drawings and redraws from the current scene graph. You almost never need scene.clear() in the build once and update pattern.
Global scope series for updateSurface() / updateBars(). If your data uses Pine's history operator ( ) or calls functions like ta.rsi() , ta.atr() , request.security() , those must be declared at global scope so Pine tracks their bar by bar history. Calling them inside barstate.islast produces inconsistent results or compiler errors.
gridLabels() tick values auto refresh. When you call updateSurface() , any tick value labels created by gridLabels() are automatically updated to reflect the new data range. Axis titles and positions stay constant. You don't need to rebuild them.
barLabels() value labels via updateBars(). Create category labels once with mesh.barLabels(catNames) at build time, then pass valLabels to updateBars() on each frame. Value labels are refreshed automatically. Don't call barLabels() again.
Lighting convenience methods are chainable. scene.setLightDir() , setLightPos() , setLightMode() , setAmbient() , setShadowStrength() , and showLightSource() all return Scene and can be chained: scene.setLightMode("point").setLightPos(0, 200, 150).setAmbient(0.25) .
Mesh transforms return Mesh. moveTo() , moveBy() , rotateTo() , rotateBy() , scaleTo() , scaleUniform() , setTag() , setStyle() , setColor() , show() , hide() all return Mesh for chaining: mesh.moveTo(0, -20, 0).rotateTo(0, 45, 0).setStyle("solid") .
Degrees vs radians. rotateTo() and rotateBy() on Mesh expect degrees. The low level Vec3.rotateX/Y/Z() methods expect radians.
scene.lookAt() is tag only. scene.lookAt(t) accepts a string tag and points the camera at that mesh. To aim the camera at an arbitrary Vec3 , call scene.camera.lookAt(vec) directly.
remove(tag) removes one object. The search order is meshes, then labels, then lines, then polylines, and the first hit wins. Avoid reusing tags across primitive types if you intend to delete by tag.
Shadow grid acceleration is directional light only. The spatial shadow grid is only built when lightMode == "directional" . Point lights fall back to a linear O(M) scan, so heavy shadow scenes are fastest in directional mode.
guiShift and yOffset. scene.guiShift and scene.yOffset position the 3D viewport on the chart without consuming historical bar slots. Increase guiShift to push the scene rightward into future bar space; adjust yOffset to slide it vertically in price units.
bar_time projection. All chart drawings are emitted with xloc.bar_time , so the scene can sit arbitrarily far left or right of bar_index without forcing Pine to extend its history buffer. This is what keeps the engine stable on long charts and future projected scenes.
barLabels() without values. When you call mesh.barLabels(catNames) and omit value labels, every later updateBars(values) auto formats the numeric values via str.tostring() . Pass valLabels only when you need custom strings.
Direct mesh.vertices mutation requires invalidateCache(). Transform mutators ( moveTo , rotateBy , scaleTo , etc.) invalidate the world vertex cache on their own. Only raw index writes like mesh.vertices.set(i, newVec) need a manual mesh.invalidateCache() call to force re-projection. Skipping it will make the renderer draw stale geometry.
Drawing budgets fail silently. If a scene emits more than 100 polylines, 500 lines, or 500 labels in a single frame, PulseWire silently drops the overflow without raising a runtime error. Missing geometry almost always means a budget overrun - lower maxFaces , drop a contour level, or simplify overlay primitives to bring the frame back inside the caps.
render() deletes non Pine3D drawings too. Every render() call clears polyline.all , line.all , label.all , and linefill.all before redrawing. Any manual label.new() , line.new() , etc. issued before render() in the same frame will be wiped. Issue custom drawings after the render call if you need them to persist.
mergeMeshes() preserves depth grouping. When every source mesh passed into mergeMeshes() has the same vertex and face count (e.g. identical primitives in a voxel grid), the merged mesh auto derives depth group boundaries so the combined geometry still sorts correctly per original instance. Mixing primitives with different topologies disables the grouping.
CPU timeouts: knobs to turn. Pine Script enforces a per bar execution budget, and dense scenes can trip it before the drawing budget ever does. If a scene compiles but times out at runtime, reach for these levers in order: lower occlusionRaster (e.g. 768 -> 384) for the biggest single perf win, reduce maxFaces to cap the solid face pool, drop levels on contour surfaces, simplify sphere/torus segment counts, and gate heavy work behind barstate.islast so history bars only build geometry rather than render it.
----------------------------------------------------------------------------------------------------------------
🔷 MORE EXAMPLES
The following scenes were all built entirely in Pine Script™ v6 using Pine3D as the rendering layer. They exist to demonstrate that the library is a real engine capable of complex, production grade visualizations.
🔸 4D Hypercube (Tesseract). A rotating tesseract, projected from 4D to 3D to 2D in real time using a custom 4D rotation matrix layered on top of Pine3D's standard projection pipeline.
🔸 Solar System. Following the publication of my 3D Solar System back in 2024, which introduced new graphical rendering concepts into Pine Script, we have seen a wave of various interpretations of the underlying vector classes, ranging from tutorials to niche specific integrations using hardcoded math. It became clear that a unified architecture was needed, one that would lower the barrier to entry while simultaneously handling the optimization process, which is both complex and error prone to do manually.
That architecture is what Pine3D delivers. Below is a re-creation of the classic 3D Solar System rebuilt entirely on top of the library. It uses a fraction of the original code , renders roughly 5x faster , and adds real lighting cast directly from the Sun , all while consuming only a third of the available drawing budget thanks to the occlusion and culling mechanisms Pine3D handles out of the box.
----------------------------------------------------------------------------------------------------------------
🔷 API REFERENCE
🔸 Top Level Entry Points. newScene() creates a ready to use Scene with a default camera and light. render(scene, ...) draws the current frame and auto clears the previous frame's chart drawings; see the Renderer section above for the full parameter list. vec3(x, y, z) creates a Vec3. colorBrightness() is an exported color utility helper.
🔸 Mesh Factories.
Primitives - cube() , cuboid() , pyramid() , plane() , sphere() , cylinder() , torus() , grid() , disc() , circle() for ready made geometry.
customMesh(verts, faces) - Low level escape hatch for authoring your own topology.
mergeMeshes(meshes, tag, removeInterior) - Bakes transforms and combines many meshes into one. With removeInterior = true , coincident faces with opposing normals (e.g. shared walls between adjacent cubes in a grid) are culled so only the exterior shell survives, a major optimization for dense voxel style scenes.
surface(heights, size, lowCol, highCol, levels, axisX, axisZ) - Creates a contour surface mesh.
bars3D(values, barWidth, barDepth, spacing, lowCol, highCol, maxHeight) - Creates a combined 3D bar chart mesh; add labels with the chainable barLabels(names, values) method.
🔸 UDT Constructors. Overlay primitives and face descriptors are plain UDTs. Because these types have many fields, always instantiate them with named arguments rather than positional, e.g. Label3D.new(position = pos, txt = "•") :
Face - fields: vi (array of vertex indices into the parent mesh), col . Used when authoring customMesh() topology; every face must have at least 3 indices and should be planar.
Label3D - fields: position , txt , textColor , bgColor , labelStyle , labelSize , fontFamily , tooltip , visible , tag . Only position is required.
Line3D - fields: start , end , col , width , visible , tag , lineStyle .
Polyline3D - fields: points , col , fillColor , width , closed , visible , tag , lineStyle .
Vec3.new(x, y, z) or the vec3(x, y, z) shorthand.
🔸 Trail Primitive. trail3D(size, capacity, trailCol, minSamples) creates a streamed Trail3D primitive with a main trail, two projection polylines, and a cage polyline. capacity is internally clamped to 300 samples to keep the rolling buffer inside Pine's execution budget; passing a larger value silently resolves to 300. minSamples (default 60) is the sample count at which the cage reaches its full cube width: below that the cage stays cube shaped and samples stretch across it; above that the cage grows rightward at a fixed step until capacity is hit. scene.add(trail) registers the sub primitives into the scene. Trail3D methods: pushSample() , axisLabels() , cage() , moveTo() , show() , hide() .
🔸 Mesh Methods.
Transform - moveTo() , moveBy() , rotateTo() , rotateBy() , scaleTo() , scaleUniform() .
Appearance - setColor() , setFaceColor() , setStyle() , show() , hide() , setTag() .
Stroke styling (direct) - mesh.lineWidth := 3 and mesh.lineStyle := line.style_dashed control width and style of every visible mesh edge in wireframe modes and the outline of solid faces in drawMode = "poly" .
Shadow opt out (direct) - mesh.castShadow := false excludes the mesh from shadow casting while still receiving light. Useful for ghost overlays, debug geometry, or semi transparent meshes you do not want occluding the scene.
Lifecycle - clone() , faceCount() , invalidateCache() .
Data mutation - updateSurface() and updateBars() refresh persistent meshes in place. updateBars() refreshes any bar label positions automatically; pass catLabels / valLabels to also update the text.
Contour helpers - gridBox() and gridLabels() queue overlays on the mesh and hand them to the scene when you call scene.add(mesh) .
Bar helpers - barLabels() is chainable on a bars3D() mesh and queues its category and value labels for the next scene.add(mesh) .
Note: rotateTo() and rotateBy() expect degrees. The low level Vec3.rotateX/Y/Z() methods work in radians.
🔸 Scene Methods.
Lighting - setLightDir() , setLightPos() , setLightMode() , setAmbient() , setShadowStrength() , showLightSource() .
Scene graph - add(mesh) , add(label) , add(array) , add(line) , add(polyline) , add(trail) , remove(index) , remove(tag) , clear() .
Lookup and navigation - getMesh() , getLabel() , getLine() , getPolyline() , lookAt() , totalFaces() .
Cache control - invalidateLightCache() after mutating light direction or scene bounds externally; invalidateAllCaches() to also invalidate every mesh's world vertex cache (use after directly mutating mesh.vertices ).
Note: scene.clear() clears the scene graph itself. render() only clears the previous frame's PulseWire drawings.
🔸 Camera Methods. setPosition(x, y, z) moves the camera. lookAt(x, y, z) / lookAt(vec3) points at a world space target. orbit(angleX, angleY, distance) does a spherical orbit around the current target. setFov(val) sets the perspective scale factor. Camera fields ( position , target , fov ) are also directly mutable via assignment when you need to tune them outside the provided setters, e.g. scene.camera.fov := 1200.0 .
🔸 Light Field Mutation. In addition to the scene level convenience setters, every field on scene.light is directly mutable for fine grained tuning: scene.light.selfShadow := true enables self shadowing, scene.light.shadowBias := 0.2 adjusts the shadow acne offset, scene.light.shadowStrength and scene.light.ambient are also exposed. Mutate them after newScene() or between frames; the renderer reads them every call.
🔸 Vec3 Methods. Core math: add() , sub() , scale() , negate() , dot() , cross() , length() , normalize() , distanceTo() , lerp() . Rotation and helpers: rotateX() , rotateY() , rotateZ() , copy() , toString() .
🔸 Overlay Primitive Methods.
Label3D - moveTo() , moveBy() , setText() , setTextColor() , setTooltip() , show() , hide() , setTag() .
Line3D - setStart() , setEnd() , setPoints() , setColor() , show() , hide() , setTag() .
Polyline3D - setColor() , show() , hide() , setTag() .
Every UDT field is mutable via direct assignment for properties without a chainable setter:
Label3D - bgColor , labelStyle (label.style_*), labelSize (size.*), fontFamily (font.family_*), visible .
Line3D - width , lineStyle (line.style_solid / _dashed / _dotted / _arrow_left / _arrow_right / _arrow_both), visible .
Polyline3D - width , lineStyle (line.style_solid / _dashed / _dotted only; arrow styles are not supported by PulseWire's polyline primitive), fillColor , closed , visible .
Mutations are read per frame by the renderer, so they animate freely.
🔸 High Level Scene Helpers. wireGrid(scene, w, d, divX, divZ, col) adds a depth sorted ground grid. scene.add(array) adds a batch of labels in one call - the idiomatic way to push a scatter cloud into the scene.
🔸 Mesh Level Chainable Overlays. mesh.barLabels(names, values, ...) adds category and value labels on a bars3D() mesh. mesh.gridBox(col, divs) adds a wireframe bounding box cage on a surface() mesh. mesh.gridLabels(col, xName, yName, zName, ticks, fmt) adds axis titles and tick value labels on a surface() mesh; tick values auto refresh on updateSurface() . All three are queued on the mesh and drained into the scene by scene.add(mesh) .
----------------------------------------------------------------------------------------------------------------
This work is licensed under (CC BY-NC-SA 4.0) , meaning usage is free for non-commercial purposes given that Alien_Algorithms is credited in the description for the underlying software. For commercial use licensing, contact Alien_Algorithms
Library
Volume MAs Cloud Trend | Lyro RSVolume MAs Cloud Trend is a volume-weighted trend-following indicator designed to identify market direction, momentum strength, and dynamic trade management directly on price. By combining volume-adjusted moving averages, adaptive deviation bands, and an integrated ATR trailing stop, it delivers clear visual trend structure and actionable signals in a single overlay.
Key Features
Volume-Adjusted Moving Average
Uses a normalized formula: (Price × Volume) MA ÷ Volume MA, ensuring high-participation price moves carry greater influence. Supports 16+ MA types, with VWMA handled natively.
Deviation Band Cloud
Upper and lower bands are built from standard deviation over the MA length, scaled by independent positive and negative multipliers to adapt to volatility.
Cloud & Trail Modes
Cloud Mode visualizes trend structure using a filled band cloud.
Trail Mode switches to an ATR-based trailing stop for trend management.
Automatic Trend Signals
Bullish signals trigger when price crosses above the positive band.
Bearish signals trigger when price crosses below the negative band.
ATR Trailing Stop (Built-In)
A volatility-adjusted trailing stop initializes on each new trend and updates only in the trade direction, helping lock in gains while staying with the trend.
Custom Visuals & Palettes
Choose from Classic, Mystic, Accented, or Royal palettes, or define your own bullish and bearish colors. Includes MA glow, trend cloud fill, and trend-colored candles.
How It Works
MA Construction
Applies the selected moving average to volume-weighted price (or VWMA when selected) to create a participation-aware trend baseline.
Band Calculation
Calculates rolling standard deviation and offsets it using user-defined multipliers to form adaptive upper and lower trend bands.
Trend Detection
Crosses above the upper band confirm bullish momentum.
Crosses below the lower band confirm bearish momentum.
Trailing Stop Logic
On each new trend signal, an ATR-based trailing stop is initialized and dynamically updated in the trend direction.
Visual Synchronization
MA, cloud, trailing stop, and candles all change color in real time to reflect the current trend state.
Practical Use
Trend Confirmation
Sustained price action outside the cloud indicates strong directional momentum.
Breakout Identification
Band crosses highlight potential trend starts, especially when aligned with volatility expansion.
Trade Management
Trail Mode provides objective, volatility-based exits for trend-following strategies.
Quick Market Scanning
Color-coded candles and cloud structure allow fast visual assessment across multiple symbols and timeframes.
Customization
Adjust MA type and length to control responsiveness
Tune band multipliers for volatility sensitivity
Switch between Cloud and Trail modes depending on strategy
Customize color schemes to match your chart layout
⚠️ Disclaimer
This indicator is intended for technical analysis and educational purposes only. It does not guarantee results and should be used alongside proper risk management and additional analysis. The creator is not responsible for any financial decisions made using this tool. Indicator
Ultra Smart TrailIntroduction
The Ultra Smart Trail indicator is a comprehensive tool for traders seeking to identify and follow market trends efficiently. Combining dynamic trend detection with adaptive price bands, this indicator simplifies the process of understanding market direction and strength. It provides clear visual cues and customizable settings, catering to both novice and experienced traders.
Detailed Description
The Ultra Smart Trail indicator works by calculating a Trend Flow Line (TFL) using a hybrid moving average technique. This TFL dynamically adjusts to market conditions, smoothing out price fluctuations while remaining responsive to significant market shifts.
.........
Trend Flow Line (TFL)
A color-coded line indicating bullish, bearish, or neutral trends based on price movement relative to the TFL.
The TFL uses a combination of weighted moving averages (WMA) and double-weighted moving averages (DWMA) for accuracy.
.....
Dynamic Price Bands
The indicator plots upper and lower bands around the TFL, based on customizable multipliers of standard deviation. These bands adapt dynamically to volatility, helping traders spot overbought or oversold conditions.
The script calculates standard deviation-based bands with customizable multipliers, enabling precise adjustment to trading styles or instruments.
.....
Uptrend/Downtrend Highlights
The background and price bands visually differentiate trending and ranging markets, making it easier to identify high-probability trade setups.
.....
Reversal Alerts
By analyzing the relationship between price and bands, the script highlights potential reversals or continuation zones with distinct levels and fills.
.........
This indicator is a powerful addition to any trader’s toolkit, simplifying market analysis and enhancing decision-making. Indicator
Fractal Trail [UAlgo]The Fractal Trail is designed to identify and utilize Williams fractals as dynamic trailing stops. This tool serves traders by marking key fractal points on the chart and leveraging them to create adaptive stop-loss trails, enhancing risk management and trade decision-making.
Williams fractals are pivotal in identifying potential reversals and critical support/resistance levels. By plotting fractals dynamically and providing configurable options, this indicator allows for personalized adjustments based on the trader's strategy.
This script integrates both visual fractal markers and adjustable trailing stops, offering insights into market trends while catering to a wide variety of trading styles and timeframes.
🔶 Key Features
Williams Fractals Identification: The indicator marks Williams Fractals on the chart, which are significant highs and lows within a specified range. These fractals are crucial for identifying potential reversal points in the market.
Dynamic Trailing Stops: The indicator generates dynamic trailing stops based on the identified fractals. These stops adjust automatically as new fractals are formed, providing a responsive and adaptive approach to risk management.
Fractal Range: Users can specify the number of bars to the left and right for analyzing fractals, allowing for flexibility in identifying significant price points.
Trail Buffer Percentage: A percentage-based safety margin can be added between the fractal price and the trailing stop, providing additional control over risk management.
Trail Invalidation Source: Users can choose whether the trailing stop flips based on candle closing prices or the extreme points (high/low) of the candles.
Alerts and Notifications: The indicator provides alerts for when the price crosses the trailing stops, as well as when new Williams Fractals are confirmed. These alerts can be customized to fit the trader's notification preferences.
🔶 Interpreting the Indicator
Fractal Markers: The triangles above and below the bars indicate Williams Fractals. These markers help traders identify potential reversal points in the market.
Trailing Stops: The dynamic trailing stops are plotted as lines on the chart. These lines adjust based on the latest identified fractals, providing a visual representation of potential support and resistance levels.
Fill Colors: The optional fill colors between the trailing stops and the price action help traders quickly identify the current trend and potential pullback zones.
🔶 Disclaimer
Use with Caution: This indicator is provided for educational and informational purposes only and should not be considered as financial advice. Users should exercise caution and perform their own analysis before making trading decisions based on the indicator's signals.
Not Financial Advice: The information provided by this indicator does not constitute financial advice, and the creator (UAlgo) shall not be held responsible for any trading losses incurred as a result of using this indicator.
Backtesting Recommended: Traders are encouraged to backtest the indicator thoroughly on historical data before using it in live trading to assess its performance and suitability for their trading strategies.
Risk Management: Trading involves inherent risks, and users should implement proper risk management strategies, including but not limited to stop-loss orders and position sizing, to mitigate potential losses.
No Guarantees: The accuracy and reliability of the indicator's signals cannot be guaranteed, as they are based on historical price data and past performance may not be indicative of future results. Indicator
Indicator
Indicator
Strategy
Strategy
