Subject:
|
Re: Colinear Vertices
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Fri, 12 Dec 2008 19:04:38 GMT
|
Viewed:
|
6711 times
|
| |
|
|
In lugnet.cad, Philippe Hurbain wrote:
> An example, this button:
> http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/55968.dat
> Granted, I rounded condlines to 2 decimal places since I couldn't get smoothing
> anyway. I did more experiments, with full precision in condline it works:
I played with the settings, and I had to set the precision all the way down to
0.133 in order to get it to fully smooth. (0.125 failed to smooth properly.)
> http://www.brickshelf.com/gallery/Philo/Misc/cone-prim.dat, but after rounding
> to 3 dp there is no smoothing between cone sections:
> http://www.brickshelf.com/gallery/Philo/Misc/cone-prim2.dat
The 3 dp version smoothed properly with a precision at .00667 (1 / 150), but not
.005. I think I'll set the precision to .01, to hopefully give it some leeway.
I realized while investigating this that there is another problem in my curve
smoothing that I have always been aware of, but forgot to mention. Smoothing
between primitives doesn't work when primitive substitution is enabled. There
are things I may be able to do to fix that, though; I'll investigate the
performance implications. So while it smooths properly with the precision set
to 0.01 with primitive substitution disabled, it doesn't smooth properly with
primitive substitution enabled.
> > conditional line, no smoothing will be done. The way that conditional lines are
> > used in parts ends up making this problem significantly less common than might
> > be expected.
>
> ...though it does happen, and is sometimes hard to avoid in some cases.
> An exemple (raisonably easy to solve here) is this part:
> http://www.ldraw.org/cgi-bin/ptdetail.cgi?s=61069
> I choose to ignore the problem to minimize part complexity:
> http://www.brickshelf.com/gallery/Philo/Misc/61069s011.png
> Splitting the top quad and adjusting condline length only moves the problem:
> http://www.brickshelf.com/gallery/Philo/Misc/61069s01a1.png
> For perfect result I had to add a condline between _coplanar_ top quad and
> triangle: http://www.brickshelf.com/gallery/Philo/Misc/61069s01b1.png
You're correct, it does happen. And the part isn't really contrived, since it
is obviously a real part. Of course, unless I'm misunderstanding, the first
version also had a T-Junction, which is generally good to avoid ;-). The reason
I never handled this is that I couldn't think of an efficient solution. The
problem with the inverted solution I discuss below is that it pretty much
requires a solution in order to be viable.
> > > Similarly, assembling mirrored subparts that should form a smooth surface work
> > > well, but if they are rotated I generally see the seam since there is rounding
> > > error, and condline smoothing doesn't happen.
> >
> > I could easily decrease my precision. Do you have a specific part that you
> > could point me to as an example?
> An exemple: http://www.brickshelf.com/gallery/Philo/Misc/pear.dat is a nice
> smooth pear... but after splitting in 1-16
> (http://www.brickshelf.com/gallery/Philo/Misc/pear1-16.dat) smoothing doen't
> occur everywhere it should:
> http://www.brickshelf.com/gallery/Philo/Misc/pear16-16.dat
The above 16-16 pear worked fine with my precision set to 0.01, so hopefully
that change will help things. On a side note, your BFC for the whole pear (both
versions) is inverted. You need to change the CCW to CW.
> > document gives a precision of three decimal places, perhaps I should drop mine
> > to .001, instead of .0001. Or maybe .005. I plan to have an LDView 4.0 Beta 2
> > release, so at least I'd have a chance to get feedback. Thoughts?
>
> I think it would be a good thing (to be tested of course!). 0.005 would be good
> imho.
I'm honestly not sure why .005 isn't cutting it, but I I'll go with .01 for
LDView 4.0 Beta 2. I'll ask people to keep their eyes peeled for surfaces that
are smooth when they shouldn't be when using that version.
> > On a related note, I have long considered an optional inverted smoothing
> > algorithm for LDView, where it smooths adjacent faces that DON'T have a type 2
> > line between them, instead of smoothing faces that DO have a type 5 line between
> > them. The problem there is that I would probably have to detect when polygon
> > points lie along the line, instead of just checking the line end-points.
>
> Would it be really bad performance wise? This would avoid the need for condlines
> on concave surfaces...
I'm not entirely sure how this would effect the performance. I have a suspicion
that it would be really bad in certain cases, and not too bad in most cases.
Turn off primitive substitution and load a baseplate up even with the current
curve smoothing, and you can see that it's relatively slow. It could be that I
can detect these intersections relatively quickly, and the change won't have a
significant performance impact. I can't think of a way off-hand to do that,
though.
The main reason I haven't done it yet is because I know for a fact that it's
going to be a lot of work to implement, even without detecting vertices that are
along an edge. I know that based on the fact that the current curve smoothing
was hard to implement, and the inverted algorithm isn't really any easier.
Granted, I'll be able to use much from my current algorithm when working on the
new one, but it's still not going to be an easy task. (There's also the point
that I did the current smoothing so long ago that I only have a vague
recollection of how it works, so I'll first have to reacquaint myself with the
current algorithm. The good news there is that I went overboard on the comments
for the current algorithm, so that shouldn't be too hard.)
So there's a known large amount of effort needed to implement the new algorithm,
and no guarantee that it will provide acceptable results, and even less
guarantee that it will provide better results than the current algorithm.
--Travis
|
|
Message has 2 Replies:
 | | Conditional Ring primitive?
|
| (...) I just noticed something else while investigating a fix for the above problem. The above model could really use a circular conditional edge primitive. I would vote for x-ycedge.dat as the filename (ie 1-4cedge.dat, 4-4cedge.dat, (...) (16 years ago, 12-Dec-08, to lugnet.cad)
| | | Re: Colinear Vertices
|
| (...) I'll need to keep 3 dp in this case. But since it didn't smooth anyway I had no incentive to enlarge the file... (...) OK, we'll see if there is downsides to this. Maybe for very small details? Have a look at some fine mesh parts such as (URL) (...) (16 years ago, 13-Dec-08, to lugnet.cad)
|
Message is in Reply To:
| | Re: Colinear Vertices
|
| (...) It makes sense! (...) An example, this button: (URL) I rounded condlines to 2 decimal places since I couldn't get smoothing anyway. I did more experiments, with full precision in condline it works: (URL) but after rounding to 3 dp there is no (...) (16 years ago, 12-Dec-08, to lugnet.cad)
|
39 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
|
|
|
|
