Line width issue for tracks

[9inpachi]

Hi all,

The function getTrack(trackParams: any): Object3D currently returns an object of THREE.Line.
The problem is that THREE.LineBasicMaterial has known bugs for the linewidth property which does not work on windows and on chrome for MacOS. See THIS for details.

I was working on a control for changing line width of tracks and came across this problem. The solution is to use either Line2 or THREE.MeshLine.

Using THREE.MeshLine
I have a solution using MeshLine here but the problem with it is that it scales with camera zoom since it is a Mesh. We can scale it for every render (animate()) we do but that is too expensive in terms of computation.

Here is what it looks like:

Using Line2
I also have a solution ready using Line2 here. Line2 is not part of three.js core and we have to use scripts in three/examples/jsm/lines/. Line2 does not have any scaling issues so I think this is the perfect choice.

Here is what it looks like using Line2

WHAT ARE YOUR THOUGHTS?
This is surely going to make tracks selection MUCH SIMPLER.

[EdwardMoyse]

Interesting! It looks like Line2 is the best solution to me.

But would outlinepass work better with MeshLine? Did you notice any other difference in performance?

[9inpachi]

But would outlinepass work better with MeshLine?

I am not sure. OutlinePass should work equally well for all geometries AFAICT.

In terms of performance, I don't notice much difference.

• For simple THREE.Line the fps with all the ATLAS geometry loaded is about 50-55.
• For THREE.MeshLine it might be a couple of frames ahead with about 52-57 fps.
• And performance for Line2 is the same as THREE.Line.

[EdwardMoyse]

Okay, so I vote for Line2. @emiliocortina - any thoughts?

[emiliocortina]

I am curious to see how it behaves when intersecting with the raycaster.

The main issue with the tracks is not their visibility (we are already changing line width when creating tracks with the current implementation) but selecting them.

Modifying their width only changes the way they are represented, but they are still one-dimensional objects, which makes it very difficult to select when hovering over them, as you have to find the exact spot.

Can you make a pull request so I can check that out? Thanks!

[9inpachi]

Sorry, I didn't follow up on this. I actually looked into selection earlier and debugged some things.

For Line2, it's just as Emilio said. But we do get a weird box in the middle like this:

Which might be used as an indicator (pretty sure not practical). However, increasing the linewidth does increase the selection area for tracks even though it's not as accurate.

And surprisingly, for MeshLine, there seems to be a more uncommon problem. I am unable to select tracks at all even though they are basically Mesh. I will look into it a bit more.

@emiliocortina the branches are in disarray and not ready for a PR so you can manually check the branches from the links I mentioned in the issue description.

[9inpachi]

Another use of Line2 is linewidth support for Windows and chrome in Mac like I mentioned in the description.

[9inpachi]

Cylinder Geometry for Tracks

So here is another possible go at tracks:

Code exists at https://github.com/9inpachi/phoenix/tree/cylinder-tracks

The code is very much unrefined right now and is only for testing purposes.
This is very interesting but heavy on the computing (at the moment). But I believe we can further refine this. The problem with non line geometry tracks in general is scaling. They do not scale with zoom which might be troublesome.

[emiliocortina]

@emiliocortina the branches are in disarray and not ready for a PR so you can manually check the branches from the links I mentioned in the issue description.

Ok, I will take a look at those approaches. If it ends up generating lag, maybe it is better to stick with either Line or Line2 for tracks.

[9inpachi]

THREE.TubeGeometry is also a good choice for loading mesh based tracks. It can be directly created from a curve instead of points and track selection also works good.

Again the only problem is scaling like I pointed before:

The problem with non line geometry tracks in general is scaling. They do not scale with zoom which might be troublesome.

I am looking around in shaders to see if I can make sizeAttenuation work for THREE.Mesh and then use a material that actually supports sizeAttenuation.

[EdwardMoyse]

A trick we used in another EventDisplay (VP1) is to have a Tube with a line inside. That way if the tube disappears, we still see the line. Not sure how this would behave here, or if it would lead to performance issues.

[9inpachi]

A trick we used in another EventDisplay (VP1) is to have a Tube with a line inside. That way if the tube disappears, we still see the line. Not sure how this would behave here, or if it would lead to performance issues.

I think it's worth to give it a try.

Another approach which I had in mind was to have two different version of tracks. One with the line geometry and the other with tubes. Such that when we turn on selection, the tube geometry tracks become visible and the line tracks become hidden and vice versa.

I tried a lot to edit the shaders for making sizeAttenuation work for meshes but couldn't succeed. We could put up a post on three.js forum if the sizeAttenuation approach is worth it and stable enough.

[9inpachi]

A trick we used in another EventDisplay (VP1) is to have a Tube with a line inside. That way if the tube disappears, we still see the line. Not sure how this would behave here, or if it would lead to performance issues.

So I gave this a try today and the result is very promising
BUT
We are looking at a loss of about 10-20 frames which is not great.

See this:

[EdwardMoyse]

No, that's not ideal. But maybe this could be another configuration option? I naively assume that it's the tubes that cause the FPS drop?

[9inpachi]

Contrary, it looks like its due to THREE.Line.
I just took a look again and it seems we get the same FPS as with THREE.Line. TubeGeometry alone is what gives better FPS.

We will have to handle selections a little different for both of these to work together. I guess we can use TubeGeometry for all the selection related functions and have the Line just there for visual purposes.

EDIT: It looks like the FPS drop is due to the TubeGeometry after all

[9inpachi]

It seems I was not debugging properly since I was also working with collections at the same time. The performance is great for both TubeGeometry and Line individually and combined too. I am getting a solid 60 FPS for both the Line and Tube combined.

I will be pushing the changes along with the #93 issue (wip-collections branch on my fork). All of it is almost complete.

[EdwardMoyse]

Excellent!