You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: