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

Graphic Buffers Update #10188

Closed
wants to merge 2 commits into from
Closed

Conversation

bremco
Copy link
Contributor

@bremco bremco commented Jul 26, 2021

Front-end implementation of Ultimaker/Uranium#714.
(See also this discussion Ultimaker/Uranium#664.)

Due to technical details (see the link above), meshes ranged by index are now rendered by specifying the range of vertex-indices in the shaders, rather than specifying the element range beforehand. (Manually, as gl_primitiveID couldn't be used because of the legacy support... also this gives more control, potentially.)

Potential bonus:

  • The compatibility mode, (for legacy OpenGL/shaders,) could be made compatible with Simulation-View relatively easy now. Perhaps I could even do that in this PR. Keeping this relatively small for now is better though!

Also not in this PR (yet?):

  • RenderBatch's are still recreated on each draw. As so much of its internals are cached, either directly or via the classes it uses this might not present a problem in practice.
  • In Simulation-View, the range to show is recalculated for each render, even when it makes a lot more sense to cache those calculations. An earlier attempt has been made at this, then reverted, however. Rather than complicate this PR by also attempting that, leave it alone for now.
  • The geometry shaders are still used. That has a little less to do with this particular update (though related), but for completeness sake, I'd like to say that we could maybe also pre-calculate/upload the 'tubes' to the graphics card instead of re-calculating them in the shaders every redraw (especially since the common wisdom is that 'geometry shaders are slow' ... not sure how true that actually is though).

Instead of re-uploading the mesh each time the range changes, handle the range in the shaders with the new draw-range parameters. This does however, mean the range has to be in vertices, not in elements. This necessitates some changes to the simulation-view, and some added bits deeper in the base code. Mainly, since each time the type of a line changes, there is an extra vertex, there needs to be a type-change count available to get from 'paths' to range indices.
@rburema
Copy link
Member

rburema commented Aug 9, 2021

Closing this in favour of #10259 due to laptop & account related shenanigans.

@rburema rburema closed this Aug 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants