scalableminds
Edge thickness/width
This is an issue that we had for a long time: The edges between nodes are only 1 pixel wide. It would be great to be able to increase that for visibility. We know that on some platforms (Chrome on Windows, I believe) this is not possible due to limitations in WebGL. However, perhaps on other platforms this could still be a win for users.
So the status quo seems to be that the line width was deprecated and now stops to work on even more platforms (not only Windows) according to https://stackoverflow.com/a/41911520
In my case it is still working (Ubuntu 18.04, Chrome):
I'll try to get something with THREE.MeshLine or https://threejs.org/examples/?q=line#webgl_lines_fat working, but it's slightly complicated as we're using shaders for our lines which don't seem to be supported on a first look. We'll also have to see whether there is a noticeable performance impact.
From what I've gathered and experimented with
- THREE.MeshLine
- uses own fragment/vertex shader with own
MeshLineMaterial, so we cannot use our own line shader - doesn't support
THREE.BufferGeometrywhich we use to manage edges and nodes - performance hit not clear
- uses own fragment/vertex shader with own
- fat lines
- uses own fragment/vertex shader with own
LineMaterial, so we cannot use our own line shader - doesn't seem to support
THREE.BufferGeometry,setPositionsmethod needs to be called - from this example which someone posted in the fat lines PR, the performance hit seems to be pretty big (use
spaceto toggle between the GL.Line and FatLine implementations)
- uses own fragment/vertex shader with own
Both materials seem to support a color, though and we should also be able to hide objects (which are the only two things we do in our custom line shader). I am unsure about the performance impact of not being able to use the BufferGeometry.
Using one of these replacements, performance is only going to become worse for tracings with a large amount of trees. We should discuss this step carefully.
Relevant internal discussion: https://scm.slack.com/archives/C5AKLAV0B/p1659962118419979?thread_ts=1659961436.367339&cid=C5AKLAV0B
In todays meeting @normanrz suggested to gather more performance insights for this feature first (i.e., what will the concrete performance hit be).
from this example which someone posted in the fat lines PR, the performance hit seems to be pretty big (use space to toggle between the GL.Line and FatLine implementations)
On my machine the hit is at least a factor of 3 (without fat lines the FPS meter is consistently at 60 which is obviously capped; with fat lines it's more at 20). So, this option is probably not a good idea.
Therefore, I'd suggest to make a similar benchmark for THREE.MeshLine.
THREE.MeshLine [...] doesn't support THREE.BufferGeometry which we use to manage edges and nodes
The current readme mentions BufferGeometries now. See here. Hopefully, this support is exactly what we need.
Another note on performance: If it's not a big effort, we could make the fat line rendering optional. Then, users who need the extra drop of performance (OR whose GPU supports native line width) can disable the potentially expensive rendering.
See https://github.com/spite/THREE.MeshLine/issues/140#issuecomment-1340228756 for maintenance status of the lib.