[UPDATED] Immediate Mode Draw

Immediate Mode Draw (IMDraw) for Unity is an API which enables drawing of a variety of primitives and text labels at run time. Debug visualisation is a common requirement of many projects. This asset is geared towards developers who want debug rendering that is convenient and efficient. All for just 10 dollars!

Features include:
• Easy to use, trivial to set up and very flexible.
• Support for solid, wire frame, line and label primitives.
• Options for culling and fading based on distance from camera.
• Set limits on the maximum number of vertices that can be rendered.
• Gizmo extension API that provides extended functionality over the standard Unity gizmo class.
• Optimized to reduce its impact on your project.
• No garbage generation.
• Includes full source code, examples and documentation.
• Fully compatible with Unity 5.0.0f4 and higher.
• Support for scriptable render pipeline (both URP and HDRP).
• Intended for use on all platforms.
• Dedicated support via e-mail or forum.


Asset store page | WebGL demo | User guide | API reference | Latest release notes | Website

_____________________________________________________________________

F.A.Q

Q: Does this work in URP, HDRP or legacy render pipelines?
A: It is intended to work in all pipelines and platforms. Be aware that Unity are still updating and changing the scriptable render pipeline and as such on rare occasions changes they make can break URP and HDRP functionality. When this happens I will make every effort to fix these issues quickly. If you have any issues, either e-mail me or comment in this forum thread and I will respond as soon as I can. Also if you want confirmation that it works in a particular version of Unity, let me know and I will test it for you.

Q: Does this work with VR?
A: Yes and some customers are using it for VR already. However there are a few parts of the API that don't work with VR (specifically IMDraw.Label and IMDraw.Rectangle). For text rendering in VR, please use IMDraw.TextMesh and IMDraw.TextMeshBillboard.

Q: What does this API offer over Unity Debug and Gizmo draw functions?
A: The API offers a much larger variety of primitives than the Unity API. Furthermore it gives you a much greater amount of options for how things are drawn both in editor and in-game. Please check out both the API reference and demos to get an idea of what is possible.

Q: How can this asset be useful to my project?
A: It is useful for situations where you want debug visualisation at run time. Some examples might include:
- Drawing boxes or spheres in-game that represent trigger volumes.
- Drawing the bounds for a renderer component such as a particle system or a mesh.
- Visualising physics collision contact points (a premade script is included for this).
- Displaying information for game objects in the world via labels.

_____________________________________________________________________

Releases

Version: 1.4.4 (Jan 19, 2022)

• [Changed] Improvements to IMDrawCamera to allow instantiation from script.
• [Fixed] Fixed issue where line and mesh primitives would flicker in certain situations on URP and HDRP.

IMDraw website (Aug 1, 2021)
- Fixed issue with website being broken due to Wordpress errors. Both the website and all demos for IMDraw are now back up and running.

Version: 1.4.3 (Apr 12, 2021)

• Note: This version has been submitted with Unity 5.3 since the submission process no longer works with Unity 5.0. It is however still compatible with Unity 5.0.
  
• [Changed] Render pipeline option moved from IMDrawCamera to IMDrawManager. On Unity 2017.1+ you can select between auto-detect, legacy, URP and HDRP render pipelines.
• [Changed] Deprecated usage of GL API for drawing lines. Mesh is now used instead.
• [Fixed] Fixed issue where collider center wasn’t used for rendering collider positions.
• [Fixed] Fixed issue where mesh bounds for lines wasn’t being set correctly.
• [Fixed] Fixed issue where line mesh object wasn’t being cleaned up correctly.

Version: 1.4.2 (Feb 26, 2020)

• [Fixed] Fixed issue where IMGizmo labels and images were incorrectly positioned/scaled when the editor UI has scaling applied.

Version: 1.4.1 (Sept 24, 2019)

• [New] Added new Arc3D primitive to IMDraw and IMGizmos.

Version: 1.4.0 (Jun 04, 2019)

• [New] Added new IMDraw and IMGizmos API draw functions.
• [New] Added support for scriptable render pipeline (LWRP and HDRP). See documentation for more information.
• [New] Added mesh-based line rendering as an alternative to GL line rendering.
• [Fixed] Changed the way screen space position was calculated in IMGizmos.
• [Fixed] Miscellaneous small bug fixes.

Version: 1.3.2 (Jun 08, 2018)

