partial torus prims

[Rene Rechthaler]

Hello, as stated here:
t04i8000-075.dat
we may need an addon for new torus prim variants...
as of now, there are only full or quarter (inside/outside) torus prims.
But sometimes we may need cut tori.
https://en.wikipedia.org/wiki/Toroidal_a...oordinates
toroidal is bigringwise (the rotation path), poloidal is smallringwise (the rotated profile)

my suggestion would be a suffix (like the -075)
and the number is the percentage of the full quarter inside/outside torus and the + or - is the direction
(from the inner/outer border or from the center line)

but you are free to discuss
(do we even need this? which way should it be done? 075 or 750? where does +/- start? and more...)

René

[Willy Tschager]

Hello, as stated here:
t04i8000-075.dat
we may need an addon for new torus prim variants...
as of now, there are only full or quarter (inside/outside) torus prims.
But sometimes we may need cut tori.
https://en.wikipedia.org/wiki/Toroidal_a...oordinates
toroidal is bigringwise (the rotation path), poloidal is smallringwise (the rotated profile)

my suggestion would be a suffix (like the -075)
and the number is the percentage of the full quarter inside/outside torus and the + or - is the direction
(from the inner/outer border or from the center line)

but you are free to discuss
(do we even need this? which way should it be done? 075 or 750? where does +/- start? and more...)

René

I'm not against it. We have tndis so why not this. Could you please make some renders as it has been done for:

https://forums.ldraw.org/thread-24731-po...l#pid41927

to get people a clear idea what we are talking about?

w.

[Rene Rechthaler]

   
something like this? (screenshot from LDPE edited with paint)

the addition itself:
t08o800 like the existing syntax
the +/- indicates from where to start
the number states how far to go (+100 would be the same as a -100, a full quarter, no suffix needed then)

usage:
could be useful for chamfers or partially prints
if a torus gets cut somewhere
-> could still apply to prim subst

[Travis Cobbs]

something like this? (screenshot from LDPE edited with paint)

the addition itself:
t08o800 like the existing syntax
the +/- indicates from where to start
the number states how far to go (+100 would be the same as a -100, a full quarter, no suffix needed then)

usage:
could be useful for chamfers or partially prints
if a torus gets cut somewhere
-> could still apply to prim subst

I know this is old, but Willy asked me to comment on this. So I have some comments.

First of all, I would obviously have to update LDView's primitive substitution in order to support this, but it doesn't look like the update would be too difficult.

Having said that, I don't like your proposed suffixes, for two reasons. First, I feel that using 05 for 50% and 075 for 75% just makes things confusing for anyone trying to understand what is going on. Furthermore, unless I'm misunderstanding, the numbers will always be less than 100%, so the 0 prefix also doesn't seem to make sense.

However, while percentages work fine for standard tori, they won't work for arbitrary fractions of 48 tori, since instead of 4 segments (25, 50, 75), there are 12, and 1/12 = 8.333333% (repeating fraction). It's true that we could use three digits (250, 500, 750), and then assume repeating for 083 and 166, but I feel that that would just complicate things further. One option would be to use a four-digit suffix, where the first two digits are the numerator and the second two are the denominator: 0104 for 1/4, 0102 for 1/2, 0204 for 3/4, 0112 for 1/12, 1112 for 11/12, etc.

I'm open to other suggestions, but I don't fell that a percent based number is a good idea. I'm fine the the + and -.

[Willy Tschager]

I know this is old, but Willy asked me to comment on this. So I have some comments.

First of all, I would obviously have to update LDView's primitive substitution in order to support this, but it doesn't look like the update would be too difficult.

Having said that, I don't like your proposed suffixes, for two reasons. First, I feel that using 05 for 50% and 075 for 75% just makes things confusing for anyone trying to understand what is going on. Furthermore, unless I'm misunderstanding, the numbers will always be less than 100%, so the 0 prefix also doesn't seem to make sense.

However, while percentages work fine for standard tori, they won't work for arbitrary fractions of 48 tori, since instead of 4 segments (25, 50, 75), there are 12, and 1/12 = 8.333333% (repeating fraction). It's true that we could use three digits (250, 500, 750), and then assume repeating for 083 and 166, but I feel that that would just complicate things further. One option would be to use a four-digit suffix, where the first two digits are the numerator and the second two are the denominator: 0104 for 1/4, 0102 for 1/2, 0204 for 3/4, 0112 for 1/12, 1112 for 11/12, etc.

I'm open to other suggestions, but I don't fell that a percent based number is a good idea. I'm fine the the + and -.

I recently started breaking that 8.3 nomenclature:

https://library.ldraw.org/parts/45361 (2-4chrd-w-edge.dat)

in the hope for more meaningful file names. Please consider leaving all cryptic name standards behind. As of the + and - I just found out that "+" works well in an editor like LDPE, but you cannot download a part from the PT with a "+" in the file name, so that would have to be fixed first

w.

[Orion Pobursky]

"+" isn't a URL friendly character since it has meaning in a URL much like "&", "#", and "/"

[Hageta]

"+"  in search a engine url is used as the space character (" ").

[Peter Blomberg]

What about updating the naming as follows?

sweep:

first number states the number of segments
second number states the resolution (8, 16, 48)

1-8
11-16
11-48
8-8, 16-16, and 48-48 would be full circles in different resolution

tori:
major sweep + "t" + major radius + "i"/"o"/"p"/"q"/"t" + minor sweep + "m" + minor radius

The 'i'nner starts from major-minor
The 'o'uter starts from major+minor
The 'p'erpendicular starts from major and continues inwards (toward major-minor)
The 'q' starts from major and continues outwards (toward major+minor)
A 't' contains the whole tube (2 inner + 2 outer) (minor sweep and "m" not needed)

cones and rings:
major sweep + "con" + major radius (minor assumed 1)
major sweep + "ring" + major radius (minor assumed 1)

cyls:
"cyls" major sweep + "i"/"o"/"p"/"q" + major radius
i starts from the low end, currently cyls
o starts from the high end
p starts from the middle and continues toward the low end, currently cyls2
q starts from the middle and continues toward the high end

spheres:
"sphe" major sweep + "i"/"o" + minor sweep
i starts from pole
o starts from equator (where major sweep is defined)

the "one-eight" of a sphere would be sphe4-16o4-16
a shallow puddle would be sphe16-16i1-16

[Rene Rechthaler]

   
edited the upper picture to fit the p+q suffix
p starts from the center line outwards
q starts from the outermost/innermost and goes inwards
last digit is the number of hi-res segments
(hexadecimal to fit it into 1 digit, its - 8 - 9 - a (10) - b (11) - c (12) would be a full quarter -> no suffix needed)
the normal res ones are 3 (1/16) - 6 (1/8) - 9 (3/16)
"special" ones on hi-res are 4 (1/12=30°) and 8 (1/6=60°)
idk how the condlines should be (tangential or continuous)

[Travis Cobbs]

the normal res ones are 3 (1/16) - 6 (1/8) - 9 (3/16)
"special" ones on hi-res are 4 (1/12=30°) and 8 (1/6=60°)

Just as a note, I initially had no idea what you were trying to say here. I eventually realized that the fractions in parentheses are the fractions of a full 360° circle.

[Peter Blomberg]

My suggestion was slightly different. Here's a picture:
   

[Willy Tschager]

Could we please be a little less cryptic with the filenames? You have 255 characters at your disposal. Anyone won't remember them anyway as dics or chrd, but probably copy them from the primref as I usually do. So a "P" or "Q" is meaningless. Use "CW" or "CCW" or "plus" and "minus".

w.

[Peter Blomberg]

I agree that one could use more characters for clarity.

However, if one always copies from the primref, it doesn't matter what is being copied. A systematic naming scheme helps interpret the line once written (reviewing, editing) and helps people generate the right filename without looking at the primref.

The existing tori naming scheme is vastly different from how other prims are named, and thus I suggest improving it.

We have two degrees of freedom here. One for the starting point of the prim, and the other for which direction it continues.

In the context of tori, CW and CCW have just as little meaning for me as p and q have for you. I visualize the major rotation axis on the left and a half circle on the right such that it opens downward. Then 'inner' is the vertex closest to the major rotation axis and 'outer' is the vertex furthest away. For these two starting positions, it doesn't matter which direction the shape continues because it is symmetric in each case. That leaves one starting position, perpendicular to the other two. For convenience, I choose the vertex at the top of my half circle. From this position, one can continue either inwards or outwards. If I write the small letters p and q and put a small arrow at the end of those characters, I immediately see that p is the one going inwards and q outwards. You may have similar visualizations or memory rules for CW and CCW, or plus and minus. The thing is that someone else will likely have a different memory rule which clashes with yours.

We can thus choose from:
inner / small
perpendicular / mid
outer / large

and:

inwards / CCW or CW / plus or minus / p
outwards / CW or CCW / minus or plus / q

For the description, we would definitely choose "inner", "perpendicular inwards", "perpendicular outwards", and "outer", but can we agree on the file naming?

[Rene Rechthaler]

I would avoid using "inside" and "outside" again, these are already used for the full quarters...
I didnt find any mathematical terms for the main lines of a torus:
https://en.wikipedia.org/wiki/Torus#/med..._torus.png
so I looked for other location terms and found them in the anatomy:
- ventral (belly sided) could be the innermost ring
- dorsal (back sided) could be the outermost ring
- lateral (side) could be the side ring
- medial (center) means to the center
>indexes from inside to outside: v as the innermost, then m medial, l for lateral and d as outermost
>the number as before...

edited the wikipedia pic:
   

[Peter Blomberg]

Medial (toward the centre) and lateral (toward the side/edge/outside) are very good suggestions.

However, I'd prefer orbit nomenclature; periaptic (inscribing circle) and and apoaptic (circumscribing circle) for the other two.

[Peter Blomberg]

