Subject:
|
Re: Taking shortcuts
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Wed, 21 Jul 2010 06:21:31 GMT
|
Viewed:
|
33569 times
|
| |
|
|
In lugnet.cad, Roland Melkert wrote:
> In lugnet.cad, Ronald Vallenduuk wrote:
> > As I've recently started creating parts I've been taking a closer look at how
> > other parts have been made. I've noticed that sometimes there are overlaps that
> > keep the file smaller. My question is: what is more important; having 'correct'
> > parts or smaller files?
> > For example take a look at npeghol2.dat. The two quads on the outside will
> > overlap with rings put on either side of this part. To avoid the overlap there
> > should be two quads on either side to follow the ring.
> > So what's best? The smallest file or no overlap?
> >
> > Ronald
>
> I'm not a part author, but from a rendering engine author's point of view. Those
> kind of overlaps can cause very ugly artifacts during rendering, so imho saving
> a couple of bytes (on harddrives containing 1.000.000.000.000 bytes these days!)
> is not worth it.
>
> Roland
I'm replying here in part because your anagramatic names compel me to do so.
Anyway, I asked this same basic question a little while back:
http://news.lugnet.com/cad/dev/?n=5972
Though, given the intervening span of time, I suspect that the prevailing wisdom
has changed.
However...
If overlap-generated artifacts are a problem, then isn't it equally a problem to
have studs resting right on top of a box-based element like a 2x4 brick? That
is, shouldn't we require each stud.dat to be surrounded by a radius-6
4-4ndis.dat, along with a series of linetype-4 statements to fill in the rest of
the space?
After all, what becomes of the radius-6 footprint made by each stud? Presumably
this would be a problem on almost *any* element that has studs on polygons
rather than on an ndis.dat, no?
Incidentally, the same would be true of the stud4.dats on the underside of the
brick.
Or is this kind of overlap deemed acceptable/irrelevant?
|
|
Message has 2 Replies:
 | | Re: Taking shortcuts
|
| Indeed: "bad" overlaps (and in particular flase intersections that are bleeding trhough to the site of the part where they are not supposed to be visible) cause disturbingly bad render errors. But on the other hand, "good" overlaps don't generate (...) (14 years ago, 21-Jul-10, to lugnet.cad)
| | | Re: Taking shortcuts
|
| (...) I'm used to getting called Ronald by 'new' people all the time. :) (...) Those studs merely touch the surface, that's not going to be a problem. But when two polygons overlap, how their pixels end up onscreen can be frame/driver dependent and (...) (14 years ago, 21-Jul-10, to lugnet.cad)
|
Message is in Reply To:
| | Re: Taking shortcuts
|
| (...) I'm not a part author, but from a rendering engine author's point of view. Those kind of overlaps can cause very ugly artifacts during rendering, so imho saving a couple of bytes (on harddrives containing 1.000.000.000.000 bytes these days!) (...) (14 years ago, 20-Jul-10, to lugnet.cad)
|
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
|
|
|
|
