Subject:
|
Re: New Part: 3437peye.dat: Duplo Brick 2 x 2 with Eyes Pattern on Two Sides
|
Newsgroups:
|
lugnet.cad.dat.parts
|
Date:
|
Thu, 11 Jan 2001 01:11:40 GMT
|
Viewed:
|
717 times
|
| |
|
|
In lugnet.cad.dat.parts, Steve Bliss writes:
> In lugnet.cad.dat.parts, Tony Hafner wrote:
>
> > Here is a Duplo 2x2 with eyes on both sides. It's a fairly common piece,
> > and I thought it would be a great first printed piece for me to do from scratch.
>
> It looks very nice! Very good job, especially as it's your first time
> doing a printed part.
Thanks- that means a lot coming from someone whose name is all over the
parts library.
> One minor thing, the description of which is kinda longwinded, sorry. It's
> generally better to lay out complex surfaces so the quads and triangles
> always meet at the vertices, instead of having the vertices of some objects
> meeting the middle of the edges of other objects.
As far as I know, I only did this in a few cases. Specifically, I did it
where the points of the eye whites meet the surrounding black ring and where
the inner white dot's bounding box fits against the edge of the quarter-disc
below it.
The former case could have been prevented by breaking the trapezoidal ring
segment into two pieces, which seemed kinda silly. I'd be happy to make
that change if it is considered important, though.
The latter case is almost unavoidable, as it's a case of a primitive
adjacent to a primitive with the colinear edge segments of different
lengths. The smaller primitive has to have a vertex along the larger one's
edge. The only solution I can see is to not use the quarter-disc primitive
for the region below the white dot, and instead building that quarter out of
quads.
> One way you could have done this is to treat the eye as a set of odd-shaped
> rings. Each ring would be composed of a sequence of trapezoids (like the
> various *ring.dat p-files), and the outer edge of each trapezoid would also
> be the inner edge of another trapezoid. In wireframe mode, it would look
> like a spider web, I suppose.
I believe that I did that... didn't I? The outer black ring was done this
way, and the white of the eye was done similarly- it may be misleading
unless you look really closely because the pupil and the white aren't
concentric. This makes the white trapezoids somewhat skewed.
I'm not trying to argue- I just want to make sure we're talking about the
same thing here. As far as I know, I only had such floating vertices in
these two cases. If I did it elsewhere, I'd be happy to reexamine my
techniques.
It seemed to me that having vertices float along edges was a bad thing that
should be avoided when reasonable, but not actually a Bad Thing That You
Should Never Do. Was I wrong?
> To get the coordinates of the trapezoids' vertices, you could have laid out
> several 4-4edge.dat primitives to mark the borders of each ring, then
> inlined the p-files. Of course, then you'd've had to construct the
> trapezoids from the points, which would be tedious.
Heh- that's close to what I did. But I didn't actually put in the
primitives- I calculated the points offline by extrapolating where the
primitives' vertices would lie and then typed in each tri/quad.
Occasionally I would open the file in MLCAD to see if I got everything
right. Yes, it was tedious.
> > Anyway, this isn't *quite* finished. These issues need to be addressed:
> > #1: I don't know which primitive to use for the top stud. This piece uses
> > a scaled-up stud4.dat, which in my opinion is the perfect dimensions.
>
> Use the name stud7.dat. Whatever we stick in the p-file, that name should
> work.
I'm fine with that, but there is still the open issue of height. In one
post, someone suggested that all stud primitives should be 4 units tall and
then if parts need it larger then they can scale it up. This keeps the
studline.dat optimization working correctly. In another post, someone
commented that studs should never get scaled because when you substitute in
other studs (ie for rendering with studlogos) it will get distorted. These
are mutually exclusive goals. I'd love a resolution on this ASAP, because
that's a lot of scaling I may have to undo. I already have done the 4x8 and
6x12 plates. If I just have to point the stud primitive at a new one,
that's a simple replace all. But If I have to muck with the scaling, those
two parts alone represent over 200 numeric changes that can't really be
automated easily (by me at least!)
> > #2: Do we have a range of pattern numbers set aside for Duplo? I need a
> > pattern designator.
>
> Nope, you can call this file 3437p01.dat.
Woohoo! I get #1! Hm, that's not a big deal is it? Are pattern numbers
specific to a given part? In other words, can there be a 3437p01.dat and a
4066p01.dat where the actual patterns on the parts are unrelated?
> > #3: Someone else (Don Rogerson) modeled the binding splines in his Duplo
> > part as being narrower (3x4 instead of 4x4). That looks like it is more
> > accurate, so I'll probably make that change.
>
> Are the 'binding splines' the ribs between the bottom tubes? That's fine,
> let's get some standard dimensions and go with it. I'm guessing the ribs
> vary enough (over time and molds) that there's little point in having
> *exact* figures for them.
No, the "binding splines" are the ones that are along the outer edges that
actually bind to the Duplo part below. They line the inside of each wall,
with one next to each spot where a Duplo stud would fit in. Hm, is that
clear? I ceased modeling the other internal supports (such as the ribs
between tubes), as they aren't functionally necessary.
> Side idea: when we've got an automated parts librarian, we could implement
> a specific meta-statement for comments that could be stripped from the
> files when they are served up for downloads. People who wanted to see the
> comments would retrieve with a different command (or option on the
> command). That way, developers comments could be preserved for later use
> (and I could drop the huge directory of pre-release files on my hard
> drive).
That would be cool, because I do find the comments useful. On the other
hand, they could easily add 10% to the average file size.
Thank you very much for reading this far! And thanks for all the helpful
comments- I couldn't contribute usefully without your insight. Heh- I'm not
sure if modeling Duplo parts is terribly useful to many people anyway, but
at least I'll be using them!
--
Tony Hafner
www.hafhead.com
|
|
Message has 1 Reply:
Message is in Reply To:
7 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
|
|
|
|
