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

indexing shapes by length is expensive #347

Open
vorth opened this issue Mar 30, 2021 · 0 comments
Open

indexing shapes by length is expensive #347

vorth opened this issue Mar 30, 2021 · 0 comments

Comments

@vorth
Copy link
Member

vorth commented Mar 30, 2021

Currently, we start with a VEF file that encodes a particular strut shape, including which vertices should offset to the end of the strut, and which (if any) should offset to the midpoint. For every length of strut that we render, we bind this parametric shape to the actual strut end (still within the prototype zone of the orbit), and we store these shapes in a map keyed by the length.

First, computing strut length requires a division, which is expensive (an matrix inversion). It would be far simpler if we could simply resolve to a zone, and let the shader bind the strut offset to the parametric shape. No length computation would be needed at all for rendering, although the parts list would still need it. The shape "stretching" math would be performed in parallel on the GPU.

At the moment, we pass shape vertices as vec3 in the buffer, and the shader automatically fills in w=0 before the matrix operations begin on the defined vec4 attribute. We can encode the parametric strut shape by using the w value to indicate "how many half offsets to add". W=0 would be used for the near-end vertices, to get no offset. W=1 would offset halfway from the near end to the far end, and W=2 would offset to the end. This computation could be done non-conditionally, which is very important for shader performance. After extracting the W value, the shader would have to set W=1.0, of course.

Note that all shape vertices would need to be pre-normalized, in the sense that the actual end offset of the prototype strut model would have to be pre-subtracted from the W=2 vertices, and the actual half-length offset similarly pre-subtracted from W=1 vertices.

In addition to extra information for the shape vertices, we would need to send both location and offset (or end) vec3s for every strut instance. The offset vec3 would be (0,0,0) for balls and panels, and in any case those shapes would have only W=0 vertices.

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

No branches or pull requests

1 participant