search

remcoder / gcode-preview

A simple GCode parser & previewer with 3D printing in mind. Written in Typescript.
https://gcode-preview.web.app/
MIT License
150 stars 30 forks source link

Tube rendering: improving performance #95

Open remcoder opened 5 months ago

remcoder commented 5 months ago

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

remcoder commented 3 months ago

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 commented 1 month ago

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.

image

sophiedeziel commented 1 month ago

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 commented 3 weeks ago

I'm suggesting to close this issue after:

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 commented 3 weeks ago

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