Graphic Buffers Update #714
Conversation
I'm not sure why we're using VAO's when so much seems to be recreated each render, but this way at least the VAO itself wouldn't also be recreated even if the objects aren't.
Still TODO: Once the RenderBatch isn't recreated each time a slightly different render is made, VertexArrayObjects will actually be used, instead of just pretended to be used. Also still TODO: any model will render as if the base color is matte dark grey. All the other rendering (like for 'lay-flat by face' or the blue model outline or the tool-arrows and such) and all the rendering _given that the cube is matte grey_ (like 'the error polka dot pattern' and the 'below the buildplate inversion') will still work properly. So everything works _except_ for the color and light-highlights. Why?
VAO includes shader uniforms, which where needed. So now, instead of cacheing per mesh alone, cache per mesh _per shader_. Currently the doesn't work 100% yet if different parts of a mesh are rendered with different settings, such as in the simulation view. Also need to check if the X-Ray view was supposed to be opaque or if that's another thing that doesn't work 100% yet (is usable though just not as pretty as remembered).
Instead of re-uploading the mesh each time the range changes, handle the range in the shaders with the new draw-range parameters.
|
Do you also have before / after profiling? I'm curious what the gains are :) |
|
@nallath Right, was one of the things I meant to do as well :-) (P.S. Even if there are no true gains I'd argue this is more correct, but that's harder to justify from a 'risk' perspective. Also technically upping the SDK with my shader shenanigans.) |
|
Lesson for next time: Run the tests after I've merged with main as well. |
Typing edition. Co-authored-by: Jaime van Kessel <[email protected]>
Seems to have fixed the test as well. Not sure if it was ever a valid test if it can't create a VAO there.
|
(... actually I don't think I did run the tests. I was confused with last week, when I had to set them up again on my work lappy.) In any case, please try again, should pass now! |
Fixes type laziness, types should work harder!
|
I still didn't do a proper benchmark, but playing around a bit with some printouts of the average time of the render of the SimulationView (where I expect most of the time-win will be) it seems that the newer code is about 20% faster. |
Co-authored-by: Aldo Hoeben <[email protected]>
|
When trying to benchmark this, I noticed I need to set up some caching or something, or this PR will feel incomplete (even though it's already a bit faster). A lot of SimilationPass could be imporved, but let's try to keep it a bit smaller for now. |
|
Closing this in favour of #721 due to laptop & account related shenanigans. |
The highly interdependent Issues this fixes:
Complications:
gl_primitiveIDbuilt-in due to support of legacy shaders.) See also Graphic Buffers Update Cura#10188, the front-end implementation of this PR.See also this related discussion #664 earlier.