Subject:
|
Re: Part Authors: opinions sought on T-Junctions
|
Newsgroups:
|
lugnet.cad.dat.parts
|
Date:
|
Tue, 6 Mar 2007 19:39:47 GMT
|
Viewed:
|
5244 times
|
| |
|
|
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
|
|
Message has 1 Reply:
 | | Re: Part Authors: opinions sought on T-Junctions
|
| (...) 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 (...) (17 years ago, 6-Mar-07, to lugnet.cad.dat.parts, FTX)
|
Message is in Reply To:
| | Re: Part Authors: opinions sought on T-Junctions
|
| (...) 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. (...) (17 years ago, 6-Mar-07, to lugnet.cad.dat.parts, FTX)
|
22 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
|
|
|
|
