Subject:
|
Re: stl2dat conversion tool beta2
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Tue, 15 Feb 2000 17:23:32 GMT
|
Reply-To:
|
RUI.MARTINS@LINK.nospamPT
|
Viewed:
|
1552 times
|
| |
|
|
On Tue, 15 Feb 2000, Marc Klein wrote:
> [SNIP]
> > > In fact, I measure the angle between the normal of the face, but the
> > > result is the same.
> >
> > Iep, but the valid values for the angle differ.
>
> What do you mean ? Isn't a = b ?
>
> \ b|
> \ |
> _ _ _______face
> a /
> /
> /face
> /
What I mean is :
_ _ _______face
a /b
/
/face
/
In that to apply a optional line you have:
: (a) must be BIGGER tha (45)
but
: (b) must be LESSER than (90+45)
Assumming both angles are positive, and that 45 is the reference angle
we talk about before.
> > > 1
> > > /|\
> > > 2-3-4
> > >
> > > to
> > >
> > > 1
> > > / \
> > > 2---4
> >
> > See my previous reply about merges !
> The merging is done only for strict coplanar and adjacent facets, and
> the removed vertex must be on the merged line. In this case vertex[3]
> must be on line [2,4].
Agreed, but more than that, the other polys which share edges
[2 3] & [3 4] must also allow for their merge.
Read on.
> [SNIP]...
> I was told by a person who works in rapid prototyping. And in my cad
> program I cannot save open surfaces so I thought this nevers occurs in
> STL files.
> I will add this case in my program. It should not be difficult.
OK, it's easy to add.
> [SNIP]
> When I talk about facet merging, it is a final process. After the
> creation of edges is done, the program looks if it can remove useless
> vertices. In this step facets can be taken independtly from each
> other, beause dat format handles them independtly.
>
> In the STL file, there is someting like :
> 1-----2
> | |
> 3-----4-----5
> | / \ |
> | / \ |
> 6-----------7
>
> it becomes in DAT file :
> 1-----2
> | |
> 3-----4
> 3-----------5
> | |
> | |
> 6-----------7
Remember this example for reference (*), read on.
> Again, the merging is done only for strict coplanar and adjacent
> facets, and the removed vertex must be on the merged line. In this
> case vertex[4] must be on line [3,5].
Here is where the BAD MODLLING manifests !, but in this case it's your
program which is introducing it, and NOT the Modeller.
you can change that to something like
1-----2
| |
3-----4-----5
| \ |
| \ |
6-----------7
or
1-----2
| |
3-----4-----5
| / |
| / |
6-----------7
See explanation below
> The same checks is done for merging edges.
> 1----2----3
> can be merged to
> 1---------3
> Only if vertex[2] is on line [1,3]
This is correct but incomplete.
Maybe I haven't explained my self well in the last mails, but you should
reread them, they may help you to better understand after the following
add on.
In Theory, you could do what you described in (*), See above, BUT in
practice you can't.
Why ? Because, as I have already said in a previous mail, of the
discreteness (precision, pixels) of your display (card+monitor).
if you draw a line from 3 to 4 and then a line from 4 to 5, actually
making a line 3-4-5, it's diferent from drawing a line from 3 to 5.
In theory they should be the same, but in practice they are not,
especially lines at odd angles (when sides (x,y) coords are not multiples
of each other).
An example is better to show this (an image is worth a 1000 words):
This one got me about 15 minutes to find by hand, but anyway.
I will use this mathematic line equation
y = M * x + B
where m is de slope, to which I give the value (3/7)
(remember NOT multiples above ?)
and B is abciss, which I give the value (-0.5)
Now lets try for 3 colinear points, just define the points (x) coordinate
and with above formula calculate the (y) coords
P1x = -3.5 => y = (3/7) * (-3.5) - 0.5 = -2 => P1y = -2
so
P1 = (-3.5 ; -2)
P2x = +3.5 => y = (3/7) * (+3.5) - 0.5 = +1 => P2y = +1
so
P2 = (+3.5 ; +1)
P3x = +21 => y = (3/7) * (+21) - 0.5 = +8.5 => P3y = +8.5
so
P3 = (+21 ; +8.5)
Now lets define the following .dat file with to lines one between P1-P2
and the other between P1-P3, which should pass by P2 (theoretically)
begin test.dat file (don't include this line)
2 0 -3.5 -2 0 +3.5 +1 0
0 PAUSE
2 14 -3.5 -2 0 +21 +8.5 0
end test.dat file (don't include this line)
put the test.dat file in LDRAW models directory
Now launch LDRAW using LDAO, with the following options:
Resolution : 320x200 4 color Bigger pixels easyer to see
Viewpoint : Oblique
Center Offset : x = 0 , y = -50
Zoom/scale : 500%
Program Mode: Single Step
Now do you see my point, or do you need any further help ?
This proves that if you merge polys and remove some points which belong to
other polys which don't also merge by this point, then you can't merge the
first polys in the first place. Or you will see (open) cracks all over the
place where this occurs.
And even more look to this example in 3D ASCII ART:
1
/ \
3 \
|\ 2
| \ /
6 4
/ \ |\
9 \| \
\ 7 5
\ /|\ |
a | \|
\| 8
b |
\ |
\|
c
where quads [6 9 a 7] & [7 b c 8] are Non Complanar.
Note: tri [7 a b] is prependicular to the 2 quads refered in hte previous
line.
if you merge quads [3 6 7 4] & [4 7 8 5], you will get the (open) cracks
problem along edges 6-7-8 and your merged edge 6-8
I hope I explained my self well this time.
See ya
Rui Martins
|
|
Message has 1 Reply:
Message is in Reply To:
 | | Re: stl2dat conversion tool beta2
|
| On Mon, 14 Feb 2000 20:06:37 GMT, Rui Martins <Rui.Martins@link.pt> wrote: [SNIP] (...) What do you mean ? Isn't a = b ? \ b| \ | _ _ _______face a / / /face / (...) The merging is done only for strict coplanar and adjacent facets, and the removed (...) (25 years ago, 15-Feb-00, to lugnet.cad.dev)
|
14 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
|
|
|
|
