Open3d: Line width has no effect

[richardrl]

Describe the bug
Setting the line_width with render option has no effect on the output.
To Reproduce
https://gist.github.com/richardrl/f76786042dcd72c6bd78396a73e172db

Expected behavior
The line width does not visually change regardless of what you set:
vis.get_render_option().line_width = 10.0
Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• OS: Ubuntu 16
• Python version: 2.7
• Open3D version: 0.9.0
• Is this remote workstation?: No
• How did you install Open3D?: pip

Additional context
Add any other context about the problem here.

[syncle]

This feature was supported by old OpenGL, but it seems not working anymore.

Please check out this discussion: https://github.com/intel-isl/Open3D/pull/738.
and this StackOverflow: https://stackoverflow.com/questions/34866964/opengl-gllinewidth-doesnt-change-size-of-lines

Unfortunately, we may need to disable the thick line feature.

[kentaroy47]

too bad that bold lines are not available..

I draw psuedo-bold lines by adding jitters to points in lineset, so that the jitter width will become the line width. The visualiziation is not bad but the code tends to become complex..

[syncle]

FYI, @JeremyBYU also made an interesting script. To implement thick lines, his script actually transforms a LineSet into a set of cylinders. I think it is a valuable idea, and the implementation is free from OpenGL version issues.

[germanros1987]

Actually...I am reopening this.

@Xardvor could we make sure that our new materials can handle different line widths?

[hansen7]

FYI, @JeremyBYU also made an interesting script. To implement thick lines, his script actually transforms a LineSet into a set of cylinders. I think it is a valuable idea, and the implementation is free from OpenGL version issues.

Hi, @syncle, thanks for referring to @JeremyBYU's solution in #738 , I find that open3d.geometry.RotationType.AxisAngle is not supported by 0.8.0.0. or 0.9.0.0, so to make it executable, just replace

cylinder_segment = cylinder_segment.rotate(
                    axis_a, center=True, type=o3d.geometry.RotationType.AxisAngle)

with

cylinder_segment = cylinder_segment.rotate(
                    R=o3d.geometry.get_rotation_matrix_from_axis_angle(axis_a), center=True)

, then it will sort :)

[fabiopoiesi]

With version 10.0 it stopped working.

[alainchau]

With v0.10.0, you can do

cylinder_segment = cylinder_segment.rotate(
                    R=o3d.geometry.get_rotation_matrix_from_axis_angle(axis_a), 
                    center=translation)

[AndreiBarsan]

I think it's worth pointing out that the linked script, while working and definitely tremendously helpful, is orders of magnitude slower than simply drawing a line in OpenGL... I am trying to render a line consisting of 1k segments, so nothing too huge, but actually building the mesh takes 4 (!!!) seconds on my machine. Doing this for, e.g., rendering a demo video can make a 30s fly-through render of a scene take 15min+, which is a non-trivial slowdown.

(For technical reasons I have to re-render the line segment at every frame; I can't just build it incrementally.)

[JeremyBYU]

Oh yes it is definitely not performant and can be slow with thousands of segments. It was meant as a stop gap measure until open3d finds a more performant long term solution. Also note there was a very large performance regression in open3d 0.10 causes n^2 runtime when drawing geometries (n= num of geometries). This caused huge issues with using my LineMesh module, each segment is its own geometry. I’m not sure if you are facing that as well but I thought I would share.

PR fix: #2523

https://github.com/intel-isl/Open3D/issues/2157#issuecomment-713180474

[AndreiBarsan]

wow, that's a really interesting thing to note. I'll keep it in mind. Thank you Jeremy!

In the meantime, I realized that if my line is already high-res, then I can probably render really coarse cones, so in LineMesh I added

            # create cylinder and apply transformations
            cylinder_segment = o3d.geometry.TriangleMesh.create_cylinder(
                self.radius, line_length,
                resolution=4,
                split=1,
            )

which seems to have helped a little. I will add your patch next, thanks for sharing!

[AndreiBarsan]

Hmm, I rebuilt Open3D from master and combined that with the much coarser mesh change from above but it is still taking ~8s to render a single frame, compared to 0.4s without the line. :(
I'll keep digging.

Update: Looks like even rendering things like boxes can become slow, even for a few hundred

[JeremyBYU]

So I had not tested that PR #2523 until a few minutes ago. After installing and testing on Windows 10 X64 it did successfully fix my issue, where I just reported results here: https://github.com/intel-isl/Open3D/issues/2157#issuecomment-715649708

However I am not sure what version of Open3D you were using before you updated to master branch. In fact if you were using 0.10.0 I don't think you would have been waiting only ~10 seconds, you would have been waiting hours! I just tried 3000 geometry objects on 0.10.0 and I didn't have the patience (or memory!) to let it finish to begin drawing.

On the new fixed master (0.11.X) (and on 0.9.0) I decided to just test scaling of geometries. It looks like on my computer that anything less that 100 geometries takes less than 0.5 seconds to begin interaction to screen. It takes about 2 seconds for 1000 geometries. It takes about 7 seconds for 3800 geometries. So I think the number you are reporting is just inline with the current limitation of open3d.

I'm sorry for leading you down that goose chase (#2523) and wasting your time! I should have realized the times you were reporting were much smaller than the ones I was facing.

[AndreiBarsan]

Yeah, I was using 0.10.0, so I guess my overhead was just from the number of geometries. I will try to eventually just write the code to build a single mesh from the lineset and try to render that. Thank you and no worries!

[theNded]

Fixed in #2803 within the new visualizer.