Skip to content
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

Closed
griffin2000 opened this issue Mar 28, 2019 · 14 comments
Closed

Support for hardware instancing #1056

griffin2000 opened this issue Mar 28, 2019 · 14 comments
Assignees
Labels
enhancement New feature or request

Comments

@griffin2000
Copy link
Contributor

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).

@romainguy
Copy link
Collaborator

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.

@romainguy romainguy added the enhancement New feature or request label Mar 28, 2019
@griffin2000
Copy link
Contributor Author

Yeah my thought was RenderableManager::Builder::instancedGeometry() would be exactly analogous to RenderableManager::Builder::geometry() except it would take instance data and indices.

@roxlu
Copy link
Contributor

roxlu commented Jun 17, 2020

Any progress on this? Missing a feature like this (together with LOD).

@romainguy
Copy link
Collaborator

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).

@roxlu
Copy link
Contributor

roxlu commented Jun 17, 2020

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.

@romainguy
Copy link
Collaborator

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.

@roxlu
Copy link
Contributor

roxlu commented Jun 17, 2020

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.

@romainguy
Copy link
Collaborator

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.

@prideout
Copy link
Contributor

For what it's worth, option 2 is supported by gltfio as of #2607.

@roxlu
Copy link
Contributor

roxlu commented Jun 17, 2020

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.

@Maria098
Copy link

Maria098 commented Aug 2, 2020

@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.
This is using OpenGL rendering on Windows desktop.

Exception

@steve3d
Copy link

steve3d commented Jan 11, 2022

Almost 2 years , any updates or roadmap of this? We also need hardware instancing function. I think this should be a standard feature.

@romainguy
Copy link
Collaborator

I agree but this has unfortunately not been a priority for us. We don't have any ETA on this for now.

@pixelflinger
Copy link
Collaborator

manual and auto instancing are now supported.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

7 participants