The quick answer is that you are mixing 2D (square, circle) and 3D.
OpenScad treats 2D shapes as having a slight thickness for rendering
purposes, but when creating an actual model the model will be blank
because a square or circle does not exist in 3D space.

Adding a linear_extrude (1) (or some other thickness) will give the
torus-slice a thickness, which is then (SLOWLY) added together to make a
shape.  I say "SLOWLY" because it is going to be resource-intensive;
OpenScad is slow on boolean operations, and it always performs a
top-level union; so you have at least 360 boolean operations it has to
calculate.

This could be sped up by having fewer, but thicker, slices.  The true
wizards here can come up with some variant that uses list comprehension
to generate a polyhedron that will render in blazing speed, but that is
outside my skill.

Side note, the matching brace style is known as Allman style or BSD
style.  I prefer this style myself, although brace style is one of the
Great Religious Flame War topics among programmers.

Here is your code, with a slice size of 10 (affects both the loop and
the linear_extrude).  Renders in decent time on my machine.  The finer
resolution you go the slower it will be.

twistedTorus( 25, 50 );

module twistedTorus( r1, r2, t )
{
for( i = [0:10:360] )
{
rotate( [90, 0, i] )
{
translate( [r2, 0, 0] )
{
rotate( [0, 0, i] )
{
linear_extrude(10) difference()
{
circle( r1 );
translate( [0, -r1, 0] ) square( [r1, 2*r1] );
}
}
}
}
}
}

On 2018-09-25 7:35 PM, Zacariaz wrote:

Pakinbot,

Your sweep.scad alleviates all the burden of defining the faces of the
polyhedron enveloping the section vertices. It is very general and allows
that lofts may be build provided that the user computes all the section
positions and orientation in the space. For simple cases of tubular forms -
that is, all sections are equal - as the present case of twisted torus, the
user computation of the section positions could be avoided by a generic
process good enough for most cases. The strategy of that generic process is
to define the section positions in the planes "orthogonal to the sweep
path" translated to each path point. That is the strategy behind Oskar
Linde sweep.scad found in the list-comprehension-demos.

I guess that a code that computes the section positions for this case would
answer the needs of lots of modeling cases. As an example, the twisted
torus model might have the following simple expression:

use <Naca_sweep.scad> // https://www.thingiverse.com/thing:900137/files

twistedTorus( 25, 50 );
translate( [-50, 0, 0] ) rotate( [90, 180, 0] ) twistedTorus( 25, 50 );

module twistedTorus(r1,r2,N=30)
{
path1 = halfcirc(r2, N);
path2 = Rz_(180, path1);
sect  = Rz_(-90, halfcirc(r1));
half1 = sweep_sections(path1, sect, 180);
half2 = sweep_sections(path2, sect, 180);
sweep(half1);
sweep(half2);
}

function halfcirc(r=50, N=30) =
[for(i=[0:N]) let(w=180/Ni) r[sin(w),cos(w), 0]];

where sweep_sections is the generic function that generates the list of
sections in position.

Loosely based on the Linde's sweep ideas, I have coded sweep_sections as:

// list of total rotations from p[0] to each p[i]
function totRots(n,lrot, Rz=identity(), M=[identity()]) =
len(M)>n ?
M :
totRots( n, lrot, Rz, concat(M, [lrot[len(M)-1]*M[len(M)-1]*Rz] ));

function sweep_sections(path, section, twist) =
let(p  = path,
np = len(p),
Rz = rotZ(twist/(np-1)), // matriz of twist rotation between steps
// tangents to the path p
tgts = [[0,0,1],
-3p[0]    + 4p[1]    - p[2],
for(i=[1:np-2]) p[i+1]-p[i-1],
3p[np-1] - 4p[np-2] + p[np-3]
],
// rotation between two steps
lrot = [for(i=[0:np-1])frotFromTo(tgts[i], tgts[i+1])],
// list of total rotations from p[0] to each p[i]
rots = [for(i=0, Mi=identity(); i<=len(lrot); Mi= lrot[i]MiRz,
i=i+1) Mi] ) // same as totRots(len(p), lrot, Rz)
[for(i=[0:len(p)-1]) transl(transf(section,rots[i+1]),p[i])];