What about proximal (closest) and distal (furthest away)?

proximal - medial - lateral - distal

[Willy Tschager]

What about proximal (closest) and distal (furthest away)?

proximal - medial - lateral - distal

We should rather use more common descriptions like plus/minus, clockwise/counterclockwise ...

w.

[N. W. Perry]

something like this? (screenshot from LDPE edited with paint)

the addition itself:
t08o800 like the existing syntax
the +/- indicates from where to start
the number states how far to go (+100 would be the same as a -100, a full quarter, no suffix needed then)

usage:
could be useful for chamfers or partially prints
if a torus gets cut somewhere
-> could still apply to prim subst

I have read over (several times) the various suggestions, but I return to this as the most elegant solution so far. It is subject to a couple of problems that have been mentioned…

We really only need to know two things:

1. how many segments of the minor radius (the tube itself) there are, and
   
2. whether we're counting from the plane of the major radius or from the perpendicular axis of the tube.
   

For #1, I'm ok with using a percentage or ratio, since we already do that for the ratio of the minor to major radius. But to Travis' point on that, there is probably a simpler way. I propose using the number of digits to signify the resolution (16 or 48), and then just use a cardinal number to that many places. In other words, a 16-res tube will always have a one-digit value of 1, 2 or 3 (since 4 would be a full quarter, already covered by the existing standard). And, likewise, a hi-res tube would have a two-digit value from 01 to 11.

For the direction, the + and - characters are intuitive enough for this, but '+' in particular is not acceptable so we just need different signifiers. Maybe p and q could work, or to Willy's suggestion of abandoning cryptic codes in favor of descriptive terms, maybe just spell out "plus" and "minus". Maybe h and v are better choices: h means measuring from the horizontal plane of the major radius (think of standing on that plane, you'd be measuring from the "horizon"), and v means measuring from vertical plane of the minor radius (if you're standing in the tube, look up to the "vertex" of the tube and count from there).

We don't need to know if we're counting "up" or "down" from the horizontal plane, since the y-factor determines this. And we don't need to know if we're counting towards or away from the center of the torus, because we already know whether it's an inner or outer torus.

Peter's suggestion of a full re-working of the naming convention is interesting and raises valid points, but I would place it outside the scope of the immediate question, which is how to designate a new set of partial-tube tori. And the question of different terminology to describe the directional measurements is fascinating, but ultimately more academic than instructive when it comes to providing a useful naming convention.

So in summary, I would suggest using Rene's original proposal, except with the rules for the suffix modified as follows:

• 'h' instead of '+', and 'v' instead of '-'
  
• 1-digit (for 16-res) or 2-digit (for 48-res) value for the number of segments of the partial tube
  

The examples from the original image would thus be:

• Green: t08o8000h1
  
• Pink: t08o8000v3
  
• Blue: t04i8000v2
  
• Red: t08o8000v2
  
• Yellow: t08o8000h2
  

[Magnus Forsberg]

How about odd number segments?
Todays numbering rules only allow even numbers; 2, 4, 6, 8, 12, 16, 24, 48

[Rene Rechthaler]

Thats a very good suggestion!
How does that get integrated in the text title / description?
Torus (Inside/Outside) 1 x (Size) x (fraction ringwise/toroidal) x (number of segments poloidal) (horizontal/vertical)

Still leaves the question of condlines...
as of now, the two on the tracker have "continous" condlines.
(I took a full quarter torus and deleted the not needed faces and condlines manually)
Is that correct or should the "cut" end have tangential or no condlines?
Any way to automate this or should they be created by editing generated tori?
(I guess this wont be used that much as full torus prims)

for odd amounts of sections (ringwise): would a third (t03) be allowed?
if finer/other sections are also allowed, I would use the "standard" nomenclature like t11-48

[N. W. Perry]

How about odd number segments?
Todays numbering rules only allow even numbers; 2, 4, 6, 8, 12, 16, 24, 48

For the major sweep? Some exist already, others could be added:
1 segment would be 48 (inverse of 1/48)
3 would be 16 (inverse of 1/16)
Others could be rounded or truncated:
5 would be 09 (truncated inverse of 1/9.6) or 10 (rounded)
7 would be 06 or 07
etc.…

But you eventually run into where numbers are duplicated (for example, both 9 and 10 segments would round to 05, and many of the higher numbers would truncate to 1). And it does bother me a little bit if the major sweep is a fraction while the minor sweep is a segment integer.

You could change the major sweep to also be a segment integer (2 digits for 16-res, 3 digits for 48-res, or just let the 48\ prefix determine), but that does break backward compatibility.

Another option is Travis' idea of showing both numerator and denominator; existing fractions could be retained with the "1-" being assumed, with others added to the spec like 5-48 and 7-48. This has the benefit of expanding the possibilities without breaking the existing syntax

On the other hand, if we come up with a code for 5 segments (10 seems like a nice round number) in the existing syntax, then any other odd-number segments could be combined with 6-segment slices to get any combination.