-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for hardware instancing #1056
Comments
It's something we'd like to do eventually but it's not a priority right now. @pixelflinger can probably comment on what a proper API would be. What you're describing sounds about right. I assume instancing would be per-primitive inside a renderable. |
Yeah my thought was RenderableManager::Builder::instancedGeometry() would be exactly analogous to RenderableManager::Builder::geometry() except it would take instance data and indices. |
Any progress on this? Missing a feature like this (together with LOD). |
You can share the vertex and index buffers and create multiple renderables but we don't have hardware instancing at this time (which is mostly about saving CPU time in the driver at least on mobile). |
Hardware instancing is necessary when we want to render things like trees. Last time I tried to render many objects I ran into an isse related with the command buffer size #2057. Creatting one mesh from it gives me a huge mesh ~2GB of OBJ data. (I can lower the poly count a bit by reducing the quality). Having instanced rendering will overcome all these workarounds. |
The command buffer size issue can be fix. I don't understand your comment about 2 GiB of obj data. You could load 1 tree and create many renderables from a single vertex/index buffer pair. It won't generate 2 GiB of data. Hardware instancing does basically that except you generate fewer CPU draw calls. |
Ah I meant that currently there are 2 solutions: 1) to reduce CPU overhead we can create one large mesh that duplicates the vertex/index data. So less calls or 2) we can do what you propose addings many renderables which will have an impact on CPU performance. |
That's correct. Although if you target desktop 2) may not be that bad depending on how many draw calls you have. 2) is particularly expensive on mobile devices. Anyway we want to add hardware instancing (and finish support for LODs), it's just not something we have been able to do so far. |
For what it's worth, option 2 is supported by gltfio as of #2607. |
Thanks @romainguy and @prideout. I accidentally ran into this today as my importer currently doesn't support 2 yet which made me look what the current status of this was. I'll add this feature to my importer. |
@romainguy @roxlu @pixelflinger @griffin2000 We seem to have a similar problem and wondering whether you will have any advice. We are not rendering trees but render clothes with a lot of stitches - thousands of tiny instances of shapes. Say we have 10 types of stitch shapes consisting of 50-200 vertices each that are each instanced thousands of times. We use the same vertex and index buffers and create separate renderable for each instance with pointers to the same buffers and different transformations. And on clothes that have many instances of such shapes we get memory exception. Reducing number of stitches resolves the problem. |
Almost 2 years , any updates or roadmap of this? We also need hardware instancing function. I think this should be a standard feature. |
I agree but this has unfortunately not been a priority for us. We don't have any ETA on this for now. |
manual and auto instancing are now supported. |
Is your feature request related to a problem? Please describe.
We require hardware instancing, to reduce the draw calls required for large repeated geometry.
Describe the solution you'd like
We'll probably be adding this feature. Are there existing plans for this we could follow? (or just wait for :) ) Otherwise our first thought is to add a instancedGeometry() call to the renderable builder, that will take InstanceDataBuffer (similar to vertex buffer), and a per-instance index buffer. The shader side will be more involved, but seems doable.
Describe alternatives you've considered
No real alternative, though we'll probably just emulate with multiple instances on the CPU side (though that is tricky as it breaks the abstraction between transforms/instances and geometry)
OS and backend
Should be implementable on all the platforms (though initially we'll add to Metal and WebGL).
The text was updated successfully, but these errors were encountered: