 | | | | | |
| |
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?
--Travis
|
It’s possible that by setting up meshes POVray can largely avoid the problem as
it rotates points and then joins them. My opinion is that Part Authors should
stick to keeping the polygon count down rather than jumping through hoops to try
to avoid a problem which I suspect is fairly rare and not that important (it’s
only likely to be a problem at high-zoom).
Tim
Tim
| | | | | | | | | | | | | | |
In lugnet.cad.dat.parts, Timothy Gould wrote:
| |
It’s possible that by setting up meshes POVray can largely avoid the problem
as it rotates points and then joins them. My opinion is that Part Authors
should stick to keeping the polygon count down rather than jumping through
hoops to try to avoid a problem which I suspect is fairly rare and not that
important (it’s only likely to be a problem at high-zoom).
|
It’s not really constrained to high zoom. If you have a 1% chance of any given
pixel along any given T-junction boundary edge resulting in a hole, then you’ll
have the roughly the same number of holes at any zoom level, since in general
the only reason to be zoomed further out is because there are more parts. It’s
true that the holes will be more randomly scattered (instead of showing up in
lines like my example), but they will still be present in roughly equal
quantities. Note also that they tend to be more obvious when rotating a part,
as their random nature causes them to pop in and out of existence, attracting
the eye to their presense.
And even if POV-Ray doesn’t suffer from the problem (which I still don’t know
one way or another), the relatively small number of additional polygons are
likely to have a minimal impact on the performance of POV-Ray. I’d say that
they’re unlikely to have a significant impact of the performance of realtime
viewers also, but since it can provide a noticeable improvement in realtime
viewers, I think it’s more helpful there.
--Travis
| | | | | | | | | | | | | | | | |
--snip--
| |
And even if POV-Ray doesn’t suffer from the problem (which I still don’t know
one way or another), the relatively small number of additional polygons are
likely to have a minimal impact on the performance of POV-Ray. I’d say that
they’re unlikely to have a significant impact of the performance of realtime
viewers also, but since it can provide a noticeable improvement in realtime
viewers, I think it’s more helpful there.
--Travis
|
Just to be clear it’s not the render time I’m worried about... it’s the
authoring time.
Tim
| | | | | | |
