 | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Travis Cobbs wrote:
> In lugnet.cad.dev.org.ldraw, Don Heyse wrote:
> > In lugnet.cad.dev.org.ldraw, Travis Cobbs wrote:
> > > Note that I consider this behavior to be a bug in LDView, and as such
> > > I will fix it when I get a chance.
> >
> > Isn't this the same problem we ran into with the twisted wedge bricks a
> > while back? Those gave us problematic conditional lines in addition to
> > the ugly zigzag shading artifacts.
> >
> > http://news.lugnet.com/cad/dat/parts/?n=5654
>
> No. This is a different problem. This problem is a bug in LDView's
> smoothing algorithm. LDView uses Type 5 lines in the LDraw file for
> smoothing, and considers any two surfaces that have a Type 5 line
> joining them to be part of a smooth curve. The problem is that two
> co-planar triangles sitting next to each other should also be
> considered to be joined together for smoothing, but they aren't,
> because there is no Type 5 line between them.
>
> Since the two triangles are co-planar, a Type 5 line between them would
> in fact be an error in the part. For some shapes, the problem can be
> gotten rid of in LDView by simply joining the two triangles into a quad.
> However, this should not be necessary, and it only works when the flat
> surface only has four points. Flat surfaces made up of more than two
> triangles cannot be fixed this way, and would require Type 5 lines
> between all their triangles in order to be smoothed properly by LDView.
I see. So what you really want to do in LDView is ignore the Type 5
lines (at least for smoothing) and smooth wherever there's no Type 2
edge lines between the triangles (and quads).
> The reason for the shading artifacts you showed was that the individual
> triangles were in fact forming a bumpy surface, and the shading was
> simply making that more obvious. Rearranging the triangles in the
> curve got rid of this problem.
Did anybody ever did actually fix the parts though? I got about
halfway through part 43721.dat before I lost focus. Meanwhile Philo
introduced the Coverer tool which may have institutionalized the
automatic generation of the problematic bumpy wedge surfaces. You can
see the ugly sawtooth shading on the wedge parts in the documentation
for the Coverer tool:
http://www.philohome.com/isecalc/coverer.htm
The problem is that the naive algorithm generates triangles where the
joins between them alternate between slightly convex and slightly
concave. I think perhaps we might need a warning for that tool to watch
out for this. Or is it possible to fix the tool to follow the convex
and concave saddle curves between the opposite corners instead? Maybe
as an option?
Anyhow I took another stab at the 43721 wedge part after re-reading
Lars' 5 year old comment about just making one octant of a twist
primitive. I used quadrants because it was easier for my feeble brain,
but I think you just scale them and you can use 8 chunks instead of 4.
http://news.lugnet.com/cad/dat/parts/?n=6571
I also didn't do any Type 5 lines yet but I think it's a bit closer
to what we really want than my previous feeble attempt.
Don
| | | | | | | | | | | | | | | | |
| |
|
> Did anybody ever did actually fix the parts though? I got about
> halfway through part 43721.dat before I lost focus. Meanwhile Philo
> introduced the Coverer tool which may have institutionalized the
> automatic generation of the problematic bumpy wedge surfaces. You can
> see the ugly sawtooth shading on the wedge parts in the documentation
> for the Coverer tool:
Sorry for that ;o) But (fortunately) here are very few twisted surfaces in LEGO
pieces, so I don't think my tool has created too much havoc...
>
> The problem is that the naive algorithm generates triangles where the
> joins between them alternate between slightly convex and slightly
> concave. I think perhaps we might need a warning for that tool to watch
> out for this. Or is it possible to fix the tool to follow the convex
> and concave saddle curves between the opposite corners instead? Maybe
> as an option?
Problem is that at this low level I have almost no information about the
intended geometry - I see only a bunch of connected lines.
Philo
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Don Heyse wrote:
> I see. So what you really want to do in LDView is ignore the Type 5
> lines (at least for smoothing) and smooth wherever there's no Type 2
> edge lines between the triangles (and quads).
Actually, no. That is indeed a long-term goal, but it is hampered by two
things. First of all, it's a lot of work. Secondly, the current algorithm is
actually useful to part authors, since it can visually highlight missing
conditional lines. (Of course, since the current algorithm has bugs, that
decreases its utility for this purpose.) If I implement the new smoothing
algorithm you suggest, I'll retain the current one as an optional one for part
authors to use, while making the new one the default one.
My planned fix for the bug in the current algorithm is to add dummy entries in
my "type 5 map" used for the smoothing. So, when I build the map of type 5
lines that is specifically used for smoothing and nothing else, I'll insert
entries between adjacent co-planar triangles. I believe that this should be
straightforward, but I haven't really investigated yet.
--Travis
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Travis Cobbs wrote:
> In lugnet.cad.dev.org.ldraw, Don Heyse wrote:
> > I see. So what you really want to do in LDView is ignore the Type
> > 5 lines (at least for smoothing) and smooth wherever there's no
> > Type 2 edge lines between the triangles (and quads).
> Actually, no. That is indeed a long-term goal, but it is hampered
> by two things. First of all, it's a lot of work. Secondly, the
> current algorithm is actually useful to part authors, since it can
> visually highlight missing conditional lines. (Of course, since the
> current algorithm has bugs, that decreases its utility for this
> purpose.) If I implement the new smoothing algorithm you suggest,
> I'll retain the current one as an optional one for part authors to
> use, while making the new one the default one.
> My planned fix for the bug in the current algorithm is to add dummy
> entries in my "type 5 map" used for the smoothing. So, when I build
> the map of type 5 lines that is specifically used for smoothing and
> nothing else, I'll insert entries between adjacent co-planar
> triangles. I believe that this should be straightforward, but I
> haven't really investigated yet.
Hmmm, it seems to me that any algorithm that can find the missing
Type 5 lines (in order to create the dummy entries) should be able
to find *all* of the Type 5 lines. Some missing lines is just a
special case of all missing. So just include them all in the dummy
list and use that for the smoothing instead of the other list. If
you want to retain the debugging features you can give each one a
tag that labels them as either real, dummy, or missing.
Then, maybe long term, you can do the lotsa extra work to switch the
Type 5 line drawing over to the dummy list as well. And at that point
maybe the standards committee can declare Type 5 lines obsolescent,
making part authoring just a wee bit easier.
Don
| | | | | | |
