Search Unity

  1. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Question Using BatchRendererGroup during editing

Discussion in 'General Graphics' started by EidLoi, Sep 10, 2023.

  1. EidLoi


    Nov 20, 2019

    I have a BatchRendererGroup-based detail system (adding grass, dirt, etc. to our tile grid surface) which works relatively well, except during editor startup and domain reloads. I am using a MonoBehaviour to contain it with the ExecuteInEditMode on top and the AssemblyReloadEvents.beforeAssemblyReload to dispose of the BRG during domain reloads.

    Main issues:
    - I have to delay startup in the editor via a coroutine since the graphics buffer for the batch fails to be uploaded to the GPU the moment the editor starts (= crushes the editor instantly). There are no issues in the build or after the initial domain reload.
    - During domain reload I can't dispose by BRG wrapper properly. It seems that it is too late to dispose persistent Native allocations (that I use for related caches) in the "beforeAssemblyReload" callback.
    - During runtime the unsafe allocations made for the draw commands are not disposed properly after a while. I can't exactly tell what triggers this, but as I move the camera it just starts to be an issue. The number of visible instances / commands are roughly capped by the culling, so it's not related to that.

    What I am looking for the the proper way to integrate a BRG in a way it works in the editor and runtime as well.
    Ideally a callback that is invoked in the editor when it is safe to create large batches (which is the whole point of a BRG) and a callback invoked specifically before domain reload when it is still safe to discard native arrays/lists. This, OR something similar to a Custom Pass, that plugs into the rendering cycle, but instead of the update, it plugs into the init/destroy pipeline phases.

    I would also be fine with two separate code paths for the editor and the player, so long as they are mutually exclusive (to avoid double drawing details).

    All in all the current solutions is more like a hack than a proper system. It is critical that we can see the rendered content during edit time, so the pure play-time MonoBehaviour is not an option.