I have resorted to the "C-like for" in its code for simplicity but the
recursive function totRots may be used instead.

The definition above requires a number of useful helper functions I have in
my libraries:

// reflection matrix of direction v
function fmirror(v) =
norm(v)==0 ? [[1,0,0],[0,1,0],[0,0,1]] :
let(u = v/norm(v))
[ [1,0,0] - 2*u[0]u, [0,1,0] - 2u[1]u, [0,0,1] - 2u[2]*u ];

// rotation matrix of the minimum rotation
// bringing di to do
function frotFromTo(di,do) =
norm(di-do)==0 || norm(di)==0 || norm(do)==0 ?
[[1,0,0],[0,1,0],[0,0,1]] :
fmirror(do/norm(do)+di/norm(di)) * fmirror(di);

function identity() = [[1,0,0],[0,1,0],[0,0,1]];

// translation of a sequence of points
function transl(pts, d) = [for(pt=pts) pt+d];

// Z rotation matrix
function rotZ(ang) = let(c=cos(ang), s=sin(ang))
[[c,s,0],[-s,c,0],[0,0,1]];

// transform of a list of points by a 3x3 matrix
function transf(pts,M)  = [for(pt=pts) M*pt];

Ronaldo wrote

This is true and the orthogonal approach can make things easy in certain
cases. But is a somehow oriented half circle (which is a one-liner) still a
simple case?
When I played around with the "original" sweep mentioned by you, I found it
quite difficult to define the right transformation paths and I still find it
a bit callenging.
Therefore I prefer the most general solution as it has a very easy logic:

1. define a (optionally parametrized) 2D-shape in XY-plane
2. map the shape to the desired path using affine operations an iteration
   variable

To a man who has hammer the whole world looks like a nail.

For the discussed twisted half circle torus my sweep indeed supports a
"close" parameter that can be used to close tori with integral twists making
the half tori union obsolete.

twistedTorus( 25, 50 );
#translate( [-100.1, 0, 0] ) rotate( [90, 180, 0] ) twistedTorus( 25, 50 );

module twistedTorus(r1,r2,N=30)
sweep(moebius(r1=100, r2=50, end= 360, twist=1), close = true);

--
Sent from: http://forum.openscad.org/

Ronaldo wrote

As for your first point, good to know. Don't know how I've missed it, but in
this case it doesn't actually matter as it cancels out. It was more for
explanatory purposes.

Secondly I get what you're saying, and believe you me I've ha a lot of
trouble getting the for loops in openscad to behave. The first for loop
defining p pretty much explain the issue.
When working with integers, there really is not issue, because you can
always just say
for( [begin:step:end-1] )
to get the actual range you're looking for, but if your step is not and
integer, in this case 360/s, you need to go to extremes ot make it work,
like
for( [0:360/s:360-360/s] )
which can course problems due to floating point "errors", and don't even get
me started on the case that the loop doesn't start at 0, in which case
you'll have to ensure that you start at a multiple of 360/s, which is pretty
much impossible, when working with floating point values.
I actually did plan to ask what to do in such situations, because it goes
without saying that sometimes 360 iterations just isn't enough to achieve
the desired resolution, so to speak.
Personally I'm used to the C syntax and would much rather have written
for( i = 0; round( i, 3 ) < 360; i += 360/s ) // 3 decimals should be ample
resolution.
and I don't see how to achieve the same effect with openscad syntax, without
going to extremes.

Lastly, what about the center point? I know it isn't strictly needed when
splitting the torus in 2, but I do believe it increases the quality, and it
certainly is need if you wish to split it into 3 or more, or simply use some
arbitrary angle.
Or am I missing something?

And also thanks. To be honest, I can't help to be a little bit proud of
myself. Regardless, I do plan to try again from scratch, to see if I can't
do a better job of it.

--
Sent from: http://forum.openscad.org/

How many steps do you want in a loop?

for (i=[0:N-1]) [ cos(360*i/N),

or

for (i=[1:N]) [ cos(360*(i-1)/N),

something like that...

On 10/9/2018 5:52 PM, Zacariaz wrote: