Tube rendering: improving performance

[remcoder]

This ticket is for experimenting and discussing improving the performance of the rendering of volumetric tubes (currently TubeGeometry in THREEjs terms).

[remcoder]

I think it makes sense to see what happens when we change tubes into blocks. Square vs round. This means a reduction in the mesh size and easier control over line width and line height..

Since it will look different, possibly more clunky, let's add this as additional render mode. So I guess well need to introduce 'render modes'.

[remcoder]

Just to document my thoughts here: I looked into the above but apparently the tube lines already have a square profile. So the profile cannot be reduced any further. Well, a triangle shape is possible, by changing a single param from 4 to 3. For now we want to keep it at 4.

Another optimization idea that @sophiedeziel is working on, is reducing the number of segments in the TubeGeometry. It already has very good results.

[sophiedeziel]

https://github.com/remcoder/gcode-preview/pull/149 is almost ready, you can try it, have fun, and give early feedback if you want to!

After this, there are several optimizations we can go for:

Some curves that are composed of several short moves could benefit from the Catmullrom curve algorithm to reduce the number of segments without compromising the final result. That can be an internal optimisation inside the extrusionGeometry. I'm thinking about doing a grooming pass on the vectors array, identifying sub-arrays of short travel lines that have a high ratio of points for a given distance, and substitute those points for new ones.

Then, when our three.js version allows it, we could benefit from https://threejs.org/docs/index.html#api/en/objects/BatchedMesh

And even before that, I think we can create only one material object per color and reuse it instead of creating an instance each time. I'm not sure we will gain a lot, but every memory gain at the scale of hundreds/thousands of objects per render is a valid gain.

[sophiedeziel]

I'm suggesting to close this issue after:

• trying BatchedMesh(https://github.com/remcoder/gcode-preview/pull/164)
• reducing the number of material instances (https://github.com/remcoder/gcode-preview/pull/165)
• improving the incremental rendering (https://github.com/remcoder/gcode-preview/pull/136)

The time to a full render was significantly reduced, to a point beyond my initial expectations. With incremental rendering improvements, the result is so smooth that tube rendering can be enabled by default without any noticeable lag.

[remcoder]

Agreed, let's just focus here on noticable rendering speed. I think that's what we started out with.

[remcoder]

All subtask listed above have been closed by now. So I'm now closing this umbrella ticket.

For additional performance work, let's create new, specific tickets.