Feature Request: support for drawing glow::POINTS and glow::LINES

[donkeyteethUX]

Thanks for the great project. I was wondering if you have plans to add support for POINTS and LINES. This would be really helpful for building data visualization tools. For reference, kiss3d has examples of this.

https://github.com/sebcrozet/kiss3d/blob/master/examples/lines.rs
https://github.com/sebcrozet/kiss3d/blob/master/examples/points.rs

[asny]

Thanks for the kind words 🙏

Points and lines are actually already supported, just draw a sphere (or whatever shape you want) for each point and a cylinder (or whatever) for each line using a Mesh and any Material. If you have many points and/or lines with the same material, use the InstancedMesh instead of Mesh for performance reasons. Also, see the wireframe example and the recently added point cloud example. Does this meet your needs? I'll be happy to discuss adding something to make it easier and more clear, for example a specific Line struct that impl Geometry or another example?

Also, it seems like kiss3d actually uses the legacy way of drawing points and lines, which might be what you're asking for. However, it is much better supported and much more flexible to draw a 3D object that resembles a point/line. It's always difficult to say something about performance since it very much depends on hardware, but it shouldn't be much slower to do it like this (might be faster on some hardware). What is important is to use InstancedMesh if you have many points/lines.

[donkeyteethUX]

Makes sense. If I understand correctly, the key difference between the "legacy way" of drawing a line and simply representing it as a cylinder, is that a true line is scale-independent whereas a cylinder is not. No matter how much I zoom in or out, it's still a line with the same fixed width. This is because the width is defined in pixels, not an actual 3d geometry.

Say you want to visualize a graph of connections between 3d points (which can be very close together or far apart, in an absolute sense) with an OrbitControl camera. If you use spheres for points and cylinders for lines, you have to worry about trying to adjust the width of shapes dynamically based on the zoom level. Otherwise, they will disappear when far away, and become too "thick" when close. The desired property ends up being a fixed pixel-width, which is what the "legacy way" already provides.

Does this use case make sense? I know lines and points might be "legacy" on some graphics backends, but we can perhaps let the backend-abstraction layer worry about that, and glow still happily supports them.

[asny]

Yeah, wanting fixed width lines makes a lot of sense. However, to me at least, that sounds like you want 2D lines, not 3D lines. My reasoning is that if you draw a line with fixed width, then you loose the third dimension, ie. you have no idea if a line is close or far away. So if I understand you correctly (please correct me if I'm wrong), you can use the Line struct for drawing 2D lines (se the shapes2D example). To find the end points of the line on the screen, you can use the uv_coordinates_at_position method on the Camera to get the uv coordinates on the screen for a given 3D position. To go to a pixel position, just multiply the uv coordinates with the width/height of the viewport and add the viewport offset if any. I probably should have made a pixel_at_position method, I will add that 💪 Do you think this approach will work for your use-case?

And I agree, you shouldn't worry about what is legacy and what is not (I probably shouldn't have brought it up). So if you want 2D lines - which is exactly what is supported by legacy OpenGL - just use the Line struct.

[asny]

Added pixel_at_position in 9712b198e6ed0b84c8db472d548dbe114fd72d5c 💪

[donkeyteethUX]

This sees very reasonable; I'll try it out. Thanks for the response!

[Nevsden]

To add a 3D use-case to the original author, I am focusing on having a viewer for 3D geometries such as toolpath planning in a CAM software (computer-aided manufacturing). There it is quite common, to have scale-invariant 3D lines primitives which show the planned path of the tool processing a surface / part.

As the number of lines in a toolpath is solely dependent on the curve approximation and number of tool passes, the line count may be huge (100.000+ lines is quite common), I could imagine that the 3D approach of rendering a cylinder for each line may bring additional costs and make the viewer quite laggy.

I will investigate this.

From the perspective of the software architecture of three-d, it seems that the rendering pipeline is specialized on triangle rendering, which is quite nice and performant. There are three-d::core::Program and three-d::core::RenderStates, which I think are specialized for the case of triangle rendering. So even if we wanted to add the gl::LINES primitive to the crate, it will not be easy or at least feel like adding a third wheel. @asny Did I see it the correct way?

[asny]

As the number of lines in a toolpath is solely dependent on the curve approximation and number of tool passes, the line count may be huge (100.000+ lines is quite common), I could imagine that the 3D approach of rendering a cylinder for each line may bring additional costs and make the viewer quite laggy.

As long as you use an InstancedMesh then it should perform just fine. Also, you don't have to do a cylinder, that's if you want a line in 3D, seems like you want a line in 3D projected onto the screen. In that case, use Camera::pixel_at_position to find the 2D positions for the line and draw it in 2D using something similar to Line (which is just two triangles), just using InstancedMesh instead of Mesh. This is exactly the same as I described above.

From the perspective of the software architecture of three-d, it seems that the rendering pipeline is specialized on triangle rendering, which is quite nice and performant. There are three-d::core::Program and three-d::core::RenderStates, which I think are specialized for the case of triangle rendering. So even if we wanted to add the gl::LINES primitive to the crate, it will not be easy or at least feel like adding a third wheel. @asny Did I see it the correct way?

I still don't see any reason why anyone would want to render points or lines in the legacy OpenGL style, so I think it doesn't make sense to discuss how to add that capability.

[donkeyteethUX]

FWIW the suggested 2d-line approach worked fine for me.

[Nevsden]

Dear @asny - I did a little benchmark on the InstancedMesh approach with a rendering example, that showcases a rare but not uncommon scenario of computer aided manufacturing. The scenario shows a set of boundaries that arrive after a slicing process: 300 boundaries with an offset between each slice and a total of 500 line segments within a single boundary. This makes for a total of 150.000 lines. I used a CpuMesh::cylinder(6) with a custom transformation to resemble a line segment. This makes for a total of 1.8 million triangle segments. The benchmark has been split into two rendering scenarios:

Scenario 1

Each boundary is converted into a Gm<InstancedMesh, PhysicalMaterial>, thus the set of 300 boundaries convert to 300 Gm<...>. Rendering these on my laptop gives me an average of 20 FPS. CPU is at 14% stress and GPU at 8%.

Scenario 2

All 300 boundaries are converted into a single Gm<InstancedMesh, PhysicalMaterial>. Rendering these on my laptop gives me an average of 20 FPS. CPU is around 11-18% stress and GPU around 15-25%.

What I gather is the rendering pipeline seems to have a bottleneck. Is it possible that I don't use the library in the intended way? Or may it be, that before the actual rendering, the preprocessing of the renderable objects places a bottleneck?

Optimization 1

I changed the sort_by function in https://github.com/asny/three-d/blob/master/src/renderer.rs#L92 to sort_unstable_by.

For scenario 1, this gave me an increase in FPS.
For scenario 2, it did not change the FPS (maybe because I only render one Gm object?)

[asny]

I'm a bit confused about your findings, it seems weird to me that the FPS is the same for both scenarios and that the stress is so low. That makes me wonder if something else is limiting your FPS? Instead, could you measure the average time it takes to render a frame?

It's also weird that there are not more difference between the two scenarios, a few thoughts:

• Your testing the same as the instanced_shapes example, could you try to measure that also?
• In scenario 2, did you represent each boundary or each line piece as an InstancedMesh? It should be each line piece to get full performance benefit.
• Instead of drawing a cylinder for each line, you could project the end points into 2D (using Camera::pixel_at_position) and draw a quad (two triangles) instead. That means 0.3M triangles instead of 1.8M.

However, what confuses me the most, is what exactly you want to show? 🙂