Hi all -
I’ve attached the below pictured TOE to this post, it’s a comparison of 3 primary ways of animating instanced geometry:
Since the latest official is out, I’ve been taking a closer look at performance of geometry instancing. I’ve always noticed how the geometry COMP incurs a constant cpu cook time that seems mostly unrelated to the amount of instances, and more a general overhead cost of the instancing data animating.
My guess has always been that the chop (or now TOP too) data has to get converted, or uploaded to GPU, or something, and there’s some CPU overhead here like there is in any top. However, the cpu overhead for me is roughly .25-.35 ms a frame, not too bad, but also if you’re using instancing a lot for UI systems or in replicators, that can add up quick, making the performance of the system more sluggish for the cpu to handle.
I’ve also started leveraging custom GLSL shaders for handling the movement of instances, and that’s where I started noticing an odd and fairly unexplained (to me) difference in CPU performance.
If I feed the very same chop of instancing data into the shader, and sample it as a samplerBuffer, using the instance Index, and offset the world position after tdDeform() (same visual result) the result is that the shader’s cook time is next to nothing, and the geometry COMP doesn’t cook at all.
If I wanted to optimize this approach even further, I could stick the animated parameters in the render top’s sampler inputs, and let the shader access it from there(since the render top cooks anyways) - which would remove constant cooking entirely from the shader. (good for replicated networks, and where lots of copies of this instancing is happening)
That said, when I switch between the 3 methods described above, the result is the GLSL approach is faster, not only does it not incur that chunky cpu cost the geometry COMP does, the render TOP is actually slightly faster in CPU, and GPU. Making me even more perplexed as to why.
Now to my actual question - What is the geometry COMP doing during instancing, that I am not doing during the glsl sample/deform stuff? Is it doing some critical things that are very useful in some other more complex use cases? or is this something that could be optimized?
With the addition of the custom instancing attributes, and other super amazing additions this geometry instancing COMP is becoming very attractive again, and would like to see it be a bit more optimized for animated data - however maybe this ask isn’t really realistic if there’s a reason for the extra cook time that isn’t obvious.
InstancingComparison.9.toe (17.7 KB)