 | | | | | |
In lugnet.cad.dev.org.ldraw, Philippe Hurbain wrote:
| |
There is one more thing to add to Joshua extensive explanations: coplanar
triangle pairs are not assembled into quads. I advocated for that, because
it offers the maximum flexibility when splitting into subparts or adjusting
vertices position (no coplanarity issues). The downside is that you should do
the triangle merging at the end of the cleanup process.
This can be done easily with Rectifier and LETGUI
Philo
|
I realise this is largely off-topic to the oriinal thread but I’ve always been
curious why the use of quads is encouraged when just about every other format
and rendering engine sticks to triangles. So the part author merges triangles
into quads and then whatever software looks at the part undoes the merge.
Tim
| | | | | | | | | | | | | | |
> I realise this is largely off-topic to the oriinal thread but I've always
> been curious why the use of quads is encouraged when just about every other
> format and rendering engine sticks to triangles. So the part author merges
> triangles into quads and then whatever software looks at the part undoes the
> merge.
Good question!
+ reduces file size by 50%
+ 50% less vertices to adjust when building "by hand"
+ triangles plays havoc with smooth shading (the helical artefact that can be
seen here http://www.holly-wood.it/tmp/LEGODraw/m50986.png disappears when
triangles are converted to quads. But I guess it could be solved at renderer
level too.
- More complexity in many tools
- introduces coplanarity issues
Philo
| | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Philippe Hurbain wrote:
> + triangles plays havoc with smooth shading (the helical artefact that can be
> seen here http://www.holly-wood.it/tmp/LEGODraw/m50986.png disappears when
> triangles are converted to quads. But I guess it could be solved at renderer
> level too.
Note that I consider this behavior to be a bug in LDView, and as such I will fix
it when I get a chance.
--Travis
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Travis Cobbs wrote:
> In lugnet.cad.dev.org.ldraw, Philippe Hurbain wrote:
> > + triangles plays havoc with smooth shading (the helical artefact that
> > can be seen here http://www.holly-wood.it/tmp/LEGODraw/m50986.png
> > disappears when triangles are converted to quads. But I guess it could
> > be solved at renderer level too.
>
> 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
I thought the solution was to orient the triangles orthogonal to the curve
of the surface rather than zigzag across it. You don't have to use quads,
but you end up orienting the triangles as if they were quads.
Can you really fix this in software without using a replacement part with
the triangles oriented better? I'd like to hear more about how that works,
especially if it can be adapted for my favorite low end flat shading
renderer :-)
Don
| | | | | | | | | | | | | | | | | |
| |
|
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 thought the solution was to orient the triangles orthogonal to the curve
> of the surface rather than zigzag across it. You don't have to use quads,
> but you end up orienting the triangles as if they were 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.
> Can you really fix this in software without using a replacement part with
> the triangles oriented better? I'd like to hear more about how that works,
> especially if it can be adapted for my favorite low end flat shading
> renderer :-)
Not as far as I know.
--Travis
| | | | | | | | | | | | | | | | | |
| |
|
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
| | | | | | |
