Add an 'epsilon' parameter to tube()

[roel-v]

Is your feature request related to a problem? Please describe.

Previewing a tube made with tube() shows z-fighting artifacts that I find very distracting and sometimes make it hard to see what is going on. In most of my models, I use a variable ZFE (for Z Fighting Epsilon) that I set to 0.01 in preview mode and to 0 in render mode. I then move or increase the size of objects by this epsilon to prevent these slivers.

Describe the solution you'd like

A parameter to tube() that increases the height of the inner cyl() by the value of that parameter * 2 and moves it down by that value. I understand that to this exactly, you'd have to slightly adjust the diameters on conical tubes and probably other cases as well. But I also think that setting this value to 0 in non-preview mode fixes the disadvantages of this inaccuracy, i.e. I think these tiny adjustments can be ignored. The default for this parameter would be 0, so that it wouldn't even have an effect unless you actually specify it. Then there remains the philosophical issue of the preview being different from the real render, of course.

Describe alternatives you've considered

It is of course trivial to implement my own version of tube() that has these changes. I'm unsure on how many users use such an epsilon to preview the preview issues, and thus to how many people it would be relevant.

[adrianVmariano]

The tube module already includes a .01 height increase for the subtracted element. It's just hard coded in there. And I don't see any z-fighting for small tubes but it looks like it starts to occur when the tubes are bigger.

I wonder if there's a way to construct the tube as a VNF instead, which would be more robust.

[revarbat]

I was admittedly considering redoing this as a VNF. Shouldn't be too hard.

[adrianVmariano]

The main problem is that cyl() doesn't give us access to the ends. You can get the inner and outer VNFs but fixing up the top is the problem. I suppose the code that makes the profile could be pulled out and put in its own function that both tube() and cyl() could call. That seems like the cleanest approach.

[adrianVmariano]

Then also a tube() function could exist.

[revarbat]

Just calculate the four (inner, outer, top and bottom) edge circles, use them to make top and bottom regions, get the VNF faces from the regions, then form the inner and outer walls. The only trick is making sure the vertex counts on both top and bottom circles of their respective side (inner vs outer) match.

[revarbat]

From that point, it could become easy to add rounding/bevel code, too.

[adrianVmariano]

Tube already has rounding and bevel support like crazy. That's part of the complication.

I think the right approach is to get the path from the code in cyl() and combine it with a second path and do rotate_sweep (or extrude).

[adrianVmariano]

Note: generating the profiles with roundings/chamfers and error handling in cyl() is 80 lines of code.

[adrianVmariano]

I tried to implement this and it was straight forward and looked good until I tried to implement realign. That seems to break the approach and it's not obvious how to fix it. The problem is different rotations may be required on the inner and outer cylinders, so the inside and outside need to be broken up, which then means the caps don't just magically work...seems like it's a mess.

[adrianVmariano]

Maybe it's not desirable to allow the number of sides to differ between inside and outside of tube?