• [New] Added ZTest options for drawing IMGizmos mesh primitives.
• [Fixed] Text mesh primitives changed to use camera world position instead of local position.

Version: 1.3.1 (Oct 20, 2017)

• [Fixed] Changed material usage to use instantiated versions instead of modifying material assets.
• [Fixed] Fixed issue GL line primitive material pass wasn't being set.
• [Fixed] Fixed issue

Version: 1.3.0 (Aug 16, 2017)

• [New] Text mesh based primitives.
• [New] 2D rectangle primitive.
• [New] Custom ZTest options for drawing of wire, mesh and text mesh primitives.
• [New] Rich text option for label rendering.
• [New] Optional font size parameter for labels.
• [Fixed] Fixed bug with WireCone3D variant where the orientation of the cone was incorrect.

Version: 1.2.0 (Feb 15, 2017)

• [Changed] Complete overhaul of IMDrawManager and IMDrawCamera components. Registration of camera components with the manager is no longer necessary. This greatly simplifies the usage of IMDraw and makes it more robust against adding/removal of managers and cameras at runtime.
• [New] Tooltips for all IMDraw related inspector properties.
• [Fixed] Fixed a bug which caused the entire IMDraw API to be disabled in Unity 5.5 or later. This involved eliminating usage of the Conditional attribute since it no longer works.

Version: 1.1.1 (July 1, 2016)

• [Fixed] Fixed IMGizmos errors when doing a build by ensuring editor specific code is properly stripped.
• [Changed] Added a troubleshooting section to the documentation.

Version: 1.1.0 (Jun 20, 2016)

• [New] Added new IMGizmos API that provides extended functionality over the standard Unity gizmo class
• [Fixed] Fixed rendering issue with IMDraw 3D grid

Version: 1.0.1 (Apr 27, 2016)

• [New] Added IMDraw.WirePyramid3D.
• [New] Added IMDraw.Pyramid3D.
• [New] Added IMDraw.WireRhombus3D.
• [New] Added IMDraw.Rhombus3D.
• [New] Added IMDraw.WireCone3D.
• [New] Added IMDraw.Cone3D.
• [New] Added IMDraw.Spotlight for drawing spot light coverage area.
• [New] Added IMDraw.Frustum for drawing camera view frustums.
• [New] Added button to IMDrawManager to assign missing meshes as default if one or more mesh reference is missing.

_____________________________________________________________________

Feature roadmap

Note: all items are subject to change.

- IMDraw helper for drawing primitives via a game object component instead of script code.
- Playmaker support with a custom action for drawing primitives.
- Helper for visualisation of mesh normals and tangents.
- Screen space 2D primitives such as lines and polygons.
- Performance optimisation using either multi-threading or the burst compiler/job system.
_____________________________________________________________________

Please leave any comments, suggestions, feature requests or issues you have with the asset in this thread.

Thank you for your interest!

 

An IMDraw v1.1.0 update has now been published to the asset store. It now features a new API for drawing gizmos and provides much greater functionality over the standard Untiy gizmo class.

 

Hey RV1.

When I try to build my app for PC I get this:

Assets/IMDraw/IMGizmos.cs(170,38): error CS0103: The name `UnityEditor' does not exist in the current context

Is this asset suppose to work when I build my app?

-Jeff

 

This asset is meant to work for any sort of build and this happens to be a bug. Fortunately it's fairly easy to fix and I'm just putting together a fix for you, which just involves replacing IMGizmo.cs. Is it okay if I send the file to the e-mail on your website?

 

Sure, that's fine. Thx.

Appreciate the quick resolution...

-Jeff

 

Hi Jeff,

I have e-mailed you a replacement IMGizmos.cs file which you can overwrite your existing copy with. The technical explanation for this fix is that IMGizmos is used for Unity editor scene view rendering, so I had to ensure that it's code is correctly stripped out when a build is performed. If this fix works out fine for you and there are no further issues, I will publish a new v1.1.1 update. I have made some adjustments to my testing procedure checklist to catch issues like this in future.

Let me know if that fix works out fine for you and if you have any further problems.

Sorry for any inconvenience it has caused.

Thanks.

Edit: If there are any other customers who urgently need the same fix, let me know and I can e-mail it to you. Publishing of asset updates usually take a few days!

Update: Version 1.1.1 has now been published, which contains a fix for the IMGizmos build issue.

 

IMPORTANT NOTICE REGARDING UNITY 5.5 OR LATER!

For anyone who is using Unity 5.5.x or later, IMDraw is currently broken because the usage of System.Diagnostics.Conditional no longer works the same as before in these versions of Unity. I am unsure why this is, but there is a bug report for this issue which Unity have marked as "by design".

https://issuetracker.unity3d.com/is...t-method?_ga=1.250619459.456450147.1385553478

I am currently working on a new v1.2.0 update which will contain improvements as well as a fix for this issue. In the meantime, this issue can be fixed by commenting out all lines in IMDraw.cs that use this conditional:

[System.Diagnostics.Conditional("IMDRAW_ENABLED")]

A fast way to do this in is to simply do a quick replace on the above line with:

//[System.Diagnostics.Conditional("IMDRAW_ENABLED")]

Once you do this, it should work as normal again.


_____________________________________________________________


Update: This issue should now be fixed in IMDraw v1.2.0 with the removal of the conditional attribute.

 

Hi there - how difficult would it be to transfer the monobehaviours into non-monobehaviours? Passing in references to the currently rendering camera for render callbacks is not an issue. I'd like to use this for HDRP but I'm not keen on adding scripts to my camera for debug visualization.

 

Hi. It would probably be easier to solve if you could still have IMDrawCamera on a game object in your scene somewhere. You would need to make a few changes to IMDrawCamera:
- Remove RequireComponent(typeof(Camera)) attribute from class.
- You would need to make the various Monobehaviour callbacks public, rename them so they don't get called automatically or ensure the game object is disabled and call them manually for the rendering camera. These include; Awake, OnDestroy, OnEnable, OnDisable, LateUpdate, OnPreCull, OnPostRender, OnGUI.
- Be sure that using SRP is enabled for the camera, since GL API is not supported for scriptable pipeline. I will be deprecating GL usage at some point in the near future.

If you are looking to completely change IMDrawCamera to not be a Monobehaviour altogether... that should be possible but would require a fair amount of changes. It would also make your life difficult when it comes upgrading to newer versions of IMDraw.

If you would like to discuss in more detail, please e-mail me imdraw@harveyc.net. Hope this helps.

 

@RV1 Hi, looking to purchase your asset, but just making sure: is this asset compatible with URP as released in v2019.3?

 

Yes. Support for the scriptable render pipeline (URP or HDRP) was added in v1.4.0. I have also recently tested it in Unity 2019.3.0f6. Should you encounter any issues after purchase, please drop me an e-mail and I will usually respond within 24 hours.

 

@RV1 Thanks. Would be cool if we could mention that in the release note so we won't be missing out other customers. Cheers

 

@RV1 Hi, would it be possible to make IMDraw automatically setup the manager and camera components? Maybe if I call one if the main draw functions and there is no manager found, just add one to the scene? I think the SRP checkbox could also be automatic. And would it possible to enable rendering in the scene view as well? Thanks!

 

It would be possible yes, however if there is more than one camera found it would have to somehow decide which one it should add the camera component to. I could perhaps just pick whichever one thats both active and highest depth?

Thanks for linking that method on detecting scriptable render pipeline, I will investigate. The reason why I went with a checkbox is that at the time I didn't feel there was a reliable and future proof way of detecting which rendering pipeline is active. The worst thing is that I try to make the detection automatic and it breaks when Unity release an update, leaving some users without a working version of IMDraw. Unity should have provided developers an easy method of detecting what graphics pipeline is active, but they sadly didn't really think about asset store developers who had to add support for multiple render pipelines.

 

I would expect the debug draws to be visible in any view by default.

No worries. It's an unfortunate time for asset developers.
https://forum.unity.com/threads/please-stop-with-the-package-release-breaking-fixes.869482/

 

I have had a think about the pipeline detection and what I will do for the next update is have a render pipeline option that replaces the SRP tickbox. The options will have auto-detect (default), legacy and SRP. That way its the best of both world and if the auto-detection fails for any reason, the user can manually select it.

I need to think about are having the manager and camera components automatically get added at runtime if you attempt to draw. I also need to think about how to make the system for controlling what cameras draw more flexible. In my own project I have multiple cameras use for rendering near vs distant objects and I only want debug rendering on the near camera. However, different people have different requirements and some may want the same debug rendering on all cameras. I will see if I can come up with something for the next update!

 

Sounds good!

Looking forward to it! The problem with using a MonoBehavior on the Camera component to configure settings is that this won't work well if you want to render in the SceneView too. Since most of the fields are settings, why not put them into the Project Settings window? Or maybe a ScriptableObject?

Looking forward to it!

 

Just another small note. I think you're ignoring the center property of colliders in the DrawCollider function. E.g. I think the position for a CapsuleCollider should be

colliderTransform.TransformPoint(capsuleCollider.center)

.
At least this works for me.

 

Ah good catch, I will make sure it goes into the next update.

 

I'm having trouble with ensuring IMDraw draws on top of 2D elements set on overlay canvases. If I set the sprite order to be -50 or so then it works fine and draws on top.

I have IMDraw.ZTest set to IMDrawZTest.Always but that doesn't seem to help.

Any way to change the layer or order that IMDraw draws to or compares from?

 

You will need to go to the IMDraw/Material folder and set the Render Queue property on the materials for arc, line, mesh and text so that the number is higher than the one used by the 2D elements. For example, if 2D elements are using render queue of 3000 (usually used for transparent materials) then set it to 3001. You may also need to set IMDrawZTest to Always if your 2D elements write to the depth buffer.

 

I think it is because we are using multiple sorting layers and Graphics.drawmesh is stuck on sortingLayer 0 from what I am reading. If I move my sprites to sortingLayer 0 then IMDraw will appear on top. Otherwise it gets placed behind, regardless of renderqueue and ztest.

 

I have tested putting a sprite renderer (with 0 order in layer) in a scene and after setting all IMDraw materials render queue to 3001 the IMDraw primitives are drawing over the sprite.

If you haven't already tried it, I would recommend using the frame debugger to help you understand how Unity engine is organising the draw order of your scene.

 

You are correct in that if you place your sprites on sortingLayer 0 (default) and order in layer 0 and IMDraw materials to render at 3001 then it will appear on top.

What I wrote above said we have objects on different sortingLayers. So if you add a new sortingLayer that is above Default then IMDraw will be covered. You can test this easily by using a SortingGroup monobehavior.

Also, like you mentioned, even if you do leave all of your sprites at sortingLayer default, you need to have their order within the layer to be 0 as well.

This won't work for us. We are using sortingLayers and orders within layers heavily. I think your asset is great for 3D projects, but probably not a fit for 2D orthographic ones as 3D sorting doesn't work nicely with 2D sorting.

Unless I'm missing something.

Either way, thanks for helping me debug. Appreciate it. And nice work on the asset.

 

Interesting. I did some reading up on this and it seems like sorting layers and ordering are properties available on all components derived from Renderer. This appears to control draw ordering internally within Unity. However this isn't exposed for Graphics.DrawMesh and therefore internally it is treated like Default layer at order 0. The render queue appears to have some effect, but even at 5000 I couldn't get the IMDraw primitives to render over a test sprite on a layer above Default. If you shift all of your sprite layers to be below Default, that will allow IMDraw to render over your sprites however I'm guessing that isn't a good fit for your project.

For now I will add a task to investigate adding control over sorting layer/order for IMDraw but this will likely involve refactoring to use MeshRenderer for mesh and line primitives.

 

Hello, did OP or anyone here test it with Unity 2020.1 URP 9 and 2020.2 URP 10 yet?

 

It has been tested on 2020.1 although not on the most recent version. I will test on those versions you have mentioned and let you know.

 

Apologies for the delay in testing. I wanted to test in all three render pipelines and I had trouble setting up HDRP since it has changed a lot since I last looked at it. I was unable to setup HDRP manually, so in the end I created a new project using the HDRP template and import IMDraw.

Here are the results of testing:

Unity 2020.1.17f1
Legacy RP - Confirmed working
Universal RP - Confirmed working
HDRP - Confirmed working

Unity 2020.2.1f1
Legacy RP - Confirmed working
Universal RP - Confirmed working
HDRP - Confirmed working

Note: if are you using URP or HDRP you need to enable Using SRP on IMDrawCamera.
If you have any problems, please drop me an e-mail. I aim to respond within 24 hours.

 

It would be super nice if you could make this asset work for single pass instanced VR. I already figured out that it is more than just upgrading the shader to support it but rather rewriting all the DrawMesh calls to use a Commandbuffer / ScriptableRenderContext instead (or use DrawMesh twice, once for each eye?). So I get that it is a lot of work, but I still would like to propose this feature to this otherwise very awesome asset

 

Hi, if you can link me any details/information of such implementation I can take a look. Unfortunately I don't own a VR kit so the problem is anything I implement I can't test but I have worked with VR devs in the past to implement changes they wanted in IMDraw.

 

Thanks for the quick reply. Okay what I did so far was add the appropriate macros to the shaders. That changed nothing so I started searching and found this thread in which someone says he is using DrawMeshNow and it only shows up in one eye which as for the same for the IMDraw Objects.

https://forum.unity.com/threads/graphics-drawmeshnow-vr-single-pass-stereo.712544/

he says commandBuffer.SetSinglePassStereo(SinglePassStereoMode.SideBySide) can fix the issue, but this is my only lead so far.

 

Hey, and thanks for this lovely asset!

I am using Unity 2021.2.4 / URP 12.1.1 and I have a problem with flickering in the editor's Game view when limiting the frame rate. I can reproduce it in an absolutely empty scene with nothing but an IMDrawManager (URP is correctly auto-detected), a camera with the IMDrawCamera component (default settings) and a simple script that limits the framerate and draws a box every frame:

Code (CSharp):

1. using UnityEngine;
2.  
3. public class DrawWireBox : MonoBehaviour
4. {
5.     void Start()
6.     {
7.         Application.targetFrameRate = 60;
8.     }
9.  
10.     void Update()
11.     {
12.         IMDraw.WireBox3D(Vector3.zero, Vector3.one, Color.cyan);
13.     }
14. }

With the camera at (0,0,-1) and identity rotation, this is what I see in the Game view of the editor:


When I set the frame rate to unlimited (0, which is the default), everything is fine. This also doesn't seem to occur when I build my game; in a build, IMDraw works fine even when limiting the frame rate. So, my guess is that it must be due to whatever shenanigans Unity is up to for limiting the frame rate in the editor. It seems as though Unity triggers re-renderings of the scene that IMDraw doesn't know about.

I decided to post this here because I had a pretty rough time figuring this out after only seeing flickering for no apparent reason. Is this something that can be fixed?

 

I will take a look this week, it's very likely new changes to either Unity or URP broke something.

 

Hi, I have reproduced the issue and I managed to fix it. The fix requires line and mesh primitives to be drawn using the scriptable render pipeline callback RenderPipelineManager.beginCameraRendering instead of drawing it in LateUpdate. If you need the fix immediately I can send you the changes. I will need to do some more work to investigate and test this more thoroughly before I publish this fix to the asset store.

 

Cool!
I can live with it for now, now that I know it's not a big issue and especially no issue at all in builds. So I'll wait for the proper update.

 

Thank you for reporting the issue and your patience

I will publish a new update with this issue fixed in early January.

 

I need to instantiate IMDraw from a script so tried the following...

Code (CSharp):

1. if (m_IMDrawManager == null)
2. {
3.     m_IMDrawManager = Camera.main.gameObject.AddComponent(typeof(IMDrawManager)) as IMDrawManager;
4. }
5. if (m_IMDrawCamera == null)
6. {
7.     m_IMDrawCamera = Camera.main.gameObject.AddComponent(typeof(IMDrawCamera)) as IMDrawCamera;
8.     IMDraw.SetTarget(m_IMDrawCamera);
9. }

However, on running I get the error "Object Reference not set to an instance of an object" in IMDrawCamera.cs:351 which is,

Code (CSharp):

1. m_LineComponent.Init();

This is called as part of the IMDrawCamera.Awake() -> IMDrawCamera.Initialise(). I cannot see within the IMDrawCamera code where m_LineComponent is initialised.

I'm sure I am missing something obvious! Is there a way to initialise IMDraw from script?

 

The reason why it's not called anywhere is because m_LineComponent is initialised when you add the IMDrawCamera component to the scene (via the editor inspector) since it is a serialized component. To fix this particular issue, add this before the line m_LineComponent.Init():

Code (CSharp):

1. if (m_LineComponent == null) m_LineComponent = new IMDrawLineComponent();

The disadvantage of instantiating these components by script is that you can't customise any of the parameters for IMDraw since the properties were designed to be edited in the inspector. However since I have seen other users do something similar I might see if I can make it friendly towards adding these components by script.

 

Thank you so much for such a quick and helpful response (which sorted the problem) and generally for such a useful asset.