Subject:
|
Re: Torus primitive discussion. was( Updated Primitive - 1-8t0102 1/8 torus)
|
Newsgroups:
|
lugnet.cad.dat.parts.primitives
|
Date:
|
Fri, 23 Feb 2001 05:06:03 GMT
|
Viewed:
|
4449 times
|
| |
|
|
Ok, Let me see if I can make some sense of this... I have read it sevaral times.
In lugnet.cad.dat.parts.primitives, Steve Bliss writes:
> In lugnet.cad.dat.parts.primitives, Lars C. Hassing wrote:
>
> > Paul Easter wrote...
> > > Do you think that this can be easily implimented into L3P? Lars?
> > Sure, I'm just awaiting the final filename convention, so that I can make
> > a programmatic (versus hardcoded) substitution covering all future
> > primitives released. Something like "NtiFFFF.dat" for
> > "1/N Torus Tube Inner Major Radius 1 Tube Radius 0.FFFF"
>
> How about using:
>
> TNNXFFFF.dat
>
> Where T is T, NN is the fraction of the major circle, X is I/O for inner
> or outer, and FFFF is the fractional ratio of tube radius to major radius.
>
> I'm suggesting this specific format for the following reasons:
>
> 1. Putting the T on the front of the filename will provide better sorting
> of the Torus p-files amongst all the other p-files.
OK, great!
> 2. Dedicating the one free filename digit/character to one of the numeric
> parameters will also provide more filename consistency and sorting. And
> giving this the major-circle denominator is more important than having a
> fifth position in the tube:major-radius fraction.
Sorry, can't seem to follow this statement.
> 3. Putting the I/O character between the two numeric parameters will
> improve readability (because it has as a delimiter between the strings of
> digits), at the expense of having somewhat poorer filename sorting.
OK.
> > Which values of N do you expect? 16? - since you only got 4 F's?
>
> I'd expect probably 04, 08, and 16. If we start getting hi-res versions of
> torii, we might see higher values (smaller sweeps). With two decimal
> digits, we can get down to a 3.6-degree sweep (that'd be 1/99).
I agree, but not sure about the 3.6 degree version, that's a bit extreme.
>
> If we need more range/precision in the numeric parameters, we could use
> hexadecimal notation, or even base-36, for those files. But then we'd need
> a way to clearly indicate which files used which notation.
ah... no! I for one can almost read Hexadecimal without a calculator to
convert it, but that was aquired over many years of decoding. Most of the
people I know and consider to be computer knowledgeable cringe when the hear
of something other than base 10.
> Hmm. Three digits of base-36 can match 4.6 digits of base-10. So, if we
> use some screwy base-36 notation from the start, we can have better
> resolution in fewer characters, leaving another filename-character (or two)
> for human-readable tags.
oh no! too complex for the mainstream dat authors.
> Running with this idea a little more, Paul suggested the following torii as
> a start:
>
> > I
> > have a list of suggested files to be generated. Most of them are fractions
> > such as 1/10(.1000), 1/9(.1111), 1/8(.1250), 1/7(.1429), 1/6(.1667),
> > 1/5(.2000), 2/9(.2222), 1/4(.2500), 2/7(.2857), 3/10(.3000), 1/3(.3333),
> > 3/8(.3750), 2/5(.4000), 3/7(.4286), 4/9(.4444), 1/2(.5000), plus a few others.
>
> Using base-36 for the t-m fraction parameter, we get filenames like the
> following. (these examples use base-10 for the major-circle denominator.)
>
> tr04i3ll.dat 1/4 Inner Torus 1:10 ratio
> tr04i400.dat 1/4 Inner Torus 1:9 ratio
> tr04i4i0.dat 1/4 Inner Torus 1:8 ratio
> tr04i555.dat 1/4 Inner Torus 1:7 ratio
> tr04i777.dat 1/4 Inner Torus 1:5 ratio
> tr04i800.dat 1/4 Inner Torus 2:9 ratio
> tr04ifff.dat 1/4 Inner Torus 3:7 ratio
> tr04o3ll.dat 1/4 Outer Torus 1:10 ratio
> tr08o3ll.dat 1/8 Outer Torus 1:10 ratio
> tr16o3ll.dat 1/16 Outer Torus 1:10 ratio
What is the "r" to stand for? Was that just an error in entry?
> Notice that 1 <> l. Hmm, maybe we should disallow a few letter-digits
> (such as o, i, and l) to prevent digit-confusion.
>
> What do you think? I'm not completely thrilled about using a high-number
> base to compress the parameters, but it would work fine. It would just be
> a bit hard to read.
>
> Steve
I'm not sure that we will need very many of torii files, I know I will use
them a bit, In the 15 or so parts I have created, I think I only use the
torii files in 3 or 4 parts. The 3 or 4 parts were specially picked to use
the torus files to help establish their integration.
So do we need to make this so complex? The more complex we make this, the
harder it will be to get authors to use it. I for one have become
frustriated with the torus project. I want to see it through though.
That is enough from me for now.
Paul
|
|
Message has 1 Reply:
Message is in Reply To:
16 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
