Subject:
|
Re: Suggested New Primitive: 4-4cyl12.dat (was: More cylinder primitives wanted)
|
Newsgroups:
|
lugnet.cad.dat.parts.primitives
|
Date:
|
Wed, 17 May 2006 13:36:01 GMT
|
Viewed:
|
5014 times
|
| |
|
|
[Lotsa snipping]
In lugnet.cad.dat.parts.primitives, Chris Dee wrote:
> We could use "rod" as a short base name for these.
I'm fine with that.
Taking up the issues Chris raised (but out of order):
> Do we need to allow for non-360 degree versions?
I think we need to allow for partial rods.
> ... so long as we don't go beyond one digit in the denominator. We could
> still have hi-res, but only in multiples of eigths.
It seems fair to limit rods to single-digit denominators. Since these are
primarily convenience primitives[1], I think it's reasonable to require authors
to use cyli, edge, disc and ndis when they are doing odd angles -- these
situations are 'relatively' uncommon.[2][3]
> ... we would never want a cylinder to disc/ndis interface without the
> corresponding edge.
I can't think of a situation where the edge would need to be omitted. But I'm
not completely sure.
But it's not really a 'never' question, it's more like 'would this happen often
enough to make it worth having a primitive?'. And I'm really sure that it
wouldn't be common enough.[4]
Having said that, I think it's easy enough to allow the possibility (addressed a
bit further down).
> 1) If not, one would be to use a meaningful suffix. Since we only have four
> variables to deal with (the bi-state presence or absence of an edge at each end
> and the tri-state presence of a disc, ndis or nothing at each end) we could
> designate that in a four character suffix (d=disc, e=edge, n=ndis, -=nothing).
> 2) With a litte less clarity would compress the suffix to two quad-state
> indicators (e=edge-alone, d=disc+edge, n=ndis+edge, -=nothing) on the assumption
> that we would never want a cylinder to disc/ndis interface without the
> corresponding edge.
I like the 2-character version much better. Especially since the 4-character
layout doesn't allow fractions.
With the addition of two additional states (for disc w/o edge and ndisc w/o
edge), there's no need to discard any options when going to 2 characters.
e=edge, d=disc, n=ndisc, c=closed (disc+edge), o=open (ndisc+edge),
nothing=plain
(I'm open to other code mappings -- I think 'd=disc+edge, n=ndisc+edge' are more
useful mappings, but I couldn't think of mnemonic alternates for disc-alone and
ndisc-alone)
> Again, the "-" placeholders could be discarded :
Absolutely. If no mirror-image primitives are allowed, and if we specify when
only one end of the rod is decorated, it must be the top end. With those two
restrictions, there should be no ambiguity.
It'd be tidier to specify precedence for all 6 conditions, so we'd always know
where to place each end of the rod (and what name to expect for each primitive).
That is, if disc has a higher precedence than ndisc, then roddn is valid, but
rodnd is not. My suggested precedence would be: closed, disc'ed, open,
ndisc'ed, edged, plain.
> 4) If we do need the fractional designation and we want to support segments
> finer that eights then I see no opportunity to add meaning and we should just
> use N-NNrod1 thru N-NNrod9 arbitrarily for these 9 combinations.
I'm not against going with a low-meaning, single-character indicator. Although
I'd suggest alphabetics instead of digits, at least for the more-common flavors
(ie, e=edged, d=disc on one end, n=ndisc on one end).
> My current preference is 2) without the "-" placeholders, or maybe 3) if someone
> can make a good justification.
My preference is (3) (with my alterations), because I'm sure we'd want the
fractions. And because it captures all the variations, while keeping the length
of the suffix down.
--
Steve
1) 'Convenience' because they are a shortcut replacement for using multiple
cyli, edge, etc. In contrast to odd-angle curved primitives that add
information to the model, because ray-tracers can replace the approximated
curves with true curves.
2) Although it doesn't seem 'uncommon' in the middle of constructing one of
them.
3) Random thought -- it'd be cool to have a 'part developers kit', that would
provide things like arbitrary-angle cylinders, and would produce DAT files in a
format acceptable for publication. Hmm, maybe just a !CYLINDER
meta-statement...
4) C'mon, someone show me wrong!
|
|
Message is in Reply To:
10 Messages in This Thread:
   
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
