| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
In lugnet.cad.dat.parts, Mark Kennedy wrote:
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
So, what do you as part authors think? Should T-junctions be avoided
in order to avoid the rendering errors that they can introduce, or
should part authors continue to strive to make parts with the fewest
number of polygons possible?
|
I try to minimise file size whenever possible myself and have nothing
against T juctions. While the gaps can be annoying I feel that they are a
fault of the rendering program rather than the parts.
|
I’d really appreciate it if you didn’t blame it on the rendering programs.
There’s really nothing that they can do to fix the problem. I can
understand why you might feel that they are at fault, but it really
isn’t true.
|
Well... Technically it is true. The rendering program ought to be
able to scan all the points in each part and look for intersections
with every edge in the part. Then break up the offensive T-joins
automagically and render it perfectly. That’s only O(n^2) or so.
Blink of an eye on today’s processors.
Doesn’t ldview do this already? I’m sure txt2dat does. Try to be
a little more up to date, will ya? ;^)
Have fun,
Don
|
|
| |
In lugnet.cad.dat.parts, Don Heyse wrote:
| |
Well... Technically it is true. The rendering program ought to be
able to scan all the points in each part and look for intersections
with every edge in the part. Then break up the offensive T-joins
automagically and render it perfectly. That’s only O(n^2) or so.
Blink of an eye on today’s processors.
|
OK, I stand corrected. Technically a program can fix things a load time.
However, you might be surprised at how long it takes. It’s “only” O(n^2), but
each iteration is slow. You have to search the current line segment against
all other line segments in the part, and find any partial overlaps. And n in
this case is the total number of points in the entire part, not just the current
file, since it’s perfectly valid for things to blend across sub-part/primitive
boundaries (look at where the studs meet the main body of the 2x2 round brick).
| |
Doesn’t ldview do this already? I’m sure txt2dat does. Try to be
a little more up to date, will ya? ;^)
|
Assuming txt2dat does this, bear in mind that it doesn’t really have to be all
that fast, since it gets run once and the generated data then gets used as often
as needed. Mind you, I’m guessing that it would actually be reasonably fast,
but the total number of points isn’t likely to be all that large. Feed the
crater baseplate into the same algorithm, and it might take a noticeable amount
of time. Oh, and txt2dat can do it in 2D, which is both easier and faster than
in 3D.
Having said all that, I’d personally be surprised if txt2dat does it at all. It
knows where all the outline points are on the text; I’m assuming it just uses a
standard concave polygon tesselation algorithm for each character in the text,
and the same thing for the background quad (treating the text polygons as
holes).
And, if you want to see that these types of things can take enough time to be
noticeable, turn off primitive substitution in LDView, then load a big model
both with and without curve smoothing enabled. It will take longer with curve
smoothing enabled. Brad Hamilton’s cathedral model, for example, reloads in 5
seconds with curve smoothing disabled, and 13 seconds with curve smoothing
enabled. (With primitive substitution turned on, it takes 8 seconds with curve
smoothing enabled, because none of the studs have to be smoothed.) Granted,
that model has 5655 parts, which is a lot, but those timings are on a 3.8GHz P4.
The difference in load times is purely based on the algorithmic complexity of
the my curve smoothing algorithm (which I’m going to estimate will run faster
than this proposed algorithm, although I could be wrong about that).
--Travis
|
|
| |
In lugnet.cad.dat.parts, Don Heyse wrote:
| |
Well... Technically it is true. The rendering program ought to be
able to scan all the points in each part and look for intersections
with every edge in the part. Then break up the offensive T-joins
automagically and render it perfectly. That’s only O(n^2) or so.
Blink of an eye on today’s processors.
Doesn’t ldview do this already? I’m sure txt2dat does. Try to be
a little more up to date, will ya? ;^)
|
Well actually what txt2dat does is a slightly different problem - it has a few
simple closed loops and has to triangulate the complex polygons bounded by them
(it uses the excellent triangle
library to do that).
Renderers on the other hand would have to check every edge for intersections,
and perform rudimentary triangulation when an intersection is found. And only to
correct a small problem on a minimum of parts - that’s a fair bit of extra
processing for not much gain, when the problem COULD be corrected at the
source...
I do however agree that it should not be a requirement for parts, but rather a
suggestion for authors. Maybe it could also be a suggestion for renderer
authors, to provide the extra processing as a switchable option.
ROSCO
|
|
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
In lugnet.cad.dat.parts, Don Heyse wrote:
| |
Well... Technically it is true. The rendering program ought to be
able to scan all the points in each part and look for intersections
with every edge in the part. Then break up the offensive T-joins
automagically and render it perfectly. That’s only O(n^2) or so.
Blink of an eye on today’s processors.
|
OK, I stand corrected. Technically a program can fix things at load time.
However, you might be surprised at how long it takes. It’s “only” O(n^2),
but each iteration is slow. You have to search the current line segment
against all other line segments in the part, and find any partial overlaps.
And n in this case is the total number of points in the entire part, not
just the current file, since it’s perfectly valid for things to blend across
sub-part/primitive boundaries (look at where the studs meet the main body of
the 2x2 round brick).
| |
Doesn’t ldview do this already? I’m sure txt2dat does. Try to be
a little more up to date, will ya? ;^)
|
Assuming txt2dat does this, bear in mind that it doesn’t really have to be
all that fast, since it gets run once and the generated data then gets used
as often as needed....
|
blah, blah, blah, snip
Oops, I was trying to be all ironical in a geeky math sorta way. But
apparently I failed. Guess I shoulda used more winkies... Do people
still use winkies? Or have they gone obsolete like ASCII art?
Anyhow, sorry about that. Have fun,
Don
|
|
|
