Get started

Trail

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.
Pine Script® indicator
by AGProLabs
Pine3D: A Native 3D Graphical Rendering EnginePine3D is a full 3D rendering engine for TradingView, powered by Pine Script™ v6. Pine3D pushes forward the frontier of TradingView 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 TradingView'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 TradingView 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 TradingView 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, TradingView 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 TradingView 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 TradingView'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
Pine Script® library
by Alien_Algorithms
4
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.
Pine Script® indicator
by LyroRS
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.
Pine Script® indicator
by Rathack
3
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.
Pine Script® indicator
by UAlgo
2
6 Multi-Timeframe Supertrend with Heikin Ashi as Source This is a multiple multi-timeframe version of famous supertrernd only with Heikin Ashi as source. Atr which stands in the heart of supertrend is calculated based on heikin-ashi bars which omits a great deal of noises. with 6 multiplication of the supertrend, its simply much easier to spot trend direction or use it as trailing stop with several levels available. this is a great tool to assess and manage your risk and calculate your position volume if you use the heikin ashi supertrend as your stoploss.
Pine Script® indicator
by Thinkologist
4
Percent Trailing Stop (%) - For Study Scripts=========== Percent Trailing Stop (%) - { FOR STUDY SCRIPTS } =========== Wow - this is an example of how to implement Alerts relating to a Trailing Stop (%) within your Study Script. It's taken a bit of effort to get this working but I think we got there! Alerts include Open Long/Short, Trailing Stop Hit, and (the most important one) Movement of Trailing Stop! <- this is actually really quite good, by the way! :) You can ignore the actual entry/exit orders - they're based on a simple MA cross and are therefore NOT relevant, NOT profitable and NOT recommended! You should be using this code as a way of adding a Trailing Stop to your own scripts - hope it helps! Set your "Open Long/Short" Alert to "Once per Bar Close" - Set your "Trailing Stop Hit" Alert to "Once per Bar" - Set your "Move TSL" Alert to "Once per Bar Close". - You're all done! Enjoy. ----------- Good Luck and Happy Trading!
Pine Script® indicator
by theCrypster
11
Percent Trailing Stop %=========== Percent Trailing Stop % =========== Another Stop Loss Indicator today - our last Fixed SL/TP script went down quite well, this one is for adding a Percent Trailing Stop from Entry Price to your own strategy. You can ignore the actual entry/exit orders - they're based on a simple MA cross and are therefore NOT relevant, NOT profitable and NOT recommended! You should be using this code as a way of adding a % Trailing Stop to your own scripts - hope it helps! You should also notice that a generally considered losing strategy (a simple MA cross) could actually become profitable with careful money management - try combining this Trailing Stop script with our Fixed Stop/Take Profit script for really accurate management of your capital. ----------- Good Luck and Happy Trading!
Pine Script® strategy
by theCrypster
7