Ellipsoid wireframe is today a wireframe of the on-the-fly generated triangle mesh
This approach still has some shortcomings:
this visualizes something that wasn't actually logged
what was logged was an abstract ellipsoid and in the future we may not even use a triangle representation to draw this (ellipsoids are trivial to raytrace, so we could render "perfect" ellipsoids just like we render perfect spheres for points today using raytracing on a small quad)
users logging ellipsoids often want to express things like eigenvectors (e.g. of covariance matrices) or other abstract quantities
what we're interested in is specifically the extent of the primary axis
To that end, we should instead use a more abstract representation by drawing the lines of (2d) ellipses on the primary axis
(both transparency and dotted lines we can't represent yet)
(this minus the solid, all outlines the same color)
Ideally, we'd also additionally render the view dependent outline on top as done here
Doing this via our outline postprocessor is not feasible right now the way it is set up, so instead we'd need to re-compute these outlines every frame and use our line renderer. While our line renderer is afaik decent with per-frame changing lines, this may be too much computation overhead though. Also, computing this outline "by hand" is probably too complicated to warrant the extra effort, which is why we should shelve this for the moment.
Other potential issues:
Fairly high line tessellation may be needed to hide the fact that our lines are still not connected 🫤
On the bright side, the line renderer is fairly well optimized for long strips, so data overhead wise this isn't as bad (total number of positions it has to send to gpu is n+2 where n is all line vertices in a single line batch + 64bit for each strip)
Ellipsoid wireframe is today a wireframe of the on-the-fly generated triangle mesh
This approach still has some shortcomings:
To that end, we should instead use a more abstract representation by drawing the lines of (2d) ellipses on the primary axis (both transparency and dotted lines we can't represent yet) (this minus the solid, all outlines the same color)
Ideally, we'd also additionally render the view dependent outline on top as done here Doing this via our outline postprocessor is not feasible right now the way it is set up, so instead we'd need to re-compute these outlines every frame and use our line renderer. While our line renderer is afaik decent with per-frame changing lines, this may be too much computation overhead though. Also, computing this outline "by hand" is probably too complicated to warrant the extra effort, which is why we should shelve this for the moment.
Other potential issues: Fairly high line tessellation may be needed to hide the fact that our lines are still not connected 🫤 On the bright side, the line renderer is fairly well optimized for long strips, so data overhead wise this isn't as bad (total number of positions it has to send to gpu is n+2 where n is all line vertices in a single line batch + 64bit for each strip)