Feature/performance tweaks

[remcoder]

Investigating the performance of the TubeGeometry leads me to believe that

• the # of tube segments is a large contributor to the overall mesh size
• we're creating more tube segments than necessary.

The screenshot it shows that the tube is divided evenly along its length while we need more division towards the corners and less far away form the corners.

This has to do with how a curve is divided. In turn this is based on where the FrenetFrames are defined along the path of the curve.

The maximum bend radius of a corner should be equal to the line width, as set in the slicer. This means that no extra segments are needed at a distance of line-width/2 from the corners.

[stackblitz[bot]]

Run & review this pull request in StackBlitz Codeflow.

[sophiedeziel]

I played with your branch yesterday and I am preparing a deep dive!

First thing I did was to replace the CatmullRomCurve3 by a CurvePath. There was no significant changes in the performance of the rendering of a benchy. It also made the end result look worse in sharp corners and top layers. I don't have a strong opinion right now into keeping it or not.

What's the most intensive in terms of processing is, as you pointed out, the number of segments.

When we build the TubeGeometry, one of the constructor's argument is the number of segments. That number is currently calculated by the length of the curve we're passing it. Longer extrusion line = more segments. The thing is, those segments are all equidistant, as you found out about FrenetFrames. That's the implementation of the TubeGeometry. I've tried to split the extrusions curves to generate fewer segments to long straight lines, but the fact that it ends up adding more objects to the scene resulted in even worse performance. The key would be to reduce the number of segments overall, without changing the number of objects added to the scene while still keeping enough segments in the corners.

There two approaches we can go from there. If I understand your reasoning, you're suggesting a custom curve implementation that have the computeFrenetFrames implemented differently.

I think we can create our own geometry that looks a lot like the tube geometry but instead of having equidistant segments, it would be smart about where to place them. I think it's also a good long term solution because a custom geometry will allow changing the shape of the tube to set line height and line width at the same time for an accurate representation of an extrusion.

Those two approaches are obviously not mutually exclusive. A custom curve implementation could have optimizations on smooth curves and sharp corners, as well as dealing with arc support in another way than splitting the curve in small intermediary travel lines and more segments. A custom volume allows shapes that better fit our use case. They can work very well together.

This is where your branch comes into play and is super useful! The wireframe view really helps in understanding the effect of any changes on the number of segments.

I'm very optimistic about where this is going. I'll pursue the path of the custom volume because it helps unlock other features I'm currently working on.

[remcoder]

My idea was to have a custom TubeGeometry that also combines a custom Curve (if I remember correctly). It might as well be called ExtrusionGeometry because if it's solely for that purpose we can ditch all the generic stuff and the geometry/curve separation and most of the math. This would also be a speedup because we can basically hardcode some unitvectors for the frames iso using trig to compute them.

Awesome you're diving into this. It was a bit daunting so didn't start on this myself yet. My request would be to document your insights so it can be built on later, by anyone. Maybe the hard part now is deciding where to start, code-wise.

[sophiedeziel]

I agree with everything you just said. Approaches, naming, benefits.

I also found that we could benefit from https://threejs.org/docs/index.html#api/en/objects/BatchedMesh, but the three.js version we're using does not have it. Since we're using a limited number of colors, I'm sure we'll get a significant boost. We would have to do a slight refactor to generate the material outside of the addTubeLine.

I'm starting with the custom volume for now.

[remcoder]

This was mostly to discuss and work towards a new geometry, which is now merged. So closing this and the batchedMesh can be a new PR