<_whitenotifier-f>
[scopehal] azonenberg 36ade4f - Refactoring: removed Statistic, converted min/max/avg statistics to scalar filters which can take uniform/sparse/scalar analog input
<_whitenotifier-f>
[scopehal] azonenberg 709cda6 - Merge branch 'master' of github.com:glscopeclient/scopehal
<d1b2>
<mubes> Quite probably a dumbassed question, but something struck me last night and I got to noodling on it...would one of the gaming engines bring any benefit on the rendering side? They certainly abstract away from individual cards and platforms, and are obviously realtime, but I don't know much about them or if you carry a lot of pain to use them, plus there's a lot of work been invested in getting to there point the project is now at, so quite
<d1b2>
possibly the answer is "I wouldn't start from here".
<d1b2>
<246tnt> That would be one hell of a dependency ..
<d1b2>
<246tnt> But also not sure what they would provide. Vulkan does the abstraction mostly. It's only if you want very tight integration / control that you need to start caring about what's underneath, but that would be the same with anything AFAICT.
<d1b2>
<mubes> Seems to me that game engines are good at providing different projections onto a data set...not sure if they'd perform well when that data set is constantly and fundamentally changing.
<d1b2>
<mubes> i.e. replaced with every sample set.
<d1b2>
<mubes> I'm seeing a lot of noise around Godot (given the Unity fallout I guess) recently for 2D application. Anywqay, no more than a grain of sand for other peoples brains in addition to my own for now.
<d1b2>
<daglem> It does use Dear ImGui, which is also used in several games IIRC.
<d1b2>
<johnsel> We are essentially our own game engine
<d1b2>
<johnsel> but I have brought up the idea of using 3d rendered meshes for the signals instead
<d1b2>
<johnsel> however pre-processing our data to make it into something meshy at various detail levels is non-trivial
<d1b2>
<johnsel> we'd be writing custom shaders one way or the other
<d1b2>
<johnsel> I've played with the same ideas though but it makes more sense to extract from a game engine what we like than to implement everything in some engine
<d1b2>
<johnsel> writing a camera/viewpoint isn't super complicated, and the world/mesh rendering of a game engine is not super helpful without meshes first
<d1b2>
<johnsel> and also not the most difficult to write ourselves
<d1b2>
<johnsel> mesh rendering that is, I don't think we'll need world to run around in lol
Darius has quit [Ping timeout: 258 seconds]
<azonenberg>
Yeah. I looked around at mesh rendering, the early versions of glscopeclient used it because GL_LINES rendering is not very portable and often has problems with >1 pixel lines
<azonenberg>
the tl;dr is that it's slower because it makes more memory reads per sample
<azonenberg>
since you need 2D/3D coordinates instead of simply a y axis value (for uniform waveforms at least, sparse is gonna be a bit slower regardless)
t4nk_fn has quit [Ping timeout: 245 seconds]
t4nk_freenode has joined #scopehal
<azonenberg>
We moved to the compute shader rendering specifically because it's faster and more flexible
<azonenberg>
as far as game engines, yeah I dont think there's any benefit. they're mostly optimized for rendering static 3d mesh data with some dynamic components
<azonenberg>
What we're doing is, as john mentioned, pretty much an engine of our own optimized for our use case
<_whitenotifier-f>
[scopehal] azonenberg 06874a5 - Added "infrequently used" hint to say that a filter's output stream should not be shown by default, only if the user explicitly adds a view to it
<_whitenotifier-f>
[scopehal-apps] azonenberg cc4b36e - Removed references to statistics since they're being removed
<_whitenotifier-f>
[scopehal-apps] azonenberg f363e6e - Merge branch 'master' of github.com:glscopeclient/scopehal-apps
<_whitenotifier-f>
[scopehal-apps] azonenberg 4d0d321 - MultimeterDialog: added field width specifiers
<_whitenotifier-f>
[scopehal-apps] azonenberg d6f5680 - Updated submodules, added support for STREAM_INFREQUENTLY_USED hint so less common measurements won't clutter the view by default
<azonenberg>
Quick update on docs: I have latex -> html working reasonably well and just need some cleanup to do in order to make the generated temporary files not clog the source directory
<azonenberg>
It probably won't be automated wrt website updates, so nearish term i'll manually push generated HTML, but it's a starting point
<azonenberg>
i expect in the next day or two to have it working