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

Graphics.DrawMesh/DrawMeshInstanced fundamentally bottlenecked by the CPU

Discussion in 'General Graphics' started by jbooth, Sep 2, 2016.

  1. Prodigga

    Prodigga

    Joined:
    Apr 13, 2011
    Posts:
    907
    @DanMeyer009 if it is coming in straight from your modelling app, then your individual grass meshes wont batch because they are (probably) seen as unique meshes. (even if they are visually identical). Manually instancing a single one at each empty position like you described will probably fix your issue.
     
  2. DanMeyer009

    DanMeyer009

    Joined:
    Sep 22, 2013
    Posts:
    18
    @Prodigga When I export my meshes they all link to the same mesh instance in blender. It keeps my fbx files much smaller the link is maintained upon import into Unity as each objects renderer still point to the same mesh. Ran some quick tests using the list<Matrix4> overload and gave me some great improvements in frame time.
    -First screen grab is from using individual Gameobjects (How I was originally doing it). Still batches a significant amount. Both are using identical materials with 10k instances of the object.
    PS...ignore the half finished models....
    GOInstanced.jpg
    -Second screen is when I'm using the DrawMeshInstanced. Note that my total saved batches skyrocket. Read that using DrawMeshedInstanced doesn't respect culling so everything gets rendered at once (Actually keeps my fps stable because it's predictable and has the added benefit that I don't have to limit the draw distance).
    ManuallyInstanced.jpg

    I do have my doubts that I'm using drawmeshinstanced correctly however. Since I am trying to render 10k objects I attempted to use a single list and got the error that I can only call 1023 instances in one shot so I had to split up my list and call drawmeshinstanced 10 times with 10 different lists to draw them all. Please tell me there is a better way to do that. So far I have to say this is pretty awesome. I never expected that much of an improvement. If anything it just made me have extremely high hopes for the new terrain tools. Unity Team keep up the good work!
     
  3. zeroyao

    zeroyao

    Unity Technologies

    Joined:
    Mar 28, 2013
    Posts:
    168
    @DanMeyer009 Thank you for sharing your results. It is our limitation on this 1023 instances. It's needed to split your list to meet this requirement.
     
  4. Prodigga

    Prodigga

    Joined:
    Apr 13, 2011
    Posts:
    907
    @zeroyao I noticed that this was automatically handled in Unity 5.4. I can call DrawMesh thousands of times, each DrawMesh call using the same mesh/same material/different MaterialPropertyBlock's, and in the FramDebugger I could see the there were multiple Batched (Instanced) operations to draw my thousands of meshes. Take the exact same scene and bring it to 5.5, I need to start using DrawMeshInstanced and I have to populate my own MaterialPropertyBlock arrays 'manually', but my scene wont render because I now 'exceed the 1023 limit'.

    A step backwards if you ask me?
     
  5. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    Absolutely not, since if you use 'DrawMesh' it's still automatically batched (or it should be). But with 'DrawMeshInstanced' you have finer control and you can make ABSOLUTELY sure that you ARE using instancing.

    Even the fact that you told us that you are exceeding the '1023' limit smells fishy to me. You should break down your scene into chunks, check those for visibility and only submit your visible meshes. If you are not interested in doing that just use 'GameObjects'.

    But if you are doing what @DanMeyer009 is doing, I CAN assure you that you are doing it WRONGLY. For a working grass/tree system check out my systems. Even with millions of grass/trees you should not exceed more than 3000-5000 visible grass blades per frame, that can be sent to the GPU in chunks.

    For some concrete examples check out my grass/tree system (the tree system is open-source). I would also recommend siggraphs and other research paper (I would also highly recommend the SpeedTree sdk documentation). You probably want to implement a tree/grass/terrain detail or want to render many animated characters (am I correct?) and there is plenty of info for that, using instancing.

    I can assure you that this time, the Unity guys did an awesome job with the instancing, because I know how my grass/tree systems worked before the instacing support. At the moment I got at least a x5 (up to 10-15x) performance improvement.
     
  6. Prodigga

    Prodigga

    Joined:
    Apr 13, 2011
    Posts:
    907
    Slow down, what I mean is why do I need to be told about a 1023 limit? Let me submit 3000 instances and, on the engine side, submit them to the GPU in lots of 1023 for batching. I'm still 'absolutely sure' of what I am instancing.
     
    hippocoder and DanMeyer009 like this.
  7. Prodigga

    Prodigga

    Joined:
    Apr 13, 2011
    Posts:
    907
    I am using instancing in my game Along Came Humans, see image bellow:



    Each 'hex' tile on the planet is made up of 6 triangle submeshes - "Triangle Tiles". As seen in this image (ignore the animation, I am just reusing this gif to show the triangle tiles)

    So, I have hundreds (and on large planet, thousands) of visible triangle tiles. The tiles on the planet do not change very often, but they *can* change at any time for any given reason. For this reason, static batching isn't an option because I would have to enter the batched planet mesh and insert/remove 'tiles' from the giant mesh and resubmit the whole thing to the GPU every time a change was made (which is slow as hell and causes a stutter every time the player does something, like place a structure on the surface).

    In 5.4, every update my 'PlanetTilesetManager' script iterates every hexagon on the planet surface, and draws the appropriate 'triangle tiles' for each 6 of the traingles in every hex using DrawMesh.

    If I am using a GPU Instancing compatible shader, everything is automatically Instanced. It doesn't matter how many elements I submit via DrawMesh, and the order in which I submit them doesn't matter either. Unity handles everything. It groups like meshes together, and draws them in 1023 'blocks' for me.

    In 5.5 this doesn't work anymore. Now I am forced to do this weird micromanagement that I didn't need to worry about before and I honestly don't see what advantaged this level of 'control' gives me.

    PS This is also why I am so excited for DrawMeshInstancedPersistant -the triangle tiles will be 'static' 'most of the time' on the surface of the planet, so it is a waste for me to have to call DrawMesh on everything every frame.
     
  8. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    If that is the case, you must know that even in 5.5 it still 'should' be automatically instanced even if you are using 'DrawMesh', it should be exactly the same like 5.4. The 'DrawMeshInstanced' is only and addition and automatic engine batching 'should' still happen. (I haven't read anywhere that there will be modification to that part, in the release notes...)

    If that is not the case I strongly suggest that you quickly submit a bug report before 5.5 is out so that the fix will be available in the final release of 5.5.

    I made many reports at key rendering features and they all fixed them all, so you should do the same.
     
  9. iivo_k

    iivo_k

    Joined:
    Jan 28, 2013
    Posts:
    312
    Making one call DrawMeshInstanced call per an array of 1023 objects is so much faster than making 1023 calls to DrawMesh. I agree that it'd be simpler if you could just submit an array/list as large as you want and Unity would take care of it, but it's not that much of a drag to handle it manually. If it was done automatically, there could be extra allocations and whatnot when the arrays would have to be split each frame.
     
  10. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    26,726
    I agree with the sentiment in the thread that if there's no downside, draw instanced should take any amount and do internal splits every 1023, as a feature request but only if there are no downsides.
     
    Stardog, arnoob, awesomedata and 2 others like this.
  11. DanMeyer009

    DanMeyer009

    Joined:
    Sep 22, 2013
    Posts:
    18
    @Assembler-Maze Ya that was strictly for testing purposes, I wouldn't be drawing an entire scene's worth at one time. And I have to second that internal batches would be nice but definitely not necessary. I've already been thinking about ways that I can implement a quick and dirty visibility system for my own culling. Great times are ahead.
     
    Assembler-Maze likes this.
  12. zeroyao

    zeroyao

    Unity Technologies

    Joined:
    Mar 28, 2013
    Posts:
    168
    The main reason is that arrays in MaterialPropertyBlock can only handle 1023 elements. It is not obvious if you don't use per-instance data via MaterialPropertyBlock. There can be two solutions: one is to allow the overload of no MaterialPropertyBlock, to split matrix array/list automatically; The other is to somehow extend the bits used to describe the array length in MaterialPropertyBlock, to allow longer arrays. But they are both imperfect to me as the underlying constant buffer approach can't handle arbitrarily long batches.

    To save memory copyings under the hood, you'd probably better to further align the batch size with your instancing shader - that the "maxcount" by default used for an instanced shader is 500. I haven't updated the documentations for this part yet, but basically you can control the batch size by using "#pragma instancing_options maxcount:{a number}". 500 is chosen to make sure 2 matrices (object to world and world to object) can stay in one 64k constant buffer.

    In 5.6 we will have DrawMeshInstancedIndirect, that takes another approach - to allow you populate instances from a ComputeBuffer, including matrices, thus you don't even need to pass Matrix4x4 array/list from C#, and you are not limited by constant buffer size anymore. Meanwhile, we are actively researching if using ComputeBuffer in general would be a better solution for all kinds of instancing in Unity. If so we will probably migrate to ComputeBuffer instancing (not necessarily to happen in 5.6).

    So until then...I guess we are still stuck with maximum 1023 instances per draw.
     
    RG_Keith and Assembler-Maze like this.
  13. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    'DrawMeshInstancedIndirect' would be very very nice indeed. Having to set those world matrices and pass them in, cause somewhat of some CPU overhead when drawing my grass, having to copy back and forward those matrices. I only need a Vector3 world position, and computing the scale and rotation procedurally on the GPU.

    And for the maxcount of 500, i'd quote the manual:

    "D3D constant buffers have a maximum size of 64KB. For OpenGL, it’s usually 16KB. You will reach this limit if you try to define too many per-instance properties. The shaders may fail to compile or, even worse, the shader compiler might crash. To work around this, you have to balance between the size of the batch and the size of per-instance properties. Defining UNITY_MAX_INSTANCE_COUNT with an integer before including any .cginc file allows you to limit the maximum number of instances an instanced draw call can draw. This allows for more properties per instance in the instance constant buffer. You can achieve the same result when using a surface shader with #pragma instancing_options maxcount:number. The default value of this max instance count is 500; for OpenGL, the actual value is one quarter of the value you specify - so 125 by default."

    So, if we target OpenGL we should take that maximum '125' batch size instead of '500'.
     
  14. zeroyao

    zeroyao

    Unity Technologies

    Joined:
    Mar 28, 2013
    Posts:
    168
    That's the exact scenario we expected for this API.
     
    DanMeyer009 and Assembler-Maze like this.
  15. LennartJohansen

    LennartJohansen

    Joined:
    Dec 1, 2014
    Posts:
    2,384
    Screenshot 2016-11-20 18.28.18.png Screenshot 2016-11-20 18.28.36.png
    I did a protoype grass renderer based on the DrawMeshInstanced with lists and the results is great. Low cpu use and fast rendering.
     
  16. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,126
    Coming from a traditional 2D pixel-art animation background (and being more of an artist than a programmer), I haven't even scratched the surface of what shaders can do for me just yet, but I know just enough to know something like this might be useful to what I'd like to do.

    To be clear, I'm aiming to optimize drawing a huge number of terrain-tile prefabs (similar to what minecraft does with voxels) in various places in the world onscreen. This seems like it would be useful to some extent for that. Am I correct in my thinking on this?

    After reading over the thing about C#, shaders, lists, and 1023 instance limits, I'm still trying to understand exactly what type of setup code I would need to draw a (virtually) unlimited number of prefabs with this? I would also need to procedurally rotate some of these prefabs before drawing them.

    Could this even be used for that? Would I need a custom shader?
     
    Last edited: Dec 11, 2016
  17. LennartJohansen

    LennartJohansen

    Joined:
    Dec 1, 2014
    Posts:
    2,384
    This would work good for your use. The 1023 limit is only per call of the DrawMeshInstanced function, you can do this as many times as you want. You can make lists of all your meshes, one list for each meshtype. and draw them like this.

    if you need some of them rotated just rotate the Matrix4x4 in the list.
    public static Matrix4x4 TRS(Vector3 pos, Quaternion q, Vector3 s); to make the position, rotation and scale of your drawn mesh.
     
  18. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,126
    @LennartJohansen

    Thanks for your quick response! That clarifies things a lot.

    Totally new to the Matrix4x4 thing though, and how it would relate to, say, a grid of tile prefabs, so may I go slowly and clarify first the steps I'd take to best-optimize something like this?

    Alright, so if I'm understanding this correctly, the correct approach would be something like the following (in a new C# script):

    1. (Prepare all prefabs for drawing by removing their MeshRenderer components in editor?)
    2. Get all the prefabs in the view of the camera
    3. Add these prefabs to smaller lists of 1023 instances each
    4. Add these smaller lists to a large list
    5. In the OnPostRender function, use DrawMeshInstanced to draw the non-rotated prefabs from each list, pulling from the larger list
    6. Use a Matrix4x4 and DrawMeshInstanced to draw the rotated tiles

    Does that sound correct?

    I'm not sure if that would cover the optimizations that I would need, so any further advice would be great!
     
    Last edited: Dec 11, 2016
  19. ShilohGames

    ShilohGames

    Joined:
    Mar 24, 2014
    Posts:
    2,835
    Think of Matrix4x4 as something you fill with data to pass to the graphics API without really worrying about how it works under the hood. I created a global array of Matrix4x4 in my C# class and I reuse it every frame. I send the latest data into my array of Matrix4x4 and then submit that using DrawMeshInstanced.

    To use DrawMeshInstanced, you do not think in terms of prefabs and camera views. Think in terms of meshes and locations in the scene for those meshes. If you want to, you can concern yourself with camera view and implement your own custom culling to reduce the number of items to send to the graphics layer, but you don't really need to do that.

    In my case, I have a C# class that manages each type of projectile in my game. There are not GameObjects and prefabs for the individual projectiles. My C# class has an array of a custom struct that I created for tracking location and rotation of each projectile, and my C# class computes movements and collisions for projectiles each frame.

    Here is a video of my game using Graphics.DrawMeshInstanced to render all of the projectiles in my scene:


    I intentionally cut my projectiles into groups of 500 for sending them into the API. Groups of projectiles (such as the 3 large blue lasers from heavy turrets) are pre-baked into a single mesh to further improve performance.
     
    jimCheng likes this.
  20. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,126
    @ShilohGames
    That's quite a cool-looking game you got going on there! Totally loving it. :D

    Alright, I'm a little slow here, but I /think/ I'm following more now -- As I'm understanding it, what you're saying is that a Matrix4x4 is, in this particular case, a single transform's positional/rotational data of whatever mesh instance in your scene you want to draw, right? You store a limited (large) amount of these, then update/display this data each frame?

    Still not sure if I'm following correctly, but I hope that's correct.

    I'm still unclear, though, on how to use this in practice. I'd highly appreciate some example code showing how to use this DrawMeshInstanced command in the proper context if you could please spare the time.

    Right now, I'm struggling with how to handle the collision data with this sort of thing being used as terrain. What could I do to optimize it in terms of collisions for a pretty decently-sized world? How are you handling collisions with your lasers? That seems like a lot of overhead, even if you are doing it all through code!
     
  21. ShilohGames

    ShilohGames

    Joined:
    Mar 24, 2014
    Posts:
    2,835
    Each laser uses a raycast to look ahead about a frame's worth of distance to check for a collision. That is true no matter how a laser is implemented. I would need to do that if I set up an instancing pool (like in my recent video), but I would also need to do that if I set up individual game objects for each projectile and managed those with an typical object pool. Either way, each laser needs to do a raycast to look ahead for a collision. If a collision is found, there is logic for applying damage to the object the laser was running into.

    There is no collision check for things hitting a laser, though. Lasers cannot be shot out of the air by other lasers. As such, there is no need for a collider or rigidbody on individual lasers.

    Since lasers don't need to accept a collision, a laser (in my game at least) only needs a position, rotation, an a velocity vector. I can store that data for each laser in a struct and then create an array of that custom struct. All of my lasers can be defined that way. Then each frame, my code processing movement and collision checks for each laser, updating the data within the array of the struct as it goes.

    Then to render the lasers, I wrote additional code to write the relevant data into an array of Matrix4x4. I use the SetTRS method on Matrix4x4 to set the position, rotation, and scale for each item in the array I wish to draw. Then submit that to the graphics API through DrawMeshInstanced.

    To make it simpler, I don't worry about keeping the items in the laser projectile array lined up with specific items in the array of Matrix4x4. I use the array of Matrix4x4 as a re-usable submission blob. When I need to submit fewer than 500 items, I still use my existing 500 item array but I define how many items to accept in the DrawMeshInstanced command. This lets me re-use the same array every frame without any additional allocations/deallocations.

    When I need I have more than 500 lasers, I submit the array of Matrix4x4 multiple times. I submit a full 500 instance batch, then I re-use the array of Matrix4x4 for the remainder of the group.

    This stuff works great. I have scenes with thousands of lasers flying around where I easily get over 100 FPS.
     
    Last edited: Dec 13, 2016
    mkracik, awesomedata and jason-fisher like this.
  22. ShilohGames

    ShilohGames

    Joined:
    Mar 24, 2014
    Posts:
    2,835
    If you need to use a typical object pool and a bunch of GameObjects, you can. For example, if you need to have collisions and physics working for all of the objects, you can do that. This will not perform quite as well as my instancing pools for my lasers, but this would give you the rendering benefits of DrawMeshInstanced while still being able to have game objects with colliders and rigidbodies.

    What you would do is run a typical object pool, but remove the mesh renderer from all of the objects in that pool. The objects would be invisible, but could still contain colliders and rigidbodies. Then in your object pool manager class, enumerate all of the objects in the pool once per frame and grab the location and rotation information from the game object transforms. Use the location and rotation information to populate your array of Matrix4x4 that you submit using DrawMeshInstanced once per frame.
     
    awesomedata and jason-fisher like this.
  23. bpears

    bpears

    Joined:
    Aug 23, 2012
    Posts:
    249
    Has anyone done a performance comparison on using
    CommandBuffer.DrawMeshInstancedIndirect VS the Graphics.DrawMeshInstance @1023 increments? Is there a big performance difference or is one just easier than the other? I wonder if the Graphics.DrawMeshInstance calls of the same mesh/instance combines the call for all the 1023 sets or if each is its own..
     
  24. bpears

    bpears

    Joined:
    Aug 23, 2012
    Posts:
    249
    Also, as mentioned earlier, persistence in the instance drawing would be great. I want to be able to tell unity exactly when to stop persisting and take a new set of draw info so that it isn't constantly dumping info that will be the same for some time.
     
  25. bytewav

    bytewav

    Joined:
    Jan 8, 2013
    Posts:
    5
    The feature is absolutely amazing for my case and help me get back a lot of memory. I can't wait to get the persistent version.
     
    jason-fisher likes this.
  26. spraycanmansam

    spraycanmansam

    Joined:
    Nov 22, 2012
    Posts:
    247
    Agreed! Any news on the persistent feature @zeroyao?
     
  27. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    And not only the persistent version.

    There could be done significantly better improvements like DrawMultiMeshInstancedIndirect (OpenGL equivalent glMultiDrawArraysIndirect) where you can pack multiple meshes inside a single VBO and send multiple commands (DrawIndirectCommand with a instance count, a base vertex, a base instance and a vertex count) with one draw call.

    But I think we'll have to wait quite a lot for that, it's clear that those not being useful for mobile they're on the secondary requirement list. After all for 2017 mobile got about 30 bills in profit while PC got 20 bills in sales. Why bother with pc with those mobile scores...
     
  28. zeroyao

    zeroyao

    Unity Technologies

    Joined:
    Mar 28, 2013
    Posts:
    168
    Greetings all,

    We had a discussion about this and we think that the purpose of introducing a new set of "persistent draws" aligns quite well with our new BatchRenderer system. It's like a generalized terrain tree system, where you can tell the component to render a bunch of instances - not necessary trees - in a very compact format, and the component will take care of culling, batching and LOD for you. I know we have been talking about this for a long time without actual progress (because we decided to focus on improving and stabilizing the instancing feature before we move on - instancing will be the corner stone of the new renderer), but I can assure you that we will get it started in 2017.

    Cheers!
     
  29. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    Thank God!

    Something like Unreal's 'Instanced Static Actor' (if i can remember correctly) Component?
     
  30. XaneFeather

    XaneFeather

    Joined:
    Sep 4, 2013
    Posts:
    90
    I'm literally flailing in ecitement. Can't wait! Any rough ETA!?
     
  31. bpears

    bpears

    Joined:
    Aug 23, 2012
    Posts:
    249
    Sounds wonderful. If you guys could keep the non-Unity (aka mesh) Terrain in mind for this too, it would be appreciated.
     
  32. Prodigga

    Prodigga

    Joined:
    Apr 13, 2011
    Posts:
    907
    Please please please consider that we might want to add or remove things from the batch at run time, an efficient way to do this without repopulating and resubmitting lists of data containing thousands of items would be grand. Maybe a method to append items and a method to remove a range of items from the current batch so we don't have to resubmit all our data and incur the marshaling performance cost.

    Everything I'm hearing points towards a set and forget system which is good for some cases (grass, a field of asteroides, etc) but sounds like it'll be unworkable for anything that needs items added and removed from the persistant instance batch. (Ie Demolishing or placing some structures in a strategy game that is rendering a city with hundreds of structures instances, for example)
     
  33. zeroyao

    zeroyao

    Unity Technologies

    Joined:
    Mar 28, 2013
    Posts:
    168
    Yes it is designed to work with both Mesh and Unity Terrain.

    Heard.

    There is no ETA yet. We haven't started actual work on it. Will post some custom builds in the forum once there is something to try out.
     
    Flurgle, Prodigga and bpears like this.
  34. Prodigga

    Prodigga

    Joined:
    Apr 13, 2011
    Posts:
    907
    Thanks zeroyao, looking forward to trying it out when it is ready! Good luck!
     
    Flurgle likes this.
  35. Flurgle

    Flurgle

    Joined:
    May 16, 2016
    Posts:
    389
    Good luck zeroyao!

    (I'd like to see some of Unity's internals exposed on Bitbucket or Github, perhaps we could get these sort of issues sorted out way faster and take the load off of the Unity team.)
     
    jimCheng, mgear and Assembler-Maze like this.
  36. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    Freaking give us the code!
     
  37. zeroyao

    zeroyao

    Unity Technologies

    Joined:
    Mar 28, 2013
    Posts:
    168
    Yes we will open source the C# part of the new system when we develop it.
     
  38. iosif_chesca

    iosif_chesca

    Joined:
    Mar 22, 2016
    Posts:
    3
    AWESOME!

    This feature really got me excited (we need it)! Good luck guys!
     
    Flurgle likes this.
  39. Diab1O

    Diab1O

    Joined:
    Mar 31, 2013
    Posts:
    317
    Hello!

    Why not work Frustum Culling with DrawMeshInstanced (frustum culling before Batching)?
    It's really do?
    You can make it optionally when you call the function.
    I think it will improve performance.

    I can do my FrustumCulling, but I do not know how to solve this problem: http://answers.unity3d.com/questions/1287755/how-can-i-determine-that-a-invisible-object-can-ca.html

    Sorry for my English.
     
    Assembler-Maze likes this.
  40. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    Yea, we should have the frustum culling optional (just as an extra parameter) since we really want to have full control over how we instance stuff.

    And yes, we should also have the possibility to see if an object is casting shadows inside a frustum. I am still trying to solve that issue, but I am kinda short on time and I found some (bad) workaround.

    The complete solution to shadow caster culling is stated here, just that I don't have time to implement it (at the moment):
    http://www.terathon.com/gdc06_lengyel.pdf

    Maybe someone is luckier.
     
  41. Flurgle

    Flurgle

    Joined:
    May 16, 2016
    Posts:
    389
  42. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    26,726
    frustum culling may be faster on gpu, if Unity is testing this...
     
  43. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    Yea, some other guys out there use a full GPU driven pipeline while others moved certain rendering systems that require a lot of culling on compute (anvil/frostbite/unreal).
     
  44. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    26,726
    Yes so we would probably be best of waiting for that. I'm sure Unity knows we want it.
     
  45. darren-walker

    darren-walker

    Joined:
    Apr 7, 2015
    Posts:
    4
    Thanks for this. I was getting an intermittent 500 ms lag spike from GC in my render routines due to Unity's allocation of these planes. Now I am completely allocation free. Why are there not public NoAlloc methods for these types of things? This should be a standard practice, IMO.
     
  46. grizzly

    grizzly

    Joined:
    Dec 5, 2012
    Posts:
    302
    Indeed and thankfully this will now feature in the next release. From the 2017.3.0b7 release notes... https://unity3d.com/unity/beta
    :cool:
     
  47. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,126
    I hate to bother anyone here, but could someone please provide an example of using this to, say, draw 100000 cubes/gameobjects on screen in various locations? Say these cubes were already placed in the scene, but you just want to replace their drawing with an instanced version -- what method could be used to do this efficiently?

    DISCLAIMER:

    I *get* the concept, but the biggest issue I have is that if I just call the function in a for loop and use Matrix4x4.SetTRS() as an argument, changing only that to match all instances in my scene I'd need to call, I can't understand how calling that in a for loop would lead to much performance gain since I'm still using the CPU for every instance... Would anyone be willing to clarify?

    Also, what about depth-sorting -- is this handled internally, or would I have to handle that manually too?
     
    Last edited: Oct 31, 2017
  48. Atair

    Atair

    Joined:
    Oct 16, 2015
    Posts:
    42
    is there any news on this? Every time i google i end up in this thread..
    Also in regards to the SRP?
     
    joshcamas and Damjan-Mozetic like this.
  49. Arycama

    Arycama

    Joined:
    May 25, 2014
    Posts:
    127
    Bump.

    Any update? I'd like to use Graphics.DrawMesh for some custom chunk-based rendering such as terrain, voxels, grass, trees etc. This is targeted at mobiles without instancing support, so being able to use Graphics.DrawMesh without unnecessary overhead would be very useful.
     
  50. Flavelius

    Flavelius

    Joined:
    Jul 8, 2012
    Posts:
    772
    I'd be interested too
     
unityunity