Vertx.Debugging: wireframe debug drawing that strips itself out of builds

Wireframe shapes, drawn with instanced rendering

The package is described as fast editor debugging and gizmo utilities for Unity, and the technique is stated plainly: it uses instanced rendering to draw shapes efficiently. That is the whole reason to use it rather than the built-in gizmo functions, because the ordinary approach of calling Gizmos.DrawSphere in a loop issues a draw call per shape, and a debug view that renders a few thousand marks can cost more than the frame you were trying to debug. Batching the shapes through instanced rendering moves that cost to a single submission.

The limitation is equally plain. All shapes are wireframe, and the project states that there is currently no support for solid shapes planned. So the tool answers questions about where things are, how far a ray reached and which direction something points, and it does not answer questions about volume or occlusion. The shapes are contained in a Shape class, and the class can be statically imported if you use the types often:

using static Vertx.Debugging.Shape;

The list of shapes is long and covers the usual debugging vocabulary: spheres, hemispheres, boxes, capsules, cylinders, arcs, annuli, a surface point, a point, an axis gizmo, arrows and arrow strips, lines and line strips, a dashed line, a half arrow used for half-edge structures, a 2D arrow built from a normal, a plane, a cone, a pyramid and a camera frustum.

One call draws the shape

The drawing API is a single static call, and the examples show how little ceremony it takes. A sphere with a colour and a duration:

// Draw a sphere with the specified color.
D.raw(new Shape.Sphere(position, radius), color, duration);

The same call draws green when nothing was hit and red when something was, because the hit variant of the shape carries that information, and a cast shape behaves the same way when no colour is supplied, drawing in green with red where hits were detected, with the cast colour and the hit colour overridable by hand:

D.raw(new Shape.SphereCastAll(position, direction, radius, hits, hitCount, 10), duration);

That last line is worth pausing on, because a shape that carries the result array of a sphere cast is not something the standard gizmo API can express. You run the cast, and the same call shows you every hit along it, which is the difference between seeing a green line and seeing where the ray actually struck geometry.

Where you can call it from, and what changes in a gizmo context

The package accepts calls from most places: Update, LateUpdate, FixedUpdate and OnDrawGizmos, and it works with the ExecuteAlways and ExecuteInEditMode attributes, so a debug draw can happen in the editor outside play mode.

The context does change the behaviour, and the documentation is specific about it. When the shape is drawn from a gizmo context, the duration parameters are ignored, which makes sense because a gizmo draw belongs to the frame it was drawn in. The Gizmos.matrix setting is respected, so a shape can be drawn in a transformed space, but Gizmos.color is not supported, meaning the colour has to come from the call itself. The gizmos are also not pickable, so they cannot be selected in the scene view, which is a limitation to remember if you are used to inspecting gizmos to find a specific object.

Physics wrappers that draw the result of a cast

The second half of the package substitutes for the physics calls themselves. Instead of calling Physics and drawing the result yourself, you call the wrapper and the result is drawn for you:

int count = DrawPhysics.RaycastNonAlloc(r, results, distance);

The same idea covers Physics2D through a DrawPhysics2D equivalent. The time the casts stay visible is controlled either by a duration property or by a settings call, and the project recommends the settings call, because the duration property cannot be stripped from a build while the settings call can.

That distinction is the practical difference between this and a hand rolled debug helper. The drawing inside these methods is stripped in a player build, and the original method is attempted to be inlined back in, though the documentation notes that this inlining is not consistent. The cost of that inconsistency is small, since one method call next to a physics operation does not matter much, but if you want the calls to disappear completely you can alias the type instead:

#if UNITY_EDITOR
using Physics = Vertx.Debugging.DrawPhysics;
#endif

With that alias in place the production build resolves the name to the real Physics type, so there is no wrapper call to strip at all.

Stripping is the feature that justifies the package

The code stripping behaviour is described without much fuss, but it is the strongest argument for the package. Calls to the drawing methods are stripped when building, and you do not have to remove code or use defines. If your code spans many statements, only the method call itself is stripped, so the surrounding logic is untouched.

Compare that with the usual approach, where a developer wraps debug code in a conditional compilation block or a runtime flag, and where a flag in a shipped build still costs a branch on every frame and a forgotten block leaves debug drawing enabled in a release. Here the removal happens at build time and you do not have to think about it, and the type alias trick takes it one step further by removing the call entirely.

The one exception is the duration property, which cannot be stripped, and the documentation is direct about the consequence: if that matters to you, use the settings call instead. It is a small exception with a documented workaround, which is more than most debugging helpers manage.

Jobs and Burst work, but the dependency set is not conservative

The version support is stated in a compact note that is worth reading twice. Unity 2022.2 and above gets all features, and that applies to version 3.0.0 of the package and above. Unity 2019.4 and above works, but with no jobs and Burst support and with an older API. The package should support all render pipelines.

Jobs and Burst support is the interesting capability here, because drawing from a job means the debug output is produced by the Burst compiled code rather than by the main thread, which is what makes it possible to visualise a simulation running at high speed. The catch is that two of the general shapes, Text and ScreenText, are not currently supported in jobs.

The package manifest also tells you what the dependency set is, and it is where a careful adopter should pause. The package depends on the Unity collections library at version 2.1.0-exp.4, which is an experimental release, alongside Burst at 1.8.8 and the mathematics package at 1.3.1. Taking an experimental version of a core library as a dependency of a debug tool is a decision worth making deliberately, since the experiment can change under you.

The package itself is published as com.vertx.debugging at version 3.0.3, in the Tools category, with the changelog and documentation links pointing at the repository. The last push was on 2026-07-23, and the repository publishes no tagged releases, so the package version is the marker to track.

The rendering problems that are not the package's fault

The notes at the end of the project documentation are a list of Unity problems, and they are the kind of list that saves an afternoon. Gizmos must be enabled in the view, which is a setting rather than a bug but is the first thing to check when nothing appears. 3D gizmos support fading, but the behaviour may be inconsistent between Unity versions, so a shape that fades in one editor may not fade in another.

The rendering complaints are more specific. If you see rendering issues such as upside-down depth testing, or artifacts in the game view, the project states that this is a Unity bug, and that you can disable Depth Write and Depth Test in the problematic view using the settings under Project Settings, Vertx, Debugging. The same notes add that if the settings interface does not work on your Unity version, that is another Unity bug.

That is an honest and useful thing for a package to document. The alternative would be leaving you to assume the tool is at fault, and the practical takeaway is that the package works around a rendering bug in the editor rather than being immune to it, so an upgrade of Unity can change what you see even when nothing in the package changed.

Editorial conclusion

Vertx.Debugging suits a Unity developer who draws shapes in the editor and then ships the same code, because the stripping behaviour removes the usual excuse for guarding debug code with defines. It is the wrong choice if you need solid filled shapes, since everything is wireframe and solid shapes are not planned, and it is the wrong choice if your project is on Unity 2019.4, where the package falls back to an older API without jobs or Burst support. Before you add it, check which Unity version you are on, because the feature set differs sharply at 2022.2, and note that the package pulls in an experimental version of the Unity collections library, which is a dependency decision to make deliberately rather than by default. The licence is MIT, the package version is 3.0.3, and the last push was on 2026-07-23.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. vertxxyz/Vertx.Debugging on GitHub