Search Unity

  1. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

[UPDATED] Immediate Mode Draw

Discussion in 'Assets and Asset Store' started by RV1, Apr 13, 2016.

  1. RV1

    RV1

    Joined:
    Nov 18, 2012
    Posts:
    56


    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 and trivial to set up.
    - 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 lines/vertices that can be rendered.
    - Gizmo 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.
    - Supported in Unity 5.0.0f4 and upwards.
    - Support for scriptable render pipeline (both LWRP and HDRP).
    - Intended for use on all platforms (desktop, mobile, web GL and more).
    - Dedicated support.


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

    _____________________________________________________________________

    F.A.Q

    Q: What does this API offer over Unity Debug and Gizmo draw functions?
    A: Functions like Debug.DrawLine only draw in the editor scene view. Immediate Mode Draw brings similar but extended functionality for in-game usage. Please check out the API reference 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.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.

    - Deprecate usage of GL API for line rendering.
    - 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 job system.
    _____________________________________________________________________

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

    Thank you for your interest!
     
    Last edited: Feb 26, 2020
    alexanderameye likes this.
  2. RV1

    RV1

    Joined:
    Nov 18, 2012
    Posts:
    56
    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.

     
  3. jeffweber

    jeffweber

    Joined:
    Dec 17, 2009
    Posts:
    588
    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
     
  4. RV1

    RV1

    Joined:
    Nov 18, 2012
    Posts:
    56
    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?



     
  5. jeffweber

    jeffweber

    Joined:
    Dec 17, 2009
    Posts:
    588
    Sure, that's fine. Thx.

    Appreciate the quick resolution...

    -Jeff
     
  6. RV1

    RV1

    Joined:
    Nov 18, 2012
    Posts:
    56
    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.
     
    Last edited: Jul 1, 2016
  7. RV1

    RV1

    Joined:
    Nov 18, 2012
    Posts:
    56
    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.
     
    Last edited: Feb 15, 2017
  8. one_one

    one_one

    Joined:
    May 20, 2013
    Posts:
    552
    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.
     
  9. RV1

    RV1

    Joined:
    Nov 18, 2012
    Posts:
    56
    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.
     
    one_one likes this.
  10. ryo0ka

    ryo0ka

    Joined:
    Sep 27, 2015
    Posts:
    34
    @RV1 Hi, looking to purchase your asset, but just making sure: is this asset compatible with URP as released in v2019.3?
     
  11. RV1

    RV1

    Joined:
    Nov 18, 2012
    Posts:
    56
    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.
     
    ryo0ka likes this.
  12. ryo0ka

    ryo0ka

    Joined:
    Sep 27, 2015
    Posts:
    34
    @RV1 Thanks. Would be cool if we could mention that in the release note so we won't be missing out other customers. Cheers
     
  13. DrummerB

    DrummerB

    Joined:
    Dec 19, 2013
    Posts:
    96
    @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!
     
  14. RV1

    RV1

    Joined:
    Nov 18, 2012
    Posts:
    56
    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.
     
  15. DrummerB

    DrummerB

    Joined:
    Dec 19, 2013
    Posts:
    96
    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/
     
  16. RV1

    RV1

    Joined:
    Nov 18, 2012
    Posts:
    56
    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!
     
  17. DrummerB

    DrummerB

    Joined:
    Dec 19, 2013
    Posts:
    96
    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!
     
  18. DrummerB

    DrummerB

    Joined:
    Dec 19, 2013
    Posts:
    96
    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.
     
  19. RV1

    RV1

    Joined:
    Nov 18, 2012
    Posts:
    56
    Ah good catch, I will make sure it goes into the next update.
     
  20. ickydime

    ickydime

    Joined:
    Nov 20, 2012
    Posts:
    66
    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?
     
  21. RV1

    RV1

    Joined:
    Nov 18, 2012
    Posts:
    56
    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.
     
  22. ickydime

    ickydime

    Joined:
    Nov 20, 2012
    Posts:
    66
    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.
     
  23. RV1

    RV1

    Joined:
    Nov 18, 2012
    Posts:
    56
    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.
     
  24. ickydime

    ickydime

    Joined:
    Nov 20, 2012
    Posts:
    66
    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.
     
  25. RV1

    RV1

    Joined:
    Nov 18, 2012
    Posts:
    56
    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.
     
unityunity